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

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

主語を個人にする

組織において、主語を"集団"にしだすとよくないと思っていて、その話を雑に書いておきたい。

たとえば納得しにくい決定事項があった時に、「これってどういう経緯で決まった話ですか？」と聞いてみると、「法務側の要請で...」みたいな話になったりすることがある。

似たような話として、「営業チームの意見として」とか「経営陣からの意向で」とかも同じ。こういう"集団"が何かを言っているみたいな表現が出てきたら注意した方がいい。"チーム"も"経営陣"も"会社"も、それ自体が意見を言ったりしない。意見を言うのはいつでも個人なのだ。それを明確にしないと、バイアスにかかってしまったり遠回りしてしまったりして、物事をよい方向に進めにくくなる。

主語が"集団"になると、とたんに個々人ではコントロールしにくいものだと勘違いしてしまう。そういうちょっとしたストレスが積み重なって、「あのチームは〜」とかなんだか他人事のような物言いが始まる。自分はこういう状態が嫌いなのだ。

"誰"の意見かを聞いてみると、実はチーム全体の総意ではなく1人の強い意見かもしれない。「会社の方針として」より「CEOの方針として」、「開発チームの強い要望で」より「エンジニアのAさんとBさんの強い要望で」のように、主語を個人にしてコミュニケーションを取った方が色々やりやすい気がする。

全宇宙人類生けとし生ける者みな全て主語を個人にしていこうな。

『問いかけの作法』がとてもよかった

fukabori.fm で話されていた『問いかけの作法』を読んだ。自分にとってはかなりよかったので、初めての感想文的なものを雑に書いておきたい。

https://amzn.to/40PBaXg

とにかくよかった。これまで自分もたくさんの会議や1on1、面談などを行い都度反省して工夫してきたが、それらの工夫がほぼ全て"体系化"されてまとめられていた。自分がやってきた/やっていることが6割くらい、残り4割は新しい発見として楽しく読めた。ハンターハンターで言うと、念の六性図くらい見事に体系化されていると感じた。

たとえば質問を投げかけた後に意見が出なそうだったらいくつか具体例を出してあげるフォローアップなども、『列挙法』という名づけをして解説してくれている。カイゼン・ジャーニーの中で紹介されている、意見を5段階で示すファイブフィンガーも、この本の中の『パラフレイズ』という手法と捉えられる。

やっていることに名づけがされると頭の中で整理されて活かしやすい。本に書いてあるので詳しい内容はここでは書かないが、『とらわれ』と『こだわり』、『フカボリ』と『ユサブリ』といった名づけでさまざまなケースをうまく抽象化して整理してくれている。

全体の構成もよいが、抽象と具体のバランスがとてもよい。fukabori.fmの中でも語られていたが、現場で実践しやすい形になっている。特に3章4章は"今"何かしらに課題を感じている人がすぐに使えるテクニックが満載である。

想像しやすい課題としては、MTG中に意見をうまく引き出せないといったものがありそうだが、この本のテーマである"問いかけ"は、MTG以外のさまざまな場で使えて応用が効くと思う。

例えば自分の場合だと以下のケースで色々と役立ちそうだなと感じた。

• メンバーとの1on1での課題やキャリア指向のヒアリング
• 他チームやマネージャー、CXOとの期待合わせ
• 採用面談における対話、採用面接における見極め
• 組織課題を抽出するグループワーク

何かをリードしたりファシリテートしたりするような立場ではなくても、こういう話を頭に入れておくと視野が広がるのでオススメである。

ガッと書いてきたが、褒めすぎたかもしれない。たぶん人によってはこんなに刺さらない気もする。テクニックに寄りすぎていると言う人もいるだろうし、『レトリック』の解説部分では気持ち悪さを感じる人もいるかもしれない。まあこういうのは全てを取り入れなければならないということではないので、よしなに取捨選択すればよいと思う。

自分がターゲットど真ん中だっただけかもしれないが、こんなに体系化してまとめられる安斎勇樹さんは本当にすごいと思ったし、それまでにどれだけの実践と探求の研鑽を積んできたのかを想像すると尊敬してしまうのだった。ハンターハンターで言うと、ピトーと闘うゴンのもとに駆けつけたときのキルアの心情に近いかもしれない。

いつか実際に話して"問いかけ"られてみたいものである。

あわせて読むとよさそう↓

note.com

議論を収束させるTips

何かを決めるゴールを設定した会議において難しいのは、議論を収束させていくフェーズである。

議論の抽象度の高さによって難易度は変わるが、収束させるにあたってここは抑えておくとよいみたいなTipsはあると思うので書き出してみる。

• 決めることがゴールという認識を合わせる
  • そもそも決める場だという認識が揃っていないと収束させるのが難しい。会議のフォーマットに目的やゴールを明記しておくとよい
• 最終的な決め方を決める
  • 最終決定者、時間、多数決などなんでもいいが、最後にどう決めるかを決めるのが大事。できれば議論が始まる前にやっておくと、議論中もそれを意識して進められるのでやりやすい
• 決めるための材料の認識を合わせる
  • 判断軸とも言える。議論が何かうまくいかない時にはだいたいこのへんの認識が揃っていない。言葉に対する認識が揃っていないこともあるので齟齬をなくしておくの大事
• 決めるための材料を今揃えられるかを確認する
  • 決められる材料が揃ってないのに話してこんでしまうことがある。これはよくない。そもそも決められる人がここにいるのかなど、今決められるんだっけと立ち止まってみた方がよい
• 同じものを見ながら話す
  • 議論している内容をホワイトボードやdocsなどに書きながら、参加者の目線を揃えながら話すのが大事。論点をリアルタイムで整理するのが得意な人がいれば役割としてお願いするのがよい
• タイムマネジメントをする
  • 決めるように時間配分を考え、決められるように進めていく必要がある。時間内に決まらないのであれば、途中で今回どこまで話して次のアクションをどうするか話すように切り替える方がよい

---

ざっと書いてみたが、何より大事なのはこれらを想定して適切な人と時間をおさえて事前に準備をしておくことだ。収束できるかどうかは議論が始まる前に決まっていると言ってもいい。