マネジメント、採用、育成、意思決定……エンジニアリング組織を率いるCTOやVPoEの方々は、日頃から大小さまざまな課題に向き合っています。このコーナーでは、エンジニアリング組織のお悩みを読者の皆さまから募集。UUUM株式会社の元CTOで、現在Repro株式会社の執行役員CTOを務める尾藤正人さんがアドバイスします。

第7回のお悩みは関係構築のために時間を割いてでも1on1を実施すべきかです。

お悩み:1on1って本当にやるべき?

中途入社でエンジニアチームのリーダーとしてジョインしました。マネジメント経験はあるもののメンバーとしての実績がないところにリーダーとして入るのは初めてで、まずは関係構築のために1on1を取り入れようと考えています。ただ、人数も多く工数がかかりすぎるので実施にためらいもあります。時間を割いてでも1on1を実施する意味はあるのでしょうか?

尾藤さんからの回答

1on1の重要性と3つの目的

1on1とは、上司と部下がその名の通り1対1で対話をすることをいいます。評価面談などとは異なり、日頃の困りごとをヒアリングしたり今後のキャリアについて一緒に考えたりする場と位置づけられています。

エンジニアに限らず、1on1を取り入れている組織は多いかと思いますが、誰でも簡単かつ効果的にできるかというとそう単純な話ではありません。懸念されているとおり、忙しいマネージャーの時間を割いてまで実施するほどの効果が見られず、継続を諦める方もいらっしゃいます。

ただ、私はマネジメントにおいて1on1は非常に重要で、コストを払ってでも実施する価値があると考えています。

今回は、それらを踏まえて1on1の目的を「信頼関係の構築」「経験学習」「課題の早期発見」の3つに大別し、その重要性やメリットについてもお伝えしたいと思います。

信頼関係は接する時間に比例する

1on1を実施するひとつめの目的は、相談内容にもあったとおり「信頼関係の構築」です。

当然ですが、人は接している時間が長ければ長いほど親しくなれます。たとえば、会ったことがない人に対しては批判的もしくは攻撃的な言葉を容易に投げることができても身内にはやりづらいですよね。1on1はチームメンバーと接する時間を長くする機会でもあります。

1on1で大事なのは、基本的には相手の話を聞く、そして相手に話をさせることです。中には1on1で自分の話をし続けたり、ティーチングのように教えたりする人もいますが、私はそれは悪手だと思います。

なぜそのように聞く・話させるを重視するかというと、なによりもまず自分の話を聞いてくれない人に対しては信頼をおけないからです。1on1を実施する上で心理的な距離が離れないよう、相手に「きちんと話を聞いてくれる人だ」と認識されることが重要になってきます。

もちろんそれだけで信頼を獲得することはできません。ただ、発言を否定したり批判したりばかりする人に対して信頼をおけるかというと、普通はおけないと思います。そのため相手の話に耳を傾けることが大切になってきます。

情報を整理して伝えるための経験学習

つぎは「経験学習」です。これについて話すために、はじめにプログラミングのデバッグ手法の「ラバーダック・デバッグ」を簡単に説明します。

このデバッグ手法では、ラバーダック(あひるの人形)に向かってプログラムの問題箇所を説明することによりデバッグをおこないます。これは前提条件も共有していない・プログラミングについて知識もないラバーダックを相手に、問題を理解できるように説明する過程で解決策がひらめき、バグを修正することができるというものです。

似た事象として、誰かに相談をしている途中で自己解決するというのは皆さんも覚えがあるかもしれません。第三者に自分の状況を伝えるには、自分が持っている情報を整理する作業が強制的に発生します。整理をすることで今まで不明瞭だった物事が見えるようになり、それが問題解決につながります。

1on1も実はそれらに近い部分があります。何か問題が起きているときに、それを人に相談しようと思うと、自分がどういう状況に置かれていて、何に困っているかを整理して説明する必要がありますよね。話し相手は情報を持っていないので、正しく伝えるためには自分の情報を整理して相手に説明するプロセスが非常に大事になってきます。

つまり1on1を通して、問題を乗り越えたり課題を解決したりといった経験をきちんと噛み砕いて、自分のスキルに昇華させる「経験学習」をできるようになることが目的です。情報を整理し、誰かに伝えることは手段としてかなり有効だからです。

実は何かを経験し、その経験で得た結果を自分のスキルとして昇華させるのは意外と難度が高く、ほとんどの人はひとりではできません。だから1on1を思考プロセスを鍛える場として使ってもらい、自分が今までやってきたことを振り返り、整理して話してもらって、フィードバックを返すようにしています。そうすると漠然としていたものが新たなスキルとして身について成長につながると考えています。

1on1は単なるコミュニケーション機会ではなく、社員の成長を促す意味でも重要なのです。

火種が小さいうちに発見し解決する

最後は「課題の早期発見」です。メンバーは普通、問題が大きくならないと上司に相談にきません。火種が小さいうちは「わざわざ相談するほどの内容でもないし…」と捉えるからです。特に今のようにリモートワークという環境下では、気軽に会話や雑談ができないため、話したいと思ったら能動的に場をセッティングする必要があり一層ハードルが高くなっています。

組織課題は人間関係に起因することが多く、ほとんどがそうだと言ってもいいくらいです。しかしそういった内容を自分からミーティングを設定して話してくれる人はほとんどいません。それが定期的に1on1を実施しておくと、なにか問題が起こりそうな兆しがあってもまだ火種が小さいうちにメンバーから話を聞くことができます。わざわざミーティングを設定するほどの内容ではないけれども、なんとなく気になっていることや嫌なこと、悩んでることなどをヒアリングできるからです。

もし1on1のような場がないと、すでに火種が大きくなってしまったころにようやく話す場を作って事態を把握することになります。

早めに情報を集めておけば、早めに対策を打てます。火種は大きくなればなるほど取り返しがつかなくなり、小さければ小さいほど容易に解決することができます。遺恨も残りませんし、課題の早期発見はいいことしかありません。

以上のことから私はマネジメントにおいて、1on1を非常に重要視しています。

エンジニア組織のリーダーの在り方

私のマネジメントのスタイルは、どちらかといえば、相手に寄り添って能力を引き出したり、導いたりする「サーバントリーダーシップ」タイプです。リーダーの役割は、メンバーが能力を最大限に発揮でき、成果を出せる環境を作ってあげることだと捉えているからです。

というのもエンジニア組織は、旧来の日本のトップダウンで指示をして、部下に動いてもらうマネジメントスタイルは向いていないと感じているからです。

なぜエンジニアが他の職種に比べてトップダウンのマネジメントが合わないかというと、やはり専門性の高い職種だからです。専門性が高い職種はいわゆるジョブ型雇用に近く、会社に対する依存度が低くなります。つまりエンジニア自身個人のスキルで職を得ている意識が強く、それだけ離職リスクが高いということです。

極端な話かもしれませんが、専門性が低い職種であれば会社に対する依存度が上がり、多少本人の意に沿わない業務を任せてもすぐに離職することはないでしょう。しかし、エンジニア組織でトップダウンの上から押さえつけるようなマネジメントをすると、優秀なエンジニアから辞めていきます。

そもそも私自身、トップダウンのマネジメントをされるのはあまり好きではありませんから(笑)、エンジニアをマネジメントする際はサーバントリーダーシップのスタイルをとるようにしています。

私の中で決め事としているのが、普段の会話の中で上下関係を意識させる上司・部下という単語を使わないことです。私にとってチームメンバーは仲間であり対等な存在です。もちろん説明の文脈上、使わざるを得ないシーンもあります。また、CTOという役職上、各メンバーの評価や給与を決める立場であり、その権限を持っているため本当の意味では対等ではありません。

しかし現場のエンジニアの中には、プログラミングスキルが非常に高いメンバーもいます。自分より優れた能力を持っている人に対して、上から目線で指図をするのはおこがましい行為ではないでしょうか。

1on1は人間関係の構築をスムーズにするひとつの手段です。まずはエンジニア組織のリーダーとして自分がどう在りたいかを考えることも大切です。

コストを払ってでもやる価値はある

「1on1をどのくらいの頻度で実施するとよいか」という質問をいただくことがあります。

早めに火種を摘むという意味ではできれば週次でやりたいところですが、冒頭でも少し触れたとおり、1on1の実施そして継続は簡単ではありません。私自身も今でも大変だと思っていますし、組織規模が大きいと人数も多くなるため現実的には人数を絞るなどの対策は必要でしょう。

ただ、新しい組織に入ったら必ず1回は全員と話すことを心がけています。今のような基本リモートワークの環境下では、転職先では直接会ったことも話したこともない人がほとんどという状況ですが、そういった中でチームメンバーが外から来たマネージャーに対して信頼を置けるかというと絶対に無理です。メンバーからしたら「外から来た人がいきなりCTOに就任したぞ」という印象ですよね。

CTOだったら1on1実施の相手はリーダークラスになるかと思いますが、時間は30分でもいいですし早く終わったら切り上げてもいいのでできるだけ負担がかかりすぎないやり方で実現してみてください。

私はメンバーからの信頼を得るためには、それなりの価値を払ってもマネジメントの一環として1on1をやるべきだと思っていいます。何もないところから信頼関係を築いていくためには、それなりのコストは払わなければいけません。

それは人が物事の決定や判断をおこなうのは最終的には理屈ではなく、感情に依るところが大きいと言われているからです。感情のケアは疎かにできません。それどころかむしろ最重要項目だと思っています。もちろん覚悟を決めて取り組めば必ず結果はついてきます。新しい環境での活躍を応援しています。

エンジニアの採用ならpaiza転職

尾藤さんに聞きたいお悩みを募集しています!

「TTJお悩み相談室」では、エンジニアリング組織のさまざまなお悩みについて、尾藤正人さんに相談したい内容を募集中です。

こちらのフォームより必要事項をご記入ください。

皆さまからのご質問をお待ちしております!


Share