工数という概念
エンジニア達が開発を進めるに当たってのスケジュール管理には、工数という概念が登場する。
工数とは「人日」や「人月」という単位が使われる。「一人が一日で終わらせる工程」は「一人日」、「二人が二日で終わらせる工程」は「四人日」という形で計算される。初見時には感覚的に分かりにくいかもしれないが、そこそこエンジニアとして経験を積んでいたブログ主も感覚的に難しいと感じてしまう。
そもそも一人が四日で終わらせる "つもり" で産出した「四人日」の工程は、四人でやれば一日で終わるのか？
結論として、これは終わらない。感覚的には、人数を倍にすれば全体的にかかる時間は半分になるように見えてしまう。これは工数という概念が生み出す大きな誤解である。
ここまで説明しても、「人数を倍にすれば開発期間は半分で済む」という自身の感覚を信じて止まない工数信者がいらっしゃるかもしれない。そのような方には名著『人月の神話』を呼んで欲しい。納期を短くしたいという願望を抱くのは自由だが、その手段として人員の追加を選択するのは愚の骨頂であることが分かって貰えるはずだ。
さて、そんな工数の管理は（現場にもよるのだろうが）エンジニアに任される。
ITエンジニアはただコード書いていれば良い職業ではない。品質の担保からスケジュール管理まで担うマルチタスクが求められる職業なのだ。むしろ "楽" と断言できるくらいには、コードを書くだけならば誰にだって出来る。問題は、そのコードを「納期に間に合わせること」である。
しかも「バグがないこと」を担保しつつ、だ。
これらの両立をあら得られた工数という概念に当てはめて管理することが求められる。これが苦痛で苦痛で……。
人数が増えると仕事は増える
設計・開発の工程を細分化していくと、その大半が他者とのコミュニケーションによるものだと気付かされる。このコミュニケーションを認識齟齬なく進める手間というのは、想像以上にストレスと手間がかかる。
ここをストレスを感じず、手間とも思わない人間が、きっと昇進していくのだと思う。
残念なことにそんな昇進を約束された強者側の感覚は理解できない。他者とのコミュニケーションを円滑に進めようと努力はするが、少なからずミスはするし、認識齟齬は起きてしまうものだ。悔しいが、そのことは下手な自信は持たないように自覚しようと努めている。
これらコミュニケーションによって発生する手間は、工数には反映されにくい。なにせ案件に関われば増えるはずなのに、工数という概念によれば「人数が増えれば、工程にかかる時間は減る」のだから、この時点で考え方として破綻している。
本来、人数が増えれば増えるほど、説明や教育のための時間と労力、情報を共有するための時間と労力……それらは決して手を抜いてはいけない重要なタスクが追加で発生するということを認識しておかなければいけない。
それでもエンジニアは工数という概念を用いてスケジュールを管理する。おそらく理由は、工数に変わる概念が存在しないから。暇な時は工数という概念に変わるものを考えているのだが、どうしても上手くいかないものだ。
「コロンブスの卵」的に「最初に言った人が凄い」ことを言ってみたい……そう思う今日この頃だ。
