ナレッジ紹介

PMOは「参謀役」「進捗管理役」「事務役」の役割を遂行するために求められる能力は下記のとおりです。
・プロジェクトの計画、実行、監視、コントロール、クローズを行う能力
・個別の作業だけに着目することなく、プロジェクト成功に向けた全体最適な大局的視点を保持する能力
・問題が発生した場合に迅速かつ効果的に解決する能力
・リスクを特定評価し、対応策を策定する能力
・プロジェクトチームをリードし、モチベーションを維持する能力
・ステークホルダーと良好な関係を維持でき、コミュニケーションが取れる能力

なお、PMOとして常に心掛けておくべきことをフィン パートナーズでは【PMO 10則】として設けています。

プロジェクトアプローチは業界特性に応じて選択することになりますが、現在は下記の3つが主流となっています。
・ウォーターフォール型：上流工程から下流工程へと開発プロセスを計画的に進める方式
・アジャイル型：柔軟で迅速な変更に対応できるよう予め厳密な仕様を決定せずに、小さな開発を反復していく方式
・ハイブリッド型：ウォーターフォール型とアジャイル型の双方を取り入れた方式

建設プロジェクトであれば計画重視のウォーターフォール型が採用されやすく、アプリケーション開発であれば短い開発サイクルでリリースし、リリース後も頻繁にアップデートする特性に合わせてアジャイル型を採用するのが一般的です。

プロジェクトの種類によって流れも変わりますが、大まかな流れは下記の通りです。

1. 立ち上げフェーズ、2. 計画フェーズ、3. 実行フェーズ

上記を踏まえ、システム導入プロジェクトであれば下記のように詳細に区切ることが多いです。

1. 企画フェーズ、2. 要件定義フェーズ、3. 設計フェーズ、4. 開発テストフェーズ、5. 移行・稼働準備フェーズ、6. 運用定着・保守フェーズ

プロジェクト立ち上げフェーズは、プロジェクト成功に向けた初期の道筋を下記の流れで描いていきます。
STEP1. 将来のありたい姿を描く
STEP2. 将来のありたい姿を踏まえ、プロジェクトの目標と目的を設定する
STEP3. ステークホルダーの期待と要求事項を明らかにする
STEP4. プロジェクト成功の定義を明確にしたうえで、スコープと制約条件を明確にする
STEP5. プロジェクトの全社的な成果とステークホルダー別の成果を整理するとともに、成果の評価尺度を明確にする
STEP6. 進行するうえで想定されるプロジェクトリスクとビジネスリスクを明らかにする
STEP7. プロジェクト推進上のルールを作成する
STEP8. 以上をもとにプロジェクト憲章を作成のうえ、ステークホルダーと合意形成し、プロジェクトの適正性を確保する
STEP9. ステークホルダーの今後の関与度合い・関与頻度を設計する
STEP10. プロジェクトチームを組成、役割と責任を明確にしたうえで、プロジェクトをスタートさせる

それぞれのSTEPでの具体的な実施事項、成功要因についてはフィン パートナーズまでお気軽にお問い合わせください。

プロジェクト計画フェーズでは、プロジェクト3大要素であるスコープ・スケジュール・コストの設定が最重要事項となります。そのうえで、プロジェクトマネジメントをするうえで必要となる進捗管理方法など各種枠組みを整理していきます。
PMOの具体的な実施事項は下記のとおりです。
STEP1. まずプロジェクトやプロダクトのスコープを可視化のうえ、決定する
STEP2. （ウォーターフォール型の場合）スコープを踏まえて、プロジェクト全体のタスクをWBSを活用して可視化する
（アジャイル型の場合）顧客やユーザなどからプロダクトに必要な機能を収集し、要求事項概要と優先順位を整理する
STEP3. 重要な進捗指標であるマイルストーンを設定する
STEP4. タスクごとに期限を設定のうえ、作業スケジュールを決める
STEP5. タスクごとにチームメンバの役割を決める
STEP6. タスクごとの作成物と成果物を特定、管理方法を決定する
STEP7. 定期的な進捗報告会を設計する
STEP8. タスクを踏まえて、プロジェクト予算を見積もる
STEP9. プロジェクトマネジメント計画書を整備する
STEP10. プロジェクトマネジメント計画書を踏まえて、進捗管理表、課題管理表、リスク管理表など、必要となる管理表を作成する

それぞれのSTEPでの具体的な実施事項、成功要因についてはフィン パートナーズまでお気軽にお問い合わせください。

アジャイル型プロジェクトの場合は、完成形の姿や期日が明確に決まらないことがあるため、仕様変更などへの柔軟性が求められます。
そのため、アジャイル型のプロジェクトは下記手順に従って計画することが一般的です。
STEP1. プロダクトの各リリース期間を開発サイクル（イテレーション）に分割します
STEP2. 開発サイクルごとにユーザストーリーを計画します
STEP3. ユーザーストーリーの優先順位付けを行い、それぞれのストーリーを実現するためのタスクに分解します
STEP4. タスクごとの労力を踏まえて、開発サイクルごとの進行速度（ベロシティ）を可視化します。この開発サイクルごとの進行速度が所定期間内に完了できているか確認し、必要に応じて微調整します
STEP5. 一つの開発サイクルのタスクやスケジュールを計画した後は、次の開発サイクルの計画に移ります

通常、プロジェクト全体のマネジメント計画書は下記要素で構成されます。
・スコープ管理
・スケジュール管理
・予算コスト管理
・要員管理
・調達管理
・契約管理
・課題リスク管理
・文書管理
・ステークホルダーエンゲージメント管理
・品質管理
・変更管理
・障害管理

それぞれの具体的な記載・遵守事項、成功要因についてはフィン パートナーズまでお気軽にお問い合わせください。

まずプロジェクト予算の元となる所要期間を見積もります。ウォーターフォール型の所要期間を見積もる主な技法は下記のとおりです。
・類推見積もり：過去のプロジェクトや類似のアクティビティのデータを転用する方法
・係数見積もり：過去のプロジェクトや類似のアクティビティのデータおよびスコープ・スケジュール・メンバー数などの係数をもとに数学的モデルで試算する方法
・三点見積もり：楽観値・悲観値・最頻値の3つのパターンで主要なアクティビティの所要期間を試算することで全体を予測する方法
・ボトムアップ見積もり：アクティビティごとにコストや所要期間を個別に見積もり、積み上げることで全体を予測する方法

所要期間見積もり後は、各タスクに想定メンバーを割り当て、そのメンバーのランク単価を所要期間に乗じることでプロジェクトの総コストを計算します。

プロジェクト予算は当初計画通りに消化されるのが理想ではありますが、要求事項の変更、メンバの異動、調達資源の変動といった個別事情により変更を余儀なくされる場合も多く、一筋縄ではいきません。
そのため、プロジェクト期間に特定リスクが顕在化する場合に備えて、予備対応コストとしてコンティンジェンシーを織り込むことが望ましい場合もあります。
織り込むにあたっては、プロジェクトのリスクを定量化のうえ、妥当な予備を推定する予備コスト設定分析を行うことで合理的な説明の基礎となり得ます。

アジャイル型のプロジェクトの作業工数を見積もる場合は、時間単位ではなく、相対的な指標や尺度を使って見積もる技法を用いることが一般的で、主な技法は下記のとおりです。
・サイズ分類：ユーザストーリーやタスクの相対的なサイズ分類を行い（High, Middle, Low、またはXL, L, M, S, XSなど）、サイズ別の想定工数を割り当てる方式
・ストーリーポイント：ユーザストーリーやタスクを抽象的なポイント数で評価し、ポイント合計数に応じて難易度分けをする方式
・チームプランニング：チームメンバーが共同でタスクを見積もり、意見交換しながら合意形成する方式

プロジェクトの計画段階でリスクを正確に把握することで、実行フェーズ以降の管理基盤とします。
プロジェクトリスクは多岐に渡りますが、下記の3点は特に留意が必要であり、プロジェクトマネジャーの責任において事前にリスク対策を施して最小限に抑えるようにします。
・作業範囲の拡大や変更
・スケジュールの遅延
・予算の超過

その他、実務上で想定されるリスクには下記のようなものがあります。
これらは計画時に早期識別のうえ、事前に対策してプロジェクトの安定性を担保することが求められます。
・スキル不足や新技術の採用から来る技術的リスク
・ステークホルダーとのコミュニケーション不足から来るリスク
・市場変動や競争激化に伴うリスク
・契約条件や法的拘束に伴うリスク
・天候条件に伴うリスク
・政治の不安定性に伴うリスク

プロジェクトの実行フェーズでは、まずキックオフ・ミーティングの開催とプロジェクト・ルールの共有を通じて、チームメンバの共通理解を築きます。
その後は、プロジェクト進捗会議に出席するほか、進捗状況や予算実績分析に役立つEVM（Earned Value Management：アーンド・バリュー・マネジメント）やコミュニケーション・ツールを活用して、プロジェクト状況を確認します。確認の結果、スケジュール遅延や予算超過している場合には、エスカレーションや是正措置を図ります。
これらに加えて、プロジェクトのクロージングまで、ステークホルダーとのコミュニケーション、成果物の品質管理、チームメンバの状態維持、コンフリクトの解決を図っていきます。

プロジェクトを成功させるためには、プロジェクトマネジャーがチームをベストな状態に保ち、最高の成果を引き出すことが求められます。
プロジェクトチームを上手にマネジメントするうえでは、下記のコツを踏まえることが有用です。

【リーダーシップ・スタイル】
・リーダーシップには、率先型・指示型・支援型・関係調整型・育成型などがありますが、プロジェクトの状況やメンバの性格によって、スタイルを柔軟に合わせていきます。
・例えばプロジェクト初期は、ゴールイメージの決定や成果への道筋整理が求められ相対的に負荷が高いため率先型で推進します。プロジェクト中盤は、支援型や関係調整型に移行する場合が多い印象です。ただし、計画との乖離が生じた場合には再度率先型に移行するということもあり得ます。

【エンゲージメント】
・プロジェクトのビジョンや意義、プロジェクト成功後の絵姿の提示など、チームメンバ１人ひとりに腹落ちさせ、意義あるプロジェクトに関わっている意識を強化することで、エンゲージメントを高めます。

【メンバの動機付け】
・昇進昇給への影響、インセンティブの設定など、メンバのモチベーション向上や維持を促します。
・プロジェクトルームや仕事効率化に繋がるツール類の整備のほか、人間関係を踏まえたレポートラインの整理など、ハード・ソフト面で働きやすい環境作りを目指します。

【成果物の品質管理】
・何を、いつ、誰が、どのように作成・管理するのかを明確にします。そのうえで、メンバが常に最新の成果物全体にアクセスできるようにすることで情報のボーダーレス化を図ります。
・プロジェクトマネジャーまたはリーダーなど、適切な役割を担う人が、適切なタイミングで成果物レビューを行い、担当者にフィードバック・改善を図ります。レビュー不足に伴う、成果物の品質低下に伴う手戻りや信頼低下を回避することが重要です。

【権限の付与】
・チームメンバに適切な意思決定権限を与えることで自律性と責任感を持たせます。

【パフォーマンス評価】
・KPI（重要業績指標）の状況や成果物の品質などで、パフォーマンスを評価し、適切なフィードバックを行います。
・チームメンバの成長を支援のうえ、パフォーマンスの発揮レベルの段階的な引き上げを促していきます。

【コンフリクト・マネジメント】
・プロジェクト推進の過程では様々な意見が飛び交うことから、価値観や意見、利害の相違によって、チーム内で対立や衝突が起きる場合があります。このようなコンフリクトの可能性を織り込み、意見の齟齬を調整していくことが求められます。
・具体的には、リーダーによるポジティブな誘導や意識変容の誘導、適時の意思決定や解決策の提示のほか、積極的な傾聴や共感など、人間関係スキルを用いて早期解決を図ります。

プロジェクトマネジメントに関して、ツール活用が有効な領域としては、例えば下記があります。
1.　タスク・スケジュール管理
2.　予算管理
3.　課題・リスク管理や変更管理
4.　成果物作成・管理
5.　会議調整・会議開催
6.　プロジェクトチーム内のコミュニケーション

ここでいうツールには、Excelなどのスプレッドシートを活用したものもあれば、SaaSのプロジェクト管理ツールなどを含みますが、システムソリューションを活用する際は下記を踏まえて採用要否を判断します。
・プロジェクト規模：関与人数が多い場合には活用可能性が高まる
・プロジェクト期間：期間が長い場合には活用可能性が高まる
・品質維持：メンバの手段を統一して品質を高めたい場合には活用可能性が高まる
・セキュリティ：情報を分散せずにセキュリティを強化したい場合には活用可能性が高まる
・ソリューションの運用コスト：運用コスト負担が高い場合に、効率化が図れる場合には活用可能性が高まる
・ソリューション解約後の制約：プロジェクト終了後に他のプロジェクトや定常業務でソリューションを活用する場合には活用可能性が高まる（解約した際に修正加工ができないなど利用制限される場合は注意）

ADKARモデルとは、チェンジマネジメントの認定資格プログラムを提供する米国Prosci社のジェフリー・ハイアットが開発した組織変革モデルです。
組織変革を成功させるためのプロセスを5つのステップで表現しています。
STEP1. 認知（A：Awareness）：変革が必要な理由を説明することで、必要性を認識してもらう
STEP2. 欲求（D：Desire）：自ら変革したいと、変革に対する意欲を持ってもらう
STEP3. 知識（K：Knowledge）：変革に必要な知識を習得してもらう
STEP4. 能力（A：Ability）：知識を活用して実際に行動してもらう
STEP5. 定着（R：Reinforcement）：変革の成果を認識してもらい、長期的に維持・強化してもらう

このモデルを通じて、組織のメンバーは自らの意思で変革を受け入れ、前進させることができます。

CoE（センター・オブ・エクセレンス）とは、重要なビジネス領域や特定の専門分野において、知識・技術・ベストプラクティスを集約することで、組織全体の能力を向上させるための部署またはグループをいいます。
CoEのメンバーは、プロジェクトチームの相談役としての役割を担いますが、プロジェクトの意思決定には関与しません。

Doneドリフトとは、アジャイルアプローチを採用している場合に、プロジェクトが進行するにつれて完了の定義が変わってしまう事象をいいます。
たとえば、競合他社がリリースした新プロダクトの影響により、自社開発プロダクトに追加作業が生じて完了時期が延びる場合を指します。
この場合、プロジェクトチームの生産性に影響を与える場合があるので、適切なマネジメントが求められます。

EVM（アーンド・バリュー・マネジメント）とは、プロジェクトの進捗状況を測定し、スケジュールとコストのパフォーマンスを評価する技法をいいます。
ウォーターフォール型とアジャイル型、いずれのプロジェクトにも活用可能であり、多くのプロジェクトに活用されています。

まず、EVMは3つの変数を用いて、スケジュールとコストのパフォーマンスを評価・モニタリングします。
・PV（Planned Value：プランド・バリュー）：特定の時点までに完了予定である作業の予算上のコスト。
・EV（Earned Value：アーンド・バリュー）：特定の時点において完了した作業に割り当てられていた予算上のコスト。
・AC（Actual Cost：アクチュアル・コスト）：特定時点までに行った作業に実際に要した合計コスト。

上記3つの変数を用いた定量評価
・SV（Schedule Valiance：スケジュール差異）＝EV-PV
この値が正である場合はプロジェクトは予定よりも早く進行、負である場合は遅延していることを指す。
・SPI（Schedule Performance Index：スケジュール効率指数）＝EV÷PV
この値が1.0超である場合はプロジェクトは予定よりも早く進行、1.0未満である場合は遅延していることを指す。
・CV（Cost Valiance：コスト差異）＝EV-AC
この値が正である場合はプロジェクトは予算内、負である場合は予算超過していることを指す。
・CPI（Cost Performance Index：コスト効率指数）＝EV÷AC
この値が1.0超である場合はプロジェクトは予算内、1.0未満である場合は予算超過していることを指す。

そのほかの定量評価
・BAC（Budget At Completion：完成時総予算）：プロジェクト完了時までの総コスト。
・ETC（Estimate To Complete：残作業コスト見積もり）＝EAC-AC
残りの作業を完了するための見積もりコストの予測値。過去の実績が今後も同じように続くと仮定して試算。
・EAC（Estimate At Completion：完成時総コスト見積もり）＝AC+ETC
プロジェクトが完了するために必要な総コストの予測値。過去の実績が今後も同じように続くと仮定して試算。

EAC＜BACであれば予算内であり、EAC＞BACであれば予算超過していることを指す。

このように、EVMの変数と尺度のモニタリングを通じて、スケジュールとコストをコントロールしていくことが求められます。

Lessons Learned（レッスンズ・ラーンド）とは、プロジェクトを実施した中で得られた知識や気付きを教訓として記録しておき、次回に同様のプロジェクトで活用できるようにすることをいいます。
形式知と暗黙知のいずれも文書・図表などで可視化のうえ、共有資産とすることが有用です。

PgMOとは、プログラム・マネジメント・オフィス（Program Management Office）のことであり、複数プロジェクトの集合体であるプログラムの運営を支援する組織体をいいます。
複数のプロジェクトの統合管理やモニタリングのほか、プロジェクト間の状況・リソース調整などを担います。

PMBOK®︎ガイドとは、プロジェクトマネジメントの知識を体系化したものです。
アメリカに本部を置くPMI®︎（プロジェクトマネジメント協会）が策定・発行したもので、現在は2021年に発行された第7版が最新となっています。
PMBOK®︎ガイドには、プロジェクトマネジメントにおける「原理・原則（行動指針）」「パフォーマンス領域（注力すべき領域）」「テーラリング（プロジェクト特性毎の調整）」「モデル・方法論・作成物」がまとめられた概要書となっています。

PMI®︎は、Project Management Instituteの登録商標です。
PMBOK®︎は、PMIの登録商標です。

PMOとは、プロジェクト・マネジメント・オフィス（Project Management Office）のことであり、プロジェクトが目標・成果に向かって推進できているかを確認する組織体をいいます。

PMOは、プロジェクトマネジャーを支援することが求められ、下記のような役割を担います。
【事務役】
・会議準備、会議日程の調整、成果物管理、新人/離任メンバの管理 など
【推進管理役】
・プロジェクトタスクの進捗管理、報告レポート作成、課題解決サポート、会議でのファシリテーション など
【参謀役】
・プロジェクト計画策定、組織間調整、経営層向けレポート作成、人材育成 など
下にいくにつれて役割と責任が広がりますが、プロジェクトマネジャーからの期待役割を踏まえて適材適所な人員を配置することが求められます。

なお、プロジェクトに限らず、ポートフォリオ・マネジメント・オフィスやプロダクト・マネジメント・オフィスなどの意味を持つ場合もあります。

WBS（ワーク・ブレイクダウン・ストラクチャー）とは、プロジェクト目標・成果を達成するために、プロジェクトチームが実行する全ての作業を階層的に分割したものです。
プロジェクト全体のタスクを管理可能な個別のタスクに分割して可視化させることで、それぞれのタスクの内容や進め方を検討することができるようになるとともに、正確なコスト試算にも役立てることができます。
通常、WBSはタスクを集約したサマリー版と、タスクを最も細かくした詳細版に大別でき、ステークホルダー報告時やチーム内進捗確認時などそれぞれ場面で使い分けます。

アクティビティとは、プロジェクトのスケジュールに組み込まれた個々の作業をいい、その個々の作業を完了するために必要なコストをアクティビティ・コストといいます。

アジャイルとは、柔軟で迅速な変更に対応できるよう予め厳密な仕様を決定せずに、小さな開発を反復していく方式をいいます。

ヴァージニア・サティアの変化モデルとは、チェンジマネジメントのフレームワークの1つで、アメリカの心理学者ヴァージニア・サティアが提唱した、人々が変化をどのように捉え、どのように対処するかのプロセスを分析したもので、ビジネスにも応用されています。
第1段階 「初期の現状」：いつもどおりの状態で、パフォーマンスは大きく変動することなく安定しています
第2段階 「抵抗」：変化に対する初期の抵抗が起き、パフォーマンスが急激に低下します
第3段階 「混沌」：変化により安定感を失い不確実な状況に陥ることで、パフォーマンスが最低レベルとなります
第4段階 「変容に向けたアイデア」：パフォーマンスが最低レベルに達することで、新しい現実に対処するための方法が模索され、パフォーマンスの改善が始まります
第5段階 「統合」：新しい方法の試行錯誤を繰り返すことで新しい知識と習慣を習得していき、パフォーマンスが向上します
第6段階 「新しい現状」：新しい環境に適応することができ、パフォーマンスが安定します

このモデルにより、組織内に起きるパフォーマンスの変動が予測できるため、リーダーは変革により何がおきるか事前に見当がつくとともに、変革を正当化させることができます。
さらに、各段階でリーダーがどういった役割を担い、手を打つべきかの計画を立てることもできます。

ウォーターフォールとは、上流工程から下流工程へと開発プロセスを計画的に進める方式をいいます。

エスカレーションとは、責任を有する上位者に判断や指示を仰ぎ、対応を要請することをいいます。
あらかじめ、エスカレーションルール・プロセスを決めておくことが望ましく、問題の性質や影響範囲、解決の緊急度合いなどを考慮して決定します。

キックオフミーティングとは、プロジェクトの始めに開催されるチームメンバーと主要ステークホルダーとの会議体をいいます。
キックオフ会議では、下記を目的として開催します。
・プロジェクトの立ち上げ宣言
・背景と目的、目標の明確化
・スコープとスケジュール、会議体の共有
・チーム体制と役割責任の明確化、一体感の醸成

クリティカルパスとは、プロジェクトの進行に必要なアクティビティを繋げたときに最も時間のかかる経路のことをいいます。
言い換えると、この経路はプロジェクトの開始から終了までに要する最長の所要期間になります。
そのため、クリティカルパス上のアクティビティのスケジュール管理を徹底することで、プロジェクト全体の遅延を防ぎやすくなります。
なお、遅々となりがちなスラック・タスクや、見当がつかないフロート・タスクは、予め開始を早める又は期限を遅くするなどの時間的余裕を設けることで遅延リスクを回避することができます。
このようなスラック・タスクやフロート・タスクの所要期間を踏まえた経路がクリティカルパスとなる場合もありますので、計画時にはタスク全体の考慮が求められます。

コッターの8ステッププロセスとは、チェンジマネジメントのフレームワークの1つで、ハーバード大学名誉教授のジョン・P・コッターが提唱する、トップダウンによる組織変革のプロセスです。
リーダーが変革を導くためのプロセスを8つのステップで表現しています。
STEP1. 危機意識を高める：変革をしないとどうなるのか、変革の必要性を強調し「危機意識」を生み出す
STEP2. 変革推進チームを結成する：変革を主導するメンバーを特定し選出する
STEP3. 変革のビジョンを作成する：変革を導くためのビジョン、将来のあるべき姿を作成する
STEP4. ビジョンを周知する：ビジョンを組織全体に伝え、周知徹底する
STEP5. メンバーの自発を促す：変革を阻む障害を除去しながら、自発的に行動できるメンバーを増やしていく
STEP6. 短期的な成果を実現する：中長期的な成果だけを狙わず、実際に短期的な成果を生み出し、組織内に認知させる
STEP7. 成果を活用する：短期的な成果をもとに変革に勢いをつけて、次の目標を目指す
STEP8. 企業文化に定着させる：変革の成果を企業の成功に紐づけて、変革を組織に根付かせる

この8つのステップは、STEP1から順を追って進めることが重要で、途中のプロセスを飛ばしてはいけないことが強調されています。

コンティンジェンシーとは、プロジェクト期間中に特定リスクが顕在化するなど、プロジェクト実行に影響を及ぼす出来事をいいます。
この出来事に備えて、予算に織り込む予備コストをコンティンジェンシー予備といいます。

コンフリクトとは、個人やグループ間の意見や価値観、利害の相違によって生じる緊張や対立の状態をいいます。

スクラムとは、短期間で作業と検証を繰り返し行うことでアウトプットを生み出すアジャイル開発の一種のフレームワークをいい、主にソフトウェア開発で使われています。

スクラムにより、プロダクトのゴールを目指している専門家チームをスクラム・チームといい、そのチームの中で進行や調整の役割を担っている担当者をスクラム・マスターといいます。

ステークホルダーとは、プロジェクトまたはプログラム、ポートフォリオの影響を受ける個人またはグループ、組織などの利害関係者をいいます。

ステークホルダー分析とは、ステークホルダーとの接し方を分析する手法をいい、たとえば発言力（高or低）と関心度（高or低）の4象限マトリックスを使って、ステークホルダーとのコミュニケーション粒度を分類する方法があります。
・発言力高×関心度高：確実な対応
・発言力高×関心度低：満足度の維持
・発言力低×関心度高：定期的な報告
・発言力低×関心度低：モニタリング

タイム・アンド・マテリアル契約とは、実際に要した時間と単価を元に報酬を支払う契約形態をいいます。
プロジェクト範囲やタスクが流動的で、予め全ての要件を特定することが難しい場合に適している契約です。

チェンジマネジメントとは、プロジェクトによる変革の成果を継続的に創出するための手法をいいます。
ステークホルダーに変革の理解と定着を図るために、プロジェクトの進行と同時並行で推進することが効果的であり、継続的なメッセージ発信のほか、ニーズの事前充足や予想される抵抗への対処、トレーニング開発、コーチングなどを推進していきます。
「ADKARモデル」や「コッターの8ステッププロセス」、「ヴァージニア・サティアの変化モデル」などのフレームワークを用いることがあります。

バーンアップ・チャートとは、プロジェクトの進捗状況を、作業量と経過時間の2軸を使った折れ線グラフで表したものをいいます。
完了済みの作業量を可視化する場合に使い、右上がりの折れ線グラフとなります。

バーンダウン・チャートとは、プロジェクトの進捗状況を、作業量と経過時間の2軸を使った折れ線グラフで表したものをいいます。
未完了の作業量を可視化する場合に使い、右下がりの折れ線グラフとなります。

パフォーマンス測定とは、プロジェクトのパフォーマンスを定量・定性の両面から測定することをいい、下記の視点で評価します。
・スコープ：作業の完了割合を測定する
・スケジュール：予定作業期間・期限と実際所要期間・完了時期を比較する
・コスト：予算に対する実績を測定し、予算実績差異を比較する
・要員：必要予定要員数と実際要員数を比較するほか、チーム/ベンダーのパフォーマンス状況を評価する
・調達：調達仕様の条件を満たしているか確認する
・品質：専門的・技術的パフォーマンス評価のほか、欠陥の発生数や発生確率、修正割合を確認する
・リスク：潜在的リスクの発現可能性を確認する

なお、進行段階では全てを測定することにこだわらず、要点を絞って測定することが効率的であり現実的です。

フェーズ・ゲートとは、各フェーズの最終段階で実施するレビューをいいます。
プロジェクトの運営責任者が集まり、進捗状況や期待されている価値や成果の充足度、現在のビジネス環境などを踏まえて、「継続（次のフェーズに進む、または一部修正後に進む）」「中断」「中止」のいずれかを判断します。
このフェーズ・ゲートで中止するか判断することが議題となる場合には、キル・ポイントと表現されます。

プログラムとは、個別プロジェクトの集合体をいいます。
プログラムマネジメントとは、プログラムの管理者として、各プロジェクトの調整を図りながらプログラムを管理していくことを指します。

例えば、次世代ロケット開発プログラムとして、低燃費エンジン開発プロジェクトと本体軽量化プロジェクト、誘導制御技術の改良プロジェクトがあるようなイメージです。

プロジェクトとは、決められた目標・期日に合わせて、要望に合った製品・サービス・成果を提供する業務をいいます。
つまり、プロジェクトには納期が設定されるとともに（有期性）、要望に合わせるため定常業務とは異なります（独自性）。

このようなプロジェクトは、特定の業種に限定されず、重工業・建設業・製薬業・システム開発業・飲食業などあらゆる業界で発生します。

なお、プロジェクトより広い集合体として、プログラムやポートフォリオがあります。

プロジェクトの成功基準として、QCD（Quality：品質、Cost：コスト、Delivery：スケジュール）を守ることが挙げられます。
【品質を満たす】
・プロジェクト立ち上げた際に想定した成果に定量的・定性的に期待に応えることが求められます。
【予算内に収める】
・プロジェクトは投資の性質を有しているため、予算内で目標の成果を達成することが求められます。いくら完了したとしても、予算超過により経済的損失を招いた場合には成功とは評価されません。
【スケジュール期限内に完了する】
・プロジェクトはスケジュール通りに完了させることが原則として求められます。いくら成果が出たとしても、期限に間に合わなければ成功したとは評価されません。

なお、求められた品質の成果を、予算通り、スケジュール通りに完了させたからといって、必ずしも成功とは言えない場合もあります。それらの定義が利用者や経営者の定義と異なる場合があるためです。
そのため、成功か否かは他者の評価によって決まるということを念頭に、各ステークホルダーと成功の定義の合意を図ることが必要です。

プロジェクトマネジメントとは、知識やスキル、ツール、テクニックを用いてプロジェクトの要望を満たしたうえで、成果に導くための取り組みを指します。
知識やスキルとしてノウハウや経験が必要になるとともに、ツールや技法としてプロジェクト計画書やタスク日程表、進捗管理、予算管理の方法が求められます。

プロジェクトマネジメント計画書は、通常、下記要素で構成されます。
・スコープ管理
・スケジュール管理
・予算コスト管理
・要員管理
・調達管理
・契約管理
・課題リスク管理
・文書管理
・エンゲージメント管理
・品質管理
・変更管理
・障害管理

それぞれの具体的な記載・遵守事項、成功要因についてはフィン パートナーズまでお気軽にお問い合わせください。

プロジェクトマネジャーは、プロジェクトの品質、スコープ、コスト、スケジュール、課題リスクなどを管理する役割のほか、ステークホルダーのニーズと期待に応えながら目標・成果を達成する責任が求められます。
プロジェクトマネジャーには、該当プロジェクトでの専門的な知識と経験のほか、プロジェクトの立ち上げから完了までの期間におけるリーダーシップの発揮が求められます。

優れたプロジェクトマネジャーには下記の特性があります。
1.　プロジェクト目標を経営層や顧客と合意が取れている
2.　経営層や顧客のほか、プロジェクトに関わるステークホルダーと常に良好な関係にあり、コミュニケーションが取れるように配慮している
3.　プロジェクトの方向性・行動指針をプロジェクトチームに伝達・啓蒙している
4.　期待値とスコープのコントロールを徹底できている
5.　進捗状況や課題リスクを常に可視化のうえ、必要に応じて自らがディープダイブして対応できる知識と経験を有している

プロジェクト憲章とは、プロジェクトの目的や成果、関係するステークホルダーを明確にしたものをいい、プロジェクトの存在を組織内部に公式に認知させるために必要になるものです。
この憲章を掲げることで、プロジェクトマネジャーは組織の資源をプロジェクトのために活用することができるとともに、ステークホルダーからの協力を得ることが出来ます。

プロジェクト憲章には、通常、下記項目が記載されます。
・目的
・スコープ
・想定している成果や成果物
・プロジェクト予算とスケジュール
・プロジェクトの完了条件
・関係するステークホルダー
・プロジェクトマネジャーと指揮命令系統

ポートフォリオとは、戦略目標を達成するための業務群をいいます。
ポートフォリオの管理者としてポートフォリオマネジャーを設置のうえ、戦略目標の達成のために、各プログラム・プロジェクト・定常業務の調整を図りながら管理していくことが求められます。

戦略目標を事業目標と読み替えて、ポートフォリオを事業部での業務と捉えると分かりやすいかと思います。
この場合、ポートフォリオマネジャーとは事業部長を指すことになり、事業部のなかで立ち上げたプログラムやプロジェクト、定常業務を管理していくことになります。

プロジェクトにおいて重要な意味を持つ時点やイベントを指します。

ソフトウェアなどのアジャイル開発において、チームメンバの活動の有効性と改善方法を議論する振り返り会議のことをいいます。

プロジェクトのマイルストーンや重要なイベント、意思決定ポイントなど、大枠のスケジュールを示したものをいいます。

内外製分析とは、プロジェクト推進に必要な製品・サービスや人材を組織内で製作・調達するか、外部から調達するか判断するための分析手法です。

技術（自社のコア技術or非コア技術）とコスト（大or小）で4象限マトリックスを使って分析するもので、コア技術×コスト小であれば内製化、非コア技術×コスト大であれば外部調達という判断になりえます。

一方で、コア技術×コスト大の場合には、技術流出の可能性も考慮しながら内外製のいずれとするか判断が求められるとともに、非コア技術×コスト小の場合でもコスト競争力の観点から内外製のいずれとするかの判断が必要となります。

受入基準とは、成果物が顧客やステークホルダーに受け入れられる前に満たしておくべき条件をいいます。

変更コストとは、プロジェクトに関連する文書、成果物などの変更に伴うコストをいいます。
プロジェクトが進行するにつれて、使用の変更や開発の修正が必要になるなど、そのコストは指数関数的に増加します。
そのため、変更は早めのフェーズで特定するとともに、後続フェーズで識別された場合には、その必要性とコストなどを比較考慮のうえ、判断することになります。

変更管理（Change Control）とは、プロジェクトに関連する文書や成果物などへの変更要求を承認または却下するプロセスをいいます。

変更管理委員会（Change Control Board）とは、変更要求を承認または却下するなど、その決定責任を任命された組織体をいいます。

変更要求（Change Request）とは、プロジェクトに関連する文書や成果物などへの修正を求める正式な提案をいいます。

プロジェクトのチームメンバーとして求められる振る舞いや期待をいいます。

責任分担マトリックスとは、タスクごとのチームメンバーの役割を明示したもので、下記区分で可視化します。
・実行責任者（Responsible）
・説明責任（Accountable）
・相談対応（Consult）
・情報提供先（Inform）