DSDMプロジェクト管理手法のモデル

動的システム開発手法( DSDM ) は、アジャイルプロジェクト配信フレームワークであり、最初はソフトウェア開発手法として使用されていました。[1] [2] 1994 年に初めてリリースされた DSDM は、当初、迅速なアプリケーション開発(RAD) 手法に何らかの規律を提供することを目指していました。[3]その後のバージョンでは、DSDM アジャイル プロジェクト フレームワークが改訂され、ソフトウェア開発とコード作成に特に焦点を当てるのではなく、プロジェクト管理とソリューション配信に対する一般的なアプローチになり[要説明] [要引用]、IT 以外のプロジェクトにも使用できるようになりました。[4] DSDM アジャイル プロジェクト フレームワークは、プロジェクト ライフサイクル全体にわたる幅広いアクティビティをカバーし、他のアジャイル手法とは一線を画す強力な基盤とガバナンスを備えています。[5] DSDM アジャイル プロジェクト フレームワークは、継続的なユーザー/顧客の関与を含むアジャイル開発の原則を取り入れた反復的で増分的なアプローチです。

DSDMは、コスト、品質、時間を最初に確定し、MoSCoW方式を用いてスコープを「必須」「すべき」 「できる」「不要」に分類し、定められた時間制約を満たすようにプロジェクトの成果物を調整します。DSDMは、ソフトウェアおよび非ITソリューション開発におけるアジャイル手法の一つであり、Agile Allianceの一部です。

2014年、DSDMは「DSDMアジャイルプロジェクトフレームワーク」として最新版の手法をリリースしました。同時に、新しいDSDMマニュアルでは、サービスデリバリーのための他のフレームワーク（特にITIL） 、 PRINCE2、Managing Successful Programmes、PMIと連携する必要性を認識しました。[6]以前のバージョン（DSDM 4.2）には、エクストリームプログラミングでDSDMを使用する方法に関するガイダンスのみが含まれていました。

歴史

1990年代初頭、 IT業界全体にラピッド・アプリケーション開発（RAD）が広がりました。ソフトウェア・アプリケーションのユーザー・インターフェースは、旧来のグリーンスクリーンから、現在使用されているグラフィカル・ユーザー・インターフェースへと移行しつつありました。PowerBuilderなどの新しいアプリケーション開発ツールが市場に登場し、開発者は提案したソリューションを顧客とより容易に共有できるようになりました。プロトタイピングが現実のものとなり、従来のシーケンシャル（ウォーターフォール）開発手法の煩わしさから解放されました。

しかし、RAD運動は非常に非体系的でした。適切なプロセスについての共通認識はなく、多くの組織が独自の定義とアプローチを考案していました。多くの大企業はその可能性に強い関心を示しましたが、フリーフロー開発によって得られる最終成果物の品質レベルを損なわないよう懸念していました。

DSDMコンソーシアムは、ソフトウェアエンジニアリング分野のベンダーと専門家の団体によって1994年に設立されました。設立の目的は、各社のベストプラクティスの経験を結集し、「独立したRADフレームワークを共同で開発・推進する」ことです。その起源は、ロンドンでButler Groupが主催したイベントです。この会議に出席した人々は、 British Airways、American Express、Oracle、Logicaといった一流企業に勤務する人々でした（Data SciencesやAllied Domecqなどの企業は、その後、他の組織に吸収されました）。

2006年7月にDSDMパブリックバージョン4.2 [7]が個人で閲覧および使用できるようになりました。ただし、DSDMを再販する人は、非営利コンソーシアムのメンバーである必要があります。

2014年には、DSDMハンドブックがオンラインで公開されました。[8]さらに、DSDMのテンプレートをダウンロードすることもできます。[9]

2016年10月、DSDMコンソーシアムはアジャイルビジネスコンソーシアム（ABC）に名称を変更しました。[10]アジャイルビジネスコンソーシアムは、DSDMフレームワークを所有および管理する非営利のベンダー独立組織です。[11]

説明

DSDMは、プロジェクトが失敗する原因の多くが技術よりも人的問題によるものであることを認識した、ベンダーに依存しないアプローチです。DSDMは、人々が効果的に連携してビジネス目標を達成できるよう支援することに重点を置いています。また、DSDMはツールや手法に依存しないため、特定のベンダーに縛られることなく、あらゆるビジネス環境や技術環境で使用できます。[8]

原則

DSDMの根底には8つの原則があります。[12]これらの原則は、チームが一貫した成果を出すために取るべき姿勢と心構えを導きます。

  1. ビジネスニーズに焦点を当てる
  2. 時間通りに納品
  3. コラボレーション
  4. 品質に妥協しない
  5. 堅固な基盤から段階的に構築する
  6. 反復的に開発する
  7. 継続的かつ明確にコミュニケーションをとる
  8. コントロールを示す

コアテクニック

  • タイムボックス化：プロジェクトを複数の部分に分割し、それぞれに固定予算と納期を設定することで、段階的に完了させるアプローチです。各部分について、いくつかの要件に優先順位を付けて選択します。時間と予算は固定されているため、残る変数は要件のみです。そのため、プロジェクトの時間や資金が不足している場合は、優先度が最も低い要件が省略されます。これは未完成の製品が納品されることを意味するわけではありません。パレートの法則によれば、プロジェクトの80%はシステム要件の20%から生じます。つまり、最も重要な20%の要件がシステムに実装されていれば、システムはビジネスニーズを満たし、最初の試みで完璧なシステムを構築することはできません。
  • MoSCoW：作業項目や要件の優先順位付けを行う手法。以下の頭字語から成ります。
    • 必須
    • すべきだった
    • 可能性があった
    • 持っていない
  • プロトタイピング：開発中のシステムのプロトタイプをプロジェクトの早期段階で作成することを指します。これにより、システムの欠陥を早期に発見し、将来のユーザーがシステムを「試運転」できるようになります。これにより、ユーザーの積極的な関与が実現され、DSDM、そしてあらゆるシステム開発プロジェクトの成功要因の一つとなります。
  • テスト：DSDMは、ソリューションの品質向上に役立ちます。DSDMは、各イテレーションを通してテストを実施することを推奨しています。DSDMはツールや手法に依存しない手法であるため、プロジェクトチームは独自のテスト管理方法を自由に選択できます。
  • ワークショップ: プロジェクトの関係者を集めて要件、機能、相互理解について話し合います。
  • モデリング：ビジネスドメインを視覚化し、理解を深めるのに役立ちます。開発中のシステムまたはビジネス領域の特定の側面を図式的に表現します。
  • 構成管理: 複数の成果物が同時に開発され、各タイムボックスの終了時に段階的に提供されるため、成果物は完了に向けて適切に管理される必要があります。

役割

DSDM環境にはいくつかの役割が導入されています。プロジェクトメンバーは、プロジェクト開始前にそれぞれの役割に任命されることが重要です。それぞれの役割には独自の責任があります。役割は以下のとおりです。

  • エグゼクティブスポンサー：いわゆるプロジェクトチャンピオン。ユーザー組織における重要な役割であり、適切な資金とリソースを投入する能力と責任を持ち、最終的な意思決定権を持ちます。
  • ビジョナリー：プロジェクトの立ち上げに責任を持ち、早期に必須要件を確実に特定します。ビジョナリーは、システムとプロジェクトのビジネス目標を最も正確に把握しています。また、開発プロセスを監督し、正しい軌道に乗せることも役割の一つです。
  • アンバサダー ユーザー: ユーザー コミュニティの知識をプロジェクトに取り入れ、開発プロセス中に開発者が十分なユーザー フィードバックを受け取れるようにします。
  • アドバイザー ユーザー: 重要な視点を代表し、プロジェクトに関する日常的な知識をもたらす任意のユーザーになります。
  • プロジェクト マネージャー: プロジェクト全体を管理するユーザー コミュニティまたは IT スタッフのいずれかになります。
  • テクニカルコーディネーター: システムアーキテクチャの設計とプロジェクトの技術的品質の管理を担当します。
  • チームリーダー: チームを率いて、チーム全体が効果的に機能することを保証します。
  • ソリューション開発者: システム要件を解釈し、成果物コードの開発やプロトタイプの構築を含めてモデル化します。
  • ソリューションテスター：いくつかのテストを実施し、技術的な範囲で正確性を確認します。必要に応じて不具合を報告し、修正後に再テストを行います。テスターはコメントとドキュメントを提供する必要があります。
  • 記録係: 各ワークショップで行われた要件、合意、決定事項を収集し、記録する責任を負います。
  • ファシリテーター: ワークショップの進行を管理する責任があり、準備とコミュニケーションの促進者として機能します。
  • 専門家の役割: ビジネス アーキテクト、品質マネージャー、システム インテグレーターなど。

成功の重要な要素

DSDM では、プロジェクトの成功を確実にするために非常に重要な要素がいくつか特定されています。

  • 要因1：まず、上級管理職をはじめとする従業員がDSDMを受け入れます。これにより、プロジェクトの様々な関係者が最初からモチベーションを高め、プロジェクト全体を通して関与し続けることが保証されます。
  • 要因2：要因1から直接派生：エンドユーザーの関与を確実にするための経営陣のコミットメント。プロトタイピングアプローチでは、機能プロトタイプのテストと評価を行うために、エンドユーザーによる強力かつ献身的な関与が求められます。
  • 要因3：プロジェクトチームは、安定した連携を形成する熟練したメンバーで構成されている必要があります。重要な課題は、プロジェクトチームへの権限委譲です。これは、チーム（またはチームメンバーの1人または複数）が、経営陣への正式な提案書の作成といった時間のかかる作業を行うことなく、プロジェクトに関する重要な意思決定を行う権限と可能性を持つことを意味します。プロジェクトチームがプロジェクトを成功させるには、プロジェクトを遂行するための適切なテクノロジーも必要です。これには、開発環境やプロジェクト管理ツールなどが含まれます。
  • 要因4：最後に、DSDMでは顧客とベンダーの間に協力的な関係が必要であると述べられています。これは、社内で実施されるプロジェクトと外部の請負業者によって実施されるプロジェクトの両方に当てはまります。協力的な関係を確保する上で、ISPLが役立つ場合があります。

他の開発フレームワークとの比較

DSDMは、幅広い反復型・増分型開発フレームワーク、特にアジャイル開発やオブジェクト指向開発をサポートするフレームワークの一部とみなすことができます。これらのフレームワークには、スクラム、エクストリーム・プログラミング（XP）、ディシプリンド・アジャイル・デリバリー（DAD）、ラショナル・ユニファイド・プロセス（RUP）などが含まれます（ただし、これらに限定されません）。

DSDM と同様に、これらには次の特徴があります。

  • これらすべてが要件に優先順位を付け、それを反復的に実行して、システムまたは製品を段階的に構築します。
  • これらはツールに依存しないフレームワークです。これにより、ユーザーはプロセスの特定のステップを独自の手法[5]と選択したソフトウェア支援で実行できます。
  • 開発における変数は時間やリソースではなく、要件です。このアプローチにより、DSDMの主な目標、すなわち期限と予算の遵守が確保されます。
  • システムに関わるすべてのステークホルダー間のコミュニケーションと関与を重視します。これは他の方法でも取り上げられていますが、DSDMはプロジェクトの成功を確実にするために、プロジェクトへのコミットメントが不可欠であると強く信じています。

参照

参考文献

  1. ^ Keith Richards, Agile project management: running PRINCE2 projects with DSDM Atern. OGC – Office of Government Commerce. The Stationery Office, 2007年7月31日.
  2. ^ Plonka, Laura他「アジャイルにおけるUXデザイン：DSDMのケーススタディ」ソフトウェアエンジニアリングとエクストリームプログラミングにおけるアジャイルプロセス、 Springer International Publishing、2014年、1-15ページ。
  3. ^ Abrahamsson, Pekka, et al. 「アジャイル手法の新たな方向性：比較分析」Wayback Machineに2018年10月24日にアーカイブ。ソフトウェアエンジニアリング、2003年。議事録。第25回国際会議。IEEE、2003年。
  4. ^ ステイプルトン、ジェニファー（2003年1月）『ビジネス重視の育成』ピアソン・エデュケーション、113ページ、ISBN 9780321112248。
  5. ^ ab Moran, Alan (2015年3月). 『アジャイルのマネジメント』 Springer. pp.  21– 24. ISBN 9783319162614。
  6. ^ DSDMアジャイルプロジェクトフレームワークマニュアル、2014年、4、16ページ
  7. ^ (www.dsdm.org 2016年10月2日アーカイブ、Wayback Machine )
  8. ^ ab 「DSDM Agileプロジェクトフレームワーク（2014年以降）」。Agile Business Consortium。2016年2月4日。
  9. ^ www.agilebusiness.org https://www.agilebusiness.org/resources/templates-and-tools/atern-template-complete-set . {{cite web}}:欠落または空|title=(ヘルプ)
  10. ^ 「AgileのDSDMコンソーシアムがAgile Business Consortiumに進化」Press Dispensary。
  11. ^ 「コミュニティメンバーシップの利用規約」（PDF） GLOBAL GAP
  12. ^ Agile Business Consortium. DSDM Agileプロジェクトフレームワーク（2014年以降）ハンドブック – 原則.

さらに読む

  • コールマンとヴェルブルッゲン：「迅速なアプリケーション開発のための高品質ソフトウェアプロセス」、ソフトウェア品質ジャーナル7、p.107-1222（1998）
  • ベイノン・デイヴィスとウィリアムズ：「情報システム開発手法の普及」『戦略情報システムジャーナル』12巻29-46頁（2003年）
  • Sjaak Brinkkemper、Saeki、Harmsen：「メソッドエンジニアリングのためのアセンブリテクニック」、Advanced Information Systems Engineering、CaiSE'98 論文集、Springer Verlag (1998)
  • アブラハムソン、サロ、ロンカイネン、『Warstaアジャイル ソフトウェア開発手法: レビューと分析』、VTT Publications 478、p. 61-68 (2002)
  • Tuffs、Stapleton、West、Eason: DSDM と Rational Unified Process の相互運用性、DSDM コンソーシアム、第 1 号、p. 1-29 (1999)
  • リートマン：DSDMの鳥瞰図、DSDMコンソーシアム、p. 3-8（2001）
  • クリス・バリー、キーラン・コンボイ、マイケル・ラング、グレゴリー・ウォトコウスキー、ウィタ・ウォトコウスキー：情報システム開発：実践、理論、教育における課題、第1巻
  • Keith Richards: Agile Project Management: running PRINCE2 projects with DSDM Atern, TSO (2007) Archived 2021-01-23 at the Wayback Machine
  • DSDM アジャイル プロジェクト フレームワーク (2014)
  • DSDM アジャイルプロジェクトマネジメントフレームワーク（v6、2014）インタラクティブマインドマップ
ウィキメディア コモンズには、動的システム開発手法に関連するメディアがあります。
  • アジャイルビジネスコンソーシアム（旧DSDMコンソーシアム）
  • AgilePM ウィキ