プロジェクト管理について詳しく解説

プロジェクト管理またはプロジェクト管理は、十分に複雑なプロジェクトの円滑な実行を構築、確保、最適化することを目的としたアプローチです。

時間をかけて計画する: これが計画の目的です
予算が立てられること（コストと便益または見返りに期待される収入の事前調査、資金源、運営上および財務上のリスクとさまざまな影響の調査など）
多数の利害関係者が関与する: これが、プロジェクト管理とプロジェクト管理を識別する組織の目的です (プロジェクト管理機能も参照)
プロジェクトマネージャーまたはプロジェクトディレクターに権限を与え、運営委員会を設置する
重要な運営上および財務上の問題を監視する

目的は明確に指定され、定量化され、日付が付けられている必要があります。結果は、最小限のコストと最短時間で、事前に定義された品質および性能基準に準拠する必要があります。

プロジェクト管理が同じ目的に貢献する一連のプロジェクトに関する場合、プログラム管理について話します。

プロジェクトとは何ですか?

決められた期限内に定義されたニーズに応えるために実行される一連のアクションをプロジェクトと呼びます。プロジェクトは、始まりと終わりのある一時的な活動であり、その実施中に特定のリソース (人的、物的、財政的) を動員します。これにはコストがかかるため、会社の予算とは独立した手段の予算編成と評価の対象となります。。

プロジェクトで期待される成果のことを「成果物」といいます。

プロジェクトは、十分に複雑で重大な利害関係があるとすぐに、定義された既知の測定可能な結果を目的とした一連のアクションで構成されます。このプロジェクトには時間が限られており、常に斬新さと変化の概念が含まれています。

私たちは以下を区別します。

結果がユニークな「仕事プロジェクト」（ブリッジ、ソフトウェア）、
および「製品プロジェクト」（新しい自動車モデル、新しい飲み物）。その目的は、多かれ少なかれ大規模に配布される、1 つまたは一連の製品またはサービスの開発です。

プロジェクトは、複雑な内部合理化操作で構成されることもあります。たとえば、合併後の 2 つの企業の機能の段階的移行や、ドイツ統一後の 2 つの国家の機能の段階的移行などです。

このプロジェクトは、次の 4 つの側面を組み合わせた「並外れた」目的 (言葉の文字通りの意味で) です。

機能的（ニーズへの対応）
技術的（仕様への準拠）
締め切り（締め切りを守る）
コスト（予算の遵守）。

プロジェクトは、プログラムと呼ばれることが多い、より複雑な全体の一部であることもあります。このプログラムは、法律、マーケティング、 IT 、技術、スタッフトレーニング、組織、物流、コミュニケーションなど、あらゆる側面で最終結果を達成できるようにするすべてのコンポーネントをカバーします。プロジェクト管理は、この分野を管理する主なルールを定義する PMBOK (プロジェクト管理知識体系) によって定義されます。

プロジェクトを分解する

プロジェクトは、複雑さを管理しやすいサブアセンブリを取得するために、バッチやサブプロジェクト、さらには建設現場に分割することができます。

プロジェクトを管理可能なサブユニットに分割することは、プロジェクトの管理、ひいてはプロジェクトの正常な完了と成功に不可欠です。
プロジェクトを細分化すると計画も立てやすくなります。

ステーキング

マイルストーンアプローチは管理行為であり、これによりプロジェクトを時間の経過とともに適切に構成できるようになり、プロジェクトマネージャーに多くの保証が提供されます。進行状況はカレンダーによってより適切に監視されます。マイルストーンを使用すると、プロジェクトを評価し、すべてが順調に進んでいる場合にのみ次のフェーズに進むことができます。そして、このフェーズ変更レビュー中に行われた決定は、プロジェクトの残りの部分を構築できる安定した要素となります。ステーキングでは、各フェーズの内容よりも結果の評価に関心があり、クライアント(またはプロジェクト所有者) が決定を下す必要があります。

準備段階: 将来がどうなるかに応じて、戦略的機会の観点からプロジェクト自体の利益を熟考します…
プロジェクト立ち上げのマイルストーン: 特定のプロジェクトを立ち上げる理由があると (「政治」レベルで) 判断し、プロジェクトマネージャー、チーム、リソース、マネージャー、予算をそのプロジェクトに専任します。
ニーズ表現フェーズ: 期待する内容 (期待される機能)、範囲、プロジェクトを評価する対象、何が重要で何が重要ではないかの定義。
ニーズ検証マイルストーン: 「クライアント」はニーズの表現を検証します (これにより、ニーズへのアプローチの変更を追跡でき、プロジェクト計画の可能な調整を正当化できます)。これらはプロジェクトが構築される基礎となります。
実現可能性フェーズ: 技術的および経済的に何が実現可能かを検討します。プロジェクトマネージャー候補者との協議、開発者候補者の技術的および財務的提案の比較。
ソリューション選択マイルストーン: 何をどのように行うかを指定する契約の署名。
開発フェーズ: プロジェクトマネージャーは、「紙製品」に関する作業を調整し、最後のボルトに至るまで何を行う必要があるかを指定します。
マイルストーン(可能性) サイトの立ち上げ: 「紙製品」が十分に定義されたら、建設作業を開始する前に在庫を確認できます。
制作段階：サイトを立ち上げ、「紙製品」を「現実」に移す作業が進んでいます。
検証フェーズ(「紙製品」では非常に早い段階で開始できます): 実際の製品または紙製品上で、期待される特性が存在するかどうかを確認 (または計算) します (偏差の可能性はあります)。管理されます）。
認定マイルストーン: 検証後、製品参照定義は「正しいもの」であり、(少なくとも、それほど簡単には) 変更されなくなります。
納品マイルストーン(およびレシピ): 製品は顧客の手に渡され、顧客はその所有者になります (観察された矛盾については留保を表明できます)。これでプロジェクト自体は終了です。
運用段階。ほとんどの場合、予約の解除から始まり、契約関係が終了します。

追加の注意事項: (1) 名前は文化によって大きく異なる場合があります。 (2) フェーズとマイルストーンは時々絡み合っており、そのたびに、次のフェーズの作業を準備したり、前のフェーズで完了しなかったものを完了したり、不十分であると思われたものを修正したりする必要があります。 (3) もちろん、吊り橋の設置、オペラ、サプライズパーティーなどに応じて適応はあります…たとえば、「ツアーオペレーター」の場合、それはサービスの提供であり、そのサービスの提供は顧客です。製品が生産されるときにそれを消費します。

相分割

品質、コスト、納期の要件を尊重しながらプロジェクトを完了させるために一般的に使用される方法 ( 「開発サイクル」と「V 字型サイクル」の記事を参照) は、プロジェクトをフェーズに分割することです。各フェーズには、次のフェーズに進む前に完了したフェーズを正式に検証することを目的としたステージの終了が伴います。
通常、次のフェーズがあります (ただし、名前はコンテキストやメソッドによって異なります)。

予備調査（または実現可能性または機会とも呼ばれる予備調査）

この段階の目標は、プロジェクトの範囲とその実現可能性を決定すること、つまり、プロジェクトの目標に何が含まれるか、何が含まれないか、そしてプロジェクトを開始すべきかどうかを定義することです。一方では、期待される利益が行われた投資とプロジェクトの予測コストに比例するかどうかを推定します。このようにして、多くのプロジェクトについて、期待される投資収益率 (より正確には回収) を決定します (ただし、すべてのプロジェクトが必ずしも金銭的利益の達成を目的としているわけではないことに注意してください。サービスの向上を目的としてプロジェクトを立ち上げることもできます)。行政の利用者を対象としたり、企業の社会環境を改善したりするため – このような場合、投資収益率は必ずしも定量的ではありません)。
一方、実現可能性調査は、組織がプロジェクトを完了できるかどうかも決定します。特に、必要なスキル、リソース、資金があるかどうかを知りたいと考えています。
私たちは以下を分析します:

実行のリスク: プロジェクトの進行中に予想される困難とそれを防ぐ手段は何か、
およびそれを行わない場合のリスク: プロジェクトが開始されずに完了しなかった場合、会社または組織にとって何が問題になりますか。

この最初のフェーズが決定的なものになった場合にのみ、プロジェクトが実際に開始されます。

起動または初期化

この立ち上げフェーズは、以下を定義する機会です。

プロジェクトの組織、つまり:
- 動員されるプロジェクトチームの構成。
- さまざまな専門家に依頼し、必要に応じて下請け業者を利用する。
- プロジェクトマネージャーまたはプロジェクトディレクターが任命され、ミッションレターが書かれます。
- 運営委員会が設立される。
スケジュール、期間、リソースの割り当て、必要な技術的手段、さまざまなマイルストーン（ガントチャート、PERT）とともに実行されるタスクの計画。
準備される可能性のある技術的環境。
コミットされるプロジェクト予算。
結果を監視する方法。

一般検討と詳細検討（または仕様書）

このフェーズの目的は、目的を達成するために何を実行または製造する必要があるかを設計または指定することです (おそらく仕様の草案)。これらの研究は、プロジェクト管理とプロジェクト管理を組み合わせたものです。
これらの成果物が「機能的」で「ユーザー」によって表現される場合、私たちはニーズや一般的な仕様の表現について話すことがあります。その場合、仕様(または詳細な仕様) という用語は、より「技術的な」文書、または詳細を説明する文書に対して留保されます。予想されるソフトウェアの「内部」機能をさらに詳しく説明します。

プロジェクトマネージャーのための解決策の調査と決定

このフェーズは、スキル、設備、期限、財務面およびマーケティング面の制約に従って、さまざまなソリューションまたは技術的および機能的なアーキテクチャを検討することで構成されます。次に、モデルまたはプロトタイプを作成し、場合によってはそれらをテスト市場に投入することによって、選択内容を検証する必要があります。測定された偏差により、選択を修正することが可能になります。
IT プロジェクトでは、このフェーズでは都市化と建築上の懸念が考慮されます。
市場にある既存のソリューションを選択する場合 (特にソフトウェアパッケージの場合)、このフェーズは入札募集を中心に構成されます。

生産と管理または製造

プロジェクトが実行または製造されるのはこの段階です。つまり、新しい製品、商品、またはサービスの実装を可能にするタスクが実行されます。
IT プロジェクトでは、このフェーズでソフトウェアの構築が可能になります。
これらのタスクの進捗状況と期限の順守を監視するために、私たちはプロジェクト管理ツール、特に遅延や期限を過ぎた場合にプロジェクトの残りの部分を再度計画できるソフトウェアを使用します。
このフェーズでは、単体テスト、統合テスト、パフォーマンステストのテストも実行されます。

レシピ

成果物が利用可能になるか受け取られたら、すぐに検査を実行して、製造結果が仕様書の作成中に発注された注文と適合しているかどうかを確認する必要があります。管理は、作成されたテストブックに基づいて厳格なテストの形式で実行されます。

受け入れフェーズの最後に、最終的な受け入れ報告書に署名します。

プロジェクトの複雑さに応じて、グローバルな検証シーケンスが必要になる場合があります。 CAP によって実装された「PERFORM」メソッドを参照してください。必要なツールがそこにあります。

下請けが使用されている場合、レシピの終了は重要な段階を示します。これは、申請者がサービスプロバイダーに対して措置を講じることができる法的保証期間が開始されるためです。

ブロードキャストまたは展開

製品は市場またはユーザーに提供され、ここでコミュニケーションポリシーが実行され、より一般的には変更のサポートと呼ばれます。

パフォーマンスと品質のモニタリング

モニタリングツールは、プロジェクトの準備中に、パフォーマンスと品質の目標を定義すると同時に確立されました。

タスクの内訳

プロジェクトを基本サブアセンブリに分割するもう 1 つの (補足的な) 方法は、プロジェクトを、タスクという単純な機能を備えたアクティビティのサブセットに分割することで構成されます。
各タスクは、そのタスクに必要な原材料によって特徴付けられます。これらは、受信または予備オブジェクト (文書、仕様、利用可能な機械、標準、訓練を受けて運用可能なオペレータ、テストセットなど) です。 1 つ以上の結果製品を提供します。これらは出力または成果物 (ソフトウェア、広告パンフレット、トレーニングコースサポート、技術シートなど) です。受信オブジェクトはすでに利用可能である場合もあれば、それらを生成することを目的とした別のタスクの送信オブジェクトである場合もあります。送信オブジェクトは別のタスクで再利用できます。
この方法 (たとえば、関係するさまざまな関係者へのインタビューによって実行される) により、準備タスクを強調し、タスク間の依存関係を具体化することができます (たとえば、PERT ネットワークを形式化する)。

WBS活動の内訳

WBS (Work Breakdown Structure) メソッドとして知られる 3 番目のアプローチは、特定された入力と結果、および担当者に委ねられた責任を伴うアクティビティ(ここではタスクに近い概念です) への静的(分析的) 分割を実行します。指定された人物、以下に必要な最適な分解レベルまで:

アクティビティの継続時間をコントロールする
必要なリソースを知る
活動にかかるコストを知る。

プロジェクト管理

プロジェクト管理は原則としてプロジェクトディレクターやプロジェクトコーディネーター、場合によってはプロジェクトマネージャーに委託されます。このプロジェクトマネージャーは運営委員会に報告します。

プロジェクトチームの管理における心理社会的側面に関して、Maders ^{[ 1 ]}は 5 つの連続する段階を区別しています。

観察段階はプロジェクトチームのメンバーと会うことに相当します。
結束段階では、団結したチームを形成できるようにする必要があります。
差別化ステージでは、チームメンバー間の違いを活用できます。
組織段階では、従来のプロジェクト管理手法を使用して、リソース管理、計画、リスクの管理を形式化します。
制作段階では、プロジェクトチームの実際の機能について説明します。マネジメントとリーダーシップに関するさまざまな理論が最も関連するのはこのレベルです。

デザインパターンアプローチ

プロジェクト管理は、プロジェクトマネージャーが可能な限り即興で行う必要がある難しい技術です。また、リスクを軽減したり、プロジェクトのエントロピーを適切なレベルに維持したりするには、経験から主要な原則が浮き彫りになります。 Alan Davis は、ソフトウェアプロジェクトに適用される 201 の原則^{[ 2 ]}を列挙しました。

さらに、James O. Coplien は、実践を中心としたプロジェクト管理現象の一側面を提供しています^{[ 3 ]} 。プラクティスとは、ソフトウェア開発で使用される設計パターンに相当する原則の正式な実装です。この意味で、エクストリームプログラミング手法では、次のような実践も提供されます。

ペアプログラミング
まずテストしてください

他の10人も同様です。

これらのプラクティスは、選択した組織部門に関するガイドを提供します。 ^{[ 3 ]}によると、ソフトウェアのデザインパターンを相互にリンクできるのと同じように、組織のデザインパターンはグラフの形式、したがって組織言語の形式でまとめられます。これらのパターンは、ミュージシャンのスケールに相当する、プロジェクトマネージャーが利用できるトークンに対応します。この言語を使用すると、プロジェクトチームに統合できる組織 (理由) を選択できます。

この限られた選択肢は、企業文化と同様の現象によって説明できます。ビジネスにおいて、変化を管理するのは最も難しいことです。会社にはそれが必要ですが、個人はそれを拒否します。この拒絶は快楽原則 (エネルギー節約原則) によって説明されますが、このチームを構成する人々にとって最も快適な範囲は、移行をできるだけ単純にすることで構成されることがわかります。

したがって、「シングルトン」設計パターンから「ファクトリー」設計パターンに移行するのに数行のコードが必要なように、「ペアプログラミング」実践から移行する場合、「コードの集団所有権」実践を達成するのにほとんど労力を必要としません（コードはみんな）。