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

エンジニアの仕事に欠かすことのできない、工数見積もり。実際の現場でいくどとなく見積もりを行ってきた筆者が、「健全な進行」にするための工数見積もりのテクニックを伝えます。

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

アプリエンジニアの池田 惇@jun_ikdです。今回は、エンジニアならば避けられない「工数見積もり」について考えてみたいと思います。若手エンジニアでも自分の作業は自分で見積もるようにするべきです。なぜなら、より正確に計画を立てられるようになれば、自分の時間をコントロールして学びや家族・友人との時間を確保できるからです。また、期日内に完了をさせることは周囲の信頼獲得に繋がります。工数の見極めはエンジニアとして、とても重要なスキルなのです。

なお、本稿での「見積もり」とは開発に必要な期間を予測することとし、見積もりが失敗する原因や対策方法をいくつか紹介します。あわせて私自身のプロジェクト進行経験も紹介します。

見積もりを失敗すると、信頼を失う

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

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

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

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

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

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

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

3

4

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週間になります。想定外の問題が発生した際、この期間を利用して解決することができます。

6

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

7

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

PERT法を利用する

エンジニアHubに会員登録すると
続きをお読みいただけます(無料)。
登録のメリット
  • すべての過去記事を読める
  • 過去のウェビナー動画を
    視聴できる
  • 企業やエージェントから
    スカウトが届く