エンジニアとの1on1はどうすればよいか

エンジニアとの1on1で変えるのは、仕事の進め方に合わせた使い方

エンジニアとの1on1に、特別な型は要りません。職種によって違うのは、本人の人柄ではなく仕事の進め方です。1on1の使い方を、その進め方に合わせれば十分です。「エンジニアは話すのが苦手だから聞き役に徹する」「技術の話は分からないから雑談にとどめる」のように職種で相手を決めつけると、目の前の本人の考えや事情とずれてしまうことがあります。

ソフトウェアの開発の仕事には、たとえば次のような進め方の特徴があります。どれがどこまで当てはまるかは、チームと本人によって異なります。

KAKEAIの1万人調査は職種を尋ねていないため、エンジニアに限った数字はありません。上司との面談全体についての数字ですが、面談で上司に期待すること（5つまで選択）として最も多く選ばれたのは「意見を聞きたい」の33.6%でした。「具体的なアドバイスがほしい」は32.0%、「一緒に考えてほしい」は29.4%、「話を聞いてほしい」は20.8%です。上司の考えや関わりを求める期待のほうが、話を聞いてほしいという期待より多く選ばれているということです。

上司が技術の細部に詳しくなくても、優先順位やお客様の事情、会社の方針については、自分の意見を伝えられます。エンジニアとの1on1でも、上司が自分の考えを出してよい場面は多いと考えられます。

以下では、飲食店向けの予約アプリで、予約の変更機能の改修を進めているエンジニアの部下との1on1を例にします。

エンジニアとの1on1で話すこと：本人だけでは決められないこと

エンジニアとの1on1では、本人だけでは決められないことを話題の中心に置くことをおすすめします。仕様の判断、作る順番、ほかの部署との調整、作業時間の確保といったことです。どれも、上司が情報を伝えたり判断を引き受けたりすることで、前に進めやすくなります。

KAKEAIの1万人調査では、面談が行動につながるのが半分くらいの回か、それより少ないと答えた人に、その理由を5つまで選択で尋ねました。最も多かったのは「その時々によって違う」の26.1%で、「特にない」の23.4%が続きます。「行動するために必要な情報が揃っていない」は15.9%、「時間やコストの制約で動けない」は15.4%、「裁量や権限がなくできない」は9.4%でした。行動を妨げる理由は人によってさまざまで、その中には、情報や時間、権限が足りないという理由も含まれています。こうした理由には、上司の側から手を打てるものもあると考えられます。

仕様や作る順番の判断を待っているとき

仕様が決まらずに作業が止まっているときは、誰の判断を待っているのかを尋ね、上司が引き受けられる部分を引き受けます。作る順番に迷っているときは、上司が理由と一緒に自分の考えを伝えたうえで本人の意見も尋ねると、判断の材料がそろいます。

ほかの部署からの要望が増えたとき

ほかの部署からの要望が途中で増えたときは、入れるかどうかの判断と、相手の部署との話し合いを上司が引き受けます。判断の材料は、本人と一緒に整理します。

集中して作業する時間が足りないとき

見積もった日数が変わりそうなとき

作ってみて初めて分かることがある仕事では、見積もった日数が途中で変わることがあります。変わったことを責めるのではなく、関係する部署への伝え方を一緒に考えましょう。

部下の側から、古いプログラムの書き直しのように、すぐには目に見えない仕事に時間がほしいと相談されることもあります。そのときは、何がよくなるのかを一緒に言葉にしておくと、ほかの部署にも説明しやすくなります。

上司が技術に詳しいときと、詳しくないときの関わり方

エンジニアとの1on1での関わり方は、上司自身が技術にどこまで詳しいかによって変わります。どちらの場合も、相談の中身と、本人がその回に上司に期待することを知る前に、関わり方を1つに決めてしまわないことが大事です。

上司が技術に詳しくないとき

技術に詳しくない上司は、分からないことを分からないと伝えてかまいません。そのうえで、技術の答えではなく、優先順位の判断やほかの部署との調整、情報の共有を引き受けます。避けたいのは、分からないからといってうなずくだけで終えることと、分かったつもりで技術の進め方に指示を出すことの両方です。

上司が技術に詳しいとき

技術に詳しい上司は、相談を受けると、すぐに自分の解き方を伝えたくなるかもしれません。意見を求められたときは、本人にも考えがあることが多いので、まずそれを尋ね、そのあとで自分の意見を理由と一緒に具体的に伝えます。一方で、本人に考えてもらおうとして、求められた意見を出さないのも避けたいところです。

1on1を、技術に詳しい別の人に任せる、という考え方について

技術に詳しくない上司に代わって、テックリードや技術に詳しい先輩が1on1を行うほうがよい、という助言があります。KAKEAIは、直属の上司ではない人に1on1を任せることをおすすめしません。1on1は、その部下の仕事を決められる直属の上司が行うのがよいからです。ただし、上司であっても、部下の仕事を見てもいないなら、上司が行う意味はありません。コードを読めなくても、本人が何を作り、どこで止まっているのかは、上司が自分の目で見ておく必要があります。技術の相談は、テックリードとの場を別に設けてかまいません。

エンジニアとの1on1の日時と、始め方・終わり方

1on1の日時は、集中して作業している時間を途中で分けないように、本人と相談して決めます。長い作業の途中に予定が入ると、1on1の前後も作業に戻りにくくなることがあります。

1on1の始めに、その日に話したいことと上司に期待することを尋ねる方法もあります。

朝会やタスク管理の道具で進み具合を共有しているチームでは、1on1で同じ報告を繰り返す必要はありません。ただ、仕事の話そのものを1on1から外す必要もありません。KAKEAIは、300万回以上の1on1を支援してきた経験と1万人調査の結果から、1on1は仕事を前に進める時間として正面から使ってよいと考えています。報告の場とは別に、判断が要ることや迷っていることを話す時間として使えます。

この先の仕事や役割の話では、本人にも考えがあることが多いものです。まず本人の考えを尋ね、そのうえで上司の意見を具体的に伝えるとよいでしょう。会社によっては、技術の専門性を深める道と、チームをまとめる役割に進む道が分かれていることもあります。どちらかを上司が先に勧めるより、本人が何に取り組みたいかを聞いてから意見を言うほうが、本人の考えに沿った話になりやすいでしょう。

1on1の終わりに、上司が引き受けたことと、本人が次に取り組むことを二人で言葉にしておくと、次の回に話を続けやすくなります。

エンジニアとの1on1がうまくいっているかを、どう振り返るか

エンジニアとの1on1は、話が弾んだかどうかではなく、1on1のあとに仕事が前に進んだかどうかで振り返ります。上司の側から、次の回に向けてできることは次の通りです。

• 上司が引き受けたことが次の回までに進んでいれば、次は、本人だけでは決められないことがほかに残っていないかを、1on1の始めに尋ねてみてください。
• 次に取り組むことが部下自身の言葉になって1on1を終えられたら、次の回は、その進み具合から話し始めます。
• 意見を求められて、自分の考えを言う前に相手の考えを尋ねられたら、次は、そのうえで自分の意見を理由と一緒に具体的に伝えるところまで進めます。
• 1on1の日時が集中して作業する時間を分けてしまっていると感じたら、次の回の日時を本人と相談して決め直します。

KAKEAIの1万人調査では、上司との面談が毎回またはほぼ毎回その後の行動につながっている人の61.3%が、「面談が成果につながっている」と感じていました。ほとんど、または全く行動につながっていない人では7.0%です。面談が行動につながっている人ほど、面談の成果を実感しているということです。エンジニアとの1on1でも、上司が引き受けたことと本人が次に取り組むことが次の回までに動いているかが、振り返りの手がかりになります。