育つプロジェクト10の原則、あるいは仕事で人を育てるために大切にしていること
12月に出した新刊「リーダーが育つ 変革プロジェクトの教科書」では、僕らがお客さんとやっている「育つプロジェクト」とはいったいどんなプロジェクトなのかを最初に示した。
1章では住友生命さんとやった青空プロジェクト（携帯端末づくりを通じて、営業職員さん達の仕事を抜本的に変えるプロジェクト）の事例を、なるべく生々しく書いた。書いた当人としては「大きな会社だし、ここまで書いても大丈夫かな？」というくらい筆を滑らせたのだが、寛大にも、ほとんどそのまま本にさせていただいた。なので読んだ人にはイメージはバッチリ伝わると思う。
もう一つ、育つプロジェクトのエッセンスとも言うべき10の原則をまとめ、2章に掲載した。多くのプロジェクトをやり、振り返りミーティングで「どうしてこのプロジェクトでは人が成長したのか？」を議論してきた集大成とも言える。
先日、本に登場していただいた住友生命の岡本さん（1章、10章）とNHN JAPANの柏木さん（14章）と白川とでやった座談会でも、この10原則について話した。「俺はこれが大事だと思う」「いや、こちらも！」と結構盛り上がった。
皆さんは普段、どれを大切にしているだろうか？そしてあまり実現できてない要素はどれだろうか？
★原則1：OWNERSHIP
世にプロジェクトマネジメントの本は多いが、どれも「全権を持ったマネージャーが一番上に1人いる。その下のメンバーが手足としてマネージャーの意志を粛々と実行する」というモデルが、暗黙の前提になっている。
だが強力なマネージャーの下で働く経験は、ひょっとしたらリーダーシップの修行には逆効果かもしれない。なぜならリーダーは自分が担当する局地戦においては、自分のビジョンを持ち、自分で判断する必要がある。マネージャーの手下になるのとは真逆のマインドが必要なのだ。
この「ここは自分の領域だ。この仕事が成し遂げられることは、自分の責任として担保せねば」という感覚をOwnershipという。勘違いされやすいのだが、Ownershipは「100%自分一人でやりきること」ではない。逆にスキルの高い人に手伝ってもらってでも、他の組織に動いてもらってでも、なんでも良いのでやり遂げることに責任を持つことだ。
育つプロジェクトではたとえ小さくても良いので、全てのメンバーに担当領域を持ってもらう。スキルが十分高くなる前は、「取扱商品ごとの在庫管理方法を調べて一覧にしてください」といった小さめのタスクになるし、それですら自力では完遂できないだろうが、「ここは自分の領域」を持つことが重要なのだ。
====
なお、住友生命青空プロジェクトのメンバーで、座談会に登壇していただいた岡本さんは、当初は会議スケジュールの調整のような地味な仕事を担当していた。だが徐々にオーナーシップを発揮する領域を難しい仕事にシフトさせていった。1年後にはプロジェクトのコアとなる部分を担当するようになり、しかも仲間から仕事ぶりを絶賛された。
関連記事：オーナーシップ≠仕事を自力でやること、あるいはうちの会社が最初に叩き込むこと
★原則2：CHALLENGE
プロジェクトを立ち上げる際に悩まされるのが、十分な知識/経験を持った人が本業で忙しく、十分な時間プロジェクトに参加できない問題だ。仕事のやり方がマズイので時間がない。時間がないからプロジェクトに参加できない。ニワトリタマゴ問題だ。
十分な知識をもったエキスパートではない社員であっても、育つプロジェクトでは歓迎される。プロジェクトで必要なワークスタイルは、参加しながら身につければ良い。業務知識が足らなければ、詳しい人をゲストとして招き、引き出せば良い。ニワトリタマゴ問題を前に立ちすくむよりは、まずは組織としてチャレンジしなければならない。
この点に関してなぜ強気かと言えば、変革プロジェクトをやる以上、どうせチャレンジはつきものだからだ。四半期決算のように何度も繰り返す仕事はプロジェクトとは呼ばれない。「プロジェクトをやるぞ」となった瞬間、それは組織にとってやったことのない、大きなチャレンジに挑むことになる。そしてプロジェクトに参加する個人にとっても、これまでやったことのない仕事、役割、馴染みのない業務領域・・に取り組まざるを得ないシーンが続出する。
組織としても個人としてもどうせチャレンジするのだから、失敗は当たり前（正しい数値を出して当たり前の四半期決算とは、この面でも違う）。普段の仕事とは仕事に対するスタンスや価値観自体をモードチェンジして臨むべきだ。だから熟練者/有識者でなくたって、失敗前提でプロジェクトに放り込むしかない。
★原則3：OPINION
わたしは普段大企業の方と仕事をすることが多いので、真面目な方が多い。そういった方々は変革プロジェクトについて議論をしていても、「正しいこと」を言おうとする。正しいことというのは、①会社の方針に沿っている、②コンプライアンス的にOK、③事実の裏付けがある、みたいなことだ。
だがプロジェクトにはたいてい正解はないし、プロジェクトを前に進めるのは「正しさ」ではない。「私はこうあるべきだと思う」「オレはこうしたい」という意見である。
自分の意見をみなに示し、それに賛同する人がいたら、その人がリーダーと呼ばれる。だから、反対されることや正しくないことを恐れずに、まずは自分のオピニオンを表明しなければならない。青空プロジェクトでも、全員が2週間考えた「オレが考えるタブレットを100%活用したワークスタイル」を発表するところから、合宿をスタートさせた。
とにかく日本人はこれが苦手で、普通に議論をしていても特定の声の大きい人しかオピニオンを示さない。育つプロジェクトでは、普段オピニオンを示すのに慣れていない人にも、オピニオンを表明する場を意図的に作る。オピニオンがない人に対しては、自分が大事にしていることを見つめるのを手伝い、オピニオンを形作る手伝いすらする。
====
普段戦略を議論し慣れていない中堅社員の人々からOPINIONを引き出していった事例は本の7章にじっくり書いた。下記の記事は同じプロジェクトの話である。（記事より本の方がずっと具体的な紹介になっている）
「ドラえもんがいなくなったのび太」がどう戦略をやり遂げたのか？あるいはファシリテーションの無限の可能性
★原則4：FACILITATION
プロジェクトを立ち上げるとなると、どこの会社でも「では、集まって相談しましょう」となるのだが、みなのスケジュールを合わせると、打ち合わせできるのは2週間後。そこに手ぶらで集まって「さて、どうしましょうか？」と話しはじめてすぐに2時間。何が決まったのかよく分からないけど、次回打ち合わせはまた2週間後・・。こんな感じでは何ヶ月たってもプロジェクトは進まない。
プロジェクトは意思決定の連続体である。何をプロジェクトのゴールにするのかを決め、やっつけるべき課題を特定し、そのための施策を選択する。施策が絞られた後も、どう変化させるのか（一気に変えるor徐々に変える）だとか、その施策を実行するためにシステムに投資するかしないか、など、意思決定を次々としていく。
意思決定は会議で行うので、プロジェクトのスピードと品質は、会議のスピードと品質とほぼ同じになる。従って、会議のスピードと品質には徹底してこだわるべきだし、会議開催のテンポにも工夫をこらす必要がある。プロジェクトに集った全員のオピニオンを引き出すのもファシリテーションの腕次第。出揃ったオピニオンの違いを考えたり、優劣を議論したり、1つの方針としてまとめるのも、もちろんファシリテーションしだいだ。
育つプロジェクトでは、会議の技術をまず叩き込む。どんなタイプの変革であれ、それが成否の鍵を握っているからだ。そして全員がファシリテーションを学んだチームでは、ファシリテーターだけが奮闘するチームよりも、さらにスピーディに質の高い検討ができ、変革はどんどん進むようになる。
====
ファシリテーションについてはこのブログでも何個か書いているが、代表的なのはこれ。
（最後に関連記事のリストを付けています）
議論のアマチュアが陥りやすい罠5つ、あるいは議論を「知的生産の場」にするために
★原則5：PROCESS
変革プロジェクトでのリーダーシップを期待されても、「この業務は経験ないから・・」「よく知らないから・・」「ITの専門家ではないので、デジタル変革と言われましても・・」などと、たじろぐ人がいる。だが、業務経験や業務知識と「変革をリードする力」は分けて考えたほうが良い。経験や知識は、知っている人を連れてくれば補填できる。そして新しいことにチャレンジするのだから、経験者だって正解を知っている訳ではない。
もっと重要で、今の日本企業に本当に足りないのは、変革プロジェクトを前にすすめるプロセスを構築する力である。プロジェクトゴールをみなで見出すためにはどういう順番で議論していけばよいのか？スジの良い施策を選択し、メンバー全員で納得するためにはどんな表を作ったら助けになるのか？社内の誰に相談し、誰の承認を早めに取れば、スムーズに社員が協力してくれるのか？
つまり、コンテンツよりもプロセスに熟達し、組織を動かし、現実のビジネスを変えることが求められている。DX（デジタルトランスフォーメーション）とは、単にITを買ってくることではなく、新しいテクノロジーをテコにして組織やビジネスを変えることだからだ。そういったプロセスをリードする能力は、知識（コンテンツ）に比べて、社外から買ってきにくい。
住友生命のプロジェクトでも、タブレットに詳しい人、タブレット用のコンテンツ作りに詳しい専門家を社外から呼び、支援してもらった。だが、変革のプロセスを組み立てるリーダーは社内でまかなう、という意志は固かった。
====
このあたりについては何度かブログを書いているけど、「何をやったらよいのかよく分からない状況で、やるべきことを示すタイプのリーダーシップ」の重要性を自分ではっきり言語化したのは、この記事を書いた時。
優れたリーダーが途端に頼りなくなる現象について、あるいはリーダーシップ2類型
その続編：理想の上司とは？あるいは松岡修造とクシャナ王女のリーダーシップ像
★原則6：OPEN
ほとんど全ての企業で、部門をまたぐ課題を解決するのに苦労している。理由の一つは部門間で情報を共有するのが難しいからだ。ここでいう情報とは、仕事をする上で必要なハードな情報（在庫数や商品スペックなど）だけではなく、ソフトな情報（何を目指しているのか、何に困っているのか・・）みたいなことも含めた情報を指している。
つまり部門最適から抜け出し、顧客に一貫した体験をしてもらう組織になるとか、全社最適なコスト構造になるためには、部門の垣根をなくし、もっともっとOPENになり、ソフトな情報を交換し合う必要がある。ファシリテーションはそのための技術でもある。
もう一つ、OPENには「思ったことを本音で語り合う場」という意味も含んでいる。プロジェクトは手探りで進むのだから、「この進め方で良いのかモヤモヤする」「あの課題を放置していると、リスクがいつか顕在化するのでは？」といった懸念を互いに共有し合うことは、プロジェクトを安全に進める上では死活的に重要である。
そしてこれまでの経歴や現在の立場が異なるメンバー同士が集うのがプロジェクト。建前だけを話していても一向に前に進まないか、見かけ上進んでいても矛盾が後から噴出して頓挫してしまう。部門の代表者として建前論を並べるのではなく、プロジェクトにとって何がベストか？会社にとって何がベストか？だけを考えれば良い場を作り上げる。思ったことを口に出来る場を作る。その方がクリエイティブになれるし、気を使わないので楽だし、何より楽しいし、結局プロジェクトは成功する。そうした伸びやかな場で、人は育つ。
====
逃げないOPENなコミュニケーションについて書いた記事はこれ。
「おばちゃんコミュニケーション能力」とは対極のコミュ力、あるいは僕が鼻つまみ者な訳
★原則7：TRIAL
「学習≒正しいことを教わり、覚えること」と思っている人が、社会人でもかなりいる。育成部門に呼ばれて5年次研修や管理職研修を受け、育成部門の人が選定した講師から問題解決やリーダーシップについて学び、覚えようとする。そういう人にとっては「やったことのないこと、教わっていないこと≒できないこと、できればやりたくないこと」になってしまう。
テストに向けた勉強と違って、仕事での学びには正解がない。変革プロジェクトであればなおさらだ。だから色々試してみる、まずはやってから考える、という姿勢の有無で、成長スピードが全く違ってくる。
住友生命の皆さんは、当初ケンブリッジの方法論に比較的懐疑的であったが、まずはやってみる、批判するならやってからだ、という姿勢があった。そしてやってみてから「今までの自社にはないが、これからのプロジェクトに絶対に必要なものだ」と実感したのだ。
★原則8：PEACE
PEACEと言っても「平和」というよりも「心の平穏、心理的安全性」という意味だ。会社で働いている時、人は知らず知らずのうちにかなりのプレッシャーを感じている。「ちゃんとしたふるまいをしないと」「上司や先輩を立てないと」「部署の方針とズレたことしないように」「成果出さないと」・・。
育つプロジェクトは、立ち上げ期にこうしたプレッシャーを解き放つ仕掛けを作っている。プレッシャーのない心理的安全性が確保されていなければ、10の原則のうちCHALLENGE、OPEN、TRIAL、OPINIONの4つは成り立たない。「このプロジェクトでなら」「この部屋の中でなら」「この仲間たちになら」、本音で話ができたり、やったことないことを試せる。その安心感が育つプロジェクトにとっては絶対に必要な条件だ。
失敗しても笑う人はいない（なぜなら全員がチャレンジしているし、変革プロジェクトの難しさを理解しているから）。プロジェクト方針が固まるまでは、プロジェクト内で議論したことを外に漏らさない（企んでいることを中途半端に漏らすと失敗するから）。同志というか、共犯者みたいな関係ができてくる。プロジェクトという、普段の仕事から半ば隔離されたチームだからこそ、普段とは違う働き方ができる。
====
僕自身は、これの重要性をあまり認識していなかった。ケンブリッジという組織も、ケンブリッジが作るプロジェクトも、かなりPEACEに配慮している。そして僕自身はPEACEが保証されていなくてもあまり物怖じしないタイプだからだ。だが、最近お話する多くのお客さんが「心理的安全性って大事ですよね」「この部屋の中でなら本音で議論できる」「しがらみがない議論、最高」とおっしゃるので、「大事なんだなぁ・・」と改めて思った次第だ。
座談会のときも、岡本さん柏木さんお二方ともに重要性（メンバーとしても、他のメンバーを向かい入れるためにも）を強調されていた。
★原則9：FEEDBACK
日本のビジネスマンはPDCAサイクルという言葉が大好きで、よくパワーポイントに登場する。だが、ことプロジェクトと人材育成に関する限り、CA（CheckとAction）を育つプロジェクトと同じレベルでやっている職場はほぼない。
育つプロジェクトでは、個人からプロジェクト全体にいたるまで、あらゆる活動に対して、フィードバック（あなたはこう見えますよ、こうだったのでは？）と振り返り（こうすべきだった、これが良かった）を繰り返す。会議の直後にやる振り返りもあれば、3ヶ月ごとに改善点を検討するミーティングもある。サイクル/頻度は様々だ。基本的に人間はフィードバックや振り返りをサボる習性があるので、育つプロジェクトではちゃんと実行するために、意図的に定期的に場を設定する。
====
フィードバックについては、やはりこの記事かな・・本にも転載した。
自分を棚に上げて叱れ。あるいはフィードバックの心得8つ
原則10：RESPONSIBILITY & HAVE FUN!
新しいことにチャレンジする際、メンバーが過度なプレッシャーにさらされないように「失敗してもいいからまずはやってみなさい」というスタンスで接する、一見聞き分けの良い経営幹部もいる。特にデジタル変革などと称して「AIでとにかく何かやってみよう」というようなプロジェクトに多い。
そういう姿勢で「何か」をやっていても、「色々難しいですね」で終わってしまうことが多い。プレッシャーがないのもメンバーからするとありがたくはあるが、「プロジェクトを通じて人を育てる」という観点からはマイナスだ。「成功しなくても良い」というスタンスでは、成長に必要な良質な修羅場にはならないからだ。
住友生命青空プロジェクトは、何万人もの営業職員の働き方にダイレクトに影響する、会社の未来がかかったプロジェクトだった。だからこそ全メンバーが必死にビジョンを想像し、つばを飛ばして熱く議論したのだ。
「絶対成功させろ」という適度なプレッシャーは育つプロジェクトに必須だが、一方でプレッシャーに潰されそうになってビクビクしながら仕事をしても、萎縮してCHALLENGEやTRIALどころではない。プロジェクトは厳しくてシンドイ。だからこそ、その過程自体を楽しんでやろうぜ、というおおらかさ、楽しむ余裕もまた、必須なのだ。
しがらみ抜きで仲間とガチで議論する楽しさ。新しいビジョンを描き、1つ1つ実現していく手応え。ヤバい局面を粘って切り抜けるスリル。その瞬間感じる仲間との連帯感。育つプロジェクトでは、プロジェクトをやることの楽しさを感じられるように場をコーディネートする。
厳しさと楽しさ、というと矛盾しているように感じるかもしれない。だが両立はできる。人間、楽じゃないと楽しくない、とはできていない。
====
座談会をやったときに、柏木さんも岡本さんもこれの大事さを熱く語ってくださったのでとても嬉しかった。岡本さんは「私はプロジェクトでなにかやるたびに、Have Fun！を押し売りしてます(笑)」なんておっしゃっていた。
そして座談会が終わったあとに「単に楽しむだけじゃなくて、RESPONSIBILITYが前提になっているのが大事！」と力説してくださる方もいた。
ブログでこれについて書いた記事はこちら。
プロジェクトは楽しくやるとうまくいく、あるいはマジックワードHaveFun！
============
以上が、育つプロジェクトが大切にしている10の原則である。
これは「仕事を通じて人が育つための10の原則」と言い換えても良い。
あくまでエッセンスなので、これだけ読んだだけではピンとこないところもあるだろう。そういう人のために、事例やエピソードや資料や写真を詰め込んだ分厚い本を書いたので、興味が湧いた人は本を手にとってほしい。
