Road to ワクワク駆動見積もり

この記事は KDDIアジャイル開発センター（KAG）Acvent Calendar 2024の23日目の記事（1/2）です。

1/2とは？

1月2日ではなく、弊社のアドカレがなぜか2つあるということです。
アドカレ書きたい人多すぎ問題の平和的解決策です。（いいぞもっとやれ）

バラエティに富んだ記事が満載で、普段あまり接点がないメンバーのすごい魅力がたくさん詰め込まれていて私自身の勉強になっています。このアドカレsはすごい、KAGすごい！
ぜひ皆さんもチェックしてみてください。

さて

本題となりますが、皆さん、見積もりって、苦手じゃないですか？

見積もりに感じる課題提起

スクラムを実践しているとなんとなく遭遇して、半分腹落ちしてないんだけど、プランニングポーカーでそれっぽく収束しているからやっている（やらされている）・・・
実はそういう現場、多い気がしています。
結果的に「見積もり」の目的は概ね果たされていることも多いので、大きな問題にもならない。

けどもうちょっと攻めてほしい！

チームが自分たちのペースを把握するためにベロシティは使いましょう、
みたいなお話はだいぶ広まっていると思うのですが、
前倒しで仕事が終わる可能性って絶対あると思いますし、
私が一番チームで実現していきたいなぁと思う世界は
「このタイミングでこれをリリースしたらぜったいみんなが喜ぶ！」
みたいな会話が起こる状態です。

どうやったら起こる？

チームを組成して、プロダクトの知識も乏しい中ではなかなか起こりません。
書いているとどんどん長くなりそうなので、２つの観点に絞ってAIに聞いてみました。

そもそも見積もりに自信がない

見積もりに自信が持てない理由はさまざまです。技術的な不確実性、過去の失敗経験、チーム内での基準の不一致などが主な要因として挙げられます。また、新しい分野や未知の技術を扱う場合、どの程度のリソースが必要か予測が困難になることもよくあります。
この課題を克服するためには、次のようなアプローチが有効です：

• 小さく分割する
  • 大きなタスクを細分化し、それぞれの要素に集中することで、全体像をより正確に捉えることができます。
• データを活用する
  • 過去の類似プロジェクトから得られたデータを活用することで、見積もりに根拠を持たせることができます。
• 心理的安全性を確保する
  • チームが自由に意見を出せる環境を整え、見積もりに対するプレッシャーを軽減することで、より現実的な見積もりが可能になります。

自分たちのワクワクを市場とリンクさせていく

不安を取り除いて自信と実績を積み重ねた上で、チームが心からワクワクするアイデアや機能を市場のニーズと結びつけることが重要です。これにより、プロジェクトは単なる業務ではなく、チームの情熱と価値が込められたものとなります。一方で、ワクワクだけでは市場価値を生むことは難しく、現実的なニーズやトレンドと適合させる必要があります。
これを実現するためには、以下のポイントが鍵となります：

• 顧客フィードバックの収集
  • 顧客やユーザーからの直接的なフィードバックを受け取る仕組みを作り、チームのアイデアが市場でどう受け止められるかを確認します。
• 共感を軸にした価値観の共有
  • チームの情熱が顧客のニーズとリンクするポイントを明確化し、その共感をプロダクトに反映させます。
• スプリントレビューでの検証
  • 開発の各段階で市場ニーズに基づいた評価を行い、チームの情熱が市場価値に繋がるよう調整します。

このプロセスを通じて、チームが心から取り組みたいと思えるプロジェクトを市場価値の高い成果物へと昇華させることが可能になります。

だいぶそれっぽいことが返ってきたぞ

It dependsな現場それぞれのお話もあると思うのですが、
AIがちゃんと返してくれるということは、世界中で近しい議論がされているのだと推測できます。

私が見積もりで一番大事だと思っているのは、
見積もりの正確性や計画通りにリリースできることではありません。

タイムリーに自分たちで自信を持って完成させることに向き合える

例えば「これは1ヶ月でできる」「3ヶ月かかりそう」みたいな見積もりを言えるかどうかで、チームの練度は全然異なってきます。

• 時間で見積もらないってどういうことだ・・・
• ポイントって人によって違うじゃん・・・

こんな声はどんな現場からも聞こえてきたことがあると思いますが、
これって、そもそも個人の見解だけで正確な見積もりをしようとしている兆候なんですよね。
そんな状態でも、
1ヶ月や3ヶ月の単位の見積もりができる人とできない人がいたり、
できるチームとできないチームがいたりする最も大きな原因は、
「そもそもそれを作ったことがないから」に尽きると私は思っています。

この状態で見積もりに時間を投資することは無駄です。（浪費でしかない。）

まずはチームで小さく作ってみましょう。プランニングポーカーなんてやらなくてもいいです。1日とかでできそうな活動をやってみて、何が起こるか、結果的に終わったかどうかを、みんなで経験してみてください。
1週間とか1ヶ月とか経っていることにはだんだん先が見通せるようになっているし、できればスクラムというフレームワークに乗っかってチームで活動してみてください。
きっとチームのパフォーマンスは想像をはるかに超えてくることでしょう。
そうしたら、1ヶ月程度の活動は見通しがつきやすくなっていますし、当初の計画よりもたくさんの活動が行われるようになっていきます。
スクラムマスターがそれをリードしてください。

おわりに

アドカレはあと二日残っていますが
ちょうど今日、入稿が完了して書影が公開されました！
年明けに発売となります、皆さんチェックしてみてください！
https://gihyo.jp/book/2025/978-4-297-14669-6

ご参考

AIが出力してくれた見積もりトピックがとっても有用なので掲載しておきます。
ポチごとに解説したいけど、今日は割愛。

アジャイル開発における見積もりの重要性

見積もりの目的

計画の立案

• チームがプロダクトバックログの項目を処理するための時間や労力を把握する
• リリース計画やスプリント計画を現実的に設定するための基盤となる

ステークホルダーへの透明性を提供

• プロジェクトの進捗状況やリリース予定時期を関係者に説明する
• ステークホルダーの期待値を管理することで信頼関係を築く

チーム内の理解と合意

• チーム全体が作業のスコープや課題を共通認識として持つ
• 見積もりプロセスが協力的な問題解決の場となる

見積もりを阻む課題とその対策

1. チームメンバー間での認識のズレ

• 課題
  • 作業のスコープや複雑さについてメンバー間で理解が一致していない。
    経験の違いから見積もりの基準がバラバラになりやすい。
• 対処方法
  • 明確な基準を共有: ストーリーポイントの定義やタスクの例を明示して、基準をチームで揃える。
  • 共通認識の場を設ける: プランニングポーカーなど、チームで議論しながら見積もる手法を活用する。
  • 不確実性の許容: 不確実性が高い場合、その旨を明記し、リスクを反映した見積もりにする。

1. 作業の不確実性が高い場合の見積もりの困難さ

• 課題
  • 技術的な難易度や依存関係が多い場合、正確な見積もりが難しい。
  • 新しい技術や未経験のドメインに関するタスクでは見積もりに偏りが出る。
• 対処方法
  • スパイクタスクを設定: 調査目的の短期間のタスクを設定し、不確実性を軽減してから再見積もりを行う。
  • 小さく分割する: タスクを可能な限り小さく分け、1つ1つの複雑さを把握しやすくする。
  • 範囲で見積もる: 見積もりを「最悪の場合～最良の場合」の範囲で表現する。

1. プレッシャーによる過少または過大な見積もり

• 課題
  • ステークホルダーや上層部からの圧力で、現実的ではない見積もりを提示してしまう。
  • チームメンバーが心理的安全性を感じられず、楽観的または悲観的な見積もりに偏る。
• 対処方法
  • 心理的安全性を確保: チーム内で自由に意見を言える環境を作る。リーダーが「正直な見積もりが重要」と強調する。
  • データに基づく交渉: 過去の実績データを示して、ステークホルダーに現実的な期待値を伝える。
  • 緩衝を設ける: 見積もりに一定の余裕を持たせ、プレッシャーによる影響を軽減する。

1. 経験やスキルのばらつき

• 課題
  • チーム内で経験値やスキルセットが異なるため、見積もりにばらつきが出る。
    新人メンバーが見積もりに参加しづらくなる場合がある。
• 対処方法
  • チーム全体で合意形成を図る: 個人ではなくチーム全体で「納得できる」見積もりを重視する。
  • ペアリングやメンタリング: 新人メンバーが経験豊富なメンバーと協力して見積もりに参加できる環境を整える。
  • 定期的な振り返り: 見積もり精度を振り返り、改善点を共有する。

1. 見積もりの結果を「約束」と捉えられる

• 課題
  • ステークホルダーやマネージャーが、見積もりを絶対的な納期の約束と解釈する。
  • アジャイルの「変化に対応する」という特性と相反する状況になる。
• 対処方法
  • 見積もりの意図を明確化: 「見積もりは計画の指針であり、確定的な約束ではない」ことを伝える。
  • 進捗の定期的な共有: スプリントレビューやデモで進捗を可視化し、ステークホルダーと対話する。
  • リスク管理を組み込む: 不確実性を考慮した計画と、調整可能なスケジュールを提案する。

1. 過去の見積もりの教訓が活かされない

• 課題
  • 過去の見積もりが精度に欠けていたにもかかわらず、そのフィードバックが次の見積もりに反映されない。
• 対処方法
  • 定期的な振り返り（レトロスペクティブ）: 見積もりの精度やプロセスを振り返り、学びを次回に活かす。
  • 履歴を記録する: 過去のストーリーポイントやタスクの実績を記録し、見積もりの参考にする。
  • 改善サイクルを導入: PDCA（計画・実行・確認・改善）サイクルを回して見積もりプロセスを進化させる。