ITプロジェクトの要件を特定するワークショップ：それらを実行する方法と理由

ワークショップについて書くのはなぜですか？ 結局のところ、たとえば、複数のSkype通話や一連のインタビューを整理するなど、より簡単な方法で要件を収集できます。 しかし、それは常に機能しますか？



政府組織の情報システムを作成することを想像してください。 このような組織は、原則として、部門、部門、さまざまな部門-法務、財務および経済、人事、広報部門など、多くの部門からなる複雑な階層構造を持っています。 これらのユニットにはすべて、確立されたプロセスがあり、可能な限り最適化されているため、作成中のシステムに転送する必要があります。



ここでどんな困難が生じる可能性がありますか？



各ユニットから個別に要件を収集するには多くの時間がかかります。 そして、これがSkype通話を介して可能になることはほとんどありません。

異なる部門の要件を1つの全体像に結合しようとすると、競合が必ず発生します。各部門には、インターフェイスとビジネスプロセスに関する独自のビジョンがあります。

要件は以前に合意した予算に収まらないため、作業量を減らす必要があります。もちろん、興味のある人は誰も彼女に役立つ機能を削除したくないでしょう。



どうする



さまざまな要件収集手法のうち、このような問題（多くの利害関係者と競合する要件を持つ大規模プロジェクトの問題）を解決することを目的とする手法を強調する価値があります。これは要件収集ワークショップです。

ワークショップとは何ですか？

ワークショップは、標準的な要件収集手法の1つであり、おそらくプロセスを形式化するのが難しいため、文献ではあまり注目されていません。 「ワークショップ」という名前から、フレームワーク内で活発な作業が行われていることは明らかです。 したがって、定義によって存在する人々は、起こっていることに受動的に参加することはできません。 要点は、利害関係者が集まって最終製品の要件を決定することです。 請負業者と顧客の代表者がワークショップに必ず出席します。 原則として、ワークショップには少なくとも半日かかります。



ワークショップは定期的な会議とは異なり、その目的はさまざまな問題について話し合うことではなく、特定の結果を生み出すことです。この場合、これは特定の要件を備えた文書です。



このプラクティスは、70年代後半にIBMによって開発されました。 その後、それらはJADセッション（共同アプリケーション開発）と呼ばれ、後に共同アプリケーション開発方法論の基礎を形成しました。 何らかの形で、ワークショップは多くの開発プロセスで使用されていますが、プロセスに縛られることなく、別個の手法と見なすことができます。

それらをいつ、なぜ実行するのですか？

あなたとユーザーが要件を形成する次のキャンディクラッシュクローンまたはスタートアップの開発に関しては、ワークショップは時間の無駄になります-それは確かです。



ワークショップは、いくつかの条件が満たされている場合に役立ちます。

• 自明ではないビジネスプロセスを備えた複雑なシステムを開発しています 。 これがおそらく主な条件です。 たとえば、システムは特定の業界向けに設計されているか、既製のアナログがありません。
• プロジェクトには多くの相反する要件があり 、その解決には集合的な議論が必要です。
• ビジネスに不可欠なプロジェクト。 特に複雑さを考えると、このようなワークショップの利点を顧客が理解することは困難です。 したがって、プロジェクトの重要性が高いほど、顧客はその成功に興味を持ち、それはより多くの時間をプロジェクトに費やす意思があることを意味します。
• プロジェクトはかなり大きいです。 統計によると（C. Jones。ソフトウェア評価、ベンチマーク、ベストプラクティス。Addison-WesleyLongman Publishing Co.、Inc.ボストン、マサチューセッツ州、2000年）、ワークショップは100機能ポイントを超えるプロジェクトで最もよく使用されます。
• いくつかのユーザーグループが最終製品に関心を持っています。 たとえば、さまざまなプロファイルの専門家がERPシステムを使用します。
• 要件を迅速に特定する必要性。 たとえば、競合するソリューションがすでに市場シェアを獲得している状況で。

上記を要約すると、ワークショップは、 相反する要件を同時に解決し、利害関係者のニーズを分析し、要件がこれらのニーズを考慮に入れるようにするツールです。

いくつかの統計

このイベントの複雑さは、ワークショップにかかる時間と相まって、愛好家を怖がらせることができます。 しかし、EBG Consultingが提供する図によると、ワークショップ：

• 最終製品の欠陥の数を20〜50％削減
• 作業量の制御できない増加のリスクを10〜80％削減します。 ワークショップとともにプロトタイピングを使用すると、最大の結果が得られます
• プロジェクト全体で要件の収集にかかる時間と労力を5〜15％節約

どこから始めますか？

計画から始めることをお勧めします。ワークショップの場合、これはかつてないほど関連性があります。 これを行うには、まず、ワークショップに何を望むか、私たちの目標は何かを決める必要がありますか？ これは、ビジネスプロセスの改善、機能要件の特定（使用シナリオ、ユーザーストーリーなど）、アーキテクチャ的に重要な要件の明確化などです。 さらに、ワークショップの目標は、要件文書のドラフト版と最終版の両方を作成することです。



目標がわかっていれば、作業の規模は明確であり、タスクに必要なそのようなイベントの数を見積もることができます。 1つのワークショップに対応できない場合は、作成する必要があるすべてのセッションとドキュメントのスケジュールを計画する必要があります。



以下は、欧米企業でのワークショップの使用を説明する要約データです。 独自のワークショップを開催するとき、それらに安全に集中できます。

参加者数	平均4-12、25以下
セッション期間	3〜8時間
セッション頻度	週に2〜3回
プロジェクトごとのワークショップの数	1-8
準備時間	セッション自体の2倍

要件を収集するには、いくつかの異なる収集手法があります。 ACDMの方法論で説明されている手法について詳しく説明することにしました。 ACDM（Architecture Centric Design Method）はソフトウェア開発へのアプローチであり、その機能はアーキテクチャに重点を置いています。 これは最も一般的な方法論とはほど遠い（最近、Wikipediaの説明でページを削除した人もいる）が、ワークショップテクニックの最も詳細な説明が提供されている（ここで、コメントと観察を補足して）。



そのため、ワークショップは、 計画、実施、最終の3つの主要部分で構成されています。

1.計画

ワークショップの結果は、その準備の程度によって大きく決まります。 彼らは交通については考えていませんでした-参加者の半分は遅れていました。 プロジェクトに関する遅れて送られた文書-ワークショップの半分はそれらを読むために行きます。 適切な人を招待するのを忘れた-すべての作業をやり直す必要があります。 一言で言えば、あなたは多くの人々（通常は指導者であり、したがって彼らの時間は最も価値がある）の時間を費やすことを理解する必要があり、あなたは行動を最大限に活用するために可能なすべてをする必要があります。

計画段階で、次の主なポイントを決定する必要があります。

• 場所
• 会員
• プログラム
• プロジェクトの概要プレゼンテーション>
• 素材
• 栄養
• 交通機関

場所。 経験からわかるように、すべての主要キャラクターがワークショップに物理的に参加していることが非常に重要です。なぜなら、経験上、他の参加者が集中するのを妨げる遅延やコミュニケーションの失敗だけでなく、プロセスに仮想的に存在する人々を巻き込むことは難しいからです。

これが可能であれば、中立の場所を選択することをお勧めします-ワークショップの参加者が同僚に引っ張られない場所。



参加者。 まず、誰がプロジェクトに興味があるのか​​を決める必要があります。 ワークショップの潜在的な参加者は、顧客、エンドユーザー、開発者、アナリスト、インテグレーター、テスター、システム管理者などです。つまり、プロジェクトに関与している全員です。 さらに、プロジェクトが複数の顧客企業および/または複数の実装企業をまとめる場合、もちろん、イベントでのこれらすべての企業の代表者の存在は必須です。 関心のある人に加えて、主題の専門家がワークショップに招待される場合があります。



主催チーム（プロセスによっては、アナリストまたはアーキテクトのチームである場合があります）は、ワークショップの参加者を選択する際に非常に注意する必要があります。 彼が代表する組織の各参加者の役割、開発中の製品に対する彼の態度を評価する必要があります-参加していない参加者と余分な参加者は、多くのトラブルを引き起こす可能性があります。 したがって、場合によっては、潜在的な参加者の存在を拒否するか、逆に、適切な人に同意するまでワークショップを実施しないことが礼儀的です。



原則として、すべての適任者を集めることは容易な作業ではありません。特に、すべての参加者がこのワークショップがまったくあきらめられた理由を理解していない場合はそうではありません。 したがって、クライアント側、より頻繁にマネージャーの人に「あなたの」人を置くことが理想的です-彼は参加者を調整し、日付を設定し、ワークショップが優先事項であることを彼らに納得させます。



ACDM方法論の作成者は、25人の参加者に自分を制限することを推奨していますが、それ以上の調整は非常に困難です。



ワークショップの前に役割を決定することも重要です。 従来、ワークショップのすべての参加者は、顧客の代表者とパフォーマーの代表者に分かれています。 前者は主な要件であり、後者は受動的なリスナーです。彼らの存在の目的は、プロジェクトのコンテキストに没頭することと、会議中にメモを取ることです。 ただし、それらの間には、最小限のロールセットを配布する必要があります。

• コーディネーター。 （ワークショップリーダー）これは、ワークショップをリードし、議論を調整できる経験豊富な人でなければなりません。 原則として、主要なアナリストがこの役割を果たします。
• タイムキーパー。 彼はワークショップの時間枠に従い（会議計画の各項目には一定の期間を設定する必要があります）、コーディネーターにそれを超えているかどうかを伝えます。
• 秘書 非常に重要な役割であるこの人物は、行われたすべての決定と未解決の質問を記録します。 このアクティビティは非常に疲れるので、役割を交互に考えることは価値があります。

また、エグゼキュータのチームは、参加者が互いに正式に紹介され、問題のコースが紹介され、役割が割り当てられる予備会議を実施することをお勧めします。



ワークショッププログラム。 コーディネーターは、プログラムのドラフトバージョンを準備し、すべての参加者に事前に送信する必要があります。これにより、参加者はイベントの計画を把握し、変更を加えることができます。



以下に、プログラムテンプレートの例を示します。 ACDM方法論で提案されている形式では、ワークショップは丸一日かかります。 八時。



場所：...

日付：...

開始時間：...

終了時間：...

NB：警告、ワークショップ中は電話をオフにしてください

アクティビティ	誰	時間
参加者のプレゼンテーション	<コーディネーター>	〜15分
プロジェクト概要プレゼンテーション	<お客様担当者>	〜1時間
休憩	全部	〜15分
機能要件の特定	<コーディネーター監修の議論>	〜2時間
昼食	全部	〜1時間
品質特性の識別（非機能要件）	<コーディネーター監修の議論>	〜2時間
休憩	全部	〜15分
ビジネスおよび技術的な制約を特定する	<コーディネーター監修の議論>	〜1時間
まとめ	<コーディネーター>	〜15分

プロジェクトの概要プレゼンテーション。 計画段階は、クライアントにそのようなプレゼンテーションの準備を依頼する時間です。 既にプロジェクトのドキュメントが山積みになっているのに、なぜこれが必要なのですか？

実際には、一部のドキュメントには多くの不明瞭な点が含まれている可能性があり、他のドキュメントには陳腐化する可能性があるため、プレゼンテーションプロセス中に、プロジェクトの問題領域を特定する質問が参加者にしばしば出ます。



理想的には、クライアントは（口頭プレゼンテーションではなく）グラフィカルなプレゼンテーションを準備する必要があります。 以下にプレゼンテーションテンプレートの例を示します。

テーマ	説明
一般的なビジネスコンテキスト	説明： 会社と市場の簡単な歴史 特徴的な機能 現在のニーズとプロジェクトがそれらをどのように支援するか
利害関係者	プロジェクトの主要な利害関係者（法的/物理的）、その役割、責任範囲を説明してください。 利害関係者がシステムを直接使用する場合は、その方法を説明してください。
一般的な機能	システムのおおよその機能を説明してください。 必需品に焦点を当て、詳細を避ける
技術的な制限	説明： 開発中のシステムが特定の理由で使用しなければならないハードウェアおよび/またはソフトウェア 統合する他のシステム 必須の技術標準、GOST、プロトコル
ビジネス制限	説明： 期間 予算の制約 法的側面
品質特性	パフォーマンス、可用性、セキュリティなどの品質システム要件について教えてください。 なぜ、誰に対して（利害関係者から）必要であるかを逐語的に説明してください。

プレゼンテーションは、請負業者の代表者と合意する必要があります-コンテンツ自体の関連性に加えて、プレゼンテーションのサイズに注意を払う必要があります。 割り当てられた時間に収まらない場合は、クライアントにそのボリュームを減らし、不要な詳細を取り除くか、割り当てられた時間を増やすよう依頼する必要があります。 さらに、ワークショップをいくつかの部分に分けることもできますが、これは非常に大きなプロジェクトの場合にのみ正当化されることを理解する必要があります



ワークショップが近づくにつれて、ロジスティクスに対処する必要があります。



素材 必要な資料はすべて事前に準備しておく必要があります。 そして、これは紙とペンだけではありません。 人々のレイアウトを考え、フリップチャート、プロジェクター、ケーブルの数を計算し、ドキュメントテンプレートを準備する必要があります。



次のようにスペースを整理します。







栄養 おなかがすいたお腹は働くのが難聴です。 昼食時の時間を節約するために、ワークショップの会場近く、たとえば同じ建物で開催することをお勧めします。 この場合、誰かが食べたい場所を探しすぎていたために夕食が遅れるという状況を避けることができます。 事前に場所を予約し、注文することを忘れないでください。 また、出席者が空腹にならず、ワークショップ中に退屈しないように、お茶、コーヒー、スナックなどの小さなスナックを考えてください。



交通機関。 通常、パフォーマーのチームが顧客にオフィスに到着しますが、代替手段がある場合があります。 ワークショップ会場への参加者の共同輸送を組織することが理にかなっている場合があり、これが都市間フライトを必要とする場合、事前にチケットの問題を解決する必要があります。

2.ワークショップを開催する

まず、コーディネーターはすべての参加者にワークショッププログラムを提示し、基本的なルールを説明します。

• 電話を切断する
• 他の参加者のアイデアを批判しないでください
• 気を散らさないでください-収集された要件の完全性は、ワークショップ参加者の関与度に依存します。

規則の発表後、ワークショップの目的と手順を簡単に説明する価値があります。



次に、顧客がプロジェクトを提示します（私たちが思い出すように、プレゼンテーションは顧客によって事前に準備されました）。 顧客側でプロジェクトマネージャーが実施。



次に、要件収集プロセスが開始されます。

• 機能要件。 参加者が完成した技術ソリューションについて説明し始めるのではなく、システムが解決するタスクに集中するようにすることが重要です。
• システムの定性的特性。 最初に、完全なリストが決定され、10分以内に完了します。次に、質的特性ごとに詳細なスクリプトが作成されます。
• 期限、予算、立法面などのビジネス制限 。
• 技術的な制限には、特定の技術（ライブラリ、フレームワーク、プラットフォーム、OSなど）を使用する必要があることが含まれます。

これらのカテゴリはACDMプロセスに固有です。 あなたの場合、これらは使用シナリオ、ユーザーストーリー、および他のドキュメントになります。



要件のカテゴリごとに、事前にテンプレートを準備することをお勧めします。 たとえば、ユースケースのテンプレートはこちらにあります 。 そのため、参加者は自分自身の方向を決めやすくなり、アイデアを書き留めることができるようになります。 さらに、テンプレートは要件の設計の均一性を実現するのに役立ちます。 参加者は暫定的なアイデアを記録するのに時間がかかります。 以下に説明する方法のいずれかで、コーディネーターは各参加者から予備的な要件を収集します。 参加者が別の要求を要求すると、他の参加者はそれを補足し、コメントを作成し、コーディネーターがディスカッションを制御します。 要件が完全に説明されたら、プロジェクタに表示するか、ボードに書き込む必要があります。これにより、繰り返しを避けることができます。







要件収集プロセスを整理するには、いくつかの方法があります。

• 要求によって 。 誰もが彼が望むときに書いた要件を表明します。 これは、かなりおしゃべりな人がいるチームで機能します。そうでなければ、コメントは待つことができません。
• 輪になって 。 この方法の利点は、要件を収集するプロセスに全員が関与することです。 しかし、人が自分の考えを表明した後、そのプロセスから気をそらすことができます。 参加者がアイデアを使い果たした場合、円をスキップする可能性を考慮する価値があります。
• ランダム調査 。 前の2つのアプローチの間の何かですが、この場合、コーディネーターは次のスピーカーをランダムに選択します。 このメカニズムの主な魅力は、誰もがイベントの経過をたどることです。
• 興味によって 。 それぞれが彼にとって興味深いシステムの部分を説明しています。 この方法は、複数のユーザーが異なる目的でシステムを使用する場合に効果的です。 ただし、前の方法とは異なり、参加者はイベントのスレッドを失う可能性があります。 さらに、出席者の中には、議論に参加したいという希望をまったく表さない人もいます。

各段階の最後に、次のように優先順位を付けます。すべての参加者に投票を行います（数の点では、要件の3分の1から半分の数にする必要があります）。 各参加者は、必要に応じて要件に投票できます。 したがって、参加者は、高中低の精神での優先順位付けとは対照的に、投票において、要件の相対的な重要度を決定できます。 公然と投票の両方で投票できます。



重要なポイント：

• 現在の要件を説明するまで、次へ進まないでください。
• 現在の議論に関係のない重要なトピックがある場合、または一部の要件で十分な情報がない場合は、会議後に後で質問に戻るために質問を延期します（たとえば、ステッカーに書いて別のボードに掛ける）。

これでワークショップの主要部分は終了します。 収集された情報を処理する段階で参加者の助けが必要になる場合があることは参加者に注目する価値があります。

3.最後の部分

受信した情報の処理

利害関係者から要件を収集する初期段階の後、請負業者のチームは、受け取った情報を処理するために個別に収集します。 予想されるイベントコース：前の会議の秘書がプロジェクターでメモを表示し、チームがメモを確認して編集を完了します。 この段階は、前に延期されたトピックに戻るときです。

ドキュメントの最終版は、ワークショップのすべての参加者に送信されます。



以下の図は、1つ以上のワークショップのフレームワークで収集された要件の処理を示しています。

成功の秘

• 準備 オフラインで実行できるすべてのアクションは、すべての参加者が事前に実行する必要があります。
• コーディネーター 。 ワークショップの成功は組織のレベルに依存するため、コーディネーターの役割についてそのようなイベントを実施した経験のある人を配置することをお勧めします。 極端な場合、ワークショップに少なくとも1回参加した人。
• 参加者 。 自分が代表するグループに対して独自の決定を下せる人を集めることが重要です。 さらに、ワークショップを開始する前に、すべての参加者の意見が等しく重要であることを明確にする価値があります。
• 最も論争を引き起こす要件と目標から始めてください。 これは明らかですが、この瞬間をお見逃しなく。
• 複数の参加者が来られない場合は、ワークショップを延期します。 多くの時間を費やし、答えよりも多くの質問を残すのは残念です。

まとめると

そのため、ワークショップは、受信した情報の計画、実施、処理という3つの部分で構成されています。 計画段階では、すべての参加者が利用可能なドキュメントに精通し、要件が特定および指定されている間、処理段階では、収集された要件に基づいてドキュメントが生成されます。



もちろん、ワークショップは顧客とのやり取りのすべての問題を解決するわけではなく、管理が間違っていると時間の無駄になります。 ただし、有能な組織では、ワークショップは開発プロセスに顧客を巻き込むための強力なツールです。これにより、最終製品の共通のビジョンに到達し、開発されたシステムのすべての機能を可能な限り考慮することができます。



この資料は、イノポリス大学のMSIT-SEプログラムによって作成されました。 要件収集の詳細は、「ソフトウェア設計方法」コースで説明されています。



MSIT-SEプログラムの詳細については、 こちらをご覧ください 。