計測していなければ見積もれませんし、無理な工期短縮を断れません

この記事を電車の中で読んだとき、正直、こんなことをされてはプロジェクトマネージャやってられないなーと思いました。

ブコメでどんな反応なのだろうかと思って見たら、過去に酷い経験をされたエンジニアが多いようで人気のあるブコメを読めばこの記事を読んで共感するところがあるのもわかるような気になって来て、そうかこれ立場の違いで受け取られ方が違う記事だわ、と思ったのでした。まる

でもですねぇ、ある程度の精度で見積もれるのはその作業をするエンジニアなのでエンジニアが記事の対応をするとちょっとあなたの技術レベルって大したことないじゃん、と思えなくもないんですよ。全体的に無理な工期短縮がある前提だったり、そんなもの進めて見ないとコードなんて書けないと言っているのですけれどね、コードのアプローチまでは慎重に進めさせてよと言っている割にコードのバッファを倍で申告するとかどれだけ自分の余裕を確保したいのかなーと。それ、仕様を決めるスキルかコードを書くスキルがもっと頑張ろうな状態なんじゃないのかしら。

立場が違えば好き勝手をいう

まず、立場が違うのであればそれぞれの分掌に基づいて事情があることは認めましょう。そうしないとエンジニアの立場も事情も汲んでもらえません。お互いの存在意義を理解することが現代の分業している事業構造から予め知っておかなければならないことです。

精度の高い見積もりはできません

はっきり言えば、ソフトウエアのコードの見積もりなんて精度高くできるものではありません。なぜなら、1つのプログラムとして同じコードは存在しないからです。複数のエンジニアに同じ仕様のプログラムを作ってもらったら実装はそのエンジニアが経験した知識を背景にコードとして具現化されるのですから。

仕様も依頼元の顧客の業務要件が何一つとして同じものはありません。つまり、プログラムの入力もプロセスも違うのだからアウトプットも違ってくるということです。

何一つ同じものがないのにどうして精度の高い見積もりができると思うのでしょうか。

根拠のロジックを組み立てる

それでも一番精度の高い見積もりが可能な立ち位置にいるのがプログラムを作るエンジニアです。

引用しているエントリを見る限り、見積もり対象範囲、つまり見積もりとしてどのような作業をするかや、作業で見積もろうとしている実現するプログラムの仕様をコードに変換するまでの仕様の詳細化をプログラムに変換できるところまで進めないとコードの見積もりはできないよ、と言っているように読めます。

これはごもっともなのですが、それを倍のバッファをとったりとと手段が悪手に感じざるを得ないです。

エンジニアとしては想定している作業と根拠のある想定工数を算出して、それを整理して説明しなければ仕事を依頼する側は理解すらできません。

そのためにも、想定工数の算出根拠、ロジックを持って見積もりをする習慣が必要です。

見積もりの基本は計測から

では無理な工期短縮を断り、エンジニアとして必要な工数を確保するためにどうしたらいいか、です。

まずは、テストが完了したコードに到るまでの作業を可視化することです。これは自分がわかっていればいいです。なぜなら、見積もりをするための計測する対象の作業だから。人に見せるつもりなら、理解して欲しいように整理はしておく必要があるでしょう。

その上で、実工数とアウトプットした実績値を記録します。とにかく、記録することを続けることが必要です。エンジニア自身があアウトプットできる量はエンジニア氏から知らないのですから。

根拠がなければ言い値の工数に合わせるだけ

もし、見積もり根拠となるロジックと実績値を持っていなければどうなるでしょうか。

依頼する側に押し切られて言い値の工数の期間に収まるように残業をするか、見積もったバッファばかりの期間を全部使い切ってしまうかです。これはどちらも好ましいことではないです。

やはり、ある程度の精度の見積もり＋プロジェクトのバッファで見積もりは考えたいですし、実行したい。そうしないといつまでたっても終わらないプロジェクトになるか見積もり金額の倍のプロジェクトになってしまうから。そうしたプロジェクトに参画すること自体、エンジニアとしてはかなり辛いことだと思うんですよ。