質問しやすい職場は、どうすればつくれるのか
エンジニアの育成に関わっていると、質問の仕方にも、その答え方にも、人によってかなり違いがあると感じます。
分からないことがあると、すぐに周囲へ聞く人。自分で調べすぎて、何時間も悩んでしまう人。質問されたら丁寧に説明する人もいれば、忙しくてなかなか手を止められない人もいます。
どれが正しく、どれが間違っていると簡単に決められる話ではありません。
ただ、私がチームづくりを考えるうえで気にしていることがあります。
それは、誰かの親切や責任感だけで、チームの仕事が成り立つ状態にしないことです。
技術力の高い人に質問が集中する。面倒見のよい人が新人のフォローを引き受ける。困っている人を放っておけない人ほど、自分の作業時間が削られていく。
こうしたことは、開発現場では珍しくありません。
一方で、質問する側が少しずつ成長し、今度は別の誰かを助けるようになれば、チーム全体で対応できる仕事が増えていきます。
同じように助け合っていても、その後の結果はずいぶん違います。
この違いは、どこから生まれるのでしょうか。
「分からないので教えてください」の先にあるもの
新人や経験の浅いエンジニアが、先輩に質問するのは当然のことです。
初めて扱うフレームワークや複雑な既存システムについて、何でも一人で解決できるわけではありません。
むしろ、分からないまま作業を進め、大きな手戻りを発生させるくらいなら、早めに相談してもらった方がよい場合もあります。
ただし、質問する側にも少しずつ覚えてほしいことがあります。
例えば、プログラムが期待どおりに動かなかったとします。
「動かないので見てください」と依頼するのと、「この条件で実行するとエラーになります。ログと呼び出し元を確認しましたが、原因が分かりません」と相談するのでは、受け取る側の負担が違います。
最初から詳しい調査ができなくても構いません。
何が起きているのか。何を試したのか。どこから先が分からないのか。
その説明があるだけでも、先輩は問題を把握しやすくなります。
そして、質問する側も、自分の考えを整理する練習になります。
私が大切だと思うのは、質問したことを申し訳なく思う必要はない一方で、相手が自分のために時間を使ってくれていることは意識してほしいという点です。
教えてもらった内容を理解する。次に同じ問題が起きたら、自分でも調べてみる。解決方法を残して、ほかの人が同じことで困らないようにする。
質問をきっかけに、そこまでできるようになれば十分な成長です。
教える側も、すべてを解決してあげる必要はない
では、質問を受ける先輩はどうすればよいのでしょうか。
経験豊富なエンジニアであれば、後輩が何時間も悩んでいる不具合を、数分で解決できることがあります。
その場でコードを書き換えてしまう方が早いかもしれません。
ただ、毎回それを繰り返していると、後輩は問題が起きるたびに先輩を頼るようになります。
先輩の仕事は増えるのに、後輩が一人で対応できる仕事はなかなか増えません。
そこで、少し時間に余裕があるときは、答えを伝える前に調査の進め方を説明してみます。
「このログから、どこまで分かると思いますか」
「最後に正常動作したときと、何が違いますか」
「この処理が呼ばれる条件を確認してみましょう」
最初は時間がかかります。
自分で修正した方が早いと感じることもあるでしょう。
それでも、後輩が原因を調べる方法を身につければ、次から一人で解決できる問題が増えていきます。
もちろん、納期直前や重大な障害への対応中に、毎回教育の時間を取る必要はありません。
緊急時は経験者が対応し、落ち着いてから原因や修正内容を説明する方法もあります。
大切なのは、何でも自分でやってしまうことでも、何があっても本人に考えさせることでもなく、状況に応じて判断することだと思います。
自分の成果から、チームの成果へ目が向くようになる
私は、エンジニアとして経験を重ねる中で、仕事に対する関心が変わっていくことにも意味があると思っています。
若い頃は、まず自分の担当機能を完成させることで精一杯かもしれません。
難しい不具合を解決したい。技術力を高めたい。周囲から評価されたい。
そうした気持ちは、ごく自然なものです。
しかし、開発の仕事は一人では完結しません。
自分が書いたコードを、別の人が修正することがあります。自分が設計したAPIを、ほかの担当者が利用します。自分が離れたプロジェクトを、次のメンバーが引き継ぐこともあります。
そこで少しずつ、仕事の進め方が変わっていきます。
例えば、コードレビューで単に修正を指示するのではなく、なぜ問題になるのかまで説明する。
障害調査で分かったことを、自分の頭の中だけに残さず、チームでも参照できるようにする。
変更の影響を受けそうな担当者には、問題が起きる前に情報を共有する。
どれも特別に立派な行為ではありません。
開発現場で、周囲が仕事を進めやすくなるようにする、ごく実務的な行動です。
こうしたことが自然にできるエンジニアは、難しい仕事を任されるようになったときにも、周囲との連携を取りやすいのではないでしょうか。
ギバーとテイカーという考え方
組織心理学者アダム・グラントの著書『GIVE & TAKE』には、他者への貢献を重視する「ギバー」と、自分が受け取る利益を優先する「テイカー」という考え方が登場します。
ただ、私は仕事をする人を、この二つのどちらかに分類したいわけではありません。
自分の給料を増やしたい、よい評価を受けたい、希望する仕事に就きたいと考えることは、悪いことではないからです。
エンジニアであれば、新しい技術を身につけたい、もっと難しい開発を経験したいという気持ちもあるでしょう。
問題になるのは、自分が成果を得るために、周囲の負担を当然のものとして扱うような場合です。
例えば、毎回同僚に調査を依頼し、自分では調べようとしない。それなのに、問題が解決すると自分一人の成果として報告する。
こうしたことが続けば、周囲との信頼関係は損なわれます。
反対に、教えてもらったことを仕事に生かし、自分も誰かを助けられるようになる人であれば、周囲も協力しやすくなるでしょう。
大事なのは、最初から人に何かを与えられるかどうかではありません。
新人の頃は、教えてもらうことの方が多くて当然です。
その経験を自分の成長につなげ、できることが増えたら周囲にも還元していく。
私は、そうした働き方ができればよいと思っています。
面倒見のよい人を、善意だけで働かせない
ここからは、管理職として考えなければならないことです。
若手の質問対応や育成を積極的に引き受ける人は、チームにとってありがたい存在です。
ただ、その人が本来担当している開発業務と、育成のために使っている時間の両方を見なければ、適切な評価はできません。
例えば、二人のエンジニアがいたとします。
一人は自分の担当機能を予定どおり完成させました。
もう一人は、自分の担当作業に加えて新人の相談にも応じていたため、作業の進捗が少し遅れました。
この結果だけを見て、前者の方が優秀だと判断してよいのでしょうか。
もちろん、育成を担当していたことだけで遅延を正当化できるわけではありません。担当業務の進め方や、周囲への相談が適切だったかも確認する必要があります。
ただ、後者が新人の成長を支え、結果としてチーム全体の生産性を高めていた可能性もあります。
管理職は、そうした貢献も把握する必要があります。
また、育成を特定の人の善意に任せきりにするのも問題です。
相談対応に使う時間を業務として確保する。質問が一人に集中しているなら担当を分散する。繰り返し発生する質問は、手順書や勉強会で解消できないか考える。
育成する人が疲弊してしまえば、せっかくの助け合いも長続きしません。
人を助けることが、本人の仕事やキャリアにとって不利にならないようにする。
これは、組織を運営する側が考えるべき課題だと思います。
採用面接でも、他者との関わり方を見ている
私はエンジニアの採用面接でも、技術的な経験に加えて、周囲とどのように仕事を進めてきたかを確認するようにしています。
例えば、過去に難しい問題を解決した経験を聞いたときです。
自分で何を調べ、どのように判断したのかは、もちろん重要です。
それに加えて、分からない部分を誰に相談したのか、周囲からどのような協力を得たのか、その経験を次の仕事にどう生かしたのかも聞いてみます。
一人で解決した経験が優れていて、誰かに助けてもらった経験が劣っているわけではありません。
開発現場では、経験者でも分からないことがあります。
大切なのは、必要なときに協力を求められること、そして協力してもらった経験を自分の成長につなげられることです。
リーダー経験のある人なら、メンバーが困っているときにどのように対応したのかも気になります。
自分で解決してしまったのか。相手に調査を任せたのか。なぜその方法を選んだのか。
こうした話から、技術力だけでは分からない、その人の仕事の進め方が見えてくることがあります。
長く一緒に働きたいと思える人とは
仕事をしていれば、自分のことで精一杯になる時期もあります。
忙しくて、後輩からの質問に十分な時間を取れない日もあるでしょう。
いつでも親切で、誰からの相談にも快く応じられる人だけを求めたいわけではありません。
私自身、管理職としては、無理な依頼を断ったり、仕事の優先順位を調整したりすることも必要だと考えています。
そのうえで、長く一緒に働く人には、自分の成長と周囲の成長を、どちらも大切にしてほしいと思っています。
最初は教えてもらう側でも構いません。
経験を積んだら、今度は誰かの相談に乗れるようになる。さらに経験を積んだら、同じ問題が繰り返されないよう、仕事の進め方を改善していく。
技術を身につけることも大切ですが、その技術や経験を周囲とどう共有するかによって、チームに与える影響は変わります。
そして、そうした行動がきちんと評価される職場をつくることは、私たち管理職の仕事でもあります。
自分の仕事で成果を出すことと、周囲が成果を出せるようにすること。その両方を大切にできる組織にしていきたいと思っています。
辰巳電子工業 SS事業部について
辰巳電子工業は、プリントシール機やアミューズメント機器などの自社製品開発を手がけてきた会社です。
SS事業部では、ゲーム開発や一般IT分野におけるエンジニアの活躍を支援しており、採用・育成にも取り組んでいます。
私は事業責任者として、エンジニアの採用や育成、組織運営に携わっています。
技術力を伸ばしたい方はもちろん、将来的に後輩の育成やチームづくりにも関わっていきたい方と、一緒に仕事ができればうれしく思います。
SS事業部の事業内容や働き方については、Webサイトでも紹介しています。
