| やさしい機能仕様 - パート 2: 仕様書とはどんなものか? |
Joel Spolsky ジョエル・スポルスキ
翻訳: Yasushi Aoki 青木靖
2000/10/3
(パート1はもう読んだ? 読んでなければ、ここにある。)
このアーティクル･シリーズで扱っているのは機能仕様であって、技術仕様ではない。人々はこの2つを混同している。標準的な用語があるのかどうか知らないが、私がこれらの用語を使うときに意味しているのは以下のことだ。
- 機能仕様書は、ユーザの観点から製品がどのように動くか記述する。それはどのように実装されるかは問題にしない。それは機能を話題としており、画面とか、メニューとか、ダイアログとかいったものの仕様を定める。
- 技術仕様書は、プログラムの内部の実装について記述する。それはデータ構造、関係データベースモデル、プログラミング言語や開発ツールの選択、アルゴリズムといったものを話題としている。
あなたが製品を隅から隅までデザインするとき、最も重要なのはユーザ体験を明確にするということだ。画面がどのようなもので、それがどのように機能し、何をするのか。それからあなたは、この画面からあの画面へとどうやって移るかを考える。あなたの製品が何をするのか決める前にどのプログラミング言語を使うかの議論をしても意味がない。このシリーズでは、私は機能仕様書についてだけ議論する。
良い機能仕様書がどんなものかイメージがつかめるように、私は短いサンプル仕様書を書いた。読み進める前に、そのサンプル仕様書を読んでほしい。
読んだ?
読まなかったでしょう。今すぐ読んで、それから戻って来て。そうしたら良い機能仕様書が何を含み、何を含むべきでないか議論することができる。私はここで待っているのでよろしく。
(辛抱強く待っている･･･)
よろしい。戻ったね。
平和な学校を作る方法
以下に挙げたのは私がいつも仕様書に入れているものだ。
注意書。純粋に自己防衛のため。「この仕様書は未完成である。」みたいなことを言う一文を何か入れておけば、人々があなたの頭を噛み切ろうとオフィスに押しかけてくることもなくなるだろう。時が経って仕様書が完成に近づいたら、これを「私にわかる限りではこの仕様書は完成しているが、何か抜けがあれば知らせてほしい。」と書き換えることができる。そしてこれは、仕様書に必ず必要なものを思い起こさせる:
作成者。1人の作成者。仕様書はチームによって書かれるべきだと考えている企業もあるようだ。あなたがグループライティングを試したことがあるなら、それ以上の責め苦がないことを知っているだろう。グループライティングは、巨大な費用を正当化するために大量の見せ掛け仕事をする必要のあるハーバード新卒のコンサルタントの軍隊を抱えたマネジメントコンサルティング会社に任せておくことにしよう。あなたの仕様書は1人の人間によって書かれ、所有されるべきだ。製品が大きい場合には、それを部分に分割し、それぞれの部分を別な人に割り当て、それぞれ別個に仕様を書かせる。他の会社では、仕様書に作成者が名前を書いて「自分の手柄にする」のは利己的だとか、「よいチームワーク」で� ��いと考えられている。ナンセンスだ。人々は自分が作った仕様について責任と所有権を持つべきだ。その仕様書で何かまずいことがあれば、その名前が仕様書に書かれている仕様書の所有者がいるはずで、修正する責任はその人にある。
で与えられた質量何lanuageのWAAS
シナリオ。製品をデザインするときには、人々がそれをどう使うだろうかという現実的で生き生きとしたシナリオが頭の中に入っている必要がある。そうでなければ現実世界でのどんな用途にも対応しない製品をデザインする羽目になる(Cue?Catみたいな)。あなたの製品のターゲット層を選択し、それぞれのターゲット層から、あなたの製品をまったく典型的な仕方で使う架空でまったく想像上の、紋切り型のユーザをイメージする。私のユーザインタフェースデザインの本の第9章(無料でオンラインで読める)は架空のユーザとシナリオの作成について扱っている。シナリオはあなたが彼らを置く場所だ。シナリオが生き生きとしていて現実的であればあるほど、あなたは製品デザインで、現実の、あるいは想像上のユ� ��ザのために良い仕事ができるだろう。それが私がたくさんの詳細を作り込む理由だ。
対象外。あなたが製品をチームで作るとき、それなしではやっていけない現実のあるいは想像上のお気に入りの機能というのを、みんな持っているものだ。もしそれらを全部やろうとするなら、際限ない時間を要し、コストがかかりすぎるだろう。あなたはすぐ機能の選択にとりかからなければならず、その最良の方法は仕様書の「対象外」セクションだ。それは私たちがやらないだろうことである。｢対象外｣はあなたが入れないであろう機能(「テレパシーによるユーザインタフェースは持たない!」)や、もっと一般的な事柄である(「このリリースではパフォーマンスについては気にかけない。製品は機能するにしても遅いかもしれない。バージョン2開発時に時間があれば、遅い部分を最適化するだろう。」) これら対象外の項目は議論を引き起こすかもしれないが、できる限り早い時期にオープンにすることが重要である。ジョージ・ブッシュSr.が言ったように、「Not gonna do it!(それはやらない)」だ。
概要。これは仕様書の目次みたいなもので、簡単なフローチャートかもしれないし、詳細なアーキテクチャに関する議論かもしれない。みんなこれを読んでビッグ･ピクチャーを把握し、それから詳細を読んで理解を深める。
書籍を教えるためにどのように
詳細、詳細、詳細。最後に詳細だ。多くの人は具体的な詳細を知る必要が生じるまではざっと目を通すだけだ。あなたがWebタイプのサービスをデザインしているなら、ひとつの良い方法は、すべての画面に正式名称をつけ、そのそれぞれを説明する章を設けて退屈な詳細をすべて記述するというものだ。
詳細は機能仕様書でもっとも重要な部分だ。サンプル仕様書で私がログインページについてすべてのエラーケースについて言及する非常な詳細さに気づいただろう。emailアドレスが正しくない場合どうする? パスワードが間違っている場合は? これらのケースはすべて、書く必要のある現実のコードに対応しており、さらに重要なのは、これらのケースは誰かがしなければならない決定に対応していると言うことだ。誰かがパスワード忘れに対するポリシーを決めなければならない。決めなければコードは書けないのだ。仕様書は決定を記述する必要がある。
未解決の問題。仕様書の最初のバージョンで未解決の問題があるのは構わない。私が最初のドラフトを書くときには、いつも多くの未解決の問題があるが、印をつけておいて(検索できるように特別なスタイルを使う)、必要なら代替案について議論する。プログラマが作業に取り掛かるときまでには、これらはすべて片づいていなければならない。(あなたはプログラマに簡単な部分を始めさせておいて、未解決な問題を後で解決してもいいんじゃないかと思うかもしれない。悪い考えだ。はじめから分かっていて解くこともできた古い未解決の問題がなかったとしても、プログラマがコードを実装しようとするとたくさんの新しい問題が持ち上がってくるだろう。加えて、あなたが自明でない問題を解くやり方は、コ� ��ドがどう書かれるかに大きな影響を与えるものだ。)
傍注。仕様書を書くときには、あなたの様々な読者のことを思い出すことだ: プログラマ、テスタ、マーケティング、テックライター、そのほか。あなたが仕様書を書いていると、これらのグループの中のどれかひとつにだけ役に立つ、有用な擬似事実を考えつくかもしれない。たとえば、実装上の技術的詳細について述べたプログラマ向けのメッセージを「テクニカル･ノート」として記すかもしれない。マーケティングの人々はそれを無視し、プログラマは食い入るように読む。私の仕様書はしばしば「テスティング・ノート」とか「マーケティング・ノート」とか「ドキュメンテーション・ノート」とかがびっしり書き込まれている。
仕様書は生きている必要がある。プログラミングチームのあるものは「ウォータフォール」メンタリティを採用している: 我々はプログラムをすべて一度にデザインし、仕様書を書き、それを印刷し、壁越しにそれをプログラマに投げ渡して家に帰る。私に言わせると「ハッハッハッ!」だ。
このアプローチが、仕様書がこうもひどい評判を受けている理由だ。多くの人々が私に言ったものだ「仕様書は役に立たないよ、誰も従わないんだから。それはいつも陳腐化していて、製品を決して反映していない。」
ごめんあそばせ。あなたの仕様書は陳腐化していて製品を反映していないかもしれないが、私の仕様書はいつもアップデートされている。製品が開発され、新しい決定がなされている間、それはアップデートされ続ける。仕様書はいつも、その製品がどう機能するかについて、その時点における私たちの最高の知見を反映している。仕様書はコードコンプリートしたときに初めて、凍結される。(これはすべての機能が完成し、テストとデバッグ作業が残っているだけのときだ。)
人々を楽にしてやるため、私は毎日仕様書を再リリースしたりはしない。私は通常アップデートされた仕様書をサーバのどこか、チームが参照できるところに置いておく。マイルストーンで私は、みんなが全体を読み直さなくても済むようにリビジョンマークをつけた仕様書のコピーを印刷する—彼らはどこが変わったのかリビジョンマークに目を通すだけでよい。
誰が仕様書を書くべきか? パート3ではこの問題を扱う。
この記事の原文（英語）は Painless Software Specifications Part 2 です。
0 件のコメント:
コメントを投稿