工数をパズルのように埋め、おおざっぱに管理する

最初に入った受託開発をメインにした会社は工数管理がしっかりしていた。
案件に工番（こうばん）または製造番号（せいぞうばんごう）、製番（せいばん）と呼ばれる番号が割り振られて15分単位で時間をつけていた。
日立グループで作番（さくばん）と呼んでいるものとだいたい同じらしい。

僕のような若手は相互に差しさわりがあるということか、複数の案件に割り当てられることはなかった。
つまり、１人月の案件が 4/1 に始まると、4/30までは、日報にはその工番をつけて、それ以降はつけちゃいけないことになる。
そしてその工番で予実管理をした。
工数が予定より多くなってら怒られるんだが、少なくてもいやな顔をされた（見積もりの精度が悪いんじゃないかといわれた）

日報には、工番と合わせて、今やっている作業が「設計」「プログラム作成」「テスト」（さらに細かく分かれていた）の何をやっているかも書かないといけなかった。
おおざっぱに 1/3 づつくらいの工数にわかれてないと「おかしい」と言われるので
「んー、今やっている作業はなにかなー。設計にもプログラム作成にも見えるけど、今の工数の消費具合からいうと、プログラム作成につけておこうかなー」
とかやっていた。ほかの人がどうしていたか知らない。

途中、客先の仕様確認とかレビュー結果をもらうとか、結果待ちに時間が空いてしまうときがある。
ミーティングの日程だってこちらの都合だけで決められるわけではないので、ミーティングまでに時間が空いてしまう。
「んー、じゃあドキュメント整理の製番でもつけておくかなー」
と、そのときさほど必要でもないドキュメントを書いてたりしてた。

あの日報をつける時間は馬鹿にならなかったし、それを集計する課長の時間も馬鹿にならなかった。
日報を転記して週に一回の課長会議みたいなのをしてたようだったが、そのための資料作るの大変だったろうな。
課長は、売り上げに結びつかなくても許される伝家の宝刀「営業製番」99998 を付けられたが、僕は、めったなことではその製番を付けることはできなかった。
社内には、社内インフラを整備する工数が割り振られていた人もいたが、そういうのは売上が結びつかなくても怒られなかった。
一方で我々一般の兵隊は売り上げに結びつかない工番はつけられなかった。
僕が、社内インフラ整備とか書籍の執筆とかを仕事ですることに、いまだに抵抗があるのは、この頃の「売上に結びつかない仕事はしちゃだめ」と思っていたのを引きづっているのだと思う。三つ子の魂百まで。

いろいろ理由で、苦しかったし予定が遅れることはあっても早まることはなかった。
今思えば、予実があってないと怒られるのは、サービス残業の発生する温床だったんじゃなかろうか。
ここまでで読んでる人は気づいたと思うけど、実績としてつけていた工数はかなり予定に合わせていて真の実績とは離れていたと思う。
あの実績で振り返っていては全然現実が見えてないな。

僕は、その会社を辞めるまではソフトウェア業界って、みんなこんなふうに工数管理しているものと思っていた。
転職してみると、15分単位に日報をつけるのは例外的だと知った。

今は、臨機応変に、それこそパズルのピースを埋めるように時間の空いた人を埋めている。
それは、最初の会社では、もっとも忌み嫌われていた仕事のやり方だ。
（計画しても現実は計画通りに進まないという現実は無視して）
ころころ案件が変わるのは計画ができてないせいだし、案件が頻繁に変わるのはキャッチアップするのが大変だから。
今はお金については社長の「費用対効果」のひとことで解決だしプログラミング言語や仕事のやり方が同じになるように努力しているので、
案件が変わっても、キャッチアップは割とするできる。

会社が大きくなれば、もっとちゃんとした工数管理をしないといけないんだろう。
今のように、みんな仲良く性善説というわけにはいかないだろう。
最初の会社の詳細な工数管理自体は悪いことじゃなくて実態が悪かったのかもしれない。

どれがよくて正解っていうのはないけど、常識っていうのは会社によって違うから、みんなできるうちに一回は転職したほうがいいと思う。