仕上げは AI との協働でやっています。事実と表現は著者本人が確認しています。
新人研修の開発演習でメンターをやっていると、 朝礼で同じ現象に何度も出会う。 マネージャー役の講師が 「進捗どうですか」 と聞いた瞬間、 受講者が視線を泳がせて固まる。 タスクは進んでいる。 何ならコードもそれなりに書けている。 でも何をどう答えればいいか分からない。 「えーと、 進んでます」 「たぶん大丈夫だと思います」 — 沈黙を埋めるために選んだ言葉が、 結果として 「何も伝わらない報告」 になってしまう。
これは性格や度胸の問題ではない。 進捗を説明するための語彙が用意されていない ことに原因がある。 そして実は、 その語彙こそが ITパスポートのマネジメント章で扱う PMBOK の中身そのものだ。 試験では用語を覚えるだけで終わってしまうので 「現場で使える状態」 にならないが、 開発演習という具体的な場と結びつけて整理すると、 PMBOK の語彙が一気に手触りを持つ。
ある日の朝礼 (再現)
ある研修プログラムの 5 日目、 受講者がチームで Web アプリを実装する開発演習の真っ最中。 各チームに 1 人ずつメンターが付いていて、 朝礼でその日の進捗確認をする運用だった。
マネージャー役 (講師) が受講者 A に聞く。
講師: 「A さん、 ログイン機能の実装どうですか」
A: 「えーと、 進めてます」
講師: 「予定通りですか?」
A: 「たぶん、 大丈夫だと思います」
講師: 「OK、 次 B さん」
これでは進捗が何も分からない。 進んでいるのか、 遅れているのか、 どこまで完了しているのか、 残りどれくらいかかるのか。 講師側からすると 「OK、 次」 と打ち切るしかないが、 内心では 「これ、 当日中に終わらない側のパターンだな」 と察している。 そして実際、 当日終わらない。
PMBOK の語彙を借りると、 この場面はこう答えられる構造になっている。
A: 「ログイン機能は、 計画では昨日中に完了予定で、 現在 70% 完了です。
ただし JWT のリフレッシュトークン仕様が当初想定と違うことが分かったので、 残作業の見積もりを 半日 → 1日 に修正しました」
何が変わったかを分解すると:
- 計画 (= ベースライン) を明示している (= 昨日中に完了予定)
- 進捗の数値化 をしている (= 70% 完了)
- 見積もりの修正 を申告している (= JWT 仕様で半日 → 1日)
この 3 つが揃うと、 講師側はリスクを判定できる。 「予定通り進んでいる」「予定より遅れている」「予定より早い」 のどれかを共有できる状態になり、 必要なら 「じゃあ B さんと C さんで分担して」 「リフレッシュトークンは省略しよう」 等の判断ができる。 進捗を語る目的は、 安心させることではなく 次のアクションを決められる状態を作ること にある。
なぜ受講者は固まるのか
開発演習の受講者を見ていて気付いたのは、 固まるパターンには 3 種類あるということだ。
1 つ目は、 計画 (ベースライン) を持っていない パターン。 「とりあえず始めて、 出来上がったら出来上がり」 で進めていて、 「いつまでに何が終わっているはず」 が頭の中にない。 比較対象がないので 「予定通り」 「遅れている」 を判定できない。
2 つ目は、 進捗を数値化していない パターン。 「進めてます」 と感覚で答える。 実装を 「ログイン画面 / 認証 API / セッション管理 / リフレッシュ」 のように分解していれば、 何個終わったかで言える。 分解していないと 「進めてます」 以上の解像度が出せない。
3 つ目は、 悪い情報を出すと怒られると思っている パターン。 「遅れています」 と言うと評価が下がる、 という認識が先に立って、 「順調です」 を選んでしまう。 これは語彙の問題ではなく心理的安全性の問題だが、 PMBOK の語彙でフラットに語れると 「遅れている」 を非難ではなく事実報告として出しやすくなる、 という副次的な効果がある。
研修現場では、 この 3 つを 1 個ずつ崩していくと、 朝礼の答え方が劇的に変わる。
PMBOK の中で何が起きているか
PMBOK ガイドの第6版までは、 10 個の知識エリアと 5 つのプロセス群でプロジェクトマネジメントを整理する構成になっていた。 ITパスポートのシラバスもこの第6版ベースで作られているので、 試験対策としてはまずこの 10 エリアを押さえることになる (※第7版 (2021年) で構造は大きく変わり、 8 つのパフォーマンス領域 + 12 のプロジェクト原則という整理になったが、 現時点のITパスポートシラバスは第6版の枠組みを引きずっているため、 ここでは第6版の語彙で書いていく)。
試験では各エリアの名前を覚えさせられるのだが、 開発演習の現場で使うときには 何の管理をしているか で見た方が掴みやすい。
| 知識エリア | 開発演習の現場で出てくる場面 |
|---|---|
| スコープ管理 | 「ログイン画面のデザインまで作る? それとも認証だけ?」 |
| スケジュール管理 | 「Day 5 終わりまでに動くものを出す」 という締め切り管理 |
| コスト管理 | 演習では時間がコスト。 「何時間使ったか」 で測る |
| 品質管理 | 「動けば OK か、 テストまで書いたら OK か」 の完了基準 |
| 資源管理 | チーム 4 人のうち、 誰がどの担当か |
| コミュニケーション管理 | 朝礼で何を共有するか・Slack でどこに書くか |
| リスク管理 | 「JWT の仕様分からない」 を朝礼で出すか抱えるか |
| 調達管理 | 演習では使わないが、 実務では「外注に出すか」 |
| ステークホルダー管理 | 講師 / 同じチームのメンバー / 他チーム |
| 統合管理 | 上記を全部まとめてプロジェクトを成立させる |
朝礼の進捗報告は、 主に スケジュール管理 + スコープ管理 + リスク管理 の交差点にある。 「予定からのズレ」 (スケジュール) と 「作業範囲のズレ」 (スコープ) と 「これから起こりそうな問題」 (リスク) を共有する場、 という位置付けになる。
受講者が朝礼で固まるのは、 この 3 つを区別する語彙を持っていないからだ。 講師が 「進捗どうですか」 と聞いたとき、 その質問は実は 「スケジュール上のズレは? スコープに変更は? リスクは顕在化した?」 という 3 つの質問を 1 つにまとめたものだったりする。 受け取る側はそれを分解できないと答えようがない。
EVM: 進捗を数字で語る仕組み
進捗を数字で語ろうとすると、 EVM (Earned Value Management) という考え方が出てくる。 ITパスポートでも EVM は出題されるが、 用語が抽象的で頭に残りにくい。 開発演習の場面に置くと一気にイメージしやすくなる。
3 つの数字を覚えると EVM が掴める。 5 日間の開発演習で、 3 日目の朝礼を想定する。 計画全体の予算 (= 作業量) を仮に 100 とおいて考える。
| 用語 | 意味 | 開発演習 (5日コース・3日目朝) での具体例 |
|---|---|---|
| PV (Planned Value) | 計画上、 今日までに完了しているはずの作業量 | 3 日目朝 = 全体の 50 (= 半分終わっているはず) |
| EV (Earned Value) | 実際に今日までに完了している作業量 | 実際は 40 (= 40% しか終わっていない) |
| AC (Actual Cost) | 今日までに実際に使った作業時間 (= かけたコスト) | 計画では 50 で済むはずだったところ、 実際は 55 使った |
この 3 つから判定できることが 2 つある。
SV (Schedule Variance) = EV - PV = 40 - 50 = -10
→ マイナスなのでスケジュール遅延
CV (Cost Variance) = EV - AC = 40 - 55 = -15
→ マイナスなのでコスト超過 (= 進んだ量より使った時間の方が多い)
ざっくり言うと、 計画より作業が遅れていて、 しかも使った時間は多い という状態が、 数字で明確になる。 朝礼で 「進めてます」 と答えていたものが、 EVM の語彙だと 「SV が -10 でスケジュール遅延、 CV が -15 でコスト超過の状態です」 と説明できるようになる。
なお、 厳密には EVM の 3 つの値はすべて 「同じ単位 (金額または工数)」 で揃えて計算する必要がある。 ITパスポート試験でもこの 「同じ単位で揃える」 の作法が問われることが多い。 ここでは単位を 100 ベースに正規化して書いている。
PMBOK 試験で問われるのは数式の方だが、 現場で使うときには 数字で語れる枠組みがある こと自体が効く。 数字で語ると、 主観 (進んでいる気がする) と客観 (40 しか終わっていない) のズレが見えるからだ。 開発演習の受講者にとっては、 自分の体感と実績のズレを発見するツールになる。
朝礼で答えるためのテンプレ
研修受講者にこれを渡すと、 翌日から朝礼の答え方がはっきり変わる、 というテンプレがある。 3 つの要素で構成する。
[ 現在の進捗 ]
- 計画では今日までに ◯ % 完了予定
- 実績は ◯ % 完了
[ 残作業の見積もり ]
- 当初想定: ◯ 時間
- 現在の見積もり: ◯ 時間 (変更があれば理由も)
[ リスクと前提 ]
- 進める上で気になっていること (= 顕在化前のリスク)
- 前提が崩れた場合の影響
このテンプレで答えると、 講師側は判断できる。 「予定通り」 と聞いて安心するのではなく、 ズレと前提を共有することで、 「じゃあリフレッシュトークンは省略していい」 「他の人にヘルプ入ってもらおう」 等の調整が早く打てる、 という状態になる。
受講者にとっても効くポイントがある。 このテンプレで答えるためには、 朝礼前に 自分の進捗を分解して計算する という作業が必要になる。 それをやると、 朝礼に向かう前の段階で 「あれ、 思ったより遅れてる」 「JWT の仕様、 確認しておかないとマズいな」 と自分で気付ける。 朝礼が報告の場であると同時に、 自分の進捗を点検する強制装置になる。
マネジメント章で混ざりやすい用語
ITパスポートのマネジメント章では、 似た用語が混ざりやすい場所が 3 つある。 開発演習の場面と紐付けて整理する。
| 用語ペア | 違いの軸 | 開発演習での具体例 |
|---|---|---|
| スコープ管理 vs 品質管理 | スコープ = 何を作るか / 品質 = どの基準で完了とするか | 「ログイン画面まで作る」 がスコープ、 「テストまで書く」 が品質基準 |
| クリティカルパス vs クラッシング | クリティカルパス = 最長経路の特定 / クラッシング = 資源追加で短縮 | DB 設計 → API → 画面の順で並んでいて DB が遅れると全部遅れる = クリティカルパス。 そこに他メンバーを投入して短縮 = クラッシング |
| WBS vs ガントチャート | WBS = 作業の階層分解 / ガントチャート = スケジュールの時系列表示 | 「ログイン機能 → 認証API → セッション管理 → リフレッシュ」 が WBS、 各タスクの開始 〜 終了を横棒で並べたのがガントチャート |
特に 「スコープ」 と 「品質」 は混ざりやすい。 スコープは 「何を作るか・作らないか」 のリストで、 品質は 「作ったものが基準を満たしているか」 の判定だ。 別の軸で見ているので、 試験ではセットで聞かれることがある。
開発演習で言えば、 「ログイン画面まで作る」 と決めたのがスコープで、 「画面はそこそこ動けば OK」 「テストカバレッジ 80% まで書く」 等の基準を決めるのが品質だ。 スコープを広げすぎると品質まで手が回らない、 スコープを絞ると品質に時間を使える、 というトレードオフが見えてくる。
振り返って
PMBOK は試験用語の塊として覚えると頭に残らない。 でも、 朝礼で詰まる場面・チームで進捗を合わせる場面・期限が近付いて焦る場面、 という具体的なシーンと結びつけると、 「進捗を語るための語彙」 として体に残る。
研修でメンターをやっていて思うのは、 PMBOK の知識は 語彙の差ではなく、 問いの解像度の差 を作っているということだ。 「進捗どうですか」 を 「スケジュール上のズレと、 スコープ変更と、 リスクの顕在化を教えてください」 と分解できる人と、 そのままの粒度で受け取って固まる人の差は、 仕事ができる・できないの差ではなく、 質問を分解する語彙を持っているかどうかの差でしかない。
ITパスポート の試験範囲は、 実務で 「説明可能な状態」 を作るための足場として、 後で効いてくる知識だと思っている。 試験対策の段階でも、 用語を覚えるだけでなく 「現場のどの場面で使うか」 をセットで持っておくと、 後で繋がる。 研修現場でこの繋がりを実感する瞬間が、 メンター側の役得でもある。