【PM志望者必見】プロジェクトマネジメントとは？ 「プロジェクトマネジメントの基本が全部わかる本」を若手社会人が要約してみた
皆さんお疲れ様です。
英知 契（えいち けい）です。
noteを始めて３ヶ月。新たな取り組みということで、ついに本要約に挑戦してみることにしました！（イェーイ！ぱふぱふ）
以前の記事で、おすすめの本３選という形でノージャンルで紹介したことはありましたが、１つの記事で１つの本を丸々要約するのは今回が初めてになります！
そして、今回要約する本は、コチラです。
交渉・タスクマネジメント・計画立案から見積り・契約・要件定義・設計・テスト・保守改善まで
橋本 将功 (著)
…ということで、１発目から早速ガチの実用書です。笑笑
今回は「プロジェクトマネジメントの基本が全部わかる本」ということで、以下の方にとって特にオススメな書籍になるかなと思います。
こんな人にオススメ
•新米プロジェクトマネージャー
•マネジメント職に興味がある方
•IT業界で、特に上流工程の仕事に興味がある方
•リーダーシップ力を体系的に育みたい方
•チームでの仕事に不安がある方
この本を選んで読んだ私自身、少しだけ上流工程の経験があるので、そのお話も踏まえながらお話しできればなと思います！
それでは、始めていきます！
プロジェクト全体で求められるスキル
説明が遅れましたが、本書ではプロジェクトマネジメントで求められるスキルを、プロジェクトマネジメントのスキルの見取り図と題して以下の2点に分類しています。
「プロジェクト全体で求められるスキル」と「プロジェクトの各フェーズで必要になるスキル」です。
まず、ここでは「プロジェクト全体で求められるスキル」について解説していきます。
１:プロジェクトとはなにか
そもそも、「プロジェクト」とは何でしょうか？
本書では、プロジェクトとは「いまある状態からあるべき状態にするために行う、スタートからゴールまで続く複数の業務」であると定義づけています。
つまり、目の前の課題を解決するためにたくさんの業務をグルグル回して見事課題解決することができれば、それは立派プロジェクトと言えるでしょう。
また、プロジェクトの目的と目標について、プロジェクトの目的は「業務の最終到達点」であるのに対し、プロジェクトの目標は「そのプロジェクトで達成するべき基準」とされています。
プロジェクトの目標の具体例を挙げると、QCD（Quality（品質）Cost（コスト）Delivery（納期））をベースにした目標設定がありますが、どちらにせよ目標と目的を履き違えてしまうと雪だるま式に問題が大きくなり、しまいにはプロジェクトの失敗に直結してしまいます。
なので、プロジェクトマネージャーという立場は、プロジェクトの全体間に立ってプロジェクトそのものが目前の課題に対してどう貢献できるかを常に考えなければなりません。
２:交渉
交渉も、プロジェクトマネジメントを行っていく上で非常に大切なスキルです。
私自身、実は少しだけPMOとビジネスアナリスト（実態はほぼPM）を経験したことがあるのですが、交渉のスキルはピカイチで大切だと思います。
当時、私はお客様が求めるものであれば是が非でも実現してあげよう、と完全にお客様からの提案を鵜呑みにして遂行していた時期がありますが、それでは上手くいくものも上手くいきません。
本書では、是が非ではなく「是々非々（良いことはよく、悪いことは悪い）」という姿勢が大切だといわれています。つまり、顧客からの意見を全て「正しい」と脳死で受け取るのではなく、無理な時は「無理」とキッパリ断る勇気を持つことが大切だということです。
半年前の腰抜け時代の私に言い聞かせてあげたいです。。。😅
３:タスクマネジメント
この本では、断言しています。
タスクマネジメントは、単なる「タスク管理」ではない。と。
では、何なのか。
それは、タスクの管理のみに拘らず、プロジェクトの目的達成のためにメンバーごとにタスクを采配することであると本書では述べられています。
また、メンバーの采配方法としては、能力値で判断するジョブ型のアサイン（配属）とタスクの見積もりの正確さの２つが重要とされています。
特に盲点なのが、タスクの見積もり精度についてで、経験者やベテラン、少なくともIT業界で「仕事ができる人（シゴデキ）」は見積もりがとても正確な人が多いです。これは、私も実際にプロジェクトで開発を経験していく中で感じたことでもあります。
ともあれ、あくまでもプロジェクトの目的を見失わず、そのために適切なメンバーの采配を考えていくことが大切です。
特に、タスクの見積もりについては現在開発担当の私が苦手としている部分でもあるので、肝に銘じて行動していきたいと思います….。
プロジェクトの各フェーズで必要になるスキル
４：プロジェクト計画
ここからは、プロジェクトの各フェーズを深掘りしていきます。
まず、プロジェクトを始めるに当たって忘れてはならなのが「プロジェクト計画」です。
最近のニュースだと、どうやら2026年に長年「未完成」だったサグラダファミリアが完成する、といったニュースが巷で話題ですが、これもまさしくプロジェクトと言えるでしょう。
流石に、どんな腕利きの建築士でも設計図を全く書かずにノープランで建築を始められる方はいらっしゃらないと思います。
そして、プロジェクト計画は以下の流れで進んでいきます。
１：ヒアリング（目的と前提条件の洗い出し）
２：座組とチームビルディング（誰とどのようなチームを作るか）
３：アサイン（誰に何を依頼するか）
４：目的（何のためのプロジェクトか）
５：QCD（品質・コスト・納期）（何を判断基準にするか）
６：会議体と意思決定フロー（話し合いと開発スタイルはどうするか）
７：契約形態（請負か準委任か）
８：マイルストーン（共有されるべき進捗は何か）
９：情報共有のやり方の策定（どのような意思疎通プロセスを作るか）
どれが抜けても大変なことになってしまいます。
特に、座組や意思決定フローでは、ウォーターフォール開発かアジャイル開発か、といったプロジェクトの進め方の根本に関わってくるので慎重に決める必要があります。まあ、全部そうなのですが。
５：見積もり
プロジェクトの計画が定ったら、次は見積もりです。
本書では、見積もりの鉄則として、「工数を見積もって、そこから費用とスケジュールを組み立てる」ことだと述べられています。
COWCOWの「あたりまえ体操」が流れてくるくらい至極当たり前のお話のようですが、実際はプロジェクトの大きなつまづきポイントになっているのです。
見積もりの流れを本書から引用すると、
１：やることを細分化して積み上げ式で見積もる
２：プロジェクトバッファ（予備時間）を見込んでおく
３：工数をスケジュール上に可視化する
４：予算取りを意識する
となるのですが、プロジェクトの見積もりは１つだけでは心許ないです。
本書では、要件定義前の「概算見積り」と要件定義•設計後の「詳細見積り」をどちらも行うことで、見積もりと実態のズレを無くしていくことが大切だと述べられています。
砕けて説明すると、「思ってたんと違う！」を少しでも無くしていけるような見積もりが必要だということです。
皆さんもM-1 2008年の笑い飯西田さんの敗者コメントが思わず口に出てくることがないように、マメな見積もりを心がけていきましょう。
６：契約
この項目については細かい内容は割愛しますが、請負契約・準委任契約についてはコンプライアンス違反スレスレの事案が多発しやすい箇所ですので、ぜひご自身で色々調べてみてください。
７：要件定義
特に大切なフェーズです。本書でも、ページを開いて早々「プロジェクトの失敗の５割（半分）は要件定義フェーズにあるでしょう！」とズバリと言及されています。まる子ちゃんの丸尾くんではないです。
ここも端的になりますが、特に私含め新米のPMにありがちなミスとしては
「要件」と「要求」を一緒にしてしまう
というやつです。
例えば、お客様から「〇〇の箇所と△△を修正してください〜」と要求されたら、それをそのままユーザーストーリーに落とし込んで要件として定義してしまう、というような事例であればイメージしやすいでしょう。
これ、よくやっちゃっていました。
なんでもかんでも鵜呑みにして進めてしまうと、いずれは大きな大きな雪玉となって、今後のプロジェクトの進め方がぐしゃぐしゃになってしまいます。
なので、プロジェクトとしての「要件」とお客様からの「要求」をしっかり線引きして、メリハリのあるプロジェクト運用を心がけることが最重要です。
そのほうが、後々にあって「やっぱりできませんでしたー」となって赤っ恥をかいたり、アジャイル開発であれば次のスプリント（アジャイル開発のサイクル）との兼ね合いも取れるようになりますしね。
８：デザイン
要件定義でプロジェクトのタスク全般の大まかなアタリをつけたら、今度はデザインです。
特に、UIやUX、フロントエンドエンジニアにとっては馴染み深いフェーズだと思います。
ここはプロジェクトの中でも最も楽しいフェーズではありますが、同時に最も結論を出すのが難しいフェーズでもあります。
プログラムや数学の問題と違って一方的な解が用意されているはずもなく、またデザインとなると人間の想像力は無限大です。
ここで大切なことは、ペルソナの策定やプロトタイピングを活かして、デザイン面での「思ってたんと違う！」を回避することです。
上記の「顧客が本当に必要だったもの」という画像は「顧客の要件」と「顧客のニーズ」に大幅なズレがあることを示している反面教師的な画像です。
これこそまさに、「思ってたんと違う！」ですよね。笑笑
こういった状況を回避するために、仕様書オンリーの確認だけではなく一度プロトタイピングを行って「見える化」してしまうことで認識のズレを回避していくことが重要なわけです。
「百聞は一見にしかず」ってこういう時に使うんですね。
９：設計
デザインまで決まれば、いよいよ設計フェーズです。
非常に重要なフェーズではありますが、今回は開発者ではなくPM目線なので割愛します。
しかし、使用する開発環境のバージョンや、どの言語を使うのか、脆弱性は問題ないかという大局的な視点は常に持ち続けた方が良いでしょう。
１０：テスト
テストの工程も、どちらかといえば開発者目線なので多くは書きません。
しかし、テストをタスク管理すること、また各テストの優先度を定めることなどの観点は必ず抑えておく必要があります。
以前私が経験したプロジェクトでも、テストの方法が定められているプロジェクトほどお客様評価も高く、テストの方法がその場しのぎのプロジェクトほど評価にムラがありました。
やはり、設計からテストまで一度経験しておくのとしていないのでは天と地ほどの差があるように感じます,,,
１１：リリース
さて、いよいよリリースです。
リリースは、私も日程調整や事後チェックなどを行ったことがあるのですがリリースの成功＝事前準備の抜けの無さ
の一言に尽きると思います。
ただ、どうしても１００％完璧なリリースというのは自分の実体験上ほとんどなかったので、リリース以前は日程の確認やUAT（ユーザー受け入れテスト）の進み具合との兼ね合い、リリース後は「何ができていて」「何ができていない」のかを明確化することが大切かと思います。
私はアジャイル開発担当だったので、特に後者のリリース後のアクションは次スプリントのタスクにするかどうかなどの議論に持っていきやすく非常に便利です。
１２：保守改善
全てのリリースが終わると、プロジェクトは保守運用フェーズに移行します、
残念ながら、私は保守運用体制はほぼ経験していないので多く語れないのですが、予算の見積もりやバージョンごとの脆弱性、また脆弱性解決と費用との兼ね合いなど意外と上流的な知識や考えが必要になってくるフェーズだと思うので、心してかかりましょう。
おわりに
というわけで、今回初の本要約でしたが、いかがだったでしょうか。
プロジェクトマネジメントやプロジェクトマネージャー職へ興味があるないに関わらず、興味深い内容だったかと思います（後半ぶっ飛ばしましたが😅ぜひ本書も読んでみてください）
私自身、本を要約していく中で感じたことがあります。
それは、
プロジェクトマネジメントとは
目前で動いているプロジェクトの
「思ってたんと違う！」の種を早期に発見して
「思ってたんと違う！」と真剣に向き合い
「思ってたんと違う！」を徹底的に排除すること
です。
いや、めっちゃ笑い飯西田さん出てきましたな。
「デザインあ」でも久々に見たくなってきたかもしれないですね。
とにかく、プロジェクトマネジメントは現実と理想のギャップをひたすら埋めながら、チームメイトが心身ともに安心して仕事に従事できる環境を用意してあげることが重要なのではないかな、と思います。
これは、少しだけでも上流工程を経験したことがある私が実体験も交えて得た感想です。
もし、少しでも「興味が湧いてきた！」と思いましたら、ぜひ本編も読んでみてみてください！
それでは、私は今から笑い飯さんが優勝した2010年のM-1をアマプラで観てきます。See Ya!
この記事が気に入ったらサポートをしてみませんか？