最終的にこうしたいので宜しくー漠然とした要求から見積もるー

きっかけ

お客様からざっくりとした要件の提示と見積もり依頼がありました。

作業内容

いつ、何をしたいのかというような具体的な業務イメージもまだなく、実現したい最終的な形だけをお客様から提示していただいた状態で見積もり依頼をいただきました。
つまり業務フローから考えていく必要のある案件でした。
まず、どうしたいのかというお客様の要件の理解ができなかったため、有識者から説明を受け、大枠を理解しました。
有識者の頭の中にはざっくりとした改修案がありましたが、その意図はあまり理解できなかったので、案の実現に必要な要素(DBレイアウト、業務フロー、他サブシステムへのインターフェース仕様など)を揃えながら、曖昧だった疑問点を明確にしていきました。
明確になってきた疑問点について有識者に改めて質問し、自分なりの考えを提案しました。
疑問点を洗いだしてから質問、提案をすることで、各々の改修案のメリット・デメリット、影響範囲、影響箇所への対処方法など具体的なところまでどんどん話が広がっていきました。

開発規模については既存の似たような機能をもつモジュールからステップ数を算出し、工数についてはプロジェクト内で使用されているステップ数に対する工数の目安マトリクスを使用し、換算ました。

レビュー

この案件はまだ見積もり第一弾、という位置づけで、お客様としては「こんなことしたいんだけどどれくらいお金がかかるのかな〜」というレベルのものでした。
それに対して、私が出した見積もりの内容は細かすぎると指摘がありました。
もっとざっくり、だいたいこれくらいの工数がかかりますよ〜ということが分かればよかったのです。
開発規模の見積についても、100Step単位で算出してくれればいいし、改修内容の細かいところについてもまだ今の段階では不要で、もうひとつ上位のレベルで検討して欲しいと言われました。
しかしこのレベルまで検討が出来ているなら、メリット・デメリットを明確にして、改修内容のレベルに応じて改修案を２つ提案してもよいかもしれないとも言われました。

確かに、おおよその工数を知るには細かすぎる見積もりだったかもしれません。
しかしそのレベルの粒度で考えていなければ、私には工数の算出ができなかったようにも思います。
感覚的にこの画面数ならこれくらいだとか、このバッチ処理ならこれくらいだろうなとか、そういう経験ベースのものさしは私にはないのです。

振り返ってみればわかりますが、見積もり着手時点でリーダーやプロマネからどれくらいのことを要求されているのかははっきりとわかっていなかったと思います。
どのくらいの成果物を出せばよいのか、そのさじ加減を決めるにはある程度の経験が必要な気もしました(「さじ加減がわからない」という私に、リーダーは「この業界、明確な根拠や理論も必要だけど、感覚って結構大事だよ」というコメントをくれました)。
また、「もうひとつ上位のレベルで記載」というのは当然、雑な仕事をしていいというわけではなくて、その程度の粗さでいいよということだと解釈しています。
要点を、要求レベルに合わせてアウトプットしていくことの難しさを感じました。