【大公開】現役SEが作成したPMP合格メモから抜粋 〜アジャイル編〜

キャリアアップ（転職・昇進）のために
PMP（Project Management Professional）の資格取得を目指す。

でも、なかなか合格できない。
これ1冊やればいい、というような参考書もないし。

そんな方々のために朗報です！

この記事では現役システムエンジニアが、
PMP合格のために作っていた勉強メモから特別にご紹介します。

PMP（Project Management Professional）とは？

世界的に知名度の高い、プロジェクトマネジメントに関する資格

米国で設立されたプロジェクトマネジメント協会（PMI）
が認定するマネジメントの認定資格のことですが、
米国内だけではなく世界的に知名度の高い資格です。

PMPの資格を取得すると新規事業の立ち上げや新製品の開発など、
「プロジェクトが円滑に進むようマネジメントする能力」
を持っているという証明になります。

つまり、今後のキャリアアップも狙えます。

PMPの合格体験記を別記事にしておりますので、よかったらご一読ください。

実務経験だけでPMP合格は難しい

PMPは実務経験があれば余裕で合格できるものではない。
参考書暗記すれば合格できるものでもない。

現役システムエンジニアである私だからこそ言えます。

例えば、プロジェクトでトラブルが発覚したとき、
まず以下のどちらの行動をとりますか？

①上位のプロジェクトマネージャに報告、相談する
②プロジェクトマネージャ自身（＝あなた）が対策検討する

PMPでは②が正解です。

PMPに合格するための知識と、
PMPに合格するための実務経験があれば、
合格に限りなく近づく。

これが事実。

実務で得たプロジェクトマネジメントの知識も経験も、
PMP合格のためにカスタマイズしないといけないんです。

筆者の勉強メモを特別公開！

PMP合格に必須なのはアジャイル関連の知識だが…

3つの記事の内容でかなりカバーできるようにしました。
初級編の記事へのリンクを貼っておきます。

ですが、これらの記事で得られる知識だけでは
”果たして合格できるのか不安”と思ってもしょうがない。

ではどうやって知識を得るか？

参考書読んだり、演習問題解いたり、色々試して見た結果、

• 参考書だと不要な情報が多い
• 参考書は無駄にページ数が多い
• そもそも参考書の内容、PMP試験に対応できてない
• 演習問題は全然アジャイルに対応してない
• 演習問題は本番試験の形式に程遠い

と思ったので、

▶︎これが頭に入ってれば、本番試験でもなんとか対応できるだろう。

というメモを独自に作りました。

実際、試験前にこの勉強メモを見るだけでも
とても良い復習になりました。

—–

そんな勉強メモから、皆さまへ「これは知って損はない！」
という内容を抜粋して、今回以降の記事でご紹介します！

「知って損はない」知識集 〜アジャイル編〜

予測型とアジャイル型のプロジェクト・ライフサイクルの違い

	予測型	アジャイル型
要求事項と納品	要求事項を予め定義し、終結時に完成プロダクトを納品する	要求事項を顧客価値で頻繁に再構成し、都度納品する
変更管理	変更はできるだけ制限する	納品の際にリアルタイムで変更が行われる
ステークホルダー	特定のマイルストーンで主要なステークホルダーが関与する	主要なステークホルダーが連続的に関与する
リスクとコスト管理	リスクとコストを詳細に計画してコントロールする	要求事項と制限事項が出てきた際にコントロールする

ハイブリッドプロジェクトでの進捗遅延

予測型プロジェクトのほうに進捗遅延が発生した場合も、
アジャイル型プロジェクトは、予測型に進捗を合わせにいくべきではない。

どちらのプロジェクトもマイルストーンが決まっていて、
共通のマイルストーンまでに進捗リカバリすれば問題ない。

MVPとMBIの違い

どちらもユーザに必要最小限の価値（製品、機能など）を提供するものだが、

• 最小限の実行可能なプロダクト（Minimum Viable Product）
  
  「新製品が実行可能かどうか、そしてそれがどうあるべきか」
  を発見することを目的としている（発見のための投資）。
  
• 最小限のビジネス増分（Minimum Business Increments）
  
  既存市場を中心として展開し、
  投資収益率を上げることを目的としている（収益のための投資）。
  
  新たな付加価値を顧客に提供できているか、
  構築されているかをフィードバックし、有用性を検証できる。

トラブルが発生したときに、まずすべきこと

• トラブルの状況確認

• トラブルの原因分析

アジャイル型のプロジェクトでは、
原因分析よりも、状況確認してプロダクトバックログを更新することが優先される。

なお、そのトラブルはPJチームで解決する。
スクラムマスターは解決を促すだけ。明確な解決策を示したりはしない。

リスク顕在化の予兆があるときの、タスクの流れ

• メンバー：リスク登録簿に記載のリスク対応策の実施
• メンバー：変更要求
• メンバー・PM
  ：リスク特定、評価（リスク管理簿の更新も兼ねる）
  ：スパイクの実施（技術的な実現性検討）
• メンバー：変更要求
• PM：承認
• メンバー：バックログの更新（優先順位の見直し）
• メンバー：承認された対策の実施
  メンバー：根本原因分析

まずはリスク登録簿を確認。
リスク登録簿に記載があれば、記載のリスク対応策の実施を、
記載がなければリスクの特定から順次実施。

管理簿に変更が入る場合は変更要求が必要。
そして変更要求の承認プロセスがないとリスク対策の実施などに踏み切れない。

スプリントで実行するタスクの洗い出しをするひと

スプリントバックログは「開発者による、開発者のための計画」。

そのスプリントで必要なタスクの洗い出しや
担当者の割り当てはPJチームのメンバーが主体的におこなう。

プロダクトオーナー、スクラムマスターのいずれでもない。

SOS（スクラムのスクラム）とは

• 2つ以上のスクラム（≒PJチーム）が代表者を出し合い、
  互いにスプリントの作業内容や状況を共有すること。

• スクラム（≒PJチーム）内に、さらに小さくスクラムを組んで
  作業を進めること。

1つの大きなスクラムでは統制が取れない場合に、スクラムを分けることがある。
SOSはスクラムを分割することではない。

全てのスクラムが効果的に作業を進め、
時には他のスクラムのサポートができるようにするのが大きなメリット。

2つのアジャイルミーティングを1つにまとめる場合

まとめることが適切と、PJチーム全体で判断した場合にまとめることができる。
例えば「レトロスペクティブ」と「スプリントプランニング」を1つに集約できる。

ただし、「スプリントレベルの計画」と「戦略レベルの計画」など、
レベルが異なるミーティングの組合せでは集約してはいけない。

　　例）
　　・リリース計画とデイリースクラム
　　・ポートフォリオ計画とレトロスペクティブ
　　・戦略的な計画とスプリントレビュー

DevOpsで重要なこと

運用チームと開発チームが連携して協力する開発手法のこと。

アジャイル型のプロジェクトに求められる
・ソフトウェアの迅速なビルドとテスト
・確実で頻繁なリリース

これらを実現するために、以下の3つが重要
　・運用チームと開発チームが継続的に協力
　・両チーム間の自動化
　・そのためのツール導入や環境整備

ペアプログラミングのメリット

ペアプログラミングでは多くの場合、知識の共有がメリットと言われるが、
実はそれだけでなく、精神的な負担を分かち合うことができることも超重要。

　・互いにソースコードを確認することでバグを減らすことができる
　・ソースコードだけでなく、暗黙知の知識を共有できる
　・当該ソースコードに関する詳細を知るひとが増え、メンバが離脱したときの苦労が減る
　・スキルレベルが低いメンバーの作業効率を上げることができる
　・経験の少ない若手社員の場合、孤立感を減らすことができる

各ペアが技術力もチームワークも向上したとき、
チームとしての生産性が上がる。

ベロシティの活用方法

ベロシティ：1スプリントにチームが消化したポイントの合計のこと。
ポイントはアクティビティごとに割り当てられている。

ベロシティは以下の用途で使用する。
　・次のスプリントでどれくらい進められそうか検討する際の参考値
　・開発完了見込み時期を割り出すための参考値
　・チームの成長度合いを把握するための参考値
　　ベロシティが安定ないし上昇傾向にある場合、チームが成長しているという定量的証拠。

ハイリスクな機能を開発するタイミング

要件が難しいなど、ハイリスクな機能は
プロジェクトの初期段階で開発されるようにスケジュールすべき。

そもそもアジャイル開発では短いサイクルでリリースし、
ユーザからのフィードバックから改善していく手法。

そのため、ハイリスクな機能を初期段階で開発すれば
機能改善する時間も多く確保できる。

キーとなる要員がチームから抜ける場合にすべきこと

まずチームのモチベーションを保つこと。

そして、スコープの縮小やスケジュールの延長ができない場合、
同等のスキルを持った要員を追加するために、どのような変更が必要かを確認する。

”とりあえず要員確保”はNG。

アジャイル手法に慣れてないメンバーがいる場合にすべきこと

最もコスト効率の高いトレーニングを明確にする。

そして、そのメンバーをトレーニングしてチーム内のスキルを均一にする。

サーバントリーダーが忙しくてもすべきこと

サーバントリーダーが他プロジェクトを兼務していて、
かつプロジェクト初期にコチラのプロジェクトに入れない場合、

サーバントリーダーは直接関われないにしても、
メンバーたちが自発的に動けるよう、
チーム内で打ち解けた関係を築いてチームの結束を促す。

まとめ

今回はPMP（Project Management Professional）合格に向けて
「合格のために覚えておいて損はないこと」をまとめてご紹介しました。

今回はアジャイル編です。

アジャイルはPMP試験で大部分を占めるので、
もはや暗記しておいて損はないです。

まだまだご紹介できる内容はあるので、
別記事で公開していこうと思います。