michtekuの開発生産性を2年分振り返る
こんにちは。michitekuの鈴木(@suzuki-0000)です。
こちらの記事では、開発生産性について書きたいと思います。
開発生産性について、カジュアル面談で「計測していますか？」など質問をいただくことがあります。
そこで今回は、2022年にmichitekuが設立されてから、いかにして開発生産性を計測・改善してきたかを紹介します。
michitekuの開発の一端を、知ってもらう機会になれば幸いです。
はじめに
開発生産性を語る上で、michitekuという会社の開発組織の変遷・特徴を紹介します。
開発組織の変遷
2022年9月、開発2名（外部パートナー）と新規構築開始。
2023年5月、プロダクト（β）をローンチ。
2023年6月、正社員エンジニア1名ジョイン。
2023年12月、正社員エンジニア1名ジョイン。
2024年2月、正社員エンジニア1名ジョイン。
2024年4月時点で、エンジニアは3名。外部パートナー（フルコミットでないメンバー含）を含めると6名前後
となっています。
開発組織の特徴
michitekuのプロダクト開発の特徴として
PSF・PMFフェーズで企画変更が多い時期である
ヘルスケア（がん領域）を中心するドメイン知識が必要である
インターン（海外エンジニア）と一緒に仕事をしている期間が存在する
フルリモート環境である
といった特徴があげられます。
（海外エンジニア？それが気になる、と思った形は以下を参考にしてください）
「Four Keys」を検討した2022年
2022年、プロダクト新規構築を行う上で、開発生産性の指標をどうするか？そこでまず検討したのが
「Four Keys」
でした。
Four Keysは、開発生産性を継続的に改善し、同時にビジネスの成果を向上させる上で有用と考えられています。しかし、導入検討時に問題になったのは、Four Keysを「簡単に計測する手法」が存在していなかったことです。Four Keysの可視化・継続的な取得を行うには、自分達で一部自作をする必要性がありました。
新規構築フェーズにおいて「生産性を可視化・改善すること目的に、生産性を浪費する」というジレンマがありました。時期尚早と判断し、Four Keysの採用を見送りました。
開発生産性として「Velocity」を導入
michitekuでは「Scrum開発」を導入しました。そこで当面の間「Velocity」を生産性指標としました。
スクラム開発における「Velocity」は、チームが一定期間内にどれだけの作業を完了したか（できるか）を測る指標です。
Velocity2年分を公開
そこで、振り返りの意味を込めて、約2年弱のVelocityを公開したいと思います。
イテレーションは原則2週間に1度（大型連休などで例外あり）
メンバーは2人〜5人程度でばらつきがある（平均は3人程度）
となっています。
2022年秋〜(立ち上げ期)
右肩で少しずつ上っていく様子が伺えます。
「新規エンジニアによる構築（人員の入れ替えが少ない）」
「新規構築のため、コード負債が少ない」
という特徴が出たグラフだと思います。
2023年春〜（1stリリース完了、海外インターン受入実施）
Velocityが右肩で下がっていく時期です。
なぜ、このようなことが起きたのでしょうか。
理由は大きく1つ、それはチームの再編に伴う調整コストと考えています。
外部パートナー（SIer）入れ替わりが発生
海外インターンの受け入れ・教育
の２点が、上記のタームに発生しました。
特に、海外インターン受け入れは、大きなコスト（投資）になったかなと考
えています。
エンジニアチーム再編による調整コスト（投資含め）は、プロダクト成長を代償に支払う可能性がとても高いです。しかし、そのコストは、エンジニア以外からは測量がとても難しいものだと思います。
自分たちのチームの特徴（michitekuでいえば、PMFフェーズであること、医療ドメインであること、フルリモートなど）を理解した責任者が、チームの再編に伴うコストを正しく測量し、ステークホルダーに向けて説明責任を負う。
当たり前のことかもしれませんが、今回のVelocityの結果を持って、あらためて実感するフェーズとなりました。
2023年秋〜（停滞期）
このフェーズでは、海外インターンが終了したことで、開発生産性が少しずつ持ち直していきます。しかし、立ち上げ期ほどのスピード感が出ていないフェーズが続きました。
なぜなのか？
深堀りした結果「コードレビューに時間を要しているんじゃないか」ということが見えてきました。しかし、そのような事実が見えても、コードレビューに時間を要している根本的な原因がわかりません。
あらためて「Four Keys」を導入
そこで、Four Keysの導入に踏み切りました。
Four Keysを導入する上で検討を実施し、「Findy Team+」を導入することにしました。
Findy Team+を導入すると、Four Keysを短時間で可視化・継続観測することが可能です。このFour Keysの中には、
変更リードタイム（Lead Time for Changes）：コードの変更がコミットされてから本番環境にデプロイされるまでの時間
が含まれています。
さらに、この数字には
「コミットからオープンまでの平均時間」
「オープンからレビューまでの平均時間」
「レビューからアプルーブまでの平均時間」
「アプルーブからマージまでの平均時間」
と分割して数字を可視化してくれます。これらの数字を深堀りすることで、どのPRで、誰が、なぜ時間を要しているのかを理解することが容易になり、改善サイクルが回しやすくなります。
加えて、michitekuでは、リリース後に検知すべき
「変更失敗率」
「サービス復元時間」
も可視化が出来ていませんでした（これまでは、簡単なポストモーテム、記録程度でした）。こちらも、いずれ課題になると考えていました。
Findy Team+では、上記指標をまとめて可視化することができます。
結果：コードレビューから、アプルーブまでの平均時間が４倍近くに
Findy Team+にて、変更リードタイムを可視化した結果です。
「赤いグラフ」に注目してください。
これは「コードレビューから、アプルーブまでの平均時間」です。少しずつ山が大きくなり、最大で、初期チームメンバーに比べて4倍近くの時間（２０H→８０H）がかかっていることが可視化されました。
メンバーと議論し内容を深堀りした結果、
仕様が不明確なままコーディングに入っている。その結果、コードレビュー時に、細かな仕様確認が始まっている
新しいメンバーが、PR時にPRのスコープを超えて議論し始めている（＝これまでのコード・アーキテクチャに疑問（負債）を感じている）
などが見えてきました。
可視化・継続的に取得された数字（ファクト）を元に議論できると、建設的に会話が進みやすいと感じています。
結果、チーム体制を変更するなどの抜本的な再編と、足元で実行可能な細かな改善の両軸を少しずつ進めて、解消に向かっています。
このような取り組みの結果、今年の1、2月の開発生産性は、人数は減っているにもかかわらず、生産性は向上しています。（「人月の神話」を証明する形になりました）。
現在のところ、Four Keys導入は、費用対効果の面で効果が高かったと感じています。
他にもmichitekuでは、開発生産性に関わる部分で
CIによるBuild確認、自動Unit/E2Eテスト（成功/失敗通知をSlackで）
Code CoverageはCIによって自動観測、足りていない場合は警告
循環的複雑度（Cyclomatic complexity）は静的コード解析ツールを用いて警告
Linter, Formatterをpre-commitに導入し、レビュー効率化
pr-agentを用いたAI提案によるレビュー効率化
などの改善を完了しています。
これからも「人が、コーディングすべきところに集中できる開発環境」を整えていき、高い生産性を目指していきます。
おわりに
いかがだったでしょうか。
ところで、michitekuは大阪万博 大阪ヘルスケアパビリオンへの出展企業に選出されました。
あらためて、プロダクトを成長させる機会を迎えています。
開発生産性をしっかり上げながら、困っているがん患者さんとその周りの方たちに、良いプロダクトを届けられたらと思っています。
いつでもカジュアル面談を実施していますので、よかったらこちらを参考に、ご検討いただければと思います。
どうぞよろしくお願いします。