はじめに

皆さん、こんにちは。SHIFT サービス改革部の森川です。

3月から開発チームのマネージメントポジションとなりました。

テスト管理ツールの"CAT"や、テスト設計を支援するツール"TD（TEST DESIGNER)"などの社内外問わず広範にご利用いただいているツールの開発部署で日々マネージメントに奔走しております。

管理職といえば、チームの皆さんが頑張った成果を数字にまとめて、上層部に素早く伝えるのが、一つの重要な責務ですよね。

報告は可視化と透明化が肝心、ということでBIツールを導入してみました。

やったこと

以下の3つの情報を、1つのBIツールに一元的にまとめてダッシュボードを作って可視化しました。

• 売上・商談情報のBI化

• 製品利用状況のBI化

• エンジニア生産力のBI化

まだ道半ばのものもありますが、形にはなってきているので、言語化＆公開してみることにします。

こういうのは完成を待ってたら、四半世紀を過ぎそうですし（笑）

売上・商談情報の課題は解像度とスピード

売上情報については、会社から週次で配布される売上情報資料を共有すればよいだけなのですが

部署として注力している数字を別出ししたり、売上区分を細かく分類する必要がありました。

これまでは手元で集計していましたが、遅い・伝わらない・毎回手作業の辛み三拍子。

そこで会社から配布される資料（Excel）をDWH（Data Ware House)に取りこむ、ワイルドなスクリプトを書いて運用することに。

また、商談情報については、CAT（弊社のテスト管理ツール）の課題管理機能を用いて運用していたので、ETLツールからAPI経由で吸い上げてDWHへ取り込みしています。（ここでCATとETLツールの連携ノウハウがたまりそうな予感がしますが、また別の回のお話で。）

売上・商談情報を週次・日時で取り込めるようになり、いつでも最新状態で見れるようになりました。

可視化だけでなく、チームが状況を理解するスピードが格段に上がったと思います。

たとえば、商談数がここ数日で伸びてきたな、と思ったらすぐに「商談の流入経路」のクロス集計を行い、どの経路で増えているかをプロットしてダッシュボードに載せる。これを受けて対するチームのネクスト・アクションがスムーズに決まった、なんてことが実際にありました。

製品利用状況の可視化で、提供価値を測りたい

製品のユーザ数やログイン数、顧客数やプロジェクト数は、定期的にインフラメンバにお願いして集計していました。

こちらも同様、辛み三拍子です。特にCATは歴史あるツールなので、全量では開発時や社内研修時など、大量の不要データが含まれます。これを除去するルール・クエリが、手作業だと毎回変わって精度が落ちる、なんてことも起こっていました。

定期的に製品DB（レプリカ）からDWHに抽出してもらい、BIツールで参照するようにしました。

データクレンジングのクエリは、まだブラッシュアップ中ですが、BIツールに封じ込めれば、いわゆる"方言ゆれ"はなくなると思ってます。

導入効果としては、数字をみるためのやり取りがなくなったこと。メンバーがそれぞれにダッシュボードを見て気づいたことを言ってくれることがある。というのがすでに良い兆候だと思っています。

今後は機能別の利用状況を出力して、リリースした機能の1次的なユーザ価値を測れるようにして、企画からリリースまでのスピード向上につなげていきたいところです。

モニタリングツールのAPM機能と連携してクロス集計するのも良いかもしれません。

エンジニアの生産力可視化

過去のエントリーでも書いていますが、エンジニアのコード更新量やプルリク数を出してみました。

SingerでGitLabのデータをサクッと抜いて可視化してみた｜SHIFT Group 技術ブログ

※ この後、JIRAのチケット消化数もBIツール上で見れるようにしています。

プロダクトの性格上、エンジニアの生産力が売上貢献にダイレクトに貢献するわけではないので、これだけでエンジニアの評価はできないですが、誰が何を担当して、どれぐらいの火力なのか、スタミナはどうなのか、下がっているのかをWATCHすることはできます。

個人的には、新しいプロダクト（フィーチャー）に入ったジュニアエンジニアのプルリク（MR)の指摘回数（コメント数）が減っていくのが、成長の過程を可視化しているように見えて、面白かったです。（後日、メンバーに訊くと確かにその傾向はあったようです。）

データは断面で採る

これらのBIのための情報はすべて断面で採っています。したがってクエリさえ組めば、期間の差分を自在に見ることができます。

私たちが知りたいことは「取り組みの成果」であることがほとんどですし、そのために妥当性の判断をするために、断面データは不可欠なのです。

この点についてはBIツール化（というよりはETLツールの役目ですね）には大きな意義があると感じました。

課題と所感

最後に思ったことと課題をつらつらと。

ヘイトが溜まらないように

続けていくには、頻繁に見てもらう必要があります。 そのためにはいつ更新されるのか、精査された数字なのか、品質の維持が大切です。 失敗するとBIヘイト＆EXCELロールバックが起こるのだと思います。
誤っているクエリ・数値は、できるだけ素早く修正してアナウンスするように心がけています。

クエリ屋さんを増やしたい

GUIでもクエリを書けるBIツールを採用してます。なので、誰でもクエリをサクッと書いてダッシュボードを刷新してもらうのが理想的です。ExcelでLookup関数と戦うよりも、SQLネイティブクエリを書けるようになる方が、キャリアとしてもプラスになりそうです。勉強会も計画中です。

わかりにくいスキーマをラップしたい

APIから直接吸い上げていることもあり、Extractしたデータの一部のスキーマがわかりにくい（汚い）という問題があります。いっそ直観的で美しいスキーマに変換するようラップして提供するのも一手かもしれません。

誰もがプロアクティブに動くために

当たり前ですが、BIツールによる可視化や透明化はそれ自体が目的ではありません。

透明化を通してKPIに対する意識を高めてもうらこと、そして誰もがプロアクティブに動けるようになることが最終ゴールだと、再認識しました。

いつかは、別の部署・立場の人たちが、同じBIの情報を見て化学反応を起こしたり、なんてことを想像するとワクワクしますね。

分析の旅はまだ始まったばかり

上記の3つのBIツールの情報を今後はクロス集計して、相関分析していけるようにしていきます。

また、売上と製品利用状況の相関が見えれば、未来予測、なども可能になるかもしれません。

チームのファイブフィンガーを採っていますので、エンジニアの生産力と、ファイブフィンガーデータから、製品品質やバグ予測、はたまた燃え尽き症候群を予測したり

なんてこともAIの力を借りればできるようになるかもしれません。

BIによる効率化は、道半ばどころかまだ始まったばかりですね。

参考： ファイブフィンガーで測るチームの健康｜dora_e_m

おまけ

システム構成

エントリーの趣旨が異なるので、詳細は割愛させていただきます。

システム構成としては、BIツールにはMetabase、DWHにはpostgres serverを、AWS EC2上にDocker with nginxで立てました。バックアップは日時でS3へ放り込んでいます。
詳しく知りたし、という方がおられましたら、コメント等いただければ可能な範囲でお答えします。

お問合せはお気軽に

SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/

SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/

SHIFTの導入事例
https://service.shiftinc.jp/case/

お役立ち資料はこちら
https://service.shiftinc.jp/resources/

SHIFTの採用情報はこちら

PHOTO：UnsplashのHannah Busing