この記事はdoda Developer Group Advent Calendar 2024 の18日目の記事です。
自己紹介
こんにちは！カスタマープロダクト本部プロダクト開発統括部グロース開発部で doda サイト開発のチームリーダーをしている川又です。
dodaサイト開発にアジャイル開発が導入されて数年が経ちましたが、最近ソフトウェア業界で開発生産性やDevOpsというワードをよく耳にするようになりました。
しかし、自分たちの開発環境に落とし込むと具体的に何を指して何をすべきなのかがいまいちピンときませんでした。
この記事では、私自身が直近学んだ点、今まさに取り組んでいるアクションをベースに開発生産性とは何か、開発生産性を上げるとはどういうことなのか、を自分なりの言葉でアウトプットしようと思います。
開発生産性とDevOps
まずこの2つのワードを噛み砕いて理解する必要がありますが、前提の定義を踏まえて私なりの言葉で説明します。
開発生産性
- 少ないリソースで高い価値を届ける力
- アウトプット/アウトカムが最大化され高いパフォーマンスを維持している状態
これらを実現させるためには以下の手法が考えられます。
-
- アジャイル開発の導入
- 自動化ツールの導入
- FourKeysによるチームの定量値の可視化
- 組織全体の成熟度向上
DevOps
- 開発/運用を統合し迅速なフィードバックとビジネス進展を推進する仕組み
自身の組織のDevOpsを測定し改善するためには、DORA（DevOps Research and Assessments）が提唱するFourkeysと呼ばれる開発生産性を計測するフレームワークを用いる。
-
- リードタイム（開発→本番反映の開発時間）
- デプロイ頻度（リリース頻度）
- 変更障害率（障害発生率）
- サービス復元時間（障害復旧までの時間）
改善活動に向けて
DevOpsに則ってFourkeysとやらを改善していけばいいんだな！
よし、やるぞ！！
…
……
………
何をすればいいの？？？？
言葉だけ覚えてもいざ実務で取り組もうとすると何をどうすればよいか分かりません。
他社のWebアプリ開発現場の記事や周辺チームのメンバーと会話して分かったことは、どうやらまずやるべきは「チームの現在値を定量的に可視化すること」のようです。
ここで登場するのがVSM（バリューストリームマッピング）です。
開発生産性に馴染みのある方はこちらの図を見たことがあるかもしれません。
VSMは一言で表現すると
価値を顧客に届けるまでの業務プロセス全体を可視化し、価値が提供される過程とボトルネックを特定するための手法
です。私たちdodaサイト開発組織に当てはめると次のように言い換えられるかもしれません。
ディレクターが起案し、部で承認された施策をチームで設計・開発し本番リリースされるまでにかかった時間と各プロセスのボトルネックを集計、特定するための手法
こう書いてみると顧客への価値提供までにめちゃくちゃ開発プロセスがあるな…文章から伝わってきますね。
VSMを作ってみた
チームのエンジニア、ディレクターの協力もあり2週間ほどかけてVSMを完成させました。改めて開発プロセスの多さを実感するとともに、それぞれのリードタイムが可視化されることで議論をする前から各プロセスのボトルネックが早くも見えてきました。
基本的にリードタイムは以下のように算出します。
LT(Lead Time)= PT(Process Time) + WT(Wasting Time)
LT：PTとWTの合計
PT：実際に作業した時間
WT：待ち時間
ここでは実際にレトロスペクティブで議論したボトルネックと改善アクションについてお話します。
①レビューに時間がかかる
まずはどの現場でもありがちな課題。LTもそうですが、WTがかなり大きかったためレビューイの待ち時間が発生していることが分かりました。
課題を具体的にすると「施策の規模が大きいためひとつひとつのPRの単位が大きくレビューに時間がかかる」になります。
そこで出た改善アクションは、各エンジニアの毎日の成果物を日次で共有しよう、というものです。
デイリースクラム後、エンジニアが毎日1時間開発の困りごと相談をする時間を設けていますが、その場で昨日作った設計書やクラス図、メソッドなど、どんな成果物でも全員に共有する運用にしました。
チームでは並行で複数の施策が動いているため、他メンバーが開発している施策のキャッチアップは非常にカロリーを消費します。（特にコードレビューは施策の要件はもちろん、背景のビジネス観点も把握する必要がある）
その負荷を下げるため毎日全施策との接点を持つことで、結果的にPRのレビュー時間、強いて言えば要件を把握する非生産時間の削減を実現しました。
（ちなみにPBIを”価値が計れる最小単位にする”もアクションとして考えられますが、ここは今まさにチームで取り組んでいます）
②テスト仕様書作成に時間がかかる
このケースはPTが大きくWTはそこまで気にならないと、いったLTでした。
一見仕方ないように見えますが、dodaサイト開発ではチームによって日常的に触れる（改修する）画面がわりと決まっています。
私たちのチームは応募画面、Web履歴書画面によく触れますが、テストケースも似通ったものが多いです。となればFMTを作ればいいじゃないか！ということでテンプレの仕様書を作成しました。
リードタイム削減！done！
③要件定義が精緻化されておらず開発の手戻りが多い
これはWebアプリ開発×アジャイル開発としてある程度仕方ないものの、要因の深掘りは不可欠だなと感じました。
結論から話すと、エンジニアをより前工程でアサインし、技術面でソリューション提案しながらIF設計を行う落としどころとなりました。
これは各プロセスのLTが長いことによるボトルネック分析ではなく、VSMを俯瞰して見たときに全体的に開発工数が大きくないか？という会話から生まれましたが、
1スプリントごとに調査・設計のサイクルを回して都度要件をブラッシュアップしていく、よりアジャイルな開発プロセスに寄せることができました。
ここまでボトルネック分析から発見し実際に改善Tryを行った3点を紹介しましたが、VSMはインセプションデッキのように1回作るだけでは真価を発揮しません。作成から少し時間も経ちチームメンバーも変わったため、2回目のVSM作成とボトルネック分析会を実施予定です。
話を戻すと、これでFourkeysのリードタイムにフォーカスして開発工程全体のリードタイムを可視化→ボトルネック改善を実施することができました。
VSM作成までの道のりや課題など、詳しくは以下の資料をご覧いただければと思います。
バグのシフトレフト
次に見る観点として考えたのはテストで発生したバグのシフトレフト（一言で言うとバグ検出を開発の前工程で行うこと）です。
先ほどVSMのボトルネック分析でも挙がった手戻りの発生は、要件の擦り合わせだけでなく各テスト工程で発生するバグ数に依存すると感じました。
そこで各施策の各工程のバグを月次で集計し、月ごとにモニタリングすることにしました。
実際に例を出してみます。
9月：工程が進むごとにバグ数が増えている
【考察】開発の手戻りが多くリードタイムがかかっていると予想
10月：各工程でバグ数がほぼ同数
【考察】IT/STとUATバグ数が同等なのでテスト設計に課題がある
11月：前工程でのバグ検出が多い
【考察】テスト設計の段階で多くのバグが検出できている
このようにテスト設計～本番リリースまでの工程で発生したバグ数を計上し月次で比較してみるとチームのバグ傾向、いわゆる健康状態が見えてきます。
バグ数を0にすることは難しいですが、可能な限り前工程（テスト設計）で検出して開発の手戻り、リードタイムを削減する取り組みを継続的に行うことでシフトレフトを実現できると考えています。
月次でチームのシフトレフト傾向を定点観測することで先ほどのVSMとは違ったボトルネックが見えてきますし、定量値を月次比較ができるためKPTによる振り返りがしやすくなります。
結局開発生産性を上げるには？
ということでここまでの話をまとめます。
私が思う開発生産性を上げるポイントは
- VSMを用いたボトルネック分析
- シフトレフトによるリードタイムの削減
- Four Keys指標の定期的なモニタリング
この3点だと考えます。もう少しストーリーを持たせるとこのような表現でしょうか。
VSMで開発フローのボトルネックを特定し、バグのシフトレフトで品質管理を早期に行うことでリードタイムを削減。Four Keys指標をモニタリングと改善策の導入で継続的なプロセス改善を行う
これが 開発生産性を上げる ことだと考えます。
分析してもリードタイムが削減できていないはダメ
リードタイム削減できているけど定点観測でモニタリング比較できていないもダメ
この3軸を踏まえてた継続的なプロセス改善活動を行うことが大事ですね。
今後は他社の取り組みなど視野を広げて吸収、改善活動を行い、プロダクトの成長に寄与していきたいと思っています。
ここまで読んでいただきありがとうございました！
川又 颯 Hayate Kawamata
プロダクト開発統括部 グロース開発部 dodaサイト開発2グループ リードエンジニア
2019年3月にパーソルキャリアへ中途入社しマイページ領域のPMに従事。その後エンジニアへの転籍を経て継続開発のチームリーダーを担う。
※2024年12月現在の情報です。
