こんにちは。出口です。
mofmofでは開発生産性を改善する取り組みを2023年7月にスタートさせ、これまで数社の受託開発案件で導入を行ってきました。
改善の取り組みを通じて、デプロイ頻度、リードタイムが見える化され、さらに改善が進んだプロジェクトについては、アジャイルの文脈でいうところのベロシティが向上しています。
受託開発においても、開発生産性を改善することで一定の成果があることが分かったため、これまで社内の数人で行っていた改善活動を全社に展開することにしました。
この記事では、実際にやったこと、やってみて分かったこと、感想、ふりかえりの結果を共有したいと思います。
やったこと
まずはやったことです。
開発生産性改善やっていく宣言
全社に開発生産性とは何か、開発生産性改善の取り組みについて共有しました。
その時に伝えた内容は要約すると以下の通りです。
- 開発生産性とは「少ないリソースで、より多くの価値を提供していくこと」
- 開発生産性の計測はFour Keysを使う
- Four Keysを計測して、分析会・ふりかえりを行い、改善していく
- 実践の場に「金曜日のチーム開発（金チー）」を利用する
ちなみにFour Keysの計測結果を表示するダッシュボードとして、dora-team/fourkeysをカスタマイズしたものを使っています。
月1回のふりかえり
各チームごとに月1回ペースで分析会・ふりかえりを実施しました。
ふりかえりの中で気になるところはヒヤリングして状況確認など行ったり、アドバイスを行ったりしました。
具体例を1つ挙げると。
「リードタイムが長い」という問題に対して深堀りをして、「レビュー待ちの状態が長く続いている」ことが分かったので、「レビューが来たら優先で確認しましょう」とアドバイスをしました。
アドバイスの結果、かなりリードタイムが短くなりました。
その頃ちょうど同じようにレビューを最優先にすると開発生産性に良い影響があるんじゃないかという記事がバズっていました。
参考になると思います。
わかったこと
やってみて分かったことです。
金チーが12月末で終わり、その後チームでふりかえりを行っています。その時に出てきたものを一部抜粋します。
一番重要なのは「意識」すること
前述のアドバイスをしたチームから、分析会・ふりかえりを行ったことでチーム内でリードタイム、デプロイ頻度をかなり意識するようになったと話がありました。
意識することでリードタイムが短くなり、開発がスムーズに回ったようです。
ですが、日々の忙しさ、眼の前のことを1つずつこなしていくことに精いっぱいになるとどうしても「意識」できなくなります。
ですので仕組み化する必要があるように思いました。
KEEP
リードタイムを短くすることで開発がスムーズに進むことが体感できた
全員ではないのが悔やまれますが、開発がスムーズに進むのは体感してもらえたようで、その点は良かったなと思います。
PROBLEM
リードタイムを短くすると開発が楽しいを体感してもらえなかった
開発がスムーズに進む→開発が楽しい→どんどん進む→サービスが出来上がるサイクルが早くなる。
という体験をもっとしてもらえるようにしたかったのですが、今回の企画ではそこまで体感してもらえなかったのが非常に残念ですし、申し訳ない気持ちです。
Four Keysの計測・分析をチーム内で行うのはまだ難しい
金チー自体をモリモリにしてしまった為、Four Keysの計測・分析を自分たちでやるところまではいけなかったです。
これは開発生産性改善というよりは金チーのPROBLEMではありますが、企画するときには気を付けないといけないポイントです。
TRY
「意識」する仕組みを作る
リードタイム・デプロイ頻度を意識するためにまずは定期的（2週間に1回、1か月に1回など）に分析会を行うのが良さそうです。
金チーでは1か月に1回ペースで実施していましたが、慣れるまでは2週間に1回もしくは1週間に1回で実施しても良いかもしれません。
チーム内でFour Keysの計測・分析を行えるようにする
今回はお試しということもあり、私と橘さんの2名で計測・分析を行いましたが、チーム内で行ってもらい、我々は第三者として参加し、アドバイスをするぐらいを最初に目標にすると良さそうです。
最終的にはチーム内で完結するようにしたいところです。
まとめ
みんなで開発生産性改善をやってみた結果、はじめに思い描いていたような浸透のさせ方は出来なかったですが、ある一定の成果はあったのかなと思います。
今後は、今回の反省を活かし、一旦個別に働きかける予定です。
慣れた人たちがある程度増えてきたら、また改めて全社に共有・展開していければと思っています。
もし何かの参考になれば幸いです。今後とも開発生産性改善やっていきたいと思います。
