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

＼聞き流せる本！Audilbe無料体験期間中／

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

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

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

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

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

手順1：タスクを洗い出す
- プロジェクトに必要なタスクをすべて洗い出す
- タスクは「○○を○○する」と記載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. 予算取りを意識する
- 見積書は発注者側や自社内を独り歩きすることを想定して、見積もり種類と明細の内容を詳細に記載して、工数にプロジェクトバッファを見込んでおく

created by Rinker

＼聞き流せる本！Audilbe無料体験期間中／

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

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

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

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

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

プロジェクトの失敗する原因の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. デザインを育てる発送を持つ
- プロトタイピングを活用する。要件定義資料などで難しい表現でプロジェクトを進めるよりもプロダクトを作成した方が力を進む

created by Rinker

＼聞き流せる本！Audilbe無料体験期間中／

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

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

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

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

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

テストの手順。

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

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

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

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

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

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

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

created by Rinker

＼聞き流せる本！Audilbe無料体験期間中／