プログラミング初学者のための本というのは充実してきているし、自分自身初学者でもない（初学者のつもりで学ぶ姿勢は大事だとしてもだ）ここいらで、チームでの仕事の進め方と、特にタイピングが速いわけでもない僕が即席チームにひょっこり入って仕事を回せる理由とその方法を書いてみる。すごく簡単で当たり前だと思っているけれど、実はやっている人は少なくて、また少ないながらに見つけた同じことをしている人がプロジェクトを上手に回しているから、書いてみようと思う。
よくある会社の月初作業に勤務表とか勤怠表というものがある。タイムカードと同じような事だ。誰が何時に出社して何時に帰ったか。そうすると何時間働いたか分かる。工場のように決まりきった仕事を淡々とこなす上で何時間働いたかはモノをどのくらいこしらえたかの指標とピッタリ合う。プログラムもデータベースに対するテーブルの打ち込みのような仕事であれば定量的に時間で仕事量を量る事が出来る。
しかし、新規プログラムシステムの開発となると、誰が何をどのくらいやっているか、なかなか分からないものである。机についていたら仕事をしているように見えるし、自己申告で勤怠に作業内容を書いても、それをどうやって検品するかというようなことがノウハウ化されていない。
プログラムの作成度を測るために組んだステップ数を測るという方法があるが、たいていこの方法で検品しようとすると管理部にプリンターで刷られた意味不明のソースコードの冊子が送られてその厚みに満足して結局動くものが出来上がらないということが起こる。
プログラムは動く状態で作成作業を進めなければならないと言うのが持論だ。何時までに動くから、その間は開発中で動かないというのを年間単位で認めてしまうと、動かないまま納期や締切が来てしまうというリスクが増大する。それを防ぐために試作期間を設けて検品するも、試作機がまともに動かないと言う事もよくある事だ。ボトムアップ開発が下位部品の制作者に依存してしまうのであれば、トップダウン開発で未完成部分は作動しなくとも他の部位と連動するダミー部品を当て嵌めることで見かけ上の動作をさせなければならない。
そして、作動する状態のプログラムを毎日ソース管理する。サブバージョン（SubVersion, WinCVS, MicrosoftVisuaiSourceSafe などなど何でも良い）で動作する状態を毎日監視して、動作しなくなるとそこで作業を止めて原因究明をする。そして、５人１０人の仕事であれば管理者がバージョンごとに誰がソースコードを何行触ったかソフトで監視する。これは毎日必ず全員分チェックする。そうすることで、実働時間中に真に誰がプログラムの決定権を握っているか把握出来るし、目に見える仕事をしていない人が誰かもすぐ分かる。目に見える仕事でなくとも何らかの仕事をしている場合と、単に遊んだり寝たりしている、悩んでいるなど、停滞がすぐに分かる。
このように、管理者が真に管理を実行する際は人の動きを後ろから見るよりもプログラムを内部から監視する必要がある。
この方法で上手く行かないケースもある。特に管理者より年長者が多いと仕事をしていないことを指摘しても動いてくれないケース。こればかりは暴力でも使わないとどうしようもない。また、先日の京都のケース。管理する以上に開発がどんどん進んでバージョン管理ソフトでその変遷の差分を読み取りきれない。これで動くものが出来れば万歳なのだが、残念な部分もあった。
ガントチャートなどで管理を目論む人がいたとして、それもプロジェクトの新香を願って決して悪意でなく管理をしようとしての試みだとしよう。しかし、それよりもソースをコンパイルして動く状態に常に保つこと、そして変更が加えられた時にそれが誰の名義で、どのような変更なのか常に把握すること。止まっているスタッフは誰か、止まっている理由は何かもソースから糸口をつかめる。サブバージョンの使い方を管理者が覚えること、覚えている人を管理者にまわすこと、どちらでもいい。トップダウン式なら完成をまたずして何らかの動作をするダミーを用意すること。
プログラムを組む以外で僕が他の人と違う仕事をしているとすると、そのくらいだ。全員分見比べる根気があったら、きっとうまくいく。上手く行くことを祈る。
