_要塞_に囲まれて開発に勤しむD氏

社内の公用語はSQL?! 10年間の営業文化を一瞬で変えた最強のBIツールの開発秘話

こんにちは!アイアンドシー・クルーズの広報です。

今回は、IACCバスティオン計画を構成する1つであり、社内BI(Business Intelligence)ツールである「Bad Intention」について、テックリードのDさんに聞いてみました!

今では事業部メンバーの多くが利用する、IACCのサービス成長になくてはならないツールとなっているんです。


ーーそれでは、Dさん、よろしくお願いします!

D氏 はい、よろしくお願いします。

福士さん

D氏
IACCのテックリード。バスティオンを一人で司る、エンジニアチームの
マネージャー。自他共に認めるテクニカルアーティスト

社内BIツール「Bad Intention」とは

トップ画像

Bad Intentionトップ画面

ーーまずはじめに、Bad Intentionとはどのようなツールなのでしょうか?

D Bad Intention(通称BI)は、オンライン上で自社サービスのあらゆる情報を取り出したり集計したり出来るフルマネージドクラウドサービスです。

わかりやすく言うとGCP (Google Cloud Platform) が提供している BigQuery のようなツールです。

社内のバスティオンアカウントさえ持っていればWeb上からSQLクエリの実行が行えます。

今やBad Intentionは各サービスに携わるメンバーのほとんどが日常的に使っています。

以前の記事のように、これまでいくつかのバスティオンツールを開発させてもらいましたが、その中でも特にアンダーカルチャーな部類のBad Intentionがここまで社内で普及するとは思っていなかったので、正直驚いているというか、完全に想定外でした。

社内BIツール開発の経緯

ーーBad Intentionの開発に至った経緯を教えてください。

D 元々の原型は自分向けのデバッグツールだったんです。簡単にSQLクエリを試すことが出来て、それを元に自動的にプログラムを生成してくれるというツールでした。GUIもいかにもエンジニアが作っているような画面でした。

今から1年半くらい前にそれを使ってデバッグ作業をしていたところ、ちょっとしたきっかけで当時のディレクターに見つかってしまって(笑) 「面白そうですね!僕も使ってみたいです!」って。それが全ての始まりでした。

SQLの触りだけは知っていたみたいですけど、そこからの彼の習得スピードはすごかったです。スキルが上がるのと同時に「こんな機能作れませんか?」みたいな相談事が段々と増えて来て。このツールの思想に反さない範囲で極力応えて行きました。

この頃からもう1人ジョインして、「もしや市販のBIツールよりも今の弊社には合っているのでは?」のような話が出始めました。

ちょうど同じ頃に別の部署で本家のBI (Business Intelligence) を導入して、使い方に四苦八苦していた時期だったので、本家に先駆けてうちらが独自に進めてしまおうと。

偶然にもギーク寄りなメンバーが揃っていたので、BIの頭文字を取ってBad Intentionと名付けました。Bad Intentionとは元々悪巧みという意味なので、本家へのちょっとしたアンチテーゼとしてちょうどピッタリでした(笑)

膨大な情報群

あらゆる情報が瞬時に取り出せるダッシュボード

いかにしてBIツールが社内に浸透していったのか

ーーなるほど。そんな誕生の経緯があったのですね。そこからどうやって社内に広まって行ったのですか?

D そこからいきなり広まったわけではなくて、一旦エネルギーメディア事業部内でBad Intentionのワークショップが開催されたのですが、この時の反応があまり良くなかったのは覚えています。

SQLワークショップの様子

SQLワークショップの様子

そりゃそうですよね、みんなSQLの知識が全く無いのに「さぁ、好きなようにSQLを書いてみましょう!」って(笑)  そんなこともあって自分の中では結局SQLを書ける人だけが使ったらいいとしか思っていませんでした。

その頃、時を同じくしてサービスも調子良くなって来て過渡期に入って来た時にみんなが一斉に「データを分析したい!」っていうブームが来たんです。分析のためにとにかく何でもかんでも全量をcsvでくださいって。

テーブルが複数に分かれているのに全量ってどうやって出すの?って言っても伝わりませんでした。そもそもサイズも巨大すぎて、とてもExcelで開ける量じゃなかったんです。

ーーたしかにExcelとなると開けるサイズにも限界がありますよね…

D 一方で、例えばリテンション率を求めたいって。じゃあその分子と分母は?って聞くと意外と答えられなかったりするんですよね。

それってSQL以前の問題なので、そもそもそういうものを考える癖が付いていなかったんです。これは正規の高額のBIツールを導入していたところで結果的に同じ問題にぶち当たっていたと思います。

そこからですね。気付いたらいつの間にか他の事業部にまで広がっていました。データドリブンに対して熱量の高いメンバーが多かったんだと思います。

そこから「社内の公用語はSQLか」ってくらい急激に浸透して、今やサービスに関わるほとんどのメンバーがスラスラSQLを書いて、自在に自分の必要な情報を取り出しています。

ーーそれはすごい!

D 一部ではプログラマたちもびっくりするくらい高度なSQLスキルを持っているメンバーたちも台頭して来て。

多くのメンバーがこれだけ高度なSQLを書けるようになって来たことは、もしかしたら他所にはない弊社ならではの新しい強みになったのかも知れません。

今やエンジニアがデータを加工したり提供したりすることはほとんどなくなったので相当楽になりました。形も決まっていないようなものを、また、出したら出したで「違う」と言われるようなものをやらなくて良くなったのは、多くのエンジニアのストレスや工数が相当軽減されたと思います。

SQLクエリの実行画面

SQLクエリの実行画面


ーーでも、「誰でも情報が取り出せる」と聞くとちょっと危険な面もありそうですね。

D そこに関してはセキュリティ対策も十分に行っていて、基本的に結果画面をコピペしたりスクリーンショットを撮ったりする行為をソフト側で禁止しています。

あらゆるオペレーションログや証跡ログもチェックしていますので、こちらに関しても出来る限りの対策は行っています。

また、セキュリティの都合上で詳しい仕組みは明かせないのですが、本番のデータベースとは違った別のデータベースを利用して演算を行っています。これによって実際のサービスに負荷がかかったり壊したりすることはないので、安全に利用することが出来ます。

ーーなるほど。それを聞いて安心しました。

BadIntentionの結果画面

見た目もわかりやすく数字が理解しやすい

プロダクト開発の思想

ーー新しいツールを生み出す際に特にこだわっている部分があれば教えてください。

D このツールに限ったことではないですけど、便利過ぎないように作ること。あとはそれに付随するかも知れないですけど、使い手に媚び過ぎないこと。この二点は自分の中で徹底しています。

ツールが便利過ぎるとそれこそツールに使われるだけになってしまって、発想の余白がなくなってしまいます。シーンによっては便利さが絶対的に正しい場合もあるでしょうけども、自分がクリエイターとして一番楽しみにしているのは発想による化学変化です。ゴールまでの脱線にこそ、ベンチャーの爆発力が秘められているんじゃないかと思います。

また、便利過ぎるとメンバーの学習の機会を大きく奪ってしまうことになるかも知れない。出来そうで出来ない「もどかしさ」こそがAIには表現出来ない面白味なんじゃないかと思っています。

ーーなるほど。便利さが絶対的に正しいように思いがちですけどそういうわけではないのですね。

2つ目の「ユーザに媚び過ぎない」は自分が最高と思うものを最高の状態で提供したいからです。「自分が欲しいから作った」ものって意外と人にも伝わって。逆に、「言われた通りに作った」「流行っているから作った」だと他人の心はなかなか動かなかったりします。

また、たくさんいただく意見に一つ一つ正面から応えていては、得てして芯のないプロダクトになってしまいがちです。システム的な不整合が生じたり論理破綻していたり。

そういう意味で自分が一番のヘビーユーザとなった時点で公開するようにしています。なんなら人と話してるよりもプログラム見てるほうが楽しいくらいですもん(笑)

「要塞」に囲まれて開発に勤しむD氏

「要塞」に囲まれて開発に勤しむD氏

ーーなるほど(笑) 実際に使っている事業部側からの声も届いているとお聞きしましたが?

D そうですね。たくさんの声をいただいているのですが、目から鱗がいっぱいありすぎて。

1枚目の鱗は「データビジネスの全体像を把握出来るようになった」という意見をいただきました。これは全く自分の頭にはなかったことだったので驚きでした。

それまでは事業部×エンジニアチームで企画についてブレーンストーミングしていてもどこか噛み合わないことが多かったんです。

今だからこそみんなネタばらししてくれていますけど、それまではデータの構成とか中身とか一切わかっていなかったらしくて。それでああだこうだ企画について語ったところで、それは浅薄と言っては失礼ですけど、明らかに会話のレイヤーが合っていなかったんです。

それが噛み合うようになってからは、間違いなくプロダクト要件の質が向上したと思います。

ーーなるほど。

D 2枚目の鱗としては「出来ることと出来ないことがわかるようになった」と聞きました。これも自分の発想には全くなかったことです。

・・・鱗ってこういう風な使い方で合ってます?

この区別って事業を進める上ですごく重要なスキルだと思うんです。だから今でもデータをわかっていない人の意見は譫言のように聞こえてしまうことがある、っていうのが最近の現場の共通認識になっています。

その結果として、ユーザやクライアントに対して、より真剣に向き合うことが出来るようになったようです。

ーーおお!それはマッチング事業を行う上で非常に大事なことですね!

D 最後の鱗は分析について。

スプレッドシートやExcelでは限界があって、それによって中途半端な分析のままで施策の考案や実施を行っていたようなんです。

それがBad Intentionの登場によって、数ギガ、数テラの情報をスムーズにストレスレスで扱えるようになって、深いレベルまで分析が出来るようになったことでPDCAの質が圧倒的に上がったと言っています。

いずれも開発者視点では全く気付かなかったことなので、ここに関してはとても勉強になりました。

ーーなるほど。思わぬ副次的な効果もたくさん得られているわけですね。現時点で課題はありますか?

D これだけ普及した背後には実は大きな課題も浮き彫りになって来ていて。

SQLのスキルってどうしても属人的になってしまうので、スキルの高い人だけが欲しい情報にたどり着けるといういわゆる「情報格差」が広がって来てしまっています。

属人化を少なくするために社内に普及させたはずなのに、結果的に属人化の問題が浮き彫りになって来てしまっていて、これはあまり健康な状態じゃないと思っています。

ただ、一方である意味それは正しい形だとも思っていて、定向進化じゃないですけどその格差を利用して上手く次のプロダクトに繋がりそうだなと、青写真を描いています。

ーー「次なるプロダクト」楽しみにしています!今日はお忙しいところありがとうございました!

D ありがとうございました!

--

画像9

今回ご紹介したBad Intentionを含め、各種バスティオンツールを「我社でも導入したい」という企業さまは、即導入が出来ます! 必要に応じてSQLの勉強会も開催しておりますので、気兼ねなくtwitter DMにお問い合わせください。

画像10

集中力を高めるために必須なハンドスピナーたち

この記事が気に入ったらサポートをしてみませんか?