たとえトラックにはねられても | 悪態のプログラマ

悪態のプログラマ

とある職業プログラマの悪態を綴る。
入門書が書かないプログラミングのための知識、会社の研修が教えないシステム開発業界の裏話は、新人プログラマや、これからプログラマを目指す人たちへのメッセージでもある。

プロジェクトリーダーのAさんが明日死んでしまったら、このプロジェクトはどうなるのだろう? ユーザー要件を一番把握しているB先輩が入院したら? 複雑な運用を1人で任されているC君が突然会社を辞めてしまったら?

そんな妄想をしてヒヤリとしたことはないだろうか?

システム開発に限らず、プロジェクトのチームでは、多かれ少なかれ、各メンバーで役割を分担しながら仕事を進めるものだろう。

しかし、仕事を完全な分業にしてしまうと、誰か1人でも欠けてしまったら、プロジェクトが止まってしまう。納期ギリギリにスケジュールされているような場合は致命的である。


そのプロジェクトから、何人のメンバーが欠けたらプロジェクトが止まってしまうか、という数字を「トラックナンバー」という。もしも、メンバーがトラックに轢かれていなくなったら・・・という例えである。

例えば、キーとなる1人のメンバーがいて、彼が抜けるとプロジェクトが止まってしまうようなら、トラックナンバーは1である。つまり、トラックナンバーは大きいほうがよい。言い換えれば、メンバーの欠落にどこまで耐えられるかということだ。

「トラックに轢かれたら」などとは物騒な話だが、要員の欠落というリスクを想定せよ、という警告を端的に表す気の利いた言葉として、しばしば使われる(※1)。


プロジェクトから特定のメンバーがいなくなって困るのは、「その人にしか出来ないこと」があるからだ。それは多くの場合、「その人しか知らない情報」があるせいである(※2)。

そういった意味では、トラックナンバーは、プロジェクト内の「情報共有の度合い」を表していると言ってもいいだろう。

プログラマがプロジェクトの一員としてできることは、自分がトラックに轢かれた時のことを考えることだ。つまり、「自分だけしか知らない情報」を作らないことである。仕様面にせよ、技術面にせよ、とにかく、自分が得た情報は、なんでも他のメンバーと共有するようにするのである(メーリングリストや Wiki などの仕組みを積極的に使うとよいだろう)。

もっとも、それ以前に、「お前がトラックに轢かれたら、プロジェクトがもっと円滑に進むのに」などと言われないようにしなければならないのだが・・・。


※1
あくまでも文学的表現であって、実際に算出することを想定したものではない(と思う)。
※2
それ以外にも、例えば、その人のスキルが非常に高いというときにもそういった状況になることがある。


■関連記事
足跡の作り方(前編)
足跡の作り方(後編)


[PR] XPエクストリーム・プログラミング入門 - ペアプログラミングでトラックナンバーを増やす
[PR] 結城浩のWiki入門 - 「Wikiって何?」という方に
[PR] Wiki Way - Wiki の生みの親が解説!