見積もりはプロジェクトの進捗によって変わる
梶原氏はプロダクトオーナーを「プロダクトバックログの管理に責任を持つ一人の人間」と定義する。プロダクトバックログとは、その製品がユーザーに提供する価値と、その実現のために必要なタスクをリスト化したものだ。これをもとに開発チームが行うべき作業の価値を最適化し、プロダクトのROIを最大化する上で必要なタスクの優先順位を考えながら、リリースのための計画策定を行うのがプロダクトオーナーの責務である。
開発プロジェクトの基本となるのが、見積もりだ。一般的に見積もりは、プロジェクトの完了までを正確に見通すものでなくてはならないと考えられている。しかし梶原氏は「見積もりとは、現時点での情報に基づく予測にすぎない。それを確定のものとして扱えば、無理なスケジュールや余計な作業が発生するなど、むしろ弊害が大きい」と警告する。
プロジェクトが大規模なものであればあるほど、たとえ大きく全体を見積もったとしても、作業の進捗にしたがって、当初の見通しと実績との差は確実に大きくなっていく。下図は各フェイズ時点での見積もりと実績の差を示しているが、左端のプロジェクト開始時から、作業の進捗に比例して、ブレ幅が小さくなっていくのがわかる。最初は「ここまでやりたい」という要件がいくつもあるが、具体的な作業が進むにつれて要件が絞られてくるため、見積もりの精度もどんどん向上していくのだ。
「まず納期ありき」は、かえって品質に悪影響も
梶原氏は「大事なのは、見積もりはコミットメントではないということだ。ビジネスサイドの人と話していると、スケジュールと予算を見積もって、あとはその通りに進めることだけを求めがちだが、そんなコミュニケーションをしている限り、誰も幸せになれない」と語る。
見積もりを「コミットメント＝確約」と、とらえてしまう弊害は大きく2つある。1つは「納期最優先」になってしまうことだ。とにかく予定に間に合わせようといろいろな小細工をして、かえって進捗を遅らせてしまう。よくある失敗が追加人員の投入だ。人月数が減ることで数字上は間に合うように見えるが、中途で加わった開発者がプロジェクトの目的や自分の役割を理解するには一定の時間が必要で、スピードアップするよりもむしろチーム内のコミュニケーションコストを増大させるリスクのほうが大きい。
2つ目は、逆に過剰なバッファを取り、余裕のあり過ぎるスケジュールを引くケースだ。こちらもユーザー上の価値提供よりも納期に目が行ってしまうため、結局締め切りいっぱいまで時間を使ってしまい、開発スケジュールやコストが余計にかかるだけで終わってしまう。
「いたずらに納期に間に合わせようとすればデスマーチ化は必至で、開発者はつらく、肝心の顧客も品質の良いプロダクトが期待できない。反対に余裕がありすぎても、余裕はあればあるだけ使ってしまうので、時間をかける割にプロダクト品質は向上しない。いずれにしても『まず納期ありき』は、良いプロダクト開発の上でむしろ障害だと言える」
定期的な計画見直しが開発関係者の団結を促す
では、良いプロダクト開発計画とは何か。梶原氏は、ステークホルダーが信頼できる計画だと示唆する。
「大事なのは、常に正しい見通しを共有し、定期的に計画を更新し続けることができる体制だ。そう言うと『いったん決めたスケジュールを守らないのか』といった声も聞こえてくるだろうが、先ほど述べた通り、そこだけに固執するとかえってマイナスになる」
むしろ重要なのは、この先の見通しに対して常にトレードオフを提示し続けることだ。「この先を順調に進めるには、当初の見積もりに対してこの変更案が有効だ」といった指針を全員に示し、より的確な意思決定を支援できる力量が、プロダクトオーナーには求められている。
ここで有効なのは、定期的な計画の見直しである。絶えず「計画＝見通し」は変化していくので、最新の状況に応じたアップデートを、プロジェクト途中に定期的に行うのが良い。そうすることで、見積もりとのブレが広がらない早い段階でトレードオフの話をできるからだ。ウォーターフォール開発だとリリース直前に間に合わなくなってしまい、土壇場で調整するはめになるケースが少なくない。見積もりの変更を恐れずに、早い時点で手を打つからこそ調整の余地も多くあるのだ。
また、ここでのプロダクトオーナーの役割は、スタッフが「スケジュールを守らない開発チーム」という視線にさらされないように、周囲の理解を得るよう配慮することにある。
「見直しを定期的なイベントに組み込むことで、『問題vs私たち』という立ち位置が実現する。スケジュールの見直しが悪いことのように思っていると、ユーザーや営業担当者が開発チームを一方的に非難する図式に陥りがちだ。そうではなく、プロダクトオーナーが率先して関係者全員に問題解決を呼びかけ、話し合うことで、前向きにプロジェクトを進められるようになる」
「この仕事量なら何週間で消化できるか」を見る
次に梶原氏は、良いプロダクト開発計画を実際に行う際の手順について「規模の見積もり」と「ベロシティの計測」という、大きな2つのポイントを紹介した。
規模を見積もる＝「時間ではなく規模が大事」
見積もりでは時間よりも規模を重視するべきだ。先に述べたように、時間重視では「まず納期ありき」に陥る危険が高い。そうではなく、こなすべき仕事量や解決する課題の数がどれだけあるかを把握することが必要だ。
チームのベロシティ（実行能力）を計測する
ベロシティとは、開発チームが実際にタスクに取り組んだ実績値であり、開発チームが今後、唯一信頼できる指標となる。具体的には、単位時間（1週間または2週間）あたりに消化できるタスク量であり、最新の4スプリント程度の平均値が、その開発チームの実力と見てよい。
この2つが完了したら、実際のプランニングに入る。「リリース日固定」と「スコープ固定」の2つの方法がある。
リリース日固定
- 開発できる総量は、スプリント数×平均ベロシティ
- リリース目標値は、開発総量の7割以内に収めておく
- リリースラインが「できる範囲」に収まらない場合は破綻しているので再調整
スコープ固定
- リリース日の予測は、総見積もり÷平均ベロシティ
- 全てのバックログがいつまでに完了するか予測を行う
- リリース日はあくまでも予測
見える化ツールでプロジェクトを一気に効率化
梶原氏は、開発プロジェクトを効率的かつ高品質に進める上で、アトラシアンの開発管理ツールを活用した「リリースプランニングの見える化」が有効だと、自己の経験に基づいて示唆する。
「アトラシアンのソフトウェア開発ツールであるJIRA Softwareでは、非常に多くのレポート機能が提供されている。これらはリリースプランニングに関するさまざまな情報を視覚化して、プロダクトオーナーの判断やチームへの情報共有、顧客に対する説明など、プロジェクトのあらゆる局面で、情報の可視化を支援してくれる」
JIRA Softwareを活用した、リリースプランニングの見える化は「実績値をもとに、ステークホルダーとより具体的な会話ができる」「プロジェクト開始時に予想していなかった変更があれば、即時にレポートに反映してくれる」という2つの大きなメリットをもたらし、フレキシブルで効率の良いプロジェクト進捗を可能にしてくれるという。
最後に梶原氏は、「私たちエウレカでは、『世界中の人々の人生を豊かにするものを自分たちの手でつくり出す』をビジョンに掲げています。私たちといっしょに何かをしてみたいという方は、ぜひ声をかけてください」と呼びかけて、セッションを締めくくった。
お問い合わせ
アトラシアン株式会社
