駆け出しエンジニア1日目が読むQiita

はじめに

「何がわからんのかわからん」「質問すればするほど、わからないことが増えていく」
「駆け出しエンジニアの研修担当になったけど、どうやって教えたらいいものか」

この記事は、そんな世の悩める駆け出しエンジニアと、そのサポーターの方々に向けたものです。
駆け出しエンジニア周囲のコミュニケーションを円滑化する一助となれたら幸いです。

この記事は、NE Advent Calendar 2022 3日目の記事です。

自己紹介

まさか自分がエンジニアを名乗る日がくるとは微塵も思わずに生きてきた、新卒２年目です。
１年目はカスタマーサクセス部署でユーザー対応に奮闘する日々を送っていたところ、
色々あって未経験で開発部に異動しました。エンジニア歴はやっと半年になったところです。
普段は、弊社のサービス ネクストエンジン の開発・改修を業務としています。

未経験と言ってもそのレベルは様々で、趣味でコード書いてました！という未経験もよくいますが、
私は初日に「コードってどこから読むんですか？」と質問したレベルの完全未経験でした。
今となっては、上から以外にどこがある！？と叫びたくなる上司の気持ちがよくわかります。

駆け出しとベテランの溝

研修を受ける側を「駆け出し」、研修・サポートする側を「ベテラン」と表記します。
駆け出しとベテラン間において、ティーチングコミュニケーションが上手くいかない原因は、
様々あれど大方これに集約されると思います。

　　駆け出し：わからないことがわからない
　　ベテラン：なにがわからないのかわからない

エンジニアと昨日まで非エンジニアだった者の間には大きな溝があり、
相手の思考回路を想像しながら教えることが難しくなります。
研修にしろOJTにしろ、教える側が「この駆け出しは一体なにがわからんのか」と
溝に橋をかけに来てくれることがどうしても多くなるでしょう。
ただ駆け出し側でも工夫できること、駆け出し側の意識で変わってくることも
多少なりともあると、半年やってみてわかりました。

全ては質問のしかた

駆け出し側でできる唯一かつ最大の工夫は質問のしかた、これに尽きます。
とりあえず何もわかりません！！！と全てを投げ出したくなる気持ちは誰よりもわかりますが
（最初の1,2週間くらいはそうなっちゃうのは許してあげてと、正直思うところもありますが）
少し余裕ができたらまずは質問のしかた、ベテランからすると質問のさせかたを変えてみましょう。

ご参考までに、私が意識しているのは以下の３つです。

• 質問の目的を最初に伝える
  全てを説明し終わってから、そういえばこれ聞いて何がしたかったんだろう？と聞いてみると、
  なるほどそうなるとまた話は別でね…、とスタートに戻った経験はありませんか？
  もしくは、聞きたい答えが全然返ってこない！と失礼ながら思ってしまったことはありませんか？

  ほとんどの場合、それはこちらの質問のしかたが悪いです。
  相手から如何に必要十分な回答を引き出せるかは、質問する側の手腕だと私は思っています。
  「〇〇を実装したくての質問なんですけど」「シンプルな興味で業務とは関係ないんですけど」
  など質問の先にあるゴールを予め共有すると、ベテランを迷わせてしまうことが減るでしょう。

• 前提の認識を共有する
  「いくら説明しても全然通じんなあ」「いっぱい説明してもらったけど全然わからんなあ」
  こういう場合、駆け出しの前提知識のズレに気付けていないことが多いです。
  SQL＝データベースそのもの、という大きな勘違いをしたままクエリの質問をしに行き、
  説明を重ねてもらうほど、さらに混乱していった初期の私が良い例です。

  質問者は現在の知識を使って考えを組み立て、その先端で質問が生じているはずなので、
  途中で「ん？」と思ったら、〇〇はこれで認識あってますか？と一旦擦り合せをしましょう。

• 質問に行き着くまでの思考を伝える
  よく駆け出しの質問を受けてくださる方は経験があるかもしれません。
  多分ここだろうなと思って説明し始めたら、途中で「いや、そこはわかるんですけど」と遮られる、
  もしくは説明し終わってからそこじゃないと言われる。いやじゃあ先に言わんか−い！！と。

  その通りです、先に伝えましょう。
  どこまでは理解できていて、どこからが分からないのか。
  エラーが解消できないのなら、そもそもなぜその方法を今回取ろうとしているのか。
  Googleがそう言ってるからなのか、以前類似の問題をそう解決したからなのか。

  質問単体だけを発するのではなく、質問が生まれるまでの思考を言語化して伝えることで、
  ベテランが回答のスタート地点を定められたり、どこで躓いているかを発見できたりします。
  また駆け出しにとっても、思ってもいなかった間違いを指摘してもらえる機会になります。

投げ出さない

重複する部分や、もちろん場合によっては不要な時もあると思いますが、大体この３つです。
以上を踏まえて、ベテラン側の気持ちになって以下の質問例を見てみてください。

　▼ ベテランが答えにくいであろう質問

　　これってどうしたら良いですか？（質問）

　▼ ベテランが多少は答えやすいであろう質問

　　これってどうしたら良いですか？（質問）
　　条件によってクエリを分岐させたいんですけど（質問の目的）
　　PHPの中にSQLを書きたい時は、fetch系関数の第一引数にクエリ、第二引数にparamを入れると
　　それを材料にしてDB側でクエリが実行されると記憶していて（前提の共有）
　　ただ今回は入れたいparamが複数あって、安易に引数を増やしていいものか（なぜ悩んだかの思考）

前者と後者では、回答のしやすさや精度が変わってくるのが想像できるのではないでしょうか。
場合によっては、前者と後者で回答内容がまるっと変わることもあり得るかもしれません。
コミュニケーションの基本だったり、質問者が与える情報量の問題のようにも見えますが、
「何がわからんのかわからん」状態に陥っている駆け出しほど、これができていないはずです。

わからないなりに投げ出さず、ベテランが迷わないような質問のしかたを意識する、
もしあなたが迷えるベテランなら「こう質問してくれると助かる」と駆け出しに伝えてみると
コミュニケーションがちぐはぐする時間が減るかもしれません。

まとめ

今回は教わる側の視点から、駆け出しエンジニアでもできる工夫をまとめました。
話しかける前にお時間の都合を聞くとか、先輩のリソースを消費している意識を持つとか、
有り難い環境に感謝をする、感謝を伝えるとか、当たり前のことは当たり前にしながら、
余裕が出てきたら少しずつでも意識していくと、上手く教われるようになれるかもしれません。

まだまだ駆け出しの身ですが、いつかベテラン側になる日が来たら1日目に伝えたいことでした。
ありがとうございました。