エンジニアの方の”あるかもしれない”日常風景をデフォルメしてコメディタッチに描く本連載「エンジニアあるある」。さて、今回はどんな風景なのでしょうか...

☆☆☆☆☆☆

ソフトウェア開発の予算や見積もりでは「人月」という単位を使います。n人のエンジニアがnヶ月働くと完成するという工程数を見積もるためのものです。見積もりも、エンジニアの単価を人月に掛け算すれば出てくるのであちこちで便利に使われています。

しかし、これは元々土木工事の見積もり計算に使われていたものでした。大昔の土木工事は、土砂を運ぶのもネコグルマという人力中心だったので、この人月計算がうまくマッチしたのです。ソフトウェア開発も１人が１日3000行のソースコードを書けるとして、このソフトウェアは何百万行だから、◯人月と、見積もりとしてはかなり正確に計算ができます。

しかし、プロジェクトはそう簡単に進みません。膨大なコードをいったん破棄して、仕切り直しなどということもしばしば起こります。それでも人月計算で定められた納期は守らなければなりません。最近では、苦戦する開発案件が、クフ王のピラミッドの建設の推定値20万人月を超えたところから「クフ王越え」などと揶揄されたこともあります。

この人月計算は、エンジニアの労働環境を悪化させる原因になっていると批判されていますが、算出法自体は優れているため、プロジェクト開始前の大まかな見積もり計算にはいまだによく使われています。

しかし、非エンジニアの人は、この人月計算を勘違いしてしまいます。よくあるのが「プログラマーの人数を倍にするから、納期を半分に短縮してくれ」という無茶な注文です。確かに人月計算上は合っていますし、土木工事のように作業の標準化が進んでいる世界では昼夜二交代にすることで納期の短縮は不可能ではありません。でも、ソフトウェア開発では絶対に無理。それが理解されません。

しかし、一方で、なんらかのアクシデントがあって、エンジニアの数が半分になってしまったような崩壊寸前のプロジェクトでも、エンジニアたちはなんとか納期に仕上げてしまいます。これは奇跡のようなことで、エンジニアチームの超ファインプレーなのですが、非エンジニアには「やってみればできるじゃん！」と受け止められてしまうのかもしれません。エンジニアも、無理なものは無理とはっきり口にするようにしましょう。

自身に向いている職種を考える際には、客観的な視点も欠かせません。転職エージェントを利用して、プロ視点での向き不向きを無料で診断してみませんか？

(イラスト：ConChan)