[見積もり編] 請負契約で仕事をする際に失敗したこと
みなさん請負案件やっていますか？
昨今はアジャイルの台頭もあり、スクラム、エクストリーム・プログラミングなどのフレームワークを利用してプロジェクトを進めたいという要望もよく聞きます。
ただ、そんな中でまだまだ請負契約でのアプリケーション開発プロジェクトがたくさんあるのも事実だと思います。
そんな請負契約でのアプリケーション開発で失敗したことと、それに対する改善案を自分への戒めとして残します。
今回は「見積もり」についてです。
実際の失敗談に辿り着くまで前説が多いですがご容赦ください。
そもそも見積もりとは？
「各タスクにかかる工数を考えること」という認識です。
この記事での見積もりスコープについて
以下のイメージで記載しています
- 請負プロジェクトの要件定義や設計が終わったタイミング、または後半の見積もり
- 要件定義は準委任でやることが多いため
- マスタスケジュールを元に、体制を考えたりスケジュールを詳細にしたりするための見積もり
なぜ見積もるのか？
プロジェクトは以下の3項目のバランスで進行しますが、その上で特にスケジュールとコストに強く関わる情報なので見積もります。当然必須ですよね。
- スケジュール
- コスト
- 品質
どう見積もるのか？
あくまで最近の自分のやり方で、もっと良い方法はたくさんあると思います。
- プロジェクトで必要な機能または画面の一覧を作成する
- 一覧の各行で実施すべきタスク一覧を作成する
- 例えば設計、実装、テストなど
- 一覧にないタスク一覧を作成する
- 例えば非機能要件に関わるものや管理工数など
- 上記を表にして、工数を考える ※ ここの手法はたくさんあるので難しい…
工数を考える方法
- 経験を元に、、、（レビューしてもらい、複数人の経験則に従った見積もりにする）
- 根拠が薄く、良くないパターンですがいつもやってしまいます…
- 過去のプロジェクトのデータを元に考える
- データを残していれば、かなり有効だと思います
- 当時のプロジェクトよりも◯◯ほど複雑なので、当時かかった工数の1.2倍を見積もる。など
- アジャイル系の見積もり手法（ここでは割愛します）
失敗したこと
ようやく本題です。
大きく以下の３つが失敗として印象に残っています。
- 前提の合意がないまま見積もる（既存踏襲という言葉には要注意！！）
- 画面一覧を機能一覧として見積もる
一覧の各行で実施すべきタスク一覧を作成するの作業時に漏れがある
前提の合意がないまま見積もる
一番大きく見積もりがぶれてしまうところだと思います。
以下のようなことを経験しました。
- お客さんんは既存踏襲でやってほしいが、開発側はその意識がなかった
- スコープの定義が曖昧だった
特に１つ目が辛いです。
そもそも既存踏襲と簡単に言われますが、既存踏襲の言葉の通り元のシステムと全く同じロジックを組むのはよほど元システムに理解度があるか、充実した設計書がないと難易度が高いです。
その工数がかかる既存踏襲という前提がないままに少なく工数見積もりをしてかなり痛い目を見ました。（更に既存踏襲＋「機能追加、機能改善」がついていたのです…）
当然設計は遅れ、開発は遅れ、テストは遅れ、品質は低下し、納期にも遅れ、メンバーのメンタルも傷つく。といったとんでもない状況に陥ります。
スコープの定義が曖昧だったというのは後述の 画面一覧を機能一覧として見積もる で詳細を述べます。
画面一覧を機能一覧として見積もる
- システムへの理解度が低いと発生しやすい
- 画面一覧だと、その画面の中にどれだけ複雑な機能が入っているかが予測出来ないことが多い
- ただし、もとから画面一覧に対する見積もりとして、大きく見積もっていれば問題ない
そんなこと気づけよ！って話なんですが、意外と難しいので足をすくわれがちなのかな？と思っています。
自分の経験だと、「画面一覧」なのに「機能一覧」と名前をつけて管理されており、その画面の中にある複雑さに気づかないまま見積もってしまったことがあります。
そんな画面一覧の項目名にも〇〇一覧機能とあって、リソースのindexがあるだけなのかと思いきや、実際はCSVダウンロードがあったり、一覧のソートがあったりしました。
indexだけなのかと思い見積もったのに、CSVダウンロードやソートがあったら当然見積もりはぶれますよね…
これでまた設計、開発、テストが圧迫されて痛い目を見ました…orz
一覧の各行で実施すべきタスク一覧を作成するの作業時に漏れがある
これは単純な話で、よく失敗してしまうのがレビュー工数の想定がなかったり、レビュー後やテスト後の再修正の考慮が漏れていたりすることを指しています。
失敗したことに対する改善策
- 見積もりを行う際は必ず前提を記述する
- 既存踏襲するしない
- スコープはどこからどこまでで、何をやって何をやらないか（画面一覧に書いてあることはやる。等）
- できるだけ細かい粒度のタスク一覧を元に見積もる
- 画面一覧だと荒く、見積もりがブレやすい
- できれば以下の形式が望ましい
〇〇一覧画面
- 一覧表示
- CSVダウンロード
- ソート
〇〇作成画面
- リアルタイムバリデーション
- CSV一括登録- 見積もりを作る項目はどの案件でもそこまでテンプレートを作っておく
終わりに
以上、改善策があっさりしてしまいましたが見積もりの失敗とその改善策の備忘録でした。
良い請負プロジェクトライフを！
