情報プロジェクト管理方法論

序文：この出版物の目的は、定期刊行物での出版を期待してITコミュニティからフィードバックを受け取り、記事に対する批判を集めることです。 この記事では、情報プロジェクト管理の分野で一般的な方法論について、時系列で簡単に説明します。



1958年、コンサルティング会社のBooz Allen Hamilton Inc.は、ロッキードマーティンスペースシステムズ開発センターおよび米国海軍省の特別設計センターのソフトウェア開発部門とともに、プログラム評価およびレビュー技術、コードの下での評価および分析技術を開発しました。 PERT-ポラリス潜水艦兵器システムの開発プロジェクト用[1]（弾道ミサイル）。



PERTは、時間が重要なメトリックである大規模プロジェクトを管理するときに時間を節約するように設計されました。 方法論には、プロジェクト全体の完了への影響に関する個々のタスクの分析が含まれます。特に、各タスクを完了するための時間が分析され、その結果、すべての段階を完了するために必要な最小時間が決定されます。 この手法は、各段階の詳細とそれらを完了する正確な時間が不明である不確実な条件で使用できます。さらに、コストよりも時間が重要なプロジェクトに適用されるイベント指向の手法です。



この方法論は、1968年のグルノーブル冬季オリンピックの準備に使用されました[2]。1911年にプロセスエンジニアリングに科学を適用しようとしたテイラーフレデリックウィンズローによって最初に記述された「労働科学団体」[3]および管理。



説明した手法の基本は、図1に示すように、アクティビティによって相互接続されたイベントによって表されるネットワーク図の構築です。





図 1. PERT方法論のネットワーク図



イベント自体には時間とリソースはありません。イベントの新しいステージの開始を意味するだけですが、アクティビティについては、最小、最大、通常、予想時間など、必要なリソースと時間の特性が決定されます。 スリッページまたはたるみの時間も計算されます。これは、他のアクティビティとの時間差で、それぞれこのアクティビティが実行スケジュールよりどれだけ進んでいるか遅れているかを示します。



ネットワークダイアグラムに基づいて、最も一般的なPERT手法の方法論が構築されます。クリティカルパス法は、最初のイベントから最後のイベントまでの最長ルートを構築することを本質としています。 したがって、クリティカルパスの遅延は最終イベントの開始を遅延させます。 この方法を使用すると、最も重要なタスクを決定し、最適化するために、クリティカルパス上にあるアクティビティの並列化で構成される「クイックパス」方法を使用できます。



1970年、Winston W. Royce博士は出版物「Managing the development of large software systems」[4]（ラージソフトウェアアプリケーションの開発を管理する）を出版しました。彼は後に「カスケード開発モデル」として知られる開発技術について説明しています。 、また「水流」または「滝」。 元のモデルでは、次の一連の開発手順を想定しています。

• システム要件の定義。
• ソフトウェア要件の定義。
• 分析;
• デザイン;
• 開発;
• テスト;
• 搾取。

最初は、ある段階から別の段階への連続的な移行が想定されていましたが、ここではウィンストンは次のステップに移動した後、前の段階の欠点を明らかにできる状況を検討し、前の段階に戻ってそれを完成できるモデルを提供します。 彼はさらに、将来「反復開発モデル」として知られるものに開発します。これは、カスケードと同じ段階で構成されますが、テスト段階からソフトウェア要件を決定する段階への移行を伴います。



1991年、ジェームスマーティンは、ラピッドアプリケーション開発（RAD）という本を出版しましたが、これは最小限の計画でプロトタイピングを使用したラピッドソフトウェア開発の概念を説明しています。時間とリソースを費やした。 したがって、機能の重要ではない部分の開発が期限に間に合わない場合、RADはこの機能の拒否を意味します。 RADには次の開発手順が含まれます。

• 計画-要件が定義されています。
• ユーザー設計-機能の定義。
• 建設-開発;
• スイッチング-実装;

1993年、マイクロソフトは、情報技術ソリューションを作成するための分野、概念、および原則のモデルのセットとして「Microsoft Solutions Framework」（MSF 1.0）をリリースしました。 MSFは次の値に焦点を当てています[5]：

• 技術的および商業的目標の遵守;
• 明確な目標の定義、役割と責任の配分。
• ステージまたはコントロールポイントに分割された反復プロセスの実装。
• 積極的なリスク管理。
• 変更に対する効果的な対応。

MSFの重要な要素は、原則、考え方、チームモデル、管理モデルです。 原則は推奨事項によって示されていますが、その一部を以下に示します。 チーム内で最もオープンなプロジェクト情報。 権限、責任、説明責任を備えたチームメンバーのエンパワーメント。 思考パターンには、「チームメイトの世話をする」または「生涯学習」が含まれます。



MSFチームモデルは、チーム内で役割を効果的に分散するために、カスケード開発モデルに記述されている手順を固有の目標と機能領域の観点から検討します。 管理モデルは、適切な人に適切なタイミングで適切なガイダンスを提供するように設計されており、開発の各段階でリソースと優先順位を制御することを推奨しています。 とりわけ、MSFには「コントロールポイント」などがあり、その概念は、MSFコア値の観点から考慮されたPERTネットワーク図のイベントに似ています。



1994年、17の英国企業のコンソーシアムが、迅速なRADアプリケーション開発の概念に基づいて、動的システム開発手法（DSDM）ソフトウェア開発フレームワークを作成しました。 フレームワークは、一連の原則、事前定義されたタイプのロール、および次のテクニックです[6]。

• タイムボックス
• MoSCoWの優先順位付けの原則、
• ワークショップ
• プロトタイピング。

タイムボックス技術は、プロジェクトを予定通りに完了し、予算を満たし、品質を維持するために使用される主要なDSDM技術です。 タイムボックスは反復であり、プロジェクトは時間的に間隔を空けて論理セクションに分割されます。 タイムボックスはイベントに分割されず、機能は重要ではありません。その結果、時間を節約するためにMoSCoW優先順位付け方法で決定される方法で部分的に除外することができます。 MoSCoWの優先順位付け方法は、4つの優先順位レベルを定義します。

• 持っている必要があります
• あるべき
• 必要（持つことができる）
• あなたができる（持っている）。

プロトタイピングの方法論には、プロジェクトのさまざまな作業段階での機能モデル、生産モデル、およびその他のモデルの開発が含まれます。これにより、遭遇する困難を特定し、パフォーマンスを評価し、商業的な観点からも含めて、インターフェイスと機能の使いやすさを評価できます。



DSDMでは、ユーザー（消費者）の開発プロセスへの参加に特別な注意が払われます。これは、フレームワークの不可欠な部分である原則に定められています[7]。

• 開発プロセスへの積極的なユーザーの関与。
• 開発チームは決定を下すことができます。
• 結果の頻繁な配信;
• 結果の受け入れ可能性の基準は、ビジネスへのコンプライアンスです。
• 反復的かつ漸進的な開発。
• 操作は元に戻すことができます。
• 高レベルの要件の安定性。
• テストは継続的かつ継続的に実行されます。
• 相互作用と協力。

上記のように、DSDM方法論では一連の標準的な役割を定義します。各役割は、次のような特定の責任範囲に対応しています。

• プロジェクトマネージャー-一般管理;
• 予言者-商業的な目標と目的の遵守を監視します。
• プロジェクトチャンピオン-リソース管理。
• チームリーダー-開発者をリードします。
• テクニカルコーディネーター-アーキテクチャ。
• 開発者-開発;
• テスター-テスト。
• 代表ユーザー-消費者の関心を表します。
• ユーザーコンサルタント-製品の使用に関する助言。
• 秘書-記録を担当します。
• 仲介者-チームメンバー間のやり取りを担当します。

2007年にリリースされたDSDM Aternと呼ばれる方法論の最新バージョンには、プロジェクトライフサイクルの次の7つの段階が含まれます。



1.事前プロジェクト。 プロジェクトのライフサイクルの最初の段階で、プロジェクトの適切性が決定され、とりわけ、プロジェクトの開始に関する行為の発行が許可されます。

2.実現可能性。 この段階で、ビジネス目標を効果的に達成する能力を含む、プロジェクトの技術的および経済的な実現可能性が決定されます。

3.ビジネスプロセスの定義-要件、戦略、アーキテクチャ、使用される標準、およびプロジェクト実装プロセスに関連するリスクの定義を意味します。

4.インテリジェンス。 この段階では、ビジネスプロトタイプを構築し、機能要件のリストを作成する予定です。

5.エンジニアリング。 機能以外の要件（パフォーマンス、セキュリティ、サポート、メンテナンス機能など）を解決することを目的とした設計調査。 製品の正常な動作のためのすべての要件の実装を含みます。

6.展開-最終消費者に製品を提供するための作業サイクル、トレーニング、および文書の作成を意味します。 また、製品が確立されたすべてのビジネス要件を満たしているかどうかも明らかにします。

7.プロジェクトを投稿します。 この段階では、結果が集計され、下された決定の有効性が評価されます。プロジェクトの結果に関する多くの情報を得るために、3〜6か月後にこれを行うことをお勧めします。



1995年、Jeff Sutherland博士とKen Schwaber博士は、Computer Science Associationが主催する年次実務会議「オブジェクト指向プログラミング、システム、言語、アプリケーション」（OOPSLA）で「スクラム」と呼ばれる方法論を発表しました[8]。 このアプローチは、1986年に科学者の竹内博隆氏と野中uji次郎氏によって、従来の一貫したアプローチとは対照的に、開発チームが共通の目標を達成するために全体として機能する、柔軟で全体的な製品開発戦略として最初に説明されました[9]。



最新のガイダンスに従って、スクラムは複雑な適応問題を解決し、同時に生産的かつ創造的に最高品質の製品を開発できるフレームワークとして位置付けられています。 公式文書に記載されているように、製品管理と開発の実践の相対的な有効性を示しています[10]。 このアプローチは、次の3つのカテゴリで表されます。

• チーム
• イベント
• アーティファクト。

チームは、目標の設定を担当する製品の所有者、開発チーム、およびスクラム方法論への準拠を保証するように設計されたスクラムウィザードで構成されています。 アーティファクトは内部用語であり、スクラムでイベントを使用して規則性を作成し、スクラムで指定されていない会議の必要性を最小限に抑えます。そのリストは次のとおりです。

• スプリント-DSDM方法論からのタイムボックスの類似物。
• スプリント計画;
• 毎日のスクラムラリー-その日のタスクを計画し、前の営業日の結果を話し合う15分ごとの会議。
• スプリントレビュー-反復中に達成された結果の議論と新しいタスクの設定。
• スプリント回顧展-反復後の開発プロセスの品質に関する議論。

1997年に、Jim Higgsmithによる記事「MESSY、EXCITING、ANXIETY-RIDDEN：ADAPTIVE SOFTWARE DEVELOPMENT」[11]が公開されました。 この方法論の重要な特徴は、要件とプロジェクトとの関係を新しく見直すことです。これは、絶えず変化する可能性を意味し、それに適応しようとしています。 普及している古典的なプロジェクトライフサイクル：planning-design-constructionはここで変更され、シーケンス：speculate-collaborate-learnで表されます。



1999年に、「Extreme Programming Explained：Embrace Change [12]」という本が出版され、Kent Beck、Ward Cunningham、Martin Fowlerが執筆した極端なプログラミング方法論について説明しています。 ASDのようなエクストリームプログラミングは、絶えず変化する要件に焦点を当て、そのような状況での効率的な開発プロセスに貢献する12の技術を提供します。

• 計画のゲーム（計画ゲーム）-おおよその作業計画の迅速な作成とその継続的な更新。
• 小規模リリース-製品の小規模バージョンの頻繁なリリース。
• メタファー（メタファー）-システムの簡単な説明。
• シンプルデザイン（シンプルデザイン）-アーキテクチャに関連して。
• テスト-この方法論は後に「テスト駆動開発」（TDD）と呼ばれる別の開発方法論になったことに注目する価値があります。
• 処理（リファクタリング）;
• ペアプログラミング（ペアプログラミング）-2人の開発者のタスクに関する作業への同時参加。
• コードの集団所有権（集団所有権）;
• 継続的インテグレーション（継続的インテグレーション）-開発の頻繁な実装。
• 週40時間（週40時間）;
• 開発サイトの顧客（オンサイト顧客）;
• コーディング標準

2001年、米国ユタ州は、柔軟なソフトウェア開発方法論であるマニフェストAgile Manifestoに署名しました。アジャイルは、極端なプログラミング、SCRUM、DSDM、ASD、あまり知られていない方法論Crystal、FDD、Pragmaticなどを含む開発方法論のファミリーですプログラミングなど。 アジャイルは、[13]に従う12の原則を定義しています。



1.私たちにとっての最優先事項は、貴重なソフトウェアを定期的かつ早期に提供することにより提供される顧客ニーズの満足です。

2.開発の後期段階であっても、要件の変更は歓迎されます。 アジャイルプロセスにより、変化を活用して顧客に競争力を提供できます。

3.稼働中の製品は、数週間から数か月の頻度で、できるだけ頻繁にリリースする必要があります。

4.プロジェクト全体を通して、開発者とビジネス担当者は毎日一緒に仕事をしなければなりません。

5.やる気のある専門家はプロジェクトに取り組むべきです。 行われる作業のために、条件を作成し、サポートを提供し、それらを完全に信頼します。

6.直接コミュニケーションは、チーム自体とチーム内の両方で情報を交換するための最も実用的で効果的な方法です。

7.稼働中の製品は、進捗状況の重要な指標です。

8.投資家、開発者、ユーザーは、一定のリズムを無期限に維持できる必要があります。 アジャイルは、このような持続可能な開発プロセスの確立を支援します。

9.卓越した技術と設計品質への継続的な注意は、プロジェクトの柔軟性を高めます。

10.シンプルさ-不要な作業を最小限に抑える技術-が不可欠です。

11.最適な要件、アーキテクチャおよび技術ソリューションは、自己組織化チームから生まれます。

12.チームは、効率を改善するために考えられる方法を体系的に分析し、それに応じて作業スタイルを調整する必要があります。



同じ2001年に、IBMはRational Unified Process（RUP）と呼ばれる開発方法論を開発しました。これは、ソフトウェア開発への商業的に証明されたアプローチの使用方法を説明しています。 RUPは、チームメンバーが次のプラクティスを最大限に活用するために必要なガイドライン、テンプレート、および指示をチームメンバーに提供します。

• ソフトウェアを繰り返し設計します。
• 要件を管理します。
• コンポーネントアーキテクチャを使用します。
• プログラムモデルを視覚化します。
• プログラムの品質を確認してください。
• プログラムの変更を監視します。

図 2. RUPワークフロー



RUPの中核は、次のワークフローです。これらの共通部分を図2に示します。そのうち、6つのエンジニアリングプロセスと3つの補助プロセスがあります。

• ビジネスモデリング;
• 必要条件
• 分析と設計（分析と設計）;
• 実装
• テスト（テスト）;
• 展開
• プロジェクト管理
• 設定と変更;
• 運営管理
• 環境

ソフトウェア開発方法論の分野における最新の革新には、2006年に出版された37signals本「Getting Real」[14]があります。これは、仕様のコンパイルや人員配置などの官僚的コストを最小限にすることを完全に目的とする同名の方法論を説明しています。 この開発アプローチでは、インターフェイス設計から開発を開始し、インターフェイス自体に進み、最後にプログラミングに進むことをお勧めします。 したがって、可能な限り早く製品の最小バージョンをリリースして開発することを意味します。これはWebプロジェクトに最適です。



Get Realは、主に中小企業やチームで使用するために提供されています。さまざまな組織上の義務は、生存に必要な条件ではなく、チームに負担をかけるだけです。 一般に、この方法論は、極端なプログラミングおよび柔軟な方法論のマニフェストで説明されている原則のほとんどを満たすか、貢献しています。 さらに、方法論は次のような知識の領域をカバーします。

• 優先管理;
• 通信管理;
• 人事管理;
• 価格管理
• プロモーション
• サポート。

おわりに

情報プロジェクトの管理に使用される主な方法論が考慮され、それらのいくつかに固有のプロジェクトのライフサイクルの段階、基本的な原則と固有の優先順位、および以前の方法論との強みと主な違いが確立されます。



情報プロジェクト管理方法論の開発の分野では、最も早いものが研究されましたが、PERTなどが提示されましたが、PERTは普遍的なプロジェクト管理方法論であり、時間が重要な指標であり、1968年冬季オリンピックの開催にも使用されました。 Winston W. Royceによって提示されたプロジェクトライフサイクルの反復モデルが考慮され、RAD、MSF、DSDM、スクラム、ASD、Extreme Programming、RUPなどのプロジェクトで一般的な方法論が説明されています。 アジャイルアジャイル開発マニフェストの原則と最新の37signals Getting Real開発方法論の機能の概要が示されています。



方法論の開発を通じて、時間機能から時間リソースへの優先順位の変化を観察できます。 さらに、方法論の最新バージョンは、機能要件の絶え間ない変更を意味します。 方法論とプロセスの最大の形式化は、90年代前半の終わりまでに観察され、その後、ライトバージョンが人気を集め始めました。

参照資料

1. Fazar W.、プログラム評価とレビュー手法// The American Statistician、Vol。 13（No. 2）、1959、S。10。

2. 1968年、グルノーブルでの冬季オリンピックの結果に関する国際オリンピック委員会の公式報告書、S。49

3. Taylor FW、The Principles of Scientific Management、米国ニューヨーク州ニューヨーク、英国英国ロンドン：Harper＆Brothers-LCCN 11010339、OCLC 233134

4. Royce WW、大規模ソフトウェアシステムの開発の管理// Proceedingsから転載、IEEE WESCON、1970年8月、1-9ページ。 Copyright©1970 by Institute of Electrical and Electronics Engineers、Inc. もともとTRWによって公開されました。

5. Microsoft Solutions Framework（MSF）の概要[インターネットリソース] / Microsoft Developer Network-アクセスモード： msdn.microsoft.com/en-us/library/jj161047.aspx （アクセス：2014年11月3日）。

6. DSDMアターンハンドブック[インターネットリソース] / DSDMコンソーシアム-アクセスモード： www.dsdm.org/dig-deeper/book/dsdm-atern-handbook （アクセス：2014年11月3日）。

7. Shopyrin DG、ソフトウェア開発のプロジェクト管理：「柔軟なソフトウェア開発技術」分野のトレーニングマニュアル、サンクトペテルブルク：サンクトペテルブルク州立大学ITMO、2007年-131ページ。

8. Sutherland JV、ビジネスオブジェクトの設計と実装/ Sutherland JV Schwaber K. // OOPSLA '95 Workshop Proceedings、ミシガン大学、1995年-118ページ

9. Takeuchi H.、新製品開発ゲーム[インターネットソース] / Takeuchi H.、Nonaka I. // Harvard Business Review、1986-アクセスモード： hbr.org/1986/01/the-new-new-product- development-game / ar / 1 （アクセス：11/03/2014）。

10.スクラムの包括的なガイド：ゲームルール[インターネットソース] / Scrum.org-アクセスモード： www.scrum.org/scrum-guide （アクセス： 03/03/2014 ）。

11. Highsmith JM、エキサイティング、そして不安に満ちた：アダプティブソフトウェア開発//アメリカのプログラマー、ボリュームX（No. 1）、1997-電子リソース：www.adaptivesd.com/articles/messy.htm（アクセス：03.11.2014 ）

12. Beck K.、エクストリームプログラミングの説明：変更を受け入れます。 米国：Addison-Wesley Professional、2005年-224 c。 -ISBN-10：0201616416

13.アジャイルマニフェストの基本原則[インターネットソース] / Beck K.、Beedle M.、Arie van Bennekum、Cockburn A.、Cunningham W.、Fowler M.、Grenning J.、Highsmith J.、Hunt A.、Jeffries R 。、Kern J.、Marick B.、C。Martin RC、Mellor S.、Schwaber K.、Sutherland J.、Thomas D.-アクセスモード： agilemanifesto.org/iso/en/principles.html （アクセス：03.11 .2014）。

14. Realの取得[インターネットソース] / 37signals、2014-アクセスモード： gettingreal.37signals.com （アクセス：2014年3月11日）。