昨年から比較的大きなプロジェクトを任されることが多くなり、山口周氏のプロジェクトマネジメントを読んでみた。
内容としてはプロマネのテクニック論に加えて、リーダーとしてのふるまいや心構えについても多く記載されており、プロマネ以外の方にもおすすめできる一冊。

比較的ベーシックなこともしっかりと書かれているため、20代や30代前半の中堅クラスの方々もしっかりと理解して実践すべきものだと思うし、それ以上の年齢層の方も自分自身のリーダーシップを振り返る手段として読んでいただくのも良いと思う。

以下、読書メモである。

第1章　プロジェクトは始まる前にすべてが決まる

• 勝てるプロジェクト、確実に成功が見込めるプロジェクトだけをやることが肝要。
• 勝てない戦いを避け、勝てるかつ意味がある戦場を見つけ出すこと。
• 不可能を可能にする、奇跡を起こす、といったプロジェクトは存在するものの、それは数百数千の屍の中でたまたま上手くいったものと認識すべき。
• 勝てないプロジェクトの特徴は、「目的が不明確なプロジェクト」。何か問題が起きた時に迂回路が取れない。チームメンバーの管理が難しくなる。
• 「これってそもそも何のためにやるんですか？」という質問は、プロジェクトの初期段階だけではなく、停滞する状況を打開する際にも有効な質問。

• プロジェクトの成否の半分は人選で決まる。プロジェクトに必要な人材の質と量に対して、ちょうど100％になるようなチーム体制では必ず破綻する。必ず何かしらのトラブルが起こった際に対応できるほどのマンパワーは確保していないといけない。
• 関係者の期待値をコントロールする。
プロジェクト開始前にメンバー人選において「このメンバーでは戦えない」と強硬に主張することで、関係者の期待値をコントロールすることができる。プロジェクトの難易度に楽観的な雰囲気をあらためる。
• プロジェクトを始める段階で、チームのホームを作ることが大事。プロジェクトチームが物理的に一緒にいられるかは成否に大きく関わる。
これは、何かトラブルが発生した際に、メンバー一人ひとりが瞬間的に判断して行動することができるか否かが物理的な場所と関係してくるから。

• プロジェクトの目的を明確化する。リーダーは夢を見る力を部下やプロジェクトのメンバーに持たせなければならない。
目標には、以下3タイプが存在する。
①合理的計算型：5年以内に海外売上高比率を50％まで高める等。
②ビジョン型：10年以内に人類を月に送り込む等。
③ランダム試行型：とにかく楽しもう、何でもいいから新しいことをしよう等。
• 強い組織は、上記3パターンの目標をうまく組み合わせる。
プロジェクト全体には、ビジョン型の目標を掲げてブレさせない。ビジョン達成のために必要な要素に分解した際、それぞれに合理的計算型の目標を掲げる。その上で直感的な飛躍や創発を引き出すためのランダム試行型の目標をスパイスとして入れる。
• プロジェクトの意義をメンバーと共有する。
人間は意義を感じない仕事には情熱を持って取り組むことができない。また、その意義や目的がメンバー自身の判断基準になるため、効率的にプロジェクトが回る。
• ダメなリーダーの特徴は、忙しいのに大した成果が出ていない人。これはアクティブ・ノンアクションと言われるもので、この状態を脱するには些細な仕事を捨てること（≒メンバーへの権限移譲）である。
• 大きなプロジェクトほど、失敗のリスクは減らす。そのため、メンバーの力量以上のタスクを割り振ったり、予算を確保できるだろう、という算段は危険。
もちろん、当初見えないリスクが突然発生することもあり得るので、プロジェクトデザイン時に見えているリスクは排除しておく。
• チームの稼働においては、ある程度遊びを持たせておくこと。このほうが生産性は高くなる。
• プロジェクトオーナーを明確化する。その上で、オーナーの問題意識や期待値も綺麗にしておくこと。それが判断軸になる。
• また、メンバーの仕事上の得意不得意・好き嫌いや、人となりは必ず把握しておくこと。そして、プロジェクトに参加するメンバーの期待値（どんな風に成長したいか等）やプロジェクト参画における心配事も事前に知ってくことが大事。
• また、アサインしてからはメンバー間の上下関係は取っ払うこと。さらに気をつけるのは、難しいタスクは経験の浅いメンバーにアサインしてリーダーがサポートする、一方能力のあるメンバーには比較的簡単なタスクを全権委任して進める。

• プロジェクトオーナーの期待値は事前にある程度下げておくこと。予算や人員、必要期間においては、当初必要と思っているものの1.5倍かかると伝えて期待値を下げる。さらに、成果についても、100％というよりは70〜80％の完遂となることを匂わせること。
• 低い期待値であれば、同じ成果でも最終的な評価は大きく変わるし、プロジェクト中のリソースの相談もしやすくなる。

第2章　プロジェクト序盤に注意すべきこと