内容
人選
成功した事業では多くの場合、「まず優秀な人材が集まり、その人々がああだこうだと議論しているうちになんとなく計画が固まっていき、結果として事業が成功している」ことを指摘しています。
コリンズはこの発見を、「行き先を決め、そのあとでバスに人を乗せるのではなく、まずバスに優秀な人材を乗せ、とりあえず発車させる」というたとえで表現しています。
プロジェクトに必要な人材の質と量に対して、ちょうど１００％になるようなチーム体制では必ず破綻します。
なぜなら、危機対応できないからです。
プロジェクトに必要とされる人材の質的・量的な要件というのは、プロジェクトが定常飛行をしている状況を前提にしています。
ところが、プロジェクトというのは大抵の場合、何らかの想定外の事象が発生するわけです。
この想定外の時、ギリギリのメンバー構成では対処できず、プロジェクトが破綻することになります。
プロジェクトメンバーの質と量とが、プロジェクトが要求する水準に対してちょうど１００％だと思われる時は、それをすんなり受け入れてしまってはいけません。
「このメンバーでは戦えません。ぜひ◯◯さんをください」と交渉しなければならないのです。
「このメンバーでは戦えない」と強硬に主張することで、関係者の期待値をコントロールすることができるということです。
「このメンバーでは戦えない」と主張することで、周囲の関係者は、プロジェクトの難易度や成功確率に関する楽観的な期待を改め、緊張感を持つようになります。
こうすることで、あとで実際にプロジェクトが危機的な状況になった時に、メンバー増員や交代の交渉をしやすくなるわけです。
逆に、初期段階で何のウォーニングも出していなければ、プロジェクト途中で危機的な状況になった時にメンバーの増員や交代を申し出ると、周囲の関係者は唐突に感じ、プロジェクトが行き当たりばったりに運営されているという印象を与えることになります。
場所をつくる
当初想定した通りのプロジェクトロジックでプロジェクトが進行することは、半分くらいのケースでしかありません。
残りの半分は、当初立てた計画がまったく役に立たないほど変貌していくことになります。
この際、新たな作業計画書を作って配布する余裕があればいいのですが、多くの場合、そういった余裕はなく、リーダーを含めたプロジェクトメンバーの全員が、相互に連絡を取り合いながら臨機応変に物事を処理していかざるを得なくなります。
この時、プロジェクトメンバー全員が、物理的に一緒にいられるかどうかで、業務効率は大きく変わります。
強い組織
「強い組織は、三つのパターンをうまく組み合わせる」という指摘です。
まず、プロジェクト全体については、「ビジョン型」の目標を掲げてぶれさせない。
そして、そのビジョンを追求するために必要な要素に分解し、これらについては「合理的計算型」で数値目標を掲げる。
さらにその上で、直観的な飛躍や創発を引き出すために、一部のリソースは「ランダム試行型」に振り分ける。
逆に良くないのが、どれか一つだけという状態です。
リーダーの判断力を効果的に活用するためには、「重要」かつ「難易度が高い」問題の解決にリーダーの時間を集中的に投入するべきで、前記の二つの条件、つまり「重要」かつ「難易度が高い」という条件に該当しない問題については、その処理権限をメンバーに大きく委譲することが求められます。
「忙しいのに大した成果が出ていない」という状態を「アクティブ・ノンアクション」という状況だと指摘し、このアクティブ・ノンアクションを脱するために、シンプルに「些細な仕事を捨てることが必要」と指摘しています。
そして、些細な仕事をメンバーに任せて、自分の時間を「重要」かつ「難易度が高い」案件に集中するためには、メンバー間でプロジェクトの目的と意義が十分に共有されている必要があるのです。
大リスクのプロジェクトは小リスクで
わざわざプロジェクトチームを作って取り組むような課題は、通常その組織が扱っている定型的な課題とは大きく異なるはずです。
これはそのまま、「プロジェクトチームが取り組む課題には大きなリスクが付きまとう」ということになります。
このように、大きなリスクがともなうプロジェクトを推進するにあたって重要なのは、できる限りプロジェクト設計においてはリスクを冒さないということです。
確実でシンプルなプロジェクト設計を心がけることが重要なのです。
たとえば、メンバーの力量については、タスクとの比較において「いまはできないかもしれないけど、プロジェクトの途中で成長するだろう」といった考え方は禁物です。
「彼なら必ずやれる」という人物を、力ずくでも引っ張ってくることが重要です。
その人を付けてくれなければ、自分はやらないと突っぱねるのも手でしょう。
東海道新幹線の開発は、時速二百キロ以上で走る超特急列車の開発という未曾有のプロジェクトでした。
その開発の総とりまとめをやった島秀雄技師は「新幹線の開発・設計においては、徹頭徹尾、実証済みの技術、いわゆる『枯れた技術』のみを用いる」と周囲に宣言しました。
「元来、宇宙開発はハイリスクな事業です。莫大な費用がかかるうえに、常に試作機一機しか作れません。試行に膨大な経費がかかるためです。（中略）宇宙開発に従事する方々は、それでも十分に安全で、枯れきった技術を保守的に使ってでも、堅実な設計・製造に全力をあげています。意外かもしれませんが、宇宙開発は、そんなおどろくほどに保守的な世界でもあるのです」
プロジェクトからリスクを排除するための着眼点はどこになるのでしょうか？
大きく分けると「論理設計に無理がないか？」と「リソースが十分か？」の二つになります。
論理設計というのは、そのプロジェクトが依拠するロジックや構造のことです。
ホワイトカラーが携わるプロジェクトは、基本的に「情報の入手」→「情報の加工」→「示唆や行動計画のアウトプット（＝意思決定）」というモジュールの連鎖で行われます。
プロジェクトにおいて、「扱う問題の数」を示す言葉を「モジュール」と呼びます。
この時、各モジュールから別のモジュールに、「どう転んでもつなげられる」という論理的な確信が持てないのであれば、そのプロジェクトの論理設計には大きなリスクがあることになります。
「プロジェクトの工数が要求するリソースに対して、それが十分に確保されているか」という問題です。
具体的には、リソースは「人」「時間」「お金」の三つに分けて考えます。
「人」が足りなければ「時間」を増やす必要がありますし、「時間」が足りないのであれば「人」か「お金」を増やす必要があります。
ここで注意しておきたいのですが、リソースは１００％ギリギリではなく、できれば70％くらいの稼働率で回る程度に確保できるのが理想的です。
実はチームの稼働には、ある程度「遊び」があった方が生産性は高くなるのです。
たとえば、ハーバード・ビジネス・スクールのステファン・トムクは、数学の待ち行列理論を用いて「稼働率が80％から90％に上昇すると処理待ちの時間は二倍以上に増加し、さらに稼働率が90％から95％に上昇すると、さらに倍増する」ことを指摘しました（ハーバード・ビジネス・レビュー二〇一二年八月号）。
プロジェクトオーナー
プロジェクトをやっていると「こちらを立てればあちらが立たず、あちらを立てればこちらが立たず」という、トレードオフの状況が必ず発生します。
このトレードオフが発生したときに、どちらを立てるかを意思決定するのがプロジェクトリーダーの大事な責務なわけですが、このときに重要な判断の拠り所になるのがプロジェクトオーナーの問題意識になります。
そのため、「プロジェクトオーナーは誰か？」「その人はそもそもどんな問題意識を持っているのか？」「このプロジェクトにどんな期待をしているのか？」を明らかにすることが重要になります。
端的にいえばチーム全体のＲＯＩ（投資対効果）が低下してしまうのです。
なぜ二～三のチームが空中分解してしまうのか？
理由のほとんどは、扱う問題よりもリーダーの資質やリーダーとメンバー間の人間関係に起因します。
プロジェクトミーティングをリーダーがすっぽかす。
メンバーがリーダーの言うことを聞かない。
プロジェクトミーティングがそもそも設定できない等々。
こういった問題はテクニカルに解消することができず、地道なコミュニケーションと支援が必要です。
要するに時間がかかるということです。
期待値コントロール
「低めの期待値」をしっかり伝えておくことで、プロジェクトオーナーをはじめとしたステークホルダーと「プロジェクトの難易度に関する見通し」を共有できる。
これが「低めの期待値」を伝える効用の一つ目です。
「低めの期待値」を伝える効用の二つ目に、「プロジェクトオーナーとのあいだで発生する様々な交渉を有利に進めるカードが手に入る」という点が挙げられるでしょう。
初期段階で「低めの期待値」を伝えたものの、「高めの期待値」を押し付けられてしまったという場合、こちら側（プロジェクトマネジャー側）の言い分とあちら側（プロジェクトオーナー側）の言い分とが摩擦を起こして、あちら側の言い分を飲んだという局面になります。
つまり「貸し」が一個できるわけです。
この「貸し」はプロジェクトの後の局面でプロジェクトオーナーとなんらかの交渉をする際のカードになります。
組織認識力
際立って高い成果を挙げる外交官は、派遣された国の政治力学を見抜いて「誰が本当の権力者なのか、誰がフィクサーなのか」を見抜く、つまり「組織認識力」のコンピテンシーが非常に高いことがわかっています。
こういったコンピテンシーは、経験と学習を積むことで高められることがわかっていますから、このような機会に「裏マップ」をつくって、政治力学を見抜く勘所を教えてメンバーを育てる、というのも大事なリーダーの仕事の一つでしょう。
さて、「裏マップ」のもう一つの使い方が、プロジェクトの実施・成果がもたらす関係者への影響を、一度多面的にチェックするために用いるということです。
よく「あの人は視野が狭い」とか「多面的に見えてない」といった批判が聞かれますが、こういう人がリーダーになると、プロジェクトの途上で様々な問題があらわれて全体の停滞を招くことになります。
どうしてそういうことが起こるのかというと、利害関係者の整理ができていないからです。
ある人物がプロジェクトに影響を与える、あるいはプロジェクトの遂行上、どうしても協力が必要だとして、その人にとってプロジェクトの実施は、どういう影響を与えるのか？
その人の上司は誰で、その人は何に愛着を感じ、何を嫌悪していて、何によって評価され、どうすれば出世するのか。
こういった要素をキーマンの一人ひとりについて分析して、プロジェクトの遂行上、踏んではならない「地雷」をあらかじめ見極めておくことで炎上を防ぐわけです。
目的に立ち返る
よく「メンバーの判断能力が低い」とか「メンバーが使えない」とか「指示通りに動かない」と言って嘆いているプロジェクトリーダーがいます。
もちろん部下本人の力量の問題もあるかもしれませんが、筆者が見る限り、その嘆きの原因の半分以上はリーダーの力量の問題です。
「判断能力が低い」のは、判断の立脚点となるプロジェクトの目的や優先順位をリーダーが明確に伝えていないからです。
「指示通りに動かない」というのも、根っこの原因は同じで、これも「最終目的」がぼやけていて、個別の指示を文脈の中で意味づけすることができないために、「指示通りに動かない」のです。
本来、よほどの緊急事態でもない限り、しっかりと目標と優先順位を共有できているメンバーであれば、個別具体的な指示など必要ありません。
一つは、「そのプロジェクトがどのような意義を持っているのかを継続的にリマインドさせる」ということです。
さて、プロジェクトチームの士気を高めるための二つ目の要素が、「期待役割の明確化」です。
平たく言えば「あなたにはこれをやって欲しい。これはとても大事な仕事だから頼むよ」といって任せるということです。
関係者を不安にさせない
プロジェクトの初期段階において、当初想定されたよりも早め早めにレポートする。
プロジェクトリーダーの最も重要な責務の一つが「関係者の不安を解きほぐす」ということです。
これにはとても繊細な感度が必要です。
前項でも指摘した通り、プロジェクトの関係者が不安を感じ始めると、様々な悪影響がプロジェクトにもたらされることになります。
不安を感じさせないための最大のポイントはなんでしょうか？
最も重要な点は「不安を共有している」と相手が思っていることなのです。
タックマンモデル
教育心理学者のブルース・タックマンは、五〜十五人程度の小グループは一般に、フォーミング（＝形成期）、ストーミング（＝混乱期）、ノーミング（＝規範確立期）、パフォーミング（＝活動期）という四つの段階を経て形成されるということを指摘しました。
今日では、この発展段階は一般にタックマンモデルとしてよく知られています。
このタックマンモデルで興味深いのは第二段階のストーミング＝混乱期でしょう。
このステージでは、プロジェクトの目的や達成のためのアプローチ、チームの価値観や優先順位などについて、メンバー同士の、あるいはリーダーとメンバー間での考え方の違いがぶつかりあい、チームは一時的に混迷状態に陥ります。
もちろん、状態としては好ましいものではありません。
しかし、タックマンは「このステージを乗り越えない限り、第三ステージのノーミング＝規範確立期には移れない」と指摘しています。
つまり「状況としては好ましくないものの、ここを避けているといつまでも本当のチームにはならない」と言っているわけで、発達段階における反抗期のようなものなのです。
ストーミング＝混乱期を早期に乗り切るには、リーダーによるチーム憲章の宣言が有効になります。
チーム憲章とは、そのチームにおいてメンバーが守るべき基本ルール集のことです。
このチーム憲章にぜひとも入れておきたいのが「すべての意見を歓迎する。絶対に否定しない」という項目です。
チームの力量
チームの力量は、必ずしも個別構成員の平均的な能力の高さに相関しません。
では何がチームの力量を決めるのでしょうか？
それにはいくつかの要素があります。
勇気付けられるような目標やビジョンというのはその代表的な要素の一つでしょう。
人は共感できないような目的やビジョンのためには潜在的な能力をフルに引き出すことはできません。
そして、次に重要なのは、チーム内で流通する「情報の量」です。
チームの中で流通する情報の量が減ると、必ずといっていいほど、プロジェクトは危険な状況に陥ります。
失敗したプロジェクトでは必ず、何らかの形で情報流通に問題があった。
メンバー同士の「横のコミュニケーション」が活発化されると、チームの自律性はより高まることになります。
すべての情報を、リーダーをハブにして経由させようとすると、チーム内の情報流通量はリーダーの処理能力に依存することになります。
複数のプロジェクトオーナー
プロジェクトオーナーが一人であれば、別に問題ないのですが、複数のプロジェクトオーナーがいる場合、これらの要件や仮説が矛盾するケースが必ず起きるのです。
基本的に、お互いに面と向かって議論して、お互いの考えを論難することを避けようとするプロジェクトオーナーたちに対し「勝者の論が一つ残るまで待つ」あるいは「お互いの矛盾をより高次元で解決する別の解に全員が納得するまで待つ」ということが必要になります。
具体的には、まず個別にプロジェクトオーナーたちと議論し、プロジェクトに対する期待や、現時点で考えている落としどころ、その論拠について、それぞれのプロジェクトオーナーの考えを引き出します。
これは、個別のインタビューをやって本音をできるだけ引き出すことを心がけます。
次に、集まった情報をもとに、プロジェクト実施上の優先順位の齟齬や落としどころの矛盾等について整理した上で、プロジェクトオーナーが一堂に会する場を作り、具体的な個人名もあげた上で、意見の対立があること、優先順位に齟齬があることを明らかにして、彼ら同士で決着させるようにします。
こういう時、プロジェクトリーダーはあえて「融通の利かないコンピューター」のように振る舞う必要があります。
空気に流されて「なあなあ」の結論を飲み込まない、ということです。
リーダー
聞く
「メンバーというものは、リーダーが考える以上に、自分の懸念や心配ごとをリーダーに相談することを忌避しようとする傾向をもっている」ということを示しています。
第４章で詳述しますが、僕には「リーダーは上機嫌たれ」という持論があります。
メンバーができる限り気負わずにいろいろな相談ごとをできる雰囲気をプロジェクトチーム内で醸成することで、心に秘めている心配ごとを隠してしまうことを防ぐためです。
そしてさらに、リーダーはそういった雰囲気をつくった上で、より積極的に「心配ごとない？」といったことを聞いてあげる必要があります。
このとき、ポイントになるのは「リーダーとメンバーの二人きりのとき」にやる、ということです。
たとえば移動中のタクシーの中や、会議室の中で他の人がいない状況です。
なぜかというと、メンバーが感じている心配ごとが、他のメンバーの不利益につながる可能性があるからです。
キーマンの時間
キーマンとの定例ミーティングを行う際、注意したいのが、報告するのは「進捗」ではなく「その時点での結論」だという点です。
定例会議等の報告会でよくなされる報告は「やったこと」に終始しがちです。
つまり「アンケートを実施した」とか「キーマンインタビューをやった」とか「プロトタイプを作ってみた」といったアクションを報告してしまうのです。
これはこれで作業進捗の報告でいいのですが、大事なのは「やったことから何がわかったか？」「その結果、アクションはどう変わりそうか」という二つを報告することです。
組織における意思決定のクオリティは、その意思決定に関わる人たちからどれだけ反対意見や違うものの見方を引き出せるかによって大きく左右されることになります。
サン・テグジュペリは「愛し合うというのは、見つめ合うことではなく、同じ方向を見ることだ」という言葉を残していますが、これはプロジェクトの関係者についても言えることです。
「慕われるだけのリーダー」でも「恐れられるだけのリーダー」でもダメで、両者を高次元でバランスさせているリーダーこそ、良いリーダーだということです。
場をコントロール
皆から自然とリーダーとされる人には、何か共通の特徴があるのでしょうか？
背の高さ？知能指数？学歴？ルックス？育ち？
いいえ、これらは、すべて否定されました。
結局わかったのは「一番先に話し始めた人」だということです。
集団が形成されて、その中で一番先に話し始めた人が、リーダー格になっていくのです。
一番先に話した人のことを周囲の人は、より知的で、エネルギーに溢れ、人格が優れていると考える傾向があります。
人の認識の歪みをバイアスといいますが、一番先に話し始めた人に対して人はポジティブなバイアスを持ってしまうのです。
この性質を利用しない手はないでしょう。
助けてくださいと声をあげる
本当に優れたプロジェクトリーダーは、必要なときに「助けてください」と声をあげることができます。
プロジェクトが危機的状況に陥りそうだというとき、優秀なプロジェクトリーダーであればあるほど、周囲に対して「助けてほしい」というサインを出さずに、なんとか自分の裁量内で火消ししようともがき、かえって事態を悪化させてしまうことが少なくありません。
プロジェクトを炎上させた、ということをなるべく周囲に悟られずに済まそうとするからです。
では具体的にどういう点に気をつけたらよいのでしょうか？
基本的には常に最悪のケースを想定して手当てを行うということです。
上機嫌
上機嫌なリーダーが率いるチームではメンバー相互間、あるいはメンバーとリーダーとの間での情報量が増加するのです。
一貫性
リーダーには一貫性が重要であると指摘した上で、さらにその一貫性のタイプを次の三つに分けて整理しています。
１：時間的一貫性：同じ人に対して、その時々で態度を変えない一貫した姿勢のこと。
２：関係的一貫性：対人関係において一貫してフェア（公平）な姿勢を保っていること。さらに、これには、垂直的関係（上司や部下との関係で共に一貫した姿勢を保つこと）と水平的関係（同僚のＡさんにもＢさんにも同じ態度、姿勢を保つこと）の２種類があります。
３：状況的一貫性：通常の状況と緊急事態やプレッシャーのきつい状況とにおける、人との接し方や行動スタイルの一貫性のこと。
極論すれば、フォロワーというのは魅力的なリーダーに仕えたいわけで、では「魅力的な人」の条件は何かというと「ブレない軸がある」ということです。
目的と手段を分ける
仕事の目的というものと、それを達成する手段というものとは、これはきっちり分けておくべきである。
そうして目的は絶対であり、隊長はそれを与えるべきものである。
しかしその手段は自由である。
それをやる人の自由に任せるべきです。
それをはっきり分けることをせず、私はその手段までゴテゴテ言っていた。
だからいかん。みんなに自由を与えなければいかん。
面白かったポイント
めちゃくちゃ面白い。
プロジェクトにおける押さえどころとリスクについては共感する所ばかり。
プロジェクトの教科書ではなく、経験に基づく押さえどころをまとめたツボのような本。
プロジェクトに関わる人は全員読むべき。
プロジェクトって大変だと思う人が多いと思うが、プロジェクトって面白い仕事だと思う。
満足感を五段階評価
☆☆☆☆☆