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

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

アーニー・リンドのアイデアは、アプリケーション開発者に人々の仕事について学ばせるのではなく、その仕事をしている人にアプリケーションの書き方を教えればいいというものでした。アーニーは、IBM カナダの副社長であるカール・コーコラン (後の IBM カナダ社長) にこのコンセプトを提案し、カールはパイロット プロジェクトを承認しました。カール・コーコランが、アーニー・リンドのイニシャルが JAL (John Arnold Lind) であることに気付き、頭字語の JAL (joint application logistics) を拒否したことから、アーニーとカールは共同でこの手法を JAD (joint application design) と名付けました。

パイロット プロジェクトは、サスカチュワン州政府の緊急治療室プロジェクトでした。アーニーは JAD 方法論を開発し、主に緊急治療室の看護師と管理者を巻き込み、アプリケーション開発担当者も参加した 1 週間のセミナーを開催しました。1 週間のセミナーでアプリケーション フレームワークが作成され、その後 1 か月未満でコーディングと実装が完了しました。これは、従来のアプリケーション開発の平均 18 か月をはるかに上回る期間です。また、ユーザー自身がシステムを設計したため、ユーザーはすぐにアプリケーションを採用し、気に入りました。パイロット プロジェクトの後、IBM は JAD 方法論を非常に支持しました。IBM は、IBM ハードウェアで実行されるコンピューティング アプリケーションをより迅速に実装する方法として JAD 方法論を捉えたからです。

アーニー リンドはその後 13 年間 IBM カナダで JAD 方法論の開発を続け、世界中を旅して JAD セミナーを開催し、IBM の従業員に JAD の方法と技法をトレーニングしました。JAD は IBM カナダ全土で広く実施され、その技法は米国の IBM にも広まりました。アーニー リンドは IBM カナダでトニー クロフォードやチャック モリスなど数名に JAD の実施方法をトレーニングしました。アーニー リンドは 1987 年に IBM を退職し、カナダ、米国、アジア各地でコンサルティング ベースで JAD の指導と実施を続けました。

JAD プロセスは、1970 年代後半に IBM の Tony Crawford と Chuck Morris によって公式化されました。その後、Canadian International Paper で導入されました。JAD は、IBM Canada でしばらく使用されていましたが、その後米国に持ち帰られました。当初、IBM は、COPICS と呼ばれる自社製ソフトウェア プログラムの販売と実装に JAD を使用していました。このプログラムは、さまざまな用途 (システム要件、穀物倉庫の設計、問題解決など) に広く採用されました。Tony Crawford は後に JAD-Plan を開発し、その後 JAR (共同アプリケーション要件) を開発しました。1985 年、Gary Rush は Computerworld で JAD とその派生である Facilitated Application Specification Techniques (FAST) について執筆しました。^[1]

もともと、JAD は、さまざまな背景や意見を持つシステム開発者とユーザーを生産的かつ創造的な環境に集めるために設計されました。ミーティングは、品質要件と仕様を取得する方法でした。構造化されたアプローチは、システムアナリストによる従来の連続インタビューに代わる優れた方法です。その後、JAD は IT 業務だけでなく非 IT 業務も幅広くカバーするようになりました (1985 年に Gary Rush が JAD の適用範囲を拡大するために作成した Facilitated Application Specification Techniques (FAST) についてお読みください)。^[2]

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

プロジェクトの計画を策定する役員、システム所有者。組織内で十分な地位を持ち、意思決定を行い、必要な戦略、計画、指示を提供できる必要があります。

主題専門家

これらは、ワークショップを成功させるために必要なビジネス ユーザー、IS プロフェッショナル、および外部の専門家です。このグループは会議の中心であり、変更を推進します。

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

ファシリテーターは、会議の進行を司り、グループが会議の議題に集中できるようにして進行を誘導します。ファシリテーターは、会議中に解決できる問題と、会議の最後にフォローアップ調査と解決のために割り当てられる必要がある問題を特定する責任があります。ファシリテーターは参加者にサービスを提供するだけで、会議に情報を提供することはありません。

筆記者/モデラー/記録者/文書作成専門家

会議の議事録を記録して公開しますが、会議に情報を提供することはありません。

オブザーバー

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

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 を体験することで、企業はシステム分析プロセスを、ミッション クリティカルな作業のための方法論であるDouble Helixなどのさらに動的なプロセスにカスタマイズできます。
• JAD セッションは、専門家を集めて意見を共有し、他者の意見を理解し、プロジェクトのオーナーシップ意識を育む機会を提供します。
• JAD 実装の方法は、「市場で入手可能な最初の高速設計手法であり、おそらく最もよく知られている」ためよく知られており、どの組織でも簡単に適用できます。
• CASE ツールを JAD ワークショップに簡単に統合できるため、セッションの生産性が向上し、システム アナリストには議論済みのすぐに使用できるモデルが提供されます。

• JAD セッションの多面的な準備がなければ、専門家の貴重な時間が簡単に無駄になる可能性があります。JAD セッションの主催者が評価対象のシステムの要素を研究しないと、間違った問題が取り上げられたり、間違った人が参加するよう招待されたり、問題解決のリソースが不十分になったりする可能性があります。
• JAD ワークショップの参加者には、問題の関連領域のほとんど、あるいはすべてについて意見を述べることができる従業員が含まれている必要があります。参加者の選択には特に注意を払う必要があるのはそのためです。グループは、新しいシステムとやり取りするさまざまな部門の従業員だけでなく、組織階層のさまざまな階層の従業員で構成されている必要があります。参加者の視点は相反するかもしれませんが、会議によって参加者はさまざまな観点から問題を見ることができます。JAD は、基礎となるプロセスをより深く理解することで、より優れたモデルの概要を明らかにします。
• ファシリテーターには、最も発言力のある参加者だけでなく、すべての参加者が意見、アイデア、考えを述べる機会を確保する義務があります。

• Yatco, Mei C. (1999) 「共同アプリケーション設計/開発」 ミズーリ大学セントルイス校2009 年 2 月 6 日閲覧。
• Soltys, Roman、Anthony Crawford (1999)。「ビジネス プランと設計のための JAD」。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 日のオリジナルからアーカイブ。
• Moeller, Walter E.「ファシリテートされた情報収集セッション: 情報エンジニアリング手法」 。2010年 3 月 22 日閲覧。
• Bill Jennerich「共同アプリケーション設計 - リエンジニアリングを成功させるためのビジネス要件分析」2006年6月26日18:50 (UTC)[2] 最終更新時間不明。1999年11月14日にアクセス。
• ゲイリー・ラッシュ「JAD - その歴史と進化 - MGRコンサルティングニュースレター」2006年7月[3]
• ゲイリー・ラッシュ、「JADプロジェクトが設計を支援」、Computerworld、第18巻第52号、31ページと38ページ、1984年12月24日。[4]
• Davidson, EJ (1999). 「共同アプリケーション設計 (JAD) の実践」.システムおよびソフトウェアジャーナル. 45 (3). Elsevier BV: 215–223. doi :10.1016/s0164-1212(98)10080-8. ISSN  0164-1212.
• Gottesdiener, Ellen; Requirements by Collaboration: Workshops for Defining Needs、Addison-Wesley、2002、ISBN 0-201-78606-0。 
• ウッド、ジェーン、シルバー、デニス;共同アプリケーション開発、ジョン ワイリー アンド サンズ社、ISBN 0-471-04299-4