内容
プロジェクトの特性
「CHAOS 2020」（Standish Group, 2020）という国際的な調査では、ITプロジェクトの成功率は31%とされています。
さらに「失敗プロジェクト徹底調査」（日経SYSTEMS, 2011）という調査では、なんと94. 5%のプロジェクトが深刻な失敗を経験したと回答されており、さらにそのうちの9割が同じ失敗を繰り返しているとされています。
事業会社で業務を効率化するためのシステムを導入するプロジェクトの場合、次のような流れでプロジェクトが進んでいきます。
1.企画：プロジェクトの企画意図や必要性を検討する
2.見積り：ベンダーに見積りを取って費用やスケジュールを確認する
3.決裁（社内合意）：費用対効果やスケジュールの妥当性などを検討し、社内決裁してベンダーに発注を行う
4.プロジェクト計画：プロジェクト計画を立てて、プロジェクトを開始する
5.要件定義：要件定義とデザインを行い、開発するシステムの大枠を固める
6.設計：設計を行い、システムの仕様を詰める
7.実装：システムの実装を行い、追加要件・仕様のハンドリングを行う
8.テスト：テストを行い、システムが適切に実装されているか確認する
9.リリース：事前に決めた手順に従ってリリースと現場への導入を行う
10.保守改善：システムが適切に動作するよう保守を行い、機能などを改善する
どんなプロジェクトでも、この1〜10の基本的な流れは変わりません。
たとえば、システム開発を行わない業務改善のプロジェクトでも、なにを実施するのかを決める要件定義や業務フローの設計、必要な資料作成のタスク実行や新しい業務フローのテスト、導入プロセスの計画や実施を順に行います。
プロジェクトを行う際は、スタートからゴールまでの流れの中で「いまどのフェーズにいるのか」を意識してマネジメントしましょう。
発注（発注者）：
●経営者・経営マネジメント層：プロジェクトの QCDに関する決裁権限をもつ人
●発注担当者：プロジェクトの進行やQCDのマネジメントを行う人
●業務担当者：システムを使って業務を実施する人
ベンダー（受託開発）：
●営業：発注者と主に請求関連のやりとりをする人
●デザイナー：画面のデザインを作成する人
●フロントエンドエンジニア：画面の実装を担当するソフトウェアエンジニア
●サーバサイドエンジニア：データベースやサーバサイドプログラムなどを担当するソフトウェアエンジニア
●インフラエンジニア：サーバの構築を担当するソフトウェアエンジニア
●テスター：システムが想定通り動いているかを確認する人
どんなプロジェクトにも、どのフェーズにも共通してよく起こる失敗パターンが3つあります。
1.プロジェクトの全体像をメンバーが共有していない
2.関係者（発注者／ベンダー／メンバー／関連企業）が対等に話し合える関係性を築けていない
3.プロジェクトマネージャーが多忙もしくは能力不足で全体観を失っている
各ポジションの人は下記のような物事にもっとも関心をもつでしょう。
発注（発注者）：
●経営者・経営マネジメント層：予算やリリース時期、費用対効果が適切なものか
●発注担当者：プロジェクトの進捗や予算の確保、重要な意思決定に関する社内調整と意思決定が適切に行えるか
●業務担当者：システムが導入された際の使いやすさや効率性が確保されるか
ベンダー（受託企業）：
●営業：売上や利益が適切に確保できるか
●デザイナー：どのような画面をデザインしなければならないか
●フロントエンドエンジニア：どのような画面上の機能を実装しなければならないか
●サーバサイドエンジニア：どのようなデータや処理を実装しなければならないか
●インフラエンジニア：どのようなインフラを構築しなければならないか
●テスター：実装されたシステムが要件や仕様通りに動作するか
進捗管理
プロジェクト全体の進捗に影響しないよう、早期にミスマッチを解消することです。
タスクやポジションのアサインを変えるか、メンバーチェンジを行いましょう。
ただ、これらの対応は相手に「低評価を受けた」という印象を与え、大きな動揺をもたらします。
ネガティブな感情から、引き継ぎが適切に行われなかったり、企業やチームについての悪評をネットでまき散らしたりするなど、個人的な報復的行為に及ぶ可能性すらあります。
また、一緒に働いていた人が外されると、チームにも大きな動揺が生じます。
そこで、アサイン変更やメンバーチェンジの際は当人とよく話して、低評価を下すのではなく、あくまでもタスクやポジションとのミスマッチであることを伝え、プロジェクト上の判断としてアサイン変更が必要なことを説明しましょう。
プロジェクトが停滞している状況はプロジェクトマネージャーにとっては不快なため、他責思考となって特定の個人のせいにしがちです。
プロジェクト計画
プロジェクト計画は、次の9つの点に基づいてまとめるとよいでしょう。
1.ヒアリング──プロジェクトの要件を確認・提案する
2.座組とチームビルディング──プロジェクトの体制を整える
3.アサイン──誰になにを依頼するかを決める
4.目的──プロジェクトの真の目指すべきところをとらえる
5.QCD（品質・コスト・納期）──プロジェクトの判断基準を決める
6.会議体と意思決定フロー──適切なプロジェクト推進方法を決める
7.契約形態──請負か準委任かを確認する
8.マイルストーン──進捗を関係者で共有する
9.情報共有のやり方──意思疎通の仕組みをつくる
QCDの優先順位をプロジェクト計画の際に確認しておかないと、意思決定者の中で各基準をクリアすることに対する期待度が当初よりも大幅に上がってしまい、交渉が難しくなります。
面白かったポイント
プロジェクトマネジメントの読み物としては読みやすい。
プロマネ初心者向けの内容としてはまとまっている。
満足感を五段階評価
☆☆☆☆
目次
序章 プロジェクトマネジメントのスキルの全体像
第1章 プロジェクトとはなにか―基本的な知識と考え方をおさえよう
第2章 交渉―適切なパートナーシップを築こう
第3章 タスクマネジメント―チームでパスワークをしよう
第4章 プロジェクト計画―目標や進め方を決めよう
第5章 見積り―必要な費用とスケジュールを構想しよう
第6章 契約―不利な条件を回避しよう
第7章 要件定義―やるべきことを決めよう
第8章 デザイン―顧客が本当に必要だったものを目指そう
第9章 設計―専門家に渡すバトンをつくろう
第10章 テスト―事業リスクを最小限におさえよう
第11章 リリース―石橋を叩いて渡ろう
第12章 保守改善―事業の成功につなげよう