エンジニアのための見積もり実践入門を読んでいて、ふと思いついたことを書く。
開発における見積もりは、なにを作るのか明確でないと不可能である。なにがいつまでにいくらでできるのか、を予測するのが見積もりなのだから、"なにが"の部分が曖昧糢糊としていたら予測もなにもない。
しかし、現実には表題のようなことを要求されることがままある。この場合どうすべきか？
無理なものは無理
一番まずいのは安請け合いであろう。「出来ます出来ます大丈夫です」といい加減に答えておいて、運よく工数が生返事の範囲内に収まっていればOK、収まらなかったらごまかす、というわけだが、いくらなんでもこれはない。不誠実であるし、モラルの問題を脇においても、もしプロジェクトが破綻すれば――おそらく破綻する。システム開発は発注者と開発者の二人三脚である。開発者だけが孤軍奮闘したところで成功は期待できない――経済的な被害が発注者・受注者ともに大きく発生しかねない。
といって無理なものは無理である。そのため、なぜこんな無茶を言い出しているのか、言い出しっぺである発注者に聞いて深堀していかねばならないだろう。それが仕事に対する職業人として誠実な態度であると思う。単に軽い気持ちで言ってみただけであれば、発注者側も問題を起こしたいわけではないだろうから、話し合いに応じてくれるはずだ。その先に解決策があるかもしれない。
例えば、予算が先に決まっているのでその範囲内で形になるものを作りたいと思っているのであれば、予算内にちゃんと収まる規模での提案ができないか探る手がある。なにもかもがよくわからない、ということであれば、まず調査から入るべきだろう。状況によっては、スケジュールを引くのがそもそも難しいとして、準委任契約＋アジャイル式で進めることも、あるいは可能かもしれない。
話し合いができないケース――「うるせえ、良いからやれよ！」――にどう対応するか？
しかし世の中すべてスムーズに動けば世話がないわけで、時には発注者が自分の立場の強さ――勘違いかもしれないが――を悪用し、リスクをすべて被るよう受注者に強要することもあろう。これをやられると、受注者側としては恐怖に負けて安請け合いしたくなるかもしれない。
しかしこの場合でも、やはり安請け合いは不味い。理由は先述の通りで、同じだ。その場しのぎをすれば後で首を絞められる――もしかすると死に至るほど絞められるかもしれない。残念ながら、こういうケースではお取引を断念することも視野に入れることになろう。
いかに見積もり作業をリードするか
不味い発注者も中にはいないわけではないが、しかし大抵の場合、どうすれば妥当と言えるのかがよくわからないので易きに流れているだけ――どこに流れ着くかわかったものではないが――と考えられる。そのため、受注者としては、発注者が不慣れそうなら提案や見積もり作業のワークフローをうまくリードできるよう動くのがよいだろう。リードするのにもコストがかかるので――やりとりが打ち合わせが増える――費用対効果も考えるべきだが、慣れた発注者としか付き合わないと決め打つのは選択肢を狭めすぎるのではないか。
理想的な発注者などそうはいない。受注側だって、"自分は理想的な受注者だ"とはなかなか言えないだろう。お互い様である。システム開発は発注者と開発者の二人三脚、うまく協力したいものである。
