はじめに
初めてのIT業界、初めての開発現場となると不安でいっぱいですよね。
在宅勤務がどんどん増えている今、会ったことがない人と一緒に働くという機会も多いと思います。
不安でいっぱいの中、タスクを割り振られて「よーし！頑張るぞ！」と取り掛かり、仕様書やコードを見てみると…
なるほど。まったくわからん。
はい、ここで質問が必要ですね。質問の仕方で周りからの評価も自身の理解度も全然変わってきます。
私は未経験でIT業界に入ったのでその時の気持ちを思い出しつつ、3年ほど経過して聞かれる側になったので、 「伝わりやすい質問」 について考えてみました。
最初から完璧は求められていないので、1.～6.の手順で分けて書きましたのでまずは1.から試していただき最終的に6.までクリアできるようになると進めやすくなると思います。
質問に対する心構え
何が何だかわからないけれども、質問をして「こんなこともわからないのか」と思われたらどうしよう…と怖くなりますよね。
ただ先輩達は質問を受けた時にそんな風に思わないです。
だるいな～って感じの対応をされたら相手が悪い。上の人に即座に相談しましょう。
逆に先輩達が恐れているのは、聞くのが怖いと自分で調べて考えて調べてを繰り返した結果、気が付けば時間はどんどん経過して納期の1日前！？えっできてないけど！？という状況です。
作業に詰まってしまうなら、質問をして理解を深めて次に生かしていきましょう。
黙っていると順調なのだと認識されますので、自分が何をしているのか何がわからないのか積極的に提示していきましょう。
ただ「じゃあ何でも聞けばいいや～！」と開き直るのではなくて、質問に答えてもらうということは相手の時間をいただいてるということを念頭に置いてください。
質問をされることは迷惑でもなんでもないのですが、質問をする側が「答えてくれて当然」「先輩だから汲み取ってくれる」という意識を持つのはあまりよろしくないです。
人の時間をいただいているのだから…
すぐ答えられるような内容にしよう。
読んでいてすぐに伝わる内容にしよう。
教えてもらったらちゃんと理解しよう。
という心構えを持って、コミュニケーションを図りましょう。
1.ログは残そう！
出社していての口頭での質問、TeamsなどでのオンラインMTGツールで実際の画面を見せながらの質問。最初は言語化するのが難しい部分も多いのでその方が手っ取り早いことも多いです。
ただ、質問した側もされた側も「何を聞いたか」「何と答えたか」は大抵忘れます。
私の場合は10分くらいでもう忘れます。
たとえ自分の記憶力に自信があって絶対覚えてる！と思っていても回答した側が忘れることもあります。人間だもの。
なのでslack等で必ずログを残しましょう。箇条書きでも構わないです。
先ほど口頭（or オンラインMTG）でお話した件になります。
【質問】～
【回答】～
回答に基づき～の作業を進めます。
お時間いただきありがとうございました。
この一手間があるだけでお互いに忘れないですし、丁寧な人だなと評価も上がります。
口頭で話した内容への理解がすれ違っている場合もあるので書いておくことで、そこは違いますと返信をいただけるので美味しいことだらけです。
2.何がわからないのかわからない
大抵これ。
最初なんて何もかもがわからない。なんならカタカナばっか喋るし何言ってるんだ？となりました。
入ったばかりの頃に「ディレクトリのCドラにバッチあるからキックして～」とか言われて「は？」ってなった記憶があります。（良い先輩でした。IT初心者の素直な感想です。）
ただ先輩側に悪意がある訳ではまったくないです。テクハラではないので怯えないでください。「すいません、言葉の意味がわからないのですが…」と言ってOKです。
言っていただけることで、この言い方は良くないな～と先輩側の学びにもなるので積極的に教えてください。
「何がわからないのかが整理できなくて、一緒に考えていただけないでしょうか」
勇気を振り絞って言ってみましょう。だるいな～って感じの対応をされry
3.不明点を分解
何が何だかわからない状況は脱出できた。
詰まっているのはわかるけど、いったい自分はどこが理解できていないのか？というのが第二の壁だと思います。
まず自分の理解をメモでもなんでもいいのでわかる限り書き出してみましょう。
コードを書くタスクなら仕様書の通訳を自分なりにしてみる作業ですね。
手が止まった瞬間が不明点です。
ここまでは理解できているけどこの先がわからないんだ、という基準になります。
不明点がわかったら後はわかりやすい質問を考えていきましょう。
逆にスラスラ書けたり書いていく内に理解ができることもあるので、そうなったら「これで認識合っていますか？」と確認を取るとより安心ですね。
4.4W1H
「いつ（When）」「どこで（Where）」「だれが（Who）」「なにが（What）」「どのように（How）」を意識して質問を組み立てましょう。
- When：～処理作成時
- Where：〇行目でエラーが発生している
- Who：〇〇の変数
- What：「型が違う」と表示されている
- How：今まで行った手順や、試したこと（文字列から数値に変えてみたとか）
4W1Hの型に当てはめていくと段々と不明点・質問の解像度も上がっていきます。
ひな型として作っておいてまずは埋めていきましょう。
埋めることができない箇所は「不明点の分解」に戻ってひたすら書き出してみて手の止まる箇所を探すこと。
面倒ですし地味ですが、コツコツ重ねることで思考の習慣化にもなりますし、慣れればひな型不要でも書けます。
5.YES or NO で解答できる・解答の選択肢がある
質問される側への配慮です。
冒頭でも述べた通りに人の時間をいただいていることには変わりないので、回答がしやすい質問を意識していきましょう。
- YES or NO で解答できる
処理作成時に〇行目で「型が違います」というエラーが発生しました。
行った手順は下記です。
①コード書いた（書いたコードを貼り付ける）
②デバッグした
「型が違う」との内容なので、
赤くなっている変数〇〇の型が現在指定している文字列ではないということでしょうか？
といただくと「はい、そうです」と回答するだけです。
ただここで「エラーが発生しました」とだけ聞かれても「そうだね、何が違うの？どう解消したいの？何がしたいの？」となるので、そのやり取りをする手間が増えますよね。
- 解答の選択肢がある
こちら回答の選択肢もですが質問が複数ある場合も項番を振っていただくと大変わかりやすいかつ答えやすいです。
仕様書の下記記載内容について2点質問させてください。
「過去12か月以内に住所変更を行ったユーザーである場合は住所変更フラグを立てること」
1.
①過去12か月以内は現時点の日付から見るのでしょうか？
②過去12か月以内は最終更新日付から見るのでしょうか？
2.
住所変更の定義についてです。
①住所変更は複数回発生の場合でも、1回の変更とカウントして1回のフラグ立てすか？
②住所変更が複数回発生の場合は、2回、3回…と変更の回数に合わせてフラグを立てますか？
回答としては、「1.は①です。2.は②です。」で完結します。
もしどちらの選択肢でもない場合は「①②どちらでもなく～となります。」と回答いただけます。
質問が1個だけならslackの場合、「①②どちらかを押下ください。」と添えておくだけでスタンプ押してもらうだけでもわかりますよね。
こういった質問を投げて、本当に数字だけで答える方には出会ったことはなくなぜそうなのかも加えて解説いただけるので助かりました。
全てを文字で表現しなくても単純にエラー画面を貼り付けるなどで視覚的にパッとわかってもらう手法もあります。
ただ、ここまで理解しているんだな、ここまでは自分で考えてくれたんだなというのがわかるので習熟度を測ることもできるので大変助かります。
おわりに
質問するのって怖いですよね。
けど一歩踏み出して回答をいただけて、うまくいったら成功体験になります。
それにベテランの方でも業務知識などはわからないことがあるのでガンガン質問しています。
大丈夫かな？とこフォローするようにはしていても自分のタスクが逼迫しているとどうしても頭の隅に追いやられてしまって「あああああ！ごめんねえええええええ！！！」という気持ちになることも多いです。
そういった時にちゃんと「わからないです、教えてください！」と言っていただけるのは先輩側からすると本当に助かります。
こう伝えるとわかってくれるんだな、最初ってこういう点がわからないんだな、次に新しい子が入ったときはすぐわかるように資料を作っておこう！などとどんどん環境も良くなります。
忙しそうだしみんなひたすらキーボードカタカタカタカタしてて怖いよーとなってもエンジニアの方って知識を広めたい方が多いので、聞いたこと以上のことを教えてくれます。
繰り返しにはなりますが、なんでも聞けばいいや～ではなくてどんどん質問の質を上げて自分の知識を深める意識は持つことは忘れないでください。
また、先輩・上司は教えること・フォローすることが仕事でもありますので、自分がきちんと質問しているにも関わらず「だるいな～」って態度だったらその人が悪いので上の人に相談しましょうね。