2024.10.21
お互い疑心暗鬼になりがちな、経営企画と事業部の壁 組織に「分断」が生まれる要因と打開策
リンクをコピー
記事をブックマーク
広木大地氏(以下、広木):さてさて、随分いろいろと盛り上がってしまいました。ここからは質疑応答というか、Slidoに頂いた質問に答えながらコミュニケーションできればと思います。
(スライドを示して)1個目の質問です。「私はメンバー側で、マネージャー陣の『メンバーを成長させたい』という気持ちは感じるのですが、『私たちに言うだけで、マネージャーたちは成長するための努力はしなくていいの?』と不満に思ってしまいます。ちょっと偉そうですが、メンバー側からマネージャーに成長してもらうためにできることってあるんでしょうか」。いい質問ですね。
芹澤雅人氏(以下、芹澤):これは大変いい質問だと思いました。いくつか観点があって、1つは、やはり前提としてNobody is Perfectという考え方を全社で共有することは重要かなと思っています。
上とか下という言葉を使うのはあまり好きではないのですが、マネージャーのような役職が上のポジションに就くと、やはりその人に対して完璧さを求めるのが人間の常なのかなと思います。
とはいえ完璧な人間はいなくて、すべての人が成長をしていく余地はあると思っているので、まずはその感覚を全社で持ちつつ、メンバーにもマネージャーにも等しく成長を求める文化や風土を作っていくことが、前提としてすごく重要だと思います。
そんな中で、メンバー側からマネージャーへ成長してもらうためにできることは、たくさんあるかなと思っています。重要なのは、相互にきちんとフィードバックをすることかなと思います。
あとは、マネージャーから言われたことを疑問のまま終わらせないことはすごく重要です。よく“説明責任”という言葉を使うと思います。「きちんと背景を説明してください」とか、「あまりブラックボックス化してほしくない」「オープンに意思決定を伝えてください」という言葉がすごく広まっているし、かなり行われていると思います。
僕は説明責任とセットで必要なのが、質問責任だなと思っています。確かサイボウズさんがすごく推し進められていて、そのサイボウズさんの本を読んで知ったことだったと思います。
やはり説明された側も受け入れる側も、きちんと質問をする必要があります。疑問に思ったことをきちんと質問して、「私はこういうことがあまりわかっていませんでした」みたいなことを伝える必要があります。
そういうことを通して、マネージャーも「あ、このあたりの説明が足りていなかったんだ」と気づきになったりします。フラットでオープンな関係がこれによって実現されると思っています。
何が言いたいかというと「マネージャーはきっとこうしてくれるだろう」「なんでこうしてくれなかったんだろう」と思っているだけだと、かなり情報に非対称性があります。
マネージャー側も「自分が完璧だろう」と思って「メンバーを成長させたい」とは決して思っていなくて、「きちんとフィードバックが欲しいな」と思っている人たちがほとんどだと思うので、そういったところをお互いきちんと話していくことは、かなり大切なのではないかなと思います。
広木:素晴らしい話でしたね。名村さん、これはどうですか。
名村卓氏(以下、名村):いやあ、素晴らしい話ですね。具体的に何ができるか。マネージャーがポジション的にやはりどうしても上と感じてしまうので、どうしてもマネージャーのほうが成長した人という観点はあるのかもしれません。
エンジニア組織では、どちらかというとマネージャーがエンジニアを支える側というか、彼らを支援するサポーターだったりします。先ほど芹澤さんがおっしゃったみたいに、何を支援してほしいのかをしっかり伝えるのは、けっこう重要かなと思っています。
「今僕にはこういうブロッカーがあって仕事が前に進まないので、なんとかこれを排除する手伝いをしてほしい」という気持ちを伝えることです。マネージャーの性質にもよると思いますが、正しいというか、きちんとしたマネージャーであれば、やはりメンバーのブロッカーを排除するためにいろいろ動いてくれると思います。そういうところを積極的に促して、お互いに気持ちよく仕事できる状態を作っていくのは大事だと思います。
強いていうなら、組織にサーベイを取ってもらって、マネージャーにきちんと自分の現在位置を知ってもらうのはけっこう重要かとは思います。結局マネージャーが見ているメンバー全員がどういうふうに感じているのかとか、どういうふうに思っているのかということです。
マネージャーはメンバーがどれぐらい成果を残すかによって自分の評価につながってくると思うので、いかにメンバーに信頼され、メンバーに成長してもらって、お互いに気持ちよく仕事をして成果を出すかみたいなところをやはり見ていると思います。
なので具体的にいうと、例えばマネジメントサーベイを取って、「マネージャーが今どういうふうにメンバーから思われているか」を積極的にフィードバックしていくことです。定期的に機会を作ったり、ディスカッションのポイントを作ったりしていくのが大事なのかなという気はします。マネージャーからすると、気づきをもらうのは大事かとは思います。
広木:ありがとうございます。そうですね。僕は先ほどの質問にいい答えがあって、『エンジニアリング組織論への招待』という本があります。これをマネージャーさんと一緒に読んでもらうと、少しいいことがあるのではないでしょうか。それは冗談です。
広木:次の質問です。「今回のテーマとは逆方向、メンバーの成長や自立意欲を削ぐような局面はありましたか。あったとすれば、削いでしまった意欲をリカバリーするために対応されたことをおうかがいしたいです」
「いろいろなハードシングスがあって、今まで言ってたことと逆方向に向かわざるを得ない」みたいなシチュエーションのことなんですかね。これは名村さん、何かありましたか?
名村:削ぐようなケースか。例えば会社の技術的な方針にうまくシンクできないケースもあると思います。例えばマイクロサービスをやった時もそうですが、「なぜそれをやる必要があるのか」「なんでそれをするのか」みたいなことはあったりすると思います。
この時すごく感じたのは、やはりコンテキストが伝わっていないと、みんなが違う捉え方をするということです。先ほど芹澤さんの話にもありましたが、マネージャーは伝える努力が必要で、物事のコンテキストみたいなものが抜け落ちてしまうことがあります。
階層的な組織になるとよりそうなるのですが、どういうコミュニケーションでもやはり抜け落ちてしまって、決断した結果だけが伝わってきて、そのコンテキストをみんなが逆読みしてよからぬ方向に行くみたいなことは、何度も経験しました。
リカバリーするというわけではなく、コンテキストドリブンみたいな話もあると思うのですが、コンテキストを正しく伝えたうえで、「そのコンテキストの問題を解決するために何がいいと思いますか」という、意思決定を促すようなコミュニケーションに変えていくのが大事だとその時感じました。
広木:確かに先ほどの質問責任ではないですが、「ナニナニかもしれないから、きっとこうなんだろう」という自己完結ではなく、わからなかったらわからないなりに「これってどういうことなんですか」とうまく聞いてくれたら、背景を説明するチャンスを得やすいですよね。
だけどそれがなかなかないと、「決まっちゃったことなんだ」という感じになります。でもそう思ってしまったら、背景ゼロから一生懸命「こういう背景があってね」と説明するしかないよねということですか。
名村:そうですね。
広木:芹澤さんはこれまでこういった局面はありましたか。
芹澤:大小いろいろあったと思いますが、名村さんが言っていたことがそのとおりかなと思っています。やはりエンジニアは前提として人の役に立つものを作りたくて、特に僕たちはBtoBなので、ユーザーが本当に課題に思っているものを解きたいという思いが強いです。かつ、「自分たちがどうやってそれを解くか」みたいなところまで関わりたいという思いが強いです。なので、WHYを極力きちんと伝える。現場にHOWとWHATを考える裁量をきちんと与えるところはかなり重要かなと思っています。
ただそれでも、「そもそもWHYの部分の定義が間違ってましたよね」とか、「ちょっとこれは納得がしにくいぞ」みたいなものがどうしても出てきてしまったりします。
その時はきちんと話し合って、そのWHYを考えた人が「これがどうしてもいいんだ」という場合はなんとしてもそれを伝えます。「もしかしたらちょっと間違っていたかもしれないな」という時は、そもそものWHYの部分から考え直すプロセスをきちんと取ることは、かなり重要かなと思います。
バリューの話ばかりで申し訳ないですが、僕たちの7つあるバリューのうちの1つに、「人が欲しいと思うものを作ろう」というバリューがあります。これはかなりWHYの部分の意識をアラインするために役立っているかなと思っています。
究極はちゃんと人が求めているもの。“人”というのは多くの場合顧客という文脈で語られるますが、顧客が何を欲しているのかをきちんと考えてWHYを設定するというところを、会社全体でカルチャーとして徹底することはやはり重要だと思うし、それができていない時はきちんとリカバーをします。
いろいろな会社で大小嫌なことがあるというか、ベンチャーだったら方針が変わることもあるし、いろいろな変化に対応するのは重要なことだったりします。その中でもちゃんと意志を持てるような組織を作っていくのはすごく大事です。阿(おもね)ってばっかりでも仕方ないかなと思います。
(次回につづく)
関連タグ:
エンジニアの“自立”には2種類ある ソウゾウとSmartHRの取締役が語る、成長と育成
「カルチャーはバリューで伝える」「ロールモデルを作る」 スタートアップ2社が取り組んだ、成長と自立を促す施策
ソウゾウ・SmartHRの組織図から見るチームの分けかた 取締役が語る、現在の構成がつくられたそれぞれの背景と意図
事業の多角化や育成可能なエンジニア組織を実現するために ソウゾウとSmartHRが抱える課題と、解決のための取り組み
マネージャーの成長のためにメンバーができること オープンな関係と成長機会を作るために大切な「相互のフィードバック」
新人教育の文化がない組織をどうリカバリーするか? “痛み”を伴うからこそ意識したい、言語化と障壁の排除
2024.11.13
週3日働いて年収2,000万稼ぐ元印刷屋のおじさん 好きなことだけして楽に稼ぐ3つのパターン
2024.11.21
40代〜50代の管理職が「部下を承認する」のに苦戦するわけ 職場での「傷つき」をこじらせた世代に必要なこと
2024.11.20
成果が目立つ「攻めのタイプ」ばかり採用しがちな職場 「優秀な人材」を求める人がスルーしているもの
2024.11.20
「元エースの管理職」が若手営業を育てる時に陥りがちな罠 順調なチーム・苦戦するチームの違いから見る、育成のポイント
2024.11.11
自分の「本質的な才能」が見つかる一番簡単な質問 他者から「すごい」と思われても意外と気づかないのが才能
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.11.18
20名の会社でGoogleの採用を真似するのはもったいない 人手不足の時代における「脱能力主義」のヒント
2024.11.19
がんばっているのに伸び悩む営業・成果を出す営業の違い 『無敗営業』著者が教える、つい陥りがちな「思い込み」の罠
2024.11.13
“退職者が出た時の会社の対応”を従業員は見ている 離職防止策の前に見つめ直したい、部下との向き合い方
2024.11.15
好きなことで起業、赤字を膨らませても引くに引けない理由 倒産リスクが一気に高まる、起業でありがちな失敗