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

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

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

このパイロット・プロジェクトは、サスカチュワン州政府の救急治療室プロジェクトでした。アーニーは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を使用していました。COPICSは、システム要件定義、穀物倉庫の設計、問題解決など、様々な用途に広く採用されました。トニー・クロフォードは後にJAD-Planを開発し、さらにJAR（共同アプリケーション要件定義）を開発しました。1985年、ゲイリー・ラッシュはComputerworld誌でJADとその派生であるFacilitated Application Specification Techniques（FAST）について執筆しました。[ 1 ]

JADは当初、多様な背景や意見を持つシステム開発者とユーザーを、生産的かつ創造的な環境で結集させることを目的として設計されました。会議は、質の高い要件と仕様を得るための手段でした。この構造化されたアプローチは、システムアナリストによる従来の連続インタビューに代わる優れた選択肢となります。JADはその後、IT業務だけでなくIT以外の業務にも幅広く適用できるようになりました（JADの適用範囲を拡大するために、ゲイリー・ラッシュ氏が1985年に考案したFacilitated Application Specification Techniques（FAST）についてはこちらを参照）。[ 2 ]

主要な参加者

エグゼクティブスポンサー
プロジェクトの計画を策定する経営幹部、システムオーナー。組織内で十分な地位を持ち、意思決定を行い、必要な戦略、計画、方向性を示す必要があります
分野別専門家
ワークショップの成功には、ビジネスユーザー、情報システム専門家、そして外部の専門家が必要です。このグループは会議の核となり、変革を推進します
ファシリテーター／セッションリーダー
会議を進行し、グループが会議の議題に沿って進むように導きます。ファシリテーターは、会議中に解決できる問題と、会議終了時にフォローアップ調査と解決のために割り当てが必要な問題を特定する責任があります。ファシリテーターは参加者にサービスを提供するものであり、会議に情報を提供するものではありません
筆記者／モデラー／記録係／文書作成専門家
会議の議事録を記録し、公開しますが、会議に情報を提供することはありません
オブザーバー
通常は、プロジェクトに割り当てられたアプリケーション開発チームのメンバーです。参加者の後ろに座り、静かに進行を観察します

9つの重要なステップ

  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は、基盤となるプロセスをより深く理解することで、より優れたモデルの概要を明らかにします。
  • ファシリテーターには、最も発言力のある参加者だけでなく、すべての参加者が意見、アイデア、考えを述べる機会を確保する義務があります。

参考文献

  1. ^「システム要件を定義するための迅速な方法」、ゲイリー・ラッシュ著、Computerworld、第19巻第40号、詳細ページID/11～ID/16（47～52ページ）、1985年10月7日。トランスクリプトはこちら
  2. ^ JAD | FAST | FoCuSeD™ 構造化ファシリテーション手法[1] .)

参考文献

「 https://en.wikipedia.org/w/index.php?title=Joint_application_design&oldid=1311530156」より取得