});次のような話を聞いたことはあるだろうか?「要求仕様をまとめる時間がない。コーディングに取り掛からないと納期には絶対に間に合わない」このような話(よく聞く話だが)は、個人もしくはチームの考え方や成熟度を測るための重要な手掛かりになる。本稿で詳しく見ていこう。「要求仕様」という単語には多くの定義があり、メソッド、プロセス、方法論、そして専門家ごとにそれぞれ固有の解釈があるようだ。要求仕様はそのプロジェクトが何を構築し、提供するのかを明確に記述すべきである、との点ではだれも異論はないはずだ。上述の話の中にある要求仕様という言葉をこの簡単な定義で置き換えると次のようになる。「構築および提供すべきものの内容をまとめている時間がない。要求仕様をまとめておかないとどうなってしまうのだろうか?■「要求仕様」の意味するものここで議論している言葉には、実際には次のいずれかの意味があるはずだ。1.「自分は要求仕様を理解している、もしくはすぐに明確にできる」2.「過去に扱った要求仕様が粗悪で、ない方がうまくいくと思う」3.「何を作ろうと、予定どおりに完成さえすれば(そして代金が回収できれば)あまり関心はない」4.「アプリケーションのアイデアがあまりにも新しい(もしくはあまりにもユニークな)ため、どうしても要求仕様をあらかじめ明確に定義することができない」いまから見ていくが、これらのどの解釈にも危険が潜んでいる。(1)「自分は要求仕様を理解している」これは「最も好意的な」解釈である。このプロジェクトの責任者は、要求仕様の内容を完璧に理解しているか、コーディング作業を進めていく中で明確にできると考えている。考えてみれば、この言葉が実際に意味するのは「自分のプロジェクトの開発者が要求仕様を理解しているか、それを明確にできる」ということになる。結局のところ、どのソフトウェアプログラムにしても機能をインプリメントするのは開発者の仕事なのだ。構築するものに関する仕様(つまり要求仕様)が文書化されず、承認も行われていない場合、何をインプリメントするのかは最終的には開発者の判断にゆだねられることになる。多くの組織では、これまではこのようなやり方がほとんどだった。このいわゆる「時代遅れの手法」がもはや許されない理由の1つとして、今日のプロジェクトが昔よりも複雑になっているという状況がある。これらは問題定義とインプリメンテーション定義という2つの分野で複雑化しているのだ。ナビゲーション、携帯電話の不法使用検知などなど、多くの専門的な目的でソフトウェアが利用されている。開発者の大部分が、これら特定の分野の解決すべき問題を把握もしくは理解しているとはとても思えない。アプリケーションの各分野も一段と複雑になり、プログラミングもそれに伴って複雑化している。堅牢なシステムを構築するために開発者が考えなければならない分散、並行、リアルタイム、相互関連といった各種コンポーネントや新しい言語などの問題は、すべてがコーディングの専門知識習得に対するプレッシャーとなって彼らにのしかかってくる。これらの新たな需要により、システムが解決しなければならない問題を見つけ出すべく開発者に与えられる時間や要員はさらに減ってきた。開発者が「すぐに明確にできる」ことを当てにできないもう1つの理由は、彼らに本質的な利益の衝突があることだ。これには自らの概算による場合もあれば、第三者の概算による場合もある。彼らに対して非常に漠然とした指示を出した場合には、その機能をインプリメントする際に数多くの選択肢が生まれてくることになる。このような場合には、彼らにとって最大の目標を達成する(通常の場合は期限内に完成させること)のに最適な方法を選ぶのが自然の流れだ。Interface)ビルダ向けに追加コードを書く仕事をしたことがある。私が追加しなくてはならなかったシステム機能仕様は「GUIエレメントのカラーをユーザーが指定できるようにする」というものだった。ユーザーがカラーを指定できるようにする方法は、テキストフォーマットでカラーのリストを表示してもよいし、さまざまなカラーのボックスを表示してその中から選ばせてもよいし、円形のカラーチャートを表示して選択させてもよいなど、いくらでもある。赤、緑、青(RGB)の値に1から255までの数値を入力させ、それらを組み合わせて好きなカラーを作り出すこともできる。この中には、ユーザーにとっては簡単だが開発者にとっては難しいというオプションもあれば、その逆もある。いまとなっては非常に悔やまれるのだが、私はこのときユーザーにRGBの値を入力させることにした。それは、これが自分にとって最もインプリメントの簡単なオプションであり、これによってスケジュールを守ることができたからだ。問題なのは、これがユーザーにとっては最も難しいオプションだったことだ。私がこの恥ずべき例を示したのは、ユーザーの要求仕様に関する重要な判断を開発者にゆだねると、開発者をどうしようもない状況に追いやり、満足のいかない結果につながることも多いことをこれが説明しているからだ。(2)「過去に扱った要求仕様が粗悪」プロジェクトマネージャが要求仕様の作成を無駄だと感じる理由の1つに、過去のプロジェクトで不適切な要求仕様に悩まされた経験が挙げられる。不適切な要求仕様はいろいろな形で現れるが、重要なのはこれらが実際に何かを構築するに当たって十分な情報を提供しないか、誤解を招く、もしくは矛盾するような情報を提供するかのいずれかである場合だ。このような場合には、それぞれの推測で作業を進めた方がプロジェクトがうまく進行するといえるだろう。これだけは覚えておいていただきたい。過去に不適切な要求仕様をベースにして作業を進めなければならない経緯があったからといって、今後もそれが繰り返されるとは限らないのだ。あなたのチームが有効かつ優れた要求仕様を作成するのを助けてくれる便利なガイドライン、テクニック、そしてツールを紹介しよう。Specification」によると、質の高い要求仕様の基準は以下のようになる。いずれの記述にもその解釈は1つしかないこと。重要な要求仕様がすべて含まれていること。記述された要求仕様すべてが、構築されるシステムに何らかの形で必要なものを示していること。上記の基準と照らし合わせて当てはまらなければ用心すべきである。私は先日、自分が見直しをしていた実際のプロジェクト要求仕様の中で次のような要求仕様を見つけた。「本アプリケーションは非常に高速かつパワフルでなくてはならない」この要求仕様に不備があることは明確だ。「高速」や「パワフル」は非常に主観的な言葉であるため、システムがこの要求仕様を満たすかどうかは検証できない。●役立つ整理とツール時には、要求仕様は本質的に悪くはないものの、その数があまりにも多い(そして十分に整理されていない)ために役立たない場合もある。従来のソフトウェア要求仕様は「本システムは......をするものである」といった大量の宣言形式的文章であふれていた。数千もの項目を一度に理解するのは人間にとって非常に困難なことである。そこで、要求仕様を分類し、整理することが役に立つ。大分類から階層化されて明確な関係を示す小分類へと分けることにより、分かりやすさとユーザビリティーが大きく前進する。機能仕様をユーザー指向で「物語」的に書くことも役立つ。ユーザー事例は、登場する「役者」がどのようにこのシステムを使い、このシステムがそれに対して何をするのかといったメカニズムを浮き彫りにしてくれる。このような目的指向のアプローチは、要求仕様の前後関係を整理し、分かりやすくするために役立つ。ツールも要求仕様を有用なものとするために役立つ。要求仕様を関連のない複数のドキュメントにまとめず、専門化された要求仕様データベースに格納しておけば、その整理、検索、そして選別は格段に容易なものになる。ソフトウェア開発チームのさまざまな役割を担う人々が、「さまざまな切り口」から好きな方法で分析できるのだ。プロジェクトマネージャなら、インプリメントされた要求仕様の数、追加された新しい要求仕様の数、そして前の週に変更された要求仕様の数といった情報を取得するツールを使い、この要求仕様を利用してプロジェクトをスケジュールどおりに進めることができる。設計者であれば、プログラムが困難であったり、アーキテクチャに影響があると特定される要求仕様をすべて検索し、技術的なリスクを除去すべく、これらをプロジェクトの初期段階でインプリメントすることができる。ツールは適切な要求仕様の作成を手伝ってくれるものではないが、これらの整理と必要な情報の検索を助けてくれるのだ。(3)「あまり関心がない」これは最も悲しい事例だ。一部には、適切なものさえ構築できればいいので要求仕様を作成する「時間がない」人もいる。このような人々は、政治的もしくは組織的な問題から絶望的だと思われるプロジェクトにかかわっていて、優れた要求仕様を作成しても何の役にも立たないと考えているのかもしれないし、新しい技術やテクニックに関する経験を積むといった個人的理由からそのプロジェクトにかかわることになったのかもしれない。理由が何であれ、人間が無関心であることは組織やツールが解決できない問題である。(4)「アプリケーションがあまりにも新しい......」ソフトウェアプロジェクトは、明確に定義された問題を既知のソリューションによって解決するものばかりとは限らない。多くの人がコンピュータによって可能なことの範囲拡大に努めていて、システムの前例がまったくない場合は、潜在ユーザーに仕組みを説明してもらうことは非常に難しい。Bricklin氏は1978年、ハーバード大学ビジネススクール在学中に最初の電子スプレッドシートである「VisiCalc」をApple向けに開発した。当時はこれに近いものがまったくなく、同氏が要求仕様を入手することは「ユーザーが存在しない」ので単純にあり得なかった。Napsterについても同様のことがいえる。Fanning氏が1999年にNapsterを開発したときも、3カ月にわたって1日18時間の作業の末にオリジナルのソースコードを書き上げ、サイトを導入するに当たって、事前にさまざまな要求仕様をまとめるようなことはあり得なかった。これは大成功を収めたのだ。このようなシステムは「探究的ソフトウェアエンジニアリング」とも呼ばれる。これらが最初にリリースされるときは、大規模な要求仕様の収集が大きな付加価値となることはあり得ない。その後のリリースとなると話が違ってくる。ユーザーがそれを理解すると、彼らから何らかの要求や期待が生まれてくる。自分が「使える」と思う新機能を開発しても、これらの期待に沿えない場合があるのだ。ユーザーのニーズを聞き取って明確に表現し、文書化して整理し、それを利用して新機能を設計およびインプリメントすることが、優れたアイデアを失敗に終わらせず確実に発展させていくのに役立つのである。■ライフサイクルを考えたインプリメンテーション要求仕様をまとめる時間がないという話は、通常は最初のリリース期限のことだけしか考えておらず、スケジュール、アーキテクチャとデザイン、テストとパフォーマンス、そしてユーザビリティーの各問題など、それを省くことがプロジェクトのライフサイクル全体に与える影響は考えていない。●スケジュール自分が何をすべきか分かっていない場合、作業の完了はどのように判断すればよいのだろう。多くのソフトウェアプロジェクトで一般化している問題が、「機能の詰め込みすぎ」によって発生する導入の遅れだ。ある特定のリリースに対して搭載すべきものをコントロールしておかないと、さらなる機能の開発やインプリメントを求める場当たり的な要求が堰を切ったように出てくる。それぞれの要求の相対的な価値を判断したり、十分な情報に基づく判断を下すための手段がないと、「機能の詰め込みすぎ」や、期限に間に合わないという状況に陥ってしまう。明確に定義された要求仕様があれば、目標の推進にも、プロジェクト範囲の厳しい管理体制の維持にもつながらない機能に対する要求を容易に却下することができるのだ。●アーキテクチャとデザインシステムで実現する機能範囲を高いレベルで理解していないと、簡単に融通が利かなかったりスケーラブルでないデザインになってしまう。既存の要求仕様は満たすものの将来的な変更を考慮していないアーキテクチャは、最終的には修正や拡張が困難になってしまう場合がある。明確に定義された要求仕様は修正や変更を予想しており、柔軟なアーキテクチャや全体的デザインのためのフレームワークを提供してくれる。●テストとパフォーマンス要求仕様の用意されていないソフトウェアのテストは、「アプリケーションがクラッシュすることなく本来の動作をすることの確認」にすぎない。テスト担当者は機能しないGUIエレメント、システムクラッシュ、そして明らかな問題を探すことはできるものの、そのプログラムが本当にユーザーの目的を満たしているのか検証する手段を結局は持ち合わせていない。「するはずのことをする」というのは、品質の高いソフトウェアを示す単純な定義の1つだ。要求仕様はシステムがすべきことを規定してくれるので、自分たちが本当にユーザーの必要としている有効なシステムを開発しているのかどうか確認するためのテストを開発サイクルのごく初期の段階から始めることができる。●ユーザビリティーまた、デザインやテストを行うためのシステム機能仕様があっても失敗する可能性はある。ユーザーインターフェイスをどれだけシンプルにして処理時間をどれだけ高速にしなければならないのか、そのシステムが何人のユーザーをサポートしなければならないのか、そしてだれがそのシステムのメンテナンスをしなければならないのかをチームが理解していなければ、必要な機能は満たしながらも問題は解決してくれないというアプリケーションが簡単に出来上がってしまう。システム機能仕様以外の情報を提供することで、設計者や開発者がシステムの成功に不可欠なほかの要因を考慮せずに持ち時間のすべてを機能のインプリメントに費やすことは確実に防ぐことができる。■詳しい調査ここまで読まれたら、後は自分の組織の中で「要求仕様をまとめる時間はない」などという会話を聞いたときにそれが意味する内容を考えてもらいたい。あなたのチームがまったく新しい何かを発明しているのであれば要求仕様をまとめずに作業を進めることができる。大部分の組織のようにモデルや前例が豊富にある範囲内で作業を進めているのであれば、わずかな時間を割いて詳しい調査を行い、これらの人々の言葉が本当に意味している内容を見つけ出したい。真相を理解していれば、プロジェクトの崩壊ではなく完成に役立つ形でそのような会話に対処することができる。Mean?」をアットマーク・アイティが翻訳したものです。広告に関するお問い合わせメールマガジンSpecialインデックスRSSfacebooktwitter利用規約ITmediaはアイティメディア株式会社の登録商標です。