このページでは、応用情報技術者試験における「プロジェクトマネジメント」の要点を解説していきます。
「プロジェクトマネジメントなんて全くわからない」という方に向けて、概要を理解しながら学習することを目標に書いていきます。そのため、深いところまでは触れていません。
応用情報技術者試験 – プロジェクトマネジメント
プロジェクトマネジメントとは?
プロジェクトとは、期間が設けられた一つの事業のことを指します。期限が決められておらず同じことを毎日繰り返して遂行する業務はプロジェクトとは呼びません。「2030年までに多摩川に橋をかけましょう」という声が挙がったら、多摩川に橋を建築するプロジェクトが立ち上がります。
そして、プロジェクトマネジメントは、予算と期限を守った上で品質の高い成果物を完成させるために行う活動全般のことを指します。
なんの計画も無しに「とりあえず橋を作ってみよう」なんてことはできません。材料の調達に必要な予算はいくらか?時間はどれくらいかかるか?骨組みを作るのにどれくらいの時間がかかるのか?など、様々な要項について考え、管理する必要がありますよね。これが、プロジェクトマネジメントです。
プロジェクトマネジメントの教科書「PMBOK」
では、実際プロジェクトマネジメントはどうやってやればいいの?という疑問が浮かびます。プロジェクトが立ち上がるたびにやり方を1から考えるのでしょうか?そうではありません。
実は、「これを参考にしてマネジメント方法を考えてね」というひな形があるのです。それが、PMBOK(Project Management Body of Knowledge)というもので、米国のプロジェクトマネジメント協会という団体によって作られました
PMBOKでは、活動内容を以下の通りに分けています。
活動内容 | 概要 |
---|---|
立ち上げ | プロジェクトの目標を決め、作業開始の準備をする |
計画 | 計画の詳細を決める |
実行 | 計画した通りに作業を実施する |
監視・コントロール | 作業の効率などを確認しつつ、改善点を見つけ出す 改善点が見つかったら、「計画」のプロセスに戻る |
集結 | プロジェクトの完了に必要な手続きを行う プロジェクト内で出たノウハウを記録する |
また、PMBOKのプロセスでは、10の知識エリアというものが存在します。これは、各プロセスからアプローチしていく対象のことを指しています。プロセスごとに対象となる知識エリアが異なります。
知識エリア | 概要 |
---|---|
統合 | プロジェクト管理計画書の作成やプロジェクトの遂行 |
スコープ | WBSの作成など |
資源 | 人員や機器などの資源を特定、管理 |
スケジュール | スケジュール計画や進捗管理 |
コスト | 予算の決定や管理 |
リスク | リスクの定義や監視 |
品質 | 品質の保証や管理 |
調達 | 発注先の選定やその管理 |
コミュニケーション | コミュニケーション計画、情報の配布 |
ステークホルダ | 利害関係者。影響される人。顧客や株主など |
これらを図にまとめると、このようになります。

立ち上げから始まり、プロジェクトの遂行中は基本的に実行と監視コントロールの繰り返し、必要があれば計画に戻る・・という流れになっています。PDCAサイクルがベースになっているようにも見えます。
ここから、知識エリアの一部を詳しく見ていきます。
スコープのマネジメント
プロジェクトスコープというのは、プロジェクトの”範囲”、すなわち「やんなきゃいけない作業」のことを指します。
ソフトウェア開発プロジェクトに必要な作業の範囲ってなんでしょう?要件定義、システム設計、プログラムの実装、テスト、、色々ありそうですよね。スコープマネジメントとは、こういうのを洗い出していくフェーズになります。
計画プロセスでは、必要となる作業を細分化し、分解していく作業を行います。このとき、WBS(Work Breakdown Structure)という作業一覧表を作成することが多く、WBSを作成すると作業の全体像が把握しやすくなり、ガントチャートと組み合わせて使われることが多いです。WBSでは、工数や担当者なども記載します。

スケジュールのマネジメント
スケジュールマネジメントの計画プロセスでは、作業の順序、必要日数などを見積もり、それを図で表したりする作業を行います。
ガントチャートは、スケジュールを横棒で表す図です。WBSと組み合わせて使われることが多いです。(「スコープのマネジメント」参照)
アローダイアグラム(PERT図)は、作業の順序関係を表す図です。
作業を線で表し、線の横には作業にかかる日数を記載します。また、関係のある作業の間に○を用いて結合点を作り、作業の段階を表します。

コストのマネジメント
計画プロセスにおけるコストマネジメントでは、費用の見積もりを行います。特に、ソフトウェア開発のコストマネジメントでは、COCOMOやファンクションポイント法という見積もり手法が存在します。
COCOMO:自社における過去の開発実績からプログラムの行数を見積もり、開発コストを算出します。
ファンクションポイント法:ソフトウェアに必要な機能数から開発コストを算出する手法です。機能を外部入力、外部出力、外部照会、内部論理ファイル、外部インターフェイスファイルの5つに分類し、それぞれの規模、難易度を加味してファンクションポイント数を算出します。
リスクのマネジメント
リスクと聞くと、マイナスなイメージを持つ方が殆どだと思いますが、実はそうでもありません。
予想外の良い結果を生み出す「プラスのリスク(機会)」と、予想外の悪い結果を生み出す「マイナスのリスク(脅威)」の2種類が存在します。
例えば、思ったより作業が円滑に進んでスケジュールが前倒しされるのは好機、作業に手戻りが発生し、スケジュールに遅れが生じるには脅威と捉えることができます。
これらのリスクを定義・対応策を決めるのが計画プロセス、リスクの管理を行うのが監視・コントロールプロセスとしてのリスクマネジメントになります。
また、リスクに対する対応戦略には次のようなものがあります。
■脅威に対する対応例(ソフトウェア開発プロジェクトの場合)
リスク対応戦略 | 内容 |
---|---|
回避 | 脅威を取り除く方法を考える。(例:スケジュールの遅れによる品質の低下を防ぐため、スケジュール期間を延長する。) |
転嫁 | リスクによる影響を第三者に移転させる。(ソフトウェアのバグで顧客に不利益を与えてしまった場合の保険に加入しておく) |
軽減 | リスクの発生頻度、影響を低くする。(従業員のミスを減らすために休憩をしっかり取らせる) |
■機会に対する対応例(ソフトウェア開発プロジェクトの場合)
リスク対応戦略 | 内容 |
---|---|
活用 | 機会を起こるようにするためのアプローチ。(ソフトウェア開発経験のある従業員を採用する) |
共有 | 機会を第三者と共有する。(新しい技術のノウハウを他社と共有する) |
強化 | 機会の発生頻度、影響を高くする。(技術勉強会を実施する) |
■機会・脅威に共通する対応
リスク対応戦略 | 内容 |
---|---|
受容 | 対策を行わず、リスクを受け入れる。リスク発生時のために予算や時間に余裕をもたせる。(コンティンジェンシー予備) |
コメント