開発のスケジュール遅延には抗うことはできないのか？　“最大16倍”の誤差を小さくする見積もりの考え方

伊藤氏の自己紹介

伊藤理恵氏（以下、伊藤）：それでは「スケジュール遅延に対して Project Manager ができること」の発表をします。私は伊藤理恵と申します。2011年にDeNAに入社して、ゲーム事業でサーバーサイドのエンジニアをしていました。2017年ごろにプロジェクトマネージャーに転向して以後、新規タイトルや運用タイトルといった複数のゲームタイトルに携わりました。

ゲーム事業ではチームの規模が大きいことも多く、1チームに複数人のPM（プロジェクトマネージャー）をアサインして、PMのチームとしてプロジェクトマネジメントに携わることが多かったです。また、PMの職能グループを作り、PMの育成・評価などの組織マネジメントにも従事してきました。

さっそくですが、みなさんのプロジェクトで、スケジュール遅延が一度も起きたことがない人はいますか？　恐らくいないのではないかと思います。一般的に、ソフトウェア開発のプロジェクトにおいて、スケジュールを最初から正確に見積もってリリースすることは難しいと言われています。

（スライドを示して）この図は不確実性コーンと呼ばれている図です。縦軸が見積もりの誤差、横軸が時間を表していて、プロジェクト初期は見積もりの誤差が大きく、プロジェクトが進行すると見積もり誤差が小さくなるプロジェクトの性質を表した図です。

プロジェクト初期の見積もりは、多く見積もってしまった場合で4倍、少なく見積もってしまった場合で4分の1倍。つまり、少なく見積もったものから大きく見積もったものの差は、16倍にもなると言われています。

遅延は抗うことができないものなのでしょうか？　もっとも避けたいのは「スケジュール遅延はしょうがない」という思考停止です。

スケジュール遅延に対してやれることはないのでしょうか？　私はPMになって5年間、この課題に取り組み続けてきました。さまざまな案件に携わりましたが、その中には防げる遅延・低減できる遅延がありました。今日は、ふだんPMとしてプロジェクトに従事していない方でも（参考になるように）、開発スケジュールの遅延に悩みを抱えている方を対象に、実体験で学んだ遅延への取り組みを紹介したいと思います。

本発表では、数百名規模のチームで、プロジェクト開始からリリースまで数年かかるような大規模プロジェクトを想定しています。昨今のゲーム開発ではこのような性質のプロジェクトが多いのではないかと思います。ただし、（発表内容は）性質の違う他プロジェクトでも転用可能な観点にフォーカスしていきたいと思います。

プロジェクトのリリース計画はいつ作られるか？

そもそも遅延とは何でしょうか？　遅延とは予定された期日、つまり計画に対して送れることです。プロジェクトにとって一番わかりやすい遅延はリリース遅延ですよね。では、プロジェクトのリリース計画はいつ作られるものなのでしょうか？

「プロジェクトのリリース計画がいつ作られるのか」というお話をするために、プロジェクトの工程を初期、中期、後期の3つに分解して考えていきます。

まずプロジェクト初期は企画・計画フェーズです。このフェーズでは、企画の立案とプロダクトの幹を作り、今後の開発計画を立てます。プロダクトの基礎となる要件やコンセプト、ターゲットユーザー、基本構造（ゲームでいえばメインのゲームサイクルのようなもの）、このような要件を固めます。また、プロトタイピング検証を行い、コンセプトの実現可能性を確認します。

要件が固まったらその後の開発計画を立てます。タスクを見積もり、開発スケジュールを作成したり、場合によっては人員計画を立てたりもこのフェーズで行います。

次に、プロジェクト中期の開発フェーズです。このフェーズは企画・計画フェーズで固まった要件を、実際に手を動かして開発します。プロダクトの詳細仕様を詰めて、タスクを分解し、実装をしてプロダクトを積み上げて作っていきます。複雑なプロダクトであれば複数の職種の連携が必要になるため、開発フローの整理も行います。

最後に、プロジェクト後期の検証フェーズです。このフェーズはQA検証など、リリースするための準備を行います。すべての機能実装が完了して機能が結合された状態で、プロダクトの最終調整が行われます。QAを行い、プロダクトがリリースクオリティまで上がれば、いよいよリリースできる状態になります。

これら3つのフェーズのうちで、リリース工程はどの工程で作るのでしょうか。プロジェクトの初期は不確実性が高いので、プロジェクトがある程度進行して、不確実性が減ってきたタイミングでリリース時期を決めたいと思いませんか？　

しかし、たいていのプロジェクトでリリース計画は、プロジェクト初期、企画・計画フェーズで作られます。プロジェクトの予算・時間には限りがあり、さまざまな制約条件があります。そのため、プロダクトの幹が決まったタイミングで、どういうプロダクトをいつリリースするのかを、計画フェーズの段階で決めないといけない実態があるかと思います。

遅延が発生する2つのケースとその要因

遅延の原因は、大きく分けてリリース計画が作られた時と、作られたあとの2ヶ所に潜んでいます。すなわち、プロジェクト初期に作ったリリース計画に問題があるケースと、プロジェクト中期・後期でリリース計画をうまく遂行できないケースです。

2つのケースの具体的な遅延の要因を見てみます。リリース計画に問題があるケースだと、プロダクトのコンセプトがブレて仕様変更が発生して、手戻りが起きることが考えられます。リリース計画がうまく遂行できないケースだと、開発フローが決まっておらず、作業の受け渡しがうまくいかない。予定していた人員がアサインできなくなってしまったというようなことが考えられます。

ここで例に出したもの以外にも、プロジェクトによってさまざまな要因があるとは思いますが、こういった要因によりスケジュールは遅延します。また、遅延は後工程に伝播して、最終的にはリリース日が守れないということが起きます。

こうして見ると、プロジェクト初期の動きは重要だということがわかります。プロジェクト初期に立てた計画に問題があると、その影響は中期・後期に伝播します。対処が遅れるとどんどんその影響は大きくなってしまいます。

遅延を見越してプロジェクト全体のバッファを予め設定しておくという対策も有効です。とはいえ、プロジェクトの予算は有限で、すべての遅延を吸収できるバッファを取るのは難しいと思います。

プロジェクト初期にプロジェクト中期・後期を見越した完璧な計画が立てられれば良いのですが、それが難しいというのは、最初にお伝えした不確実性コーンのとおりです。

精度の高さを重視した事例

ではどうするのがよいのでしょうか？　私が過去に遭遇した事例をもとに、対応策を考えていきます。プロジェクト初期にリリース計画を立てようとしていた時の事例です。

企画要件が固まり、リリース時期を決める必要がありました。そのため、開発要件ごとに見積もりを出して、見積もりからスケジュールを立て、開発がいつ完了するかを確認して、その結果を踏まえてリリース時期を決めることになりました。

さて、どうやって見積もり、スケジュールを立てるのがよいでしょうか？　私が実際に経験した2つの事例を紹介します。

1つ目の事例は見積もりの精度の高さを重視しました。大規模プロジェクトの大事な意思決定に使う見積もりで、あとからリリース時期を変えるのは難しいです。そのため、全開発要件の詳細な仕様書を作成して、担当のプランナー、エンジニア、デザイナーそれぞれが細かく作業分割して「精度の高い見積もり」を出しました。仕様作成と見積もりに約3週間という労力がかかりました。

見積もりの結果からスケジュールを立てたところ、想定していたリリース時期を大きく超過することがわかりました。予算と照らし合わせ人員の追加も検討しましたが、限度があります。

結局、いくつかの開発要件をリリースから落とす対応を実施しました。時間をかけて見積もった開発項目をリリース日から落とす判断となり、仕様書を作る時間や見積もりの時間が無駄になってしまいました。

また、見積もり中は開発作業に集中できないため、見積もり中の2、3週間は開発作業が進行せず、開発スケジュール全体の遅延にもつながってしまいました。

見積もりの時間を重視した事例

もう1つの事例です。事例1では見積もりに時間がかかりすぎたことが問題となったため、この事例では見積もりの時間がかかりすぎないようにしたいと考えました。

ここで知りたいのは、プロジェクト全体の作業の完了目途です。仕様の細かいケースまで考慮した見積もりである必要はなく、開発要件をある程度の粒度でまとめて、規模がわかればよいと考えました。ただ、事例1のやり方よりも見積もりの精度は下がるので、それを踏まえてプロジェクト全体のバッファは確保するようにしました。これらことに気をつけて、別の方法で見積もりを実施しました。

ここでは、プランニングポーカーという手法を用いました。

まずは全職種のリーダーを集めて「この機能は全職種の作業の開始から終了までこれくらい」と、イメージの湧く開発項目を1つ用意して、その項目を「5」として基準にします。その基準に対してこの開発項目がどれくらいの大きさかという比較で、フィボナッチ数列の数字から選択してもらいました。ここでフィボナッチ数列を使うのは、ちょうどよく比較しやすいサイズになっているからです。

人間は1なのか、2なのか、3なのかという小さい数字での比較はイメージが付きやすいですが、54なのか、55なのか、56なのかという大きい数字の場合は比較がしづらいです。一方、34なのか、55なのかという比較であれば選びやすいです。

基準の開発項目は実際にかかる期間で見積もりをして、それをもとに他の開発項目の見積もりを期間に変換しました。その結果、思っていたよりも違和感のない見積もりを少ない工数で算出できました。

プロジェクトの不確実性を計画に取り込む見積もり

これらの事例から学べる、遅延しない計画を作るために大事なこととは何でしょうか？　それは「プロジェクトの不確実性を計画に取り込む」ということです。事例1では見積もりの精度の高さを重視して詳細な仕様書を作成、担当者ごとに詳細な見積もりを出しました。一方、事例2では見積もりの時間を重視して、開発項目をある程度の粒度にまとめて全職種集まった規模で見積もりをしました。

プロジェクト初期という今後の不確実性が大きい見積もりの中で、見積もりの精度の高さを求めるのは難しいです。事例2のように、不確実性が大きいことを理解して見積もりの手法を選択することが大切です。

プロジェクトの不確実性を取り込んだ見積もりについて考えていきます。まず、見積もりの手法にはさまざまなものがあります。例えばボトムアップ見積もり、これは作業を分解して構成要素ごとの工数を見積もって積み上げる方法です。事例1ではこの方法で見積もりを行いました。

対して、アフィニティ見積もりというものがあります。こちらは作業を相対的なポイントで見積もる方法で、Tシャツサイジングやプランニングポーカーといった手法が有名です。事例2ではこのアフィニティ見積もりを使いました。

また、見積もりの単位もさまざまです。テーマで見積もるのか、テーマを分解したエピックで見積もるのか、エピックを分解したユーザーストーリーで見積もるのか。開発項目をどれぐらいの粒度の単位で区切るのかを考える必要があります。事例1は細かい粒度の単位で、事例2は粗い粒度の単位で見積もりをしました。

プロジェクトのフェーズごとに適切な見積もりの手法、適切な見積もりの単位を選択して使い分けることで、効率良く見積もることができます。

プロジェクト初期は見積もり誤差がどうしても大きくなるフェーズです。開発項目はテーマ、エピックといった粗い粒度の単位を選択して、ボトムアップで見積もると時間がかかってしまうため、アフィニティ見積もりが適していると思います。

対してプロジェクト中期・後期ですが、開発項目をユーザーストーリーのような細かい粒度の単位で見積もることで、プロジェクト全体の不確実性を減らしていくことが重要になります。また、この時期はユーザーストーリーを実現するために必要なタスクに分解して、実際にかかる時間をボトムアップ見積もりで見積もるというほうが見積もりやすいと思います。

バッファの確保方法

プロジェクト初期の見積もりを使ってリリース計画を立てる際は、見積もり精度が低いことを考慮して、バッファを確保することも大事です。バッファの持たせ方としては、まずスケジュールにバッファの期間を持つ方法があります。

また、開始要件にバッファを持つという意味で、開発要件をMUST要件、WANT要件に分けて、時間が足りない場合にWANT要件を削るのも1つの手段です。また、開発予算にバッファを持ち、途中で人員を追加するなども考えられます。

スケジュールにバッファ期間を持つ方法では、バッファ期間をどれぐらい確保するべきかは気になると思いますが、バッファ期間の算出方法の一例として、2点見積もり手法を使ったことがあります。

この方法では、開発項目に対して想定外のことが起きずに最速で終わる見積もり、何が起きても終わるだろうという見積もりの2つの見積もりを出し、そこから適切なバッファを算出する方法です。

いくつかの算出方法があるのですが、私のプロジェクトでは①の期間で開発が完了する可能性を50パーセントと仮定して、①と②の差分を合計して2で割る方法で算出したものをバッファとして使いました。

また、見積もりは1回だけではありません。プロジェクトを進めながら、より精度の高い見積もりが出せるタイミングで再見積もりを行うことで、リリース計画の精度が上がっていきます。ゲーム開発の場合は、αフェーズ、βフェーズというようにいくつかのマイルストーンに区切って、フェーズごとにリリース計画をアップデートしています。

最初に決めたリリース計画の大枠の範囲内で、開発の進行状況に応じて調整をかけていきます。リリース計画の精度が上がることで、スケジュールが遅延する可能性は下がっていきます。

ここまで見積もりにフォーカスしてきましたが、遅延は見積もりの方法を改善するだけでは解決できません。今回の見積もりの事例ではリリース計画に問題があるケースでしたが、リリース計画がうまく遂行できないケースも含めて、他にもさまざまな要因でスケジュール遅延は発生します。

スケジュール遅延の要因となる課題やリスクに対して、どう計画に反映させるのかはプロジェクトマネージャーの腕の見せどころだと思います。

不確実性を受け入れて柔軟に計画に取り組みましょう。プロジェクトマネジメントの手法にはウォーターフォールやアジャイルのようないろいろな手法がありますが、どんな手法でも計画の遅延につながるリスクに対応しようという考え方は共通です。また、さまざまな手法はあれど、実際に導入してみようとするとなかなか難しいです。

まず、チームメンバーに理解してもらい、協力してもらう必要があります。協力してもらってもうまくいかないこともあります。それでもプロジェクトの成功のためにどうすればいいのか。思考停止せずに考え続けることが、プロジェクトマネージャーにとって大事な姿勢だと思います。

不確実性を受け入れて計画に取り込み、アップデートし続ける

まとめです。スケジュール遅延に対してPMができることとは。遅延の要因はリリース計画を立てる時と立てたあとに分類できます。リリース計画を立てるプロジェクト初期の動きは重要です。プロダクトの不確実性を受け入れて計画に取り込みましょう。プロジェクトを進行しながら計画をアップデートして、リリース計画の精度を上げていきます。良いプロダクトを世の中に届けていきましょう。

最後に。ゲーム事業部ではPMの採用を行っております。プロジェクトマネジメントに興味がある方、一緒に専門性を高めていきたいと感じた方、応募をお待ちしています。

ご清聴ありがとうございました。