プロジェクトマネジメントの基本が全部わかる本 交渉・タスクマネジメント・計画立案から見積り・契約・要件定義・設計・テスト・保守改善まで
Contents-list
これはなに？
プロジェクトに必要な最低限の要素を押さえるためのメモ
題材：プロジェクトマネジメントの基本が分かる本
PMBOKなどの知識体系
失敗から学ぶOJTスタイルだと、成功体験を積めずに挫折してしまうことも
スキル見取り図
プロジェクト計画・見積もり・契約
→要件定義
→デザイン→設計→テスト→リリース→保守改善
大事なこと
スキル分析
具体的に自分（相手）が最初から最後までその業務を実施できるか・実施したことがあるか
プロジェクトとは。。
今ある状態からあるべき別の状態にするために行う、スタートからゴールまで続く複数の業務
プロジェクトの本質的な特性
1. スタートとゴールが決まっている
2. 不確定要素が多い
3. 異なる立場や専門性を持つ人が分業してかかわる
よくある失敗例
• プロジェクトの全体像をメンバーが共有していない
• 関係者（発注者/ベンダー/メンバー/関連企業）が対等に話し合える関係性を築けていない
• プロジェクトマネージャーが多忙もしくは能力不足で全体感を失っている
プロジェクト固有のリスクをマネジメントする
• できるだけ早期に検討や調整を行ってリスクを潰しておく
よくある課題
1. 現場で使える知識体系がない
2. 無茶振りされる
3. スキルの属人化
プロジェクトとは何か
今ある状態からあるべき状態にするために行う、スタートからゴールまで続く複数の業務
プロジェクトの目的と目標
目的：最終的な到達点
目標：達成するべき基準
プロジェクトの目標は一般にQCD（Quality, Cost, Delivery）によって定義することができる。QCDはトレードオフの関係なので、進行によって調整をする必要がある。
プロジェクトの特性
失敗率の高さはプロジェクトの3つの基本的な特性に由来する
– スタートとゴールが決まっている
– 不確定要素が多い
– 異なる立場や専門性を持つ人が分業して関わる
プロジェクトの難しさ
失敗を後で取り返すことが難しい。挽回するために大きな時間と予算を必要とする。
よくある失敗パターン！
1. プロジェクトの全体像をメンバーが共有していない
2. 関係者（発注者/ベンダー/メンバー/関連企業）が対等に話し合える関係性を築けていない
3. プロジェクトマネージャが多忙、もしくは能力不足で全体感を失っている
プロジェクト固有のリスクをマネジメントする
できるだけ早期に、検討や調整を行いリスクを潰す
第二章 交渉
・交渉の際に必要なマインドセット
無理なことは率直に伝えること。
相手が誰であろうと是々非々で「あるべき進め方」を提示していく。
フラットに意見を聞き、方向性を示す。
多角的な情報を集めてみんなの意見を聞きながら、関係者に方向性を指し示すようなやり方がリーダーシップとして最適
交渉の際に気を付けるポイント
1. ヒアリングの機会を定期的に設ける
2. コミュニケーション手段を使い分ける
同期（曖昧な物事の相談）・非同期(伝達)
言語・非言語
3. 説明資料と議事録を文書化する（自分を守るため）
4. 相談内容や決定事項は関係各所に共有する（聴いていない！を避ける）
プロジェクトの目的や進捗、課題事項や変更点などは随時報告しておく
5. フォーメーションを組んで交渉する
交渉の効果的な進め方
・プロジェクトを進める中で懸念点をあらかじめ説明する
→PJがどのような影響を与えるかの視点は持っていないことが通常
・エビデンスを主体に説明資料を作成する
→言った・言わないの状態を避ける≒ファクトベースに話すと心理的負荷を軽減することができる
・最終的な着地点を明確にする
ハードな交渉は必要最低限に絞り、プロジェクトを適切に完了するためには何が必要なのかを明示する
・会社間の交渉内容はあらかじめ組織内で合意しておく
独走しない。
「仲の良さ」と「信頼関係」の違いを理解しよう
PMは一歩引いて、冷静な関係性を構築するようにするなど、役割の切り分けを行うと良いでしょう。
第三章 タスクマネジメント
・タスクマネジメントはタスク管理ではない
タスクマネジメントを通じてプロジェクトが適切にゴールに向かっているか確認しながらコントロールする司令塔
・アサインは「ジョブ型思考」の人が望ましい
タスクを実行できるだけの技術や経験があることは前提として、マインドもよく見る必要がある。※「メンバーシップ型」（所属意識が強い）人のアサインは避ける。肩書きでアサインすることは避ける。
・アサイン変更の際の注意点
モチベが低いメンバーがいる場合：
すぐにプロジェクト体制上の懸念として意思決定を行う上層部に認識を共有しておく
・タスクの遂行能力を見極める
新規メンバーの見極め方：
なるべく早くスキルを確認する
・見積もりでタスク遂行能力を見極める
「やってみないとわからない」というようなスタンスのメンバーは経験不足で遂行能力が低いか、責任回避的でタスクに積極的に取り組むマインドがないかのどちらかであることがほとんど
タスクを洗い出す
タスク名は「〇〇を〇〇する」と記載する
「いつまでに」の部分は機関ではなく、工数を記載する
抜け漏れなく行う
タスクを実施する優先順位をつける
ガンドチャートよりもクリティカルパスがおすすめ
タスクを依頼する
タスクの目的とプロジェクト上の背景を説明する
タスクの優先順位と完了条件、期限を合意する
定期的に進捗と課題を確認する
タスクのアウトプットを確認する
定期的に振り返りを実施する
チームのパフォーマンスを底上げする（KPT）
第四章 プロジェクト計画
プロジェクトが始まったら、最初に「プロジェクト計画」を立てる
ヒアリング：プロジェクトの要件を確認・提案する
座組とチームビルディング：プロジェクトの体制を整える
アサイン：誰に何を依頼するかを決める
目的：プロジェクトの真の目指すべきところを捉える
QCD（品質・コスト・納期）：プロジェクトの判断基準を決める
会議体と意思決定フロー：適切なプロジェクト推進方法を決める
契約形態：請負か準委任かを確認する
マイルストーン：進捗を関係者で共有する
情報共有のやり方：意思疎通の仕組みをつくる
ヒアリング：誰がキーパーソンか
後から変えることが難しい条件を優先的に確認する
目的(何のためにプロジェクトをやるのか)
前提条件（必ず守る必要がある条件はなにか）
座組（連携が必要なメンバーや企業はどこか）
意思決定者（決済権限を持つ人は誰か）
利害関係者（得する人・損する人）
予算(適切な予算があるか)
スケジュール（適切な実施期間はあるか）
具体的にやりたいことは何か
座組
ステークホルダーのリテラシーレベル
関係者のマインドチェック
アサイン
ベンダーからは複数社から相見積もりを取るのが基本
QCD（品質・コスト・納期）
プロジェクトの方針の意思決定はQCDの基準を基に行います。
プロジェクト計画の段階で、どの基準を他より優先するのかを合意しておきましょう。優先順位を計画の際に確認しておかないと、意思決定者の中で各基準をクリアすることに対する期待度が当初よりも大幅に上がってしまい、交渉が難しくなります。
会議体
会議は簡単にプロジェクトメンバーの時間を奪ってしまうので、設定する際は慎重に検討すること
意思決定について
ワンマン社長や多忙すぎる担当者がいると、プロジェクトをスムーズに進めることができず、大きな遅延の原因となる
契約形態
マイルストーン
あらかじめ発注者や社内の意思決定者に、「いつ、どの段階で、何を共有し、どんな判断が必要になるのか」を事前に決めて定期的に報告することをプロジェクト計画の時点で伝えておきます
第五章 見積もり
必要な費用とスケジュールを構想しよう
見積もりは工数を見積もって、そこから費用とスケジュールを組み立てる。今提示している見積もりはどの程度の正確さを持つものかを意思決定やプロジェクトメンバーに明確に共有することがポイント。
概算見積もり：現時点でを明確に伝える。バッファを見込んで高めに出す。
詳細見積もり：明確にやるべきことがわかっている状態
ボトムアップ見積もり方式
やることを細分化して積み上げ方式で見積もる
プロジェクトの目標を実現するには誰が何をやらなければならないかを細分化して、メンバーのタスクレベルにまで落とし込みます。見積もり明細には対応項目ごとの工数と単価を明記して記載しておく
プロジェクトバッファを見込んでおく
バッファがどれくらい必要なのかは、PJによって様々。1.2-1.5くらいの計数をかけて出す方法がある。
工数をスケジュール上に可視化する
予算どりを意識する
第六章 契約
不利な条件を回避しよう
契約書はプロジェクトを進める際の責任や義務について記載する重要な書類です
請負契約
発注者に「成果物」を納品しその成果物に対価を支払ってもらう
ex. 実装・テスト
準委任契約
発注者の代わりに行った専門的な「労働」の対価について支払いを受ける
ex. 要件定義・設計
請負契約のチェックポイント
成果物は何か？成果物に何を書くかでプロジェクトの負担が大きく変わる顧客が「検収」した際に、契約内容と異なる場合は無償で対応しなければならない「契約不適合」への対応が発生する。
何をもってプロジェクトを完了とするか「検収の条件」をあらかじめ決めておかないと、契約不適合の無償対応を迫られ続けることになる
それは本当に対応が必要か（契約不適合への対応）契約書は契約不適合による不利益を防ぐ！「その要求は本当に契約不適合にあたるのか」を契約書で確認するようにしよう
一方的な内容になっていないか（損害賠償条項）損害賠償責任が青天井になっている場合は上限額を記載するようにしよう
準委任契約のチェックポイント
作成する資料や具体的な進め方、報告方法は共有できているかどのくらいの期間と工数を使えばどのような成果を得ることができるのか、お客様に共有するる。受注者は納得感を得てもらうことにも気を配りましょう
「善管注意義務」に違反していないか？「業務を委任された人の職業や専門家としての能力、社会的地位などから考えて通常期待される注意義務」が善管注意義務。プロとしての姿勢が重要。
共通するチェックポイント
偽装請負になっていないか？・発注者は受注者の労働者に指揮命令や業務管理をできないようにする・発注者と受注者の体制を明確に分ける
支払サイトと支払い方法は確認できているか少しでも支払いを遅くして自社の資金繰りを有利にしようとしている契約がある大企業では現金化に時間のかかる「手形」を発行するケースがある→下請代金の支払いは、できる限り現金によるものとすること
監査の立入要件が入っているか他企業との守秘義務の関係上、上記のような一方的な条文は現実的とは言えない
まとめ
契約書はトラブルが発生した時だけでなく、未然に防ぐためにも重要な書類となる。企業も人間同士が集まっているものなので、当然勘違いも起こる。
過剰な要求を受けた際には「それは契約外なので別途協議しましょう」と言えるよう、内容は十分チェックして必要な交渉をして締結するようにしましょう。
第七章 要件定義
やるべきことを決めよう
要求と要件を切り分ける
決めるべきことをスケジュールの観点で見極める
ビジネス要件(Why）を固める
プロジェクトの目的を明確にする
市場調査
競合調査
ビジネスモデル
KPIツリー
ペルソナ設計
ユーザーヒアリング
カスタマージャーニーマップ
ユーザーストーリーマッピング
ユースケース
業務フロー
グロース設計
UI/UX
「実現すること」（What）の軸足と概要を描く
システムアーキテクチャ
機能要件一覧
画面遷移図
シーケンス図
ER図・テーブル定義書
API一覧
データ移行
非機能要件一覧
合意された事柄を資料化する
できるだけ「図で表現する」
スライド作成ツールで作成しない
「正しい描き方」よりも「伝わる資料」
before(AsIs)/after(ToBe)を作成する
法律など社会のルールを踏まえる
時勢に応じて変わるので、チェックすること
要件変更や追加要件のハンドリングをする
期限を切ることが大事。相手が言うことを要求として一旦受け止める。
第八章 デザイン
顧客が本当に必要だったものを目指そう
デザインはプロセスでまとめる
うまく進めるために、、
ペルソナを設計する誰に向けて作っているのかを明確にしていくとうまく合意形成ができるペルソナは客観的な属性で作るユーザーインタビューの意見が正しいとは限らないすでにあるプロダクトを客観的に評価する際には、ユーザーインタビューは有効だが、新しいものを作る際にはあまり参考にならないことが多い。
ビジュアル・アイデンティティを決めるロゴやフォント、トーン&マナーを考える
プロダクトの全体像をデザインする（1）類似するプロダクトのUI/UXを学習する（2）ユーザーにとって何がメインの画面や機能なのかを検討する（3）検討内容をUIに落とし込む
「デザインを育てる」という発想を持っておくプロトタイピングでUXを育てる
第九章 設計
専門家に渡すバトンをつくろう
要件の実現方法を決める
できるだけ曖昧さを残さない。
設計とは、仕様（あるべき動作や構造など）を決めていくこと
技術スタックを選定する
技術スタックの選定はビジネスに影響する。技術スタックとはプログラミング言語やOS、ミドルウェア、フレームワーク、ライブラリ、インフラスペックなど、実際にプロダクトを制作する際に使用する技術の組み合わせのこと。
開発の「作法」を整える
専門家の間でどのように仕事を進めていくかの「作法」をチームで合意しておく- ソースコード管理- コード規約- 開発方法- デプロイ方法- コンテナ- 使用ツール
設計書に求められる精度を確認する何を書くのかを決める。
設計書を作成する基本設計から着手する。技術的負債とは行き当たりばったりなソフトウェアアーキテクチャと、余裕のないソフトウェア開発が引き起こす結果のこと
設計書のレビューITプロダクトレビューで重要な観点全般・セキュリティ・インフラ・データベース・API
設計は大変なプロセス
簡素でも必要最低限の設計は行ったほうがいい
第十章 テスト
事業リスクを最小限に抑えよう
テストは軽視されやすい反面、事業リスクにも直結する重要なフェーズです。限られた工数やスケジュールでいかに効率的に品質を担保できるかを念頭にマネジメントを行いましょう
テストを軽視することで発生する3つのリスク
1. 「できるはずのこと」ができない
2. 「プロダクトが悪用されていることに気づかない」
3. 「開発企業や開発チームとしての責任を問われる」
※民法改正に基づき請求できる内容
追完請求：
引き渡した商品の修理の請求（修補請求）
または不具合のない商品の引き渡し請求（代替品引渡し請求）
損害賠償請求：
損害は発生した場合は損害賠償請求が可能
代金減額請求：
購入代金の減額の請求
契約解除：
契約を解除して代金の処遇を請求することが可能
適切なテストの進め方
「テストとはなにか」の認識を共有するソフトウェアテストの7原則
テストは「欠陥がある」ことしか示せない
全数テストは不可能
早期テストで行かんとコストを節約
欠陥の偏在
殺虫剤のパラドクスにご用心
テストは状況次第
「バグゼロ」の落とし穴
各テストの定義を確認するユーザビリティテスト：使いやすさのチェッククリエイティブチェック：情報に間違いがないか単体テスト・結合テスト：処理や機能・複合の機能をテストリグレッションテスト：PG改修時のチェック総合テスト（シナリオテスト、システムテスト）連携テスト（システム間テスト）負荷テスト脆弱性テスト受入テスト（検収）テスト駆動開発
テストを計画する単体・および結合テストまではテストコードで自動化総合テストはテスト計画書をもとにテスターが実施完了後に負荷テストをツールで実施脆弱性テストは事業者に委託し、発注者の検収はそれらの報告書をもとに行う脆弱性テストは事業者に委託し、発注者の検収はそれらの報告書を基に行う並行してクリエイティブチェックを行う
テストをマネジメントする必ずテスト全体をマネジメントする人を立てる責任の追求ではなく対策を追求するチケット（タスク）で管理するどの順番で対応追うすべきかの優先度（着手順）を都度伝える進捗を意思決定者に定期報告する：1-2回/週
第十一章 リリース
石橋を叩いて渡ろう
リリースは事前の準備が肝心
不確実性は完全には無くせない。
リリースは4つの手順で進めることがトラブル回避の近道
事前に日程と体制を調整する（連休前などは避けた方が無難）メンバーが確実に稼動できる日にリリースしないと、トラブル発生の対応ができない。
リリース計画を作成するタイムラインに沿って考える緊急時の対応計画リリース計画の策定
リハーサルを実施する想定していた手順に齟齬があったり、想定よりも時間がかかったりする場合などはリリース計画を見直しましょう。
関係各所に説明するリリース計画は、必ず現場レベルから経営層のトップ、広報など対外的な窓口の対応者まで事前に説明しておきます。
第十二章 保守改善
事業の成功に繋げよう
プロジェクトの費用対効果
プロジェクトとは、より大きな事業としての成功を実現するために始める
→プロジェクトと事業を切り離さないこと
損益分岐点でプロジェクトの費用対効果を判断する
→損益分岐点とは、売上が投資した費用を上回る点のこと
固定費
初期開発費用
インフラ費用
保守運用費用
プロダクト改善費用
分析・戦略立案費用
カスタマーサポート費用
利用するツールや有料ライブラリの費用
変動費
マーケティング費用
セールス費用
事業の目的に向かってプロジェクトを繰り返し成功させる
