Joel on Software   このページは"ジョエル・オン・ソフトウェア

※新しい翻訳はJoel on Software Translation Projectにあります。

その他の "Joel on Software" の記事（日本語）

その他の "Joel on Software" の記事（英語）

著者へのメール（英文のみ）

あなたはなぜ仕様書を書く必要があるのかと仕様書に書くべきことは何かについて学んだ。では誰がそれを書くべきかについて話すことにしよう。

誰が仕様書を書くか?

こごでMicrosoftの歴史について少し話をさせてほしい。Microsoftが急速に成長し始めた1980年代のことだが、ソフトウェアマネジメントの古典である人月の神話はみんな読んでいた(あなたがまだ読んでいないのなら、ぜひともお勧めする)。この本の要点は、遅れているプロジェクトにプログラマを増員すると、プロジェクトはよけい遅れるということだ。その理由は、チームにn人プログラマがいるとき、コミュニケーション・パスの数はn(n-1)/2で、これはO(n²)で増加するからだ。

そのためMicrosoftのプログラマたちは、どんどん大きくなっていくプログラムをどうやって書けばよいのかと懸念していた、ただ事態を悪くするだけのプログラマの増員が世に行き渡っていた考えであったその当時においてだ。

Microsoftで長年「チーフアーキテクト」をしていたチャールズ・シモニーはマスタ･プログラマという概念を提案した。このアイディアでは、1人のマスタ･プログラマが基本的にすべてのコードを書く責任を持つが、彼はジュニア・プログラマのチームを「コード奴隷」として使うことができる。それぞれの関数のデバッグで悩むかわりに、マスタ･プログラマはそれぞれの関数のアウトラインをなすプロトを作り、それを実装するようにジュニアプログラマの1人に渡すのだ(もちろんシモニーはマスタ･マスタ・プログラマだった)。「マスタ･プログラマ」という用語はあまりに中世風なので、 Microsoftはそれを「プログラムマネージャ」と呼ぶようになった。

理論的には、これは人月の神話問題を解くと考えられた、誰も他人と話す必要がなくなるからだ—各ジュニアプログラマは1人のプログラムマネージャとだけ話をすればよく、コミュニケーション量の増加はO(n²)ではなくO(n)になる。

どうもシモニーはハンガリー記法は知っているようだが、ピープルウエアは知らないようだ。誰もコード奴隷なんかにはなりたくない。このシステムは全然機能しなかった。結局Microsoftは人月の神話がどうであれ、頭のいい人々をチームに追加すれば、限界価値は逓減するにしても出力を増加できるということを発見した。私がいたころExcelチームには50人のプログラマがいたが、25人のチームよりは生産的であっただろう—2倍とはいかないが。

マスタ/スレーブプログラミングのアイディアは信用を失ったが、Microsoftでは今でもプログラムマネージャと呼ばれる人たちが飛び回っている。Jabe Blumenthalという頭のいい男が、プログラムマネージャという地位を再発明したのだ。すなわち、プログラムマネージャは製品のデザインと仕様を所有する者だ。

それ以来、Microsoftのプログラムマネージャたちは要求を集め、コードが何をすべきか見極め、そして仕様書を書いている。通常プログラムマネージャ1人にプログラマが5人いて、このプログラマたちにはプログラムマネージャが仕様書の形で表現したことをコードに実装する責任がある。プログラムマネージャはまた、マーケティング、ドキュメンテーション、テスト、国際化、そのほか、プログラマが時間を費やすべでないあらゆるわずらわしい詳細に関し、調整を行う必要がある。最後に、Microsoftのプログラムマネージャはこの会社の「ビッグピクチャー」を心に抱いていることを期待されており、プログラマたちはと言えば、正しいコードを書くことに専念できる。

プログラムマネージャは貴重な存在だ。プログラマが市場性より技術的なエレガントさばかり気にしていることに不平を言ったことがあるなら、あなたにはプログラムマネージャが必要だ。いいコードを書ける連中がいい英語を書くこととなると決していい仕事をしないと不平を述べたことがあるなら、あなたにはプログラムマネージャが必要だ。あなたの製品が明確な方向もなく漂流しているように思えるなら、あなたにはプログラムマネージャが必要だ。

どうやってプログラムマネージャを雇うか?

多くの会社はプログラムマネージャの概念すら持っていない。それは具合の悪いことだ。私のいた当時のMicrosoftでは、強力なプログラムマネージャのいるグループは非常に成功した製品を作り出した: Excel、Windows 95、Accessが頭に浮かぶ。しかし他のグループ(MSN 1.0やWindows NT 1.0)はプログラムマネージャを通常無視している開発者たちに仕切られており(そのプログラムマネージャたちはどのみちあまり実力がなかったので、たぶん無視されても仕方なかったのだ)、その製品はあまり成功していなかった。

ここに避けるべきことが3つある:

1. プログラムマネージャにしてやるとコーダに約束しないこと。良いプログラムマネージャになるためのスキル(明快な英語を書けること、外交手腕、マーケット・アウェアネス、ユーザに対する理解、よいUIデザイン)が良いコーダであるためのスキルでもあることはめったにない。そのどちらもやれる人間がいるのは確かだが、非常に少ない。優れたコーダをC++ではなく英語を書かなければならない別なポジションに昇進させて報いると言うのは、ピーターの法則の古典的な例である: 人々は彼らが不適格となるレベルまで昇進する傾向がある。

2. マーケティングの人間をプログラムマネージャにしない。悪気はないのだが、マーケティングで優秀な人間が、製品をデザインできるほど技術的な問題をよく把握していることは滅多にないということに、読者は同意してくれると思う。

基本的にプログラムマネジメントというのは独立したキャリアパスだ。すべてのプログラムマネージャは非常に技術的であることが要求される、優れたコード書きである必要はない。プログラムマネージャはUIについて学び、顧客と会い、そして仕様書を書く。彼らは広い範囲の人々とやっていく必要がある—「ばかな」顧客から、スタートレックのユニフォームで出社してくるイライラさせられる世捨て人のプログラマに、$2000のスーツを着た気取ったセールスの連中まで。プログラムマネージャはある意味でソフトウェアチームを結びつけるものであり、カリスマ性は必須だ。

3. コーダをプログラムマネージャの監督下に置かない。これはちょっとした間違いだ。Microsoftのプログラムマネージャとして、私はExcelのVisual Basic (VBA)ストラテジーをデザインし、VBAをExcelにどのように実装すべきか、微細な詳細にいたるまで完全に仕様化した。私の仕様書は500ページに及んだ。Excel 5.0の開発の高みから私の見積ったところでは、毎朝250人の人々が働きに出て来て、私の書いた巨大な仕様に関わる作業をしていた。私はこの人たちが誰なのか全然知らなかったが、Visual Basicチームに限っても、これのドキュメンテーションを書くだけのために1ダースほどの人々がいた(Excel側からドキュメントを書いていたチームや、ヘルプのハイパーリンクを管理していたフルタイムの人は入れないでだ)。奇妙なのは、私が職階の｢最下層｣にいたということだ。そう、私には部下は誰もいなかった。私が誰かに何かしてもらいたいと思ったら、それをするのが正しいということを納得させる必要があった。もし主席開発者のベン・ワルドマンが私が仕様書に書いたようなことを何もやりたくないと思っていたなら、彼は単にやらなかっただろう。テスタが私の仕様書に書いたことは完全にはテストできないと文句をつけてきたら、私はそれを単純化する必要があった。もしこれらの人々の誰かが私の部下であったなら、製品はそんなに良いものとはならなかっただろう。彼らのあるものは上司にとやかく言うのはまずいと思うかもしれない。あるいは、私がうぬぼれや近視眼のために、私のやり方でやるように断固として命令していたかもしれない。実際にはコンセンサスを得る以外には私に選択肢はなかった。このような意思決定形式が、正しいことが行われるようにするための最善の方法だった。

このシリーズの最後のアーティクルでは、人々が読みたくなるような良い仕様書をどうやって書くかについて話そう。