共同アプリケーション設計

共同アプリケーション設計（共同アプリケーション開発、または JAD とも呼ばれる）は、もともとは 1970 年代半ばにニューヨーク電話会社のシステム開発センターがダン・ギーランの指揮の下で開発および展開したソフトウェア開発プロセスを説明するために使用された用語です。この方法論の一連の実装の後、ギーランはさまざまなフォーラムでこの方法論とその実践について幅広く講演しました。当時サスカチュワン州レジャイナの IBM カナダのシニア システム エンジニアであったアーニー・リンドが1974 年に共同アプリケーション設計を作成し、その名前を付けました。しかし、既存の方法では、アプリケーション開発者が特定の部門または職務の詳細を数ヶ月かけて学習し、その後、その機能または部門向けのアプリケーションを開発する必要がありました。開発のバックログの遅延に加えて、このプロセスはアプリケーションの開発に何年もかかり、アプリケーション ユーザーに完全に受け入れられないことがよくありました。

アーニー・リンドのアイデアは、アプリケーション開発者が人々の仕事内容を学ぶのではなく、実際にその仕事をしている人にアプリケーションの書き方を教えるというものだった。アーニーはこのコンセプトをIBMカナダの副社長カール・コーコラン（後にIBMカナダ社長）に提案し、カールはパイロットプロジェクトを承認した。カール・コーコランは、アーニー・リンドのイニシャルがJAL（ジョン・アーノルド・リンド）であることに気づき、当初提案したJAL（ジョイント・アプリケーション・ロジスティクス）という略語を却下したため、アーニーとカールはこの手法をJAD（ジョイント・アプリケーション・デザイン）と名付けた。

このパイロットプロジェクトは、サスカチュワン州政府の救急救命室プロジェクトでした。アーニーはJADメソッドを開発し、主に救急救命室の看護師と管理者、そして一部のアプリケーション開発担当者を対象とした1週間のセミナーを開催しました。この1週間のセミナーでアプリケーションフレームワークが作成され、その後、従来のアプリケーション開発の平均18ヶ月に対し、1ヶ月以内にコーディングと実装が完了しました。また、ユーザー自身がシステムを設計したため、アプリケーションはすぐに採用され、好評を得ました。パイロットプロジェクト後、IBMはJADメソッドをIBMハードウェア上で動作するコンピューティングアプリケーションをより迅速に実装する方法として高く評価し、積極的に支持しました。

アーニー・リンドはその後13年間、IBMカナダでJADメソッドの開発を続け、世界中を旅してJADセミナーを開催し、IBM社員にJADの手法と技術を指導しました。JADはIBMカナダ全土で広く実施され、その技術はアメリカのIBMにも広まりました。アーニー・リンドはIBMカナダで、トニー・クロフォードやチャック・モリスを含む数名にJADの実施方法を指導しました。アーニー・リンドは1987年にIBMを退職しましたが、その後もカナダ、アメリカ、アジア各地でコンサルタントとしてJADの指導と実施を続けました。

JADプロセスは、1970年代後半にIBMのトニー・クロフォードとチャック・モリスによって体系化されました。その後、カナディアン・インターナショナル・ペーパー社で導入されました。JADは、米国に持ち込まれる前に、IBMカナダでしばらく使用されました。当初、IBMはCOPICSと呼ばれる自社販売のソフトウェアプログラムの販売と実装を支援するためにJADを使用しました。これは、システム要件、穀物エレベーターの設計、問題解決など、多くの用途に広く適用されました。トニー・クロフォードは後にJAD-Plan、そしてJAR（共同アプリケーション要件）を開発しました。1985年、ゲイリー・ラッシュはComputerworld誌でJADとその派生であるFacilitated Application Specification Techniques（FAST）について執筆しました。^{[ 1 ]}

元々、JAD は、さまざまなバックグラウンドや意見を持つシステム開発者とユーザーを生産的かつ創造的な環境に集めるために設計されました。会議は、質の高い要件と仕様を得るための方法でした。構造化されたアプローチは、システムアナリストによる従来の連続インタビューの良い代替手段となります。その後、JAD は、より広範な IT 作業だけでなく、非 IT 作業にも拡大しました (JAD の適用範囲を拡大するために 1985 年に Gary Rush によって作成された Facilitated Application Specification Techniques (FAST) についてお読みください。^{[ 2 ]}

エグゼクティブスポンサー

プロジェクトを立案する責任者、つまりシステムオーナー。意思決定を行い、必要な戦略、計画、指示を提供できるだけの組織内の高い地位に就いている必要がある。

分野別専門家

これらは、ワークショップを成功させるために必要な、ビジネスユーザー、情報システム専門家、そして外部の専門家です。このグループは会議の要であり、変革を推進する原動力となります。

ファシリテーター／セッションリーダー

ファシリテーターは会議を進行し、会議の議題に沿って参加者を誘導します。会議中に解決できる問題と、会議終了後にフォローアップ調査と解決のために担当者に割り当てる必要がある問題を特定する責任があります。ファシリテーターは参加者をサポートする役割を担い、会議に情報を提供することはありません。

書記／モデラー／記録係／文書作成専門家

会議の議事録を作成・公開するが、会議に情報を提供することはない。

観察者

通常は、プロジェクトに割り当てられたアプリケーション開発チームのメンバーが参加します。彼らは参加者の後ろに座り、静かに進行状況を観察します。

1. プロジェクトの目的と制約を特定する: ワークショップとプロジェクト全体の明確な目的を持つことが不可欠です。ワークショップ前の活動、計画とスコープ設定は、ワークショップのスポンサーと参加者の期待を設定します。スコープ設定では、プロジェクトの範囲内にあるビジネス機能を特定します。また、プロジェクトの設計と実装の複雑さの両方を評価しようとします。プロジェクトの政治的な機密性を評価する必要があります。これは過去に試みられたことがありますか? 何回の失敗がありましたか? 実装の失敗は何回ありましたか? 規模設定は重要です。最良の結果を得るには、システムプロジェクトは、画面やメニューに至るまで、完全な設計を 8 ～ 10 日間のワークショップで設計できるように規模を設定する必要があります。
2. 重要な成功要因を特定する：開発プロジェクトと調査対象の業務機能の両方について、重要な成功要因を特定することが重要です。計画された変更が効果的であったことをどのように確認するのでしょうか？成功はどのように測定されるのでしょうか？成果評価の計画を立てることで、導入されたシステムの有効性と品質を、運用期間全体にわたって判断することができます。
3. プロジェクトの成果物を定義する：一般的に、ワークショップの成果物はドキュメントと設計図です。ワークショップのドキュメントの形式と詳細レベルを定義することが重要です。どのような種類の図が提供されるのでしょうか？どのような種類の、または形式の記述が提供されるのでしょうか？最初から図の作成を支援するCASEツールを使用することをお勧めします。利用可能なツールのほとんどは、優れた図作成機能を備えていますが、記述のサポートは一般的に弱いです。記述は、標準的なワープロソフトで作成するのが最適です。
4. ワークショップのスケジュールを定義する：ワークショップの期間は1日から5日まで様々です。プロジェクトの最初のワークショップは3日間以上行うべきです。参加者は初日の大半を、それぞれの役割、他の参加者、そして環境に慣れることに費やします。2日目は、お互いを理解し、問題や懸念事項を伝えるための共通言語を開発することに費やされます。3日目には、全員が協力して問題に取り組み、真の生産性が達成されます。最初のワークショップが終われば、チームビルディングは完了です。プロジェクトの次の段階、例えばプロトタイプの検証のために、より短いワークショップをスケジュールすることができます。ただし、最初のワークショップで築いたチーム心理を参加者が再び確立するには、1時間から3時間かかります。
5. 参加者を選定する：ワークショップを成功させるために必要なのは、ビジネスユーザー、IT専門家、そして外部の専門家です。彼らは会議の真の「中核」であり、変革を推進する原動力となるでしょう。
6. ワークショップ資料の準備：ワークショップに先立ち、プロジェクトマネージャーとファシリテーターは分析を行い、ワークショップの焦点を絞るための予備設計図（ストローマン）を作成します。ワークショップ資料は、参加者が調査対象の業務機能を理解するのに役立つ文書、ワークシート、図表、さらには小道具などで構成されます。
7. ワークショップの活動と演習を編成する: ファシリテーターは、ワークショップの最終成果物につながる中間成果物を提供するワークショップの演習と活動を設計する必要があります。ワークショップ前の活動は、これらのワークショップの演習を設計するのに役立ちます。たとえば、ビジネス領域分析の場合、何が含まれますか? 分解図? 高レベルのエンティティ関係図? 正規化されたデータ モデル? 状態遷移図? 依存関係図? 上記すべて? 上記のいずれでもない? 環境に適した技術的な図のレベルを定義することが重要です。図について最も重要なことは、ユーザーが理解できる必要があるということです。図の選択が決定したら、ファシリテーターはワークショップの議題に演習を設計して、グループにそれらの図を作成させます。ワークショップでは、互いに積み重ねていくように直列に指向された演習と、各サブチームが問題の一部に取り組むか、異なる機能領域で同じことに取り組む並行演習を組み合わせます。ファシリテーター主導の高強度演習はグループに活力を与え、特定の目標へと導きます。低強度演習では、意思決定の前に詳細な議論を行うことができます。議論にはグループ全体が参加することも、チームが課題を解決し、グループ全体が検討するための限られた数の提案を提示することもできます。参加者を統合するために、ファシリテーターは異なる部門から同様の専門知識を持つ人を組み合わせることができます。参加者が互いに学び合えるように、ファシリテーターは専門知識を混ぜ合わせることができます。ワークショップの組織的、文化的、政治的目的を達成するために、サブチームのメンバーを組み合わせるのはファシリテーターの役割です。ワークショップは技術レベルと政治レベルの両方で機能します。合意とコミュニケーションを構築し、プロセスの早い段階で問題を提起するのはファシリテーターの役割です。根本的なビジネス上の問題が解決できない場合、システムの技術的な実装について心配する必要はありません。
8. ワークショップ参加者の準備、情報提供、教育：ワークショップの参加者全員に、プロジェクトの目的と制約、およびワークショップで期待される成果物について周知徹底する必要があります。参加者への説明会は、ワークショップの1～5日前に行う必要があります。参加者が広範囲に分散している場合は、電話会議で説明会を実施できます。説明会資料は、「概要説明ガイド」、「説明会ガイド」、「プロジェクト範囲定義」、「管理定義ガイド」など、適切な名称で作成できます。資料は8～12ページで、参加者に対してプロジェクトの範囲を明確に定義します。説明会自体は2～4時間かかります。説明会は、参加者全員がワークショップに向けて必要な心理的準備を整えるのに役立ちます。
9. ワークショップのロジスティクスを調整する：ワークショップは中断を避けるため、会場外で開催する必要があります。プロジェクター、スクリーン、PC、テーブル、マーカー、マスキングテープ、付箋など、多くの備品を用意してください。必要な具体的な設備や備品はファシリテーター次第です。シンプルなフリップチャートから電子ホワイトボードまで、様々なものが考えられます。いずれにしても、部屋のレイアウトは参加者間のコミュニケーションと交流を促進するものでなければなりません。

• JADは、要件定義プロセスにかかる時間とコストを削減します。2～4週間で情報が収集されるだけでなく、様々なシステムユーザーによって合意された要件が特定されます。JADの経験により、企業はシステム分析プロセスを、ミッションクリティカルな業務向けのメソッドであるダブルヘリックスのような、よりダイナミックなものへとカスタマイズできるようになります。
• JADセッションは、専門家同士が一堂に会し、意見を共有したり、他者の意見を理解したり、プロジェクトに対する当事者意識を育む機会を提供するのに役立ちます。
• JADの実装方法はよく知られており、「市場で入手可能な最初の、そしておそらく最もよく知られている加速設計手法」であり、あらゆる組織が容易に適用できる。
• CASEツールをJADワークショップに容易に統合することで、セッションの生産性が向上し、システムアナリストは議論済みですぐに使用できるモデルを利用できるようになります。

• JADセッションに向けた多角的な準備がなければ、専門家の貴重な時間は容易に無駄になってしまう。JADセッションの主催者が評価対象となるシステムの要素を十分に検討しなければ、誤った問題に取り組んだり、不適切な参加者を招いたり、不十分な問題解決リソースを使用したりする可能性もある。
• JADワークショップの参加者には、問題の関連領域のほとんど、あるいはすべてについて意見を提供できる従業員を含めるべきです。そのため、参加者の選定には特に注意を払う必要があります。グループは、新しいシステムとやり取りする様々な部門の従業員だけでなく、組織階層の異なる階層の従業員で構成されるべきです。参加者間で意見の相違が生じる可能性もありますが、会議を通じて様々な視点から問題を見ることができるようになります。JADは、基盤となるプロセスをより深く理解することで、より優れたモデルの概要を明らかにします。
• ファシリテーターは、最も発言力の強い参加者だけでなく、すべての参加者が意見、アイデア、考えを述べる機会を得られるようにする義務がある。  

• Yatco, Mei C. (1999). "共同アプリケーション設計/開発" . ミズーリ大学セントルイス校. 2009年2月6日取得.
• Soltys, Roman; Anthony Crawford (1999). "JAD for business plans and designs" . 2009年3月13日時点のオリジナルよりアーカイブ。 2009年2月6日取得。
• Dennis, Alan R.; Hayes, Glenda S.; Daniels, Robert M. Jr. (1999年春) 「グループサポートシステムを用いたビジネスプロセスモデリング」 . Journal of Management Information Systems . 15 (4): 115–142 . doi : 10.1080/07421222.1999.11518224 . 2015年5月14日取得.
• Botkin, John C. 「アプリケーション開発プロセスにおける顧客参加」。 1998年12月1日にオリジナルからアーカイブ済み。
• モーラー、ウォルター E. 「ファシリテーターによる情報収集セッション：情報工学の手法」 。 2010年3月22日取得。
• ビル・ジェネリッチ「共同アプリケーション設計 ― 成功するリエンジニアリングのためのビジネス要件分析」2006年6月26日 18:50 (UTC)最終更新日時不明。1999年11月14日アクセス。
• ゲイリー・ラッシュ著「JAD ― その歴史と進化 ― MGRコンサルティングニュースレター」2006年7月
• ゲイリー・ラッシュ、「JADプロジェクトが設計を支援」、Computerworld、第18巻第52号、31ページと38ページ、1984年12月24日。
• Davidson, EJ ( 1999 ). 「実践における共同アプリケーション設計 (JAD)」。Journal of Systems and Software。45 ( 3) 。Elsevier BV: 215–223。doi : 10.1016 / s0164-1212(98)10080-8。ISSN 0164-1212。 
• ゴッテスディナー、エレン; 『コラボレーションによる要件定義：ニーズを定義するためのワークショップ』、アディソン・ウェスリー、2002年、ISBN 0-201-78606-0。
• ウッド、ジェーン、シルバー、デニス著；共同アプリケーション開発、ジョン・ワイリー・アンド・サンズ社、ISBN 0-471-04299-4