なぜ見積もりはバラバラになるのか？「モバイル見積もり勉強会」 #モバイル見積を通じて分かったこと

2014/1/24(金)19:00-21:30 にスマホアプリを新規作成したらいくらかかる？モバイル見積もり勉強会 #モバイル見積を@youten_redoと共催しました。

勉強会の目的と資料等

開始前の、勉強会の目的は「見積もりのノウハウ共有とかそんなのが1割とあとは興味本位が9割」という具合でした。
今回、勉強会を通じて色々な発見があったので、見積もりという単語のあいまいさと考え方についてエンジニア視点でメモしておきます。
割と書きたいことだけ書いていること、ケーススタディの一つなので汎用性の高い話ではなく特定分野のお話ということ、を念頭に置いてください。

イベント詳細 http://www.zusaar.com/event/3147004
- 『カレー屋チェーン店「ペッパー警部」の公式アプリを作る』仮想案件の見積もりを各チームで行う、という流れです。

共催者、参加者の感想は

に詳しいので詳細は割愛します。

資料はこのあたりです。興味があれば見てください。

モバイル見積りガイダンス https://docs.google.com/file/d/0BybSp1RcLhkVczFkU1czd3g3Yms/
アプリ開発方針書 https://docs.google.com/file/d/0B3JEBJmnCulYcUVoOXA5ZUhjSUU
アプリ要求仕様書 https://docs.google.com/spreadsheet/ccc?key=0AnJEBJmnCulYdHYxZFJFOUg5c2ppczlVbExFTHlvVUE&usp=drive_web

こちらの画像は画面遷移仕様

画面遷移の数は少なく、わかりやすいですが、地図表示にGPSが必要、NFC,iBeaconを使いたい（試作要素）、サーバー連携などがポイントとなってくるAndroid/iOS対応モバイルアプリです。
アプリ自体の解説と各チームの見積もりについては
共催者のページ（http://greety.sakura.ne.jp/redo/2014/01/post-41.html）に詳しくあるので割愛します。

このエントリではアプリの内容については触れていませんので、前述のエントリを読んでなくても以下は読める…と思います。

この記事の諸注意

今回の勉強会の要件項目と数字だけをみて自社に適用しようとすると必ず失敗するので、そのあたりご理解の上、読み進めてもらえると助かります。
わかっていればいいんですが「相見積もりの中央値とっときゃなんとかなるのでは…」、「なるほど、これぐらいのアプリだと中央値が業界標準なのかな…」とか考えてる人がいたら（これらの見積もりがすべて外れている可能性を考慮してないので、自分で確認しないと何かあったとき）爆死するよ、僕知らないからね。というぐらいのニュアンスです。

なぜこうも見積もりはバラバラになるのか？

この勉強会では見積もり差が最大で10倍程度ついてしまいました。
答えはわりと簡単で、見積もりに関連する要素が多いから＆見積もりという言葉が差す範囲がみんなバラバラ（＝顧客、開発者間で一致しない。主催者でさえも）だからです。わかりやすい要素を選んで図示してみました。

図は、エンジニアが普段慣れ親しんでるプロジェクト工程の例です。今回、仮想案件で見積もりを実施しましたが要件定義を読んで「これはまだまだ変更される恐れがあるな」と考えるか「要件に対して工数が最小化する仕様でつくろう」と考えるかで全く違ってきます。受け入れテストでどこまでサポートが必要なのか、要件定義書自体を作ってくれるのか、受注したら自分たちでメンテして運用する必要があるのか…（仮想案件では対象外とした）。色々なケースが想像できます。ここでは工程が抜ける程度なので影響は限定的です（それでも認識違いがあるとツラいレベル）。

当然、工程だけじゃなくて、プロジェクトをどうとらえるか、の考え方にも影響されるので、このあたりも見積もりをむずかしくします。

定例会議があれば交通費が余分に必要になりますし、作業に使うはずだった工数も吸われます。仕様の詳細化のタイミングで仕様変更があるかも知れません。その手戻り、仕様未決定の部分はリスクとして管理されるべきでしょう。未決定の部分を詰めるためにはモックによるプロトタイピングが必要かもしれません（これらは見積もり時には検討していない作業かもしれませんね）。

お客様と仕様を交渉したり、テスト対象を決めたりする作業が多いのであれば、エンジニアだと効率が悪いという話になるでしょう。そうなればディレクターなりプロジェクトマネージャなりをアサインして、より本格的なマネジメントが必要です。当たり前ですが大規模になればなるほど作業は細分化され、個人で把握している範囲は狭くなります。

また必要なら間接部門や営業費、利益を加えなくてはいけません。今回は簡単化のため間接費やら全部含めて40,000円/人日としました。このあたりはどう考えても会社ごとに事情が違うはずです。
なので数字だけ見て議論しても誰も幸せにならないです。
（あとコンペという形式をとるならそれにかかる費用などを間接的に回収する必要がありますし、受注するために追加の仕様を提案して盛り込むとか、普通の作業見積より＋αの手の込んだことが必要です…）。

何度かの交渉の中で、このような意識の差をすり合わせる、というのが現実的な打ち合わせです。勉強会ではこのあたりまでできなかったので結果としてリスクの取り方、仕様の考え方がチームごとに異なり、差が広がった感じです。

この結果を見ると勉強会でやるとうれしいことは、このあたりの数字の詳細化ではなくて、エンジニアによる要件を落とし込む際の考え方やノウハウの共有、ディスカッションと考えられます。
多分、勉強会の運営側で厳密に仕様を固めて変動要素をなくしていくと、見積もり精度は上がるはずです。しかし自明な作業を機械的にやる感覚に近くなり、勉強会で試す意味が薄くなりそうです。

今回は、当初の目的であるノウハウ共有については、参加者の間で、ディスカッションできたみたいで良かったです（ほんとうなら自分が参加者になりたかったんだけど）。
実際の結果は見積書の金額より作業項目と工数など規模感をみてもらったほうがより当日の視点に近い感覚で読めると思います。

見積もりの基準値はないのか？

見積もりのための技術を一般化して基準値を求めよう、という考え方もあると思います。今回の勉強会では、仮想案件に対して複数のチームが見積もるという形を取りましたが、実際に適用するにはいくつか不備があります。

仮想案件のクライアント予算の指定をしていない（株式会社ペッパー警部の予算は無尽蔵である）
見積もり時に質問があれば、その場で仕様を確定させた（株式会社ペッパー警部のシステム開発部はスマホアプリ開発のプロである）
そもそもクライアントの目の前で詳細見積もりをするエンジニアは、いない（持ち帰り、じっくりと社内で検討する）

大きく前提条件が異なるので、このあたりは残念ながら参考になりません。

エンジニアの共通認識として、最初から仕様が固まっていれば（納期とか実現可能性とか気になるものの、このあたりがクリアされていれば）、たいていの場合大丈夫という感覚があります。
本当にだめなのはいつまでたっても仕様が決まらないことと、繰り返される仕様変更です。あなたは、『デスマであることを理解しながらも、なすすべなくデスマに突っ込んでいくエンジニア』を何人も見てきたはずです。

リスクマネジメントの重要性

しかし、最初から仕様が固まっていることはほとんどない、というのもご存じのとおりです。
正しいプロジェクトでは、これらはリスクとして管理され、期間を区切り、リスクを最小化します（どうしようもないリスクは放置することもままある）。

場合によっては受託契約を要件定義、製造、など工程や期間で切ってしまうのもいいでしょう。全く読めないなら派遣契約のほうが良いかもしれません。
与えられた権限次第ですが、契約の種別、期間なども選択肢でしょう。ただこのあたりになるとエンジニアじゃなくてマネージャ職っぽいですね。
見積もりでリスクをどう考えるか、で見積もり結果は大きく異なってくるでしょう（見切れた作業では差は表れにくいです）。

とある業界の常として、重複した期間で0.5人月ずつアサインされた人は、必ず1人月以上の仕事をさせられる法則がある（と筆者は信じている）ので、
アサインする人の数で、見積もりの基準として、考えるのがいいかもしれません。

また、さっきから都合上、人月ベースで話してますが本来の見積もりは、機能単位での金額しか出てこないはずです。

どうしても見積もりの基準値が欲しい場合は、プロジェクトの業界統計（IPAがまとめている）や社内の統計情報を参考にするとよいです。
プロジェクトごとメトリクス計測していれば工程ごとの作業工数、不具合検出率などから予測値が得られます。計測した項目から重要そうなパラメータを利用して見積もると割と納得度が高いです（※過去の統計が必ず通用するわけではないので精度が上がるか？については難しいところです。一般的に差分開発であれば精度は高くなります）。
このあたりはプロジェクト管理、メトリクス計測ですね。

相手との関係性で成り立つ「見積もり」

結局のところ、見積もりは双方の関係性（予算、人件費、また双方の持つ技術力など）から出すものなので個別の議論はあまり意味がない、という身もふたもないところに着地します
（特に付き合いのある会社間では、これぐらいのクオリティになるだろうな等、ある種の信頼関係もあるはずです）。支払った金額に対して納得できる価値を提供できるか、という本質的な関係性が残ります（双方が納得して評価するために見積もりが必要、とも言えます）。