マネージャーに成長してもらうためにメンバーができること
広木大地氏（以下、広木）：さてさて、随分いろいろと盛り上がってしまいました。ここからは質疑応答というか、Slidoに頂いた質問に答えながらコミュニケーションできればと思います。
（スライドを示して）1個目の質問です。「私はメンバー側で、マネージャー陣の『メンバーを成長させたい』という気持ちは感じるのですが、『私たちに言うだけで、マネージャーたちは成長するための努力はしなくていいの？』と不満に思ってしまいます。ちょっと偉そうですが、メンバー側からマネージャーに成長してもらうためにできることってあるんでしょうか」。いい質問ですね。
芹澤雅人氏（以下、芹澤）：これは大変いい質問だと思いました。いくつか観点があって、1つは、やはり前提としてNobody is Perfectという考え方を全社で共有することは重要かなと思っています。
上とか下という言葉を使うのはあまり好きではないのですが、マネージャーのような役職が上のポジションに就くと、やはりその人に対して完璧さを求めるのが人間の常なのかなと思います。
とはいえ完璧な人間はいなくて、すべての人が成長をしていく余地はあると思っているので、まずはその感覚を全社で持ちつつ、メンバーにもマネージャーにも等しく成長を求める文化や風土を作っていくことが、前提としてすごく重要だと思います。
そんな中で、メンバー側からマネージャーへ成長してもらうためにできることは、たくさんあるかなと思っています。重要なのは、相互にきちんとフィードバックをすることかなと思います。
あとは、マネージャーから言われたことを疑問のまま終わらせないことはすごく重要です。よく“説明責任”という言葉を使うと思います。「きちんと背景を説明してください」とか、「あまりブラックボックス化してほしくない」「オープンに意思決定を伝えてください」という言葉がすごく広まっているし、かなり行われていると思います。
僕は説明責任とセットで必要なのが、質問責任だなと思っています。確かサイボウズさんがすごく推し進められていて、そのサイボウズさんの本を読んで知ったことだったと思います。
やはり説明された側も受け入れる側も、きちんと質問をする必要があります。疑問に思ったことをきちんと質問して、「私はこういうことがあまりわかっていませんでした」みたいなことを伝える必要があります。
そういうことを通して、マネージャーも「あ、このあたりの説明が足りていなかったんだ」と気づきになったりします。フラットでオープンな関係がこれによって実現されると思っています。
何が言いたいかというと「マネージャーはきっとこうしてくれるだろう」「なんでこうしてくれなかったんだろう」と思っているだけだと、かなり情報に非対称性があります。
マネージャー側も「自分が完璧だろう」と思って「メンバーを成長させたい」とは決して思っていなくて、「きちんとフィードバックが欲しいな」と思っている人たちがほとんどだと思うので、そういったところをお互いきちんと話していくことは、かなり大切なのではないかなと思います。
広木：素晴らしい話でしたね。名村さん、これはどうですか。
名村卓氏（以下、名村）：いやあ、素晴らしい話ですね。具体的に何ができるか。マネージャーがポジション的にやはりどうしても上と感じてしまうので、どうしてもマネージャーのほうが成長した人という観点はあるのかもしれません。
エンジニア組織では、どちらかというとマネージャーがエンジニアを支える側というか、彼らを支援するサポーターだったりします。先ほど芹澤さんがおっしゃったみたいに、何を支援してほしいのかをしっかり伝えるのは、けっこう重要かなと思っています。
「今僕にはこういうブロッカーがあって仕事が前に進まないので、なんとかこれを排除する手伝いをしてほしい」という気持ちを伝えることです。マネージャーの性質にもよると思いますが、正しいというか、きちんとしたマネージャーであれば、やはりメンバーのブロッカーを排除するためにいろいろ動いてくれると思います。そういうところを積極的に促して、お互いに気持ちよく仕事できる状態を作っていくのは大事だと思います。
強いていうなら、組織にサーベイを取ってもらって、マネージャーにきちんと自分の現在位置を知ってもらうのはけっこう重要かとは思います。結局マネージャーが見ているメンバー全員がどういうふうに感じているのかとか、どういうふうに思っているのかということです。
マネージャーはメンバーがどれぐらい成果を残すかによって自分の評価につながってくると思うので、いかにメンバーに信頼され、メンバーに成長してもらって、お互いに気持ちよく仕事をして成果を出すかみたいなところをやはり見ていると思います。
なので具体的にいうと、例えばマネジメントサーベイを取って、「マネージャーが今どういうふうにメンバーから思われているか」を積極的にフィードバックしていくことです。定期的に機会を作ったり、ディスカッションのポイントを作ったりしていくのが大事なのかなという気はします。マネージャーからすると、気づきをもらうのは大事かとは思います。
広木：ありがとうございます。そうですね。僕は先ほどの質問にいい答えがあって、『エンジニアリング組織論への招待』という本があります。これをマネージャーさんと一緒に読んでもらうと、少しいいことがあるのではないでしょうか。それは冗談です。
メンバーの成長や自立意欲を削いでしまった経験
広木：次の質問です。「今回のテーマとは逆方向、メンバーの成長や自立意欲を削ぐような局面はありましたか。あったとすれば、削いでしまった意欲をリカバリーするために対応されたことをおうかがいしたいです」
「いろいろなハードシングスがあって、今まで言ってたことと逆方向に向かわざるを得ない」みたいなシチュエーションのことなんですかね。これは名村さん、何かありましたか？
名村：削ぐようなケースか。例えば会社の技術的な方針にうまくシンクできないケースもあると思います。例えばマイクロサービスをやった時もそうですが、「なぜそれをやる必要があるのか」「なんでそれをするのか」みたいなことはあったりすると思います。
この時すごく感じたのは、やはりコンテキストが伝わっていないと、みんなが違う捉え方をするということです。先ほど芹澤さんの話にもありましたが、マネージャーは伝える努力が必要で、物事のコンテキストみたいなものが抜け落ちてしまうことがあります。
階層的な組織になるとよりそうなるのですが、どういうコミュニケーションでもやはり抜け落ちてしまって、決断した結果だけが伝わってきて、そのコンテキストをみんなが逆読みしてよからぬ方向に行くみたいなことは、何度も経験しました。
リカバリーするというわけではなく、コンテキストドリブンみたいな話もあると思うのですが、コンテキストを正しく伝えたうえで、「そのコンテキストの問題を解決するために何がいいと思いますか」という、意思決定を促すようなコミュニケーションに変えていくのが大事だとその時感じました。
広木：確かに先ほどの質問責任ではないですが、「ナニナニかもしれないから、きっとこうなんだろう」という自己完結ではなく、わからなかったらわからないなりに「これってどういうことなんですか」とうまく聞いてくれたら、背景を説明するチャンスを得やすいですよね。
だけどそれがなかなかないと、「決まっちゃったことなんだ」という感じになります。でもそう思ってしまったら、背景ゼロから一生懸命「こういう背景があってね」と説明するしかないよねということですか。
名村：そうですね。
広木：芹澤さんはこれまでこういった局面はありましたか。
芹澤：大小いろいろあったと思いますが、名村さんが言っていたことがそのとおりかなと思っています。やはりエンジニアは前提として人の役に立つものを作りたくて、特に僕たちはBtoBなので、ユーザーが本当に課題に思っているものを解きたいという思いが強いです。かつ、「自分たちがどうやってそれを解くか」みたいなところまで関わりたいという思いが強いです。なので、WHYを極力きちんと伝える。現場にHOWとWHATを考える裁量をきちんと与えるところはかなり重要かなと思っています。
ただそれでも、「そもそもWHYの部分の定義が間違ってましたよね」とか、「ちょっとこれは納得がしにくいぞ」みたいなものがどうしても出てきてしまったりします。
その時はきちんと話し合って、そのWHYを考えた人が「これがどうしてもいいんだ」という場合はなんとしてもそれを伝えます。「もしかしたらちょっと間違っていたかもしれないな」という時は、そもそものWHYの部分から考え直すプロセスをきちんと取ることは、かなり重要かなと思います。
バリューの話ばかりで申し訳ないですが、僕たちの7つあるバリューのうちの1つに、「人が欲しいと思うものを作ろう」というバリューがあります。これはかなりWHYの部分の意識をアラインするために役立っているかなと思っています。
究極はちゃんと人が求めているもの。“人”というのは多くの場合顧客という文脈で語られるますが、顧客が何を欲しているのかをきちんと考えてWHYを設定するというところを、会社全体でカルチャーとして徹底することはやはり重要だと思うし、それができていない時はきちんとリカバーをします。
いろいろな会社で大小嫌なことがあるというか、ベンチャーだったら方針が変わることもあるし、いろいろな変化に対応するのは重要なことだったりします。その中でもちゃんと意志を持てるような組織を作っていくのはすごく大事です。阿（おもね）ってばっかりでも仕方ないかなと思います。
（次回につづく）
