プロジェクトに成長サイクルを。あるいは仕事場での育成
1年ほど前に「日経システムズ」に寄稿した、「プロジェクトで人をどう育成するか」というテーマの原稿を再録します。
掲載した際は、僕の力不足で規程の文字数をオーバーしてしまい、編集の方にずいぶん削っていただいたので、こちらのバージョンが元原稿です。
言いたいことを無理矢理2行にまとめると、
「頑張って育成しよう」と言っても無理だから、勝手に成長しちゃうサイクルをプロジェクトに組み入れよう。僕らはそれでうまくやれているよ。
ですね。
★プロジェクトメンバーの育成は、歯を食いしばって？
プロジェクトで働くメンバーをどうやって育成するかを考えようとすると、私たちはすぐに普段のプロジェクトワークとは別に、特別な仕掛けを考えようとしてしまいます。「トレーニングだ」「画期的な育成施策だ」「そもそも人事考課制度が良くない」といった具合に。
でも、ちょっと待って欲しいのです。
そういった取り組みにはとても多くの時間が必要なものですが、「毎日こんなにしんどいのに、その上、自己研鑽しろ、後輩を指導しろ、と言われても・・。その前に寝たいよ。」というのが、プロジェクトで働く多くの方の本音ではないでしょうか。
私たちの多くは普段の仕事に加えて人材育成にいそしむほど勤勉ではないし、仕事の効率を犠牲にして人を育てる余裕もないのが、ほとんどの会社での現状です。
特別教育熱心な上司・先輩についた場合や、本人の成長意欲が特に高い場合（例えば勝間和代読者？）といった例外的な状況下でのみ人が成長する、というのが現状に近いと思うのですが、この状況は寂しすぎます。
これを踏まえ、私が本稿で訴えたいことをまとめてしまえば、次のようになります。
「プロジェクトは本来的に人を育てる環境である。だとしたら、その環境特性を意図的にアップさせるようにプロジェクトを運営することこそが、育成でもっとも重要なこと。キレイゴトを唱えるよりも成長の仕掛けを組み込もう」
仕事における成長は、ダイエットに似ています。成功するダイエットでは「今日、ケーキを我慢できたから0.5キロやせたはず」ではなく、「普段からエレベータを使わないことにしている」といった、日々の生活習慣がものをいいます。
同様に「今日PMBOKを読んで勉強した」ということよりも、毎日漬かっている現実（いま所属しているプロジェクト）での習慣こそが、成長のスピードを決めるのです。
★成長サイクルを組み込む
では、どの様な習慣をプロジェクトで持てばいいのでしょうか。私の回答は、図1の様な成長のサイクルを意図的に仕掛けることです。私自身の経験をベースに、1ステップずつ説明していきましょう。
①背伸び環境を作る
私が「一番成長したな」と実感したのは、社会人になって8年程度たった頃、かなり背伸びせざるを得ない仕事を任せられたときです。それは、古河電工という老舗大企業での人事業務改革プロジェクトにおいて「業務改革担当の主任コンサルタント」を担当することになった時でした。
当時の私が持っていた経験や能力をやりくりしただけでは、とうていできない仕事です。でも、私がそれをやり遂げない限り、プロジェクトは失敗してしまう。一言で言って、とても困った状況です。
この様に「成長しなければ、どうにもならない」という、背伸びを強いる環境に身を置くことからサイクルは始まります。
（ちなみに、このあたりの「背伸びっぷり」については、古河電工の関さんとの共著である
「プロジェクトファシリテーション ～クライアントとコンサルタントの幸福な物語～」
という本に詳しく書きました。）
②試行錯誤
プロジェクトは絶対に失敗させるわけにはいきませんから、どうやったらいいか必死に考えました。そして、本だろうが、トレーニングだろうが、先輩コンサルタントのノウハウだろうが、それまで学んだことを片っ端から試していきました。何しろ、自分がやったことがあること、できることだけをやっていては、足りないのですから。
③スキル不足に気づく
試行錯誤をしてみると、当然うまくいかないこともあり、同僚や上司やお客さまから「ここがうまくいっていなかった」という指摘を受けます。これはきわめて重要な成長への糧になります。教科書に「○○せねばならない」と書いてあるのを読むより、100倍切実に感じ、二度と繰り返さないためにはどうしたらいいかと必死になるからです。
④成長の定着
こうして、徐々にできることが増えていき、プロジェクトを見る視点も高くなっていったとき、それを定着させる効果があったのが「サンセットミーティング」でした。プロジェクトで一区切りが着くごとに開催する振り返りの場です。
ここで「今回新たにできるようになったことはなにか」「なぜうまくいったのか」「次回、別な人がやるためにはどうすればいいのか」などを議論したのです。ノウハウを言語化したことで、せっかく苦労して成し遂げたチャレンジを、自分自身やプロジェクト全体に定着させることができました。
この4つのサイクルのうち、「②試行錯誤」は本人次第のところがありますが、「①背伸び環境を作る」や「③スキル不足に気づく」については、プロジェクトで意図的に仕掛けることができます。
いわば、コントロール可能な部分といって良いでしょう。ですから、本稿ではこの2点について詳しくお話したいと思います。
★良い背伸びと悪い背伸び？
背伸び環境で人が成長する、もっとも劇的な例は「修羅場プロジェクトに投入されたメンバーが、一皮むけて大きく成長する」という現象です。誰もが関わりたくない修羅場プロジェクト、しかしそこでものすごく成長する人がいる。
その理由を考えるにあたって「修羅場を立て直すため、どさくさ的権限委譲が行われる」ということは見逃せません。
「まだ下っ端だから」「業務のことを良く知らないから」等々の言い訳が修羅場では通用せず、「とにかくやれそうなヤツに仕事をやってもらう」とならない限り、事態を収拾できないからです。
「この人の能力はこんなものだろう」というそれまでの定説を越えた難易度の仕事が割り振られることになります。それに応えるためにがむしゃらに仕事をする過程で「火事場のくそ力」が出て、そのまま基礎能力として定着してしまう、という訳です。
しかしながら、私は修羅場プロジェクトが嫌いです。第一の理由は「プロジェクトは楽しく成功させてなんぼ」という私のポリシーに反しているからです。もう一つの理由は、修羅場では大きく成長する人がいる一方で、脱落者が多く出てしまうことです。
ある人にとってはちょうど良い背伸び環境であっても、ある人にはハードすぎて背伸びどころではなくなってしまう、ということが往々にしてあるのです。
つまり、「成長にとってちょうど良い背伸び環境」とそうでない「無茶な環境」があるということになります。
ですからプロジェクトに関わるときに私が一番気にしているのは、全てのプロジェクト関係者にとって「楽しいけれども、能力を無理矢理引き延ばす必要がある状況」を作ることです。
「私自身がかつて経験したような、ちょうど良い背伸び環境をプレゼントすること」と言っても良いでしょう。
その秘訣は、権限委譲のレベルを適切に調整することにあります。
★仕事の難易度は抽象度と責任範囲で決まる
どのような権限委譲をすれば、「ちょうど良い背伸び」になるのでしょうか。それを考えるためのモデルが図2です。
縦軸の「抽象度」とは、「仕事のつかみ所のなさ」であり、プロジェクトで言えば上流工程は抽象度が高く、下流工程に進むほど抽象度は下がります。
上流での抽象度の高い仕事例：
⇒プロジェクトのゴールや、改革のポイントすら見えていない状況での現状調査
下流での抽象度の低い仕事例：
⇒○月○日までに××を元に、△△を作る
当然、抽象度が高い状態では「何をどの様に検討するか」から自分で考え、周囲を説得していかなければならないので、仕事の難易度は非常に高くなります。
横軸の「責任範囲」は任せる仕事の範囲です。1枚の資料を作る、明日の打ち合わせを仕切る、などは狭い範囲の仕事といえますし、1つのチームやプロジェクト全体をリードする仕事は責任範囲が広いといえます。
仕事の難しさは、この縦軸・横軸のどこに位置しているかで決まります。
ですからプロジェクトの下流ではプロジェクトマネージャーを任せられる人でも、業務改革の方針を立てたり、プロジェクト計画を立案する、といった上流の仕事では1つの打ち合わせを仕切るのにも四苦八苦することがあり得ます（むしろ、あるのが普通です）。
適切な権限委譲を考える際には、仕事の抽象度と責任範囲の両方を見極めることが第1歩となります。
そして、仕事を任せる人のスキルレベル（経験やポテンシャル）がどの程度なのかを知っていれば、仕事と能力のギャップ（スキルギャップ）をおおよそ把握できます。このギャップの大きさに応じて、権限委譲のスタイルを選択する必要があるのです。
ただし、仕事の難易度も、人の能力も、そんなに簡単には見極められませんし、やっている間に、変わっていくものです。決まっているはずの方針ごとが、実は社内でコンセンサスが取れていなかったり、業務ヒアリングがうまいと思っていたメンバーが、実はそうでもなかったり。
ですから「権限委譲の程度自体が適切か」は適宜見直していかなければなりません。
★スキルギャップに応じて仕事を任せる
図3は、権限委譲スタイルをリストアップしたもので、委譲レベルが低い方から順番に並んでいます。
これらのスタイルはどれかが優れていて、どれかが禁じ手、という訳ではありません。仕事の難易度と権限を委譲する相手によって、権限委譲のレベルを選択することが大切です。
かなり難しい仕事を、あまりスキルのない人に依頼しているのに、「⑤定点観測」や「⑥放置」しかしないのは、権限委譲のしすぎです。仕事は失敗し、成長どころではなくなるでしょう。
逆に、スキルがある人があまり難しくない仕事をする際に「②手取り足取り」や「③主体的にレビュー」をするのは、頭を使って仕事しなくて良いよ、と言っているようなものです。鬱陶しく感じることで、仕事へのモチベーションも上がらないでしょう。
私と一緒に働いている、AさんとBさんの実例で考えてみましょう。
Aさんには、あるシステムのアーキテクチャー方針をお客さまと議論する準備を担当してもらいました。まだプロジェクトは始まったばかり。アーキテクチャー方針について、何をどのレベルで議論すべきかも分からないという、きわめて抽象度の高い状態です。
彼はシステム構築でのリーダー経験もあり、「責任範囲が広い」事には慣れていましたが、抽象度が高い議論を任せきるのは難しいと思い、「③主体的なレビュー」のレベルが適切だと判断したのです。
「まず、この会議ではどんな目的で、何を議論すればOKなのかを考えてきて。資料についても、実際に作る前にラフスケッチを僕に見せて。何曜日にできる？」といった具合。
数日後にレビューしてみると、やはり苦戦・迷走していました。この時は半ば「②手取り足取り」の状態で、2人で議論しながら準備を進めることになりました。
一方、Bさんがマネージャーを務めるプロジェクトは、業務上の課題を分析し、改革の施策案をまとめるフェーズにありました。つまり仕事の抽象度も高く、責任範囲もプロジェクト全体におよびます。
ただし、Bさんはプロジェクトマネージャーの経験もあり、これまでも成長著しかったので「プロジェクトでおこる全ての問題を自力では解決できないだろうが、そのときは自分からマズイと判断し、アラームを上げるだろう」と判断しました。
そこで私とBさんは相談の上、権限委譲のレベルを「⑤定点観測」と「⑥放置」の間くらいに設定することにしました。Bさんも納得の上でのことです。
AさんとBさんに対して私が委譲した権限は、それぞれ異なっていたわけですが、結果として二人ともそれぞれなりに、この仕事を通じて成長したと思います。
Aさんは助けをもらいながらも難易度の高い打ち合わせをこなす経験を積むことができました。いつか、自力で完結できる時が来るでしょう。
Bさんは自分自身でプロジェクトの成功に必要な事を、高い次元で考える癖がついて来ました。
もちろん、AさんにしろBさんにしろ、「私が育てた」という感覚はありません。状況を整え、任せるところは任せた後は、自分で試行錯誤していったのです。つまりは本人次第なのですが、彼らの成長を支援する立場としては、ベストを尽くしたと信じています。
★早く、直後にスキル不足に気づく
「成長に近道はない。短期はある。」とは英会話教室のつり広告キャッチコピーですが、プロジェクトにおける成長にもそのまま当てはまります。
短期間に成長するためには、成長のサイクル（図1）を端折るのではなく（近道はない）、サイクルを速く、意図的に回せば良いのです（短期はある）。
そこでポイントとなるのはサイクルの3番目「不足に気づく」頻度を増やすことです。私がプロジェクトを立ち上げる際には、スキル不足に気づく仕掛けをたくさん組み込みます。全ては紹介できないので、ここでは「チェックポイント」を取り上げます。
チェックポイントというのは、打ち合わせの後などに行うミニ反省会のことです。「今日の打ち合わせは、当初の目的を達成できたか」、「結果に合意していない参加者はいなかったか」などなど、確認すべきことは多くありますが、会議を仕切った人（ファシリテーター）へのフィードバックも大事な議題です。
「うまく議論をマネージできていたか」、「会議を有意義で楽しいと感じてもらえるように気を配っていたか」などについて、ダメだったことはダメとはっきり言い、良かったことも口に出して評価します。
大事なことは、極力具体的な行動レベルで指摘すること。「進行がまずかった」ではなく「Cさんがあの発言をしたのを、結果的に無視することになっていたよ。あの場合、望ましいのは・・」といった具合です。
必ずしも上司が部下に指導するばかりではありません。私もよく「白川さん、今日のファシリテーション、ちょっと強引でDさん不満そうでしたよ」などと注意をされます。
「スキル不足に気づく」という点で、チェックポイントが特に有効なのは、すぐにやる、短時間で頻繁にやる、という点です。私たちにとって、何かを指摘されて一番身にしみるのは、何かをやったすぐ後なのです（そういう意味では、犬のしつけと同じですね）。
半期に1回、人事考課をつけられる時に上司から怒られるというサイクルにくらべ、改善のサイクルは非常に早くなります。すぐにスキル不足に気づき、次回同じ事をやるときにはできるようにする。この繰り返しです。
同時に、チェックポイントはチャレンジのための命綱の役割も果たします。背伸びして能力以上の役割を担当するのですから、必ずしもうまく行くことばかりではありません。そんなとき、直後にチェックポイントで失敗を認識し、リカバリー策を打つのです。
この意味では、自社の同僚だけでなくお客さまからもフィードバックを頂くことが非常に有効です。チェックポイントのような場を設定するだけで、意外に率直なコメントをいただけるものです。つまり「背伸びでチャンレジしても、命を落とすような大失敗を避けるための命綱」がチェックポイントなのです。
★そして、自分を育成する
ここまでは「プロジェクトで人をどうやって育てるか」という視点で書いてきました。では、自分の成長は誰が面倒を見てくれるのでしょうか。
実は、その問い自体がナンセンスなのです。自分の事なのですから、自分で責任を持つしかないのです。
「会社が育成してくれなかったから、僕は成長していないんだ」とつぶやいたって、誰もなぐさめてくれません（ちなみに私の会社、ケンブリッジでは入社1日目に「キャリアは自己責任」と申し渡されます）。
だとすると、「自分が自分を育成するために、自分が仕事をしているプロジェクトにどういう成長サイクルを組み込むのか」が私たちにとって意味がある問いになります。
答えはシンプルです。
これまで書いてきたことを、自分がプロジェクトマネージャーだろうと、1メンバーだろうと、1つずつプロジェクトで実施していけば良いのです。
例えば、どの様な権限委譲スタイルを取って欲しいのか、プロジェクトの開始前に上司と相談してみてください。
例えば「今の打ち合わせの反省会を10分間限定でやりましょう」と提案してみてください。
できるようになったことを、ちょっとした勉強会のような場をつくって人に教えるのもいい方法です。
鍵は、プロジェクトに（ひっそりと）組み込むこと。皆さんも明日からでもできること、自分のプロジェクト環境に合ったやり方を考えてみてください。
まとめ。
プロジェクトは最高の人材育成機関。少しだけそれを意図的に組み立てて、成長を加速させよう。
今日はここまで。