プロジェクトマネジメント

プロジェクトマネジメントとは、特定の目標を達成するために、一定期間をかけて完成させる計画的な作業や活動を管理することです。

★本ページの内容：

1. プロジェクトとは
2. プロジェクトマネジメントとは
3. プロジェクトマネジメントスキルについて
4. プロジェクトマネジメント業務について
5. プロジェクトマネジメントツールについて
6. プロジェクトを成功に導くポイントについて
7. プロジェクトマネジメントの重要性について
8. PMOについて
9. プロジェクトマネジメントのサンプル資料

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）とはプロジェクトを管理するため、各工程を各担当者の作業レベルまで分解し、割り当てたものです。上記の体制図における役割と責任は、次の表のとおりです。

　プロジェクトの成功は「プロジェクトマネージャー」のプロジェクトマネジメントスキル（知識・経験・実績・信用）に掛かっていると言っても過言ではありません。プロジェクトマネジャーがプロジェクトの目的や仕様を的確に理解して、プロジェクト体制をしっかりと構築し、スキルの基づいて確実に運用すれば、メンバーが効率的に業務を遂行でき、成果物を納品できて成功に至るからです。

3. プロジェクトマネジメントスキルについて

　まず、プロジェクトマネジメントスキルには限らないことですが、スキルは「知識・経験・実績・信用」という要素で構成されています。

（※）ITプロジェクトの規模感（イメージです。正確な定義はございません）：

　ここで特筆すべきこととして、プロジェクトマネージャーはITスキル保持者とは限りません。ITスキルがないプロジェクトマネージャーは多く存在します。特に中小規模プロジェクトでは文系出身で、論理的思考があり、コミュニケーション能力が高く、必要なIT知識はプロジェクト参加者から得るようにして、分からないことは持ち帰り、大会議のファシリテーターのように振舞うことによりプロジェクトを成功に導いたプロジェクトマネジャーを数多く見てきました。

　但し、大規模なITプロジェクトになると、やはりITスキルを保有するプロジェクトマネージャーが求められます。大規模プロジェクトでは、専門家が集まることが多く、専門用語でコミュニケーションを取りながら、仕様の確認・整理、役割分担と責任分担、問題管理、進捗管理、スケジュール管理、予算管理、リスク管理を行い、アプリケーション構築方法、インフラ・セキュリティの課題対応や運用・保守に対して的確なソリューションを迅速に提供して進捗を早めることができるからです。

4. プロジェクトマネジメント業務について

　プロジェクトマネジャーに必要な資質は、「プロジェクトマネジメント手法を理解・遂行する論理的思考およびチームをリードするコミュニケーション能力」です。プロジェクトマネジャーになるための一番の近道は、OJTです。つまり、プロジェクトリーダーあるいは副プロジェクトマネジャーとして、優秀なプロジェクトマネジャーの下で期間１年以上の中規模以上のプロジェクトに従事することです。

　また、プロジェクトマネジャーの一般的な業務は次のとおりです。

5. プロジェクトマネジメントツールについて

　市場にはプロジェクトマネジメントを支援するための専用ツールが多数存在します。但し、プロジェクトの規模によっては、オフィスツール+ファイル共有サーバー（グループウェア含む）で十分対応可能です。一般的に用いられるツールは以下のとおりです。

★参考：ユーザー企業側のプロジェクト予算管理では、プロジェクト全体の稟議書・決議書で承認された金額内に収めることが主なタスクとなります。ベンダー側では、利益を確保するために各プロジェクトのフェーズについて厳密な予算管理が必要です。そのための複数のプロジェクトにおける投資や人材配置を管理する専用ツールも存在します（例: HP Project and Portofolio Management）。

6. プロジェクトを成功に導くポイントについて

　インフラ系システム改善プロジェクトのように、プロジェクト参加者がIT部とベンダーに限られているプロジェクトの遂行は難しくありません。エンドユーザーとは、当該システム利用不可時間を調整するだけで済みます。

　会計システムや人事・給与管理システムの改善プロジェクトのように、参加者が３者のみのプロジェクトの遂行の難度は中レベルです。システムオーナーである人事部や経理部からの参加者が担当業務に精通していれば、プロジェクトは問題なく達成できます。

　販売系ERP導入プロジェクトや製造系ERP導入プロジェクトのように、プロジェクト参加者が4者以上である場合、システムオーナーの決定、会議を含むコミュニケーションの場面や調整事項が多くなるため、プロジェクトの遂行難度は高くなります。

　グローバルなERP導入プロジェクトなどでは、プロジェクト参加者が多く、コミュニケーション言語および時差調整の課題が上記の課題に加わるため、国内ERPプロジェクトと比較すると超高難度となります。

　各プロジェクトの難度に対して適切な実績があるプロジェクトマネジャーをアサインすることが、プロジェクトを成功させる重要なポイントとなります。

　次に、もう一つの重要なポイントの説明を進めるため、「1.9　ITベンダーマネジメント」に掲載したシステム企画・構築・運用までのスコープ図を再掲します。

　上記のスコープにおける各フェーズは、以下のように複数のプロセスで構成されています。

（１）事前準備： RFP作成プロセス　

　ユーザー企業がプロジェクトを成功させる鍵は、ITベンダーに提出する提案依頼（RFP）を「高い完成度」で作成することです。システム仕様書作成には、あらゆるリソース「ヒト・モノ・カネ・情報・時間」を投入すべきです。

　特に「仕様のあいまいさ」による変更・追加は、プロジェクト進行中の業務量の増加、スケジュール変更および予算増加を招くため、仕様が正確に定義されてからプロジェクトを開始してください。　

　RFPを作成するための考え方は次のとおりです。

　続いて、RFP本文の作成に必要な情報の例は以下のとおりです。

　RFPにおいてクラウドを利用する場合は、利用可能なCPUの周波数、スレッド数とコア数、メモリーとストレージの容量の記載で十分です。RFP本文を補足する資料は、「スクラッチ開発」と「パッケージ導入」のいずれの方式を採用するかによって内容が異なります。

★特記事項：パッケージソフトウェアを導入する大規模プロジェクトでは、当該パッケージに詳しいITコンサルタントと一緒にRFPを完成することがあります。パッケージが提供している機能群が自社で必要な機能にどれくらい適合しているか（適合率, fit）を把握する必要があるからです。なお、適しない機能(ギャップ, gap)については、どのように当該機能を実現するかも検討する必要があります（アドオン、カスタマイズ、人間が個別に運用で対応するなど）。この一連の作業をフィット＆ギャップ（Fit & Gap）と言います。

★参考：RFI（Request for Information）について「こちら」をクリックしてご参照ください。

（2）ベンダー選定：一般競争入札プロセス　

　ベンダーを選定するための一般競争入札プロセスは、以下のとおりです。

（３）プロジェクト本番：プロジェクトマネジメント

　プロジェクトマネジメント本番の内容は、以下のとおりです。

　「要求定義フェーズ」では、ベンダーと詳細な機能確認をする際、機能変更や追加が発生することがあります。微細な変更であれば、工数の変更は発生しませんが、機能追加の場合は工数やスケジュールに伴って納期のリスケや予算の増加が発生します。このようなことが多少発生する前提で、全体スケジュールの予備日および予備費で賄えるように管理することが重要です。

　リスケや予算増加を回避する一つの方法は、「要求定義フェーズ」完了後に受けたエンドユーザーから機能変更や追加についての要求をその直後のシステム構築フェーズでは反映しない「静止ポイント」を設けることです。その場合、受け付けた要求は、ビジネスに必須な機能なのか、便利な機能なのかを分類して、優先順位を付け、見積を取り、システムオーナーと合意の上で、システムリリースの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が意思決定できない事項の例

1. M&Aによる経営環境の大きな変化に伴うプロジェクトの継続・延期・中止に関する判断
2. ベンダー側が提案したソフトウェアアプリケーションにプロジェクト内で解決できない大きな瑕疵・不具合が発見された場合のプロジェクトの延期・中止の判断など

　大手のユーザー企業や大手のITベンダーでは同時に複数のプロジェクトが推進されているため、これらのQCDおよびリスクを管理する仕組み・組織として、「PMO・全体管理型」が構築・編成されます。「PMO・プロジェクト事務局型」と「PMO・全体管理型」のイメージ図は以下のとおりです。

9. プロジェクトマネジメントのサンプル資料

　まず、RFPの作成手順は以下のとおりです。

　続いて、RFPに関するサンプル集は次のとおりです。

1. RFPのサンプル
   1. テレワーク用VDI基盤構築サンプル
   2. 複合機リプレイスサンプル
2. RFP評価基準のサンプル
3. RFP実施のための通知サンプル
   1. 案内状(応諾の意思確認)サンプル
   2. RFP採用通知サンプル
   3. RFP不採用通知サンプル
4. RFP依頼者プレゼンテーション時のアジェンダ
5. RFPベンダープレゼンテーション時のアジェンダ
6. キックオフミーティングのアジェンダ（一部・二部）
7. プロジェクト参加者名簿のサンプル
8. プロジェクト進捗管理資料のサンプル
   （アジェンダ、議事録、課題管理表、進捗管理、全体スケジュールなど）
9. プロジェクトリリース・稼働判定資料
10. プロジェクトクロージングのアジェンダ

ワンポイントメッセージ：プロジェクトマネジメントは、適切に用いれば部門横断のシステム課題を円滑に解決できる効果的な手法です。

　次項の”COBIT”は「こちら」をクリックしてご参照ください。