開発生産性向上の鍵：高速で成果を生み出すためのプロセス改善 - 開発生産性 Advent Calendar 2024 14日目
これは 開発生産性 Advent Calendar 2024 14日目の記事です。
開発生産性について
開発生産性という概念の私なりの説明文
単純に「開発生産性」を主語として他者と対話すると、前提やスコープが揃っておらず話がズレてしまう可能性が高いです。
そのため「開発生産性とは複数の要素が混ざったふんわりしたもの」程度に考えてもらうために私が開発生産性という概念を一言で説明するなら、
” 組織やチームが解決したい問題を解決するために、活動のプロセスを改善し、効率的かつ効果的に成果を上げるための要素の総称 ”
としています。
開発生産性の歴史は 食べログ 開発者ブログ 萩野さまの 開発生産性の現在地を開発生産性の歴史と開発生産性Conference2024から振り返る (10 31, 2024) がとてもわかりやすくまとまっておりました。
開発生産性を向上させたい背景(理由)
自分自身やメンバーが「開発生産性を向上させたいな」と感じたとき、その環境や状況では以下の観点において何かしら問題があると感じているのではないかと考えています。
効率が悪い
品質が悪い
持続可能性がない
コミュニケーションの課題
顧客満足度が低い
他にも理由はあると思います。開発生産性を上げたい理由によって対応策が異なる場合が多いので、なぜ開発生産性を向上させたいのかを明確にすることが第一歩だと思います。
開発生産性向上の目標：成果(アウトカム)とは
成果を生み出すための流れ
開発チームの効率化やプロダクトの品質向上（開発生産性の向上）の目標は、
” 高速で成果（アウトカム）を生み出し続けること”
にあると考えています。
本文中の成果（アウトカム）の定義は、「活動やプロジェクトの結果や成果物として得られる最終的な成果や効果」とし、インパクトまでを生み出す一連の流れを示すものとしてロジックモデルが提唱されております。
図1. ロジックモデル
マーク・J・エプスタイン (著), クリスティ・ユーザス (著), 鵜尾雅隆 (監修), 鴨崎貴泰 (監修), 松本裕 (翻訳), 社会的インパクトとは何か――社会変革のための投資・評価・事業戦略ガイド (10,14 2015)
成果を生み出すためのプロセス
投入資材（インプット）と活動（アクティビティ）によって結果（アウトプット）を生み出し、その結果をターゲットに当てた効果が成果（アウトカム）です。成果によって、社会の変化や外部への広がりがインパクトとして表れます。
しかしながら、成果（アウトカム）を狙って生み出すのは難しいです。不確実な現代において、何が成功するのか分からないですし、少し前までうまくいっていたものが急に効果を失うこともよくあります。
成果はコントロールしにくいものです。そのため、私はインプット、アクティビティ、アウトプットの量と質を増やすことが正攻法だと考えています。このプロセスを高速に回すことで、アウトカム(成果)が生まれる可能性が高くなります。
注意： アウトカムを最大化させる方法はソフトウェア改善だけではないことを認識する
一点注意すべきは、アウトカムを生み出す方法がソフトウェア開発以外にも存在するかもしれないという点です。
もしソフトウェアを作らずに問題を解決できる方法があるならば、（後から業務負荷など別の問題が発生する可能性はありますが）素早く対応できる可能性が高いです。開発しなければ運用コストもかかりません。
したがって、開発以外の解決策も視野に入れて検討する必要があります。
成果を生み出すための改善プロセスの進め方
1．解決したい問題の状況を把握する
問題の状態を分類するためのフレームワークの一つに、クネビンフレームワークがあります。
David J. Snowden and Mary E. Boone A Leader’s Framework for Decision Making (11, 2007)
mtx2s’s blog mtx2sさまの クネビンフレームワークとソフトウェアエンジニアリング で詳細に説明されているので、ここでは割愛しますが、問題の状態や種類によって、アウトプットの量を向上させるべきか、質を向上させるべきかが変わってきます。
Chaotic（カオス）：何が起きているかはわかるけど把握できない問題に取り組む場合、実効性のありそうな一次対応を実施することが求められます。この場合、開発生産性を考えるよりも問題を発生させない暫定対応を行います。
Complex（複雑）：複数の問題が絡んでいることはわかるけど、どんな因果関係があるかわからない問題であれば、失敗しても影響が小さい実験を繰り返し、成功パターンを見つけることが重要です。アウトプットの量を改善することが効果的です。
Complicated（煩雑）：因果関係がわかっている問題であれば、しっかり分析して適切な解決策を導き出します。より最適な解決策を見つけるために、アウトプットの質を向上させる必要があります。
Simple（単純）：原因と結果の因果関係が誰の目にも明らかな問題です。この場合、プロダクト開発で解決できることもあれば、そもそも開発しなくても解決できることもあります。ベストプラクティスも明確であり、対応策を判断して実行します。
2. アウトカムを精緻に分析できるようにプロダクトの質を意識する
問題の分類が終わり、プロダクト開発によってアウトカムを検証するとなりましたが、本質的でない要素（プロダクトの不具合など）が検証結果に影響するようでは成果を生み出すための開発生産性向上以前の課題です。そのため、検証可能なプロダクトを提供するためには必要な品質を作り込み、保証します。
独立行政法人情報処理推進機構 つながる世界のソフトウェア品質ガイド あたらしい価値提供のための品質モデル活用のすすめ (5 29,2015)
3. プロダクト開発プロセスを明確にして、プロダクト改善の量と質を改善する
上記は、普段私が意識している開発プロセスの基本形です。順番にプロセスを実施し、各アウトプットに対してそれぞれ検証を行います。
非常に細かく定義しているように見えますが、特別なことはしていません。チケットには「なぜやるのか？」と「どうやってやるのか？」を記載し、右に行くほど具体的に記載していきます。
実装が完了したものに関しては、単体テスト→結合テスト→システムテスト→受入テストの順に評価を行い、すべてクリアすることでリリース可能（アウトカム検証可能）なアウトプットの品質を担保します。
このプロセスの各項目の時間を、品質を担保したまま短縮することで量を増やし、各項目の進め方を改善することで質を向上させていきます。
まずは開発プロセスの全体像を可視化し、それを意識しながら対応することが重要です。一通りプロセスを実行してみて、もしプロセス自体に課題があると分かった場合は、項目のやり方やプロセス自体も更新していきます。
4. Four Keys メトリクスは、アウトカムを検証するためのアウトプットの品質を保証する指標だと考えてます。
開発生産性を測定する指標の一つに「Four Keys」があります。
Google Cloud Japan Team さまの 記事 エリート DevOps チームであることを Four Keys プロジェクトで確認する (9 23, 2020) の記事を参照しました。
プロダクトの品質特性の一つである保守性は、理解容易性、変更容易性、テスト容易性で構成されています。これらは「Four Keys」のデプロイ頻度、変更リードタイム、変更失敗率、サービス復元時間を計測することで現状を把握できます。そして、これらの数値が良いチームは、ハイパフォーマンスなチームである可能性が非常に高いとされています。
Boehm, Brown, and Lipow's 23 Quality Characteristics (1976)
Takuto Wada 質とスピード（2022春版、質疑応答用資料付き (5 9,2022)
「Four Keys」を計測することは、高品質なプロダクトを生み出すハイパフォーマンスなチームであるかを評価するための有益な指標です。しかし、アウトカムを検討する際には、Four Keys だけでは不十分です。例えば、BtoBサービスやモバイルアプリでは、過度な本番リリースが顧客に悪影響を与える可能性があります（急に使い方が変わってわからなくなるなど）。そのため、注意が必要です。
まとめ
本文章では、開発生産性を「組織やチームが解決したい問題を解決するために、活動のプロセスを改善し、効率的かつ効果的に成果を上げるための要素の総称」と説明し、開発生産性向上の目標は、「高速で成果（アウトカム）を生み出し続けること」としました。
アウトカムを生み出すための開発生産性を向上させるためには、顧客の要求や課題の取得を含めた一連の開発プロセスを可視化し、意識して実行し、常に振り返って必要であればプロセスごとに改善していくことが重要だと考えています。
開発生産性は非常に重要な概念であり、私の改善策も一例に過ぎません。状況によって改善プロセスや取るべき指標は異なるでしょう。
様々な事例を共有し、IT業界全体で学び合うのに非常に良いテーマだと考えています。ぜひ、悩みや事例をどこかでお話させていただきたいです。
最後までお読みいただきありがとうございました！