はじめに
はじめまして。しくみ製作所の野田雄大と申します。はじめてPM的なポジションでお仕事させていただく機会をいただき、暗中模索しつつ表題の開発生産性について取り組んだ奮闘記を今回は執筆させていただきました。
何に取り組んだか？
表題の通り「開発生産性」です。
クライアントから私の参画しているプロジェクトの「開発生産性がイマイチ」という評価をいただいていたことがきっかけです。
開発生産性は通常、「インプットあたりのアウトプットの量」をもって定量的に計測される指標です。しかし、私の参画するプロジェクトでは何をインプットとして何をアウトプットとするかなどは定められておらずクライアントの言っている「開発生産性」が何を指しているのか誰もわからない状態からスタートしました。
開発生産性とは何を指しているのか？をクライアントにヒアリングすることを試みましたが、担当者レベルで定義がバラバラであり「これを改善すれば良い！」というものが中々掴めないでいました。そこで、簡単に収集できる数値から仮説を立てて、仮説ベースでアクションを起こしていくという方向で取り組んでみました。
まず、開発生産性とは一般的に何を指すのか？というところから入りました。『エンジニア組織を強くする 開発生産性の教科書』（佐藤将高 著） の中で以下のように開発生産性には三つのレベルがあるという内容を目にしました。
引用: https://gamma.app/docs/-necbojc9wcdk8yw?mode=doc
プロジェクトに照らして、仕事量生産性の問題・期待付加価値の生産性の問題の二つの側面でそれぞれ問題が無いかを検討してみようと考え、以下のように検証と仮説の立案、アクションの策定を進めていきました。
仕事量生産性の問題
私の参画しているプロジェクトはマイクロサービスアーキテクチャを採用しており、複数のベンダが複数のシステムを開発しているという状況でした。
そこで、各システムごとのソースコードの量など開発のアウトプットに着目してみました。
すると、我々のチームのアウトプット量は他システムと比べて多いことがわかりました。
アウトプットの量に問題が無さそうというところで、もう少し上の工程で問題がある可能性が出てきました。
そこで、FourKeys(DORAメトリクス)を元に開発生産性を検証してみることにしてみました。
すると、デプロイ頻度とリードタイムに問題があることが判明しました。(図の赤線が平均値。左に行くほどスコアは悪い)
これを踏まえて、開発のスピードには問題ない一方で、開発した機能がなかなか本番環境に適応されないため投資対効果が低いと感じられてしまっているのではないか？という仮説が出てきました。
そこで、デプロイ頻度が改善されればリードタイムも自然と改善されるということで、デプロイ頻度を改善することをアクションとして設定しました。
- FourKeys(DORA指標)とは？
- GoogleのDORA(DevOps Research and Assessment)チームが提唱したソフトウェアの開発、デリバリー、保守の有効性を測定するために利用できるパフォーマンス指標のフレームワーク 参考: https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance?hl=en
期待付加価値の生産性の問題
過去にいくつかクライアントから指摘をいただいていた事項から仮説を立てました。詳細はここには書けないため割愛させていただきますが、ざっくりいうと、我々のアウトプットのクオリティとクライアントの期待値がズレていたり、開発する機能の優先順位付けやリソースの分配がうまくいっていないというところに原因がありそうでした。
結果として、そういった認識の齟齬や期待値の調整などがうまくできておらず、過剰・不足が各所で発生しているのではないかという仮説が浮かび上がってきました。
そこで、誰が・いつまでに・何を・どうやるか明確にしていくというアクションを設定しました。
どう取り組んだか？
デプロイ頻度の改善
元々のデプロイの頻度を（手動で）計測したところ、2~3ヶ月に一回程度の頻度で本番環境へのリリースが行われていました。
当時の開発の状況を見てみると、開発 → 試験環境へリリース → 検証・不具合修正 + その他細かい対応 → STG環境へリリース → 受け入れ試験 → 本番環境へリリース と開発が直列で行われていました。
- イメージ図
リリースフローなどはシンプルで運用は楽だったのですが、これだとその他の細かい対応がスタックしてしまったり、次の開発が今の開発のPRDリリースまで開始されないなどリリースサイクルが大きくなる要因がありました。
そこで、開発を複数レーンに分散して並行させて、開発のリソースを最適化を図っていきました。
- イメージ図
その結果として、デプロイの頻度は2~3ヶ月に一回から1ヶ月に一回程度実施できるように改善されました。
誰が・いつまでに・何を・どうやるかを明確にしていく
ここではチーム内での取り組みとクライアント向けの取り組みの2軸で改善を図りました。
- チーム向けの取り組み
- 週に一回の定例を実施するようにしました。
- 仕様の一元化
チームとしてはスクラム開発を採用しているため、日々のDailyScrumと月に一回のふりかえり(レトロスペクティブ)を実施していました。しかしそれでは、チーム全体で共有すべきこと・改善すべきこと・確認すべきことの取りこぼしが発生してしまうということもあり、週に一回の定例でカバーするようにしました。
開発の仕様などが散在しており、実装の際に認識違いや漏れが発生していたため、仕様をGitHub Wikiなどに取りまとめるようにしました。
- クライアント向けの取り組み
- スケジュールや作業進捗の見える化
- 手順書の作成
当時、リリースフローやスケジュールが全体を通して見える図のようなものがない状態でした。全体感が見えないため、チームメンバーもクライアントもどんなタスクが控えていて、何をいつまでにどのタイミングでやるべきかという認識が曖昧なまま議論が進んでいました。その結果として、上述のような認識の齟齬が発生してしまっていたと考えられます。そこで、リリースフロー、プロダクトバックログ、スプリントバックログをなどを図式化して、全体感が直感的に把握できるようにしました。
テスト・リリースなどをいつ・誰が・どこまでの責任で実施するのかが特に明示されないまま進んでいました。その結果として、直前に認識が違っていたことが発覚し調整が必要になったり、実施後にクライアントから質問をいただくなどの事例が発生していました。
そこで、リリース手順書・テスト計画書などを作成し、誰が・いつまでに・何をするかの齟齬を生まないようにしていきました。
その結果として、数ヶ月間に渡ってこの運用を続けていますが現状認識の齟齬による大きな問題は今の所発生していない状態になっています。
今後やっていきたいこと
- 生産性の定義をプロジェクトとして明確にしたい
- 今回はほぼ仮説ベースで色々とアクションしていたが、本来なら何をアウトプットとして、何をインプットとするかを明らかにしないといけないので、そこを明確にするところからやっていきたい。
- リリースフローを2~3週間に1回くらいに改善したい
- 仮説ベースでのアクションだったが、デプロイ頻度・リードタイムのパフォーマンスが低いことはわかっているので、ここは継続的に改善したい。
- リリースの頻度は改善されたが、開発している機能の粒度は変わっていないので、機能の粒度を細かくして改善を試みる。
- 定量的な数値を元に分析・意思決定していけるようにしたい
- 今回のアクションでの結果プロジェクトの雰囲気としては良くなっているような実感はあるのですが、一方で、定量的に評価することができないので仮説の検証やらなんやらができていないです。なので、指標の策定とデータの収集を進めて、改善の施策を合理的に考えられるような環境を作りたい。
さいごに
今回は仮説ベースで色々考えて色々やってみるというふんわりした内容になってしまっていますが、私の場合、PM専任という形ではなく、開発もしながら上述のような取り組みも並行して行っていたので、教科書通り、最初に指標を定めてデータを収集して、評価・分析して...なんてやってられなかったという背景があります。しかし、これはPM専任だろうとなかろうと同じことなんじゃないかなと思います。
個人的には、「開発生産性」が明確に定義されていないプロジェクトにおいて、仮説→アクション→検証・分析という流れが良いのではと感じています。検証・分析の結果、効果が定量的に示せたら、自然と他のチームなどにも波及していき、結果的に開発生産性への意識が高まっていくのではないかなと思うからです。
そういった意識の波及の先駆けとなれるように、引き続き取り組んでいきたいと思います。