1.4 オーバーラップさせる部分のモニタリング事例
では、概念はわかったので、これらをどのようにモニタリングしていくべきかについて紹介します。
全体像は下図の通りです。各レイヤーに対して、どういった形でモニタリング基盤を用意してレポーティングを作っていくかを示します。
1.4.1 開発組織の生産性モニタリング
わかりやすい部分から行くと、開発組織の生産性は基本GitHubといったホスティングサービスに集約されていることが多いです。そのデータをスクリプトを書いてモニタリングしても良いですし、最近ではファインディ株式会社が提供している「Findy Team+」や、海外製品だと「Code Climate」などがあります。
GitHubのチーム単位、リポジトリ単位などさまざまなセグメントでの分析が可能です。基本的なプルリクエストの作成数やマージまでにかかった時間、Four Keysの数値といった分析が可能であり、生産性の可視化を考えるとこの1つの製品で十分なモニタリングができます。
また、複数チームが組織に存在する場合にはすべてをここに集約することで組織がサイロ化せずに中央集権型に他のチームとの比較ができるため、組織全体のボトムアップやコミュニケーションの促進につながります。
1.4.2 工数 × 金額 × 資産のモニタリング
開発組織以上のレイヤーについては、あらゆるデータを「BigQuery」を代表とするデータウェアハウスに投入しています。
例えば、工数のデータは端的に言えば 「今日8時間働いたが、どのプロジェクトに何時間使ったか」 です。どこの会社でも資産計上の目的でプロジェクトコードのようなものがあると思いますが、それを勤怠管理ツールと紐づけて入力してもらいます。つまり、人事的なデータと財務・経理的なデータを適切な権限を付与しながら紐づけています。
そのデータを、一旦BPM（Business Process Management）システムに入れてから、月次でBigQueryにデータ投入してもらいレポートを作成します。
これらのプロセスをトラッキングするときに、1点注意すべきことがあります。このプロセスの肝はメンバーが勤怠管理ツールからのインプットです。
あまり細かく入力するべきプロジェクトコードを分けすぎても各々の入力作業が大変になり、管理コストが上がります。そのため、初めは傾向値が分かる程度にすることが大事です。さらに、Googleカレンダーと勤怠管理ツールを連携することで、カレンダーに予定があれば自動でそこにプロジェクトコードが紐づく仕組みなども導入しています。
すると、以下の形のレポートが作れるようになります。
良い点としては、BigQueryでSQLライクにデータ抽出ができることで自由度が高くなることです。本部単位で見たり、チーム単位でみたり、特定のプロジェクトコードベースで見たりすることができます。また、工数にかかった金額についても実給与から引っ張ってくることで、より予算との紐づけが可能です。
このレポートから、開発生産性の健全性を以下の観点から見ていきます。
- プロジェクト完了状況 + 予測スケジュールとの予実 : 終了予定日（予測スケジュール）と終了日のズレを認識して、コストマネジメントを最適化する
- 開発業務割合の遷移 : 開発業務割合（クリエイティブな作業の割合）を高めて、クリエイティブな活動にかける時間を増やす
- ミーティングやその他、クリエイティブな作業以外に大きな時間を割いていないか
これらの取り組みで、各レイヤーの開発生産性に関する言語の変換を行っています。
1.5 採用するか、開発生産性を上げるか
本記事の最後に強い開発組織を作る上での採用戦略との関係性を考えてみます。
ソフトウェア開発を行う開発チームを強くするためには、しばしば 「強いエンジニア」の採用に帰結されます。各社、どれだけ採用費をつぎ込むかに注目を浴びがちになります。
実際、技術力が高く問題解決能力に優れたエンジニアは、多くの問題を克服しプロジェクト・プロダクトを成功に導く原動力となります。単に技術的な課題を解決するだけでなく、チーム全体の能力向上にも寄与し、時間とともに同じチームにいるメンバーにポジティブな影響を与え、全員のパフォーマンスを向上させることができます。このようなエンジニアが一人いるだけで、開発プロジェクトの成功確率は大きく高まります。
強いエンジニアと一緒に働くのはエンジニアにとって大きな福利厚生とも言えるでしょう。つまり、これほど技術投資としての費用対効果良いものはありませんが、この理想的な状況に至るまでには、多くの壁が存在します。採用の難化です。
当然、優れたエンジニアは各社がほしいわけで、魅力的な開発現場やプロダクト、企業文化が必要になり、報酬も釣り上がっていきます。これらの要素を用意できる企業は稀であり、自分の胸に手を当ててみても圧倒的に他社に勝てる部分があるかは難しい判断です。また、リモートワークの普及に伴い、国内エンジニアの海外流出や社内育成の難しさなど、新たな課題が生まれています。
では、どうするべきかを考えていくと、採用強化はしながらも、今いるエンジニア組織の価値最大化を考えるべきでしょう。出発視点を意識すると、現在のエンジニア組織の開発力の「現在地点」を理解することが重要です。つまり「開発生産性」に焦点を当てます。
組織が直面している現実を正確に把握し、今後の方向性を定めるための第一歩です。開発生産性の評価は、単に開発レイヤーだけでなく、組織全体の戦略的な意思決定にも役立つべきです。これにより、どんな人的資産をどのように活用すれば、組織全体としての生産性を最大化できるかの洞察が得られます。
強いエンジニアの採用は、確かに開発チームにとって大きな利点です。しかし、それだけでは不十分とも言えます。組織全体としての生産性向上には、開発のソフトウェアライフサイクルだけではなく、適切なプロジェクト管理、効果的な組織内コミュニケーション、戦略的な人材管理、継続的な技術投資、そして継続的な学習と改善の文化の醸成が不可欠です。現代の変化する市場環境と技術の進歩に迅速に対応するためには、組織全体で柔軟かつアンラーニングな思考が求められます。これらの要素が組み合わさることで、真に強い開発組織が形成され、開発生産性の向上が実現します。
まずはここまで、読んでいただきありがとうございます。次回以降は、それぞれの組織レイヤーに関する、より詳しいメトリクスの考え方について紹介します。
