プロジェクトマネジメントとは、特定の目標を達成するために、一定期間をかけて完成させる計画的な作業や活動を管理することです。
★本ページの内容：
- プロジェクトとは
- プロジェクトマネジメントとは
- プロジェクトマネジメントスキルについて
- プロジェクトマネジメント業務について
- プロジェクトマネジメントツールについて
- プロジェクトを成功に導くポイントについて
- プロジェクトマネジメントの重要性について
- PMOについて
- プロジェクトマネジメントのサンプル資料
1. プロジェクトとは
まず、プロジェクト（Project）とはなにか。ケンブリッジ英英辞典では、「特定の目標を達成するために、一定期間をかけて完成させる計画的な作業や活動のこと」と定義されています。
Cambridge Dictionary: Project
A planned task or activity that takes a certain period of time to complete in order to achieve a specific goal.
有名なプロジェクトの例として、マンハッタン計画（Manhattan Project、マンハッタンプロジェクト）やアポロ計画（Project Apollo、プロジェクト・アポロ）がありますが、これらは「原子爆弾構築や有人月面着陸という目標を達成するために、一定期間をかけて完成する計画的な作業や活動」を指します。つまり、目的を達成するための「手段」です。余談となりますが、これらの目的は「戦争勝利」および「宇宙開発競争の優位性確保」でした。
スコープをビジネスに絞った場合、例えば受注生産方式の製造業や建設業では顧客から受注した案件をプロジェクトと呼びます。
ITの分野では、①ITサービス（ソフトウェアアプリケーション含む）を構築・提供するベンダー側のプロジェクトと②IT活用するユーザー企業側のプロジェクトに分けられます。
ここでは、後者を扱います。具体的には、ユーザー企業でビジネス目的を達成するための一つの手段として、IT活用が挙げられます。そして、ITを最大限に活用するためには、自社業務に適切な機能・品質のITサービスやソフトウェアアプリケーションを適切なタイミングと予算で調達し、エンドユーザーに安全・安定的に提供することが必要です。
このITサービスやソフトウェアアプリケーションの「企画、調達（開発・構築）、提供」のために期間限定のチームで行う業務を「プロジェクト」と呼びます。なお、一人で全部の作業を実施する「一人プロジェクト」と呼ばれるものもありますが、ここでは、中規模以上で、最低限ベンダーをパートナーとしてチームを組むことを前提としています。
2. プロジェクトマネジメントとは
「プロジェクトマネジメント」とは、プロジェクトの成果物の品質を担保し、期限内に納品させ、かつ予算内に収めるために必要なチームワークを効率的・効果的に遂行する管理業務です。
チームワークである以上、チーム体制を構築・運用する必要があります。このチーム体制をプロジェクト体制と呼びます。一般的なプロジェクト体制および主な役割・活動は以下の図のとおりです。
WBS（Work Breakdown Structure）とはプロジェクトを管理するため、各工程を各担当者の作業レベルまで分解し、割り当てたものです。上記の体制図における役割と責任は、次の表のとおりです。
| No. | プロジェクト参加者 | 役割・責任 | 備考 |
| 1 | プロジェクト オーナー | プロジェクトの全責任者 | ・社長 ・IT担当役員 ・IT部長（CIO） |
| 2 | プロジェクト スポンサー | ヒト、モノ、カネ、情報、時間を提供する | ・IT担当役員 ・IT部長（CIO） |
| 3 | プロジェクト マネジャー （以下、PM） | ・プロジェクトを推進・統括する ・プロジェクトマネジメントスキル必須 | ・次長/課長クラス ・意思決定 ・体制構築 ・課題・問題管理 リスク管理含む ・進捗管理 ・スケジュール管理 ・リソース管理 ・予算管理 ・会議体管理 ファシリテーション含む |
| 4 | プロジェクト リーダー | ・プロジェクトの一部をリードする ・PMを補佐する | ・課長/課長代理クラス ・営業機能のリード ・製造機能のリード ・管理部門のリード |
| 5 | プロジェクト メンバー | ・個別機能実現のために参加する | ・係長クラス/主任クラス ・販売管理担当 ・生産管理担当 ・人事・給与担当 ・経理/会計担当 |
| ６ | PMO プロジェクト マネジメント オフィス | ・PMOメンバーが意思決定できない事項に対応する | ★PMOメンバー： ・プロジェクトオーナー ・プロジェクトスポンサー ・PM ・プロジェクトリーダー ・他の管理職・有識者 |
プロジェクトの成功は「プロジェクトマネージャー」のプロジェクトマネジメントスキル（知識・経験・実績・信用）に掛かっていると言っても過言ではありません。プロジェクトマネジャーがプロジェクトの目的や仕様を的確に理解して、プロジェクト体制をしっかりと構築し、スキルの基づいて確実に運用すれば、メンバーが効率的に業務を遂行でき、成果物を納品できて成功に至るからです。
3. プロジェクトマネジメントスキルについて
まず、プロジェクトマネジメントスキルには限らないことですが、スキルは「知識・経験・実績・信用」という要素で構成されています。
| No. | スキル | 会得する方法 | 備考 |
| 1 | 知識 | ★プロジェクトマネジメント手法 ・大学で学ぶ ・研修・セミナーで学ぶ ・独学 ・OJT | ★資格： ・PMP ITに限らず様々な分野の プロジェクトに汎用的に 適用できるマネジメント手法の資格 ・プロジェクト管理 ITに特化している資格 |
| 2 | 経験 | ★OJT →プロジェクトマネージャーの部下として プロジェクトリーダー →プロジェクトリーダーの部下として プロジェクトメンバー | ・プロジェクト参加 |
| 3 | 実績 | ★プロジェクトの規模（※） ・小規模プロジェクト ・中規模プロジェクト ・大規模プロジェクト | ・マネジメントしたプロジェクト の参加人数は重要である |
| 4 | 信用 | プロジェクト成功実績は信用に繋がる | ・信用があると判断され、 信頼されて次の仕事を任される |
（※）ITプロジェクトの規模感（イメージです。正確な定義はございません）：
| No. | 規模感 | 金額 | 参加者数 | 期間 | 備考（事例） |
| 1 | 小規模 | 1億円未満 | ～10 | 数か月 | 一般的な業務システム |
| 2 | 中規模 | 1～5億円 | 10～50 | １年未満 | ローカルERP導入プロジェクト |
| 3 | 大規模 | 5～100億円 | 50～300 | １年～ | 全国規模販売管理・ 物流システム導入プロジェクト |
| 4 | 特別大規模 | 100億円～ | 300～ | 3年～ | グローバルERP導入プロジェクト 大企業M&Aによる システム統合プロジェクト |
ここで特筆すべきこととして、プロジェクトマネージャーはITスキル保持者とは限りません。ITスキルがないプロジェクトマネージャーは多く存在します。特に中小規模プロジェクトでは文系出身で、論理的思考があり、コミュニケーション能力が高く、必要なIT知識はプロジェクト参加者から得るようにして、分からないことは持ち帰り、大会議のファシリテーターのように振舞うことによりプロジェクトを成功に導いたプロジェクトマネジャーを数多く見てきました。
但し、大規模なITプロジェクトになると、やはりITスキルを保有するプロジェクトマネージャーが求められます。大規模プロジェクトでは、専門家が集まることが多く、専門用語でコミュニケーションを取りながら、仕様の確認・整理、役割分担と責任分担、問題管理、進捗管理、スケジュール管理、予算管理、リスク管理を行い、アプリケーション構築方法、インフラ・セキュリティの課題対応や運用・保守に対して的確なソリューションを迅速に提供して進捗を早めることができるからです。
4. プロジェクトマネジメント業務について
プロジェクトマネジャーに必要な資質は、「プロジェクトマネジメント手法を理解・遂行する論理的思考およびチームをリードするコミュニケーション能力」です。プロジェクトマネジャーになるための一番の近道は、OJTです。つまり、プロジェクトリーダーあるいは副プロジェクトマネジャーとして、優秀なプロジェクトマネジャーの下で期間１年以上の中規模以上のプロジェクトに従事することです。
また、プロジェクトマネジャーの一般的な業務は次のとおりです。
| No. | 業務 | 内容 | 備考 |
| 1 | 意思決定 | PMの権限確認 | ・指揮命令系統 ・メンバー評価 ・リソースアサイン ハードウェア ソフトウェア |
| 2 | 体制構築 | メンバーの選定・統括 | ・参加者の スキルの把握 業務量の把握 |
| 3 | 課題・問題管理 | 重要度・緊急度の見極め | 小・中・大レベルの課題分類 |
| 4 | 進捗管理 | 全体スケジュールに 対して作業の進捗管理 | ・進んでいる ・オンタイム（順調） ・遅れ 遅れ管理 リスケ |
| 5 | スケジュール管理 | 全体スケジュール 個別タスクスケジュール | 予備日を考慮したスケジュール必須 |
| 6 | リソース管理 | ・ハードウェア ・ソフトウェア | 不足部分はプロジェクトスポンサーと相談 |
| 7 | 予算管理 | 予算内に収める | ・初期費用 （ライセンス、ハードウェア） ・開発費用 ・運用費用（サポート） |
| 8 | 会議体管理 | ・月次 ・週次 | ・ファシリテーション ・議事録 |
| 9 | リスク管理 | a) プロジェクト開始前 ・仕様のあいまいさ ・技術的な難易度 ・メンバーのスキル不足 ・タイトなスケジュール ・予備費がない予算など b) プロジェクト進行中 ・プロジェクト中に仕様の追加・変更 （ヒト、スケジュールや予算に変化） c) プロジェクト解散後 ・運用体制未構築 | ★リスク対応策 ・リスク回避 ・リスク享受 ・リスク転換 |
| 10 | コミュニケーション能力 | ・ポジティブな言動を心がける ・ネガティブな言動は避ける ・建設的な批判はOK！ ・感情的な非難はNG。 | ・マクレガーのY理論 |
| 11 | 情報セキュリティ | a) セキュリティキーフレーズの決定 例： Project XX Confidential b) プロジェクトメンバーのリスト化 ユーザー企業側とベンダー側 | ・リストメンバー以外の者による プロジェクト資料へのアクセスが 確認された場合、セキュリティ 事故とみなす。 |
5. プロジェクトマネジメントツールについて
市場にはプロジェクトマネジメントを支援するための専用ツールが多数存在します。但し、プロジェクトの規模によっては、オフィスツール+ファイル共有サーバー（グループウェア含む）で十分対応可能です。一般的に用いられるツールは以下のとおりです。
| No. | 業務 | 支援ツール |
| 1 | 意思決定 | QCD+R |
| 2 | 体制構築 | パワーポイントのSmartArt |
| 3 | 課題・問題管理 | スプレッドシート |
| 4 | 進捗管理 | ・スプレッドシート ・マイクロソフトプロジェクト ・フリーテンプレート |
| 5 | スケジュール管理 | 同上 |
| 6 | リソース管理 | スプレッドシート |
| 7 | 予算管理 | スプレッドシート |
| 8 | 会議体管理 | ・スプレッドシート ・議事録： MSワード、スプレッドシート |
| 9 | リスク管理 | スプレッドシート |
| 10 | プロジェクトマネジメント 専用ツール | 代表的なWebツール ・Backlog |
★参考：ユーザー企業側のプロジェクト予算管理では、プロジェクト全体の稟議書・決議書で承認された金額内に収めることが主なタスクとなります。ベンダー側では、利益を確保するために各プロジェクトのフェーズについて厳密な予算管理が必要です。そのための複数のプロジェクトにおける投資や人材配置を管理する専用ツールも存在します（例: HP Project and Portofolio Management）。
6. プロジェクトを成功に導くポイントについて
インフラ系システム改善プロジェクトのように、プロジェクト参加者がIT部とベンダーに限られているプロジェクトの遂行は難しくありません。エンドユーザーとは、当該システム利用不可時間を調整するだけで済みます。
会計システムや人事・給与管理システムの改善プロジェクトのように、参加者が３者のみのプロジェクトの遂行の難度は中レベルです。システムオーナーである人事部や経理部からの参加者が担当業務に精通していれば、プロジェクトは問題なく達成できます。
販売系ERP導入プロジェクトや製造系ERP導入プロジェクトのように、プロジェクト参加者が4者以上である場合、システムオーナーの決定、会議を含むコミュニケーションの場面や調整事項が多くなるため、プロジェクトの遂行難度は高くなります。
グローバルなERP導入プロジェクトなどでは、プロジェクト参加者が多く、コミュニケーション言語および時差調整の課題が上記の課題に加わるため、国内ERPプロジェクトと比較すると超高難度となります。
| No. | 難度 | 内容 | 備考（事例） |
| 1 | 低 | IT部とITベンダーで完結するプロジェクト 利用部門とは利用不可時間のスケジュール調整のみ | ・ネットワーク改善プロジェクト ・AD/DNS改善プロジェクトなど |
| 2 | 中 | IT部、利用部門およびベンダーで完結するプロジェクト | ・人事/給与管理システム改善プロジェクト （IT部と人事部） ・会計システム改善プロジェクト （IT部と経理部） ・SFA/CRM導入システムプロジェクト （IT部と営業部） |
| 3 | 高 | IT部、複数の利用部門およびベンダーで完結するプロジェクト | ・販売系ERP導入プロジェクト （IT部・経理部・営業部） ・製造系ERP導入プロジェクト （IT部・経理部・営業部・製造部） |
| 4 | 超高 | IT部、国内部門、海外拠点およびベンダーで完結するプロジェクト | ・グローバルERP導入プロジェクト チーム編成、コミュニケーション言語および時差対応の課題あり |
各プロジェクトの難度に対して適切な実績があるプロジェクトマネジャーをアサインすることが、プロジェクトを成功させる重要なポイントとなります。
次に、もう一つの重要なポイントの説明を進めるため、「1.9 ITベンダーマネジメント」に掲載したシステム企画・構築・運用までのスコープ図を再掲します。
上記のスコープにおける各フェーズは、以下のように複数のプロセスで構成されています。
| No. | フェーズ | 内容 | 備考 |
| 1 | 要件定義フェーズ 事前準備 | RFPを作成するプロセス | ・必要な機能と便利な機能を分ける ・必要な機能優先 |
| 2 | 要求定義フェーズ ベンダー選定 | 一般競争入札プロセス | ・複数ベンダーに声掛けする ・契約締結 |
| 3 | システム構築フェーズ プロジェクト本番 | プロジェクトマネジメント | ・キックオフミーティング ・プロジェクト進捗管理 ・ユーザーテスト ・稼働判定 ・システムリリース（納品） ・クロージング |
| 4 | システム運用フェーズ 事後対応 | マイナー機能改良・改善 | ・システムリリースから6か月以上 |
（１）事前準備： RFP作成プロセス
ユーザー企業がプロジェクトを成功させる鍵は、ITベンダーに提出する提案依頼（RFP）を「高い完成度」で作成することです。システム仕様書作成には、あらゆるリソース「ヒト・モノ・カネ・情報・時間」を投入すべきです。
特に「仕様のあいまいさ」による変更・追加は、プロジェクト進行中の業務量の増加、スケジュール変更および予算増加を招くため、仕様が正確に定義されてからプロジェクトを開始してください。
RFPを作成するための考え方は次のとおりです。
続いて、RFP本文の作成に必要な情報の例は以下のとおりです。
RFPにおいてクラウドを利用する場合は、利用可能なCPUの周波数、スレッド数とコア数、メモリーとストレージの容量の記載で十分です。RFP本文を補足する資料は、「スクラッチ開発」と「パッケージ導入」のいずれの方式を採用するかによって内容が異なります。
| No. | フェーズ | 内容 |
| 1 | スクラッチ開発 | ・データベース情報 ・実態関連図 = Entity Relationship（ER）図 ・各画面のイメージ図 ・全体画面の遷移図 ・業務フロー ・ベンダー選定基準 |
| 2 | パッケージ導入 | ・業務フロー ・帳票類の印刷 ・ベンダー評価基準 |
★特記事項：パッケージソフトウェアを導入する大規模プロジェクトでは、当該パッケージに詳しいITコンサルタントと一緒にRFPを完成することがあります。パッケージが提供している機能群が自社で必要な機能にどれくらい適合しているか（適合率, fit）を把握する必要があるからです。なお、適しない機能(ギャップ, gap)については、どのように当該機能を実現するかも検討する必要があります（アドオン、カスタマイズ、人間が個別に運用で対応するなど）。この一連の作業をフィット＆ギャップ（Fit & Gap）と言います。
★参考：RFI（Request for Information）について「こちら」をクリックしてご参照ください。
（2）ベンダー選定：一般競争入札プロセス
ベンダーを選定するための一般競争入札プロセスは、以下のとおりです。
| No. | 業務 | 内容 |
| 1 | ベンダー選定 | ・声掛けする参加ベンダーの選定 |
| 2 | 会議室予約 | ・ベンダーのRFP説明会用 ・各ベンダーからの提案書プレゼン用 ・RFPプレゼンテーター・評価者参加必須 |
| 3 | 各ベンダーへRFP参加依頼通知送付 | ・辞退を想定して複数ベンダーに声掛けする ・ベンダーの参加人数を限定しておく （３～4名） |
| 4 | 各ベンダーからRFP参加回答受領 | ・客観的な評価をするため最低3社が望ましい |
| 5 | 一般競争入札プロセス実施 | ・秘密保持契約書を締結する ・参加ベンダー全員に一回でプレゼンする →セミナー形式 ・参加ベンダーに個別にプレゼンする →あるベンダーが参加していることを 他のベンダーに知られたくないケース |
| 6 | RFP本体および補足資料を各ベンダーへ送付する | 専用サイトがあると望ましい |
| 7 | RFP内容質問受付期間 | RFP質問-回答票利用する |
| 8 | 各ベンダーより提案書受領する | 期限厳守 |
| 9 | 各提案書を読み込む | QCDおよびリスクは把握しておく |
| 10 | 各ベンダーによる提案書のプレゼンを聴く | ベンダーPMのプレゼン必須 |
| 11 | 各評価者は提案書を評価する | ベンダー評価基準ベース |
| 12 | 各ベンダーへ提案書採否の連絡をする | 不採用の場合、理由を記載すると親切 |
| 13 | 採用した提案書のベンダーと契約を締結する | 事前に契約スキームを確定しておく |
| 14 | プロジェクト開始 | キックオフミーティング実施 |
（３）プロジェクト本番：プロジェクトマネジメント
プロジェクトマネジメント本番の内容は、以下のとおりです。
| No. | プロジェクト内容 | 備考 |
| 1 | キックオフミーティング | ・一部： お互いのメンバー紹介 （プロジェクトのトップ参加） プロジェクト全体の説明 ・二部： プロジェクトのトップ退室 今後の予定確認（定例会） |
| 2 | プロジェクト進捗管理I ・要求定義フェーズ | ・頻繁にベンダーと会議を実施するフェーズ →定例会で確認する内容 アジェンダ 前回の議事録確認 課題・管理管理 進捗管理 プロジェクトスケジュール 次回のスケジュール確認 |
| 3 | プロジェクト進捗管理II ・システム構築フェーズ | ・ベンダーによるシステム構築中心になるフェーズ →必要に応じて会議を開催する |
| 4 | ユーザーテスト | ・ユーザーが実際に利用を試みる |
| 5 | システム稼働判定 | ・合否 ・否の場合、対応スケジュール調整 |
| 6 | エンドユーザーへ説明会実施 | ・メインユーザーには座学形式推奨 ・拠点ユーザーにはオンライン説明会実施 |
| 7 | システムリリース（納品） | ・新システム利用開始 ・システムによって、旧システムと並行利用あり |
| 8 | クロージングミーティング | ・プロジェクト全体のパフォーマンス評価 |
「要求定義フェーズ」では、ベンダーと詳細な機能確認をする際、機能変更や追加が発生することがあります。微細な変更であれば、工数の変更は発生しませんが、機能追加の場合は工数やスケジュールに伴って納期のリスケや予算の増加が発生します。このようなことが多少発生する前提で、全体スケジュールの予備日および予備費で賄えるように管理することが重要です。
リスケや予算増加を回避する一つの方法は、「要求定義フェーズ」完了後に受けたエンドユーザーから機能変更や追加についての要求をその直後のシステム構築フェーズでは反映しない「静止ポイント」を設けることです。その場合、受け付けた要求は、ビジネスに必須な機能なのか、便利な機能なのかを分類して、優先順位を付け、見積を取り、システムオーナーと合意の上で、システムリリースの6ヶ月後以降に行うマイナー機能改良・改善フェーズで実施します。
（4）事後対応：マイナー機能改良・改善
「スクラッチ開発」の場合は、システムリリースから約6ヶ月が経過した頃に、エンドユーザーへアンケートを行い、システムのマイナーな機能改善を実施します。この機能改善を実施することによって、システム利用の満足度が高まり、５～６年継続できます。もちろん、この間にも、ビジネス環境変化による機能の追加変更は実施します。
このフェーズの構築はシステム構築稟議書（決議書）にマイナー機能変更・改善の費用（目安：全体構築費用の10%）を含めておくことによりスムーズに実施できます。
7. プロジェクトマネジメントの重要性について
ここで、プロジェクトマネジメントの成功事例を紹介します。A社のIT担当役員はITには詳しくなく、かつプロジェクトマネジメント手法を知りませんでした（国内企業では少なくない話です）。要件として営業部門と製造部門が利用していた業務システムの改善が必要でしたが、営業がリードするのか、製造がリードするのか、IT部が全部やるべきなのか、システムオーナーがなかなか決まりませんでした。
経営陣はこの課題を解決するためにプロジェクトマネジメントの経験があるITマネジャーを新規採用し、IT担当役員はITマネジャーに時間をかけて業務を習得させてから、システム改善を遂行させようとしました。しかし、これは非効率であるため、ITマネジャーはIT担当役員にプロジェクトマネジメント手法を説明し、営業業務および製造業務に詳しいプロジェクトリーダーのアサインを依頼しました。結果、システム改善プロジェクトは問題なく成功し、ITマネジャーのプロジェクトマネジメント手法は高く評価されました。
つまり、プロジェクトマネジャー（PM）がすべての業務の内容を把握していなくても、業務に詳しい人とチームを組んでプロジェクトマネジメント手法を用いることにより、相乗効果（シナジー）を発揮して、目標を達成できるということです。
その後、営業のCさんと製造のDさんは他のプロジェクトにも参加して、最終的にPMP（プロジェクトマネジメントプロフェッショナル）資格を取得して現場のビジネスパワーユーザーとなりました。彼らは会社全体のITリテラシーを向上させる立役者となりました。
よく質問される「プロジェクトマネジメント体制でのメンバーの実績をどのように評価するのか」についてはまず、プロジェクトマネジャーが各メンバーのプロジェクト活動の業績を評価して、各ライン管理職へ報告します。そして、各メンバーの直属の上司であるライン管理職がプロジェクト業務およびライン業務を総合評価して、部門長が最終的に評価を確定します。この方法はクロスファンクショナルチームと呼ばれ、各メンバーの評価は以下のイメージ図のとおりに行われております。
★部長・次長は、会社が定めた半恒久的なチームをリードする管理職であるのに対し、PMはテンポラリー（一時的）なチームをリードする管理職です。
8. PMOについて
PMO（Project Management Office）は「組織内のプロジェクトを統制する仕組みを作り、実行していく組織」だとPMI（Project Management Institute：プロジェクトマネジメント協会）は説明しています。
中小企業での実際の仕組みとして、進行中のプロジェクトにおいて、アサインされているPMが意思決定できない事項については、PMOメンバー（ユーザ企業およびベンダー側の管理職・有識者）が意思決定を行い、解決するチームとなります。このチームを「PMO・プロジェクト事務局」といいます。「２. プロジェクトマネジメントとは」のプロジェクト体制図では黄色いで囲んでいる部分に当たります。
★PMが意思決定できない事項の例
- M&Aによる経営環境の大きな変化に伴うプロジェクトの継続・延期・中止に関する判断
- ベンダー側が提案したソフトウェアアプリケーションにプロジェクト内で解決できない大きな瑕疵・不具合が発見された場合のプロジェクトの延期・中止の判断など
大手のユーザー企業や大手のITベンダーでは同時に複数のプロジェクトが推進されているため、これらのQCDおよびリスクを管理する仕組み・組織として、「PMO・全体管理型」が構築・編成されます。「PMO・プロジェクト事務局型」と「PMO・全体管理型」のイメージ図は以下のとおりです。
9. プロジェクトマネジメントのサンプル資料
まず、RFPの作成手順は以下のとおりです。
続いて、RFPに関するサンプル集は次のとおりです。
- RFPのサンプル
- RFP評価基準のサンプル
- RFP実施のための通知サンプル
- RFP依頼者プレゼンテーション時のアジェンダ
- RFPベンダープレゼンテーション時のアジェンダ
- キックオフミーティングのアジェンダ（一部・二部）
- プロジェクト参加者名簿のサンプル
- プロジェクト進捗管理資料のサンプル
（アジェンダ、議事録、課題管理表、進捗管理、全体スケジュールなど） - プロジェクトリリース・稼働判定資料
- プロジェクトクロージングのアジェンダ
ワンポイントメッセージ：プロジェクトマネジメントは、適切に用いれば部門横断のシステム課題を円滑に解決できる効果的な手法です。
次項の”COBIT”は「こちら」をクリックしてご参照ください。