デリバリー・ホライゾンの目的は

ソリューションデリバリーについての決定を通知することです。 そして、

• ニーズについての共通理解があることを確認し、ニーズを満たすアクションのバックログを特定して優先順位を付け、成果を評価する手段を確立します。
• ビジネス・ゴールに至るように要求をマッピングします。
• ユーザー・ストーリーをスライスして詳細化し、チームがソリューションの動作するインクリメントとして実装できるようにします。
• このインクリメントはバックログ項目に追加され、実装可能なビジネス価値の単位へと洗練され、さらに詳細化されます。
• テストや顧客の評価によるフィードバックを受け、バックログから項目を作成、変更、再優先順位付け、削除します。

要素

デリバリー・ホライゾンで実践するべきこと（要素）は以下の通りです。

１．ユーザー・ストーリーのReadyを確実にする

（直後に実装する分だけ：ジャスト・イン・タイム）

• よく構成された物語が含まれている
• 明確で、簡潔で、正確な受け入れ基準のセットを提示している。
• 望ましい実装単位を表すものとして受け入れられている。
• 達成可能な開発単位を表している。
• バックログ内で明確に優先順位が付いている。

２．バックログの保守

2つの基本要素

• バックログ項目の優先順位付け
• 直近の開発作業にを支援するのに十分な項目のバックログへの確保

上図のように、ｎ回目のスプリントの間にその直後に実装するべきストーリーの要求を分析したりしてスプリントバックログの項目を確保するようにします。

３．デリバリーの成功をサポート

• ストーリーに関連する順序付けと依存関係の適切な処理、
• 外部チームおよびステークホルダーとの調整（チームは開発に専念）、
• 現在実装中の項目に関する明確な質問への回答など

ビジネスアナリストのリーダーシップの発揮のしどころです。チーム・エンゲージメントを高めることが極めて重要です。

４．アジャイル・コンテキストでの学習を確実に行われるようにする

• 学習がより良いアウトカムを達成するために使用されるようにする。より良いアウトカムは、定量的または定性的に説明できる。
•  次のデリバリー・サイクルでどのデリバリー・プロセスを変更、保持、または停止する必要があるかを検討する
• レトロスペクティブは、多くの場合、継続的なデリバリー・プロセスの向上を目的とし、最新のデリバリー・プロセスからの学習について議論するために使用される。
• 最新のインクリメントで提供された価値が期待されたものであったかどうかを検討し、必要に応じてイニシアチブまたは戦略ホライゾンにフィードバックする。

５．プロダクトビジョン、顧客、価値に焦点を当て続ける

• ビジネスアナリシス・テクニックとアジャイル・ビジネスアナリシスの原則を適用して、求められている価値を提供し、プロダクトビジョンを達成することに重点置く。

フィードバックと学習

• フィードバックは陣族で、理想的には小さな塊で行う
• 実装されたストーリーからフィードバックを評価
  →　価値をもたらす可能性のあるもの、そうでないものを特定
  →　バックログを洗練
• バックログ項目の、優先順位を変更、変更、削除
• 新しいストーリーを追加できる。
• フィードバックは、レトロスペクティブやレビューなどの構造化されたプロセスのほか、日常的なやりとりや実装を通じて非公式にも行われる。

アジャイルBA原則の適用

・全体を見る

・顧客として考える

・価値あるものは何かを決めるために分析する

・例を使って真実を得る

・実行可能なものは何かを理解する

・コラボレーションと継続的改善を促進する

・無駄を省く

イニシアチブ・ホライゾンの目的は

ソリューション案、フィーチャー、優先順位、およびライフスパンに関する意思決定を明らかにすることです。
そして以下のような質問に対して回答できなければいけません：

• ニーズを満足させるソリューション案は何か？
• 最小限のアウトプットで最大限のアウトカムを提供できるソリューション案はどれか？
• 推奨されるソリューション案のフィーチャーによって記述されるソリューション・コンポーネントは何か？
• ニーズを満たす十分な価値が提供されているか？
• フィードバックと学習に基づき、ソリューションは継続し、変化し、あるいは取り消される必要があるのか？

要素：

イニシアチブ・ホライゾンで実践するべきこと（要素）は以下の通りですがBABOKガイドのタスクに対応しています。

1.ソリューション案を特定する

引き出し、モデル化、デザイン案定義までのタスクに対応します。

2.ソリューション案を推奨する

ソリューションを推奨するタスク

3.ソリューション・コンポーネントを特定する

デザイン案定義のタスクの「要求の割り当て」です。

4.ソリューション・コンポーネントの優先順位付け

「要求に優先順位をつける」タスクです。

→ここでデリバリー・ホライゾンに移ります。

5. ニーズが満たされているかどうかの判断

→デリバリー・ホライゾンの結果を知識エリア「ソリューション評価」で行います。

6.ソリューションの実現性の継続的評価

→戦略ホライゾンに結果をフィードバックします。

このように、イニシアチブ・ホライゾンの活動はサンドイッチ構造と考えられます。

要求をコンポーネントに割り当て、優先順位を付けたらデリバリー・ホライゾンにわたして作業してもらい、その結果を評価して必要に応じて戦略ホライゾンに伝えることになります。

参考までに、BABOKガイドの3つの知識エリアのタスクを紹介します。

知識エリア「要求アナリシスとデザイン定義」の6つのタスク

• 要求を精緻化しモデル化する：分析手法を使用して、一連の要求とデザインを詳細に記述します。
• 要求を検証する：一連の要求またはデザインが、特定のステークホルダーが使用できる程度の詳細さで作成されており、内部矛盾がなく、高い品質を備えていることを確実にします。
• 要求の妥当性を確認する：一連の要求またはデザインが、ビジネス価値を提供し、組織のゴールと目標に貢献することを確実にします。
• 要求アーキテクチャーを定義する：すべての要求とデザインが、チェンジにおけるビジネス目的全体に役立ち、高い凝集性を持って、全体としてまとまって働くように構造化します。
• デザイン案を定義する：ニーズを満たすさまざまな実現方法を特定し、調査し、記述します。
• 潜在価値を分析しソリューションを推奨する：ソリューション候補に関するビジネス価値を評価し、トレードオフを含めて異なる実現方法を比較します。そして全体の価値を最大化できるソリューションを特定し、推奨します。

 知識エリア「要求のライフサイクル・マネジメント」の5つのタスク

• 要求をトレースする：影響分析や、カバレッジ、割り当てのために、要求、デザイン、ソリューション・コンポーネント、その他のワーク・プロダクト間の関係を分析し、維持します。
• 要求を維持する：ライフサイクル全体を通じて要求とデザインを正確かつ最新に保ち、状況に応じた再利用を容易にします。
• 要求に優先順位を付ける：特定の要求とデザインに関連する価値、緊急性、リスクをアセスメントし、常に、最も重要なものに対して分析または実装、もしくはその両方に関する作業が実施されるようにします。
• 要求変更を評価する：新たなステークホルダー要求および変更されたステークホルダー要求を評価し、チェンジのスコープ内で対応する必要があるかどうかを判断します。
• 要求を承認する：ガバナンス・プロセスに関与するステークホルダーと協力し、要求およびデザインについて承認を獲得し、合意を形成します。

 知識エリア「ソリューション評価」の5つのタスク

• ソリューション・パフォーマンスを測定する：ソリューションがエンタープライズのゴールおよび目標とどのように整合しているかを含めて、ソリューション・パフォーマンスを評価する最適な方法を特定し、評価を実施します。
• パフォーマンス測定結果を分析する：ソリューションがエンタープライズとステークホルダーに提供する価値を理解し、ソリューションが現在のビジネス・ニーズを満たしているか判断するために、ソリューションのパフォーマンスに関する情報を調べます。
• ソリューションによる限界を評価する：ソリューションが現在のビジネス・ニーズを満たすのを妨げる可能性のある課題を、ソリューション・スコープの範囲内で調査します。
• エンタープライズによる限界を評価する：ソリューションが提供できる価値の最大限の実現について、エンタープライズを妨げる可能性のある課題を、ソリューション・スコープの範囲で調査します。
• ソリューションの価値を向上させるアクションを推奨する：ソリューションが提供できる価値を増大させるために、エンタープライズがとれるアクションを特定し、定義します。

大切なのはデリバリー・ホライゾンからのフィードバックと学習です。

• ソリューション案は、今でも適切か。
• 選択したソリューション・コンポーネントは、今でも適切か。
• ソリューション・コンポーネントの優先順位と実行順序が適切に付けられているか。
• 望む成果を実現するためには、すべてのソリューション・コンポーネントをデリバリーする必要があるか。

 イニシアチブ・ホライゾンでもアジャイルBAの原則を適用します。

• 全体を見る
• 顧客として考える
• 価値あるものは何かを決めるために分析する
• 例を使って真実を得る
• 実行可能なものは何かを理解する
• コラボレーションと継続的改善を促進する
• 無駄を省く

菅政権が発足しデジタル庁の創設が決まりましたが、課題は山積みのようです。3度目の正直という改革がどこまでできるのか、気をもむところもありますが、D庁こそビジネスアナリシスが必要になることだけは間違いがありません。「デジタル敗戦」の一つの要因としてグローバル標準の上流工程をないがしろにしていたことがあるのではないでしょうか。大臣の言葉の一つに「アジャイルガバメント」があります（日経コンピュータ誌10月29日）。こういう用語を使用できる方が大臣に就任されたのは大変喜ばしいことで、ぜひご活躍されることを期待したいと思います。

そのアジャイルですが、IIBA日本支部から「BABOKガイドアジャイル拡張版バージョン2（日本語訳）」が今年の7月に発行されました（英語版は2017年に発行）。これはスクラムやXPなどの小規模なアジャイルソフトウェア開発を対象とするのではなく、大規模、エンタープライズレベルでのアジャイル開発に焦点を置いた全く新しいビジネスアナリシスの考え方で、ソフトウェア開発のみならず任意のビジネス領域にまで拡張されたものです。

エンタープライズ環境でアジャイル開発するために最も重要なことは組織戦略とイニシアチブをしっかりリンクすることです。従来の小規模のアジャイル開発（スクラムやXP）では想像のつかない重要な活動です。スクラムチームのメンバーが頻繁に経営層とユーザーストーリーについて意見を交わすことはできません。顧客ニーズを価値提案に変換し経営的ニーズ（ビジネスニーズ）に結び付けるためにはその橋渡しとなるビジネスアナリシスの存在が必須です。それがエンタープライズ・アジャイルにビジネスアナリシスが不可欠になる理由です。

このたび、「エンタープライズ・アジャイルに不可欠なビジネスアナリシス」と題してオンラインセミナーを開催する運びとなりましたので、ご案内申し上げます。尚、筆者はこの「BABOKのアジャイル拡張版V2」の日本語訳をし、内容に精通していますので解説させていただきます。

セミナー概要

• 日時：　　12月21日（月）　15：00　～　17：00
• 場所：　　オンライン（Zoom）
• 参加費：　無料
• 講師：　　清水千博、CBAP：　ＫＢマネジメント代表
• 定員　：　50名
• 尚、Zoom情報はセミナー開始前日までに申込者にお知らせいたします。

アジェンダ

1. グローバル環境におけるアジャイル開発の現状
2. エンタープライズ・アジャイルにおけるビジネスアナリシス
   －アジャイル拡張版の位置づけ
   －アジャイルマインドセット
   －3つのホライゾン
   －戦略ホライゾンとＢＡＢＯＫの関係
   －イニシアチブ・ホライゾンとＢＡＢＯＫとの関係
   －デリバリー・ホライゾンとＢＡＢＯＫとの関係
3. ＫＢマネジメントが提供するビジネスアナリシス研修

詳細とセミナー申し込みは

こちらをクリック

3つのホライゾンの概要です。

• 戦略ホライゾンは、組織内で行われているすべての作業のスコープで、組織全体に影響を与える意思決定に関することを対象として、3ヵ月～数年の期間で行います。
• イニシアチブ・ホライゾンは、単一の最終成果物（プロダクト）を生産するために必要な作業スコープで、特定のゴール、イニシアチブ、チームに影響を与える意思決定に関することを対象として、単一チームまたは複数チームの意思決定者をサポートし、今後１～3か月の期間で行います。
• デリバリー・ホライゾンは、作業が発生する場でプロダクトの個々の部分を構築するスコープで、ソリューションのデリバリーについて行われる意思決定を対象として、1～4週間から6～8週間の期間で行います。

次の図は3つのホライゾンの関係の概要を示しています。

[図のクリックで拡大表示]

それでは3つのホライゾンの具体的な内容を解説します。

戦略ホライゾン

戦略ホライズンにおけるビジネスアナリシスの目的は、「組織のビジネス・ゴール」に関する意思決定を伝えることです。

次のような理由でビジネス・ゴールは変化します（むしろ積極的に変えるのです）。

• 消費者の嗜好が変化するから
• 競合他社が破壊的な技術を生み出すから
• 規制が変更されるから、など

ですから、アジャイル・ビジネスアナリシスはビジネス・ゴールの優先順位を、継続的に再アセスメントし、新たな機会を評価します。そしてアジャイル・ビジネスアナリシスによって、組織は迅速かつ効果的に組織のビジネス・ゴールを適応させ、組織の利用可能なリソースを迅速に再展開することができます（複数のイニシアチブで最適化するのです）。これはまさにコロナ禍における日本（のみならずグローバル）の状況を考えてみると極めて重要なことです。

戦略ホライゾンでのBA作業の要素（抜粋）です。

変化を観察します

次の分野の変化をしっかり観察することが重要です。それにはイニシアチブ・ホライゾンデリバリー・ホライゾンまでにおける変化を理解することが必要です。

• 顧客の期待の変化：顧客の調査と分析、新規顧客の調査も含む。
• 外部環境の変化：経済および社会的状況の変化（例：コロナ禍）や新テクノロジーの台頭（AIやIoTなど）、そして競合会社の動向など。
• 組織内の変化：リソース配分を常に変える必要があります。リモートワークの導入。
• 現場から学ぶ：イニシアチブとデリバリー・ホライゾンからの情報を重要視します。
• 機会と脅威を分析し組織が次のことができるよう支援します。
  －新たなイニシアチブの開始
  －現行イニシアチブのリソース配分、スコープ、などの変更
  －成功の可能性の低いイニシアチブの中止

フィードバックと学習

新しいイニシアチブを始めるかどうかの意思決定にちょうどよい分量の情報を提供します。そして次の問いに回答できるようにします。

• 満足させるべきニーズはあるか？満足させる価値があるか？
• そのニーズは組織の戦略目標と整合しているか？
• そのニーズを満たすことに価値はあるのか？
• など

そしてアジャイル・ビジネスアナリシスの原則を適用します

 全体を見る：

組織が存在する環境、現状の能力、強み、組織の課題を明確にします。

顧客として考える：

組織がゴールを設定すること、組織横断での仕事の整合を採ることを助けます。
顧客への焦点がないと、次のような問題が発生してしまう。

• イニシアチブ・ホライゾンは意味のない個々の顧客経験を創り出してしまう、
• 一貫性のない、部分最適の顧客経験を創り出すかもしれない

価値あるものは何かを決めるために分析する： 意思決定者が組織ゴールを追求する際にリソースを適切配分できるようにし、組織全体の作業が、確実に最大限の価値を生み出すようにします。

例を使って真実を得る：

リアルタイムで発生する事実と事例に基づき、急速に変化する不確実な環境においてデータに基づく意思決定を可能にします。

実行可能なものは何かを理解する：

新しい情報の重要性を継続的に解釈する。

コラボレーションと継続的改善を促進する：

組織が顧客と迅速に対応できる効果的なチャネルを構築できるようにします

無駄を省く：

次のような場合に無駄が発生しますので、そうならないようにします。

• イニシアチブが、お互いに整合しない成果を提供する場合、

• 価値を提供しないイニシアチブに引き続き割り当てられる場合。

ここでBABOKガイドV3の知識エリア「戦略アナリシス」の概要をご紹介します。

BABOKガイドV3の知識エリア「戦略アナリシス」は次の4つのタスクがあります。

• －現状を分析する
• －将来状態を定義する
• －リスクをアセスメントする
• －チェンジ戦略を策定する

この4つのタスクは同時に実行されることが多く、かつ「現状（Current States）」は常に変化している可能性が強いことを示しています。そして「戦略アナリシス」はイニシアチブの初頭に一度行えばそれでよいというわけではなく、コンテキストの変化に応じて継続的に何度も行うべきことを言っています。まさにこのコロナ禍の現状を言い当てているのではないでしょうか。このBABOKガイドV3はまるで現在のコロナ禍で日本・グローバルな環境において劇的な変化が起きている状況をまるで見据えているかの如く記述されていることに注目してください。そして最新のアジャイル拡張版の「戦略ホライゾン」の内容はBABOKガイドの知識エリア「戦略アナリシス」を簡略化したものにアジャイル・マインドセットを組合わせたもののようです。

BABOKガイドV3のタスクはもとからアジャイル環境を考慮して作成されているようです。

次は「イニシアチブ・ホライゾン」です。

最小限のアウトプットでアウトカム（提供される価値）を最大化すること。すなわち、「やることをより少なくし、正しいことを正しく行う」こと。（Do right things, right.）

アジャイル・マインドセットの主要な側面はつぎのとおりです。

•  迅速かつ一貫して価値を提供する。
•  果敢にコラボレーションする。
•  学ぶために反復する
•  ムダを省くためにシンプルにする。
•  コンテキストを考慮し、現実に適合する。
•  フィードバックを反映し、プロダクトとプロセスの両方を最適化させる。
•  最高品質のプロダクトを生み出す。

アジャイル開発手法には次のように多くのフレームワークがありそれぞれ特定のプラクティスやアイデアがあります。

• スクラム
• カンバン
• エクストリーム・プログラミング（XP）
• 適応型ソフトウェア開発
• リーンソ・フトウェア開発
• SAFe
• LeSS
• DAD

しかし、次のマインドセットはすべてのフレームワークに共通なものです。

•  人間に対する尊重および価値提供上の創造性の重要性
•  生産されるプロダクトやサービスが実際の顧客ニーズを満たすことを確実にするための、迅速なデリバリー、フィードバック、学習の重要性
•  共通の理解を構築するための、チーム・メンバーとステークホルダー・コミュニティ間におけるコラボレーションとコミュニケーション
•  作業を、ビジネス価値を実現する小さなスライスに分割し、増分的（インクリメント）に、そして反復的に提供する。

ご存知のアジャイル宣言（アジャイル・マニフェスト）です。

私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、より良い開発方法を見つけだそうとしている。この活動を通して、私たちは以下の価値に至った。

• プロセスやツールよりも個人と対話を
• 包括的なドキュメントよりも動くソトウェアを
• 契約交渉よりも顧客との協調を
• 計画に 従うことよりも変化への対応を

すなわち、左記のことがらに価値があることを認めながらも、
私たちは右記のことがらにより価値をおく

上記の「システム」を「ソリューション」に変えるとアジャイル・ビジネスアナリシスになります。具体的には次の表になります。

 上の表の右側の「動く何かをステークホルダーに提示し、即座にフィードバック。。」はBABOKの知識エリア「ソリューション評価」をご存知の読者なら意味が通じると思います。

「ニーズに焦点。。。ニーズの理解に焦点。。」は、「引き出し」から要求アナリシスを意味します。

BABOKガイドの拡張版という位置づけがおわかりになるでしょうか。随所にありますので注意深くお読みください。

 そして、アジャイル・ビジネスアナリシスの原則を以下のように定義しています。

全体を見る

ビジネス・コンテキストと変化（チェンジ）が必要な理由に焦点を当てます。
BACCMのコンテキストが中心。　システム思考がベースです。

 顧客として考える

ステークホルダーに焦点をあてて、ソリューションに顧客の声（VOC）を反映するようにします。

 価値あるものは何かを決めるために分析する

ソリューションにより提供される価値に焦点をあてて、イニシアチブの優先順位づけを行います。

 例を使って真実を得る

ニーズの共通の理解に焦点を当てるために、アナリシス・モデルを活用します。

 実行可能なものは何かを理解する

実行可能なソリューションに焦点をあてます。

 コラボレーションと継続的改善を促進する

ステークホルダーとのコラボレーションに焦点をあてます。ステークホルダー・エンゲージメントがキーです。

 ムダを省く

次の二種類のムダな活動はやめましょう。

• 価値はあるが、ニーズ（ビジネス・ニーズ）を満たさない活動
• 価値を付加しない活動
  ドキュメントは、必要なとき以外は作成しない。

]]> http://kbmanagement.biz/?feed=rss2&p=4868 0 http://kbmanagement.biz/?p=4856 http://kbmanagement.biz/?p=4856#comments Sun, 16 Aug 2020 08:03:30 +0000 admin http://kbmanagement.biz/?p=4856  初めに

7月にIIBA日本支部からBABOK^®ガイド・アジャイル拡張版V2の日本語版（書籍）が発行されました。
筆者は翻訳チームの一員として参画してまいりましたので、概要を解説したいと思います。

実は、BABOK^®のアジャイルへの取り組みはこれが初めてなことではなく、V2と謳っているのでお分かりかと思いますが、2013年にBABOK^®ガイド・アジャイル拡張版V1が発行されています。この時はBABOK^®そのものがまだV2の時代でした。そしてアジャイルも普及し始めた段階で、スクラム、XP、カンバンなどソフトウェア開発に限定された使い方がされていました。すなわち、スクラムやXPの中でビジネスアナリストはどのような仕事をするのか、どんな価値を提供するのか、というレベルのものでした。それは当時の北米のBAにとって大きな評価を得て、BBC（世界最大のビジネスアナリシスのカンファレンス）では一大コミュニティを形成までされていたものです。

しかし、その後5年の間に世界（主に北米）では、単なるソフトウェア開発にとどまらず、あらゆる業務領域にアジャイル手法（アプローチ）が普及し、かつエンタープライズレベルにまで拡張されている状況になりました。
さらに、最近の変化の激しい・不確実で・複雑で・曖昧な（VUCA）環境の状況に迅速に（素早く）対応する解決策（ソリューション）を見つけ出すべきビジネスアナリシスにとって、ますます重要さを増す分野となっています。

まさに現在のコロナ禍の状況そのものかもしれません。
このような状況におけるビジネスアナリシスの在り方のひとつとしてアジャイル拡張が大きな価値を提供することが可能になります。

 1.　アジャイル・ビジネスアナリシスとは何か。

アジャイル・マインドセットを伴う、アジャイルなコンテキストにおけるビジネスアナリシスのやり方をまとめたものです。激しく変化し、不確実で、複雑で、曖昧な（VUCA）環境において競争上の優位性を提供することができ、ソフトウェア開発を越えて、任意の事業領域に活用することができるものです。ですからまさに現在のコロナ禍の状況にはうってつけのアプローチといえます。

アジャイル・マインドセットで重要なのはレビュー（学習）とフィードバックです。3つのホライゾンにおいて、特定のホライゾンでのフィードバックが他の2つの意思決定に影響を与えます。詳しくは後述します。

アジャイルデリバリー

アジャイル・デリバリーは迅速なフィードバックと短い意思決定サイクルを通じて価値を創造するビジネス戦略ですが、次のように2つの基本的な形式があります。

• 反復型計画：
  短いサイクルで実施することにより、（短いサイクルで実施する作業に）焦点を当て、その作業に対するステークホルダーからのフィードバックと学習を多く得て、（後続の）作業の優先順位付けと洗練を行います。
• 適応型計画：
  上記反復型計画に、長期計画への継続的な変更を加えたものです。定常的な計画と分析が行われ、最大の価値を提供するために作業の優先順位を決定し、洗練していきます。

 アジャイル・ビジネスアナリシスの活動の概要：

• ビジネス・ゴールを達成するために組織戦略とイニシアチブをリンクします
• 情報（ニーズ）を発見し、要求に変換し、伝えることにより、どこで価値を生み出すことができるかを明確にします。
• 価値は誰のために創造されるのか、価値の創造に貢献できるのは誰か、価値の影響を受けるのは誰かを明確にします。
• ステークホルダーがアプローチ、優先順位、トレードオフについて決定を下せるように支援し、制約事項、意見の相違、リスク、複雑さに直面しても、継続的な価値創造に焦点を合わせられるように支援します。

 アジャイル・ビジネスアナリシスの7つの原則です。（次回に解説）

• 全体を見る
• 顧客として考える
• 価値あるものは何かを決めるために分析する
• 例を使って真実を得る
• 実行可能なものは何かを理解する
• コラボレーションと継続的改善を促進する
• ムダを省く

要求アナリシス（BABOKガイドの第6章)は、ビジネスアナリストがどのように優先順位を付けてステークホルダー要求とソリューション要求を段階的に仕上げていくかを説明します。そしてプロジェクト・チームがスポンサー組織とステークホルダーのニーズを満たすソリューションをインプリメントすることを可能にします。そのためには、ステークホルダーが満足するようなソリューションを定義するためにステークホルダーニーズを分析し、改善を識別し推奨するためにビジネスの現状を評価し、そして結果の要求の検証と妥当性確認をします。

 3.5.1　要求に優先順位を付ける（6.1）

アジャイルなプロジェクトにおいては、要求は徐々に仕上げられます。言いかえれば、引き出しタスク全体にわたって引き出した結果は、徐々にまたは継続的にブレークダウンされて仕上げられていきます。これは継続的改善の概念に似ていて、ビジネスアナリストは求められる詳細さで要求を絶えず詳しく記述し、意図したプロジェクト結果に基づいて優先順位付けされる新しい要求を識別します。各仕上げのポイントでは、ビジネス価値への貢献およびリスクの度合い応じて、構成要素が評価され優先順位付けされる必要があります。これは、アジャイルでは、プロジェクトの初期に一回だけ行う活動ではありません。これは、製品に関して学習することから始まり、すべての未了作業および新しい仕事に関するプロジェクトのライフサイクル全体にわたって行われます。

 .1　アジャイルテクニック

・バックログマネジメント:
バックログマネジメントは多くの機敏なアプローチ中の必要条件を優先的にする標準方法です。ビジネス・ニーズが変わったり、ビジネスをより深く理解できた場合は、常に、バックログは再度、優先順位付けがされます。

・狩野アナリシス:
狩野アナリシスは、ユーザ・グループにフィーチャーの相対的重要度に対する洞察力を提供することができます。

・計画ワークショップ:
優先順位付け作業は、通常計画ワークショップ中に行われます。

注: MoSCoW優先順位付けの拡張も参照してください。

  3.5.2　要求を体系化する（6.2）

ジャストインタイムで、連続的に行う要求の引き出し活動とドキュメンテーション活動により、要求がアジャイルなプロジェクトのためにどのように体系化されるだろうかを考えることは重要です。例えば、ユーザストーリーは、それをもっぱら記述する多数のドキュメントの中にしばしば現われます。その結果、適切な要求を探すことが厄介な活動にもなります。アジャイルなプロジェクトのドキュメントは手軽であるべきですが、要求マネジメント計画と、プロジェクト・チーム・メンバーおよび他のステイクホルダーによって使用できる要求を体系化する方法を持っていることはまだ重要です。

アジャイルの中で、フィーチャーセット間の依存性を最小化するために、要求を体系化することは価値があるでしょう。これは複雑さとリスクを最小化するので、ビジネス・レベルの価値で、テスト可能性が改善できます。技術的実装に相反するものとして、ビジネス価値にまつわる要求と、次第に仕上がる要求を体系化することは、ビジネス上の見地から設計されるソリューションに帰着します。例外はコンポーネントチームのようなプロジェクトに存在し、ビジネス価値は実現技術を提供することから生じます。そのときでさえ、リスク評価とビジネス価値への貢献に基づいて、これらの要求の優先順位付けと選択を行う必要があります。エピック内のストーリーマップは、要求を体系化する方法として使用することができます。

 .1　アジャイルテクニック

・ストーリー分割：
エピックおよび(または)フィーチャーが体系化の方法として使用される場合、個々のストーリーはエピックかフィーチャーのまわりで体系化されるでしょう。

・ストーリーマッピング:
ストーリーマッピングは、さらに個々のストーリーがどのように関係があるか、あるいは、互いに支援するか示します。
これは、関連するストーリーを決定し、それらの関係に基づいたストーリーおよび関連する要求を体系化する方法として使用されるでしょう。

3.5.3　要求の仕様化とモデリング（6.3）

要求を仕様化しモデル化するためには、異なるレベルの仕上げと、異なるやり方があります。このアプローチは段階的詳細化（仕上がり）を支援するべきであり、変化に適応可能で、学習に基づき、そして、チームにソリューションをあまり早期には選択させないようにするべきです。さらに、意図および意図したビジネス価値が仕上げを通じて一貫してコミュニケーションされることを確実にするべきです。アジャイルなチームは、分割の最低のレベルでストーリーとタスクを使用する傾向があります。これらのストーリーとタスクは詳しいドキュメンテーションとユースケースに支援されます。受け入れテストが、要求の仕様化とモデリングの一部として作成されることが、ますます一般的になってきます。

 .1　アジャイルテクニック

・ビヘイビア駆動開発(BDD):
機能性の具体的な例は、ステークホルダーが自分たちのニーズの仕様化と理解を助けてくれるかもしれませんし、あるいはより大きな価値のある特定のシナリオを扱うことを支援してくれるかもしれません

・ストーリーボーディング：

ユーザ・インターフェース(UI)機能性と振る舞いについて記述するために使用されます。

3.5.4　前提条件と制約条件を定義する

前提条件と制約条件の定義は、アジャイルなプロジェクトではリスク管理アプローチによって扱われます。例えば、それらが関係するフィーチャーかエピックで追跡できるように、いくつかのアジャイルなチームはテーマ内のストーリーとしてリスクを扱います。その後、リスク緩和アクティビティは優先順位が付けられ、鎮静するでしょう、また、その後、ストーリーとしての再優先順位付けが行なわれます。これは、典型的にチーム全員の支援に加えて、ビジネスアナリストおよびプロジェクト・マネージャーの役割を担う個人によって作成されます。その後、優先順位付けはプロダクトオーナーあるいは類似の役割の誰かによって行なわれるでしょう。

 .1アジャイルテクニック

・手軽なドキュメント：
前提条件と制約条件は、プロジェクトの進歩とともに、プロジェクト・チームによって作成される手軽なドキュメンテーションの中で文書化することができます。

・ペルソナ:
ペルソナは、プロダクトチームが開発の間に知るべき、特別のユーザ・グループかステークホルダー・タイプに関連したリスクを追跡する一つの方法として使用することができます。ペルソナはスキャンし、ステイクホルダー分析の間にステイクホルダー・タイプに関して作られた任意の前提条件に関する情報を含めるために任意に修正されます。

・ユーザーストーリー：
ユーザストーリーはストーリーと関係する前提条件あるいは制約条件(特に後者)を追跡するために修正することができます。チームは、さらにこれらが開発のために計画されたストーリーと離れていることはチームとステイクホルダーに明らかである必要がありますが、顕著な作業項目としてチームが取り組むリスクを集める方法としてユーザーストーリーフォーマットを使用することができます。

3.5.5　要求を検証する（6.5）

検証は、何かが明確に設計されており品質規格を厳守していることを確実にします。例えば、ユーザストーリーあるいは他の要求ドキュメントが適切に構造化されていることを検証することは、適切なフィールドを含んでおり、適正レベルな詳細さを含んでいます。要求はプロジェクトのコースの至る所でのチームによって確認されます。振り返りおよびオペレーションレビューによって、チームは、要求の詳細レベルあるいはチームのパフォーマンスを改善するために要求を仕様化しモデル化する方法を修正することを決定するかもしれません。振り返り中のチーム、毎日のチームミーティングあるいは他のミーティングからの直接のフィードバックあるいはワークショップを誘発して、ソフトウェアが開発されているとともに、要求の検証は、通常チームのステイクホルダーとの直接の相互作用によって行われます。

 .1　アジャイルテクニック

・振り返り：
振り返りは、構築されたものが要望されたビジネス結果にマッチするだろうということを確認するために、構築されたものの上に迅速なフィードバックを行ないます。

・ストーリーマッピング:
ストーリーマッピングは選択されたユーザーストーリーが要望されたビジネス結果を実際にデリバリーされるだろうということを確認するための技術です。

3.5.6　要求を妥当性確認する（6.6）

妥当性確認は、引き渡せるかプロダクトがその意図した目的を実際に満足することを確実にします。例えば、ユーザーストーリーは、それが記述するように意図されるビジネスプロセスか活動について十分に記述することの妥当性確認をします。要求はソリューションの開発およびデリバリーの全体にわたって、顧客、また可能なら、プロダクトオーナーか類似の役割の人との連続的な関与によって妥当性確認されます。これは開発の間において、リリース計画、イテレーション計画など、プロジェクト中の多くのポイントで起こります。プロトタイプは、さらにユーザにプロトタイプの発展上のユーザからフィードバックを得るプロダクトレビューミーティングを備えた開発で、初期にテストし試みることを与えることにより、その意図した目的に関する機能性のユーティリティを妥当性確認する、有効な方法になりえます。

 .1　アジャイルテクニック

・ビヘイビア駆動開発：
ビヘイビア駆動またはテスト駆動開発では、例は設計された要求のための手段として、またソリューションを設計するための受け入れ基準を設立するために使用されます。これらの実世界の例を満たす能力は、ソリューション要求を妥当性確認する手段として役に立ちます。

・振り返り:
ソリューションが予定通りに開発されているかどうか、あるいは成功裡にニーズを満たしているかどうかを妥当性確認するために、顧客は振り返りのセッションによってソリューションを評価することができます。

エンタープライズアナリシス(BABOKガイドの第5章)は、ビジネスアナリストがどのようにビジネスニーズを識別し、その定義を洗練、明確にし、そしてビジネスによって現実的にインプリメントできるソリューションスコープをどのように定義するのか説明します。この知識エリアは問題定義と分析、ビジネスケースの開発、フィージビリティ調査そしてソリューションスコープの定義について記述します。エンタープライズアナリシスは、ビジネスニーズ、解決するべき問題や機会を識別し、ニーズに取り組む適切なアプローチを決めることに関係しています。

 3.4.1　ビジネスニーズを定義する（5.1）

BABOKガイドに述べられている「ビジネスニーズを定義する」タスクはアジャイルなアプローチにも拡張されます。

 .1　アジャイルテクニック

・ビジネスケイパビリティ分析:
ビジネスニーズに対応するのは、通常新しい能力の開発あるいは既存の能力の増強です。

・協働ゲーム:
いくつかの協働ゲームは満たされないビジネス・ニーズを見つけ出すことに役立ちます。

3.4.2　能力ギャップをアセスメントする

BABOKガイドに述べられている「能力ギャップをアセスメントする」タスクはアジャイルなアプローチにも拡張されます。

 .1　アジャイルテクニック

・ビジネスケイパビリティ分析:
これは既存の能力に何が欠落しているのか理解するために使用することができます。

3.4.3　ソリューションアプローチを決定する

アジャイルは一つのソリューションアプローチです。それは従来のアプローチより速く価値のあるデリバリーを提供するため、あるいは、問題領域を調査する必要があるために選択されます。そして、ソリューションアプローチがプロジェクトの間に発展することができるように、インクリメンタルなデリバリーを支援します。アジャイルなアプローチは、調査されている問題または機会の最良のソリューション案を決定する際に柔軟に対応できます。ソリューションはカスタム開発として進化的にプロトタイピングから始まりますが、その後、カスタマイズされた既製ソリューションに移行するかもしれませんし、それとも、例えば別製品の一部分になるかもしれません。そのため、アジャイルなプロジェクトにおいては、ソリューションアプローチは、時々開発の間に変わる場合があります。

 .1　アジャイルテクニック

目的整合モデル：
目的整合モデルは、与えられたビジネスニーズへの最良のアプローチに関するガイダンスを提供することができます。

3.4.4　ソリューションスコープを定義する（5.4）

チームが、問題解決またはソリューションへの顧客嗜好に関して学習するにつれ、アジャイルなプロジェクトのスコープはプロジェクトの間に変化します。スコープはより高いレベルの抽象的概念(テーマとエピックのような)の中で定義されており、プロジェクトが進むとともに詳述されます。これらの上位の抽象的概念は、ソリューションスコープを決める計画する上で、またチームが、プロダクトのアーキテクチャーとリリース用の最初のビジョンを考え出すことを可能にする上で重要です。これは多くの場合反復プロセスです。すなわち、最初のアーキテクチャー評価において技術的実現可能性に基づきリリース計画およびプロジェクト期限に影響を及ぼすので、スコープが洗練されるかもしれません。同様に、アーキテクチャー計画は修正されるかもしれないし、あるいはリリースでデリバリーされる計画された上位要求に基づいたインフラストラクチャーを建て増すことへの段階的なアプローチを含んでいるかもしれません。

 .1　アジャイルテクニック

・ビジネスケイパビリティ分析:
プロジェクトのスコープは、それが作成しているか増強しているビジネスケイパビリティ能力と関係があるに違いありません。

・ストーリー分割:
エピックとフィーチャーはスコープを定義する根拠として役立つことができます。

・ストーリーマッピング:
ストーリーマップはプロジェクトによってデリバリーされた様々なストーリーの関係を見るために使用することができます。

 3.4.5　ビジネスケースを定義する

アジャイルなプロジェクト用のビジネスケースは、指定されたコストおよび時間内の特定のビジネス結果の達成に基づきます。ビジネスケースは頻繁に再訪され、チームは、何を伝えることができ、またどれくらいよく実際の(知覚されなかった)ニーズを満たし、指定されたコストおよび時間内にビジネス結果および意図した価値を達成することができるかを知ることができます。

.1　アジャイルテクニック

ビジネスケイパビリティ分析:
ビジネスケースに関連した顧客と組織的な価値は定義します。

・狩野アナリシス:
どのプロダクトフィーチャーが市場への最も大きな影響力を持つか識別します。

・目的整列モデル:
組織において、どんな種類の投資が最大値を生成するか識別します。

・リアルオプション:
価値が確実に得るために、いつ投資ニーズを実行するべきかの評価ができます。

「要件のマネジメントとコミュニケーション」（BABOK®ガイドの第4章）は、ビジネスアナリストがコンフリクト、​​問題、および変更を管理し、ステークホルダーとプロジェクトチームがソリューションスコープを確実に合意する方法、その要求をステークホルダーに伝達する方法、そして得られた知識をビジネスアナリストが将来に備えて保守する方法について説明します。これは1度だけのアクティビティではなく、プロジェクトのライフサイクル全期間において継続的に実施されます。

 3.3.1　ソリューションスコープと要求をマネジメントする（4.1）

アジャイルなプロジェクトは開発が進むにつれて、スコープは明確に定義されていきます。使用されているアジャイルなアプローチによりますが、スコープの具体的な詳細はプロダクトバックログの中、あるいは同様のドキュメントで見つけることができます。これらの活動の中で管理されたプロダクトバックログ、ユーザーストーリーあるいは他の要求ドキュメントの内容は、前セクションで解説した引き出し活動によって作成されます。仕上がりのレベルによって、プロダクトバックログ自身の詳細さのレベルも異なるかもしれません。追加の工数がこれ以上のビジネス価値のリターンを提供しないだろうとスポンサーが決めれば、スポンサーがプロジェクトを終了することを決定してもよいことも考慮するべきです、

 .1　アジャイルテクニック：

バックログの管理：
ほとんどのアジャイルチームは、ソリューションスコープと要求の両方をマネジメントするために、プロダクトバックログを使用します。

ストーリー分割：
ストーリー分割は粒度の適正水準においての計画を可能にし、アジャイルアプローチのジャストインタイムの性質を支援します。

3.3.2　要求のトレーサビリティをマネジメントする（4.2）

アジャイルプロジェクトでは、すべてが戦略的なテーマ、エピック、ストーリーにさかのぼるようにリンクされて、プロジェクトが定義されます。そして、プロダクトオーナーまたはビジネスアナリストによって維持されます。

 .1　アジャイルテクニック：

ストーリー分割：
ストーリーがより小さな粒度の部分へ分解されるとき、より大きなエピックか特徴を保持しながら、分解されたストーリーを結んでいる場合、より大きな、親概念は、要求トレーサビリティを作成するのを支援することができます。

ストーリーマッピング：
活動のプロセスかフローを示して、ストーリーマップは主としてユーザストーリーの関係を示していますが、さらに、それらはユーザが遂行することができなければならない、より大きなアクティビティにユーザーストーリーをマップします。そのため、ストーリーマッピングは、関連ストーリー、およびストーリーと、それらが支援するより大きなアクティビティ間のトレーサビリティを提供するツールとして役立つことができます。

 3.3.3　再利用に備えて要求を保守する（4.3）

成熟したアジャイル組織では、このタスクは伝統的な方法で保持されます。すなわちドキュメンテーションとプロトタイプは将来の類似の開発プロジェクトで再利用できるように、保持されます。違いは、要求がプロジェクトの最中に文書化されるのかそれともプロジェクトの終了時に文書化されるのかです。プロダクトバックログ、ユーザーストーリーおよび他の標準的な要求ドキュメンテーションに加えて、ソース・コードはそれ自身もドキュメント化のためにもしばしば書かれます。コードが満たす要求に関する情報は、開発者がソース・コードのために作成するノートに含むことができます。

 .1　アジャイルテクニック：

ユーザーストーリー：
良くドキュメント化されたユーザーストーリーは、保持することができ、また製品の将来の洗練された出発点あるいは別の同様のプロダクトの要求としての再利用可能なものです。

 3.3.4　要求パッケージを準備する（4.4）

要求パッケージの準備は、プロジェクトを定義するために使用されるテーマ、エピック、そしてストーリーに関連するシナリオ、ユースケース、受け入れテスト、およびモックアップ、モデルを介して処理されます。そして、ソリューション開発のライフサイクルにおける継続的な活動です。使用される具体的なテクニックは、プロジェクトの開始時に選択されたアプローチに依存しますが、必要に応じてプロジェクトのコンテキストの理解に基づき最適に機能するものに変更されます。リリース計画は、しばしば要求のパッケージ化する方法をガイドするのを支援し、計画されたプロダクトリリースにおいてチームがどのようにフィーチャーをまとめ上げて提案するのか理解できます。

 .1　アジャイルテクニック

ストーリーの分割：
エピック、機能、または最小市場機能（MMF）は、ステークホルダーと議論することができる大きなパッケージにまとめてユーザーストーリーのグループにと関連します

 3.3.5　要求を伝達する

アジャイルなプロジェクトでは、要求は継続的に開発者に伝えられます。要求コミュニケーションは、最も頻繁にリリース計画ミーティングで行われ、リリースに向けたテーマとストーリーがレビューされ、選択されます。そしてイテレーション計画ミーティングにおいて、モデルと仕様がチームとプロダクトオーナーの間で選択されて、さらに詳細に議論されます。イテレーション計画ミーティングでは、リスクもレビューされ議論されます。さらに、毎日のチームミーティングでは、開発者が明快な回答を得るかあるいは曖昧な要求を識別する機会として、しばしば利用されます。そこでは、ビジネスアナリストは、要求の詳細をコミュニケーションするか、曖昧なもの明確にします。要求のためのモデルとビジュアル化は、ソリューションが解決する必要のある問題の詳細な要求と、理解を促進する迅速なコミュニケーションの方法になりえます。

 .1　アジャイルテクニック

計画ワークショップ：詳細については、このテクニックを参照してください。

引き出し（BABOK(R)ガイド第3章）は、ビジネスアナリストがどのように、ステークホルダーと連携し、ニーズや懸念を識別、理解し、そして彼らが働いている環境を理解する方法について説明します。効果的な引き出しは、ステークホルダーが口にする表面的な欲求よりも、むしろの実際の根本的ニーズを明確にすることを確実にします。引き出しは、従来のアプローチ（ウォーターフォール）では独立したフェーズ/活動だったのですが、アナリシスの活動と一緒に、プロジェクトの全期間で実行されます。引き出しは、(別個の活動またはフェーズとして引き出しを行っていた従来のアプローチと比較すると)プロジェクト全体にわたって進行し、アナリシス活動と共に行なわれます。

アジャイルなプロジェクトにおいては、最も多く共通するパターンが、ソリューションのハイ・レベルのニーズ、ゴール、スコープを見る最初の引き出し活動です。すべてのイテレーションの中で、バックログアイテムを構成するユーザストーリーのための引き出しでさらに詳細に引き出しが行われます。

 3.2.1　タスク：引き出しを準備する（3.1）

プロジェクト存続中の全期間で引き出しが行われます。早い段階で、それはハイレベルの要求を定義するために支援材料とリソースのスケジュールを調整するためにビジネスアナリストによって行われます。プロジェクトのこのフェーズで引き出し活動は、より探検的セッションとして一般に組み立てられます。そして根本的なニーズを理解し、フィーチャーの最初の要求リストを組み立て、そして今後の作業にとって何が最も価値があるのか決めます。プロジェクトが進行するにつれて、作業がバックログの優先順位付けによって調整されます。そしてより頻繁に、ローレベルの特別のフィーチャーか要求の詳細を理解するためのより構造化された、直接的な引き出しセッションに帰着するでしょう。ステイクホルダーは、要求を仕上げるために開発者と直接仕事をしても構いません。その状況で、開発者は、プロジェクト用のビジネスアナリシス活動を行なっており、よいビジネスアナリシスプラクティスのトレーニングを受けるべきです。それが可能でなければ、ビジネスアナリストがその代理を務めるでしょう。このタスクは、リソースのスケジューリングとバックログの漸進的な精緻化に合わせて入力の調整が必要です。

引き出し活動に備えて、一緒に働くステークホルダーのニーズ、ウォンツおよび好みを理解するために、ビジネスアナリストが顧客調査およびステイクホルダー分析を行なうことが勧められます。引き出しの議論をステークホルダーに最適化することによって、ビジネスアナリストは、引き出しセッションの効率および価値を最大化することができます。

 .1　アジャイルテクニック

ペルソナ：
ペルソナは、ステークホルダーの特定のニーズへの洞察を提供してくれ、ステークホルダーのニーズを理解する上で最も効果的なテクニックです。

ユーザストーリー：
ユーザストーリーはストーリーが明確にする価値を享受する人の役割を識別します。（したがって、その価値について詳しく説明できる利害関係者を識別します）

ストーリーマッピング：
ユーザおよび他のステークホルダーとユーザストーリーマップを開発することは、ソリューションにインプリメントされたストーリーが現実味のある製品になることを確実にするでしょう。

 3.2.2　引き出しの活動を指揮する（3.2）

引き出しの活動はプロジェクト全体で頻繁に行われ、毎日のように実施されます。早い段階では引き出しは、高レベルの要求やプロダクトビジョンを定義するために実行されます。プロジェクトの進捗とともに、ステークホルダーは、イテレーション計画と開発の最中に、開発チームと直接対話をします。すべての引き出し活動の意図は、直接作業を正確に確実に行うのにちょうどよい詳細さの要求を生成することです。この引き出し活動は、プロダクトユーザー、および議論されているフィーチャーまたは要求に既得権益を持っている他のステイクホルダーとともに、しばしばワークショップで行われます。

 アジャイルテクニック

ビヘイビア駆動開発：
ステークホルダーは、単に抽象的なモデルを使用するのではなく、サンプル（例）を提供することによって、彼らのニーズを明確にすることです。

協働ゲーム：
協働ゲームにおいて、引き出しの参加者は問題やソリューションの共同理解の構築に協力することが推奨されます。

注：上記のように、アナリシス活動は通常、引き出しセッション中に実行されます。このアジャイル拡張版に記載されるテックニックのほとんどは、多くのBABOK®ガイドのテクニックと同様に、この目的に適しています。

 3.2.3　引き出しの結果を文書化する（3.3）

ドキュメントの主要な価値は、それが長期的な知識の維持のために使用できることです。アジャイルアプローチは、要求の開発とソフトウェアの実装との間の時間を最小限に抑えて、チームにそのドキュメント作成に費やす労力を減らすことを目指しています。引き出し活動の記録は、後日に重要な意思決定が理解できるようにするため、または規制やガバナンスの要求が満たされていることを確実にするためには必要です。要求および要求用コンテキストを表わす成果物は、単に文章によるドキュメンと限定する必要はありません。モデル、モックアップ、プロトタイプなどにより要求を視覚化することは、ソリューションに関する大規模な情報量を伝えるための迅速なメカニズムです。しかしながら、不必要にソリューションの選択肢を制限せずに要求を定義することが重要なように、ソリューションを模倣するビジュアル化を使用する場合はさらに注意するべきです。

 アジャイルテクニック

手軽なドキュメント：
開発ドキュメントのガイドラインについては、このセクションを参照してください。ほとんどの場合、引き出しとアナリシス作業の別々のドキュメントが存在しません。

 3.2.4　引き出しの結果を確認する（3.4）

これは、イテレーションの計画時、イテレーションの開発期間中、そして顧客の受け入れ時にチームによって実行されます。顧客は結果を見ると、特定のストーリーのいくつかの要素について心変わりすることがあります。このフィードバックは、引き出しの活動を主導するタスクへのインプットとなります。

 .1　アジャイルテクニック

ビヘイビア駆動開発：
引き出しの結果は受け入れ基準の形で捕らえられ、頻繁にソフトウェアがステークホルダー・ニーズを満たすことを確認するためにチームによって使用されます。 ビヘイビア駆動開発またはテスト駆動開発では、例は引き出された要求を確認するために使用され、受け入れ基準を作成する根拠としてよく使用されます。

振り返り（リトロスペクティブ）:
振り返りのセッションにおいて引き出された情報は、顧客が運用中のプロダクトを見た時に感じた見解に基づき、確認もしくは反駁されるかもしれません。そしてソリューション要求の修正につながるかもしれません。