項目 | 説明 |
---|---|
依頼者や見積もり会議参加者の役職と業務はなにか? | システムを誰が使うのかを把握したり、システムのイメージを理解してくれやすい人が誰かを見極めるために把握したい。 できれば会議の雑談等でさりげなく聞いておく。それが出来なければ会議の中で聞く。 |
システムを実際に使う人間はだれか? | やはり実際に使う人間の意見が強いため把握しておきたい。 依頼者や見積もり会議参加者の中に含まれていれば聞きやすいし、含まれていなければ別途ヒアリングさせていただくか想像で補う。 複数人が利用するか、役割や権限の違う人間が利用するかは重要。 |
システム化しようとしている業務を現状どのように運用しているか? | 依頼者は、システム化すれば便利になるというイメージだけを持っていることがあり、業務の置き換えを明確にイメージできていない場合が多い。 なので、現状の業務とシステム化したい範囲の業務を聞き出し、どのように現在の業務が変わるかを仮で作ってみて先方に見てもらい、業務がどう置き換わるかを明確にイメージしてもらう必要がある。 誰がシステムのどの機能をどう扱うか?という点が肝になる。 |
いつまでに必要か? | 期限が特にないなら問題ないが、期限が決まっているなら見積もりや設計にも影響する。 |
以下の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倍という感じで指数関数的に多く取るほうが良さそう。大きくなるほど想定外の可能性が高くなる。
デザインを作らないで進めると画面が出来たときにイメージと違う問題に必ず遭遇する。
なので、デザインを作って合意を取ってから開発に入るほうが間違いない。
そのためのデザイン工数は必ず入れておくこと。
管理画面を作ることになればユーザー管理は必須になるため、必ず開発工数として含めておく。
たとえ簡易的な管理画面だとしてもパスワードの変更くらいは出来たほうが良い。パスワードが変更できないシステムを作るとパスワードを破られたときに言い訳が出来ない。
ほとんど修正が必要ないような簡単な修正を見積もる場合、雑務ややり取りに掛かる時間の方が大きくなってしまうことが多い。 そうなると見積もり金額が割高になってしまう。なので、赤字覚悟で安くするか他の作業と合わせて行うなどの考慮が必要になってくる。 基本的にあまりおいしくない仕事になることが多い。 赤字覚悟で安くするなら逆に無料にしたりして恩を売っておくとか、次につなげるような工夫をして無駄にならないようにしておく方が良い。 細かい作業が多いなら保守料を毎月貰うとかもいいかも。(逆に気軽にお願いされすぎて損するパターンもあるかもだが)
自分の経験に基づいて工数を見積もる。 特に変な考慮はいらないはず。やり取り工数については要注意だが。。
ある程度は実際に作ってみたり、手を動かして調べてみるほうが良い。 受注にならなかった場合は作業時間が無駄になるが、ある程度の見積もり精度が無いと大きくオーバーしてしまった時が痛いのでその分の保険だと思って作業する。
ページ数毎に工数を算出する
機能数毎に工数を算出する
以下の5パターンの見積もり時間を算出してバランスを見て時間を算出する。
・超希望的観測案 (初期時点での要件から変更なく、ほぼ詰まらず想定通りに進んだ場合)
・現実路線での最速案 (初期時点での要件から変更はないが、多少は詰まりやコミュニケーションが発生した場合)
・現実路線での通常案 (ある程度の要件変更があり、ある程度詰まりやコミュニケーションが発生した場合)
・現実路線での遅延案 (そこそこの要件変更があり、そこそこ詰まりやコミュニケーションが発生した場合)
・MAX遅延案 (要件変更であったり、なかなか解決できない問題が発生するなどして想定以上に時間が掛かった場合)
タスクの見積もり工数を予想するときには、バッファを考慮しないつもりでも自然とバッファを含めた工数を予想していることが多い。
自分がナチュラルに予想した工数が実工数と比べてどんな感じなのかを見極めておくことによって更にバッファを載せる場合などに役に立つ。