プロジェクトとは
1. プロジェクトの意義と特徴
プロジェクトとは、特定の目標を達成するために行われる活動のことです。
例えば、「新しいシステムを開発する」「文化祭を成功させる」「家を建てる」といった活動がプロジェクトに該当します。
有期性（始まりと終わりがある）
必ず「開始日」と「終了日（目標達成日）」が決まっています。永遠には続きません。
独自性（毎回違う）
過去に全く同じ条件で行われたことはなく、毎回「新しい何か」を生み出します。
プロジェクトの対義語が定常業務（ルーチンワーク）です。
- 定常業務：毎日同じ作業を繰り返す（例：受付業務、工場のライン作業）。終わりがない。
- プロジェクト：特定の目標に向かって進む（例：新製品の開発）。目標達成で終わる。
2. プロジェクトの体制
プロジェクトを成功させるには、関わる人々（ステークホルダ）の協力が不可欠です。
| 役割 | 説明 |
|---|---|
| プロジェクトマネージャ (PM) |
プロジェクトの総責任者（リーダー）。 計画を立て、メンバーに指示を出し、進捗や予算を管理して、プロジェクトを成功に導く責任を持ちます。 |
| プロジェクトメンバー | PMの指示のもと、実際に作業（プログラミングや設計など）を行うチームの構成員。 |
| ステークホルダ |
プロジェクトに関わるすべての利害関係者のこと。 開発メンバーだけでなく、発注者（お客様）、経営者、システムの利用者、さらには協力会社なども含まれます。 |
ステークホルダごとに「システムに求めること」が違います（例：社長は安くしたい、現場は使いやすくしたい）。PMは、これらステークホルダの意見を調整し、全員が納得するゴールを目指す必要があります。
マネジメントのプロセス
1. プロジェクトマネジメントの流れ
プロジェクトマネジメントは、行き当たりばったりで行うのではなく、以下の5つの基本的なプロセス群（流れ）に沿って進めます。
2. プロジェクト憲章
「立ち上げ」のプロセスで作成される、プロジェクトの誕生証明書のようなものです。
プロジェクト憲章に書かれること
- プロジェクトの目的や背景
- プロジェクトマネージャ（PM）の任命と権限
- 大まかなスケジュールと予算
※試験ポイント：
「プロジェクトマネージャを正式に任命し、権限を与える文書」と聞かれたら「プロジェクト憲章」です。
プロジェクト管理手法
プロジェクトを成功させるには、限られた条件の中で目標を達成する必要があります。
特に、プロジェクトの3大制約と呼ばれる「スコープ（範囲）」「スケジュール（時間）」「コスト（費用）」は、互いに密接に関わり合っているため、PMはこれらをバランス良く管理しなければなりません。
1. プロジェクト統合マネジメント
スコープ、スケジュール、コストなど、様々な管理要素（知識エリア）を全体的に調整し、まとめる（統合する）管理プロセスです。
「あちらを立てればこちらが立たず」という状況（例：機能を増やすとコストが上がる）に対して、全体のバランスを見ながら最適な判断を下します。
- プロジェクト憲章の作成（立ち上げ）
- プロジェクトマネジメント計画書の作成（計画）
- 統合変更管理：プロジェクト途中の仕様変更などに対し、スケジュールやコストへの影響を評価して、承認・却下を判断する。
2. プロジェクトスコープマネジメント (WBS)
プロジェクトスコープマネジメントとは、プロジェクトで実施すべき作業の範囲（スコープ）を定義し、管理するプロセスです。
「何を作って（成果物スコープ）」「どんな作業をするか（プロジェクトスコープ）」を明確にし、「やるべきこと」と「やらなくていいこと」の境界線を引く管理です。
プロジェクト全体を、管理しやすい小さな作業単位（タスク）まで階層状に分解・細分化した図表（作業分解構成図）です。
「作業の抜け漏れ」を防ぐために作られます。
├── 1. 企画・準備
│ ├── 1.1 メニュー考案
│ └── 1.2 予算決定
├── 2. 調達
│ ├── 2.1 食材の買い出し（肉、野菜、ルー）
│ └── 2.2 機材のレンタル（鍋、コンロ）
└── 3. 当日運営
├── 3.1 調理
└── 3.2 接客・販売
開発の途中で「やっぱりこの機能も追加してほしい！」と新機能の追加が承認された場合、PMはスコープマネジメントの一環としてWBSを更新し、新しい作業範囲を明確にする必要があります。
勝手に作業を増やすと、スケジュールやコストの制約を圧迫してしまいます。
3. プロジェクトスケジュールマネジメント
WBSで洗い出した作業を「いつ・誰がやるか」スケジュールに落とし込み、進捗を管理します。
試験で頻出する2つの図法を覚えましょう。
横軸に時間、縦軸に作業項目（WBSのタスク）をとり、作業の開始〜終了を横棒（バー）で表した表。
メリット：全体の予定と現在の進捗が直感的にわかる。
デメリット：作業同士の依存関係（Aが終わらないとBが始められない等）が分かりにくい。
作業の順序や依存関係を矢印（アロー）と丸（ノード）でつないだネットワーク図。
メリット：作業の順序関係が明確。全体の期間に影響する最長ルート（クリティカルパス）を見つけやすい。
活用例：プロジェクト全体のスケジュール計算。
4. プロジェクトリスクマネジメント
プロジェクトに悪影響を与える「リスク（不確実な出来事）」を事前に予測し、対策を立てます。
情報セキュリティと同じように、リスクに対する対応策は以下の4つに分類されます。
| 対応策 | 内容 | 例え（野外イベントでの「雨」リスク） |
|---|---|---|
| 回避 | リスクの原因そのものを取り除く（発生確率を0にする） | そもそも「屋内」のイベント会場に変更する |
| 軽減 (低減) | リスクの発生確率や、起きたときの被害を小さくする | テントや雨具をあらかじめ準備しておく |
| 転嫁 (移転) | リスクによる損失の負担を、第三者に移す | 雨天中止に備えて「興行中止保険」に加入する |
| 受容 (保有) | あえて対策はせず、発生したらそのまま受け入れる | 雨が降ったら仕方ないと諦め、そのまま決行する |
5. プロジェクトコミュニケーションマネジメント
必要な情報が、必要な人に、適切なタイミングで伝わるようにする管理です。
活用例： 業務の進捗報告の仕方、定例会議の開催、社内チャットツールの導入など。
6. コストマネジメントと見積り手法
プロジェクトにかかる費用（コスト）を予算内に収めるための管理です。
特に、開発が始まる前に「いくらかかるか」を予測する見積りの手法が試験でよく問われます。
過去の似たようなプロジェクトの経験やデータをもとに、「だいたいこれくらいだろう」と予測する手法。
プロジェクトの初期段階で、短期間に概算（ざっくりとした金額）を出したいときに適しています。
WBSで分解した細かい作業単位ごとにコストを計算し、それを下から上へ積み上げて（合算して）全体のコストを出す手法。
時間はかかりますが、精度が高い（正確な）見積りが可能です。
システムの「機能（画面数や帳票数など）」に点数（ポイント）をつけて、その合計から規模やコストを計算する手法。
利用者（お客様）からも機能が見えやすいため、納得感を得やすいのが特徴です。
開発するソフトウェアの「コードの行数（Lines Of Code）」を基準にして見積もる手法。
プログラミング言語やプログラマのスキルによって行数が変わるため、近年は使われにくくなっています。
過去問演習（プロジェクトマネジメント）
プロジェクトにおいて，新規プロジェクトを正式に認可する文書として，適切なものはどれか。
- ステークホルダ登録簿
- プロジェクト憲章
- プロジェクトスコープ記述書
- リスク登録簿
システム開発プロジェクトで使用される技法のうち，スケジュール作成に用いる技法として，適切なものだけを全て挙げたものはどれか。
- a DFD(Data Flow Diagram)
- b 回帰分析
- c クリティカルパス法
- d プレシデンスダイアグラム法
- a，b
- a，d
- b，c
- c，d
システム開発のプロジェクトマネジメントにおけるWBSの説明として，最も適切なものはどれか。
- クリティカルパス上の作業を記載したものである。
- 主要な成果物に関する予定開始日と予定終了日を記載したものである。
- 全ての成果物を作成するための作業を階層的に分解して記載したものである。
- プロジェクトで使用するツールを記載したものである。
次のアローダイアグラムに基づき作業を行った結果，作業Dが2日遅延し，作業Fが3日前倒しで完了した。作業全体の所要日数は予定と比べてどれくらい変化したか。
- 3日遅延
- 1日前倒し
- 2日前倒し
- 3日前倒し
プロジェクトにおけるリスクマネジメントに関する記述として，最も適切なものはどれか。
- プロジェクトは期限が決まっているので，プロジェクト開始時点において全てのリスクを特定しなければならない。
- リスクが発生するとプロジェクトに問題が生じるので，リスクは全て回避するようにリスク対応策を計画する。
- リスク対応策の計画などのために，発生する確率と発生したときの影響度に基づいて，リスクに優先順位を付ける。
- リスクの対応に掛かる費用を抑えるために，リスク対応策はリスクが発生したときに都度計画する。
Aさんは新規プロジェクトの計画段階の作業をしており，開発コストの見積りに着手した。この段階で短期的に概算費用を見積もる方法として，最も適切なものはどれか。
- FP法を用いて見積もる。
- 作業単位のコストを見積もり，合算して全体を見積もる。
- 予想されるソフトウェアのコード行数を基に見積もる。
- 類似プロジェクトを参考に見積もる。