クリエイティブな仕事は工数管理が難しい

プログラミングや、HTMLコーディングの際によく聞く工数管理ですが、実は私は、クリエイティブな仕事においては工数管理というものは、とても難しいと考えております。

工数が見えない

プログラミング・コーディングと言えば、すでに出来上がった仕様書やデザインを、ソースコードに書き起こす仕事と思われるかもしれませんが、そのソースコードを考え出す事自体が、単純な作業ではないため、作業にかかる工数が見えてこないのが現実です。

ソースコードを書く作業は、解決方法は無限にあり、同じ結果を目指していても、全く異なるソースコードが出来上がる事もあります。
むしろ「書く作業」という言葉すら相応しくなく、これ自体が思考を要する仕事です。

なので、作りたい物の仕様やデザインを把握しても、既存の環境を確認したり、それを実現する手段が明確でなければ、その時点でかかる工数を割り出す事は不可能であり、もはや予言に近いのです。

クリエイティブな仕事とは相性の悪い人月・人工

現在でも未だに使われている「人月（にんげつ）」「人工（にんく）」という工数管理の方法ですが、ハッキリ言ってこれはクリエイティブな仕事と相性が最悪な管理方法です。
もちろん、思考を要するソースコード制作においても同様です。

人月や人工とは、要は何人いればどのぐらいで仕上がるかとか、1人が1日にどれぐらいの作業を行えるかの指標です。
つまり、人が多ければ作業が早くなったり、1人あたりが可能な仕事量の可視化というわけですね。

例えば、部屋に家具を配置する作業であれば、人数が多いほど作業は早く終わりますが、プログラミングやコーディングの場合、1ファイルを複数人で更新する事など不可能であり、ファイルを分割して複数人で作業するにしても、平行して作業する人のコードと噛み合う作りに出来るかという問題が発生します。

Webサイト制作に例えれば、HTMLとCSSを書く人に分けたとしても、CSSを書く人はHTML構造を把握した上で制作する必要がありますし、HTMLを書く人もCSSを書く人に気を使って作業を行う必要があります。
そうなると、過剰なコミュニケーションが発生する事となり、二人羽織でやっているだけで、実質1人で作業するのと変わらない状況になります。

また、2人に同じ作業を割り当てれば、たとえシフト制で交代が発生しても、次の人が前の人が書いたコードの続きを書いてくれるであろうと考えるかもしれませんが、これも大きな間違いです。
次の人は、前の人の書いたコードを解析する必要がありますし、解析したうえで、どのような処理で書きかけの時点で値をどのように流しているかを把握したうえで、続きのコードを書く必要があります。
ただコードを継ぎ足して済む話ではありません。

作業時間の圧迫

1人が1日に、どれだけの作業が出来るかを可視化し、それを基準に工期を決定するという事は、工期の圧迫の要因にもなりえます。

先述の通り、プログラミングやコーディングは仕様やデザインによって、書くべきコードは大きく変化します。
ゆえに一度実績があるからと言って、過去の工数がそのまま別の案件に適用できるものではありません。

また、工数を管理する目的の多くは、金額の見積や納期の決定です。
顧客としては、安く早い方が当然いいわけであり、その要望に答えようとすると、可視化できている1人の工数から最短工期を計算してしまうでしょう。
そして価格も安いと、他の案件も高速で裁いて、数を稼がなくては利益も得られません。

40年以上前からも言われていた事

「人月の神話」を聞いた事がありますでしょうか。
フレデリック・ブルックス氏が執筆した書籍であり、ソフトウェアエンジニアリングが人を増やしただけでは解決しないなどの事が書かれています。
そしてこの書籍が発行されたのが、1975年。40年以上も昔から発行されています（もうすぐ50年以上になろうとしていますが）。
本自体は読まなくても、その大まかな概要を知る事ができ、それでも充分に人月の問題点が理解できます。

つまり、人月との相性の悪さは、40年以上前にも言われていた事であり、日本は未だに人月・人工という問題のある方法が採用されてきたという事になります。

作業者ががんばってきただけ

今まで人月計算で行ってきて、それでうまくいってきたと思うかもしれませんが、本当はうまくいっていたというよりも、問題のある方法だけど、なんとかがんばってきただけだと思います。
日本は残念ながら、苦労が美徳、今までに行ってきた方法が正解であり、それを曲げない風潮があるように思います。
しかし、それでも上層が決めた事に下流工程の人は立場上指摘する事が出来ず、泣く泣くがんばってきただけではないのかと。

本当は人を増やせば解決する問題でもなく、ギリギリの工期で密かに残業もしながらも、なんとか期日に間に合わせてきたのではないかと思います。

必要なのは工数管理ではなく余裕のある納期設定

プログラミングやコーディングは、ただ書くだけの単純作業ではなく、書くコードの行数はもちろん、組むべきロジックもその時点では予想すらできないため、ハッキリ言って工数管理は不可能な業種です。

しかし、工数を管理して、カツカツなスケジュールを組むのではなく、逆に余裕のある納期を設定するべきです。
HTMLコーディングの場合、最低でも2週間は欲しい所で、特にWordPressで特殊な記事の出力などもやっていたら、ましてや5日程度では到底間に合いません。

作業者に工数を算出させて見積りをするのは、現実的ではありません。
なにしろ、どのようなコードを書くのかなど、その時点で決まっていないからです。
それだけでなく、コードを書いても、それで正常に動くとは限らず、自分の書いたコードでも原因の調査には意外と時間を要するため、試行錯誤の時間も必要になります。
なので、月単位の余裕を持った納期を設定し、その期間に出来る事をやるようにすればいいのです。
最低でも完成を目指し、そして余った時間で、さらなる質の向上や、新しいアイデアを盛り込むなどをすればいいのです。

お客様からすれば、「早い！安い！」がいいかもしれませんが、ハッキリ言ってそれで「うまい！」は付いてきません。
なので、そこはお客様にもご納得していただき、充分な納期と、最短工期にはない付加価値も提供し、決して安売りしない事が重要でしょう。