『プロジェクトマネジメントの基本が全部わかる本』を読んで学んだPMの本質とは「管理」ではなく「調整」である
『プロジェクトマネジメントの基本が全部わかる本』を読んで学んだPMの本質とは「管理」ではなく「調整」である
はじめに
プロジェクトマネージャー（PM）の業務を担当することになり、実際の現場でタスク管理に追われる日々を送る中で、「本当にこれがPMの仕事なのか？」という疑問を感じるようになりました。そんな時に手に取ったのが本書です。
読了後、PMの本質はタスク管理ではなく、プロジェクトを適切にゴールに向かわせるための「調整」であることを理解できました。また、QCD（品質・コスト・納期）のバランス感覚や、ステークホルダー間の利害調整の重要性についても深く学ぶことができました。
注記: 本記事は人間が読書で得た要点をまとめ、AIが文章を整理・補強して作成しています。
本書の概要
タイトル: プロジェクトマネジメントの基本が全部わかる本
内容: PMに必要なスキルセットから実際の各フェーズでの具体的な対応方法まで、プロジェクトマネジメントの全体像を網羅的に解説した実践的な入門書
主な気づき
1. PMに必要なスキルセットは6つの領域に体系化されている
本書では、PMに求められるスキルを以下の6つのカテゴリーに整理し、各領域で具体的に必要なスキルを明示しています：
交渉スキル
- 提案／合意形成: 各フェーズで必要な提案を行い、フィードバックを取りまとめて合意形成を行う
- QCDの調整: 発生しそうなリスクや対応コストを説明し、品質／予算／納期の調整を行う
- ステークホルダーの利害調整: 関係者の利害調整を行う
タスクマネジメントスキル
- プロジェクト全体像の共有: メンバーに要件定義を含意したプロジェクトの全体像を伝える
- タスクの洗い出し: プロジェクトを遂行するために必要なタスクを洗い出す
- 優先順位: タスクを実行するうえで必要な優先順位の調整を行う
- 進捗把握: 各メンバーのタスクの進捗状況をリアルタイムに把握する
- 振り返りと見直し: KPTなど、プロジェクトで都度振り返りを行う
プロジェクト計画スキル
- 座組の整理: 関係者の役割分担や意思決定のプロセスを整理する
- プロジェクトリスクの整理: プロジェクトを実施するにあたって想定されるリスクを洗い出して関係者に共有する
- 適切な開発手法の選定: プロジェクト要件を満たすために適切な開発手法を選定する
なぜこれが重要か: これらのスキルセットを明確に理解することで、PM業務の全体像を把握し、自身が強化すべき領域を特定できます。多くの人が「PMはタスク管理をする人」という認識を持ちがちですが、実際は事業成功に向けた総合的な調整役であることがわかります。
2. QCDの優先順位を事前に決めることの本質的重要性
品質（Quality）、コスト（Cost）、納期（Delivery）は常にトレードオフの関係にあり、すべてを同時に最大化することは不可能です。特に品質を最優先にするかどうかの判断は、プロジェクトの方向性を決定づけます。
実践的アプローチ:
- プロジェクト開始時に、QCDの中でどれを最優先するかをステークホルダー間で合意形成
- 追加要求が発生した際は、QCDへの影響を必ず説明してから対応を検討
- 「品質優先なら納期延長もやむなし」など、具体的な判断基準を設定
要求受け入れ時の対応: 要求者は追加機能の影響を理解していないことが多いため、要求を受け入れる際に「それがQCDにどう影響するか」を必ず説明することが重要です。後から「それなら要求は言わなかった」というケースを避けられます。
3. 「プロジェクトは最初が肝心」の具体的な実践方法
座組みなど初期設定でつまづくと、問題が雪だるま式に拡大していくという指摘は、多くのPMが経験する課題です。
関係者同士で平等に話し合える関係の構築: 発注者が上でベンダーが下のような構図にならず、意見が述べやすい関係にし、全員でプロジェクトを完遂することを目標とすることが重要です。
具体的な対策:
- 意思決定フローの明確化: 誰が最終決定者で、どのような手順で承認を得るかを事前に定義。決定者が多忙で遅延しないよう配慮
- 情報共有の仕組み作り: 会議体や報告フォーマットを初期段階で確立
- マイルストーンの設定: いつどの時点で何を共有するかを決めることで、ステークホルダーへの進捗報告の手間を削減
4. PMを多忙な環境にしないことがプロジェクト成功の鍵
PMのメンタルや作業負荷がおかしくなると、プロジェクトの管理が行き届かず、当初の予定通りに進まなくなります。
実践的対策:
- 無理がないよう、無理なタスクは次回に回すべき
- PMが全てを抱え込まず、適切にタスクを分散する
- 定期的な負荷チェックと調整の仕組みを構築
補足: これは多くのPMが陥りがちな問題で、「自分が頑張れば何とかなる」という考えがプロジェクト全体を危険にさらすことを理解する必要があります。
5. 外部連携システムの工数は「甘く見積もらない」
API連携など、既存のサービスを活用する場合、「すでに作られているもの」だからと見積もりを甘くすると、思わぬ工数を取られることが多々あります。
よくある問題:
- 正常に動作しない場合の対応
- 作り込みが甘く、こちらが追加で実装を求められる
- サポートが遅い
実践的対策: 外部連携部分には通常の1.5〜2倍の工数を見積もり、事前検証期間を必ず設ける
6. 一部ユーザーの意見を聞きすぎることの危険性
ユーザーの声を聴きすぎてしまい、一部の意見を入れたばかりに、後々問題になったり、作ったものの使われないケースがあります。
対策のポイント:
- 要求の背景にある本当のニーズを見極める
- 全体のユーザー層を考慮した判断を行う
- 「本当にそれが必要か」を常に問い続ける姿勢
実践的アプローチ: 要求を受けた際は、その要求が解決したい課題と、想定される利用者の範囲を必ず確認することが重要です。
7. 交渉における「完璧主義になりすぎない」マインドセット
多数のステークホルダーが関わるプロジェクトでは、様々な意見が出るため、それをすべて聞き入れて100点にすることはほぼ不可能です。
実践的マインドセット:
- 80点を取れたら良しとする判断力: 完璧にできなかったと落ち込まず、「80点取れたらまぁいいだろう」のマインドで進行
- 無理なものは無理と伝える勇気: 上の意見は絶対だと思い込まず、無理なものは無理と伝え、妥協案や代替案を提示
- 定期的なヒアリング機会の設定: 作業期間が長くなると依頼者の意見が変わったり、下に降りていない話が進んでいるケースがあるため
8. 情報共有と合意形成の仕組み化
資料準備の徹底: 共有会などでは必ず資料を用意し、MTGの前には事前資料、その後に議事録を作成すべきです。
なぜ重要か:
- 打合せでは資料があれば進行がしやすくなる
- 齟齬がなくなる
- 議事録があることで水掛け論がなくなり、「ちゃぶ台返し」を防げる
会議の効率化: 会議は必要最低限かつ必要最低限の時間に絞り、事前に資料を準備しておくなど、会議時間をなるべくかけないよう心がけることが重要です。
9. 信頼関係と「仲の良さ」の違いを理解する
プロジェクトをチームで進めていく際に信頼関係があるほうが業務は円滑に進みますが、なれ合いになっている場合はかえって進行を阻害するケースがあります。
具体例: プロジェクトのことを思い行動すべきなのに、人間関係を優先して行動してしまうケース
実践的対策: プロフェッショナルな信頼関係の構築を心がけ、個人的な関係性とプロジェクト上の判断を明確に分ける
10. タスクマネジメントの本質を理解する
重要な認識: タスクマネジメントはタスク管理ではありません。PMの作業はタスクの管理だと思われることもありますが、メインはプロジェクトが適切にゴールに向かうよう調整するのが仕事です。
具体的な実践方法:
タスクの洗い出しと管理
- 各フェーズで何を誰がいつまでに対応するか、すべて洗い出す
- タスク名は「○○を○○する」という形で明確化
- 期間は「何時間で完了」として見積もる（「何日までに」ではなく）
期間見積もりの理由: 「何日までに」で見積もると、途中で問題が発生した際にすべてを調整し直さなければならないため、時間ベースでの見積もりが効果的です。
優先順位付けの手法
- クリティカルパス法の活用: ガントチャートとは違い、優先すべきことを順番に、また正しい工数を導きやすくなります
- ガントチャートに頼りすぎない: ガントチャートを作るとそれっぽいスケジュールが見えるため安心してしまいますが、更新されないままでいると、本来のスケジュールとの乖離が生まれる危険性があります
タスクアサインの重要ポイント
- タスクの背景説明: タスクを依頼する際には背景の説明がないと、作業者が自分で考えを出せないうえ、歯車感が出てしまいます
- 定期的な進捗確認: アサインされたばかりでシステムのことをあまり知らない人の場合、思いもよらない方向に進行している場合があるので軌道修正が必要
11. 振り返り（KPT法）の継続的実施
KPT法で良かったこと（Keep）、改善していきたいこと（Problem）、今後チャレンジしたいこと（Try）を振り返ることで、全体の認識共有や次回への経験の活用が可能になります。
実装のコツ:
- 各フェーズ終了時に必ず実施
- 全メンバーが率直に意見を言える環境作り
- 改善アクションを具体的に決めて次回に活かす
12. プロジェクト計画における効率的なヒアリング
目的、前提条件、座組、意思決定者、利害関係者、予算、スケジュール、具体的にやりたいことなどは、打合せで定期的に確認する必要があります。
なぜ定期的な確認が必要か: 初期に決まっていない部分などもあるため、特に目的や前提条件など、後から変えることが難しいことから聞いていくことが重要です。
ベンダー選びの原則: 少なくとも3〜4社から相見積もりを取ることで、適切な判断材料を確保できます。
13. 見積もりの「不確実性コーン」を理解し活用する
プロジェクト初期の見積もりは本質的に不正確であり、進行とともに精度が向上していくという概念です。
実践での活用方法:
- 概算見積もりの扱い: 不確実性コーンのグラフで言う一番左の時期なので、必ずバッファを持った見積もりにする
- ざっくり見積もりを外部に共有しない: 数字が独り歩きを始め、思わぬ工数で作業をしなければならないケースに陥るため
- 詳細見積もりの手法: 1,3,5,10,15という5刻みで見積もることで、自然とバッファが生まれる
- 全体バッファの設定: さらに1.2〜1.5の係数をかけてプロジェクト全体のバッファを持つ
利用可能な見積もり手法: パラメトリック見積もり、三点見積もり法、類推見積もり、ボトムアップ見積もりなどを使い分ける
14. 契約面での重要な確認事項
契約形態の理解
- 請負契約と準委任契約の把握: 契約形態により責任や成果物の範囲などが変わってくるため、ベンダーを雇う場合はどちらの契約かを判断しておく
- 偽装請負の確認: 法的リスクを避けるため、偽装請負になっていないかも確認が必要
損害賠償の項目確認
もし青天井になっていれば上限を必ずつけてもらうことで、リスクを限定できます。
15. 要件定義における要求と要件の切り分け
まず何をしたいかを「要求」としてヒアリングして、それを「要件」に落とし込む作業が重要です。
なぜ重要か: もし混同していたら、「言ったのにやってくれていない」という問題につながるため、明確に切り分けておく必要があります。
実現方法のまとめ: 要件が定まった後、システムアーキテクチャ、機能要件一覧、画面遷移図、シーケンス図、ER図・テーブル定義書、API一覧などを作成して実現方法を模索します。
要件定義での注意点
- 要件定義書の作成ツール: スライドツールでは表現のサイズに制限があるため、他のツールを使って図を用いてわかりやすい表現でステークホルダーに要件の内容を伝えるべき
- 法律・社会ルールの確認: 叶えたい要件について必ず法律に準拠しているか、また社会のルールに逸脱していないか事前に調べる必要がある
16. 設計段階での品質確保
開発の作法を整える
ソースコード管理、コード規約、開発環境、デプロイ方法、コンテナ、使用ツールなどの決め事はしっかり決めておく必要があります。特にコード規約は品質に関わってくる部分となります。
設計書レビューの体系的実施
本書では、設計書レビューで確認すべき観点を以下のように体系化しています：
全般・機能要件:
- 機能要件が適切にハンドリングされているか
- 正常系／異常系（エラーハンドリング）が適切に設計されているか
性能・セキュリティ:
- 設計上性能要件が満たされているか
- セキュリティに留意した仕様になっているか（認証、暗号化、脆弱性対策等）
インフラ・データベース:
- インフラが適切に設計されているか
- DBスキーマが効率的かつ網羅的に設計されているか
API・アプリケーション:
- APIが適切に設計されているか
- バリデーション（入力チェック）が適切に設計されているか
17. テストの重要性と体系的な実施
テストの工数配分
テストは成果物を生み出さないため削られがちですが、全体の工数の3割はテストに費やした方が良いとされています。リスクを減らすために欠かせないものです。
ソフトウェアテストの7原則
特に重要な原則として以下が挙げられます：
- テストは「欠陥がある」ことしか示せない
- 全数テストは不可能
- 早期テストで時間とコストを節約
- 「バグゼロ」の落とし穴
実践的理解: 全数テストは実質不可能のため、バグが0のシステムを作ることは困難または納期によってはそのリスクも高まることを理解してもらわなければいけません。
各種テストの実施
ユーザビリティテスト、クリエイティブチェック、単体テスト・結合テスト、リグレッションテスト、総合テスト、連携テスト、負荷テスト、脆弱性テスト、受け入れテストなどを体系的に実施します。
テストマネジメント: テストは各々が報告するにあたって、それが類似しているのか、また解決済なのかなど、テスト全体を取りまとめる人が必ず必要になります。
18. リリースと保守における現実的な対応
リリース時の不確実性への対応
本番リリースにあたって、100%問題ないと断言できるのは難しいため、思いもよらない本番だけの問題等もあったりするので、リリース日には必ず対応できる人がいる状態で行うべきです。
事業観点での継続的な評価
- 損益分岐点の考慮: リリースして終了ではなく、事業としてこのプロジェクトの損益分岐点が必ず測れるようにしておく
- 死の谷への対処: リリース当初はどうしても売り上げが立たないものなので、ファネルモデルを用いて今がどの状態か認識していくとよい
本書の感想
良かった点
- 体系的なスキル整理: PMに必要なスキルセットが6つの領域に体系化され、各領域で具体的に何をすべきかが明確に示されている
- 実践的な問題への対処法: 現場で直面する具体的な問題（外部連携の工数見積もり、ユーザー要求への対応等）とその対処法が豊富
- テーブル形式の整理: スキルセットやチェックリストが表形式で整理されており、実務での参照が容易
- バランス感覚の習得: QCDの調整や完璧主義に陥らないマインドセット、80点主義など、PM特有の判断力について学べる
- 契約・法務面への言及: 多くのPM本では触れられない契約形態や損害賠償条項についても解説されている
改善点
- アジャイル開発での適用方法: 要件定義などの手法をアジャイル環境でどう適用するかの説明がやや不足しており、この点は他の専門書での補完が必要
- 規模別の使い分け: 小規模〜大規模プロジェクトでの手法の使い分けについてより詳しい説明があると良い
- 具体的なツール活用: プロジェクト管理ツールやコミュニケーションツールの具体的な活用方法についてもう少し詳しい記載があると実践しやすい
総評
PM業務の全体像を理解するための優れた入門書です。特に「PMはタスク管理者ではなく、プロジェクトの調整役」という本質的な理解が得られる点が大きな価値でした。また、実際の現場で直面する問題への対処法も豊富で、辞書的に参照する使い方も可能です。
特に印象的だったのは、完璧主義に陥らない80点主義の考え方と、様々なステークホルダーとの関係性の築き方についての実践的なアドバイスです。これらは経験を積まないと身につかない感覚を、体系的に学べる貴重な内容でした。
推奨する読み方:
- 全体通読: まず全体を読んでPM業務の全貌を把握
- 必要スキルの特定: 序章のスキルセット一覧を使って自身に不足している領域を特定
- 実践と振り返り: 実際のプロジェクトで手法を試し、KPT法で効果を検証
- 辞書的活用: 各フェーズで該当章を参照しながら業務を進行
組み合わせて読みたい書籍:
- アジャイル開発については『SCRUM BOOT CAMP THE BOOK』で手法の具体的適用を学習
- より高度なPM手法については『プロジェクトマネジメント知識体系ガイド（PMBOK）』で理論的背景を強化
- チームマネジメントについては『エンジニアのためのマネジメントキャリアパス』で人的側面を補完
- 契約・法務面については『IT契約の教科書』で専門知識を深化
まとめ
本書を通じて、PMの本質は「管理」ではなく「調整」であることを深く理解できました。QCDのバランス調整、ステークホルダー間の利害調整、そして何より「80点で良しとする」判断力の重要性を学べたことが最大の収穫です。
また、タスク管理に追われがちなPM業務の中で、本来注力すべき「プロジェクトを適切にゴールに向かわせる調整」に意識を向けることの重要性を再認識しました。見積もりの不確実性への対応、外部連携システムでの注意点、テストの重要性など、実務で直面する具体的な問題への対処法も数多く学べました。
PM業務を始めたばかりの方はもちろん、タスク管理に追われがちな現役PMの方にとっても、本来の役割を再認識できる価値ある一冊です。読後は必ず、より戦略的で効果的なプロジェクト運営ができるようになるでしょう。
Discussion