The Rational Edge

要求仕様の決定に時間を割かない結末は？

Jim Heumann
Rational Software Corporation
2002/1/22

---

　次のような話を聞いたことはあるだろうか？

　「要求仕様をまとめる時間がない。すぐにコーディングに取り掛からないと納期には絶対に間に合わない」

　このような話（よく聞く話だが）は、個人もしくはチームの考え方や成熟度を測るための重要な手掛かりになる。要求仕様をまとめる時間がないという言葉が出てくるのは実際にはどういうときであり、どのような意味があるのだろうか？ 本稿で詳しく見ていこう。

　「要求仕様」という単語には多くの定義があり、メソッド、プロセス、方法論、そして専門家ごとにそれぞれ固有の解釈があるようだ。しかし、要求仕様はそのプロジェクトが何を構築し、提供するのかを明確に記述すべきである、との点ではだれも異論はないはずだ。もし上述の話の中にある要求仕様という言葉をこの簡単な定義で置き換えると次のようになる。

　「構築および提供すべきものの内容をまとめている時間がない。すぐに……」

　このようなことを大声で口にする人などいるとは思えないがどうだろう？ では、要求仕様をまとめる時間がない、などという言葉が出てくるのは一体どういうことなのだろうか？ また、要求仕様をまとめておかないとどうなってしまうのだろうか？

■「要求仕様」の意味するもの

　ここで議論している言葉には、実際には次のいずれかの意味があるはずだ。

1. 「自分は要求仕様を理解している、もしくはすぐに明確にできる」
   
2. 「過去に扱った要求仕様が粗悪で、ない方がうまくいくと思う」
   
3. 「何を作ろうと、予定どおりに完成さえすれば（そして代金が回収できれば）あまり関心はない」
   
4. 「アプリケーションのアイデアがあまりにも新しい（もしくはあまりにもユニークな）ため、どうしても要求仕様をあらかじめ明確に定義することができない」

　いまから見ていくが、これらのどの解釈にも危険が潜んでいる。

（1）「自分は要求仕様を理解している」

　これは「最も好意的な」解釈である。このプロジェクトの責任者は、要求仕様の内容を完璧に理解しているか、コーディング作業を進めていく中で明確にできると考えている。だが、よく考えてみれば、この言葉が実際に意味するのは「自分のプロジェクトの開発者が要求仕様を理解しているか、それを明確にできる」ということになる。結局のところ、どのソフトウェアプログラムにしても機能をインプリメントするのは開発者の仕事なのだ。構築するものに関する仕様（つまり要求仕様）が文書化されず、承認も行われていない場合、何をインプリメントするのかは最終的には開発者の判断にゆだねられることになる。

　これのどこがいけないのだろうか？ 多くの組織では、これまではこのようなやり方がほとんどだった。だが、このいわゆる「時代遅れの手法」がもはや許されない理由の1つとして、今日のプロジェクトが昔よりも複雑になっているという状況がある。そして、これらは問題定義とインプリメンテーション定義という2つの分野で複雑化しているのだ。

　そもそもソフトウェアは、10年前には影響するなど思いも寄らなかった分野や生活の中にまで浸透してきた。畜産管理、自動車のナビゲーション、携帯電話の不法使用検知などなど、多くの専門的な目的でソフトウェアが利用されている。開発者の大部分が、これら特定の分野の解決すべき問題を把握もしくは理解しているとはとても思えない。さらに、アプリケーションの各分野も一段と複雑になり、プログラミングもそれに伴って複雑化している。堅牢なシステムを構築するために開発者が考えなければならない分散、並行、リアルタイム、相互関連といった各種コンポーネントや新しい言語などの問題は、すべてがコーディングの専門知識習得に対するプレッシャーとなって彼らにのしかかってくる。さらに、これらの新たな需要により、システムが解決しなければならない問題を見つけ出すべく開発者に与えられる時間や要員はさらに減ってきた。

　開発者が「すぐに明確にできる」ことを当てにできないもう1つの理由は、彼らに本質的な利益の衝突があることだ。彼らには期限がある。これには自らの概算による場合もあれば、第三者の概算による場合もある。彼らに対して非常に漠然とした指示を出した場合には、その機能をインプリメントする際に数多くの選択肢が生まれてくることになる。このような場合には、彼らにとって最大の目標を達成する（通常の場合は期限内に完成させること）のに最適な方法を選ぶのが自然の流れだ。

　私はかつて、ユーザーがプッシュボタンやリストボックスといったエレメントのカラーを指定する機能がまったくないGUI（Graphical User Interface）ビルダ向けに追加コードを書く仕事をしたことがある。私が追加しなくてはならなかったシステム機能仕様は「GUIエレメントのカラーをユーザーが指定できるようにする」というものだった。さて、ユーザーがカラーを指定できるようにする方法は、テキストフォーマットでカラーのリストを表示してもよいし、さまざまなカラーのボックスを表示してその中から選ばせてもよいし、円形のカラーチャートを表示して選択させてもよいなど、いくらでもある。また、赤、緑、青（RGB）の値に1から255までの数値を入力させ、それらを組み合わせて好きなカラーを作り出すこともできる。この中には、ユーザーにとっては簡単だが開発者にとっては難しいというオプションもあれば、その逆もある。

　いまとなっては非常に悔やまれるのだが、私はこのときユーザーにRGBの値を入力させることにした。それは、これが自分にとって最もインプリメントの簡単なオプションであり、これによってスケジュールを守ることができたからだ。問題なのは、これがユーザーにとっては最も難しいオプションだったことだ。私がこの恥ずべき例を示したのは、ユーザーの要求仕様に関する重要な判断を開発者にゆだねると、開発者をどうしようもない状況に追いやり、満足のいかない結果につながることも多いことをこれが説明しているからだ。

（2）「過去に扱った要求仕様が粗悪」

　プロジェクトマネージャが要求仕様の作成を無駄だと感じる理由の1つに、過去のプロジェクトで不適切な要求仕様に悩まされた経験が挙げられる。不適切な要求仕様はいろいろな形で現れるが、重要なのはこれらが実際に何かを構築するに当たって十分な情報を提供しないか、誤解を招く、もしくは矛盾するような情報を提供するかのいずれかである場合だ。このような場合には、それぞれの推測で作業を進めた方がプロジェクトがうまく進行するといえるだろう。だが、これだけは覚えておいていただきたい。過去に不適切な要求仕様をベースにして作業を進めなければならない経緯があったからといって、今後もそれが繰り返されるとは限らないのだ。あなたのチームが有効かつ優れた要求仕様を作成するのを助けてくれる便利なガイドライン、テクニック、そしてツールを紹介しよう。

●適切な要求仕様、不適切な要求仕様

　「IEEE 830 Documentation Standard for a Software Requirements Specification」によると、質の高い要求仕様の基準は以下のようになる。

不明瞭でないこと	いずれの記述にもその解釈は1つしかないこと。用語が明確で、適切に定義されていること
完全であること	重要な要求仕様がすべて含まれていること。いずれの項目もその定義を後回しにしない
検証できること	プロジェクトの一部として指定された機能すべてに対し、これらが適切に提供されたかどうかを判断するためのテストが用意されていること
首尾一貫していること	特に、矛盾する用語、相反する必須処理、そして実行不可能な組み合わせがないこと
修正作業が容易であること	重複部分がなく、索引や内容が正しいこと
出所が明確であること	参照される要求仕様すべてが一意的に確認できること
正確であること	記述された要求仕様すべてが、構築されるシステムに何らかの形で必要なものを示していること。これは当然のことのように思えるかもしれないが、関係のない要求仕様やまったく別のシステムに関する要求仕様が含まれてしまうことが驚くほど容易に発生する

　では、不適切な要求仕様はどのようにして見分けるのだろうか？ 上記の基準と照らし合わせて当てはまらなければ用心すべきである。

　私は先日、自分が見直しをしていた実際のプロジェクト要求仕様の中で次のような要求仕様を見つけた。

　「本アプリケーションは非常に高速かつパワフルでなくてはならない」

　この要求仕様に不備があることは明確だ。なぜならば、「高速」や「パワフル」は非常に主観的な言葉であるため、システムがこの要求仕様を満たすかどうかは検証できない。

●役立つ整理とツール

　時には、要求仕様は本質的に悪くはないものの、その数があまりにも多い（そして十分に整理されていない）ために役立たない場合もある。従来のソフトウェア要求仕様は「本システムは……をするものである」といった大量の宣言形式的文章であふれていた。だが、数千もの項目を一度に理解するのは人間にとって非常に困難なことである。そこで、要求仕様を分類し、整理することが役に立つ。大分類から階層化されて明確な関係を示す小分類へと分けることにより、分かりやすさとユーザビリティーが大きく前進する。機能仕様をユーザー指向で「物語」的に書くことも役立つ。ユーザー事例は、登場する「役者」がどのようにこのシステムを使い、このシステムがそれに対して何をするのかといったメカニズムを浮き彫りにしてくれる。このような目的指向のアプローチは、要求仕様の前後関係を整理し、分かりやすくするために役立つ。

　ツールも要求仕様を有用なものとするために役立つ。要求仕様を関連のない複数のドキュメントにまとめず、専門化された要求仕様データベースに格納しておけば、その整理、検索、そして選別は格段に容易なものになる。ソフトウェア開発チームのさまざまな役割を担う人々が、「さまざまな切り口」から好きな方法で分析できるのだ。例えばプロジェクトマネージャなら、インプリメントされた要求仕様の数、追加された新しい要求仕様の数、そして前の週に変更された要求仕様の数といった情報を取得するツールを使い、この要求仕様を利用してプロジェクトをスケジュールどおりに進めることができる。また、設計者であれば、プログラムが困難であったり、アーキテクチャに影響があると特定される要求仕様をすべて検索し、技術的なリスクを除去すべく、これらをプロジェクトの初期段階でインプリメントすることができる。ツールは適切な要求仕様の作成を手伝ってくれるものではないが、これらの整理と必要な情報の検索を助けてくれるのだ。

（3）「あまり関心がない」

　これは最も悲しい事例だ。一部には、適切なものさえ構築できればいいので要求仕様を作成する「時間がない」人もいる。このような人々は、政治的もしくは組織的な問題から絶望的だと思われるプロジェクトにかかわっていて、優れた要求仕様を作成しても何の役にも立たないと考えているのかもしれないし、新しい技術やテクニックに関する経験を積むといった個人的理由からそのプロジェクトにかかわることになったのかもしれない。理由が何であれ、人間が無関心であることは組織やツールが解決できない問題である。

（4）「アプリケーションがあまりにも新しい……」

　ソフトウェアプロジェクトは、明確に定義された問題を既知のソリューションによって解決するものばかりとは限らない。多くの人がコンピュータによって可能なことの範囲拡大に努めていて、システムの前例がまったくない場合は、潜在ユーザーに仕組みを説明してもらうことは非常に難しい。Dan Bricklin氏は1978年、ハーバード大学ビジネススクール在学中に最初の電子スプレッドシートである「VisiCalc」をApple向けに開発した。当時はこれに近いものがまったくなく、同氏が要求仕様を入手することは「ユーザーが存在しない」ので単純にあり得なかった。Napsterについても同様のことがいえる。ノースウエスタン大学を中退した18歳のShawn Fanning氏が1999年にNapsterを開発したときも、3カ月にわたって1日18時間の作業の末にオリジナルのソースコードを書き上げ、サイトを導入するに当たって、事前にさまざまな要求仕様をまとめるようなことはあり得なかった。でもこれは大成功を収めたのだ。

　このようなシステムは「探究的ソフトウェアエンジニアリング」とも呼ばれる。これらが最初にリリースされるときは、大規模な要求仕様の収集が大きな付加価値となることはあり得ない。だが、その後のリリースとなると話が違ってくる。ユーザーがそれを理解すると、彼らから何らかの要求や期待が生まれてくる。自分が「使える」と思う新機能を開発しても、これらの期待に沿えない場合があるのだ。ユーザーのニーズを聞き取って明確に表現し、文書化して整理し、それを利用して新機能を設計およびインプリメントすることが、優れたアイデアを失敗に終わらせず確実に発展させていくのに役立つのである。

■ライフサイクルを考えたインプリメンテーション

　要求仕様をまとめる時間がないという話は、通常は最初のリリース期限のことだけしか考えておらず、スケジュール、アーキテクチャとデザイン、テストとパフォーマンス、そしてユーザビリティーの各問題など、それを省くことがプロジェクトのライフサイクル全体に与える影響は考えていない。

●スケジュール

　自分が何をすべきか分かっていない場合、作業の完了はどのように判断すればよいのだろう。多くのソフトウェアプロジェクトで一般化している問題が、「機能の詰め込みすぎ」によって発生する導入の遅れだ。ある特定のリリースに対して搭載すべきものをコントロールしておかないと、さらなる機能の開発やインプリメントを求める場当たり的な要求が堰を切ったように出てくる。それぞれの要求の相対的な価値を判断したり、十分な情報に基づく判断を下すための手段がないと、「機能の詰め込みすぎ」や、期限に間に合わないという状況に陥ってしまう。明確に定義された要求仕様があれば、目標の推進にも、プロジェクト範囲の厳しい管理体制の維持にもつながらない機能に対する要求を容易に却下することができるのだ。

●アーキテクチャとデザイン

　システムで実現する機能範囲を高いレベルで理解していないと、簡単に融通が利かなかったりスケーラブルでないデザインになってしまう。既存の要求仕様は満たすものの将来的な変更を考慮していないアーキテクチャは、最終的には修正や拡張が困難になってしまう場合がある。明確に定義された要求仕様は修正や変更を予想しており、柔軟なアーキテクチャや全体的デザインのためのフレームワークを提供してくれる。

●テストとパフォーマンス

　要求仕様の用意されていないソフトウェアのテストは、「アプリケーションがクラッシュすることなく本来の動作をすることの確認」にすぎない。テスト担当者は機能しないGUIエレメント、システムクラッシュ、そして明らかな問題を探すことはできるものの、そのプログラムが本当にユーザーの目的を満たしているのか検証する手段を結局は持ち合わせていない。「するはずのことをする」というのは、品質の高いソフトウェアを示す単純な定義の1つだ。要求仕様はシステムがすべきことを規定してくれるので、自分たちが本当にユーザーの必要としている有効なシステムを開発しているのかどうか確認するためのテストを開発サイクルのごく初期の段階から始めることができる。

●ユーザビリティー

　また、デザインやテストを行うためのシステム機能仕様があっても失敗する可能性はある。例えば、ユーザーインターフェイスをどれだけシンプルにして処理時間をどれだけ高速にしなければならないのか、そのシステムが何人のユーザーをサポートしなければならないのか、そしてだれがそのシステムのメンテナンスをしなければならないのかをチームが理解していなければ、必要な機能は満たしながらも問題は解決してくれないというアプリケーションが簡単に出来上がってしまう。システム機能仕様以外の情報を提供することで、設計者や開発者がシステムの成功に不可欠なほかの要因を考慮せずに持ち時間のすべてを機能のインプリメントに費やすことは確実に防ぐことができる。

■詳しい調査

　ここまで読まれたら、後は自分の組織の中で「要求仕様をまとめる時間はない」などという会話を聞いたときにそれが意味する内容を考えてもらいたい。あなたのチームがまったく新しい何かを発明しているのであれば要求仕様をまとめずに作業を進めることができる。だが、大部分の組織のようにモデルや前例が豊富にある範囲内で作業を進めているのであれば、わずかな時間を割いて詳しい調査を行い、これらの人々の言葉が本当に意味している内容を見つけ出したい。彼らは各自の専門知識外である重要な判断を開発者に任せようとしているのだろうか？ 彼らは適切な要求仕様と不適切な要求仕様との違いを理解しているだろうか？ 彼らは単に開発を行うシステムに関心がないのだろうか？ 要求仕様を規定しない場合、彼らはそのプロジェクトのライフサイクルにおけるほかの分野への潜在的な影響を理解しているだろうか？ 真相を理解していれば、プロジェクトの崩壊ではなく完成に役立つ形でそのような会話に対処することができる。

本記事は「The Rational Edge」に掲載された「What Does "No Time for Requirements" Mean?」をアットマーク・アイティが翻訳したものです。

IT Architect 連載記事一覧