WEB技術
受託開発の見積時に抑えておくべきポイント
2015年6月2日 by 5
最近弊社の若手から見積もりのコツを聞かれることが多いので、初回打ち合わせ時とその後の見積作成までの工程に分けてまとめてみました。
今回は新規の案件を想定し、ジャンルは絞らずにWEB開発全般に適用できるような見積もりにしています。
システム開発で見積もりをする目的
もちろん金額がわからないと取引が始まらないというのもありますが、システム開発で見積もりをする目的は「発注者と受注者の意識合わせをすること」です。
金銭や時間、人的リソースの部分を最初にクリアにし、契約の可否やプロジェクトスタートの可否判断に使用します。
単に金額を出して案件を獲得するというだけでなく、このフェーズでプロジェクトを成功させるまでのイメージを掴むようにしましょう。
初回打ち合わせ時
１. 細かい仕様よりも目的や背景に目を向ける
システムの話をしていると細かい仕様部分の話で時間を使ってしまうことがあると思います。 作るものが完全に決まっていて、先方の言うとおりに作るだけの場合はいいのですが、システムのイメージが固まっていない人が大半なので受託企業としては、「提案すること」が必須となります。
より良い提案をするには目的や背景、さらに予算や技術的制限事項を詳細に抑えておくべきでしょう。
2. スコープを明確にする
新規案件の場合は分かりやすくていいのですが、保守案件や連携システムがある場合には注意が必要ですね。
例えば、既存システムを改修した場合、下記のような点を確認する必要があります。
- 改修対象以外への影響範囲の調査やテストも必要か
- 連携しているシステムの改修も必要か
- 業務フローが変更される場合、影響度の調査やユーザへの周知も必要か
- ドキュメントの修正も必要か新規の場合でも、本番サーバの構築までやるのか、アプリ完成までなのか等の確認が必要です。
スコープを定義する上で大事なポイントとして、「何をするか」だけでなく「何をしないか」も一緒に定義すると良いでしょう！
３. 不明点を明確にしておく
おそらく初回の打ち合わせで全てを明確にするのは中々できないでしょう。
なので打ち合わせの最後でも途中でもいいので、「何が不明なのか」、「どうすれば不明じゃなくなるのか」を整理しておきましょう。
ここが明確になっているとクライアントも協力がしやすくなります。
４. 幅がある状態でもいいのでざっくり見積もりを出す
1～3ができている前提ですが、まずは規模感で見積もってみましょう！
スコープが明確になっていて過去の実績や経験で似たものがあれば、ざっくりは出せるはずです。
3で不明点が明確になっていれば幅がある理由も理解してもらえるし、クライアントも早めに予算感が掴めるはずです。
また、「全然予算足りんわ！」ってなった場合にも、その場で代替え提案も出せます。
開発経験のある人はわかるかもしれませんが、システムってちょっと仕様を変えるだけで金額が倍変わったりするんですよね。。。
その場で見積もりを出すのは結構経験値がいることなので、自信がない人は後で見返すためのメモだけ取っておき、実際にクライアントへ出した見積もりとの差を比較して徐々に精度を高めていきましょう。
見積を作るまでの工程
１. 不明点の調査
良い流れで来ていれば不明点が明確になっていると思います。
その不明点を一つずつ解消していきましょう。
調査は突き詰めればきりがないと思うのですが、この段階では見積もりができる最低限の調査までで良いです。
例えば、調査項目に「Facebookでログイン」の機能があったとします。
ここでは下記がわかれば詳細な実装方法がわからなくてもある程度の工数が見積もれるはずです。
- 認証方式は何か
- SDK提供されているか（言語も）
- 前例があるか
- アップデート等の注意事項特に前例があるかは重要で、前例がないものはバッファを多めに載せておくことをお勧めします。
２. WBSの作成
WBS（ワークブレイクダウンストラクチャー）はシステム開発の見積もりにすごくマッチしていて、一番良い材料になります。
WBSの精度で見積もりの精度もかなり変わります。（WBSの作り方は別途解説したいと思います。）
例えば、転職サイトの見積もりをしていたとして「スカウト機能」の工数を出すのはすごく難しいと思います。
一方、かなり簡略化していますが下記のようなWBSがあるとだいぶ見積もりやすいと思います。
- 企業ユーザ機能
一般ユーザ一覧
プロフィール検索機能
- 並び替え機能
- ページネーション
- 詳細画面へ遷移ボタン
- スカウトメッセージ送信画面に遷移ボタン
- スカウトメッセージ送信
タイトル、メッセージを記入して送信機能
- 一般ユーザ機能
メッセージボックス
受信一覧
- 送信一覧
- スカウト一覧このように漏れがなく詳細に落としこんだWBSが作成できれば良い見積作成できるでしょう。
３. WBSの最小単位毎に積み上げ見積（ボトムアップ見積）を作成
続いて、WBSの最少単位ごとに金額 or 工数を振っていきます。
数は多いですがタスク単位に落とし込まれているため、漠然としていた時よりもかなり見積もりしやすいです。
下記の１～３を合計しすれば、積み上げ見積もりは完成です。
- タスク単位に見積もる
- テスト工数を見積もる（一つ一つのタスクに入れてしまうケースもある）
- 不明点やリスクを加味してバッファを見積もる４. 見積の妥当性を確認
１～３を行うことで精度の高い見積もりは出せている想定ですが、大きなミスをしないためにも妥当性の確認は徹底しておきましょう。
下記に見積もりの妥当性を確認する方法を記載していきます。
WBSに抜けはないか
これがあると元も子もないのでしっかりチェックしておきましょう。
別の方法でも見積もってみる
別の方法で見積もるとタスクレベルでのミスは防げませんが、全体として桁違いのミスを防ぐことができます。
簡単なのは過去のプロジェクトをベースに見積もってみる（類推法）ことです。
過去のプロジェクトは企業にとっては財産なので、それを有効活用しましょう。
不明点が含んでいるリスクを軽視していないか
この時点で不明点はある程度解消していると思いますが、実際に開発が始まってから解決していくべき不明点もあるかと思います。
その不明点がどれくらいのリスクを含んでいるかも考慮しておきましょう。
規模に対してテストやバッファが妥当か
テストもバッファも必要なものなので、妥当な分が盛り込まれているか確認はしましょう。
この辺りは見積もる人の度胸次第みたいになりがちですが、過去の実績等から適切な見積もりをするように心がけましょう。
まとめ
いかがでしたでしょうか？
業界歴が長い人でも見積もりは難しいし、よく分からないと言う人も結構いますが、手順を追って行えば、だいぶ敷居は下がってきます。
また、経験も重要な分野なので早いうちから見積もりに慣れておくことをお勧めします。
/* */
!function(f,b,e,v,n,t,s){if(f.fbq)return;n=f.fbq=function(){n.callMethod?
n.callMethod.apply(n,arguments):n.queue.push(arguments)};if(!f._fbq)f._fbq=n;
n.push=n;n.loaded=!0;n.version=‘2.0’;n.queue=[];t=b.createElement(e);t.async=!0;
t.src=v;s=b.getElementsByTagName(e)[0];s.parentNode.insertBefore(t,s)}(window,
document,‘script’,‘//connect.facebook.net/en_US/fbevents.js’);
fbq(‘init’, ‘893615277419786’);
fbq(‘track’, “PageView”);