要件把握をセッションを主導する

6 分

一般的に、要件把握セッションはソリューションアーキテクトの主導で行われます。これらのセッションの目標は、実装可能なシステム要件に対する全体的なニーズを特定することです。プリセールスフェーズの段階でも同じソリューションアーキテクトが参加していたのであれば、それらのソリューションアーキテクトは、顧客のニーズと成功要因をすでに理解している可能性があります。そうでない場合は、最初のセッションの前に、ソリューションアーキテクチャに十分な情報が提供される必要があります。これらの情報は、出席者とのディスカッションを効果的に進めるために使用できます。

それらのミーティングを通じて経験を増やしていくことにより、効果的な方法論を採用できるようになります。プロジェクトや顧客ごとのニーズに応じて、柔軟に対応するようにしましょう。要件把握セッションに臨むにあたっては、プラン、テンプレート、および目標とする結果を事前にまとめておく必要がありますが、それらに縛られるあまり、議論、創造性、および解決策の幅が制限されることのないようにしましょう。

要件の全体像

プロジェクトにおいて要件がどのように文書化されるかは、採用される方法論によって変わってきます。ただし、いずれの場合も、「だれが」、「何を」、「なぜ」という観点から要件を把握する必要があります。これらのパラメーターは、ユーザーストーリーとしてまとめたり、明細行品目の要件に指定することができますが、いずれにせよ、検証可能かつ説明可能なものにする必要があります。要件を効果的に整理するには、次のポイントを押さえるようにしましょう。

だれがその要件を要求しているのか
顧客のニーズはどのようなものなのか
顧客の目的は何なのか

要件やストーリーの内容が多い場合は、それらを管理しやすいパーツに分ける必要があります。これらのパーツは、方法論によって異なる用語で呼ばれます。たとえば、アジャイルアプローチでは、エピッキングと呼ばれます。呼び名はともかく、ソリューションアーキテクトは、そのプロセスが確実に実施されるように注意を払う必要があります。

優先順位付け

どのようなプロジェクトでも、要件を実施するために費やせる時間とリソースには限りがあります。そのため、ソリューションアーキテクトは、プロジェクトチームや顧客と協議しながら、要件のリストやバックログについて優先順位を決める必要があります。

ビジネスアプリケーションのプロジェクトでは、デプロイが段階的に実施されることが多いので、担当チームは通常、優先される実用最小限製品 (MVP) を最初に決める必要があります。 MVP を決めることで、初期段階で実施する必要がある要件を特定することができます。また、残りの項目は、今後のイテレーションやスプリントの対象として分類できます。

ソリューションアーキテクトは、特定された主要ビジネス目標を使用して、要件を評価する必要があります。目標の達成に大きく寄与する要件に対し、より高い優先順位を指定するようにしましょう。そうすることで、重要ながらも主要目標の達成には寄与しない要件がある場合に、それらを主要目標から切り離すこともできます。

実現可能性

ソリューションアーキテクトは、要件を評価して、それらが実現可能かどうかを確認する必要があります。実現するのが理想的ではあるものの、さまざまな理由で達成できない要件を特定しましょう。たとえば、次のような要件がこれに該当します。

必要なデータが用意できない。
他のシステムの更新が必要になるが、プロジェクトの時間枠内では達成できない。

ソリューションアーキテクトが確認するべきチェック事項: "要件を達成するうえでの阻害要因はないか?"

出席者の管理

要件把握セッションに臨む前に、予想される状況を検討して、適切な出席者を特定するようにしましょう。望ましいのは、対象分野についての知識がある、経験豊富なメンバーを揃えることです。また、短時間の小規模なセッションを複数回実施することで、目的に特化した、生産性の高いセッションを実現することができます。プロセスのパーツごとにそれぞれ専門の担当者を招くようにすると、プロセスの各部がどのように機能するかを全体像でとらえることができるので、非常に効果的です。多くの場合は、このアプローチをとることで、不足している機能要素を後から補充する手間が省けます。

また、経営陣に参加してもらうと、より確定的な情報が得やすくなるので、これも効果的です。ただし、シニアマネージャーが出席するとなると、社内スタッフの参加意欲に影響が出る可能性があるので、その点には注意が必要です。そのような場合、社内スタッフの発言が減り、失言を恐れて上司の意向に沿った意見ばかり言うようになる傾向があります。好ましくない状況が予想される場合は、セッションを分けて開くようにしたり、一部のセッションについては参加を控えるようにマネージャーに要請するなど、必要な対応をとったほうが良いかもしれません。

セッション前の準備作業

ソリューションアーキテクトは、セッションの前に、現行のソリューションやそのプロセスについて、できるだけ多くの情報を収集する必要があります。それらの情報を事前に調べることで、ディスカッションをスムーズに進めるための想定問答を準備することができます。出席者にとっても、準備の時間が設けられれば、セッションで使用する文書や事例を準備しやすくなります。

また、プリセールスチームが収集した情報も忘れずに確認するようにしましょう。既に話し合われた内容と同じことが、顧客によって再び持ち出されないようにすることも重要です。これまでの経緯を十分把握するために、過去のデモ録画がないかどうか確認するようにしましょう。

要件の明確化

多くの場合、ビジネスユーザーから寄せられる初期段階の要件は、実際の要件とイコールではありません。ソリューションアーキテクトが調査を行って、ユーザーの意見を引き出したり、他の関係者とやり取りをしながら、本質的な要件を導き出す必要があります。ソリューションアーキテクトは、ユーザーの気分を害したり、仕事の仕方が下手だという意味にとられないようにしながら、
相手に "理由" を尋ねる質問の方法を習得する必要があります。質問の本当の目的は、中核的な問題点を理解して、最良のソリューションをデザインできるようにすることです。

共通性のある質問をあらかじめ用意しておくと、情報を効果的に引き出すことができます。

そのプロセスは1日で完了できますか。
このプロセスには、他にだれが関与しますか。
その情報はどこから得たものですか。
なぜそのプロセスが必要なのかについて説明していただけますか。

当初用意していた質問が自由回答形式の質問である場合は、「はい/いいえ」で回答する質問に組み立て直すことで、本質的な要件やニーズをより把握しやすくなります。次に示すのは、ソリューションアーキテクト (SA) とビジネスユーザーの間での簡単なやり取りの例です。

ユーザー: 過去 30 日以内のすべての期限切れ取引に関するレポートを印刷する必要があります。

SA: レポートを使用するのはだれですか。

ユーザー: 管理者が使用します。

SA: マネージャー、あなたはこのレポートをどのように使用しますか。これがレポートの形式である必要はありますか。それとも、先月の期限切れ取引を直接尋ねる方法でも事足りますか。

マネージャー: レポートを見るのは月に 1 回だけなので、それでも問題ありません。

SA: データに目を通す際、どのようなことを確認するのですか。

マネージャー: 5 万ドル以上の取引を探し、それらについて詳細なレビューを行います。

SA: それでは、5 万ドル以上の期限切れ取引だけを表示して確認できるシステムにしたら、そのほうが便利ですか。

マネージャー: はい、それだと非常に助かります。

改訂後の要件: マネージャーが、5 万ドル以上の期限切れ取引を毎月レビューする必要がある。

ソリューションアーキテクトが十分な質問をしていなければ、このチームでは紙のレポートを作成することになっていたでしょう。必ず、ニーズを完全に把握できたという確信にいたるまで、"理由" をたずねていくようにしましょう。

競合する要件の解決

ビジネスユーザーの間で、相互に競合する要件が生じることは少なくありません。そのため、顧客側から、強い決定権を持つ人物に参加してもらうことが必要不可欠となります。ソリューションアーキテクトは、アイデアや妥協案を提示することで、関係者を合意へと導くことができます。ただし、組織内の権力的対立には関与しないようにしましょう。

ビジョンの主張

ソリューションアーキテクトは、要件の正当性を、敬意ある態度でメンバーに理解させる能力を身につける必要があります。そのためには、考えたソリューションのビジョンをわかりやすく伝えて、そのビジョンが目標の達成にいかに寄与するかを顧客に理解させるスキルが必要です。新任のソリューションアーキテクトの場合、態度が上から目線だと受け止められることで、セッションの進展に問題が生じることが少なくありません。顧客にビジョンを伝える際には、顧客の意見を軽視した態度にならないよう注意しましょう。

演習: 要件把握セッションのプランニング

Woodgrove Bank の各チームについて、情報を確認してください。それらのチームの中から、要件収集に参加してもらうチームを決定してください。要件収集の対象から除外するチームを決定してください。それらの決定を下した理由を説明してください。

続行