今後書き加えたい内容

• 画面設計は作った方が良いこと
• 画面設計は完成形デザインに限りなく近いものを作ったほうが良いこと
• 画面設計を作ったらそれをベースにテストケースを作ってみるとより深く理解できること
• 独自仕様を作るとよくないのでなるべくどこかのシステムを参考に作ること
• ランニングコストについてもよく調べておくこと
• 開発環境・ステージング環境の準備が必要か検討すること
• DBやデータのバックアップ体制も作るかを検討すること
• 見積もりはシステム規模によって1〜3日かけた方が実際安全であること
• 運用をシステムに落とし込むパターンの場合は現在の運用をかなりよく聞いておいた方が良さそうであること
• 運用について聞く際には、運用での登場人物を明らかにすると分かりやすい(運営責任者、経理担当者、作業者、作業統括者など)
• 実際のスケジュールも仮で引いてみたほうがスケジュール上で必要になってくる作業工数や追加作業が見えてくるので良い
• システムを使ったときの運用イメージをどこまでリアルに先方にイメージさせるかによって初期のシステム解像度が大きく変わる(つまり見積もり精度に影響する)
• システムの運用イメージを先方にイメージさせるには、出来ることなら実際の作業に当たっている人に対して現在の作業をヒアリングしてその作業がどう置き換わるのかを説明すれば良い(つまり今の実際の作業とシステムの機能を結び付けてイメージしてもらう)
• システムの開発を依頼している人間、またはシステムの開発の会議に参加している人間が、どういう役割の人でどういう業務を行っている人かによって、システムと業務の結びつきをちゃんと理解できるかが変わってくるということ
• 基本的にすべてのデータは運営者が変更できるようにしておくべきで、これをしておかないとこちらでDBに直接データを入れる等の管理コストが掛かるため手離れが悪くなる
• システムのセキュリティレベルは事前にやる範囲とやらない範囲を明確にしておいた方が良い(IP制限、2段階認証、ログイン試行制限、定期バージョンアップ、ペネトレーションテスト、セキュアコーディングレビュー、ウィルス対策ソフト導入)
• 金額が大きい仕事は得られる金額が大きい分失敗したときに損害として払う金額も大きくなる可能性がある
• 多分書いたけど重要なのでもう一回、システムを作るうえでお客側にとってはあっても無くても特に困らないけど、保守側にとってはあったほうが良い機能が存在する(会員管理機能、管理者管理機能など)。管理画面として作っておけば運営側で管理してもらえるが、作ってなければこちらで対応せざるを得ない。
• システムのつじつまを合わせるうえで見積もりに無い機能を実装せざるを得なくなるパターンもよくある。料金削減のために特定の機能の一部を削った場合など、結局後でそれを実装しないと進めなくなることが判明して実装することになるなどがある。もしくは、削った訳でないが考慮できていなかった場合など。
• システムからのお知らせ機能、会員に対するお知らせ機能は作っておいた方が良い。規約の変更やその他お知らせは必ず必要になってくる。お知らせ機能は書き換えするタイプではなく、投稿機能とした方が良い。
• 案外メールの仕様を詰めるとシステム上では見えない抜け漏れや運用の問題が見えてくるのでメール仕様は早めに詰めておくべき
• 画面デザインを見せて「表示して欲しい項目や文言があったら言ってください」と言ってもあまり言ってくれないし、多分運用が始まってから言われるのでこっちである程度聞くなり考慮するなりしておいた方がいい
• 意外と見落としがちだが「電話番号」のハイフンが必要か否かは最初に同意を取っておいた方が良い。ハイフンありとするかなしとするかで実装が結構変わるため。(別記事参照)

経験した事

• 社長と社員で求めているシステムの像が違う
• 実際にシステムを扱う人間は末端の人間でリテラシーが低い
• スマホしか持っていない人がいる場合があるのでPC操作前提で進めるのは危険

見積もりに当たって収集する情報

項目	説明
依頼者や見積もり会議参加者の役職と業務はなにか？	システムを誰が使うのかを把握したり、システムのイメージを理解してくれやすい人が誰かを見極めるために把握したい。 できれば会議の雑談等でさりげなく聞いておく。それが出来なければ会議の中で聞く。
システムを実際に使う人間はだれか？	やはり実際に使う人間の意見が強いため把握しておきたい。 依頼者や見積もり会議参加者の中に含まれていれば聞きやすいし、含まれていなければ別途ヒアリングさせていただくか想像で補う。 複数人が利用するか、役割や権限の違う人間が利用するかは重要。
システム化しようとしている業務を現状どのように運用しているか？	依頼者は、システム化すれば便利になるというイメージだけを持っていることがあり、業務の置き換えを明確にイメージできていない場合が多い。 なので、現状の業務とシステム化したい範囲の業務を聞き出し、どのように現在の業務が変わるかを仮で作ってみて先方に見てもらい、業務がどう置き換わるかを明確にイメージしてもらう必要がある。 誰がシステムのどの機能をどう扱うか？という点が肝になる。
いつまでに必要か？	期限が特にないなら問題ないが、期限が決まっているなら見積もりや設計にも影響する。

見積もりの基本

見積もり前にある程度固めておくこと

以下の3点の視点から考えることでシステムの規模や難易度が具体的に見えてくる。

運用フロー

そもそもシステムは運用フローを助けるためにあるので、現状の運用フローがどのようになっていて、システム導入によってどのように運用フローが変化して、どのようなメリットが得られるのかを考えておく必要がある。
話を詰めていくと、そもそもシステムの導入が必要ないことやシステムの導入によって逆に手間が増えてしまうことが判明することもある。デメリットが大きいのに多額の資金を投入してシステムを実装してしまうとお互いに得しないことになってしまう。

ページ構成

具体的なページ構成の構成を考える。
それによってシステムの規模が分かる。
Figmaなどのプロトタイプツールで画面設計を作ると分かりやすい。

機能構成

ページ構成では見えてこない機能面での構成を考える。
例えば、セキュリティ面の実装、バッチ処理の実装、外部連携の実装など。
機能実装の部分が一番工数が必要になってくる部分なので出来る限り見積もり時点で出しておく必要がある。
ディレクトリマップを作成して各ページの備考として機能を記述していくと各画面に紐づく機能が可視化出来て分かりやすい。

イメージ膨らませ力が必要

依頼主はほとんどがシステム実装については無知で具体的な完成イメージを持っていないことが多い。
依頼主からのヒアリングを元に足りていない部分を自分で補完して完成イメージを作り上げるスキルが必要になる。

十分なヒアリングが可能なら十分にヒアリングした上で完成イメージを作り上げる。
例えば、直にシステム実装の依頼を受けたのなら十分なヒアリングは行いやすい。

逆に十分なヒアリングが不可能なら分からない部分は勝手に自分でイメージを膨らませて完成イメージを作り上げる。
自分の作った完成イメージが依頼主のイメージと違うならそれをたたき台にして完成イメージを修正していく。
例えば、複数社への依頼の場合は十分にヒアリングが行えない場合が多い。
自分が膨らませて作った完成イメージが依頼主のイメージと違ったことで依頼に漏れた場合は経験不足なのでしょうがない。

その他

工数を見積もる場合は、以下の点に注意する。
①やったことのある改修内容であるか？
⇒やったことない場合はバッファ時間を多めに取る必要が出てくる
②最短で終わる場合は何日で出来そうか？
⇒最短で終わる可能性は基本的にほぼ無いが一応考えておく
③普通に考えて何日で出来そうか？
⇒ある程度は詰まる箇所もあると考えて普通ならどのくらいかかるかを考える
④想定できるレベルで時間がかかると何日で出来そうか？
⇒現時点で思いつくレベルの詰まりポイントが全部詰まった場合でどのくらいかかるかを考える
⑤想定できない問題が起こったときに何日かかりそうか？
⇒想定外の問題が起こって超詰まったときにどのくらいかかりそうかを考える
⇒もはやこのレベルの問題は見積もりに含めることが出来ず、再交渉するか、あきらめるかを考えておく必要がある

上記の内容を踏まえて工数は、④で考えた工数がMAX工数、③で考えた工数がMIN工数として考えるべき。
規模が大きくなってきた場合には⑤の可能性も多少は考えてMAX工数に少しプラスしてバッファを取ることも考える。
見積もりで出す工数は、出来るならばMAX工数で出せればベスト。あとは依頼者の懐事情等を考えてMIN工数くらいまでは値下げを考えてもいい。
MIN工数以下になる場合は、その案件で自分が得られるものが無い場合は断ることも考えたほうがいい。

実際に受けた案件のうち見積もり時間以内に収まった案件が6割あれば十分。8割あれば上出来だと考える。10割になった場合は最初に吹っ掛けすぎてる可能性もある。
時間内に収まった案件が見積もり時間の何割の時間であるかも考える。5割を切るなら後から割り引いても良い。～7割なら場合によってはそのまま。7割以上なら想定内。

見積もり表フォーマット

No.	作業カテゴリ	大項目	中項目	小項目	作業時間(H)	バッファ時間(H)	合計時間(H)	合計時間(人日)	実績(H)	実績/見積もり 比 (%)
1	見積もり				0.0 H	0.0 H	0.0 H	0.0 人日	0.0 H	000 %
2	実装	DB(設計/SQL作成等) (※)			0.0 H	0.0 H	0.0 H	0.0 人日	0.0 H	000 %
3		管理画面			0.0 H	0.0 H	0.0 H	0.0 人日	0.0 H	000 %
4		フロント			0.0 H	0.0 H	0.0 H	0.0 人日	0.0 H	000 %
5	テスト	テスト仕様書作成 (※)			0.0 H	0.0 H	0.0 H	0.0 人日	0.0 H	000 %
6		テスト実施			0.0 H	0.0 H	0.0 H	0.0 人日	0.0 H	000 %
7	反映				0.0 H	0.0 H	0.0 H	0.0 人日	0.0 H	000 %
8	打合せ等 (※)				0.0 H	0.0 H	0.0 H	0.0 人日	0.0 H	000 %
9	雑務				0.0 H	0.0 H	0.0 H	0.0 人日	0.0 H	000 %
10	合計				0.0 H	0.0 H	0.0 H	0.0 人日	0.0 H	000 %
	バッファ率					+ 0 %

※ 合計時間(H) ＝ 作業時間 ＋ バッファ時間
※ 合計時間(人日) ＝ 合計時間(H) ／ 8
※ バッファ率 ＝ バッファ時間 ／ 作業時間

※「実装＞DB(設計/SQL作成等)」にはSQL作成後に実装しながら変更していく時の工数は含めない。(後から変更する分の工数は対応する画面の実装工数に含める)
　⇒つまり、基本的には最初のDB設計/SQL作成の工数のみを考慮して算出する
※「テスト＞テスト実施」にはテスト実施しながらテスト仕様書を変更していく時の工数は含めない。(後から変更する分の工数はテスト実施の工数に含める)
　⇒つまり、基本的には最初のテスト仕様書作成の工数のみを考慮して算出する
※「打合せ等」の時間はまとまった打合せ工数のみを考慮して算出する。(実装時の細かな打合せ時間は対応する画面の実装工数に含める)
　⇒つまり、基本的には最初の要件確認の打合せの工数のみを考慮して算出する

見積もりが必要な要素

要素	説明
見積もり	見積もりに掛かった時間
設計	設計に掛かる時間
実装	実装に掛かる時間
テスト	動作テストに掛かる時間
反映	本番や開発環境に反映するのに掛かる時間
やり取り	仕様確認やミーティングなどのやり取りに掛かる時間
契約書作成	契約書作成に掛かる時間(契約書を交わさないなら不要)
雑務	作業が途切れた場合などには作業内容を書き残したり思い出す時間などが発生するためその時間も考慮する
不確定要素	見積もり時点で仕様が固まっていない部分、もしくは実装実績が無いために実現方法が固まっていない機能の仕様詰めや実装に掛かる時間
バッファ	実装が思い通りに進まなかった時を考慮して多めにとっておく時間

各要素の見積もりで考えておくこと

実装

一番時間の掛かるところなので更に細分化して考えるようにする。 ここではバッファは大きく考えすぎず現実ベースで考えるようにする。ただ、バッファ時間の根拠になりそうな作業はある程度目星を付けておく。 実装方法が分かっている作業はあまり作業時間が膨らむことは無いと思われるのでバッファは少なめでも良い。

テスト

2番目に時間が掛かるところ。 ここを削減すると金額的には安くなるが、バグが見つかった場合は結局自分の信頼性が落ちてしまうので、あまり得策ではない。 実装箇所が少なくても影響範囲が大きい場合は大きく時間を取られることもある。 クライアント的にはそんなテストしなくてもいいよってなるかもしれないが、いざバグが出たときはクライアントのダメージより自分の信頼性へのダメージの方が大きい気がする。 なので、自分のためになるべく削りたくない部分。サービスして金額だけ安くするか、他の工程の時間にしれっと含めるか、時には工夫が必要。

反映

忘れがちだが、本番や開発環境への反映の時間を考慮すべき。 ファイルアップロードのみなら作業時間は少な目で済むが、DB更新やサーバー設定変更など他の作業が入ってくれば大きく時間が増えることになる。 本番だけでなく開発環境への反映などもある程度想定しておいたほうが良いかも。

やり取り

これも忘れがちだが、必ず要件確認などの時間が発生してくる。 クライアントによっては、やり取りに時間が掛かる人や、追加実装をさりげなくお願いしてくる人などいるので、クライアントによって考慮する時間が左右されてくる部分かもしれない。 この時間は大きく見積もりに含めることは出来ない部分も多そうなのでバッファとか他の作業に混ぜることが多いかもしれない。 追加実装などをお願いされないため、無駄なミーティング時間を発生させないためにクライアントにこの時間も工数に入っていますよとアピールするのは良いかもしれない。

雑務

作業に入る時や作業を中断する時、環境を整備したり、アカウント情報を探したりするようなこまごました時間は必ず発生してくる。 実装時間のみで見積もってしまうとこういう小さい時間の積み重ねで結局見積もり時間をオーバーしてしまうことがよくある。 少ない時間だが必ず発生してくる時間なので必要な時間として考えておいたほうが良い。

不確定要素

不確定要素が多いと追加機能の実装が必要になったり仕様の変更が必要になったりするため、不確定要素が多い案件には大幅に工数を乗っけておく必要がある。

バッファ

工程ではないが、実装やテストの予備時間として必要な時間。 現実ベースで見積もったとしても、ほとんどの場合は想定を超えてくることがほとんど。 そんなに掛かるはずないだろと思っても、勇気を持って多めに取っておいたほうが良いはず。全体の工数の2倍取っても良いかも。 見積もり書には含められないので他の作業にさりげなく混ぜておく。 ただ、多くとりすぎて高くなってしまい受注できない、もしくは早く作るだけの技術が足りないと思われるなどの問題との兼ね合いが難しいところ。
バッファの倍率は規模が大きくなるほど多く取るべき。10人日の開発なら1.2倍、20人日の開発なら1.5倍、60人日の開発なら2倍という感じで指数関数的に多く取るほうが良さそう。大きくなるほど想定外の可能性が高くなる。

見積もりに必ず入れる工数

デザイン工数

デザインを作らないで進めると画面が出来たときにイメージと違う問題に必ず遭遇する。
なので、デザインを作って合意を取ってから開発に入るほうが間違いない。
そのためのデザイン工数は必ず入れておくこと。

管理画面のユーザー管理画面作成工数

管理画面を作ることになればユーザー管理は必須になるため、必ず開発工数として含めておく。
たとえ簡易的な管理画面だとしてもパスワードの変更くらいは出来たほうが良い。パスワードが変更できないシステムを作るとパスワードを破られたときに言い訳が出来ない。

そのほか考えておくこと

ほとんど時間のかからない作業の見積もり

ほとんど修正が必要ないような簡単な修正を見積もる場合、雑務ややり取りに掛かる時間の方が大きくなってしまうことが多い。 そうなると見積もり金額が割高になってしまう。なので、赤字覚悟で安くするか他の作業と合わせて行うなどの考慮が必要になってくる。 基本的にあまりおいしくない仕事になることが多い。 赤字覚悟で安くするなら逆に無料にしたりして恩を売っておくとか、次につなげるような工夫をして無駄にならないようにしておく方が良い。 細かい作業が多いなら保守料を毎月貰うとかもいいかも。(逆に気軽にお願いされすぎて損するパターンもあるかもだが)

見積もりの方法

見積もりパターン

ある程度工数が分かりやすい依頼

自分の経験に基づいて工数を見積もる。 特に変な考慮はいらないはず。やり取り工数については要注意だが。。

やったことない作業で工数が分かりにくい依頼

ある程度は実際に作ってみたり、手を動かして調べてみるほうが良い。 受注にならなかった場合は作業時間が無駄になるが、ある程度の見積もり精度が無いと大きくオーバーしてしまった時が痛いのでその分の保険だと思って作業する。

Webシステムの場合

ページ数を算出する

ページ数毎に工数を算出する

機能数を算出する

機能数毎に工数を算出する

その他考えた見積もり方法

5パターンの見積もり時間を算出して適当な時間を採用する

以下の5パターンの見積もり時間を算出してバランスを見て時間を算出する。
・超希望的観測案 (初期時点での要件から変更なく、ほぼ詰まらず想定通りに進んだ場合)
・現実路線での最速案 (初期時点での要件から変更はないが、多少は詰まりやコミュニケーションが発生した場合)
・現実路線での通常案 (ある程度の要件変更があり、ある程度詰まりやコミュニケーションが発生した場合)
・現実路線での遅延案 (そこそこの要件変更があり、そこそこ詰まりやコミュニケーションが発生した場合)
・MAX遅延案 (要件変更であったり、なかなか解決できない問題が発生するなどして想定以上に時間が掛かった場合)

正しく見積もるために

見積もり時間を少なく見積もってしまう原因として考えられること

• タスクを洗い出し切れていない
• 顧客とのコミュニケーションコストや仕様変更リスクを考えていない
• スマホやタブレットでの表示調整の時間を考慮していない

見積もり時間を多く見積もってしまう原因として考えられること

• タスクを細かく分けすぎている(個々のタスクにはまとまった時間を当てることになるので必然的に工数が積みあがって多くなる)
• タスク同士で重なる作業を考慮していない(同じ作業が別のタスクで複数回カウントされてしまっている)

見積もり間違いを減らすための方法

• タスクを洗い出すためにある程度実装してみる(時間を掛けすぎずに見積もるコツを見極める必要あり)
• 顧客の特性を見極めて顧客係数を算定してそれを工数にかけ合わせる(顧客係数をかけることによってコミュニケーションコストや仕様変更コストを算出できるようにする)
• スマホやタブレットでの表示調整の時間を忘れず工数に含める
• タスクを細かく分けすぎない(丁度良い分け具合を覚える)
• タスク同士で重なる作業を削る工程を見積もり作業に含める

自分の工数感覚を把握しておく

タスクの見積もり工数を予想するときには、バッファを考慮しないつもりでも自然とバッファを含めた工数を予想していることが多い。
自分がナチュラルに予想した工数が実工数と比べてどんな感じなのかを見極めておくことによって更にバッファを載せる場合などに役に立つ。

参考記事

その外注は大丈夫？失敗しないLaravel開発会社の選び方
見積もりは難しい。いつまで経っても難しい。