エンジニアが知っておきたい工数見積もり術！  無理ゲー進行 から脱するために大切なコト

見積もりが重要なのは、ビジネスの成否・残業時間・評価・精神的プレッシャー・個人や部門間の信頼関係など、多くの要素に関わってくるからです。

見積もりとは、ソフトウェアのプロが直面する活動のなかで、最もシンプルだが最も恐ろしいものである。ビジネス価値の多くは見積もりにかかっている。我々の評判の多くは見積もりにかかっている。不安や失敗の多くは見積もりが原因である。ビジネスと開発者を分断してきたのは見積もりだ。両者の関係が不信感に満ちている原因も見積もりだ。

『Clean Coder プロフェッショナルプログラマへの道』p.141より

参考： プロのエンジニアに必要なものとはなんだ？『Clean Coder』に学ぶ信頼獲得のメソッド【今こそ読み解きたい名著】

例を挙げてみます。AさんとBさん（いずれもエンジニア）が、同じ仕事内容で10回の作業を行ったとしましょう。

• Aさん：1回にかかる作業時間を10日と見積もる
• Bさん：1回にかかる作業時間を5日と見積もる

実際に作業が完了した日はそれぞれ以下のグラフのようになりました。

Aさんの見積もりは10日なので、1回を除き見積もり期間内に完了しています。Bさんの見積もりは5日なので、見積もり期間を超えた回数は5回でした。

比較すると、見積もり期間内に終えた回数が多いのはAさん、作業完了までの平均日数が短いのはBさんです。2人のうち、評価や信頼を得られそうなのはどちらでしょうか？

おそらく、多くのチームで評価されるのは、Aさんでしょう。設定した期間までに完了させることで、他の作業やビジネスのプランを立てやすいため、チームワークにおいてはAさんのような取り組み方が好まれるのです。

しかし、実際にはBさんのように見積もりから遅れがちな取り組み方をしている人も少なくないのではないでしょう。自ら厳しい見積もりを提示してしまい、締め切りに追われてしまうというパターンです。

実際の現場でも見積もりが甘かったがゆえにプロジェクトが遅延し、「期間を守れなかった」という理由で信頼関係が崩れてしまうのです。

見積もりに関する期待の違い

見積もりが失敗する大きな原因として、「見積もり」に対して見積もり以上のことを期待していることが挙げられます。特に、プロジェクトマネージャーやディレクターとのコミュニケーションには気を配りたいもの。エンジニアと非エンジニアの方が考える「見積もり」の違いを整理しておきましょう。

エンジニア視点での期待

エンジニアの場合、短すぎる見積もりを出してしまう傾向があります。残業を増やして達成する場合もあると思いますが、期間予測を誤っていることには変わりありません。

短めの見積もりを出すことは、自分自身の能力への期待であると言えるでしょう。特に期限を設定されていなくても、余裕のない期間を回答してしまうことがあります。「自分ならこれくらいの期間で完了できる」と油断し、文字通り、「希望的観測」で見積もりをしてしまうのです。

特に、「どれくらいかかる？」と口頭で尋ねられた時などは注意が必要です。楽観的に考え、つい短い期間を答えてしまうことがあるからです。立ち話などでラフに尋ねられると、深く考えずに「xx日くらいでできるんじゃないかな～」と短めの期間を答えがちだと思います。その後、よく考えてみると課題が見つかった、といった事態に見舞われ、慌てることになります。

このように、エンジニアは自分自身の能力に期待したり、相手の期待に応えるために短すぎる期限を守ろうとしてしまいます。頼まれたわけでもないのに、できるだけ短い期間を回答してしまうことがあるのです。

見積もりを成功させるには、このような期待と現実を分けて考えることが重要です。

エンジニア以外の視点での期待

エンジニア以外の職種では、プロモーションやビジネスのプランを立てる・UI/UXデザイン・プロトタイプを使った検証といったタスクがあるでしょう。これらの多くは開発やリリースのスケジュールに依存します。そのため、エンジニア以外のメンバーは、作業期間そのものではなく完了するタイミングを知りたいと考えているはずです。見積もり = 完了のコミットメントだと期待していると言えます。

先ほどのAさん・Bさんの例では、Aさんのほうが完了のタイミングを守っているため評価が高くなるのです。

これから紹介しますが、見積もりとはピンポイントなタイミングではなく、幅や期間を意味します。チームが必要としている情報が「見積もり」なのか、「確実に完了できるタイミング」なのかを見極める必要があるでしょう。

見積もりとは何なのか

あらためて、見積もりとは何なのか考えてみます。

ソフトウェア開発プロジェクトは毎回状況が異なります。ビジネス要件や使用する技術は異なりますし、開発チームの人員も変化します。そのため、毎回新しい問題にぶつかりスケジュールの予測が難しくなるのです。

したがって、見積もりを「今からぴったり5日後に完了」のように1点のタイミングにすることはできず、「4～7日後の間に完了」のように、「幅」が必ず必要なのです。

なぜ見積もりに幅を持たせることが必要なのでしょうか。不確実性のコーンをもとに説明します。

『ソフトウェア見積り 人月の暗黙知を解き明かす』Kindle版 位置No. 1156より

不確実性のコーンは、プロジェクトの各段階の見積もりと実際に必要になった工数が、どの程度ばらつくのかを示したグラフです。

初期コンセプトの段階では0.25倍から4倍、見積もりにばらつきが発生します。例えば、見積もりの値が1ヶ月であるとき、工程が完了するまでの期間は短ければ1週間、長ければ4カ月と、非常に幅広くなってしまいます。

不確実性のコーンは見積もりの難しさを表しますが、同時に精度を高める方法も表しています。プロジェクトのステップを進めることでばらつきを小さくできるのです。例えばユーザーインターフェイス設計の完了まで進めれば、ばらつきは0.8倍から1.25倍まで狭めることができ、より現実的な工程完了日を仮設定できるでしょう。

このように、見積もりの精度を高めるにはプロジェクトのステップを進めることが有効といえます。

より良い見積もりを作るために

しかし、現場においては期間内の完了に対してコミットメントを求められることが多いと思います。見積もりの精度を100%にすることは困難ですが、期限内の完了確率を高める方法はいくつか存在します。具体例とともにご紹介しましょう。

プロジェクトのステップを進める

不確実性のコーンで述べたように、見積もりのばらつきを小さくするにはプロジェクトのステップを進める必要があります。

そのため「要求の完了」もしくは「ユーザーインターフェイス設計の完了」のフェーズまで、プロジェクトチーム全体で協力して素早く進めるべきなのです。これらが完了するまでは、現実的な見積もりを作成することはできません。どうしても早い段階で見積もりが必要な場合は、不確実性のコーンを参考に幅を持った見積もりを作りましょう。

また、プロジェクト途中で要件変更や人員変更が発生する場合もあります。これらの要素は見積もりに影響するため、定期的に見積もりを更新してプロジェクト内外に周知する必要があります。

その場で回答しない

「xxはどれくらいかかる？」と口頭で聞かれることがありますが、その場の直感で回答することは避けましょう。5分程度でも構わないので、工程完了までに必要なタスクを書き出したり、他のエンジニアと相談したりするだけで見積もり精度は大きく向上できます。

尋ねられるとついその場で回答したくなりますが、代わりに「今は手が離せないので15分ほしい」のように伝え、整理した後に回答すると良いでしょう。

バッファを設ける

見積もりは必ず幅があるものなので、あらかじめバッファを持っておく必要があります。開発の状況に合わせてこのバッファを利用するのです。 ここではスケジュールバッファとフィーチャーバッファの2つを挙げます。

スケジュールバッファとは、作業の見積もり期間とコミット期限に差をつけて、問題対応に備えることです。 例えば、見積もりの値が2週間の時に完了のコミットメントを3週後にすれば、スケジュールバッファは1週間になります。想定外の問題が発生した際、この期間を利用して解決することができます。

フィーチャーバッファは必須機能とそうでない機能を分け、スケジュールを調整することです。1ヶ月後のリリースが動かせない場合、例えば必須機能は見積もり2週間分までとし、それ以外の機能は間に合う分だけ実装するような方法です。

もしこれらのようなバッファがなければ、残業などで調整せざるを得なくなります。個人の残業に頼ったプロジェクトはマネジメントの崩壊と同義です。プロジェクトマネージャーの方は、自分が調整可能なパラメータを持つことを心がけてください。

PERT法を利用する

見積もりに有効な、プロジェクトマネジメント手法であるPERT（Program Evaluation and Review Technique）の見積もり計算式を紹介します。強力かつシンプルな手法なので、困っている現場ではすぐに試してみてください。

ある作業にかかる時間を見積もる時、まずは以下の3つの値を設定します。

• 最良時間
  • 何も問題が起きず、全てがスムーズに進んだときに必要な時間
• 最有力時間
  • 完了する確率が最も高いと思われる時間
• 最悪時間
  • 問題が次々に見つかって最も上手くいかないときに必要な時間

この3つの値を下の公式に当てはめると見積もり時間を求めることができます。

例えばあるタスクに対して最良時間 = 1日、最有力時間 = 3日、最悪時間 = 10日だとすると、見積もり時間は以下の通りです。

このように、PERT法では作業完了までの時間を直感的に判断せず、少し考えるプロセスを経るため精度向上に効果を発揮します。

レビューを行う

コードレビューと同じように、見積もりも他のエンジニアとレビューし合うのが重要です。レビュワーはタスクの内容や見積もった数値に疑問があれば質問し、抜けているものがあれば指摘します。

何度かレビューをしていると、人ごとに見積もりの特徴があるとわかってくると思います。特に、無理して短めの期限を設定しがちの人は、レビューを通して適切な見積もりにすることが必要です。

レビューによって見積もり精度が高まるだけでなく、メンバーとの情報共有もできるので、ぜひチームで取り組むことをおすすめします。

経験を活かす

過去に行った似たタスクや同じ規模のプロジェクトでかかった期間を参考にしましょう。

注意したいのは、「経験を活かす = 前回より短い期間にする」と思ってしまうことです。もちろん、学びを活かして取り組むべきですが、状況は毎回変化するため未知の問題が発生するほうが自然です。したがって、似たようなタスクやプロジェクトの経験があったとしても、次回も同程度の期間が必要だと考えるべきです。見積もりよりも短い期間で完了できたときは誰も困らないのですから。

プロジェクト進行に合わせて見積もりを作る

さて、ここまで見積もりの基本的な手法をご紹介しましたが、現実にはプロジェクトの姿形は多様です。そのプロジェクトに応じて、見積もりの考え方も調整が必要です。ここからは、私が経験した既存サービスへの大規模な機能追加プロジェクトで、どのように見積もりを作ったのかを、ケーススタディとして簡単に説明します。

プロジェクトのはじめの段階

初期の段階ではアイデアとおおまかな要件だけがありました。ここで早速、プロジェクトマネージャーから「リリースまでにどれくらいかかる？」と尋ねられます。エンジニアチームで作った見積もりはおおよそ3ヶ月です。しかし、見積もりには幅があり最大で6ヶ月必要となる可能性があったため、私はプロジェクトマネージャーに「リリースまでに6ヶ月必要」と回答しました。

最大の期間を回答した理由は、未定の仕様が多く、技術面で未知の部分もあったためです。想定を大きく超えていたようで「なんでそんなにかかるの？もっと早くできないの？」という反応でした。

そこで、漠然としたアイデアを要求・要件として必要な粒度に分解し、見積もり精度を高める協力を求めました。見積もりの精度を上げるには、初期構想から要件定義までを終え、プロジェクトをブラッシュアップすることが重要です。プロジェクトのステップを進める重要性をチーム全体に共有したのです。

初期段階では無理をせず、正直な見積もりを出すことで、構想していた一部のアイデアは実現コストが大きすぎることも分かりました。このことから、上級マネージャーを含めてビジネスプランの見直しを行い、早い段階で方向転換が行われたのです。

各タスクの見積もりを作る

要求やUI設計が揃ってきたら、各タスクの見積もりを作ります。ここで大切にしたのは、実際の作業担当者が自分自身で見積もりを行うことです。

新人とベテランの混ざったチームであれば、ベテランエンジニアが全ての見積もりを作ったほうが精度が高いかもしれません。しかし、各タスクは実際の担当者に見積もりをお願いしました。おのおのが担当する部分の仕様を把握できれば、抜け漏れや課題がないか自ら考えることができます。メンバー各自がタスクの見積もりを考えることでプロジェクトへの理解が深まったのです。

相互に見積もりのレビューも実施して情報共有としても活用しました。

個人単位の見積もりを持ち寄り、チーム単位の見積もりを作る

個人の見積もりを持ち寄り、WebAPI・モバイルアプリ・Webフロントエンドといったチーム単位の見積もりを作ります。

複数名で開発を担当する場合、自分の開発担当箇所以外に一定の時間を見積もる必要があります。人数が多くなるほどコードレビューや情報共有が必要となり、一人あたりのスピードはどうしても低下してしまうからです。

モバイルアプリは3名のチームだったので、スピードを重視すれば最大で3箇所の開発を並行して行えます。しかし、品質の維持が難しくなるため、同時に開発するのは2箇所までとし、レビューやテストコード作成の時間を確保して品質を保証できるようにしました。

私はどんなプロジェクトであっても、スケジュールバッファを必ず設けるようにしています。小さなプロジェクトでは機能の増減が難しくフィーチャーバッファを取れないことがあります。ここでスケジュールバッファをなしにすると、調整できるパラメータがないため最初から追い込まれた状態になってしまいます。大小問わず差し込みの作業は発生しますし、冬季であれば体調を崩すメンバーも出てきます。問題は起きて当たり前なので、対応できる期間をあらかじめ確保することを心がけています。

定期的にアップデートする

プロジェクト進行中は定期的に見積もりをアップデートしました。更新作業に時間をかけすぎてもNGですが、必要なタイミングでアップデートすることは重要です。

私は不確実性のコーンに載っている各フェーズに沿ってアップデートを行うことが多いです。この時、プロジェクトマネージャーと再度「なんでそんなにかかるの？もっと早くできないの？」という議論になることもあります。感情ではなく事実を正確に伝え、協力して見積もりを作りつつプロジェクトをコントロールするようにしています。

参考書籍

『ソフトウェア見積り　人月の暗黙知を解き明かす』（日経BP社、2014年）では、今回引用した不確実性のコーンなど、見積もりについての分析と改善の方法が豊富に紹介されています。本稿を読んでより深い情報を得たいと思った方は読んでみると良いと思います。

おわりに

エンジニアはスケジュールに追われることも多いですが、自分を苦しめているのは自分が作った見積もりかもしれません。より良い見積もりを作り、不要なプレッシャーを取り除いてプロジェクトに活かしていきましょう。

著者プロフィール

池田 惇（いけだ・じゅん）@jun_ikd

スマートフォンアプリエンジニア。iOS・Androidのアプリ開発を行いながらPMや開発チームリーダーを経験。エンジニアとして技術を学び続け、プロダクトマネジメントや人材育成でも活躍したい。アジャイル開発とオープンソースソフトウェアの活用を好む。

編集：薄井千春（ZINE）