プロジェクト・マネジャーが知るべき97のこと/要求と仕様
すぐれた要求とは、製品のフィーチャーがある既存の問題あるいは潜在的な問題をどのように解決するかを記述したものです。すぐれたフィーチャー（機能と呼ばれることもある）とは、そうした重要な問題を解決するために製品に追加されるものです。要求はセールスによって獲得されたり、ソフトウェアプロジェクト・マネジャーによって作り出されます。
- 米国外でその製品を売ることはできない（要求）。私たちは国際化と地域サポートを提供する必要がある（フィーチャー）。
- ユーザーはごく単純なタスクを完了するのに5 つのボタンをクリックする必要がある。これだとユーザーはイライラしてタスクを完了できない。私たちはユーザーインターフェイスを単純化して（要求）、同じタスクを完了するのにボタンのクリック数を2 回以下に減らす必要がある（フィーチャー）。
これに対して仕様とは、問題がどのように解決されるか、要求がどのように満たされるかを正確に記述したものです。先ほどの例を使うと、次のような仕様がシステムアーキテクトによって書かれることになります。
- ポップアップメッセージを含むすべてのテキスト文字列を抽出して、外部リソースバンドルに置く（仕様）
- アプリケーションを改良して、画面上に表示されるテキストをすべて、外部リソースバンドルから取得する（仕様）
- 必要とされるロケール用のリソースバンドルを作ることによって、ローカライゼーションを実現する（仕様）
- ボタン1、2、3 をクリックすることで実現していた機能は、ボタンA の1回クリックにまとめる（仕様）
- 既存のボタン4、5 の機能は、ボタンB にまとめる（仕様）
要求と仕様の区別をあいまいにすると、間違った人に判断させることになります。どの機能がユーザーにとって重要なのか、ユーザーに代わってソフトウェア開発者が「判断」してしまったり、コードをどう組み立てるかをプロジェクト・マネジャーが「開発者に教える」ことになります。いずれにせよ、最終的に作られるソフトウェア製品はひどいものになるでしょう。
開発者は通常、顧客、ユーザー、マーケティング、セールス、パートナーになる可能性のある人たちと会話をしません。彼らはどの新規フィーチャーが一番重要なのか理解しようとしていないのです。それに対して、プロジェクト・マネジャーは通常、熟練した開発者ではありません。彼らはフィーチャーをどう実装するのが一番よいか理解していませんし、未熟な仕様提案がその製品の別のところにどんな影響を及ぼすのかも理解していません。開発者とプロジェクト・マネジャーには、それぞれ特有のスキルセットがあるのです。
すぐれた要求は、解決しようとしている問題について、また、その問題を解くことが重要である理由について記述したものです。開発プロセスにおいて、プログラマにはもっと柔軟に、もっと効率よく、もっとモチベーションを高くもってもらいましょう。プログラマが問題に集中して徹底的に理解すると、独立した設計判断が下せるようになります。プログラマは自分たちが選び抜いてきた技術によってのみ縛られるべきです。プログラマでない人によって作られた、厳格だけれども脆弱な仕様によって縛られるべきではありません。
とはいえ、仕様は文書化しておく必要があります。ところが、仕様は変化するものです。あなたは製品開発ライフサイクルの最後になってようやく、この製品がそもそもどう作られるべきだったか理解できるようになったという経験はありませんか？
あなたが作ろうとしているもの（what）とその作り方（how）を分けておきましょう。そして、それぞれの役割に基づき、きちんとトレーニングを受けたチームメンバーに判断させましょう。
この作品はクリエイティブ・コモンズ 表示 3.0 アメリカ合衆国ライセンスのもとに利用を許諾されています。
あなたは以下の条件に従う場合に限り、自由に
- 共有 – 本作品を複製、頒布、展示、実演できます。
- 再構成 – 二次的著作物を作成できます。
あなたの従うべき条件は以下の通りです。
- 表示 – あなたは適切なクレジットを表示し、ライセンスへのリンクを提供し、変更があったらその旨を示さなければなりません。これらは合理的であればどのような方法で行っても構いませんが、許諾者があなたやあなたの利用行為を支持していると示唆するような方法は除きます。
