Debimate

Written By Nao

【どうやって見積もりしてますか?】プロジェクト工数を見積もるときの私なりのやり方【ボトムアップ見積り】

by ·

前書き：超概算見積もり？KKD法でいいですか？

私は、立場上、プロジェクトの工数を見積もることが多いです。

しかし、自分が担当していない領域（例：iOSやAndroid）の見積もりは流石にできません。そこで、他メンバに作業を依頼します。そのタイミングで、次のような質問を受けることがあります。

　

？？？< 「見積もり、どうやるんですか？」

　　

このような質問にしどろもどろな回答している内に、自分の中でも考えがまとまっていないことに気づきました。そこで、本記事に簡単な見積もりのやり方を残そうと考えた次第です。サーバーサイド視点で説明します。

ちなみに、KKD法は「勘！経験！度胸！」という、製造業で古くから伝わるメソッドです。

　　　

ボトムアップ見積もり（PMBOK）を採用

ボトムアップ見積もりは、成果物や作業を分解し、実施する作業をWBS（Work Breakdown Structure）として表現し、作業項目単位で工数を見積もる方法です。

PMBOK（Project Management Body of Knowledge）に登場する方法であり、一般的かつ理解しやすい方法であると認識しています。

 

例えば、「画像を投稿する（サーバー側）」の要件があった時、以下のように作業を分解していきます。

  • 大項目：画像を投稿する
    • 中項目：画像を投稿するAPIを実装
      • 小項目：API仕様をiOS／Androidエンジニアに共有：N人日
      • 小項目：コントローラ層の実装：N人日
      • 小項目：ユースケース層の実装：N人日
      • 小項目：AWS S3に画像をアップロードするサービス層の実装：N人日
      • 小項目：画像ファイル名をハッシュ値に置き換える対応：N人日
      • 小項目：Amazon S3名を環境変数経由で受け取る処理の実装：N人日
    • 中項目：画像の保存先をインフラ構築
      • 小項目：Amazon S3を追加するIaCの実装：N人日

 

作業を分割することによって、作業の抜け漏れが少なくなります。また、一つ一つの作業範囲（小項目）が非常に小さくなるため、見積もりの精度が上がります。

 

ちなみに、私はボトムアップ見積もりをPMBOKから採用していません。偶然、辿り着きました。

私がまだ20代の頃に1時間単位で工数を減らしてくる顧客がいたので、理論武装（≒「作業の細分化」および「作業が必要な理由の補足文を準備」）して工数獲得する必要がありました。試行錯誤し、ボトムアップ見積もりに辿り着きました。

　　　　　　

ボトムアップ見積もりの利点

  • 作業の抜け漏れ（観点不足）をレビューしやすい
  • 作業が小さいので、見積もりの確度が高い
  • 作業単位で、係数（不確実性や難易度を踏まえて、見積もり工数に乗ずる値）を変更できる
  • 顧客がエンジニアの場合は、作業内容を説明しやすい（理解を得やすい）
  • 作業スコープの認識が合いやすい（言った／言わない問題が起きづらい）
  • ボトムアップ見積もり中に残したメモが、開発時における設計ドキュメントの雛形になる

　　　　

ボトムアップ見積もりの欠点

  • 要件が明確な状態でないと、作業項目を割り出しづらい
  • 経験したことない作業を細分化しづらい
  • 想定していない作業が発生した場合、その分だけ工数が不足する（観点の考慮漏れ）
  • インフラ構成やAPI本数などを割り出すため、設計の領域に入り込みがち
  • 見積もりにかかる工数が非常に大きいため、スピード感がない。失注時のダメージも大きい
    • 要件の大小に応じて、作業の分割粒度を変える必要がある

 

ジュニアエンジニアは、「どんな作業するか分からない」と迷うことが大半だと思います。私も、20代の頃に想定作業のリストアップが不足しており、その分がマルっと工数不足になったことがありました。

　　　　

データ入出力とデータ構造を明確にする

賢いデータ構造と間抜けなコードのほうが、その逆よりずっとまし。

またもやフレッド・ブルックス本の第11章から。「コードだけ見せてくれてデータ構造は見せてもらえなかったら、私はわけがわからぬままだろう。データ構造さえ見せてもらえれば、コードのほうはたぶんいらない。見るまでもなく明らかだから」

引用元：伽藍とバザール（The Cathedral and the Bazaar）, Eric Steven Raymond著

 

見積もり時に、私が意識しているのはデータ入出力とデータ構造（DBのER図）です。データ入出力はインターフェースそのものであり、現時点でできることを表します。データ構造は、将来どのようなデータを追加で返せるか、どのようなデータ分析ができるかを表します。

 

インターフェースおよびデータ構造の変更は、リスクが伴うものです。予め、ある程度の確度が必要です。

 

例えば、データ入出力でヤラカシがちなのは、ファイル書込／参照のケースです。バージョン間でファイルフォーマットが変わったため、アプリがファイル参照時に例外を吐くことがあります。ファイル（インターフェース）を気軽に変えると、後から関係者と調整が必要になったり、うっかり調整を漏らしてバグが発生することがあります。余談ですが、20代の頃に「ファイルもインターフェースなので、気軽に変更しないでください」と怒られました。

 

別の言い方では、データフローとCRUD（Create, Read, Update, Delete）を抑えるようにしています。前述した「画像を投稿する」という要件であれば、「画像はどうやって配信するのだろうか（Readの観点）」「データ更新時、キャッシュの影響を受けずに更新するにはどうすべきだろうか（Updateの観点）」「画像をS3から物理削除できるだろうか（Deleteの観点）」といったことまで考えます。

要件によっては「記事に紐づく画像は、記事が公開されるまで参照できないようにすべき」といった観点も考えられます。しかし、この観点は、データフローやCRUDに思いを馳せるだけでは辿り着きません（少なくとも私は）。要件として明記されていたり、過去に類似の要件を経験していたり、想定ユースケースを事前に深堀していなければ、辿り着けないと思います。

 

観点の網羅性は、シニアエンジニアとの壁打ちで高めていけばいいかなと割り切っています（シニアエンジニアが捕まらない問題があるかもしれませんが）

　　　　　　

自身の見積もり精度を何となく把握する

会社によっては、「見積もり（予定）」と「実績（実際に使った工数）」を管理していると思われます。この予実をもとに、自身がどの程度の精度で見積もりできているかを把握できていると好ましいです。

 

私の見積もり精度は、自分の見積もりに対して自ら作業する時はトントンです。しかし、他の人に作業をお願いすると、盛大に超過することがあります。原因は単純で、私と作業者との間にあるスキル差や経験差を考慮した見積もりになっていないからです。

当然、ある程度のバッファ工数を設けて作業を依頼するのですが、さしたる根拠もなく「このぐらいの工数できるよな多分」と見積もりを修正するので、運ゲーです。かと言って、バッファを沢山増やすと「こんなに工数がかかりますか？」と身内からも言われてしまいます。

 

正直答えがありません。

とは言え、見積もり精度は高い方が好ましいので、少なくとも見積もり精度を把握できる環境を構築すべきです。

　　　　

削るのは要件。テストを削るな

「テスト要らなくね？」

　

顧客と金額感の折り合いがつかないので、減額するために「テスト不要」という意見が登場します。

 

私の体感ではテストコードを書いた方が実装速度／PRレビュー速度が速いです。和田卓人氏（「テスト書いてないとかお前それ〜」で有名な方）も以下のように「質とスピード」に関して度々言及しています。

短期的なスピードを追って作業するものと、そうでないもののスピードがいつ逆転するかというと、1カ月だと。

引用元：品質を犠牲にすることでソフトウェア開発のスピードは上がるのか？

　　　　

削るべきは、テストではなく、要件です。

「テスト要らなくね？」を聞く度に、「啓蒙が必要だ……」と心を燃やしています。

　　　　

最後に

見積もりこそ、AIの仕事じゃないかと思う今日この頃。

　　　

タグ:

おすすめ