BOOK IT  ビジネス書

【要約】プロジェクトマネジメントの基本が全部わかる本 交渉・タスクマネジメント・計画立案から見積り・契約・要件定義・設計・テスト・保守改善まで|本のまとめ。

次の方を対象にしています!


プロジェクトマネジメントの基本が全部わかる本」を参考に説明します。


参考: プロジェクトマネジメントの基本が全部わかる本


\ 聞き流せる本!Audilbe無料体験期間中 /

好きな本が聴き放題!アマゾン Audible 30日間 無料体験を試す

>> 詳しく知りたい方へ!Audibleで無料で本を聴く方法を徹底解説

プロジェクトマネジメントの基本が全部わかる本 要約|プロジェクトマネジメントのスキルの全体像。まとめ

プロジェクトマネージャが直面している課題がいくつかあります。

  • 現場で使える知識体系がない
    • PMBOKやITSSのような多くの業界で活用できるため抽象度が高い
  • 無茶振りされる
    • 予算が少ない、期限が短い、など
  • スキルの属人化
    • プロジェクトで様々な状況に対応してきた人だけに知見がたまる



アンケートによると約7割のプロジェクトマネージャがスキル不足と感じています。なぜスキルが不足するかというと、実践で使える共通概念がなく、実務で覚えようとするがOJTが機能していないためです。


OJTを機能させるためには、プロジェクトマネジメントを修得して的確に人教えられる人材が必要です。しかし、実際かなり少ないと言えるでしょう。必要なスキルを含めてこのあとの章で説明します。


プロジェクトマネジメントのスキルセットをセルフチェックしてみましょう。

  • 交渉
    • 提案/合意形成:各フェーズで必要な提案を行い、フィードバックをとりまとめて合意形成を行う
    • QCDの調整:発生したリスクや対応コストを説明し、品質/予算/納期の調整を行う
    • ステークホルダーの利害調整:関係者の利害調整を行う
  • タスクマネジメント
    • プロジェクト全体像の共有:メンバーに要件定義で合意したプロジェクト全体像を伝える
    • タスクの洗い出し:プロジェクト遂行のため必要なタスクを洗い出す
    • 調達:タスクを実行するうえで必要なポジションのアサインを調整する
    • タスクアサイン:メンバーにタスクをアサインする
    • 進捗管理:各メンバーのタスクの進捗状況をリアルタイムで把握する
    • 情報共有:情報共有ツール選定を行い、運用ルールを設計する
    • 振り返りの実施:KPTなど、プロジェクトで都度振り返りを行う
  • プロジェクト計画
    • 座組の管理:関係者の役割分担や意思決定のプロセスを整理する
    • プロジェクトリスクの整理:プロジェクトを実施するにあたって想定されるリスクを洗い出して関係者に共有する
    • QCDの優先順位確認:品質/予算/納期の優先順位を確認する
    • 適切な開発手法の選定:プロジェクト要件を満たすために適切な開発手法は何か
    • マイルストーンの設定:スケジュールにおいてマイルストーンとなるポイントを設定する
    • 情報共有の仕組みづくり:会議体や情報共有フローの仕組みづくりを行う
  • 見積もり
    • 工数:プロジェクトに必要な工数を見積る
    • 実行計画の作成:見積もった工数をスケジュールに落とし込む
    • 費用:見積もった工数を基に費用を算出する
    • 請求対応:費用を請求する
  • 契約
    • 契約書案が適切な内容になっているかレビューする
  • 要件定義
    • ビジネス要件:ビジネス要件を合意できるかを確認する
    • システム要件:システム要意見を合意できるかを確認する
    • 追加要件のハンドリング:当初想定されていなかった追加要件のハンドリングを行う
  • デザイン
    • ビジュアル・アイデンティティ:プロダクトのビジュアル・アイデンティティを設計する
    • UI/UXデザイン:UI/UXデザインを作成する
    • プロトタイピング:プロトタイプを実施する
  • 設計
    • 技術スタックの調査選定:実装で使用する技術を選定する
    • 開発の手法を整える:開発の際に必要な取りまとめを行う
    • 設計書を作成する:設計書を作成する
    • 設計書レビュー:各領域の設計が適切に行われているかを確認する
  • テスト
    • 品質担保の合意形成:限られたリソースを確保すべき品質について関係者と合意を形成する
    • テスト計画の作成・レビュー:テストをどのように進めるか何を重点的に確認するか計画を作成、レビューも行う
    • テスト体制の構築:テストを実施する体制を構築する
    • 関係者への報告:関係者に対してテスト状況を報告する
  • リリース
    • リリース計画の作成・レビュー:リリース手順や全体の役割分担を作成。またはレビューする
    • ストア申請:ストアに申請する手続き等を確認して実施する
  • 保守改善
    • 費用対効果の確認:プロジェクトの費用対効果について確認し、合意を形成する
    • 保守・改善内容の合意形成:プロダクトの保守と改善内容の合意を形成する
    • 保守改善体制の構築:プロダクトの保守改善体制を構築する
    • データ分析体制の構築:プロダクトのKPIやログ分析の体制を構築する
    • グロース体制の構築:プロダクトのグロース体制を構築する
    • 広告運用体制の構築:プロダクトの広告運用体制を構築する


プロジェクトマネジメントの基本が全部わかる本 要約|プロジェクトとはなにか。まとめ

プロジェクトとは「いまある状態からあるべき状態にするために行う、スタートからゴールまで続く複数の業務」と定義します。プロジェクトには目的と目標があります。プロジェクトの目的はプロジェクトが向かうべき最終的な到達点、プロジェクトの目標はそのプロジェクトで達成すべき基準のことです。


プロジェクトの目標はQCD(品質、コスト、納期)によって定義できます。


プロジェクトには3つの特性があります。

  • スタートとゴールが決まっている
  • 不確定要素が多い
  • 異なる立場や専門性を持つ人が分業してかかわる



プロジェクトの特性は次の形でプロジェクトの困難として現れます。

  • 失敗を後で取り返すことが難しい
    • 座組で不適切な人がプロジェクトに関わると遅延や失敗の原因となる。挽回するには大きな時間と予算が必要となる
  • どんなプロジェクトも起こりやすい失敗パターンがある
    • プロジェクトの全体像をメンバーが共有していない
    • 関係者が対等に話し合える関係性を築けていない
    • プロジェクトマネージャが多忙もしくは能力不足で全体観を失っている


プロジェクト固有のリスクはできるだけ早期に対応してしまいましょう。たとえば次のようなリスクです。

  • 管理画面の実装を想定していない、または必要な工数を過小評価する
  • システムの外部連携に必要な工数や体制を過小評価する
  • 一部のユーザの意見を聞いて要件定義や設計、実装を行ってしまう


また人に頼るのも仕事のうちです。プロジェクトマネージャとは全体を俯瞰して優先して対処すべき物事を判断する人です。

  • プロジェクトマネジメント:プロジェクトの目的達成のためにできることを最大限実施すること。アクティブな調整をし計画にフィードバックしていく。
  • プロジェクト管理:進捗やミーティングなどの管理を行うこと


プロジェクトマネジメントの基本が全部わかる本 要約|交渉。まとめ

交渉は精神的な負担が大きいため苦手とするプロジェクトマネージャは多いものです。しかし、交渉の矢面に立たなければ信頼はされません。


交渉の難しさは、QCDに絡んでヒト・モノ・カネの特性が異なるものを適切に調整し合意する必要があることと、立場の違いにより利害が衝突するからです。相手に関わらず、素直に良い悪いと意見を持ち進めていくことが必要です。またフラットに物事を考え、方向性を示していくことも必要になるでしょう。


交渉で気をつけるべきことがあります。

  • ヒヤリングの機会を定期的に設ける
  • コミュニケーション手段を使い分ける
    • 同期(直接話す)/非同期(メールやSlack)、言語/非言語(声の大きさや表情)を使い分ける
  • 説明資料と議事録を文章化する
  • 相談内容や決定事項は関係各所に共有する
  • フォーメーションを組んで交渉する


参考: プロジェクトマネジメントの基本が全部わかる本


\ 聞き流せる本!Audilbe無料体験期間中 /

好きな本が聴き放題!アマゾン Audible 30日間 無料体験を試す

>> 詳しく知りたい方へ!Audibleで無料で本を聴く方法を徹底解説

プロジェクトマネジメントの基本が全部わかる本 要約|タスクマネジメント。まとめ

タスクマネジメントは、日々変化する中でプロジェクトがゴールに向かっているかを確認しながらコントロールする司令塔です。主に要件定義と設計が終わった後の実装、テストのフェーズで行います。しかし、プロジェクト計画や要件定義、設計でもメンバーと手分けしてタスクを実施する際に行います。


アサインを決めるときは、そのタスクを実行できるだけの技術や経験があることを前提として、さらにマインドもよく見なければなりません。「ジョブ型思考」とよばれるタスクをこなすことがモチベーションになる思考の人にアサインすると良いでしょう。反対に企業に所属することがマインドとして強い「メンバーシップ思考」の人もいます。アサインするなら「ジョブ型思考」の人です。「メンバーシップ思考」の人がいると遅延やタスクが止まることがあります。

  • モチベーションが低いメンバーがいるとき
    • 懸念点として意思決定を行う上層部に認識を共有する
    • トラブルが起こる前に共有するのがポイント
  • 新規メンバー
    • タスクをこなせる経験と専門性があるかを確認する
  • 見積もりでタスクの遂行能力を見極める
    • 能力が高いエンジニアは見積もりも正確に行う



タスクマネジメントの手順は次の通りです。

  • 手順1:タスクを洗い出す
    • プロジェクトに必要なタスクをすべて洗い出す
    • タスクは「○○を○○する」と記載sうsる
    • 「いつまでに」の部分は期間ではなく工数(何時間か)を記載する
    • 抜け漏れなく行う
  • 手順2:タスクを実施する優先順位をつける
    • ガントチャートでタスクを組み立てる
      • ガントチャートの欠点
      • タスクの抜け漏れに気づきにくい
      • 納期に合わせたスケジュールになりやすい
      • タスクの追加や変更管理が煩雑になりやすい
      • タスクを振られた人が学生症候群(作業に余裕があるほど後回しにする)になりやすい
    • 優先順位はクリティカルパス法を使う
      • 一番時間のかかるクリティカルとなる作業経路の優先度を上げる
  • 手順3:タスクを依頼する
    • 手戻りがないように配慮する
    • 背景や理由を説明する
    • タスクの優先順位と完了条件、期限を合意する
    • 定期的に進捗と課題を確認する
    • タスクのアウトプットを確認する
  • 手順4:定期的に振り返りを実施する
    • KPTを使い振り返りを行う。KPTはKeep(良かったこと)、Problem(改善したいこと)、Try(今後努力すること)に分けて話す


プロジェクトマネジメントの基本が全部わかる本 要約|プロジェクト計画。まとめ

プロジェクト計画のポイントは9つ。

  • ヒアリング
    • ヒアリングを効率的に行う
      • プロジェクトの目的、前提条件、座組、意思決定者、利害関係者、予算、スケジュール、具体的にやりたいこと。を確認する
      • 目的や前提条件など後からは変えることが難しいことを優先的に確認する
  • 座組とチームビルディング
    • 座組は一度組むと変更するのが難しい
    • ステークホルダーのリテラシーレベルを確認しておく
    • 関係者に進行を妨げるマインドの人がいるか確認しておく
  • アサイン
    • 誰に何を依頼するか決める
    • 計画時点で招集しておく
    • ベンダーを使うときは相見積もりを取るのが基本
  • 目的
    • 真に目指すべきところをとらえる
  • QCD
    • プロジェクト計画の段階で、どの基準を他よりも優先させるかを合意しておく
  • 会議体と意思決定フロー
    • 会議は参加者の時間を奪うため、設定する際は慎重に検討する
    • 意思決定のフローのディテールまで細かく口を出す権力者がいると遅延の原因になったりする
    • トラブルメーカーがいる場合は、回避方法を検討して提案する
    • アジャイル、ウォーターフォールなど開発手法を選択する
  • 契約形態
    • 請負か準委任かを確認する
  • マイルストーン
    • いつ、どの段階で、何を共有し、どんな判断が必要になるか、を事前に決めておく
  • 情報共有とやり方
    • 意思疎通の仕組みをつくる


プロジェクトマネジメントの基本が全部わかる本 要約|見積もり。まとめ

見積もりは工数を見積もって、そこから費用とスケジュールを組み立てるのが鉄則です。精度の粗い「概算見積もり」と比較的精度の高い「詳細見積もり」を段階的に出します。


プロジェクト計画段階ではブレは0.25倍〜4倍あると言われています。金額が1000万なら250万〜4000万までブレます。不確実な状態で金額や工数を求められることが多いです。見積もりを通じて「ビジネスの現実」と「プロジェクトの現実」をすり合わせていくことがプロジェクトマネージャに求められます。


いまの見積もりがどの程度の正確さをもつものか意思決定者やプロジェクトメンバーに共有することがポイントです。概算見積もりは不確実性が多い段階で提出する見積もりです。不安定な要素が多いためバッファを見込んで高く設定する方がよいでしょう。一方で詳細見積もりは不確実性をある程度つぶした状態のより正確な見積もりのことです。


見積もりの手順

  • 手順1. やることを細分化して積み上げ式で見積もる
    • 目標を実現するために誰がなにをやるかを細分化し、メンバーのタスクレベルまで落とし込む
    • 工数は1, 3, 5, 10, 15人日のような日数を使うとよいでしょう。5人日以上は5人日刻みとする
    • 見積もりの詳細には対応項目ごとに工数と単価を明記して記載してく
  • 手順2. プロジェクトバッファを見込んでおく
    • 1.2〜1.5程度の係数をかけて出す
  • 手順3. 工数をスケジュール上に可視化する
  • 手順4. 予算取りを意識する
    • 見積書は発注者側や自社内を独り歩きすることを想定して、見積もり種類と明細の内容を詳細に記載して、工数にプロジェクトバッファを見込んでおく


参考: プロジェクトマネジメントの基本が全部わかる本


\ 聞き流せる本!Audilbe無料体験期間中 /

好きな本が聴き放題!アマゾン Audible 30日間 無料体験を試す

>> 詳しく知りたい方へ!Audibleで無料で本を聴く方法を徹底解説

プロジェクトマネジメントの基本が全部わかる本 要約|契約。まとめ

契約書はプロジェクトを進める際の責任や義務について記載する重要な書類です。請負契約と準委任契約があります。請負契約とは発注者に成果物を納品しその成果物に対価を支払ってもらう契約、準委任契約は発注者の代わりに行った専門的な労働の対価に対して支払いを受ける契約です。


請負契約の場合は「成果物とは何か」「何を持って完了とするか」「本当に対応が必要か(契約不適合への対応)」「一方的な内容になっていないか(損害賠償条項)」を明確にします。


準委任契約の場合は「具体的否進め方、報告方法を決める」「善管注意義務(委任した人が期待した働きを行う義務)に違反していないか」を明確にします。また請負、準委任どちらも共通で「偽装請負になっていないか」「支払い方法」「監査の立ち入り要件」の確認をします。

プロジェクトマネジメントの基本が全部わかる本 要約|要件定義。まとめ

プロジェクトの失敗する原因の5割が要件定義です。要件定義ではプロジェクトで実現すべきことを決めます。


要件の決め方。

  • 手順1. 要求と要件を切り分ける
    • 実現したいことと、実現すべきことは異なる。発注者から要求をまとめて、具体的に検討し要件にする。要求は「○○したい」と表現し、要件は「○○する」と表現する。
  • 手順2. 決めるべきことをスケジュールの観点で見極める
    • 要件定義フェーズで詰める要件と、あとのフェーズで詰める要件を切り分ける
    • 打ち合わせと作業のバランスをとる
  • 手順3. ビジネス要件(Why)を固める
    • プロジェクトの目的を明確にする
    • 市場調査を行う
    • ビジネスモデルの確認
    • KPIを決める
    • ペルソナ設計
    • ユーザーヒヤリング
    • カスタマージャーニーマップ
    • ユーザーストーリーマッピング
    • ユースケース
    • 業務フロー
    • グロース設計
    • UI/UX
  • 手順4. 実現すること(What)の軸足と概要を描く
    • システムアーキテクチャ
    • 機能要件一覧
    • 画面遷移図
    • シーケンス図
    • ER図・テーブル定義書
    • API一覧
    • データ一覧
    • 非機能要件一覧
  • 手順5. 合意された事柄を資料化する
    • できるだけ図で表す
    • スライド作成ツールでは作らない(ページの広さに限界があるため表しきれない可能性が高い)
    • 正しい書き方よりも、伝わる資料
    • before(AsIs) / after(ToBe)を作成する
  • 手順6. 法律など社会のルールを踏まえる
  • 手順7. 要件変更や追加要件のハンドリングする
    • 変更はつきものなので、大事なのは期限を切って対応すること


プロジェクトマネジメントの基本が全部わかる本 要約|デザイン。まとめ

IT業界では目に見える画面のビジュアルや操作性などのデザインをUIデザイン、顧客体験などのデザインをUXと呼び分けています。


デザインは次の手順で考えます。

  • 手順1. ペルソナを設計する
    • ペルソンをつくって「誰に向けてつくっているのか」を明確にしていくとうまく合意形成できる
    • ペルソナは客観的な属性でつくる
    • ユーザーインタビューの意見が正しいとは限らない
  • 手順2. ビジュアル・アイデンティティを決める
    • ロゴやフォント、トーン、マナーを考える
    • プロダクトの「顔」を決める
      • ロゴは次のように考える
      • 一目でサービスを体現している
      • 大きくても小さくても判別できる
      • 白黒2色でも形がわかる
      • ロゴとサービス名は切り離して使うことを想定する
  • 手順3. プロダクトの全体像をデザインする
    • 類似するプロダクトのUI/UXの学習をする
    • ユーザにとってなにがメインの画面や機能なのか検討する
    • 検討内容をUIに落とし込む
  • 手順4. デザインを育てる発送を持つ
    • プロトタイピングを活用する。要件定義資料などで難しい表現でプロジェクトを進めるよりもプロダクトを作成した方が力を進む


参考: プロジェクトマネジメントの基本が全部わかる本


\ 聞き流せる本!Audilbe無料体験期間中 /

好きな本が聴き放題!アマゾン Audible 30日間 無料体験を試す

>> 詳しく知りたい方へ!Audibleで無料で本を聴く方法を徹底解説

プロジェクトマネジメントの基本が全部わかる本 要約|設計。まとめ

設計とは仕様を決めていくことです。手順は次の通り。

  • 手順1. 技術スタックを選定する
    • プログラミング言語、OS、ミドルウェア、フレームワーク、ライブラリなどの組み合わせ
    • 新技術を導入する際は、その学習時間も考慮する
  • 手順2. 開発の作法を整える
    • ソースコード管理
    • コーディング規約
    • 開発環境
    • デプロイ方法
    • 仕様するツール
  • 手順3. 設計書に求められる精度を確認する
    • どの設計書をどのレベルまで正確に記載する必要があるかを決める
  • 手順4. 設計書を作成する
  • 手順5. 設計書をレビューする
    • 全般
      • 機能要件
      • 正常形、異常形
      • 性能要件
      • シーケンス図
    • セキュリティ
      • 認証
      • データ構造
      • 脆弱性チェック
      • 暗号化
      • WAF/IPS/IDS
    • インフラ
      • インフラ構成図
    • データベース
      • DBスキーマ
      • テーブル定義書
    • API
      • 認証
      • セッション管理
      • 認可
      • 連携データ設計
    • アプリケーション
      • 動作ロジック
      • バリデーション
      • セッション管理
    • フロントエンド
      • 動作ロジック
      • バリデーション


プロジェクトマネジメントの基本が全部わかる本 要約|テスト。まとめ

テストは工数やスケジュールが削られやすいが、削りすぎるとパターンを網羅できずバグが発見できないリスクがあります。


テストの手順。

  • 手順1. テストとはなにか、の認識を共有する
    • ソフトウェアの7原則
      • テストは欠陥があることしか示せない。欠陥がないことは証明できない
      • 全数テストは不可能。すべての組み合わせをテストすることは難しい
      • 早期テストで時間とコストを節約。小さい規模で完成した順番にテストを行う。後になってバグがあると全体に影響する可能性がある
      • 欠陥の偏在。特定の処理や画面にバグが集中することが多い
      • 殺虫剤のパラドックスにご用心。同じシナリオやデータを使って繰り返しテストしても新しいバグは発見できない
      • テストは状況次第。状況が変わると処理結果が変わることがある
      • バグゼロの落とし穴。欠陥がないことと品質が上がることはイコールではない
  • 手順2. 各テストの定義を確認する
    • ユーザビリティテスト:ソフトウェアの使い方を確認するテスト
    • クリエイティブチェック:掲載されている情報や画像に間違えがないか確認する
    • 単体テスト、結合テスト:単一の処理でテストすることを単体テスト、複数の処理を組み合わせてテストすること結合テストという
    • リグレッションテスト:プログラム改修で想定外の影響がないか既存機能も含め確認するテスト
    • 総合テスト:全体的にソフトウェアを確認する
    • 連携テスト:別システムと連携している場合に動作確認を行う
    • 負荷テスト:運用の際の負荷に耐えられるか確認する
    • 脆弱性テスト:ソフトウェアに脆弱性がないか確認する
    • 受け入れテスト:要件通りに納品されているか確認する
  • 手順3. テストの計画をする
    • 例)
    • 単体テストと結合テストはソフトウェアエンジニアがテストコードを書いて自動化
    • 結合テストはテスト計画書を基にテスターが実施
    • 完了後に負荷テストをツールで実施
    • 脆弱性テストは事業者に委託し、発注者の検収はそれらの報告書を基に行う
    • 並行してクリエイティブチェックを行う
  • 手順4. テストをマネジメントする
    • 全体をマネジメントする人を立てる
    • 責任の追求ではなく対策を追求する
    • チケットを管理する
    • 進捗を意思決定者に定期報告する


プロジェクトマネジメントの基本が全部わかる本 要約|リリース。まとめ

不確実性を100%潰すことは不可能です。トラブル回避のために次の手順で進めましょう。

  • 手順1. 事前に日程と体制を調整する
  • 手順2. リリース計画を作成する
  • 手順3. リハーサルを実施する
  • 手順4. 関係各所に説明する


プロジェクトマネジメントの基本が全部わかる本 要約|保守改善。まとめ

プロジェクトはつくって終わりではありません。プロジェクトをビジネスの成功に結びつけます。そのために次のことを考えましょう。

  • プロジェクトの損益分岐点を考える
  • プロジェクトの固定費
    • 初期開発費用
    • インフラ費用
    • 保守運用費用
    • プロダクト改善費用
    • 分析・戦略立案費用
    • カスタマーサポート費用
    • 利用するツールや有料ライブラリの費用
  • 変動費
    • マーケティング費用
    • セールス費用
  • 売上
    • 例)売上 = 顧客数 × 顧客単価
  • 死の谷と呼ばれる、成果と投資が見合わないフェーズを乗り越える
  • ファネルモデルをつくる。認知→興味→比較検討→購入の流れを意識する



参考: プロジェクトマネジメントの基本が全部わかる本


\ 聞き流せる本!Audilbe無料体験期間中 /

好きな本が聴き放題!アマゾン Audible 30日間 無料体験を試す

>> 詳しく知りたい方へ!Audibleで無料で本を聴く方法を徹底解説

  • この記事を書いた人

おやすみドリー

本の要約をする人 | 年間100冊は本を読む | Audible(オーディオブック)、kindle(電子書籍)など読書方法を紹介 | 良い本をたくさんの人に届けたい | ビジネス書・マーケティング・自己啓発・小説を幅広くインプット | ビジネス関連・忘れない読書方法・文章の書き方なども発信中

-BOOK, IT,  ビジネス書