リリースはいつになりそう？開発スケジュールを見立てるコツ
こんにちは！カミナシPMのかもしー (@96kemu96) です！
これはプロダクトマネージャー Advent Calendar 2022 🎄の21日目の記事です！
今回はプロダクト開発におけるスケジュールの握り方と、達成するために工夫していることについて書きます。
途中、試行錯誤の道のりをつらつらと書いてしまったので、ポイントだけ知りたい方は最後の方まで飛んでください！✈
📍誰のためのnote？
・開発見積もりがブレてしまう
・スピード感のある開発をしたい
・ビジネスチームにスケジュールをどう伝えたら良いか悩んでいる
明確なリリース期限を決めたくないプロダクトチームと、決めてほしいビジネスチーム
新機能を開発するぞ！と決めたときから、「いつリリースですか？」「いつから顧客に案内して良いんですか？」とセールスやCSから聞かれますよね。
「◯月です！もう顧客に案内してよいですよ！😎キリッ」と言えればいいんですが、それだとアジャイル開発の良さがなくなるし、なにより事実として実装や要件の不確実性が高いので約束が難しいです。
実際、ビジネスチームとプロダクトチームの間に立つ身として、双方の主張をまとめるとこんな感じです。
ビジネスチームとしては、リリース期限を決めてほしい
ですよね、わかります。
もし早めに決まれば、顧客の掘り起こしできるし、今対応している新規顧客を受注できるかもしれないし、売上予算達成のための武器になる。
受注やアップセルはリードタイムもあるので、できれば事前に決めてもらえると予算が立てられますよね。
しかしプロダクトチームとしては、明確なリリース期限をできれば決めたくない
はい。これもわかります。
なぜなら決めてしまうと、不確実なことが起きたとき「時間」を守ることを優先せざるを得ないので、「品質」や「スコープ」が落ちる可能性が出てくるからです。
それは短期的には良いかもしれないですが、負債の種をつくるかもしれないというトレードオフがあります。
妥当なスケジュールを引くための道のり
ということで、今回の新機能のリリースでは、妥当なスケジュールを引くために頭を抱えました🤒
最後に結論を書いているので、サクッと知りたい方はここから飛ばしてください！
以下、時系列でまとめます。
試行錯誤1
（開発前）機能ベースでエンジニア複数人にストーリーポイントを見積もってもらった
まず開発する前に、必要な人員リソースや期間を把握したくて見積もりました。
具体的にはスプレッドシートに機能一覧をつくり、エンジニア複数人で話し合いながら見積もりました。
ここでいう機能の粒度感は、◯◯が保存できる、◯◯を取り込める、というように挙動が想像できる、そこそこ細かめのレベルです。
見積もったストーリーポイントにバッファをしっかり1.5倍も入れて、営業日換算で出しました。
結果
しかし開発が始まって1ヶ月ほどスプリントを回して見直したところ、実際と見積もりでなんと約4倍のズレがありました。Wow。
理由としては、以下がありそうでした。
・不確実なものは13や21ポイントになってしまい、意外と大粒な機能があった
・既存機能に乗せる新機能だったので、いろんな調査が必要だった
・プロダクトのフェーズとして、今回からちゃんと設計をやることになった
試行錯誤2
（開発初期）↑で見積もったものをベースに、ずれた分の倍数を掛けた
開発して1ヶ月が経った頃、予実が4倍ほど違っていることを受けて、悲観的に考えると経営やビジネスチームに早期に連携をする必要がありそうだと思い、見直しをしました。
やったことは、予実のズレを補正するためにズレ補正倍数を算出して掛けること。
今思えばずれた見積もりに、さらに倍数かけてどうするんだ・・・！と思うのですが、エンジニアとして正確に見積もるのは難しいと言われるし、非常に時間がかかるので、さくっと1時間程度で補正しようとして係数を算出しました。
具体的には、妥当そうな1チケットをサンプルとして取り出し、そのチケットが開発前の見積もりと実際でどれくらいずれたのかを算出。それをもとに悲観ライン、現実ライン、楽観ラインの係数を出しました。
・悲観ライン（実装スピードに正の影響がでなかった場合）：5倍
・現実ライン（2-3割の実装スピード改善が出る場合）：4倍
・楽観ライン（開発スピード改善＋ドメイン知識や既存実装の理解が深まることで、最終的に今の半分のスピードで前に進めるようになった場合）：2.5倍
結果
改めて全体に補正係数をかけたうえで実績を比較してみたら、結構違いました😅 たしか10倍くらい。よりズレたのですぐ違う方法を模索し始めましたw
だめだった理由としては、チケットにはいくつか種類があることを考慮できていなかったから。
たとえば、設計が必要かどうか、フロントの挙動だけか、API実装も必要なのか、負債解消施策との調整する必要があるか、などにチケットによって見積もりはかなり違いますよね。
（番外編）エンジニアにぶっちゃけ肌感どう？って聞いてみたら
ここまで来て、画面ラフやデータの構造案はエンジニアにすでに伝えてあるし、なんか経験をもとにした肌感、予想は立てられるんじゃないかな〜と思いました。
なので複数のエンジニアを急にhuddleで呼び出して、「ぶっちゃけ聞きたいんですけど！どれくらいで行けそうな感じがしますか？」と聞いてみました。笑
しかし、たまたまカミナシのプロダクトのソースコードに手を入れるのが初めてのメンバーが多かったこともあったのか、人によって結構違いました。
そのうえで、自信ないです・・・！って自信なさそうな感じで言われました。
ということで、肌感聞く作戦は30分くらいで無理だとわかりました。笑
試行錯誤4
（開発初期〜中期）スコープを区切り、段階的×チケット枚数でざっくり見積もってみた
開発初期はベロシティが安定しなかったのですが、徐々に安定してきたことでこの見積もりができるようになりました。
（その裏にはリファインメントの見直しや、スクラムマスターの強化などがあります・・・！）
結論からいうと、このやり方が最も良さそうでした！
最初から正確に出そうとせず段階的に精度を上げていく考え方をベースに、機能ごと×チケット枚数程度のざっくり感で見積もっています。
見積もりの粒度感については、ストーリーポイントで見積もるといろんな不確実性を含む大きな数字がつきがちなので、1チケット＝1日以内で終わる粒度で見積もっているのですが、今のところ良い感じです。
【結論】妥当な見積もりの出し方
いろいろな先人がすでに記事にも書いていることをなぞりますが、最初から妥当に見積もるのは無理そうなので諦めて、段階的詳細化をしていくのが良さそうでした。
段階的詳細化とは、プロジェクトマネジメント協会（PMI）が発行しているPMBOKで解説されているプロジェクトの特性の１つで、得られる情報が増え、より正確な見積りが可能になるにつれて、プロジェクトマネジメント計画書が詳細化していく性質を表しています。
つまり、プロジェクトというのは初期段階では詳細まで把握することはできず、時間の経過とともに詳細が明らかになっていくことを示しています。
自分の経験を踏まえて噛み砕くと、見積もりには3つの不確実要素があるので、それが徐々に明らかになると精度が上がるんだなーと思います。
💡見積もりに必要な3つの不確実性
・要件の明確化（なにをつくるのか）
・機能ごとのチケット枚数の予測（どうやったらつくれるのか）
・ベロシティの予測（どれくらいの量できるのか）
【番外編その1】スケジュール遅れないためには
というわけで、見積もりを色々試してみて私は気づきました。
正確に見積もることよりも、「◯月までにリリースしてやろうぜ！！」という適度なストレッチスケジュールとモメンタムが大事なんじゃないかと！
たとえば3日で終わるタスクだとしても、設計や調査に時間をかければ5日かけることもできるし、逆にレビューの出し方とか進め方を工夫すれば2.8日で終わらせることもできます。
"達成したい期日"があるからこそ、今の実装のあり方や要件、開発リソース配分に疑問を持ち「どうにか工夫して、品質と時間を守らなきゃ！🦸🏼♂️」となるんじゃないかなと。
そうするとクリエイティビティが発揮されて工夫がうまれ、開発速度が上がるんじゃないかなと！
また、難易度の高いスケジュールにコミットするには、エンジニアから自主的にオプションを提案してもらいたい。そのためには、エンジニア全員が、スケジュールの当事者意識を持てる仕組みが必要だと思っています。
ここが足りなかったと気付いたので、絶賛強化中です。🔥
具体的には、こんなことをしています。
・開発メンバーと一緒にロードマップを更新
・朝会で都度スケジュールの話をする
・スクラムマスター含む開発メンバーと相談して、毎スプリントストレッチしていこうという目線合わせする
【番外編その2】ビジネスとのコミュニケーションのコツ
「リリース期限を決めてほしいビジネスチーム」とのコミュニケーションで工夫していることを最後に。
正確な見積もりが難しい理由をちゃんと説明する
話せばわかる。ちゃんと自ら説明しにいくことで信頼を築ける
定期的にスケジュールのupdateを説明する
特にセールスは受注までのリードタイムがあるので、機会損失を生まないように定期的に状況をupdateする
個別の顧客に「これを◯月までに作ります」というコミットを握らない
どうしてもなんとしてでも握りたい場合は、どんな事があっても行けるだろうというレベルの期日を握る
ニーズがあれば、本リリース前後で必要なコミュニケーションについて、また別のnoteで書くかもしれません✍
最後に
長くなりましたが、最後までお読みいただきましてありがとうございました！
もし、参考になった！わかる〜！と思った方は、スキ♡してくださるととても嬉しいです😊
参考
書いた後に見つけたのですが、言いたいことまさにこれでした！
この記事ほうがわかりやすいので是非！🙌
最後に…カミナシは全方位的に募集しています🔈
カミナシのPM組織はまだ立ち上がったばかりです。ほぼ0→1です！一緒に3,900万人の仕事を楽しくしませんか？
求人一覧はこちら
カミナシPMのEntrance Bookはこちら
カジュアルに話したい！という方は、Twitter DMなどでも気軽にお声かけください🕊
この記事が気に入ったらサポートをしてみませんか？