第１３回目「徹底解説！プロジェクトマネジメント」（岡村正司著）
新年第一回目は、尊敬する岡村正司氏の著書からです。
この本に興味を持てば→徹底解説! プロジェクトマネジメント
この本については、好川氏のビジネスの杜にも記載されています。
幹は５つ。
１．統合／スコープマネジメント
- 計画を練り、節目で判断
- 成功裏の開発：技術力と費用面の裏付けが必要
- スコープマネジメント：プロジェクト成果物（プロジェクト（以下ＰＪ）の最終目標）を作成するために必要な全ての作業が確実に実行することを保証するためにある
- ＰＪの選択：投資効果の観点から、ＲＯＩ（投資収益率）、ＲＯＡ（資産利益率）、ＲＯＥ（資本利益率）、ＢＥＰ分析（回収期間分析）、ＰＶ分析（現在価値分析）などを利用
- 予算・スケジュールをプロジェクトマネジメントが承認して実際の開発へ
- 作成する成果物の数と生産性→プロジェクトマネジメントの中で最も考慮すべき一要素
- ＷＢＳの作成＝ＰＪ全体を設計することに通じる
- スコープ：ＰＪの成果物、成果物を作成するための作業の範囲、具体的にはＷＢＳに記述
- プロダクトスコープ：成果物の範囲、プロジェクトスコープ：作成作業の範囲
- ベースライン：スケジュールやコストを決めるための基本となる値、発注者と開発者で合意する
- 成果物の「数」の管理ができていれば、スコープの大半は押さえることが可能
- スコープの破綻→ＰＪの失敗につながる
- スコープの変更の仕組み（一連の仕組みを用意）：要求、承認、トラッキング（変更実施の確認）、変更の内容・頻度の評価
- スコープ変更内容・発生頻度の評価も必要
- スコープ検証：ステークホルダー間の合意を得るための検証作業
２．タイム／コストマネジメント
- タイムマネジメント：作業の定義、作業順序設定、所要期間見積り、スケジュール作成、スケジュール管理
- 作業の定義：作業単位をアクティビティレベルに展開
- 作業順序設定：作業の前後関係を決定（ハードロジック（必然）とソフトロジック（任意））
- 所要期間：開発生産性、経験、専門家の判断をもとに決定
- マスタースケジュールの作成：まずはＰＪの要件（サービスイン日程、予算、要員、外部要因等）の整理
- 開発規模（開発要員）がマスタースケジュールに与える影響大
- 開発支援ツール：効果の見積りと習熟度期間を考慮（習熟してこそ本来の生産性がでる）
- プロジェクトマネジャ（以下ＰＭ）：常に現在のクリティカルパス、所要期間、コストでの問題を認識する
- リソースレベリング（資源の平準化）：まずフロートのある作業スケジュールを調整する
- 第一にプロジェクトメンバーのスキルを評価
- マネジャ：マネジメントスパン（配下の要員数）を判断（このマネジャは何人の部下をマネジメントできるか）
- 所要期間見積り：開発生産性の評価が重要
- 作業段階の件数を把握することで中間成果物の作成状況を評価→スケジュール遅延の発生原因を素早く突き止めること早道
- 進捗管理：件数ベースとコストベースの併用
- 解決を指導するチームを決める
- スケジュール管理：まずは実現可能性を判断
- 開発支援ツール：習熟曲線を知る
- コストマネジメント：資源計画、コスト見積り、予算設定、コスト管理
- コストオーバの発生←ＰＭがその技量のすべてを使って対策を打つ
- 開発コスト見積り：開発対象範囲、そこに含まれる機能を定義
- 開発規模の増大→開発生産性が大きく低下
- 開発生産性：開発規模、開発言語で大きく影響される
- マネジメントコストの見積り（どれだけ確保するか）も成功要因の一つ
- リスク＝結果額×発生可能性（結果額：予想される被害額）
- コストベースライン：局面の最初に作成、局面ごとこのベースラインと比較する
- ＥＶＭ（アーンド・バリュー・マネジメント）
- コスト計上に役立つ３つの簡易法：50-50ルール（最も適している）、20-80ルール、0-100ルール
３．品質マネジメント
- 金メッキ：時間とお金の無駄
- 品質≠グレード
- 品質マネジメント：品質計画、品質保証、品質管理
- 品質計画：品質基準を設定し、手順を決めること
- 品質保証：品質基準を満たすために品質マネジメントとして実行する計画的、体系的な全作業
- 品質管理：品質基準に適合しているか監視、不満足の場合はその原因を取り除く
- 品質＝作り込むもの、レビュー≠品質強化の最善策
- 設計の検証：不適合のコストと成果物の手直しや修正とのコスト比較によって考慮する
- 欠陥を予防するコスト＜欠陥を是正するコスト
- 品質管理にＴＱＣ（ＱＣ七つ道具）は不可欠
- 品質マネジメント：ＰＪメンバーに対する動機づけが必要
- 外部品質（発注者側からみた品質）と内部品質（開発者側からみた品質）がある
- どのチームの成果物に品質上の問題があるかを把握する
- キャパシティプラン：ＰＪの前工程で必要な資源を見積り、ＰＪの後工程、（完成に近づくにつれて必要な資源と確認する作業全体、資源効率性に関する品質マネジメントのアプローチ
- テスト資源の不足で開発生産性を確保できないのは悲劇
- 後半局面の測定は実証レベルで行う
- 効率性：設計能力そのものの指標、大型ＰＪでは成功の鍵
- 業務要件を確定する要件定義局面：どの程度まで仕様を確定できるかが重要
- 品質の確認は綿密なテストで実施
- 本番環境での実施を忘れない（システムネックを見極める）
４．ヒューマン／コミュニケーションマネジメント
- ヒューマンリソースマネジメント（組織マネジメント）：プロジェクト組織計画、要員の調達、プロジェクトチームの育成
- プロジェクト組織計画＝プロジェクト体制の構築、成果物はＲＡＭ，組織編成表等
- プロジェクトチームの育成＝チームビルディング、ＰＭが継続して力を注ぐ作業
- 体制構築がＰＪの成功に貢献する
- ＰＭは、構築する体制によってＰＪ遂行方針を表現する、局面毎に要件に合致する体制を構築する
- ＰＪ体制は局面ごとに考える
- チームビルディング：個人がやる気を出す状態を作る、チャレンジを与える
- 長所を伸ばすことで短所をカバー（富士山は高いから裾野が広い）
- チームビルディングの三大成果物：チームスケジュール、チーム体制図、ミッション定義
- コミュニケーションリンクを減らす
- 指揮命令を単純化する
- 進捗会議と意思決定会議は分離する：参加メンバーが異なる、議論のテーマが異なる
- 意思決定会議は必要なメンバーのみ出席させる
- 要員調達：コアスキルについては絶対妥協しない、コアスキルと持つ要員の確保はＰＪ成功の鍵を握る（ＰＪの現場に常駐できるかどうかはこだわらない）
- チームの推進力：チームの実質的リーダの力量による
- 問題点を１０個挙げることは素人でもできるが、解決策を一つ提示することはプロフェッショナルにしかできない
- コミュニケーションマネジメント：コミュニケーション計画、情報の配布、進捗報告、ＰＪ完了手続き
- コミュニケーションモデル：プッシュ型、ブル型、フィードバック型
- コミュニケーションの確立：ＰＪメンバーに全ての情報を開示（一番大事なのはプロジェクト成果物）、正確である（正確性）、リアルタイムである（リアルタイム性）
- 用語と単位は統一する
- 問題と原因と区別
- 問題：目標との差異、問題の大きさ＝悪影響の大きさ
- 原因：解決策＝原因を排除すること
- 懐柔→問題解決の先延ばし
- 理論的（技術的裏付けが必要）、理論武装して話を進める＝ＰＭの大事な能力
５．リスク／調達マネジメント
- リスク＝発生確率×結果額
- 定性分析と定量分析
- リスク対策：回避（原因を取り除く）、転換（リスクを他の部分に移す）、軽減（発生確率や結果額を下げる）、受容（受け入れる）
- リーダの働き：本来の工程を知り、そこに戻す作業を指導する
- サービスインの遅延→絶対に避けなければ成らない特別なリスク
- 契約：Win-Winの関係
- プロジェクトの実態を把握＝正確な情報収集が必要→PMSの利用
- 問題は目標を持っている人にしか認識されない
- ソフトウェア開発：PMBOK（選ばれた知識）を解釈し、理解することが必須
気付き
PMBOKに基づいてPJを実施する時の注意点とともに、著者の経験に基づいたマネジメントの方法が分かりやすく記載されています。
PMBOKに記載されていることを実際にどの様に活用すべきか、著者の考えをベースに記載されています。
PMの経験のある方にとっては、当たり前のことと思われることもありますが、非常に役立つこと、実際に実施すべき事項が随所に散りばめられています。
PMBOKを勉強している方も、参考の一助になると思います。
それにしてもエッセンスが多すぎました。何回もフォトリーディングする価値がありそうです。
１２月受講生のみなさん、今年も目標に向かってがんばりましょう。
