Joel on Software

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

 

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

その他の "Joel on Software" の記事(日本語)

その他の "Joel on Software" の記事(英語)

著者へのメール(英文のみ)

 

やさしい機能仕様 - パート 1: なぜわざわざ書く必要があるのか?


Joel Spolsky ジョエル・スポルスキ
翻訳: Yasushi Aoki 青木靖
2000/10/2

The Joel Testを発表したとき、読者から寄せられた最大の不満の種は、仕様書を書かなければならないということだった。仕様書はデンタルフロスみたいなもので、みんな書かなきゃいけないと思ってはいるが、誰も書かない。

なぜ人々は仕様書を書きたがらないんだろう? 人々は仕様書作成フェーズを飛ばせば時間を節約できると主張している。彼らは仕様書作成がNASAのスペースシャトルのエンジニアか巨大な保険会社で働いているような人たちのための贅沢品であるかのように振舞っている。戯言だ。何よりも仕様書を書かないというのは、あなたがソフトウェアプロジェクトに持ち込む、最大かつ不必要なリスクである。それは着替えだけリュックに詰めて、その場になれば何とかなることを期待してモハーベ砂漠の横断に出発するのと同じくらい愚かなことだ。仕様を書かずにコードに飛びつくプログラマやソフトウェアエンジニアは、彼らがかっこいい早撃ちガンマンででもあるかのように思う傾向がある。彼らはそうじゃない。彼らはとても非生産的だ。彼らはまずいコードを書き、粗悪なソフトウェアを生産し、まったく必要のない大きなリスクを負うことでプロジェクトを危険にさらしている。

些細なものを別にすれば、(1週間以上のコーディング、あるいは2人以上のプログラマを要する)どんなプロジェクトであっても、仕様書がなければ、あなたは常により多くの時間を費やし、品質の低いコードを作ることになると私は考えている。理由はこうだ。

仕様書のもっとも重要な役割はプログラムをデザインすることだ。たとえあなたがすべてのコードを一人で書いているのだとしても、あなたが純粋にあなた自身のために仕様を書いているのだとしても、仕様を書くという行動自体が—プログラムがどう機能するか詳細に記述するということが—プログラムを実際にデザインするようあなたに強いるのだ。

想像上の2つの会社の2人のプログラマを訪ねてみよう。ヘイスティ・バナナ・ソフトウェアで働くスピーディは決して仕様書を書かない。「仕様書? 私たちには仕様書なんかいらないわ!」一方、ウェル・テンパード・ソフトウェアで働くロジャーズ氏は、仕様が完全に明確になるまではコードを書くのを拒否する。彼らはたくさんいる私の想像上の友人の中の2人だ。

スピーディとロジャーズ氏にはひとつの共通点がある: 彼らはそれぞれの製品のバージョン2.0の後方互換性確保を任されている、ということだ。

スピーディは後方互換を提供する一番よい方法は、単にバージョン1.0のファイルをバージョン2.0のファイルに変換するコンバータを書くことだと決める。彼女は急いでそれを作り始める。タイプ、タイプ、タイプ。カタ、カタ、カタ。ハードディスクが回る。埃が飛ぶ。2週間ほどたって、彼女はコンバータを作り上げる。しかしスピーディの顧客はそれがあまりうれしくない。スピーディのコードは彼らに会社の全員が一度に新しいバージョンにアップグレードすることを強いる。スピーディの最大の顧客であるナナー・スピリッツ社は、バージョン2.0でバージョン1.0のファイルがコンバートせずに使えない限り、新しいバージョンを買うのを拒む。スピーディはバックワードコンバータを書き、それを保存機能にフックすることに決める。しかしちょっと問題があって、バージョン2.0の機能を使っているとうまく行きそうに見えるのだが、いざ1.0フォーマットで保存しよとしてもできない。あなたが30分前に使った機能が古いフォーマットでは保存できないということを、そのときになってはじめて教えられるのだ。バックワードコンバータを書くのにはさらに2週間かかる上に、あまりうまく機能しない。経過時間は4週間だ。

一方、ウェル・テンパード・ソフトウェア(通称「ウェルテンプソフト」)で働くロジャーズ氏は、仕様をもらうまでは決してコードを書こうとしない、あのうざったい計画的なタイプのひとりだ。彼はスピーディがしたのと同様に後方互換機能を20分でデザインし、基本的には以下のような内容の仕様を作る:

  • 古いバージョンで作られたファイルを開いたとき、ファイルは新しいフォーマットに変換される。

その仕様を見た顧客は、「待ってくれ! 私たちは全員一斉に切り替えようとは思っていない。」と言う。それでロジャーズ氏はもう少し考えて、仕様書を修正する:

  • 古いバージョンで作られたファイルを開いたとき、ファイルはメモリ中で新しいバージョンに変換される。ファイルを保存するとき、ユーザにはそれを元のフォーマットに戻す という選択肢がある。

さらに20分が経過する。

ロジャーズ氏の上司はオブジェクト指向マニアで、これを見て何かが間違っていると思う。彼は違ったアーキテクチャを提案する。

  • コードは二つのインタフェースV1とV2を使うように分解される。V1はすべてのバージョン1の機能を含み、V2はV1を継承し、さらにすべての新機能が追加される。さて、V1::Saveは後方互換性を扱う一方、V2::Saveは新機能を保存するために使うことができる。もしV1ファイルを開いてV2機能を使おうとすると、プログラムはただちに警告し、ユーザはファイルをコンバートするか、それとも新機能をあきらめるか、という選択をしなければならない。

さらに20分。

ロジャーズ氏は不機嫌だ。このリファクタリングをするには、彼が当初見積もった2週間じゃなく、3週間かかる。しかしこれは顧客の問題のすべてをエレガントな仕方で解決するので、彼は取り掛かってプログラムを書くことにする。

ロジャーズ氏のトータルの経過時間: 3週間と1時間。スピーディの経過時間:4週間。ただしスピーディのコードは見劣りがする。

この物語の教訓は、作られた例なら何だって証明できるということだ。おっと、違った。これは私が言おうとしたことじゃない。この物語の教訓は、あなたが製品を人の言葉でデザインしているとき、いくつかの可能性について考え、修正し、デザインを改良するのには数分しかかからないということだ。ワープロ文書の段落をひとつ削除するのに気分を害する人はいない。しかしあなたがプログラミング言語で製品をデザインしているなら、反復デザインをするのには何週間もかかる。さらに悪いことに、あるコードを書くのにほんの2週間かけただけで、プログラマは、それがどんなにまずいものであっても、そのコードにとても執着するようになる。たとえそれが最高のアーキテクチャを表現していない場合でも、スピーディの上司や顧客が何と言おうと、彼女にその美しいコンバータのコードを捨てさせることはできない、その結果として、最終製品は初期の間違ったデザインと理想的なデザインとの間の妥協の産物になりがちだ。「私たちがすでに書いていたコードを前提とすると、それが私たちに得られた最良のデザインだったし、それにすでに書いたものを捨てたくはなかった。」そしてそれは「私たちに得られた最良のデザイン」ほど良いものではない。

これが仕様書を書く大きな理由の1番目だ。大きな理由の2番目はコミュニケーションにかかる時間を節約できるということだ。あなたが仕様書を書けば、プログラムがどう動くと想定されているか一度だけ説明すれば済む。チームのみんなはただ仕様書を読めばいいのだ。QAの人たちはプログラムがどう動くと想定されているか知るためにそれを読み、何をテストすればよいのかがわかる。マーケティングは、まだ作られていない製品についてWebに載せるために、ベイパーウェアのホワイトペーパーを書くときにそれを使う。ビジネス開発の人たちは、その製品がいかに禿げや瘤を治すかという奇妙なファンタジーを紡ぎ出してミスリードするが、それで投資家を引き寄せられるのだから、それはそれでOKだ。開発者たちはどういうコードを書くのか知るためにそれを読む。顧客は開発者の作っているものが自分たちの欲しい製品であることを確認するためにそれを読む。テクニカルライターはそれを読んで素敵なマニュアルを作る(それはなくなったり捨てられたりするが、それはまた別な話だ)。マネージャは何が起こっているのかについて経営会議で知っているような顔をするためにそれを読む。などなど。

このコミュニケーションは不可欠であり、あなたが仕様書を書いていない場合でも発生するが、それはアドホックな仕方でである。品質保証の人たちが否応なしにあれこれとプログラムをいじり回し、そして何か奇妙なことが起きるたびにプログラマを邪魔して、どうなるのが正しいのかについて馬鹿げた質問をする。これがプログラマの生産性を損なうのを別にしても、プログラマというのは「正しい答え」ではなく、彼らがコードに書いたことに即して答える傾向がある。だから品質保証の人たちはプログラムをデザインに対してテストするのでなく、プログラムに対してテストすることになり、これは、そのー、もう少し有用にもなり得たのだ。

あなたが仕様書を書かないと、哀れなテクニカルライターに起きることはとても滑稽だ(悲しいたぐいの仕方で)。テックライターはしばしばプログラマに割り込めるだけの政治力を持たない。多くの会社では、テックライターがプログラムがどう動くと想定されているのか質問するためにプログラマにたびたび割り込みをかけると、プログラマはマネージャのところへ行って、この[卑語省略]ライターたちのためにいかに仕事に支障が出ているか泣き言を言い、連中をどうか遠ざけてくれるように頼み、マネージャは生産性の向上のためにテックライターがそれ以上貴重なプログラマの時間を無駄にするようなことを禁じる。あなたはそんな会社をいつでも言い当てることができるだろう、というのはそのヘルプファイルやマニュアルが、画面を見ていて理解できる以上の情報を与えていないからだ。たとえばあなたは画面で次のようなメッセージを見る:

  • LRF-1914サポートを有効にしますか?

・・・それであなたが「ヘルプ」をクリックすると、悲喜劇的なヘルプトピックが現れて、何か次のようなことを言うのだ。

  • LRF-1914サポートを有効(デフォルト)にするか無効にするか選択します。もしLRF-1914サポートが必要なら "Yes"をクリックするか"Y"を入力してください。もしLRF-1914サポートが必要ないなら、"No"をクリックするか"N"を入力してください。

あー、ありがとう。LRF-1914サポートが何か知らないという事実をテクニカルライターがどうにかして隠そうとしているのは明らかだ。彼らがプログラマに聞くことができなかったのは、(a)テックライターが気後れしたためか、(b)プログラマがハイデラバード(パキスタン)にいて、テックライターがロンドンにいたためか、(c)マネジメントにプログラマの邪魔することを禁じられたためか、あるいはその他の、あまりにもたくさんあって書ききれない企業の病理がいくつも重なったためなのだが、根本的な問題は仕様書がないと言うことだ。

仕様書を持つべき大きな理由の3番目は、詳細仕様がないと、スケジュールが立てられないということだ。それがあなたの博士論文で14年かけるつもりでいるなら、あるいはあなたがDuke Nukemの次期バージョンを作っているプログラマで、「我々は準備ができたときに出荷する。」というのであれば、スケジュールはなくてもOKだ。しかしほとんどあらゆる現実のビジネスにおいては、製品開発にはがかかるため、ものごとにどれくらい時間がかかるのか知っている必要がある。あなたは値段を見ずにジーンズを買ったりはしないだろう。それなら、責任あるビジネスが、どれほどの時間がかかり、したがってどれくらいの金がかかるのか知ることもなしに、どうして製品開発の決定を下せるだろう? スケジュールについてもっと詳しく知りたければ、やさしいソフトウェアスケジュールを読んでほしい。

非常に一般的に見られる誤りは、何かをどうデザインするべきかについて議論しながら、その決着を付けないことだ。Windows 2000の主席デベロッパーであるブライアン・バレンタインは、彼のモットー「10分以内に決断、さもなきゃ次のはただ」で有名だ。

あまりに多くのプログラミング組織が、通常は政治的な理由によって、デザインについて議論するときはいつも、誰も結論を出そうとしない。そのためプログラマは議論にならない部分についてだけ作り始める。時がたつと、すべての難しい決断は最後に残されることになる。そういうプロジェクトはほとんど間違いなく失敗する。あなたが新しいテクノロジーに関連した新しい会社を立ち上げ、そしてあなたの会社が構造的に決断を下すことができないのなら、あなたは決して何も出荷することはないだろうから、今すぐ会社を畳んで投資家に金を返すべきだ。

仕様を書くというのは、仕様書がないと隠されてしまうような、これら大小のいらだたしいデザイン上の判断を明確にする、優れた方法である。小さな決断であっても仕様によって確定できる。たとえば、あなたがメンバー制のウェブサイトを構築しているとして、ユーザがパスワードを忘れたらユーザにメールするものとしよう。すばらしい。しかしこれだけではコードを書くのに十分ではない。コードを書けるためには、あなたはメールに書く実際の文面を知る必要がある。多くの企業では、ユーザが実際に見る文章についてはプログラマは信用されていない(そして多くの場合、これには正当な理由がある)。そのためマーケティングの人間か、PRの人間か、あるいはその他の英文専攻の人間が、メッセージの正確な言い回しを考え出すよう要求される。「親愛なるシュラブ、これがあなたのお忘れになったパスワードです。もうなくさないように注意してください。」あなたが良い、完全な仕様書を書こうとするとき(このことについてはすぐ後で詳しく議論する)、あなたはこれらのことに気付いて、それを修正するか、少なくとも大きな赤い旗でマークしておくだろう。

OK、今や私たちの考えは同じだ。仕様書は母性であり、アップルパイだ。多くの人がそれを理解しているかは疑問だが。そして私の暴言はおもしろかったとしても、新しいことは何も言っていない。ではなぜ人々は仕様書を書かないのだろう? それは時間の節約のためじゃない、なぜなら節約にはならないからであり、そしてほとんどのコーダはそのことを認識していると思う。(多くの組織で唯一存在する「仕様書」は、プログラマがコードを書いたで、しかも300人目の人に機能の説明をしたに、Notepadで手早く書いた1ページのテキスト文書だ。)

その理由は、それほどに多くの人々が書くのが嫌いなためなのだと私は思う。空白のスクリーンから始めるというのはとてもフラストレーションを感じるものだ。個人的には、私は書くことに対する恐怖を克服するために、週に3-5ページのエッセイを書くことを要求される講義を大学で受講した。書くことは筋力だ。書けば書くほど、あなたはより書けるようになる。もしあなたが仕様書を書く必要があるが書けないのであれば、日記を付け始め、weblogを作り、創作文章講座を受講し、親戚のそれぞれや、過去4年ほど疎遠になっていた大学時代のルームメートにすてきな手紙を書けばよい。何であれ、紙に言葉を書き出すことに関わるあらゆることが、あなたの仕様書を書く能力を向上させる。あなたがソフトウェア開発マネージャで、仕様書を書くべき人々が書いていないというのであれば、彼らを山の中でやっている2週間の創作文章講座に送り込めばよい。

もしあなたが機能仕様書を書いている企業で働いたことがないなら、たぶん現物を見たことがないだろう。このシリーズの次のパートでは、短いサンプル仕様書を示し、良い仕様書が何を持たなければならないかについて議論する。さあ続きを読もう!



この記事の原文(英語)は Painless Functional Specifications です。 

ジョエル・スポルスキは、ニューヨーク市の小さなソフトウェア会社  Fog Creek Software の設立者です。イェール大学を卒業後、マイクロソフト社、Viacom社、 Juno社でプログラマとして働きました。


このページは著者の個人的な意見を掲載したものです。
All contents Copyright ©1999-2005  by Joel Spolsky. All Rights Reserved.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky