Konifar's ZATSU

私はのび太の味方じゃないわ、悪の敵よ

考え方が合わないのか情報が揃っていないのか

「考え方が合わないなー」と感じた時は、相手と自分の持っている情報が揃っているかを疑ったほうがいいよね、という話を雑に書く。

たとえば「上司の理解がない」「部下の危機感が足りない」「同僚が慎重すぎる」みたいなやつ。なんでそんな考え方をするのかわからなくて憤りを感じるようなことがある。本当に考え方が合わないこともあるが、実は持っている情報量の違いによって思考結果が異なるだけで、思考回路自体に違いはなかったということも多い。

例を出してみる。プロダクトの1年後を考えてこれを絶対にやったほうがいいというボトムアップの提案が受け入れられなかったとする。

この時、実は相手は裏側で短期の売上目標を達成するために必死なのかもしれないし、ステークホルダーとのハードな交渉をしているのかもしれない。あるいは、プライベートで大変なことがあって考える余裕がないのかもしれない。逆の立場で見ると、実は提案する側はメンバーのモチベーションを考慮していて、これができないことによる組織のネガティブインパクトに危機感を持っているかもしれない。

この例だとコミュニケーションや提案をしっかりやれよという話に見えるかもしれないが、こういった「実は」「かもしれない」と表現される情報が擦り合っていないことが意外と多い。それを「考えが合わない」と勘違いしてしまったりする。

ここでいう情報というのは色々ある。過去の事例、現在の組織や事業の状況に加えて、人の感情やモチベーション、個々人の経験などもそう。そういった情報を揃えてから話すと「あーそれならたしかにね」となることもわりとある。

まあわかるけど、こういう情報揃えるのってめんどくさいし大変だよね。相手にも一理あると考えて解釈を広げて対話する必要があるので、感情のコントロールも要求される。

だからこそ、ここのコストを下げるために情報をフラットにする仕組みや対話できる文化が必要になる。しかしそれらはあくまでコストを下げる役割であり、情報を揃えるためには一定のコストを払う気持ちでいたほうがいい。相手への期待が大きいほど、そこのコストを払うことに対して憤りを感じたりするかもしれないが、まあ役職や役割による過剰な期待は持たずにやっていったほうがいいと思う。その方が自分がコントロールできて楽だしね。

にんげん、むずかしい。以上!

 

権限委譲しきれていない時に意識すべきこと

権限委譲でよくある失敗として、「権限委譲しきれていない」というのがある。気になってちょいちょい細かく口を出してしまうのだ。自分の経験だと、もともと優秀なプレイヤーだった人に多い気がする。

権限委譲する側でもされる側でも改善はできるが、どちらかといえば権限委譲する側の方がコントロールしやすいので意識するべきことを雑にまとめておきたい。

自分の集中するべきことを明確にする

  • 口を出してしまうのは、口を出す余裕があるから
  • 委譲した分何か別の集中するべきことがあるはずだが、それが明確じゃないか忘れてしまっている
  • 自分が為すべきことを明確にして、優先順位を考えるべき

期待の認識を合わせる

  • 口を出してしまうのは、期待を下回っているように感じてしまうから
  • そもそもどこまでを期待していて何を任せているのか認識を合わせた方がいい
  • デリゲーションポーカーなどで委譲の分野やレベルなどを確認するべき

情報が渡っているか確認する

  • 口を出してしまうのは、委譲した部分に関わる意思決定に不安があるから
  • 意思決定も任せたのなら、意思決定に必要な情報が行き渡る状態になっているかに気を配った方がいい
  • 必要に応じて会議体やコミュニケーションラインを一緒に見直すべき

チェックポイントを決める

  • 口を出してしまうのは、変な方向に進んでいないか不安になるから
  • 「放置しすぎ」にならないよう、確認のタイミングを最初に決めておくとよい
  • 相手を信じるだけではうまくいかないので、伴走の設計が大事

解決策ではなく懸念や課題だけを伝える

  • 口を出してしまうのは、こうした方がいいんじゃないかとヤキモキしてしまうから
  • 自分の経験や思想から解決策のアイデアを伝えてしまいがち
  • あくまで自身の懸念や課題感だけを伝えて、どうするかは委譲した相手に意思決定してもらうスタンスでいた方がいい

たぶん他にもありそうなので、酸いも甘いも噛み分けてきた方々の知見吸いたい。

委譲全般で抑えるポイントは次の記事をバイブルにするとよいと思う。

blog.shojimiyata.com

マネージャーに"キャパオーバー"はない

Sansanの@m_nishibaさんを雑談に誘ってお話ししている中で、自分がふと「ちょっとキャパオーバー気味なんですよねぇ」と口にしたところ、それはちょっと"臭う"兆候だよねという話になったので雑にまとめておきたい。

3行でまとめるとこんな感じ。

  • (一般論として) マネージャーはやることを自分で決められる裁量がある
  • キャパオーバーではなく、"優先順位を下げてやらない"判断であるべき
  • キャパオーバーという言葉が出てきたら一度立ち止まって優先順位の見直しをするとよい

たしかに~~~~。ポロッとキャパの話してしまうことがあるんだけど、本来は何をやるか/やらないか (≒キャパ) を決めるのもマネージャーの役割なので、キャパオーバーはおかしい。キャパオーバーという言葉が出てきたら、それは優先順位づけがうまくできていないサインと思う方がよい。

とはいえマネージャーはやること多すぎて自分でキャパ決めるって言ってもそんな綺麗にいかないでしょ、という意見もわかる。わかるよ。実際そうなりがちだよね。ただ、そううまくいかないとしてもキャパオーバーという言葉をよくない兆候として扱って立ち止まって責任範囲や優先順位を見直してみる、というのはわりと汎用性の高いTipsではないかと思う。要は「キャパオーバーを"優先順位を下げた"という表現で言い換えられないか」を考えてみましょうということである。

書いていて思ったけど、これ別にマネージャーに限った話ではないよね。限界はあるものではなく、自分で決めるものでござるよ。

UzabaseのPodcast『Meet UB Tech』で、キャリア、VPoE README、CTOとの役割分担、信頼と心理的安全性、採用活動の委譲などについて話しました

UzabaseのPodcast Meet UB Techに、初のゲストとして参加してきた。光栄である。

open.spotify.com

tech.uzabase.com

雑に言うと以下のような話をしている。がんばって話したので、気になったトピックがあれば聞いてみてほしい。自分の音質が悪すぎて申し訳ない!マイクも使っていたのになぜ...

  • Kyashに入社してから今までの役割の変遷
  • VPoEになった背景
  • VPoEとCTOの役割分担
  • なぜVPoE READMEを書いたのか
  • VPoE READMEを読んだ労務や人事のメンバーからも反応があった
  • VPoE READMEに込めた温度感
  • VPoEを3ヶ月やってみた時点での反省
  • 目標の立て方に関するマインドチェンジ
  • 事業成長からの逆算
  • 説明責任を最初に考えたらダメ、実行責任が先
  • 信頼と心理的安全性
  • メンバーからの「ビビりすぎ」というフィードバック
  • 採用活動の責任4分割と委譲
  • 委譲における期待の伝え方、認識合わせ
  • EMからICになった背景
  • EMとICを行き来できる制度設計(整ってない)
  • Kyashのメンバーとのキャリアの向き合い方
  • Kyash採用やってるよ!!!

ちなみにもともと自分はMeet UB Techを息子氏と散歩しながら聞いていた。毎回わりと面白いが、一番好きなのは林尚之さんがゲストで出ていた『#6 エンジニアのキャリアと組織』である。

open.spotify.com

この中で話されていた、採用活動や予算策定などのマネジメント領域を3年くらい前からメンバーで行うようにしているという話は、自分の今の委譲の方針にも影響している。

パーソナリティのイイダユカコ @becyn さんの声も聞きやすくてよい。もうひとりの赤澤 @go0517go は自分には珍しく定期的に会って近況を話す仲の友人だが、こうして仕事として絡めるのは嬉しいし収録も楽しかった。

では、次回は After Show「新海誠 ー 光の表現の変遷と俺たちの焦燥感」でお会いしましょう(嘘)Bye!

不満への過剰な共感は状況を悪化させる

何かを相談された時、自分は相手の状況や主張にまず共感を示してしまいがちである。嘘をついて同調しているわけではないのだが、この姿勢自体が状況を悪化させることもわりとあるよなと思っていて、雑にまとめておきたい。

たとえば「他チームの◯◯さんが開発の状況を理解してくれていない。理解する気も見えない」といった相談をされたとする。それに対して、「あーなるほど、たしかにねぇ」みたいなことを言った瞬間に、溝を広げることになってしまうかもしれない。

この場合、本来はお互いの歩み寄りが必要な話なのだが、相談してくれた側に寄り添って話すことで当事者間の関係性がよくなるどころか悪化することもありうる。吐き出してスッキリするかもしれないが、根本の解決にはならない。

チームメンバー思いのマネージャーや組織の中の"いい人"ほど、知らず知らずのうちにこの罠に陥りがちな気がする。おそらくコーチングを学んだ人はこういう相談を受けた時の言葉の引き出しやシナリオを多く持っていて、うまく相手に気づきを与えて自己解決を促すことができるのだと思う。自分はまだその域に達していないので、後で「さっきのアレ、自分と話したことでむしろ状況を悪化させてしまったかもしれないな」と反省することがある。

じゃあどうすればいいかというとケースバイケースで悩ましいのだけれど、人と人との関係性の相談であれば当事者同士で直接すぐ話してもらうよう促すのがよいと思う。言語化とコミュニケーションが難しいことも多いので、そこは最大限フォローするというスタンスで相手に寄り添うのがよさそう。あとは自分自身きちんとコーチングを学んで引き出しを増やしていくしかない気がする。

書いてみたものの、身に染みついた性格によるものなのでかなり意識しないと矯正できないんだよなあ。ちなみにこの相手の気持ちを過剰に気にしてしまう性格は、5歳くらいの頃に友だちにいじわるをしていたら母親にチビるくらい怒られた経験から形成されている。イルミの針を抜いたキルアをイメージしながら頑張るしかない。

メンバーからのフィードバックに向き合う

7月にEMをやめたのだけれど、実は最近マネジメントロールに戻った。

1on1などで自分や組織の至らないところについてメンバーから率直なフィードバックをもらうことが多く、そのたびに本当にありがたいと思っている。ちなみに最近もらってよかったフィードバックは、「ハレーションを恐れすぎ」です。

メンバーからのフィードバックは受け手のスタンスや振る舞い次第で何も言ってもらえなくなったり信用をなくしたりすることもあるので、「メンバーからのフィードバックに向き合うとはどういうことか」を雑にまとめておきたい。

フィードバックをもらうまで

  • フィードバックを受け付けていることを伝える
    • 言いにくい話も多いので、スタンスを明確に伝えておかないとフィードバックはもらえない
    • 予定が詰まっていると遠慮されてしまうので「予定は調整するのでいつでも声をかけてほしい」と伝えるとか
    • 意見を持ってそうな人には直接声をかけるのもよい
    • 目安箱を作ってたまに呼びかけてもいいかも
    • 一度だと伝わらないので何度も言っていくのも大事
  • ハードルを下げる
    • フィードバックは技術と慣れが必要なので難しい
    • 「意見がまとまってなくても伝えてほしい」、「〜のように見えるという主観の意見が欲しい」「DMでもOK」といった感じで、フィードバックをしやすい呼びかけをする
    • 当事者意識の高い人ほど「自分でも何かできることあるんじゃないか」と考えて率直な意見を伝えられないこともあるので、「他責な意見を歓迎する」「耳の痛いことほど言ってほしい」といったメッセージを伝えるのも大事
  • タイミングを作る
    • いつでも言ってと伝えていても、改まった場がないと言えない / 言わない人も多い
    • タイミングを作ってあげることで、フィードバックをもらいやすくなる

フィードバックをもらう時

  • 感情的にならない
    • 一度でも感情的な反応をしてしまうと、二度とフィードバックしてもらえなくなるくらいの気持ちでいた方がいい
    • 「伝えてくれた内容で怒ったりすることはない。もしかしたら自分の至らなさにつらくなってちょっと表情や振る舞いに表れちゃうかもしれないけど、それは自分の問題であなたのフィードバックに対する不満ではないので気にしないでほしい」みたいな話を最初に伝えておく
  • ネガティブフィードバックこそ求めていると伝える
    • 気遣っていい面を言おうとしがちなので、いっそ「耳の痛いフィードバックでけちょんけちょんにしてほしい」と伝えるくらいの方がいい
  • お礼を言う
    • フィードバックするのは大変だし、時には勇気がいることなのでまずは感謝の言葉を伝える
  • 正しく理解する
    • わかったふりをするのが一番ダメ
    • 相手の伝えたいことを正しく理解できるように深掘りの問いかけをしたり、自分の理解が正しいかを別の言葉で確認したりする
  • 感想とギャップを伝えて対話する
    • フィードバック内容に対して感じたことや、自分の目線から見て異なることを丁寧に話す
    • 相手を責める雰囲気にならないよう、言葉に注意する
    • ギャップがある時は情報に差があることが多い。情報に差が出てしまっていること自体は自分に原因があるという前提に立っておく
  • できる約束をする
    • フィードバックがどう活かされるのか、何が変わるのかを伝えるのが大事
    • できるかわからない約束ではなく、確実にできる約束をひとつ話しておくとよい。この積み重ねこそが信用になる

フィードバックをもらった後

  • どう活かされたかを伝える
    • フィードバックに対して何をすることにしたのか、やってみてどうだったかを本人に伝える
    • これをきちんとやらないと「あれどうなってるんだっけ?」「何も変わってない」「言っても無駄」といったよくない状態になることもある
    • うまく改善できなかったとしても伝える。そうしないとフィードバックを受けてアクションを起こしたことすら伝わらない

ざっと書いてみたけど、なかなか難しい。たぶんメンバーとの関係性によっては必要ない項目も入ってると思う。 少なくとも自分はこのあたりを意識してメンバーからのフィードバックに向き合っていこうと考えている。

率直な意見をぶつけてくれる人に敬意を払う

率直に思ったことを言ってくれる人は貴重である。貴重であるが故に、敬意をもって接しなければならない。

特に反対意見や耳の痛い感想はなかなか言えない人も多い。 たとえば何かをやるかどうかの相談をした時に、「そもそもやる意味あるんですか?」とか「全く賛成できないですね」とか「自分は絶対やりたくないです」とか。言い方は改善の余地があるかもしれないが、こういう意見をぶつけてくれる人は大事にした方がいい。

大事にするというのはどういうことかというと、意見を言ってくれたことに対してお礼を言う、誠実に向き合って返答する、伝え方に関してフィードバックをするといった具体的なアクションを起こすことである。当たり前と言えば当たり前なんだけど、実行できる人は意外と多くはない。

特にお礼を言うというのは意外とやれていなかったりする。性格にもよるとは思うが、率直に意見を言うのにはエネルギーがいる。相手に伝わるように強めの言葉を選ぶこともあるし、勇気も必要になる。そういう行動をとってくれたことに対して、感謝を示すべきだ。

言ってくれた後でDMでも何でもいいので「あの時は言ってくれてありがとう」「そういう姿勢はすごくありがたい」「これからもよろしくお願いします」といった言葉をかけるのがよい。そこまでするのはやりすぎだと思うかもしれないが、感謝は言わないと伝わらないことも多い。伝えて相手に逆にネガティブな感情を抱かせることもあるかもしれないと不安にもなるが、自分の経験だと杞憂でしかなかった。

意見をぶつけてくれた相手は、おそらく想像以上にエネルギーと勇気を使っている。それに対して敬意を払い、実際に行動を起こすだけの話である。嫁氏から「太った」と言われた時にこそ実践したい。