本日のセール商品 闇株新聞編集部『闇株新聞 the book』
☆評価が、9件のカスタマーレビューで5つ星のうち 4.4ですね。評価母数は少ないけれど高いですね。
人気ブログ「闇株新聞」の書籍化らしいです。
エンジニアは出来高を客観的な視点で確からしさを証明できないのだから生産性を求めるのはおかしい
それ、計画時に出来高計れます?
生産性とは計画経済の中の話だと思うんだよね。「ある期間にこれだけ作ろう!」って話。プロジェクトである期間で「プログラムをn本作ろう!」ってことです。なので、労働集約型の作業なわけで。
キーワードは、“ある期間”、“出来高”。これだけ指標が揃っていれば、あとは生産する設備の数をどうするかって話です。プログラムはまだまだエンジニアが作らないと業務ロジックを入れられないので生産設備=エンジニアなわけで。で、予算でそれだけ生産設備であるエンジニアを投入できるかで計画時の出来高が見積もりできるんですよ。
エンジニアのスペックは誰も知らない
モノづくりの生産設備なら機械なのでその機械自体の品質にそった出来高の標準値があって、その出来高の幅も中心値から±の幅の中で資材を入れ続け、稼働し続ける限り生産されるんです。これ、誰でも理解できますね。
厄介なのは、エンジニアの出来高は、その一人一人のエンジニアのスペックとしてラベリングも認定もされていないってことです。つまり、エンジニアは成果物を生産するのにその出来高が客観的に見えないわけです。
大体、出来高っていう言葉自体、なんか、フィーリングですが「これだけ出来ちゃいました……。」ってニュアンスありません?計画して作った、というより、偶発的に出来ちゃった、って。
ものすごくできるエンジニアだって、気分が乗ればいつも以上のコードを書くし、悩みがあれば途端に書けなくなるし。だから平均値なんでしょ、っていっても、それってどこから持ってくるのとか、それが自分たちのホントの出来高と一致しているの、とか“確からしさ”って継続したメトリクスの収集をしない限り誰も自信を持って言えないですよねぇ。
視覚化できないものは計れないけれど無理やりはめても無理がある
消費財のように工場の流れ作業で手順化され、一つの生産物を製造する時間計測をできる作業は標準時間を設定できるので、時間当たりの出来高が客観的にも視覚化できるんですね。だから、多く作る計画を立てるならそれに見合った設備なり手順の改善なりで要求に見合った出来高を得られるための活動が取れるわけです。
では、プログラムはどうか、って話です。設計書でもいいです。プログラムならプログラムの本数、設計書ならページ数。ITプロジェクトも「ソフトウェアエンジニアリングなんだから」と言うなら、そうした計測できるものを当てはめて考えるんですね。そこがおかしいんじゃないかって。
出来上がるものを計画時にスペックからバッチリ決めて計画的にできるんでしたっけ?ソフトウェア開発って。そうならないからプロジェクトマネージャは苦労してるんでしょう。スペックが決まっていないからエンジニアは残業しちゃってるんでしょう。
確かに、見積もりするとき、成果物単位で“何ページ作る想定にする”とか“100ステップのスクリプトをn本作るだろう”とかで見積もるものです。でないと、工程と人の道幅の妥当性が“類推見積もり”で判断できないから。
それで見積もれば見積もったで、プロジェクトの計画でWBSを展開するときのインプットデータにしますよね。で、成果物を分解してドキュメントなら章節項とかにバラして出来だかと予実の較差を計って計画とつじつまを合わせるように調整するわけで。
で、そのロジックに生産性というキーワードを持ってくる意味あるの?って思うんですよ。大体、プロジェクトごとに生産設備であるエンジニアが入れ替わるし、エンジニアごとの出来高なんて誰も言えないですもんね。計測していないから。
なので、生産性という言葉を聞くと、「眉唾だなぁ……。」って思うんです。