プロジェクトマネジメントの基本が全部わかる本 交渉・タスクマネジメント・計画立案から見積り・契約・要件定義・設計・テスト・保守改善まで みんなのレビュー

投稿元：

レビューを見る

最近話題のプロジェクトマネジメントの本。
またもや翔泳社の50%ポイント還元キャンペーンにつられて買ってしまった。

最近、開発もやってるのにプロマネのような仕事もやらされてて、読んでみた。
自分はプロマネにはむいていないのだろうなと思う(この本に書いてある事例と比べるとかなり小規模なプロジェクトではあるけど)。

設計の次がテストというのがなかなか興味深い。
一瞬、「製造工程はどうすればいいんだ」と思ったけど、第3章のタスクマネジメントがそれにあたるのだろうなと思った。ここが一番重要だからね

後、いたるところに、QCD(Quality：品質、Cost：コスト、Delivery：納期)という言葉がでてくるのだけど、それだけプロジェクトを成功に導くために重要な概念なのだろうなと思った。今やってるプロジェクトは、全部ダメになりそうな気がする…(Qualityぐらいはよくしたいのだけど、納期が短すぎて簡単なテストすらする余裕がない…)

プロマネとして大きすぎる負担を引き受けて心身を病む人がいるっていうのは、なんかわかる気がする。自分も、なんかうまくいかないなと悩んでる。そもそも、自分の考えに自信がなくて不安しかない。

「顧客のいう通りに機能を実装したら、そこがセキュリティの穴になって後で大問題」というのは、7payの話かな。セキュリティを保つと不便になることもあるからね。このへんは、難しいけど、セキュリティへの考慮は重要ということなのだろう。

チャットで和気あいあいしてるのに、優秀な人がやめていくという話が面白かった。優秀な人ほど馴れ合いのネガティブな影響に気づきやすいとのこと。なんとなく分かる気がする(自分の場合、ただたんに雑談が苦手なだけだけど)

なお、著者によると、能力の高いソフトウェアエンジニアが出す見積もりは極めて正確だとのこと。本当、見積もりを正確にだせるようになりたいけど、なかなか難しいんだよ…(能力が低いだけ…)

後は、ビジネス要件の話については、重要なことだろうなと思った。「なぜそれをやるのか」というのが分からないと、モチベーションも低くなりかねないしね。まあ、今やってるプロジェクトは、「なぜそれをやるのか」をうまく説明できないのだけど…(しいていうと、他に仕事がないから)

なお、要件定義資料にはスライド作成ツールは使わないほうがいいとのこと。なぜなら、広さに制限があるとのこと。なるほど。やっぱり、Excelを使うのがいいという事か。というと、そういうわけではなくて、Visio、draw.io、Lucidchart、miro、Whimsical、Cacooというツールを利用するのがいいらしい。やっぱり、そうだよね…。

後、設計を残すことは大事とのこと。今やってるプロジェクトは、途中で設計作るのやめた。そもそも、どういう仕様にすればいいのかが分からない所がおおすぎて、直接プログラムに落とし込むことに。品質絶対悪くなるよなと思う。

とりあえずこの本に書いてあったことを心に留めて、プロジェクトを進めていきたい。

投稿元：

レビューを見る

ソフトウェア開発プロジェクトのマネジメントについてのスキルを整理した一冊。
マネジメントするべき「プロジェクト」とは何であるのか、という解説から始まり、成功に至るために必要なステークホルダーとの交渉、決めるべきこと、各フェーズで求められていることが網羅されている。

いちソフトウェア開発者としてキャリアを築く中で、自然に身につけていたなと思う内容もあれば、これまであまり意識出来ていなかったなと思うところも。
本書は、そういった経験則で語られがちな内容を言語化し、通して学べる形で書籍化されている点が非常に良かった。
私自身は現在プロジェクトマネージャーになる予定も経験もないが、管理される側として、あるいは今後のキャリアの参考として、非常に勉強になった。

投稿元：

レビューを見る

現場感のあるアドバイスが数多くあり、プロマネでなくプロジェクトメンバとしても大変参考になる本だと思いました。

投稿元：

レビューを見る

▼感想
・これまで数冊プロジェクトマネジメントに関する本を読んできましたが、上位に値するくらい内容量もわかりやすさも良かったです。

・当方は、「PJ計画」、「要件定義(非機能要件含む)」、「テスト」が特に理解が深まりました！

投稿元：

レビューを見る

いまある状態からあるべき状態にするために行う、スタートからゴールまで続く複数の業務をプロジェクトと定義し、プロジェクトをどのように進めればよいのか解説した図書。プロジェクトの流れに沿って解説があり、イメージしやすい。これらの能力を身に着けられるとうれしいなぁ。なお著者がIT業界でのプロジェクトに多く関わっているため、IT業界の例が多め。

投稿元：

レビューを見る

・関係者（発注者/ベンダー/メンバー/関連企業）が対等に話し合える関係性を築く
・プロジェクトマネージャーが多忙もしくは能力不足で全体観を失わないようにする

マネジメントは管理だけではない
　管理：状況確認（計画との差分）、作業アサイン
　　→計画に固執する
　マネジメント：管理＋目的達成に必要な判断、全体像の把握、事前調整
　　→リスク把握し、アクティブな調整を行い、計画にフィードバックさせる
■交渉
　・説明資料と議事録は文書化
　・フォーメーションを組む：重要度、費用と進捗課題は人を分けるなど
■タスクマネジメント
　・タスクを洗い出す→優先順位つける→メンバアサイン→振り返りＫＰＴ
　★タスク名は「○○を○○する」で記載
　　いつまでに、は期限ではなく工数で記載
　・ガントチャートの欠点
　　タスクの抜け漏れ、
　　納期に合わせたスケジュールになりやすい（逆線表）
　　追加、変更管理が煩雑
　　メンバが「学生症候群＝ぎりぎりにやる」になりやすい
　・メンバアサイン
　　背景、目的も伝える
　　完了条件を認識合わせる（優先度、期限とともに）
　★定期的な振り返り
■プロジェクト計画
　・目的、前提条件
　　座組（体制図）、意思決定者、利害関係者、予算、日程、要求
　　を確認する
　　（目的、前提条件を優先的に確認。後から変更難しい）
　・開発体制
　　スクラム（≒アジャイル）開発はメンバスキル必要、予算＆日程が流動的
　　→納期・予算厳守の開発には向かない

■見積
　・工数見積もり→費用と日程を組み立てるが鉄則
　・ざっくり見積もり：What（何を実現するか）
　　通常の見積もり：How（どうやって）、Who（誰が）で見積もる
　・プロジェクトバッファ　1.2～1.5の係数をかける
　　　リスク低い＝やること明確 1.2倍
■契約
　請負契約　チェックポイント
　・成果物の完成義務：成果物の定義
　★検収の定義
　・契約不適合への対応
　・損害賠償事項：上限額の設定
　　追完請求（補修）、代金減額請求

　準委任契約　チェックポイント
　・作成資料、具体的作業、報告の共有
　・善管注意義務：通常期待される注意義務
　　（PMとして期待されることをやっているか）

■要件定義
　・「要求＝やりたい」と「要件＝すること」を切り分ける
　・ビジネス要件（Why）を固める
　・実現することの軸足と概要を描く
　　システムアーキテクチャ、機能要件一覧、非機能要件一覧
　　画面遷移図、シーケンス、ER図（データ構造）、API一覧
　・資料化
　　できるだけ図で表現：draw.io
　　正しさより伝わる資料
　　BA（Asis/Tobe)を作る：現状把握を怠らない
　・要件変更/追加要件は期限を切って対応
■デザイン
　・ユーザーインタビュー
　　既存のプロダクトの客観的評価に向く
　　新規プロダクトには向かないことが多い
　・ロゴ、フォント、トーン＆マナー、顔を決める
　★全体像をデザイン
　　類似プロダクトUI/UXを学習する
　　ユーザーにとってのメイン画面、機能を検討する
　　→基本的パーツを作る
　　検討内容をUIに落とし込む
　　デザインを育てる：プロトタイピング
■設計
　・技術スタックの決定
　　　言語、OS、ミドルウェア、フレームワーク、ライブラリ、インフラスペック
　・開発作法の整える
　　　ソースコード管理、コード規約、開発環境
　　　デプロイ方法、コンテナ採用判断、仕様ツール
　・設計書記載精度を決める
　・技術的負債を見極める
■テスト
　・ソフトウェアテストの7原則
　★各テストの定義を確認する
　　リグレッションテスト、受入(検収)テスト、負荷テスト
　・テスト計画、マネジメント
　　テスト全体管理者を置く
　　責任の追及ではなく対策を追求する
　　チケット（タスク）で管理する
　　定期報告を行う
■リリース
　トラブル発生時の対応を検討する
■保守改善
　PJ目的は事業としての成功を実現する。QCD達成が目的ではない
　プロダクト改善費用
　　保守運用のみ、保守運用＋改善、保守運用＋大型改善
　　それぞれの対応工数を見積もる
　ファネルモデルを作る

投稿元：

レビューを見る

・感想
PMに立つ上で基礎知識をかなり分かりやすくまとめた書籍。
定期的に読み直し、知識のアップデートを図る必要有。
復讐をよくおこなって35歳までには身につけたい。
・Todo
・PJはスタートとゴールが決まっており、
　QCDの観点はトレードオフになる。
企画:プロジェクトの企画意図や必要性の検討
見積:ベンダーに見積を取って費用やスケジュールの評価
決裁:費用対効果やスケジュールの妥当性を検討し、社内決裁の上でベンダーに発注
PJ計画:プロジェクト計画を立てて開始する
要件定義:要件の定義とデザインを行い、開発するシステムの大枠を決める。
設計:設計を行い、システムの仕様を詰める
実装:システムの実装を行い、追加要件・仕様のハンドリングを行う
テスト:テストを行いシステムが適切に実装されているか確認する。
リリース:事前に決めた手順にしたがってリリースと現場への導入
保守改善:システムが適切に動くよう保守。必要に応じて機能改善

★スタートから無理な予算やスケジュールになっていないか妥当性を確認。
　※適切な人材も配備しておくようにすること。
→PJの全体像を共有しておく。
　関係者（発注者、ベンダー、メンバー、関連企業）が対等に話し合える関係性がない。
　PJマネージャーが多忙もしくは能力不足で全体感を失っている。
　この３つは失敗要素に繋がりやすい。

★PMはプレイヤーとして多忙で全体間、必要作業整理が遅れないようにする。
★マイクロマネジメントをするとメンバーの自律性（指示待ち）をなくす。
★メンタルを常に正常に保っておくこと。
　＝タスクを抱えすぎない。

・ITでよくあるリスク
　管理画面の実装を想定していない。必要工数を過小評価する。
　システムの外部連携に必要な工数や体制の過小評価
　一部ユーザー意見を聞いて要件定義や設計、実装を行う。

★PMは管理だけではなく、困難な状況でも協業して目的を達成したりプロセスを維持する必要がある。
　→打ち合わせで進捗を管理するだけ、タスクをメンバーに振るだけ、Excelで予算や稼働時間の調整をするだけ　のマネジメントは不用。
　★PJ実態をリスクの観点で把握してアクティブな調整を行い、それを計画にFBしていく必要がある。

★PJは基本不確実で当初の予定通りには進まない。
→不確実性を減らしQCDの高い基準の達成には、計画の承認や要件定義の際に意思決定者や関連するキーパーソンの判断、調整が必要不可欠。

★交渉の前面に立たないPNは各関係者から信用されずプロジェクト継続性にも支障をきたす。
　やるべき交渉や調整をメンバーに丸投げしないこと。

・PJを適切に進める点で完璧主義はネガティブに働くことを意識しておく。
★多角的な情報を集めて、みんなの意見を聞きながら関係者に方向性を指し示すやり方を行うこと、

★同期、非同期のコミュニケーションを使い���けて相談しにくいことは同期のコミュニケーションを取ること。
　※リアルタイムか非リアルタイムか。
・10人しか居ない会議で3人しか話さないのは7人の工数を無駄にしている。

★議事録を必ず取ることでPJの言った言わないを防ぐ。
　決定事項は関係ないと思えるような人にも共有すること。
・フォーメーションを組んで交渉すること。

★PJを進める上で注意すること
　・PJを進める中での懸念点をあらかじめ説明する
　・エビデンスを主体に説明資料を作成する
　・最終的な着地点を明確にする
　・会社間の交渉内容はあらかじめ組織内で合意しておく。
★ハードな交渉は必要最低限に絞り、PJを適切に完了するためには何が必要なのかを明示し、そこ
に理解を得られるよう努力すること。
　そしてハードな交渉ほど事前に組織内で合意をとっておくこと。

・タスクマネジメントはタスク管理ではない
★アサインを決める際はそのタスクを実行出来るだけの技術や経験があることは前提として、更にマインドもよく見なければならない。
・そのポジションに必要なタスクをこなせるかを能力とマインドの観点でチェックするように
★言い訳や責任回避の姿勢が見られプロジェクト進捗に影響する場合は上層部に掛け合って早めにアサインを変更してもらうようにする。
→不可能な場合はサポートする体制を組む、クリティカルパスのボトルネックにならないタスクのみを割り当てて全体進行に影響しないようにする工夫が必要。

★トラブル報告する際はメンバー個人の問題ではなく、プロジェクトの課題として報告するように。
　また事前に懸念点として意思決定を行う上層部に認識を共有しておくこと。

★見積でタスクの遂行能力を見極める。
やってみないとわからない　というスタンスのメンバーは経験不足で能力が低いか、責任回避的でタスクに積極的に取り組むマインドがないかのどちらか。

タスクは〇〇を〇〇すると記載
必要なことを達成する為にどうすべきか洗い出し、
優先順位を決めて、誰がいつまでに実施するかをリスト化。
★いつまでには期間ではなく工数を記載。
　粒度が大きくても良いので抜け漏れなく。
★タスク組み立て後はガントチャートを活用し、優先順位をつける。
　クリティカルパスを使って穴を埋めていくことが理想。
★タスクを依頼する際はPJ上の背景や理由を説明すること。
★人が無理し続けられるのは3ヶ月から長くても半年。2ヶ月以上無理が続く場合はPJを止めて全体を見直すこと。

★担当者のレベルが低い場合はサブタスクまで分解してあげる
　タスクを丸投げすると、アウトプットの質が低かったり方向性が異なってやり直しが発生しやすくなる。

変化の激しいPJは毎週、そうでないPJは月一や四半期で振り返り会を行う。
テーマは良かったこと、改善したいこと、課題、今後努力したいことを出し合う。

プロジェクトが停滞した場合は
・メンバーのスキルが低い＝ミスマッチであることを伝えてPJの判断としてアサイン変更
・アサイン担当の稼働が逼迫＝マネジメント��足。負荷分散のために他者へタスクを振る、プロジェクト全体のスケジュールを調整すること。

★PJ計画の立て方。
・ヒアリング　PJの要件を確認、提案
・座組とチームビルディング　PJの体制を整える
・アサイン　誰に何を依頼するか決める
・目的　プロジェクトの真の目指すべきところをとらえる
・QCD プロジェクトの判断基準を決める
・会議体と意思決定フロー　適切なプロジェクト推進方法を決める
・契約形態　請負か準委任かを確認
・マイルストーン　進捗を関係者で共有
・情報共有のやり方　意思疎通の仕組みを作る
★キーパーソンを決めながら行っていくこと。

★ヒアリングで重点的に聞くこと
目的　何のためにPJをやるのか
前提条件　必ず守る必要がある条件はなにか
座組　PJメンバーや連携が必要な企業はどこか
意思決定者　決済権限を持つ人
利害関係者　得をする人、損をする人は誰か
予算　適切な予算があるか
スケジュール　適切な実施期間があるか
具体的にやりたいことはなにか。

エゴはプロジェクトを推進する力になるが実現可能性の観点で前提条件や目的もよく検討すること。

★外部ベンダーを使う際は有望企業を3ー4社集めること。
・その企業ならではの提案があるか
・見積もりが安すぎないか

★誰にいつまでに何を決めてもらわないとプロジェクトが予定通りに進まないのかをプロジェクト計画にマイルストーンとして明確に記載する

ウォーターフォール
　フェーズ毎に区切るので進捗確認がしやすかったり、各フェーズ予算やスケジュールを明確にしやすい。
　デメリットは要件定義や設計フェーズはドキュメント主体なので理解力や想像力が関係者に求められる。
アジャイル
基本はプロダクトを確認しながら開発が出来るが以下を満たさないとウォーターフォールより時間がかかる。
①素早い意思決定が出来ること
　※意思決定が止まると開発全体が止まる
②プロジェクトメンバーの要求レベルが高い。
　各工程について習熟している必要がある。
　基本的な考えが備わってないと混乱する可能性もある。
各ポジションをスキルが高いメンバーで固められない場合はウォーターフォール型を取ること。
　フロントエンド　画面
　バックエンド　　アプリケーションやデータベース等
　インフラ
　利用するフレームワーク
③外部システムやサブシステムとのシステム連携がある。
　既に公開のAPIなら問題ないが、今後の拡張において未公開だと不適切である
④プロジェクト全体の予算やスケジュールを調整出来る

契約形態もはっきりとさせておくこと。
マイルストーンをハッキリさせ、各ポイントで報告入れることを明示する。
アジャイル（スクラム）開発がマッチするのはIT予算が複数年で継続的に組まれており、優秀な開発チームを継続的に維持できる企業であること。

見積は工数を見積もってそこから費用とスケジュールを組み立てることが鉄則。
概算見積の金額ブレ幅は4倍から0.25倍まである。
概算はバッファを積���で高めに出すこと。

★プロジェクトはモノを買う時より安かろう、悪かろうになる。

★ざっくり見積は類似案件から出せるが出した責任はPMや実行チームが追う為絶対に言われてもその場では出さない。
すぐに見積るので一旦持ち帰りますと回答すること。

見積手法の種類
パラメトリック見積　
　特定の係数モデルを利用し、重みづけして工数を算出
三点見積もり法
　作業毎に最頻値、楽観値、悲観値を設定し、値を掛け合わせて工数を算出
類推見積もり
　過去の類似プロジェクトを参考に見積
ボトムアップ見積もり
　成果物や作業を分解してそれぞれの構成要素工数を算出し、積み上げて全体工数を見積る。

ざっくり見積もりは
プロジェクト目標を達成する為に誰が何をやらなければならないかを細分化して、メンバーのタスク（作業）レベルにまで落とし込む。
★基本工数は5人日以上は5人日刻みで出すことを推奨。
　そこからその人の1日あたりの単価をかける。
→決まった予算枠やスケジュールとマッチしないときに何を削れば対応できるか調整しやすくなる。
見積もり明細には対応項目毎に工数と単価を明記して記載しておくと明朗会計で信頼されやすくなる。
★一色の記載があるものは積み上げ式ではなく信頼性が低いので、相手に突っ込むこと。

・PJバッファは1.2-1.5くらいの係数をかけて出す。
　※バッファを消化しなかった場合は請求金額を安くする、機能追加やドキュメント整備など追加対応を実施するなどでPJ満足度を上げる。

見積費用は説明できるようにしておくこと。
なにを削れば擦り合わせられるかの調整も想定しておくこと。

要件や仕様が変わると工数が変動し、それを見積もる必要があることは関係者に都度説明しないといけない。

請負契約　発注者に成果物を納品し、その成果物に対価を支払ってもらう
準委任契約　発注者の代わりに行った専門的な労働の対価について支払いを受ける

請負契約で注意すること
成果物はなにか。
　チーム内部のドキュメントと顧客納品のドキュメントは品質が大きく異なる。
　※成果物の工数は適切に見積もる必要有。
何を持ってプロジェクトを完了とするか。
　結合、総合テストが完了している、第三者の脆弱性テスト報告内容を確認したりする。検収定義を契約書やプロジェクト計画書で文書化しておくこと。
それは本当に対応が必要か。
　締結時に記載内容をよく確認すること。
一方的な内容になってないか。
　損害賠償が青天井になってないか上限額が記載されているか。
　※重過失の場合はこの限りではないと記載する。

★準委任契約はどのくらいの期間と工数を使えばどのような成果を得られるかを資料サンプルやプロジェクト計画、業務報告のサンプルで早めに示してお金を払う理由を納得してもらうこと。

★偽造請負には要注意。
　・発注者は受注者の労働者に指揮命令や業務管理を出来ないようにする
　・発注者と受注者の体制を明確に分ける
　請け負った業務内容や就業場所を細かく記載する���うにする。

★支払いサイトをしっかり確認し、中小企業が倒産しないようにすること。

★要件定義
　要求（実現したいこと Want）　と　要件（実現すべきこと Must）　を切り分ける
　決めるべきことをスケジュールの観点で見極める
　ビジネス要件（Why）を固める
　実現すること（What）の軸足と概要を描く
　合意された事柄を資料化する
　法律など社会のルールを踏まえる
　要件変更や追加要件のハンドリングをする。

・市場調査
　プロジェクト対象がどのような規模でどのような競合他社があるのかを調査する。
　※調査はWeb検索や各種調査報告書、新聞、書籍、専門データベースなど。
・競合調査
　　売上や市場でのポジション、どのような機能や売り方、見せ方をしているかを分析。
・ビジネスモデル
　自社のビジネスモデルを検討。
　想定収益が想定費用と比べて安すぎないか、継続的な成長のための再投資が可能か
ビジネスモデルキャンバス
　顧客、提供価値、チャネル、顧客との関係、収益、リソース、活動、パートナー、コストを一枚に。
４P分析　商材、価格、流通、販促
４C分析　顧客にとっての価値、費やすお金、利便性、コミュニケーション

ペルソナ設計と分析

カスタマージャーニー
　ペルソナが日々どのような生活や仕事をして、開発プロダクトとどう関わるのか、どのようなペインを解決するのか。

ユーザーストーリーマッピング
ユーザーから見たプロダクトの中での機能や特徴の位置付け
何が必須機能や特徴なのか。

ユースケース
ユーザーがプロダクトを利用して、特定の目的を達成するまでのユーザーとプロダクト双方のやりとりを明確に定義したモノ。

システムアーキテクチャ
プロダクトがどんなインフラ構成で稼働するか、連携システムはどこにあるのかを図示する。
具体的にどんな技術を利用し、どんな専門家が必要かを把握する

シーケンス図
ユーザーの作業やプログラム、データの流れや概要を図示する。

ER図、テーブル定義書
プロダクトで利用するデータをどのように構造化するかを定義。

API一覧
どんなAPIを利用するかを一覧化。

★合意された事柄を資料化する。
　なるべく図で表現。
　※Powerpointでらなく、絵で描くと良い。
　インデックスは必ず入れる

業務改善やプロダクトリニューアルは、
AsIS/ToBeを入れること。

★要求提出や要件についての意思決定はそのままだと時間がかかるので提案型で要件をとりまとめるアクティブな対応が必要。
　要求をヒアリングとしてとりまとめ、実際にプロダクトに落とすとどうなるかを要件定義のフレームワークやプロダクトのデザインイメージに落とし込み、最終判断を仰ぐようにする。
A案かB案の2択に絞ると進みやすい。
→やり直しと停滞が一気に減って効率化に繋がる。

★打ち合わせではアイデアを募る　発散の場なのか、
　要件や仕様を判断する　収束なのか　を明示するようにする。

デザインは���ルソナ（代表的なユーザー像）設計をしっかりとすること。

★プロダクト全体像のデザインの仕方
類似するプロダクトのUI/UXを学習する
ユーザーにとって何がメインの画面や機能かを検討する
検討内容をUIに落とし込む。

意思決定者が口出しして進まない場合は幅広い方向から複数案を提示して選択する。

★設計
　技術スタック（プログラミング言語やOS、ミドルウェア、フレームワーク、ライブラリ等技術の組み合わせ）を選定
　PMは言ってることを理解できるようにしておく必要有。
　開発の作法　を整える
　設計書に求められる精度を確認
　設計書を作成
　設計書をレビューする。

技術選定時はGoogle trendsを使って流行度合いや技術のメリデメを比較検討する。

デプロイ　開発したソフトウェアをサーバー上に展開・配置して利用できるようにすること。

テスト環境　実装画面や機能をテストする環境
ステージング環境　本番環境に類似する環境で表示内容の確認や性能面をテストする環境
本番環境　リリース後にプロダクトが動作する環境

どんなプロジェクトでも設計書は残すこと。
※リプレイス時や改修時の調査工数を減らすため

★テストは責任の追求ではなく、対策を追求すること。

★piyolog などを定期的に見て、事件や事故を定期的にチェックしておく。

投稿元：

レビューを見る

プロジェクトとは、 いまある状態からあるべき状態にするために行う、スタートからゴールまで続く複数の業務 と本書では定義している。

投稿元：

レビューを見る

プロジェクトマネジメントの経験はないですが、そちら側からの視点に興味があり、読み始めました。

プロジェクトの全体像などが、分かりやすく書かれており、すごく読みやすかったです。実際の質問などがカテゴリ毎に掲載・著者が回答しておりましたので、イメージをしやすかったです。

投稿元：

レビューを見る

見積もりと実績でスキルチェックを行う
　見積もりが曖昧な場合はスキル不足かモチベーション不足
タスクは具体的にxxをyyするの形で
　見積もりは工数で
　　スケジュール管理はクリティカルパスベースで
　依頼時は優先度、完了条件、期限を明確に
プロジェクト計画
　ヒアリング
　　目的
　　前提条件
　　座組
　　意思決定者
　　関係者
　　予算
　　スケジュール
　　やりたいこと
　座組
　アサイン
　　ベンダー選定
　　　提案があるか
　　　価格が不当に安くないか
　目的
　qcd
　会議体、意思決定フロー
　　ステークホルダー
　　開発方法
　　　アジャイル
　　　　意思決定が早い
　　　　メンバーのスキル要件が高い
　　　　　レビューアーは特に
　　　　外部連携はリスク高め
　　　　スケジュールや予算は柔軟性が必要
　契約形態
　マイルストーン
　　関係者がいつどんな判断が必要になるか
　情報共有の方法
　　ツールの使い方
見積もり
　概算見積もりと詳細見積もりを使い分ける
　　要件定義前
　　要件定義、設計後
　3点見積もり
契約
　請負契約
　　納品した成果物に対する対価
　　　成果物の定義
　　　　ドキュメントをどうするか等
　　　検収の定義
　　　損害賠償の範囲
　準委任契約
　　労働に対する対価
　　　作成する資料
　　　進め方
　　　報告方法
　　善管注意義務
　工程で契約形態を変更するのは有効
　偽装請負
　支払い
　　方法
　　サイト
　　　取引期間の締め日から支払いまでの期間
　監査の立ち入り要件
　　アクセスログの提供方法などれんけいほうほうを明確に

投稿元：

レビューを見る

プロジェクトを進める上で幅広く必要とされる知識やマインドセットをかなり幅広く抑えている。聞いたことのある概念や用語は多いが、それをスキルセットとして自分の中に落とし込めていないものがとても多いので、こういう本を手元に一つ置いておきたい。
様々な局面でのコミュニケーション(同期・非同期)の取り方や、ウォーターフォールとアジャイル(の中でもスクラム)の開発の使い分けなど、参考になった。

投稿元：

レビューを見る

プロジェクトマネジメントもプロダクトマネジメントも「ほぼ同じ」というザックリな視点ではあるが、「基本がわかる本」というコンセプトなのでこれで十分。プロジェクトを業務委託先と進めていく上で理解しておかなくてはいけないキーワードがしっかり盛り込まれている。

プロジェクトマネジャーならば、この本をすべて頭に入れてからスタートしてほしいところだ。

こういうプロジェクトマネジメントに必要な知識、手順がまとまっている使いやすいサイトって無いのかなぁ。経営理論やマーケティング理論もそうか。概念としては体系立てられているが、マニュアルレベルの個別対処となるとその時の状況、自社のリソース、自分やメンバーのスキルなど半分以上がケース・バイ・ケースの変数に依存するので動き方が異なってくるもんなぁ。プロジェクトも同じだよね。PMBOK（ピンボック）通りの手順だと石橋叩いてる途中でリソースが尽きちゃいます。

僕はプロジェクト・オーナーの立場で携わるので本書の第6章「契約」は特に勉強になった。手元においておくとしよう。

投稿元：

レビューを見る

評価3.5
PMとはざっくりどんな感じなのかを知るために本書を手に取った。
網羅的に基本的なことが紹介、解説されていて入門者にはとてもよかった。