はじめに
こんにちは。PharmaXでエンジニアリングマネージャーをしている古家(@enzerubank)です。
本記事では、開発タスクの予実の乖離についての課題を整理し、対応策についてまとめています。
課題意識
弊社ではスクラムで開発を行っており、スプリントプランニングの時点で今回のスプリントで使える時間を計算し、各メンバーのキャパシティを可視化するようにしています。
そしてユーザーストーリーを各タスクに分解後、実時間でタスクを見積もり、キャパシティに収まるかどうかを確認し、オーバーコミットにならないようにしてからスプリントを開始しています。
ただそれでも、スプリントが終わってみるとタスクが予定通りに終わらないことが何度かありました。
予定通り終わらないこと自体が悪なのか？
スプリントの見積もりと実績に乖離があり、予定どおりに終わらなかったこと自体は自分は悪ではないと考えています。今までやったことのないような難易度の高いタスクをやろうとすればするほど、予定と乖離が起こることはよくあることだと思います。
これを許容しないなら絶対にできるタスクしかやれないことになるので成長もありません。
ただ問題は乖離があることに対して、ふりかえりを行い、次の改善のアクションをとろうとする習慣がないことです。せっかく上手くいかなかったのなら、それを学びに昇華して改善していかなければ、チームでスクラムをやっている意味がありません。
また開発の見積もりと実績に乖離がある状態が長く続くということは当然、開発のロードマップは遅れるということになります。そうなれば開発コストがかかるだけでバリューを出していないと受け止められてしまい、開発チームへの信頼も下がっていってしまいます。
そうなれば開発チームの発言力は下がり、開発がやりたいことをやる権利も無くなっていき、仕事がつまらなくなるという負のループに入っていく恐れもあります。
予定通りに終わらない場合に考えられる原因と対応策は？
原因として考えられる要因と各対応策を上記にまとめてみました。対応策は以下の4つになります。
- 使っている時間をツールなどで計測する
- 見積もりの予実の乖離を可視化して、毎回のスプリントで乖離を減らすことを目指す
- タスクばらしのスキルや開発の進め方をペアプロや勉強会で教える時間を取る
- 理想の開発確保時間を定義してその時間を確保できるようにMTG類は断捨離する
使っている時間をツールなどで計測する
これは実績時間を手動で記入する方法とツールで今やっているタスクを記録する方法の大きく2つの方法をとることになると思います。
前者は作業終了時や終業時にAsanaやJIRA等のタスク管理ツールに実績時間を入れてもらいます。
ジュニアのメンバーが多かったりフルリモートで作業をしているようなチームの場合は使っている時間をすべて計測する後者のアプローチをとる場合もあると思います。
使ったことはないですが、TimeCrowdのイメージが近いです。自分も前職では似たような海外ツールで時間計測をしてオフショア開発チームのマネジメントに使っていました。
見積もりの予実の乖離を可視化して、毎回のスプリントで乖離を減らすことを目指す
タスクの実績時間の計測ができたら次は予定時間と実績時間の比較を行えるような分析画面を用意します。これはスプレッドシートで可視化してもいいですし、ツール上で分析機能があるならば、それを使ってもいいですね。
タスクばらしのスキルや開発の進め方をペアプロや勉強会で教える時間を取る
見積もりが実績と合っていない場合に考えられる原因は以下3つです。
- タスクばらしのスキルが未熟
- 事業ドメインやコードベースの知識不足
- 開発言語/FWの開発スキルが未熟
本来は自分自身で勉強して足りないスキルを埋めて乖離を減らしていって欲しいですが、
教育を担当できるエンジニアがいる状況であれば、ペアプロや勉強会で細かいところまでサポートできるのが理想ではあります。
理想の開発確保時間を定義してその時間を確保できるようにMTG類は断捨離する
そもそもまとまった開発時間が確保できているのか？を確認することも大切です。
プログラミングは隙間でコツコツやるのは向いてなく、4時間はまとまった時間をとれるのが理想です。
そういったカレンダーになっているのかを定期的に確認すると良いでしょう。
その上でスプリント内で理想的な開発時間を確保している人をモデルケースにその人の時間に皆が近づくように改善していきます。
FAQを追記（2024.10.08)
記事を出してからいくつか質問をもらったのでFAQを追加しました。
見積もりが正確になることにどんなプロダクトの価値があるのか
A. 予定していたスプリントタスクが終わらない → スプリントゴールが完了できない → プロダクトロードマップが後ろにずれこむ → プロダクトの検証のスピードも遅くなり、事業目標の達成にも影響が出るという関係で考えている。結果的に事業サイドと開発サイドの信頼感が損なわれる
予定どおりに終わらなかったことが悪ではないと言いつつ、努力によって予実を乖離しないところを目指すのかはなぜか
A. 終わらないことは最悪事実として仕方ないのでふりかえりして次に活かすという前提はあるものの、やはりゴールを確約（コミットメント）はしているので、終わらせるために全力を尽くす必要はあって予実の乖離を減らしていくための努力は必要だと考えている（完璧に無くすことができるとは思ってない) 不確実性を小さく分けて確実性を上げるためにスクラムをやっているので、終わらないということが繰り返されるのはよくない兆候かなと。
確実性というのは、「納期通りに終わる」ということなのか
A. 確実性は「何を作ったら良いのか」「どう作ったら良いのか」の2つがわかっている状態だと考えている。この2つが最初はわからない(不確実性が高い)状態で、スクラムを通して段階的に作るものも作り方もわかってきて、不確実性が減ってくる。ただ新しい学びを得てピボットしたり、今までやったことのない開発が始まることはありえるので、そしたらまた不確実性は高まるが、また上記2つの確実性を上げていく活動に戻ることを繰り返す。確実性が上がってくると「何をどう作ったらいいのか」の解像度が高まるので、結果的に納期通りに終わる可能性は上がるという関係。
さいごに
いかがだったでしょうか？これらの対応策を着実にやっていけば良い変化が起きてくるかと思います。
弊社もまだ取り組んでいる最中なので、明白な成果が出てきたらまた記事にまとめる予定です。
開発の見積もりの乖離に悩んでいるエンジニア・EMの方の参考に少しでもなれば幸いです。
PharmaXエンジニアチームのテックブログです。エンジニアメンバーが、PharmaXの事業を通じて得た技術的な知見や、チームマネジメントについての知見を共有します。 PharmaXエンジニアチームやメンバーの雰囲気が分かるような記事は、note（note.com/pharmax）もご覧ください。
Discussion