コラム：開発者が学ぶべきこと（2）
品質向上と効率アップの基本

Tim Romero（ティム・ロメロ）
2003/5/27

■現在と過去の違い

　4月は新しい年度の始まり。すでに5月も終わりだが、節目の季節に過去を振り返って功績をたたえたり、反省したりするにはいい時期だ。

　日本のIT企業にとっては、厳しい状況に変化はないようだ。筆者のコンサルティング業でも、ソフトウェア開発プロセスの向上や、限られた予算内でいかにエンジニアをうまく管理するか、といった相談内容が多い。

　皆この業界の何がいけないのかということばかりに目を向けているようだが、筆者自身はどこが正しかったかを振り返る方がずっとためになると考えている。そこで今回は、予想外の成功を収めたあるエンジニア軍団の話をしよう。そのエンジニア軍団とは、IBMの「ブラック・チーム」と呼ばれていたグループだ。

　1960年代のコンピュータ業界は、現在とまったく違っていた。コンピュータは大きく高価で、システムを常時稼働させておくためにはフルタイムでスタッフが必要だった。製品サイクルも、数カ月単位ではなく数年単位だったし、現在のプログラミングツールが数秒で処理してしまうような作業も、何週間もかかっていた。そして、新しいコンピュータモデルが出るごとに、OSやアプリケーションもそれに合わせて開発しなくてはならなかったのだ。

　しかし、何より一番の違いは、当時はシステムに対する顧客の目が厳しかったということだ。コンピュータシステムがこのように複雑な状況下で開発されていたにもかかわらず、顧客はシステムというものは必ず動くものだと考えていた。現在のソフトウェアベンダは、バグがあることは仕方のないことだと顧客に信じ込ませている面もあるが、1960年代にはバグのあるOSは不良品だと考えられていた。もちろん顧客は不良品にお金を出したりはしない。

■伝説の「ブラック・チーム」

　当時IBMでは、ソフトウェアのバグのせいで経費が多大なものとなっていた。何とか対策を立てなくてはいけない状況下にあったIBMの経営陣は、あるときソフトウェアの検査を担当している一部の人間が、平均より数十％も高い確率でバグを見つけているという事実に気が付いた。

　そのグループの個人個人は、特に優秀なわけでも才能があったわけでもなかった。ただ、彼らは皆ソフトウェアの検査を楽しんでおり、ほかの担当者より検査が得意であっただけなのだ。同じ考えを持った人間が集まったので、彼らは一緒に仕事をし、お昼を一緒に食べ、時にはプライベートな時間にも集まって、どうすればソフトウェアのバグをより多く見つけられるかを考えていた、というわけだ。

　その結果はすぐに表れた。このグループはほかに比べて何倍も効率よく仕事をこなし、そのうち自分たちの仕事はソフトウェアを検査するというより、ソフトウェアを壊すことだと考えるようになった。皆自分の才能にプライドを持ち、自分たちのことを悪徳なデストロイヤーだとイメージづけるようになった。そのうち彼らは黒いスーツを着て出社するようになり、自分たちのことをブラック・チームと呼ぶようになったのだ。

■ブラック・チームの進んだ道

　1960年代のIBMは、クリエイティブな職場環境を生み出す企業として知られていたわけではない。当時のIBMのイメージといえば、紺色のスーツにノリの利いた白いワイシャツ以外の何ものでもなかった。しかし経営陣は、このブラック・チームの存在に目をつむった。というよりむしろ、経営陣も喜んでいたといっていい。それは、このチームがとても情熱的で熱心だったこともあるが、何よりソフトウェアの品質が急速に良くなっている事実を見て、感心せずにはいられなかったのだろう。

　彼らはさらにおかしな方向へと進んでいった。ブラック・チームのメンバーは、ソフトウェアのバグを見つけると狂ったように笑い出すようになった。彼らのソフトウェアに対する行為は、合理的に検査を行っているというより、ソフトウェアに対する拷問を行うという感じだった。メンバーの一部の人間はひげを長く伸ばし、コードを攻撃しながらいかにもドラマの一場面のように、ひげをいじっていた。彼らが不気味になればなるほど、チームの効率はますます良くなっていった。

　いっておくが、ブラック・チームはかなり真剣だったし、ほかの開発チームと仲良くすることもなかった。プログラマらはブラック・チームにある程度の敬意を示していたが、どちらかというと恐れていた。プログラマにとってブラック・チームのメンバーが自分に近づいてくる姿を見るほど嫌なことはなかったし、ブラック・チームにコードを検査されたせいで涙を流すことになったプログラマも少なくない。

■こうしたチームが生まれる可能性は低いが……

　このようにブラック・チームは恐れられてはいたが、エンジニアはこのチームに入りたがった。メンバーの1人が抜けると、チームでは自ら次のメンバーを選び出した。このようにして、当初のメンバーがすべて去った後も、ブラック・チームはその特徴を残したまま存続した。

　このケースで経営陣が取った手段は、ブラック・チームがほかと違った態度でいたことをとがめなかったことと、彼らの仕事が重要な仕事だということに気付かせたことだろう。実際の効果は、チームメンバー自身が生み出したにすぎない。

　日本の大企業でブラック・チームのような存在が生まれることはあるのだろうか。その可能性はかなり低いといわざるを得ないが、1960年代のIBMでもこのようなチームが生まれる可能性は低かったのも事実だ。

　つまり、ここで筆者のいいたいことは、品質向上と効率アップのために必要なのは、UMLでもRADでも新しいプログラミング手法でも何でもないということだ。いい仕事をする環境さえ整っていれば、そこから自然に結果は見えてくるものである、ということだ。

筆者プロフィール

Tim Romero（ティム・ロメロ）●米国ワシントンDC出身。1991年に来日し、インターネット金融取引システムなどの開発を手掛けるヴァンガード（Vanguard）を設立。同社がデジタルガレージに買収された後、取締役として2002年9月まで在籍。現在は東京やサンフランシスコの企業とともに、エンジニアリングおよび開発プロセスの改善、技術管理の合理化に向けた活動を行っている。なお、本コラムは不定期での掲載を予定している。