勉強不足なことは無茶振りする

ブコメした見積もりのエントリのテーマを取り上げようと思っていたのですが、もしかしたら読み違いもあるかと思ってそのエントリを読み直してみたらそんなこともなったのでどうしたものかと一旦棚にあげたらどうでもよくなったのでした。

多分、あの見積もりのエントリはプロダクト開発でいわゆるSIでのシステム開発じゃないんだろうなぁ、そう言ったこと（プロダクト開発）であることが暗黙にあるんだろうなぁ、と行間を読み始めていたら、もういいやと。その割には若干消化不良ですが。

あと、ブコメをちょびっと見たら思いの外共感しているエンジニアが多くてエンジニアのみなさん、見積もりに苦労しているんだなぁと思うなど。過去の見積もりのエントリが参考になればいいのだけれど。

見積もりから連想したこと

見積もりのエントリやブコメからこんなことを連想したんですね。営業やプロダクトマネージャがエンジニアに工数見積もり（ここでは仕様決めからリリースまでとします。これも見積もりのエントリでは曖昧）をしたとします。コードを作れるエンジニアは、コードを作るまでにあれこれとやることを思い浮かべながら、過去の類似の機能を参考にこのくらいならできるかもしれないと作業工数の数字を弾くわけです。

エンジニアが作業工数を見積もる時には見積もりを考えているときに認識している作業だけが見積もり対象の作業として工数を積み上げます。これ、とても大事です。

特に、営業やプロダクトマネージャ（顧客でもいいけれど）がカジュアルに工数の見積もりをしてきたときにエンジニアはその瞬間に思い浮かぶ作業だけを過去の経験から類推して近そうな数字を持ってきつつ、できるだろうと楽観値を出すんですよ。ここで悲観値を出すのは過去に見積もりで苦労して学習したエンジニアだけです。

一方、営業やプロダクトマネージャや顧客は見積もりの依頼元からの指値（金額もあるけれど期間の付帯条件がつく場合が多い）を実現性の精査もせずにそれがまるで変更できないルールのように無意識に思い込んで判断基準にしているんです。さらに営業やプロダクトマネージャの都合（自分の作業）を差っ引いたり、利益を積みたいとか様々な自己都合の分を先に控除した数字を持っているんです。機能しない営業などは顧客と交渉する術を持たないので言われたことをパススルーしてエンジニアにぶつけてくるからタチが悪いんですよ。

エンジニアも営業もプロダクトマネージャも知らないことは根拠がない

エンジニアはエンジニアで説明できる見積もりの根拠を示すことができない。

これは見積もり手法を知らないということと過去の実績を記録していないから起きることです。これはエンジニアが明らかに勉強不足です。もう1つは、見積もりするための対象となる見積もり対象の作業が記憶でやっていると本来は含めなければならない作業の見落としが発生するということです。

標準的な作業のテンプレートがあればいいのですし、直近のWBSがあればそれが作業プロセスになっているでしょうからその作業をやることを前提として工数を見積もるとしてもいいのです。つまり、見積もりで何が入っているかを可視化することが大事だよ、ということなんですが、頭の中だけで数字を積み上げようとすると100％漏れます。

営業やプロダクトマネージャはコードを書かないからプロダクトができるまでにどんな作業をするかは仔細まで知らないとどうしてエンジニアがいう工数が掛かるかが理解できない。

これもエンジニアの見積もり根拠を示せないと根っこは同じなんですが、どうしてその作業が必要かを理解しないと外からのバイアスが掛かった判断しかできなくなってしまうんです。これも勉強不足からくるものです。

依頼元はこのくらいの金額や期間でやりたいとリクエストがあったとしても、まずはエンジニアの作業は何をやってそれぞれの工数がどのくらい掛かるか、それの精度はどのくらいか情報を集めないと作ってもいないものの出来上がりを見通すなんてできないです。

解らないことを見なかったことにしてはいけない

見積もりとは明示的な作業を行うことの工数の算出です。エンジニアはなんの作業をするからこれだけの工数が掛かると明朗会計にする必要があるし、営業やプロダクトマネージャは、この作業したらどれだけの工数がコストとして掛かるかを訊ねなければいけないのです。

双方が勉強不足のままだと解らないことを見なかったことにしているだけでこういったことを放置していると無茶振りが横行するんですよ。

そうしたことをやっているからブコメのようなことが日常的に起きているんじゃないんでしょうかねぇ…。

そういうのが嫌で、アジャイル開発でプランニングポーカーをやったり、スプリント０をやったりするのは、具体的な作業を明らかにすることであったり、標準的なエンジニアがやったらどのくらいの工数が掛かるかを全員で精査したり、作業を遂行する上での暗黙の前提を明示化することだったりするんですよね。開発のタスクは誰がやるかはそのタイミングで自薦となるので自分がやったらどのくらいで前提は何でとはっきりしておかないと後で痛い目にあうし。

ていうか、これ読め。