チームが最もベストな状態は「責任と心理的安全性が高い」
伊藤直也氏（以下、伊藤）：次は、「組織課題の発見とアプローチ」について。
僕が最近すごく気に入っている考え方がありまして、それが「心理的安全性と責任」という話なんですよね。『チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ』に書いていたもので、ここでもやはり「2軸で切りましょう」というコンサルタントみたいな話なんですけど、これはすごく本質だと思って見ていました。
この四角い箱が組織やチームの雰囲気だと思ってください。横軸が責任の大きさ。縦軸が心理的安全性。
「心理的安全性」という言葉が若干わかりづらいんですけど。これは「チームの中でどんな発言をしても、自分の立場が脅かされることはないだろう」というような、隣の人をよく知っていて・遠慮しないで話せて・建設的な議論ができる、ということです。居心地がいいとかよりも、「遠慮なく発言できること」です。
基本的に、そのチームが最もベストな状態になるのは、責任が大きくて心理的安全性が大きい状態を指します。
これはみなさんも経験でわかると思うんですけど、責任だけが大きくてチームの状況が最悪だと、もう嫌で嫌でしょうがないですよね。不安ですよね。
一方で、チームの状態はものすごくいいんだけど責任がしょぼい。
ここに「快適」と書いてますけど、これはいい意味じゃなくて、要するに「ぬるま湯」ということなんですよね。仲良しグループになっちゃって、ビジネス的な厳しさがない状態なので、「チームが学習しないとそのミッションをクリアできない状況」になっていないから、現状維持・保守的になってしまう。
また、責任も低くて心理的安全性も低い状態だと、基本的には仕事に関心も持てないので、無関心になっていく。ここにいくと、人は辞めてしまうという話なんですが。
それが、きちんと責任と心理的安全性が高くなると、人は学習をしながらチームできちんと問題を解決していく状態になるんですね。
これがなぜ重要かというと、自分のチームが今のマトリクスのどこにおかれてるかによって、マネジメントで取るべきアプローチがけっこう変わってくるんです。これは、僕の経験上で感じたことなんですよね。
縦軸・横軸のどちらで考えるかで、施策も変わる
おもしろい事例が一休にあるので、紹介します。一休という会社の中では、大きくはホテル予約をやっている宿泊事業部と、飲食の予約をやっているレストラン事業の2つがあります。それぞれにエンジニアの部署があるんですね。
長年、その部署ごとに仕事をしているので、それぞれマネジメントスタイルが違うんですよ。事業責任者の性格の違い、あるいはエンジニアのボスの性格もあって、ちょっとタイプが違うんです。
そんな2つの組織に対して、当時、僕がいろんな人の話を聞いて「こうだね」と言い、みんなも「そうだね」と言ったのがこれです。
レストラン事業部は、少しぬるま湯だったんですよね。みんなが仲良くて、朝会も和気あいあいとやっていて。チームとして、雰囲気はすごくいいんだけど、プロジェクトとして何をやっているかというと、細かいことばかりやっていてよくわからない。
一方で宿泊事業部は、売上もすごく上がっているし、会社の売上げのドライバーなので、プロジェクトもトップダウンでゴーンと大きいのが降ってきたりして、みんな「おおっ」とか言いながらやっている。けれど、若干チームの中でうまくお互いの関係性を築けていない状態だったんです。ベテランの人が辞めてしまうこともあった。
青もオレンジも、右上に持っていきたいわけですよね。だけど、同じ「右上に持っていきたい」でも、レストラン事業部はぬるま湯状態です。そんなレストラン事業部でやらなきゃいけないことは、「君たちがやらないといけないのはこれだ」「フォーカスすべき問題はこれだから、そっちはやるな」という、きちんとしたプロダクトマネジメントなんですよね。
宿泊事業部の場合、プロダクトはきちんと作ることができている。スケジュールもきちんとしてましたからね。だからアウトプットは出てる。しかし、それを気合いと根性でやっていたり、あるいは運用業務の負荷が高くなっちゃって、特定の人にその業務が集中していてつらい思いをしてる……などがたくさん起こっていました。
そこで、きちんとチームビルディングをして会話をして、負荷を平準化するアイデアを出し合うといったマネジメントをしなきゃいけなかったんですね。
縦軸・横軸のどちらで考えるかで、出てくる施策が変わります。これはぜひ参考にしていただきたいと思います。
マネジメントのコストを下げるため、フレーミングをちゃんとやる
「組織には構造が必要なのがわかった」「組織の目指すべき方向性を分析するためのフレームワークも手に入った」「じゃあ、そろそろミクロのところに入っていこう」というので、ヒューマンマネジメントに入りましょう。
よく方々で話してるんですけど、技術顧問時代に、顧問を依頼に来る人の典型的パターンがこれです。開発組織で問題が起こると、エンジニアの人はそれを「技術の問題だ」と思い込んでやってくる。
「うちの会社はいい感じに開発できてなくて、技術的にイケてない。技術的にイケてるようにしたいです」と言ってくるんですけど、実際に話を聞いてみると、ツールが悪い、レガシーがあるではなくて、そもそも人が全然うまく働ける状態になってない、大きな意思決定をできる状況になってない、みたいなことがよくあります。
「技術の組織だから、技術の方向に問題がある」と思いがちな頭を切り替えて、むしろ「人のほうに問題がある」と考えたほうがだいたい当たりやすい……というのが、さっきの『ピープルウェア』に書いてることです。
その「人」の話です。人の話は本当にいろいろあるんですが、ものすごく重要なことを2つに絞って話します。
まず「フレーミング」。たぶん聞き慣れない言葉だと思うんですけど、すごく大事です。フレームとは、絵画などが載っている枠のことです。
「認知フレーム」というものがあります。これは、人間は物事を見るとき、人によって使ってるフレームが違うということなんですよね。ある状況について、みんな思い込みがいろいろあって「この人はここ見てるけど、この人はここを見てる」があります。
そして、そのフレームは対話によって変えることができます。ちょっと自己啓発的な話になるんですけど、これは実際にそうです。
同じ仕事を振るときも、例えば「これは作業を行う場です」と伝えるのか、「学習する場です」と伝えるのかで、最終的に出てくる結果が全然違うという話があります。だから、ちゃんと良いフレームを使いましょう、使わせるようにしましょう。これがフレーミングになります。
一般的には「期待値調整」と言われますよね。会社側でマネジメントが求めることと、本人がやりたいことをきちんとすり合わせることを「期待値調整」と言います。
マネージャーから「こういうことやってほしい」と伝えるだけじゃなくて、物事の見方をなるべく正しい方向に持っていくのがフレーミングですよね。
これをちゃんとやるというのが、組織マネジメントをする上で最も根本的に利いてくるので、重要なことだと思ってます。
とくに、新しいプロジェクトに人をアサインするとき、新しいポジションリーダーになってほしいときに、このフレーミングをサボると、だいたいあとになって問題が起こります。
マネジメントをやってる人は、マネジメントで手がいっぱいになりがちなんです。しかし、トータルのマネジメントコストを下げたいなら、最初の期待値調整やフレーミングをしっかりやることに時間を割くといいです。そこさえきちんとやっておけば、あとは放っておいてもうまくいくので、トータルでのマネジメントコストが下がることになります。
先ほど話したとおり、その本人にとって同じ変化でも、フレーミングの如何で印象がまったく変わります。
たとえば、とある人の組織的な役割が決まっていて、「組織図上、ここにいるから君の仕事でしょう」「チケットを切ったのでお願いします」と、チケットをいきなり渡されることがよくあると思うんですけど。
これをやると、「やれ」と言われた人のモチベーションはだいたい下がりますよね。でも、ちゃんと全体の中で「今お願いしようとしてることがこういう意味があって」「これは君のこういう能力を持って解決してほしいから、ぜひやってほしい」と丁寧に説明すると、「わかりました」と言って、やってくれる。そういう簡単な話なんです。
ただし、忙しくなってくるとついついサボっちゃうのが、マネージャーのよくあることです。「そこは面倒くさがらずにきちんとやろうね」が言いたいことです。
とくにリーダーを抜擢する、もしくはポジションを変えるときは、これをきちんとやっておくのが重要です。そうしないと、後々その期待値がずれていって、マネージャーとリーダーで言い合いになるなんてのが起こります。
1on1は、組織の問題を明確にしてくれる
あとは、1on1の面談を……。やってますか、みなさん？ 自分のチームのメンバーとやってるかな？ ちょっとハウツーの話なんですけど、これをやりましょう。
もともと、僕がなぜ1on1の面談をやったほうがいいと思ってやり始めたかというと、任天堂の岩田（聡）さんが昔『ほぼ日（ほぼ日刊イトイ新聞）』で対談した記事があり、これ読んで「おおっ」と思ったからです。
岩田さんが任天堂の社長に抜擢されて、就任した当時になにをやったかというと、全社員と1on1の面談をずっとくり返すことだったらしいんですよ。
岩田さんって、みなさんご存じのとおり、すごいハッカーで、プログラムもバリバリ書けるし、ゲームも作れるクリエイターです。その人が「じゃあマネジメントするか」と言って始めたことが、この1on1の面談だったそうです。
岩田さんは、（ほぼ日の対談記事の中で）「1on1の面談をすると、どういうふうに組織を作り直して、どういう運営をしたらいい、云々が全部わかります」と書いてます。この記事はすごくいいので、ぜひ読んでほしいんですけど。
「問題発見が重要だ」という話を冒頭でしましたが、1on1をするといろんな問題が手に取るようにわかるんですよね。
さっきのKaizen Platformの例が良い例なんですけど、「自分は1人で仕事をしてて、ちょっと不安です」という話は、1on1で話してるときに初めて出てくるんですよ。
同時期にいろんな人と話してると、4〜5人が同じこと言ったりするのは、必ず組織になにかしら課題を抱えてるサイン。でも、違う人がそれぞれよくよく聞くと同じことを言ってる……など、そういうものを面談以外で見つけるのは、なかなか難しいんじゃないかなと思います。
あともう1つは、さっき話したフレーミング。期待値をきちんと揃えるというのが、1on1のなかで一番やりやすい例です。
そのときのコツがあります。期待値調整、あるいは新しいお願いをするときは、1on1をやって、最初に相手が話したいことを全部話させて、バケツを空にするというのがすごい大事。
そして、相手のバケツが空になってきたところに、「じゃあ、僕らも話があるんだけど」ってポンと放り込むと、スッと入っていくんですよ。
これをやらずに、ふだんから仕事で不満や不安を抱えている人に対して、いきなりこっちから「ちょっと、新しいことがあるんだけど……」とお願いすると、だいだい不満を溜めてしまって、最後には辞めてしまうことが起こる。定期的にバケツを空にしてから（こちらからの要望などを）入れることをくり返すのが、けっこう重要です。
ただ1on1は、慣れてないと何を話していいかわからない。この間、誰かが書いてたんですが、「事前に話したいことをアンケートでとっておいて、それを見ながら話すと話してやすくていいですよ」とのことでした。
これを「バウンダリーオブジェクト」と呼んでいます。要するに、2人の会話の間に物を1つ置くと、会話の対象がそっちに向かうので、話しやすくなることがあるんです。まあ、これも1つのコツです。
「人の問題」こそ、冷静になること
一休の場合、やはり僕もCTOに就任したときに、「最初にやらなきゃいけないのはこれだな」と思って、初日から40数名のエンジニアと1〜2時間ずつ1on1をやりました。人の話をずっと聞くのはけっこうしんどいんですけど、これを1ヶ月くらいかけて丁寧にやりました。
今は、僕も不定期でいろんな「この人と話したほうがいいな」と思う人と話すんですけど。昔から組織にいる人は、しがらみも含めていろんな問題をよく知ってるので、話を聞く度に発見がありますね。あとは各事業部のマネージャーが、各チームのエンジニアと定期的に1on1して、月に1回くらいやっているみたいです。そこで気になることがあったら、マネジメントミーティングで相談しています。
さっき、心理的安全性と責任の話で「この位置にチームがあるよね」という話がありましたが、これをトップダウンで「僕たちの組織は今こういう状況なので」とボーンっていきなり図をみせても、たぶんみんなには響かなかったと思うんですよ。
僕はこれについて最初に仮説を立てて、何人かと「なんとなくこうなんじゃないかな」と話していてわかってきたので、この図を先に作っていました。そして、1on1する人と「こんな感じかな？」と言って、図を見せながら1on1で話すと、「確かにこうかもしれませんね」という話になっていきます。
たくさんの人と1on1で話して、なんとなくコンセンサスがとれた状態になってから「じゃあこれでちゃんと全体でみんなで話そう」と、みんなの前で話します。そこから、実際のアクションや組織戦略を決めていく……というのをやりました。まあ、それくらい1on1で話すのが大事ですってことです。
ただし、ヒューマンマネジメントにおいて、すごく注意しなきゃいけないことが1つあります。人の話題は、やはり組織の中ですごく強く意識が持っていかれるんですよね。
今日ずっと言ってますけど、マネージャーの大事なことは「今その時点でフォーカスしないといけないことに集中すること」ですが、「誰それさんが辞めたいと思ってます」というと、それまですごく大事なこと考えていたことが、まったく別のことにドーンと全ての意識を持っていかれてしまい、みんなが慌てふためいて「もうちょっと1on1しなきゃ」「なんで辞めたいのか聞いてみて」と、わ～ってなっちゃうんですよ。
だんだん人が増えてくると、会議が「人」の話ばかりになるんです。それはけっこう危ないです。「人の話題にそこまで時間をかけていいのか」は、常にプロダクトや組織、事業の話と天秤にかけて話していく。冷静に切り替えるのが大事だと思います。
