はじめに
ここ1年位はプロジェクトリーダーという立場でメンバーと関わる機会が増えました。
その中で、人によって質問の頻度や質がバラバラであるということに気づきました。
本記事では、「職場において駆け出しエンジニアは先輩にどう質問すればよいのか」というテーマに対して
- 質問のタイミング
- 質問すべきこと
- 質問の仕方
以上3つの観点からまとめてみました。
対象読者
- 仕事でエンジニアをやっている人
- うまく質問ができている自信がない人
- 後輩からもっといい質問をして欲しい人
質問のタイミング
前提
質問ばかりしていると先輩の時間を奪ってしまうし、質問をしないと自分の仕事が進まないというジレンマを感じる人も少なくないはずです。
是非、「プロジェクト全体としてより効率的な選択をとる」ということを意識してみてください。
自分一人で調べたら1時間かかるものを、先輩に聞いて5分で解決したならばプロジェクト全体で時間を節約できたことになります。
一方、自分一人で調べたら1分かかるものを、先輩に聞いて5分で解決したならばプロジェクト全体で時間を無駄にしたことになります。1
自分一人で解決しようとすると時間のかかりそうな問題、自分ひとりで解決する目処が立たない問題などは、どんどん質問していったほうが良いということです。
では、
自分一人で解決しようとすると時間のかかりそうな問題、自分ひとりで解決する目処が立たない問題
これをどうやって判断するのでしょうか。
15分ルール
1つの目安として15分ルールがあります。
問題が起きた時は
【1】最初の15分は自分自身で解決を試みる
【2】15分後も解決していなかったら必ず人に聞く
前者を守らないと他人の時間を無駄にし、後者を守らないと自分の時間を無駄にする。
15分間かけて解決しない問題は今の自分では解決できない、あるいは、解決できる可能性はあるがプロジェクト全体として非効率になってしまう。
と考え、15分を目安に質問するようにしましょう。
15分ルールは自分と他人を含めたプロジェクト全体の時間を効率化させます。
質問すべきこと
質問の種類
質問をするとき、実は下記のような質問の種類があります。
- 技術的に難しい・知らないので教えて欲しい
- プロジェクトのルールを教えて欲しい
- 仕様に関することを教えて欲しい
15分ルール適用の可否
- 技術的に難しい・知らないので教えて欲しい
上記の場合は、15分ルールに従い、15分調べてわからない場合に質問するという方針で良いと思います。
- プロジェクトのルールを教えて欲しい
- 仕様に関することを教えて欲しい
しかし、上記のような場合は、15分ルールに従わず、もっと早いタイミングで質問して良いと思います。2
なぜなら、プロジェクトのルールや仕様に関することは、少し調べてわからなければ、そもそもドキュメントとして残されていないなどの可能性もあるからです。
また、ネットの海に答えが転がっていないため、少し調べてわからない場合は自己解決をすることが難しいからです。
数分調べてもわからない場合は、思い切って先輩に聞いてしまって良いでしょう。
質問の仕方
下記の5つを意識して質問をします。
- 目的
- 現在自分が何をしようとしているのかを簡潔に説明する
- 背景
- 目的を達するための背景情報を提示する
- 質問相手は現在の自分の状況をすべて理解しているわけではないので前提知識を提示する
- 現在の状況 (エラー内容)
- 目的と背景を踏まえて、自分の書いているソースやエラー内容について説明する
- 試したこと
- エラーに対してどのようなことを試したのかを説明する
- 結論 (回答者に期待すること)
- 回答者に何をしてほしいのかを伝える
- ヒントがほしいだけなのか、解決策を教えてほしいのかなど
質問例
目的
税込価格を計算するメソッドが作りたいです。
背景
商品の価格に関する機能を作っています。
現在、商品は「税抜価格」と「税額」のみを持っています。
新たに「税込価格」というプロパティを作る必要が出てきたため、
税込価格を計算するメソッドを作ろうと思っています。
現在の状況 (エラー内容)
下記のようなソースを書きました。
public int CalcTaxIncludedPrice(int price)
{
return price * TAX;
}
状況によって、このメソッド内でNullReferenceExceptionというエラーが発生します。
試したこと
NullReferenceExceptionについて調べてみましたが、どういう意味なのかよくわかりませんでした。
結論 (回答者に期待すること)
NullReferenceExceptionについて教えてください。
また解決策もお聞きしたいです。
これでどんなメリットがあるの？
回答する立場から見ると
- 目的がはっきりしているので質問内容がわかりやすい
- 質問されていて「結局何がしたいの？」と疑問に思うことは多々あります
- 先に目的を話してくれるとその後の話が聞きやすいです
- 背景があれば回答に幅が出る
- どんな材料が使えるのかがわかると回答もしやすいもの
- ちなみに上記の例の場合、ぬるぽをただ回避するだけでなく「「税込価格」というプロパティのゲッターに「税抜価格」と「税額」の和を返すという設定をすればいいよね」という別角度の回答ができるようになります
- 試したことがあれば回答に無駄がなくなる
- すでに試した内容をドヤ顔でアドバイスするという無駄足を踏みにくくなります
- 結論があれば回答がしやすい(当たり前)
- 困っているとだけ言われても質問される側も困ります
質問する立場から見ると
- 見当違いな回答が減る
- 目的や背景を伝えているので「今回のパターンには応用が効かない」ような回答が減ります
- 自分自身の整理ができる
- 理論立てて伝えることで自分の中でも整理ができます
- 特に複雑な問題に直面したときに頭の中が整理できます
- たまに質問しながら自己解決に至ることも
まとめ
自己流ではありますが、質問に関してまとめてみました。
各人の状況、プロジェクトの状況等々によって最適な質問は違います。
本記事は一つの参考程度に捉えていただけたら幸いです。
ちなみに本記事はQiitaで行われている「新人プログラマ応援 - みんなで新人を育てよう！」の記事です。
他にもたくさんの方が新人プログラマ応援記事を書いていますので見てみてください。
ポエム追記
質問を受ける立場の心がけについての追記。
一方、自分一人で調べたら1分かかるものを、先輩に聞いて5分で解決したならばプロジェクト全体で時間を無駄にしたことになります。
ということを本記事で書いていますが、質問を受ける立場からすると、質問された内容が「いや、そんなんググったら一発でわかるやん」と思える内容のことって往々にしてありますよね。
しかし、「自分で調べろ！」とか「xxって調べたら出てくるから調べてみ！」くらいで返答していると、良くない可能性もあるということを覚えておく必要があります。
(もちろん質問してきた相手がどのくらいのレベル感の人間なのかということも勘定する必要がありますが)質問をしたという行動に対して、質問された側のフィードバックの仕方によって、質問する側が「次も気軽に質問に行けるかどうかが変わる」からです。
質問する側が質問をしたときに「冷たくあしらわれた」というネガティブなフィードバックを受けると、次から質問することを躊躇するようになります。一方質問をしたときに「優しく教えてもらえた」というポジティブなフィードバックを受けると、次からはより質問をすることに積極的になれます。
簡単すぎる質問のために自分の作業を中断して時間を作ることを億劫に感じてしまうのは人間であれば仕方のないことですし、同じことを何度も聞かれたりすればいい気分がしないのもまた人間であれば仕方のないことです。
ただ、次も質問しやすい状況を作っておいて、質問する側の人がいつでも質問をしやすい状況を作っておくことは、結果的にプロジェクトの成功につながるかもしれませんね。