ITマネジメント

ソーシャルブックマークに登録：
印刷用ページの表示

適切な要求仕様を仕上げるための8つの秘訣
──“曖昧さ”がコストを肥大化させる

（2006年08月17日）

　プロジェクトを成功させたいのなら、何はともあれスタートが肝心だ。とにもかくにも、まず最初に、適切な要求仕様をまとめ上げなければ、成功はおぼつかない。だが、その方法は千差万別、ビジネス・アナリストの数だけ存在すると言っても過言ではない。そこで、本稿では、要求仕様をまとめるうえでの秘訣を、8つに整理して紹介したい。

メアリ・プラット
Computerworld オンライン米国版

　ここで、8つの秘訣を紹介する前に、読者の皆さんに理解しておいていただきたいことがある。それは、間違った意思疎通、間違った解釈、ユーザーに対する無理解が、不透明で不完全な要求仕様を生み出すということだ。ペンシルベニア州キング・オブ・プロシアに本拠を構える電子コマース・サービス・プロバイダー、GSIコマースの上級ビジネス・アナリスト、アンドリュー・アリ・クリバノフ氏も、「曖昧さを極力排除しなければならない。曖昧であることが欠陥を生む」と断言する。

　こうしたことをおざなりにしたまま要求仕様を固めてしまうと、結局は高くつくことになる。インディアナ州カーメルを本拠とするEBGコンサルティングの主席コンサルタントで、『The Software Requirements Memory Jogger』（Goal QPC Inc., 2005）の著者でもあるエレン・ゴッテスディーナ氏によると、一般に、プロジェクト予算のおよそ3分の1は、間違った要求仕様に起因する欠陥を修正するために費やされているという。

　それでは、以下、8つの秘訣を紹介しよう。

【秘訣その1】全体的な目標を明確にする

　プロジェクトの要求仕様を固める前に、会社（組織）としての目標をきちんと理解しておく必要がある。

　「まず基準を定めなければならない。組織としての戦略は何か、中長期的に目指すものは何か、といったことをはっきりとさせておくべきなのだ」と語るのは、ペンシルベニア州ニュートンスクエアに本社を置くプロジェクト・マネジメント・インスティテュートのカスタムケア＆テクノロジー担当ディレクター、ジョセフィン・デイ氏だ。

　目標が明確に定義されていれば、利害関係者やユーザーを正しく識別し、プロジェクトによって影響を受ける他のプログラムを特定することができる。いずれもプロジェクトを成功させるためには不可欠のステップだ、というのがデイ氏の主張なのである。

【秘訣その2】あらゆるツールを活用する

　要求仕様をまとめるためのツールにはさまざまなものがあるが、マサチューセッツ州スプリングフィールドのマサチューセッツ生命保険相互会社でシステム・アーキテクトを務めるスーザン・バーク氏は、そのための最良のアプローチとして“セルフ・ドキュメント化推進ワークショップ”を提唱する。

　「決定権のある人々を会議室に集め、有能な進行役と筆記者を置き、徹底的に議論すれば、会議の最後に要求仕様は完成している」と同氏。このアプローチでは、要求仕様のドラフトをその場で確認できるため、ミス・コミュニケーションを回避することもできるという。

　ただし、この方法も含め、1つの情報収集アプローチに依存しすぎるのは好ましくない。「要求仕様を検討する方法は1つだけではない」と、バーク氏もそれを認める。

　ゴッテスディーナ氏によれば、代表的な手法としては、インタビュー、プロトタイプによる実験、ワークショップの設置、従来から用いられてきたプレーンな観測などがあるという。

　さらにゴッテスディーナ氏は、要求仕様をまとめるビジネス・アナリストは、プロジェクトのスポンサーとなるビジネス・リーダーや実際にプロジェクトを推進する人、開発したシステムを利用するユーザーなど、関係者全員とインタビューする必要があり、「ワークショップなどでも、カギを握る関係者と緊密に連携することが求められる」と指摘する。

　その場合、だれといつ話し合うか、といったことも重要になる。プロジェクト・チームでまだビジョンの構築などが検討されている段階では、プロジェクトのスポンサーなど、ハイレベルな関係者を招くべきだが、具体的に要求仕様を固める段階ともなれば、実際に利用するユーザーの声を聞くことが大事になるというわけである。

　有益な情報を得るためのもう1つの方法は、プロジェクトによって解決するプロセスを現在人々がどのように処理しているかを、実際に観察してみることだ。この“現場実習”が常に実行可能であるとは限らないが、「これはビジネス・アナリストにとってきわめて有効な情報収集テクニックだと言える」と、ゴッテスディーナ氏は強調する。

　もう1つのクリエイティブなテクニックは、ユーザー自身に開発するシステムのマニュアルを書かせることだ。そうすることで、「ユーザーはシステムとどのようにやり取りすればよいかを考え、それが最終的にシステムがどうあるべきかというビジョンを確立するうえでも役に立つことになる」と同氏。

【秘訣その3】カバーすべき分野を把握する

　ユーザーの要求を収集する万能の手法というものは存在しないが、何よりも重要なのは、対応しなければならない範囲について知っておくことだ。そのために役に立つのがチェックリストである。

　JPモルガン・チェース・アンド・カンパニーの元上級副社長でプロジェクト室の責任者だったピーター・ロッジマン氏は、チェックリストの重点項目として、次の4点を挙げる（なお、同氏は現在、ニューヨーク州ニューロシェルでコンサルティング会社のプロフィッタブル・プロジェクツを経営している）。

●柔軟性：ユーザーが求めているものは何か？　それが将来変化する可能性は？

●接続性：データを必要とするのはだれか？　データを操作するのはだれか？　アプリケーションに接続する他のシステムは？　一言で説明すれば、「データはどこから来てどこへ行くのか？」（ロッジマン氏）

●プロセス：アプリケーションがくぐるプロセスは？　人々は、どうなるかは知っていても、それを明確に説明することは苦手だ。「それを手助けする必要がある」（ロッジマン氏）

●キャパシティ：現在および将来において、システムはどれほどのトランザクションを処理しなければならないのか？

【秘訣その４】いつ、だれと話すかを吟味する

　「適切な時点で、適切なレベルの人物と、適切なテーマについて話すことが重要だ」と指摘するのは、ニューハンプシャー州ベッドフォードにあるウェレット＆アソシエイツの上級ファシリテータ、ビル・ハガーアップ氏だ。例えば、ハイレベルの管理職は、全体像と将来の展望を示してくれるだろう。一方、ローレベルの従業員は、具体的なニーズについて詳細に教えてくれるはずだ。

　ただし、そのためには少しばかり厄介な政治的状況を打開しなければならない──そう語るのは、オマハにあるコンサルティング会社、TDアメリトレードのビジネス・アナリスト、シェリー・カドレー氏だ。同氏はこれまで、いくつものプロジェクトに関与してきたが、最初に会った人の話と次に会った人の話が食い違い、3番目に会った人の話はさらにあさっての方向へ向かってしまうといった状況に遭遇することも珍しくなかったという。

　「（1つのプロジェクトにも）さまざまな意見や考え方がある。そうした状況を打開するには、まずは“人を知る”ということから始めなければならない」（カドレー氏）

　それはまさにビジネス・アナリストのソフト・スキルであり、「ビジネス・アナリストたる者は、人づきあいの巧みさを磨く必要がある」とカドレー氏。同氏によれば、例えば出張などの機会にスタッフと時間をかけて話し合うことで、問題解決の糸口を見いだせることもあるという。

　また、ハガーアップ氏も、「ビジネス・アナリストはクライアントと積極的にランチやゴルフに出かけ、緊密な関係を築きながら、権力闘争を回避し、調和を図る必要がある」と、社交性の重要性を訴える。

【秘訣その5】あらゆるチャネルを利用する

　人づきあいを大事にしていても、オフィシャル・チャネルだけにとらわれていたのでは、あまり意味がない。カドレー氏は、「私は優れた情報源をいくつか持っているが、相手は、プロジェクトに直接関与している人であるとは限らない」と打ち明ける。同氏は、“優れた分析能力を持った”ビジネス・サイドの上級管理職と頻繁にコンタクトし、プロジェクトが会社全体にどのような影響を及ぼすか、といった視点で意見を聞いたり、会っておくべきマネジャーの名前を教えてもらったりしているという。

【秘訣その6】現場を知る

　ユーザー・ニーズを正しく理解するためには、ときにはビジネス・クライアントと同じ体験をすることも必要である。「彼らの目線で考えることが重要」（ハガーアップ氏）だからだ。

　1970年代、バーガーキングの上級プログラマーだったハガーアップ氏は、今日においてはファーストフード・レストランでごく一般的になったシステムの開発に従事していた。当時、バーガーキングでは、すべての社員に、年に1週間、レストランの現場で働くことが義務づけられていたという。「現場では、さまざまな仕事を手早く処理する必要があった。そうした現場の苦労を学ぶことで、仕事の本質を理解することができた」と、同氏は振り返る。

【秘訣その7】すべての流れをひととおり経験する

　GSIコマースのクリバノフ氏は最近、海外への製品出荷を容易にするソフトウェア・プログラムについて、ユーザーの要求仕様をまとめる必要に迫られたことがある。そのとき同氏は、何が求められているかについて、より具体的な感覚をつかむべく、カスタマー・サービスを担当するプログラム・マネジャーや出荷グループのオペレーション・マネジャーとともに、英国の架空の顧客が2店のオンライン・スポーツ用品店で買い物をするというシナリオを考えた。

　利害関係者を集めたワークショップで、クリバノフ氏は2人のマネジャーにこのシナリオに基づいたプレゼンテーションを行わせ、全員でトランザクションの流れを確認した後、ソフトウェアがどのような機能を持つべきかについて議論した。

　「それは、最終地点からスタート地点へとさかのぼるアプローチだった。そして、そのプロセスが終了したとき、われわれの前には完璧な要求仕様が出来上がっていた」（クリバノフ氏）

【秘訣その8】徹底的に問いかける

　要求仕様をまとめるにあたっては、「情報収集の懐疑論者になるべきだ」と主張するのは、マサチューセッツ州ランドルフにあるコンサルティング会社、カーテン・アソシエイツの代表、ナオミ・カーテン氏だ。「どんなことでも額面どおりには受け取らず、自分の理解が正しいかどうか常に疑ってかかるべきだ。前提そのものさえ疑い、疑問に思うことは徹底的に質問する必要がある」

　一見、非効率的にも思えるこの主張だが、カーテン氏はその有効性を説く。この手法を使えば、要求仕様を完成させるために必要な情報をすべて引き出すことができるというのだ。

　「アナリストは社交上のスキルを駆使して、この手法の有効性を引き出すべきだ」と、カドレー氏もカーテン氏に同調する。実際、カドレー氏もまた、しばしば同じ人に向けて、同じ質問を繰り返すという。ただし、表現を変えるように心がけているため、それほど嫌がられることはない。

　また同氏は、同じ質問を別の人にぶつける際には、“外交的手腕”も駆使する。例えば、「ある方からこのような話をうかがいましたが、正しく理解できているかどうか自信がありません。申し訳ありませんが、もう1度あなたから説明していただけますか」、あるいは、「ある方とこういうテーマで議論をしましたが、この件についてあなたの意見を聞かせてもらえませんか」という具合に問いかけるのだ。

　しかも、カドレー氏の場合、そこでは終わらない。インタビューが終わった後、もう1度、「質問すべきことで、まだ質問していないことはないか」と自問するのだ。こうした質問方法は、「ときとして思いも寄らぬ重要な情報を引き出すことがある」（カドレー氏）という。

態度は時に言葉より重要

　「ユーザーに的確な質問をすることができたからと言って、それで成功が約束されたわけではない」と、カーテン・アソシエイツの代表、ナオミ・カーテン氏が語るように、言葉は正しくても、間違ったボディ・ランゲージや自信がなさそうな態度を見せれば、たちまち会話は滞り、要求仕様に不可欠な情報を引き出すことができなくなる。「忍耐に欠ける態度や不快そうな表情を見せれば、すべてがそこで止まってしまうことになる」と同氏は警告する。

　カーテン氏は以前、参加者を3つのグループに分けたワークショップを立ち上げたことがある。最初のグループはITワーカーの役を担い、2番目のグループはユーザーを演じ、最後のグループは観客となった。ロールプレイングの中で、“ユーザー”の1人は、ITワーカーがインタビューの途中、定期的に深く呼吸したことを「忍耐が限界に来た兆候」だと感じ、応答を手短に切り上げたと報告した。

　別のケースでは、“ITワーカー”が何か言いたいことがあって、話し出すチャンスをしきりにうかがっていた。ロールプレイングのパートナーは、その態度から、ITワーカーがまるで相手の話に耳を貸さない人物のように見えた、と感想を述べた。

　こうした経験を踏まえて、カーテン氏は、「ちょっとしたことが、自分の本心とはまったく異なる印象を相手に与えてしまうことになるため、インタビュー中の態度には細心の注意が必要だ」とアドバイスする。

(Computerworld.jp)