こんにちは、チャイフ(@chaif123)です。
『プロジェクトを変える12の知恵』という本を読了いたしました。
著者・影山明氏が勤めていた「ケンブリッジ・テクノロジー・パートナーズ」というコンサルティング会社で浸透していた12のルールを紹介してくれている本になります。そのうち、僕が特に重要だと感じ、かつ自分の仕事で実践できそうな6項目についてまとめてみました。
それでは!
※ちなみに、想定する読者は「プロジェクトマネージャー」の方々です。仕事としてでもいいですし、プライベートで何かしらのイベントの企画をやろうとしている方も含めます。
プロジェクトマネージャーってめちゃめちゃ大変です
本の内容に入る前に、プロジェクトマネージャーってめちゃめちゃ大変なんですよ、って話をします。
興味がない人あるいは完全に理解している人は2 重点項目6選まで飛ばしてください。
プロジェクトマネージャーとは?
プロジェクトマネージャーとはどんな仕事でしょうか?
細かい所掌範囲や定義は会社によって異なるとは思いますが、共通する要素としては、「納期までに成果物を完成させられるように、プロジェクトをマネジメント(≒管理)する」仕事ではないでしょうか。
そのために、例えばこんな業務が挙げられるでしょう。
- キックオフ
- クライアントの要望から計画の立案
- 全体スケジュールの作成
- 担当メンバーのアサイン
- プロジェクト推進
- マイルストーン管理
- 担当メンバーの進捗管理
- 担当メンバーのモチベーション管理
- プロジェクトのコスト管理
- クライアントへの進捗報告
- 問題発生時の対応
- クロージング
- 納期の調整
- 成果物の取りまとめ
- クライアントへの成果報告
なぜプロジェクトがうまく回らないのか?
プロジェクトマネージャーの業務内容はざっくりは上記のような項目になってくるのですが、実はそれだけではありません。
なぜなら、プロジェクトごとにあらゆる性質が異なります。
- プロジェクトの難易度
- 要求される粒度・頻度・知識
- 適切なツール
- クライアントの性質
これらをできるだけ正確に認識し、臨機応変に適切な対応を執る必要があるからです。
例えば、以下のようなことがあるかもしれません。
- プロジェクトAではメンバーにほぼ丸投げで済んでも、プロジェクトBではこまめに擦り合わせを行う必要があるかもしれません。
- プロジェクトAではとても活躍できたメンバーが、プロジェクトBではあまり活躍できないかもしれません。
- プロジェクトAでは有効に機能したツールが、プロジェクトBでは役に立たないかもしれません。
- プロジェクトAでは月2回のミーティングでよくても、プロジェクトBでは週3回ミーティングをしなければならないかもしれません。
- プロジェクトAでは結果だけを報告すればよくても、プロジェクトBでは過程を詳細に厳密に報告する必要があるかもしれません。
これらの項目は全て目には見えない要素かつ、誰も答えを知っていないので、教えてもらうこともできません。
つまり、情報を整理してプロジェクトマネージャーが自分で判断する必要があります。
ここの判断を間違えると(もちろん定量的なものではない以上「あっている」「あってない」のゼロヒャクではありません。「適切度が低いと」くらいのニュアンスになります)、プロジェクトが進行していく中で、どこかで問題が生じます。
「情報共有」が正確かどうかで、プロジェクトのリスクが変わる
プロジェクトは、例外なく人が手を動かして進めていくものです。
まず大前提ですが、人から人へ情報を伝える際に、100%伝えることは不可能です。
とはいえ、90%も伝われば10%の認識齟齬があっても問題にはならないかもしれません。80%でも、大丈夫かもしれません。では70%ならどうでしょう?50%なら?
このように、「情報共有」の伝達度が下がれば、そのぶんプロジェクトの中で問題が生じる可能性(リスク)が上がっていきます。
そして重要なこととして、プロジェクトマネージャーはプロジェクト全体の情報交差点です。10人のプロジェクトなら10人の、100人のプロジェクトなら100人の人間が、プロジェクトマネージャーに「情報」を求めてきます。
したがって、プロジェクトマネージャーは必然的に、次の2つの基礎能力を要求され、これらがうまく機能するかどうかが、プロジェクト全体のリスクに直結します。
- クライアントから情報を正しくキャッチする能力
- メンバーに情報を正しく伝達する能力
重点項目6選
プロジェクトマネージャーがめちゃくちゃ大変であるということを再認識したところで、本題である『プロジェクトを変える12の知恵』の重点項目6選を紹介しましょう。
これらは間違いなく、上記のような課題を解決する助けになってくれます。
プロジェクト・ゴールとCSF
第一に、プロジェクト・ゴールとCSFです。
目的地を決めずに走り出すことほど意味のないことはありません。
プロジェクト・ゴール
プロジェクト・ゴールとは、文字通りプロジェクトが目指すところです。
いわば「これを達成すればプロジェクトは成功である」という評価指標、判断基準です。プロジェクト・ゴールを決める際の必須事項が、以下の2つになります。
- 具体的に決める
- 経営層を巻き込んで決める
ここでの「具体的」とは、「定量的」を指します。
「この数字を達成する」という基準を設ければ、プロジェクト終了時に成功・失敗を客観的に、確実に判断できます。逆に言えば、プロジェクト・ゴールを設定していないプロジェクトに、成功はありえない(誰にも判断できない)ということになります。
CSF(Critical Success Factors)
CSFとは、Critical Success Factorsの略で、主的成功要因と訳しています。
いわば、プロジェクト・ゴールを達成するために必ず通るべき道・ポイント・条件です。プロジェクト・ゴールを一段階具体的な目標へとブレイクダウンしたもので、これに期限を設けたものがマイルストーンになるんだろうと解釈しています。
これは、作業計画を立てるときの、このCSFを道標として機能します。あるアクションを実施するかどうか迷ったときに、「CSFに向かえているかどうか」を判断材料にできる、ということですね。
グラウンド・ルール
第二に、グラウンド・ルールです。
最初に言質をとっておくことは、後々のトラブルを防ぎます。
グラウンド・ルールとは?
グラウンド・ルールとは、「その場を共有する人が守るルール」という意味です。ベース(基盤)となるルール、というイメージですね。
プロジェクトの中では、誰しもがこのルールに則って行動します。「永続フィールド魔法カード」みたいなものです。
グラウンド・ルールを決めるタイミングは、プロジェクトが始まるときに行うノーミング・セッション(本書参照)のタイミング。
グラウンド・ルールを決めるメンバーは、プロジェクトメンバー全員で話し合って決めるのが良いそうです。
本書で挙げられている例は、大きく3つのくくりに分類されています。
- 単なるルール
- 出社時刻、メール件名の決まり、お互いの呼び方など
- セッション(ミーティングをそう呼んでいるそうです)ルール
- 人の話を遮らない、簡潔に話す、事実と意見を区別する、ヒソヒソ話をしないなど
- プロジェクト・ライフを楽しくするルール
- 週に1度は食事に行くなど
グラウンド・ルールを設定する利点
グラウンド・ルールの強力なところは、「個人の指摘をチームの指摘に変える」という効果があるところです。
予めメンバー全員で話し合い合意した約束事なので、グラウンド・ルールは絶対的な正義になります。個人の主観的な指摘ではなく、チーム全体としての指摘になり、伝わりやすくなる、というわけです。
セッション・ゴールとアジェンダ
第三に、セッション・ゴールとアジェンダです。
会議が有意義なものになるかどうかは、準備段階で9割が決まります。
セッション・ゴール
セッション・ゴールとは、会議の目的地のことです。
これも、プロジェクト・ゴールと同じで「達成できたかどうか」をわかるように、具体的な表現にする必要があります。
- いい例:合意する、〜について洗い出す
- 悪い例:検討する、〜について
セッション・アジェンダ
セッション・アジェンダとは、ゴールへのプロセス・順序・道筋です。
アジェンダの各項目には、とりあえず以下を記入しておくのがよさそうです。
- 時間
- メインスピーカー
事前に概要を共有しておくと、当日の対応が少なくなるのでオススメです。
また、会議の冒頭でゴールとアジェンダを参加者に確認して認識を合わせておくと、どこに向かうかがハッキリするので、脱線が少なくなります。
80・20(エイティー・トゥエンティー)
第四に、80・20(エイティー・トゥエンティー)です。
完璧を求める必要はありません。
80・20(エイティー・トゥエンティー)とは、「100%の時間で100%の成果を求める」のではなく、「20%の時間で80%の成果を出そう」という考え方です。
「そもそも100%やりきる必要があるのか?」という問いかけをし、作業する「範囲」と「程度」を見極めます。必然的に「しないこと」を見極めることが必要になります。その判断基準としては、以下の2つが挙げられます。
- 目的
- リソースの制約
「目的」にはプロジェクト・ゴールやCSFが使えます。「リソースの制約」とは、納期・コスト・工数などを考慮することです。
イエローフラッグ
第五に、イエローフラッグです。
良くない報告ほど、早く伝える必要があります。
これは、困っていることを周りに知らせるツールです。
「良くない報告ほど、早く伝える必要がある」という非常に重要な考え方を、イエローフラッグという名前をつけることによってより浸透しやすくしたものです。
さらに、「イエローフラッグを振るのは”good”な振る舞いである」という価値観を浸透させることで、「困っていることを周りに知らせる」のを気軽にできるように促しています。
一方、「レッドフラッグ」という概念があり、この状況はもう誰がどんなアクションを取ろうが挽回できない状況です。「イエローフラッグを振るのは”good”な振る舞いである」とすれば、「レッドフラッグを振るのは”too bad”な振る舞いである」という価値観もあります。
タイムアウト・ルール
第六に、タイムアウト・ルールです。
走り続けるのではなく、時間を区切ることが全体の効率化に繋がります。
「タイムアウト」とは本来はスポーツ用語で、作戦確認や変更、流れを変えるために使われます。
会議の場においても似たような目的で使われます。具体的なアクションは、以下の3つのどれかになります。
- 休憩をとる
- 話題を変える
- 解散する
どんなときに使うかは、準備が不足していた場合、集中力がなくなってきた場合、議論が混沌としてきた場合など様々でしょう。「グラウンド・ルール」で、「1時間に1回、5分の休憩を入れる」など決めてしまうのも有効ですね。
まずはマネしてみましょう
いかがでしたでしょうか。おさらいです。
- プロジェクト・ゴールとCSF
- グラウンド・ルール
- セッション・ゴールとアジェンダ
- 80・20(エイティー・トゥエンティー)
- イエローフラッグ
- タイムアウト・ルール
- 1.2.はプロジェクトの最初に決めるべきこと。
- 3.6.は会議のテクニック。
- 4.5.はプロジェクト推進中のテクニック。
そして僕は冒頭で、「情報共有」が正確かどうかで、プロジェクトのリスクが変わると述べました。
1.2.3.はまさに、システマチックな「情報共有」であり、5.も問題発生を未然に防ぐための「情報共有」です。これらを実践することで、ある一定以上の「情報共有」が保証されるということです。
また、本書には他にも6つのテクニックも紹介されていますし、上記の6項目についても詳細に記載されていますのでぜひ一度読んでみてください。
それでは。
チャイフ
コメントを残す