以前の記事
3.1 アウトプット（出力量）を上げた後に、アウトカム（価値結果）を考える
まずは、アウトプット（出力量）とアウトカム（価値結果）の話です。ほとんどの開発チームが近年アジャイル開発を行っています。スクラムガイドの中でも、「価値」という言葉がよく出てきます。スクラムチームの中にはプロダクトオーナー（以下、PO）が存在して、バックログの優先度を決めることでどの順番でユーザーに価値を届けたらプロダクトが伸びるかを考えています。スクラムでなければPdM（プロダクトマネージャー）が担当する領域です。
「開発生産性を上げる vs 価値があるものを作る確率をあげる」という構造を考えると、開発チームはまず開発生産性を向上して開発力を上げ、アウトプット量を増やしてから価値やアウトカム（結果）を考えたほうが良いです。
責務の違いが多少なりとも関係していますが、エンジニアリングを主務としているメンバーが、ユーザーに届ける施策や機能のアウトカムの議論にコミットする、もしくは意識するのは非常に難易度が高いです。ビジネスの理解、ユーザーの理解、マーケティングの理解といったあらゆる領域の知識がないと経済合理性やユーザーファクトのバランスを考えながらプロダクトバックログの優先度をつけることは難しいです。
バックログの優先度を決めるのと同じで、開発組織を強くするのも優先度をつけなければいけません。ただ、頭の中の地図を作る上で意識と議論はしたほうがよいです。
つまり、最終的にどの施策・機能があたるかは難しい問題で、高速に10個の機能が作れるなら、POやPdMは"計画"に時間をかけずにどんどん改善を繰り返すことができるので、結果としてヒットするプロダクトが作れる可能性も高くなるかもしれません。そのためにイテレーションが存在しており、一定の期間で失敗とアンラーニングによる高速学習を繰り返すフレームワークになっています。
3.2 "数値"を高めると強い組織になるのか、強い組織の"状態"が数値を高めるのか
開発生産性を測る指標は色々とありますが、有名なのはDORAが提唱するデリバリーパフォーマンスを示す「Four Keys」でしょう。
| 指標 | 説明 |
|---|---|
| デプロイ頻度 | どれくらいの頻度でソフトウェアが本番環境にデプロイされるか |
| リードタイム | コードがコミットされてから本番環境にデプロイされるまでの時間 |
| 変更失敗率 | デプロイされた変更が故障や問題を引き起こす割合 |
| 平均復旧時間 | システムが障害やダウンタイムから復旧するのにかかる時間 |
これらの数値は、数多くの開発チームを分析しクラスタリングした上で、ハイパフォーマーの特徴として抽出されたものです。ここでの重要な問いとして、「Four Keysといった数値を高めたら、自分たちが目指す強い開発組織の状態になるのか？」というと答えは、NOです。
特に開発生産性の可視化は、管理や監視のために測定するのはアンチパターンで自分たちのケイパビリティー向上のために使わなければ、逆効果になるケースもあります。よくあるケースとしては、開発生産性の指標をハックして無理やり数値をよく見せる行為です。自分たちのために計測していれば極端にハックする意味がないことは明白ですが、開発生産性を存在価値のために数値を提供すると、ある事象が起きやすいので気をつけたいところです。
こういった事象を「グッドハートの法則」と言います。または「キャンベルの法則」という類似の法則もあります。どちらの法則も、組織や制度が数値向上を目的にすると多少なりとも圧がかかり、数字を作るためだけに行動することを意味します。
よく例として用いられるのが「コブラ効果」です。イギリス統治下のインドにおいてコブラの数を減らすために設けられた報酬制度で、コブラを捕まえたら報酬がもらえる制度です。当初は成功したように見えましたが、人々がその制度をハックし、報酬のためにコブラを飼い始めました。つまり、自給自足でコブラを買い捕まえて報酬を得ようとしました。
そのため、政府が報酬を廃止すると価値のなくなったコブラが野に放され、結果的にコブラの数は増加しました。目標や指標がもたらす予期せぬ結果の危険性としてよく出てくる逸話の1つです。
KGI（※経営目標達成指標）に強い開発組織の状態が目標としてあり、その因子（KPI）の1つとして、開発生産性のFour Keysといった数値があることを意識します。
状態が数値を作り、数値が状態を作るわけではありません。
本来、強い開発組織を作るのが目的で、その結果指標として開発生産性の数値があります。そのために「SPACE」といった開発フレームワークは、複数の指標（定量と定性）を選定し可視化する必要性を強く説いています。定量的なデータは「結果として何が起こったか」を示し、定性的なデータは「なぜ起こっているか」を教えてくれます。リソースの制限を意識しながら、きちんと一歩ずつ順番を考えて状態を作り上げていくしかありません。
3.3 変数の多さが複雑性を作っている
そもそも、開発組織が強くなるために必要な変数は果てしなく幅広く、ヒト（組織文化、設計スキル、採用のヘッドカウント...…）、モノ（システム、稼働率、技術負債..….）、カネ（技術投資、リファクタリング、ツール利用...…）の投資バランスが複雑に絡み合っています。
それらを定量と定性データをうまく組み合わせながら、正しい指標を組織ごとやフェーズごとに選択し改善を進めていかなければなりません。定量的なデータは「結果として何が起こったか」を示し、定性的なデータは「なぜ起こっているか」を声として抽出させてくれます。フェーズによっては、強いエンジニアの採用や、ジュニアなメンバーをミドルまで引き上げる育成などが優先度として最も高いかもしれません。
一方、本題の開発生産性の向上にどれだけのリソースをかけるかは組織ごとに議論が必要です。採用や育成戦略は開発チームとは別で進めるもの（マネージャーやEM）であるケースもあります。そのため開発チームの内部は、認知負荷をどう下げていくか（エコシステムの拡充、Platform Engineeringの導入）といったソフトウェアアーキテクチャを改善することで、開発生産性を向上させていくこともありますし、同時並行でFour Keysといった数値や定性的なデータは何を取るかを考えるべきかもしれません。
