プロジェクトマネジメント入門（というか「お仕事のお作法」）

先週が体調の底だったようで、今週は徐々に上昇してきた。ようやく目先の仕事を片付けることができて、ToDoがとんでもないことになっていた。加速装置のスイッチをいれないと仕事が終わりそうにもないのだが、しかし、こいつを使うとまた倒れるかもしれないので慎重にしなければならない。悩ましいところである。
さて、今週、へろへろになりながらも、新任プロジェクトリーダー向けのプロジェクトマネジメント研修の講師をこなしたが、来月のはじめには新入社員向けのプロジェクトマネジメント研修のコマがある。新任プロジェクトリーダー向けの研修の資料を流用できるから、集中すれば準備作業はそれほど手間はかからない予定だが、話の内容、レベルは調整しなければならない。
アイデアをまとめるために、レジュメ（案）を書こうと思う。テーマはプロジェクトマネジメント入門となっているけれど、実際の内容は「お仕事のお作法」という感じになると思う。
0. 新入社員がプロジェクトマネジメントを学ぶ意味
・プロジェクトマネジメントはあらゆる仕事の進め方につながる
・プロジェクトの部分を任されることは、その部分のプロジェクトマネジメントをしなければならないことを意味している
・将来的にはプロジェクトマネジャー、プロジェクトリーダーになることを期待されていいる
1. プロジェクトとは
(1)プロジェクトの定義
・「プロジェクトとは、独自の製品、サービス、所産を創造するために実施される有期性の業務である。」(PMBOK第三版)
・プロジェクト／定常業務
→プロジェクトには必ず始まりと終わりがある
(2)プロジェクトの主要な構成要素
・目的（アウトプットの品質）
・コスト
・期限
・リソース
→プロジェクトには制約（コスト、期限、リソース）がある
(3)プロジェクトのステイクホルダー（関係者）
・お客様
・プロジェクトオーナー、プロジェクトチーム（プロジェクトマネージャー（プロジェクトリーダー）、メンバー）
・その他プロジェクトの利害関係者
→もちろんお客様は王様だけれども、その他のプロジェクトの利害関係者が大きな力を持っていることもある
→プロジェクトは「生き物」だから、公的な役割分担と実質的なリーダー（主導権を持つ人）は一致しないこともある（顧客から主導権を奪うことを考えるべし）
→ステイクホルダーを説得できれば主導権を握れる。説得できなければ全体の方針に歯をくいしばって従って仕事をする（宮崎駿）。

出発点―1979~1996

(3)プロジェクトの成功／失敗
＜成功＞
・コスト、期限、リソースの制約の下、プロジェクトの目的を達成（所定の品質のアウトプットを提供）すること
→品質、コスト、期限、リソース(QCDR)はトレードオフの関係にあるのでバランス（最適化）をとることが必要
→複数のプロジェクトに参加している場合には、それらの間のトレードオフも意識してバランスをとること
＜失敗＞
・プロジェクトの目的が達成できない
・コスト、期限、リソースの制約を守れない
→制約が守れなければ「過剰な品質」もプロジェクトの失敗
(4)プロジェクトを成功させる前提条件
・ステイクホルダーがプロジェクトの目的について合意・意識を共有している
→常に再確認すること
→腑に落ちないことは放置しないこと（例：あいまいな会議の結論は再確認、気になることは文書化してみる）
2.マネジメントの基本
(1) PDCAサイクル
・Plan：計画を立てる
・Do：計画に基づき実行する
・Check：実行した結果と計画の差異をチェックする
・Action：計画と差異（＝課題）に対処する
(2)定期的なサイクルとリズム
・なるべく定期的（日次、週次、隔週、月次、マイルストーン）にPDCAサイクルを回す
→オフラインでPDCAサイクルを回すことはできるが、可能であればミーティングをすること
→プロジェクトにリズムができて安定して仕事が進むようになる
→お客様とのミーティングも定期的にすることも効果的
(3)進捗ミーティングで確認すべきこと
・プロジェクトの目的、アウトプット、マスタースケジュールの確認、プロジェクト計画の変更の確認
・前回ミーティングからの進捗状況、課題への対処状況
・進捗遅れ、新たに発生した課題の確認
→放置して解決する課題はない、課題を解決するには「何か」（方法、メンバーなど）を具体的に変えなければならない（「やる気」「意志」では課題は解決しない、「がんばります！」は危険なサイン）
→課題の解決には文殊の知恵方式で（当事者とプロジェクトリーダーだけが抱えるのではなく、他のメンバーも知恵を出す、助け合うチームづくり）
・次回ミーティングまでのToDo、アウトプットイメージの確認
→アウトプットイメージはあいまいさをのこさずに共有する
→無理な作業の割り当て、締切は設定しない（結局守れないだけ）
・決定事項はかならず文書化
→メールでもよい（もちろんプロジェクト記録を利用してもよい）
3.計画
(1)分割とMECE
・仕事の難易度を下げるために作業を分割する
→分割するほど作業の難易度は下がるがマネジメントの手間は増大する
→相手の能力を見て作業の分割のレベルを決める（大きすぎず、小さすぎない単位の作業を任せる）
・プロジェクトの作業への分割はMECE（だぶりなくもれなく）で
→もれがあるとプロジェクトが破綻（完成しない）
→だぶりがあると効率性が低下
(2)WBS(Work Breakdown Structure)
・プロジェクト計画の基礎
→WBSでプロジェクトのスコープ（作業・アウトプット）を定義
→スコープ、スケジュール、コスト、体制（分担）を矛盾なく統合する
・ロジックツリーの構造でプロジェクトの作業・アウトプットをMECEに分割
→プロジェクトマネジメントそのものの作業（計画、会議、レビュー、手続きなど）も忘れない
・WBSの粒度（分割の細かさ）はプロジェクトのその時点、状況、目的に依存
→スケジュール、コスト、分担を決めるために必要な粒度で分割
→プロジェクトの進行に応じて段階的詳細化（ローリングウェーブ）する
→プロジェクトリーダーが大きな仕事の分割、分担を決め、分担内の詳細化は担当者が行うことも
(3)スケジュール
・マイルストーンの設定
→納期、中間報告（委員会）など目標とすべき最終・中間の締切を設定
・作業の依存関係に留意し、ガントチャートを作成
→中小規模のプロジェクトではガントチャートでスケジュールの作成は可能
→大規模な複雑なプロジェクトでは専用のソフトウェア(MS Projectなど)を活用
・実行可能性について吟味する
→無理のあるスケジュールは「必ず」破綻するので無意味（「無理のないスケジュール」と思ってもたいてい遅延する）
→体制（アサインしたメンバーの稼働状況）などによってスケジュールの調整が必要
・スケジュールの短縮方法（コストとトレードオフの関係にある）
→ファストトラッキング：作業の着手を前倒しにする
→クラッシング：リソースを追加投入して作業期間を短縮
(4)コスト
■人工費
・人工費＝時間×時間単価
・WBSのタスクごとに時間を想定
→経験にもとづく（自分がどの程度の時間をどの作業に費やしているか記録を取ると将来の作業見積もりに役立つ）
→想定が困難な場合にはWBSを細分化する
■直課経費
・外注
→仕様を詳細化、明確化するほど価格を低減できる（仕様があいまいだと外注先が安全を見込んで高めの見積をする）
→原則、複数の見積をとる（本命が決まっていたとしても）
■その他経費
・仕様・企画で数量（アンケートの件数、インタビューの対象者数）などを具体的に想定する
(5)リスク
・「既知の未知」と「未知の未知」
→想定しうる不確定要因：リスク（既知の未知）にはあらかじめ対処できる
→リスクの大部分は過去に経験したことの反復：チェックリストで想定可能
・余裕をもった計画
→スケジュールは「必ず」遅延し、コストは「必ず」オーバーするので余裕のもった計画を立てる
→「余裕」のマネジメントはプロジェクトリーダーがすべき（メンバーがリーダーに隠れて勝手に余裕を見込まない）
4.実行とチェック
(1)チームの形成
・必要な情報を共有すること
→率直なコミュニケーションができる関係が重要
・目的を共有すること
→「仲良し」である必要はない（摩擦も当然、必要なこと）
→共有した目的に向かって進むという意識は必須（これがあればプロジェクトは前進する）
(2)自己マネジメント
・マイルストーン（締切）
・アポイントメント
・ToDo
→日次、週次、月次で定期的に確認
→やり方は「継続できる」方法で（ツール、参考書はたくさんある）
＜自分のツールの紹介＞
(3)コミュニケーション
・報連相
→マネージャー、お客様は想像以上に自分のことを理解していない
→課題はなるべく早く相談（あっさり解決することも多い）
→自分の課題の解決は辛い、他人の課題を解決することは楽しい（助け合ったほうがよい）
→「やばい」ということを感じる感度を磨く
・会議のお作法
→事前連絡：日時、出席者、場所、目的（ブレスト、課題解決、意思決定、オーソライズ）、アジェンダ、役割分担（議事録作成）、資料
→事前準備：自分の貢献できること、議事録（記入すべきところは記入）
→進行：遅刻しない、ホワイトボード、時間通りに終える、結論を確認
→まとめ：議事録は早く、結論を中心に

会議が絶対うまくいく法

(4)レビュー
・品質を高めるためには第三者のレビューを丁寧にすることにつきる
・レビューをするためには、スケジュール、レビューアーのアサインを計画しておくことが必要
・チーム内でのレビューには率直に
→上下関係は意識しない
→専門家ではないからできる指摘も多い
(5)フォーマットの活用
・プレゼンテーション、報告書は標準フォーマットを活用
→複数でやるプロジェクトの効率化、他のプロジェクトへの再利用が可能になる
＜標準フォーマットの紹介＞
5.プロジェクトマネジメントのためのシステム・ツール
(1)プロジェクトマネジメントのためのシステム
＜略＞
(2)ナレッジシェアのためのシステム
＜略＞
6.完了とまとめ、教訓
(1)お客様からのフィードバック
・プロジェクト完了時（遂行中も含めて）お客様のフィードバックを得る
→率直な意見を聞ける関係づくりを
→お客様の中、ステイクホルダーによって評価が違うことがある
→CS調査結果（特にコメント）は必ずチェックする
(2)チームでの振り返り、教訓のまとめ
・チームメンバーで飲み会（ランチミーティングでも）、打ち上げをかねて振り返りの会を
・自分なりにプロジェクトから得た教訓をまとめておく
→優れたアスリートはかならず詳細なノートを作っておく
(3)再利用できるプロセス資産の整理
・効率化のために再利用できるフォーマットなどは再利用・共有できるように整理する（「内容」の流用はダメだが）
→WBS、見積、企画書、書式、チャートなど
6.お仕事のお作法と心得
(1)お作法
・プロジェクトは生き物
→目を離すとすぐ休眠する、世話をしないと死んでしまうことも
・マネジメントはめんどくさい
→意志に任せない、習慣（リズム）と仕組み（自分の虚栄心を利用する、他人に監視してもらう）を作る
・考えてから着手、しかし、今は考えないという決断もある
→やみくもに着手せず、MECEを意識して最短コースで作業を進める
→先のことはあえて「今は」決めない（情報が入手できるまで）という決断もある（段階的詳細化）
(2)心得
・リアルに、客観的に
→自分の能力は過大評価／過小評価しがちだが、結局は「できることしかできない」
→計画はリアルに、客観的に
・率直であること
→必要な情報を共有することがプロジェクト成功のための必須条件
→摩擦があっても率直であることが最終的には重要、信頼を獲得できる
・心配させない、督促させない
→業務の計画・状況・見込みの情報は共有する
→お客様、マネージャーは「どうなっているのかわからない」状況を最も心配する
→問題があっても、問題があることが明確であれば対処できる
参考文献

考える技術・書く技術―問題解決力を伸ばすピラミッド原則

世界一わかりやすいプロジェクト・マネジメント【第３版】

A Guide to the Project Management Body of Knowledge: Official Japanese Translation(プロジェクトマネジメント　知識体系ガイド　PMBOKガイド)

以上