エンジニアにとって良い質問をするスキルが重要な理由
ソフトウェアエンジニアのリソースは貴重で、これらを組織全体で高効率に活用できるかどうかが、強靭な開発組織か非効率な組織かの分かれ目になります。
ここで言うリソースは時間に限らず、知識や技術スキルも含みます。会計上は時間＝コストなのでそこに注目してしまいますが、知識や技術スキルを持っている人から持っていない人へ移植することによる全体リソースの増加(技術継承)にも焦点を当てるべきだと考えます。
そこで、質問という行為は、「チームメンバーの時間」というリソースを消費して、「自分が浪費したかもしれない将来の時間」を節約しつつ、「質問することで得られる、自分の知識やスキル」といったリソースを増加させる行いだと言い換えられます。
自明ではありますが、この行為を良いトレードオフにするためには、「チームメンバーの時間」の消費が小さく、「自分が浪費したかもしれない将来の時間」と「質問することで得られる、自分の知識やスキル」が大きい状態を心がけることが本質的です。
このような構造上、良い質問をすることは重要なスキルで、組織レベルで考えて改善していくべき課題だと思っています。
次の章から、私が個人的に気を付けているポイントについて紹介していきます。
(余談ですが、人によって時間の価値が違うため、極力自分と単価の近いメンバーに質問することを良しとする組織もあります。極端な話、社長に聞いても新人に聞いても解決するなら新人に聞くべきという論調です。理屈は分かりますが、過度にこれをやり過ぎると組織の風通しが悪くなったり、縦に階層が連なる組織になったりと、別の軸で弊害が生まれると思っているので、少なくとも自分の所属するチーム内では誰にでも気軽に質問できる環境がいいなぁと思っています。)
良い質問をするためのポイント
良い質問をするには、内容だけではなくタイミングも考慮する必要があります。
ここでは、「作業着手前」と「作業中、詰まった場合」で分けて考えましょう。
作業着手前の良い質問
技術調査でも、新機能開発でも、不具合の調査・修正でも、作業に取り掛かる前に質問をするのが、上記のトレードオフを最大化する重要なポイントです。
明らかに作業工程の見通しがついていて、最終的なアウトプットの形まで把握できている場合は質問する必要がありません。
ただし、少しでも方向性に不安があるとか、手探り状態の場合には、進むべき方向とおおよその段取りについて有識者と確認しておくとよいでしょう。熟練した技術者に事前相談すれば、大きく道を踏み外すことはないはずです。
僕の場合は、下記のような項目を含めて確認をすることが多いです。
■ 概要 + Context の共有
どのような目的でこのタスクが存在していて、いまこのタスクに取り組む背景は○○という情報を必ず共有します。
■ アウトプットのイメージの確認
どういう内容のアウトプットを、どれくらいのクオリティで出すのか、この段階で明確にします。成果物がコードじゃない場合は、具体的なイメージが湧くものをサンプルで用意することもあります。
(データ分析作業の場合は、最終的なグラフのイメージなど)
■ プロセスの確認
タスクの概要とアウトプットのイメージを確認出来たら、どのようにしてそこに至るのかというプロセスの確認をします。
例えば、「○○というライブラリを調査してテックリードと導入の合意を取った後、△△というデータを○○というライブラリのフォーマットに変換するラッパーを作りますが、作業イメージに相違ないですか？？」といった具合です。このときに、どういうコードを書くのかというディティールまで詰めるのは、個人的におススメしていません。質問のトレードオフが悪い方向に動くからです。(他人の時間を多く奪い、自分の成長機会を失う。)
ぜひ参考にしてみてください。
作業中に行き詰った場合の良い質問
当初想定していたプロセスでは上手くいかなかった場合や、自分のスキル不足などで作業に行き詰まることがあると思います。
行き詰まるとは、「(自分の中では)万策尽きた状態」「作業が詰まったが、この後の作業イメージが複数あり、選択をミスったときのリスクが大きい」「そもそも方向性自体を変えなければいけない」という状態だと僕は思っています。
逆に、下記のような場合には(まだ)質問するべきではないと考えます。
- Web で調べればすぐに情報を得られる
- 自分で○○分も粘っていない。(○○は組織によって適切な数値が異なる)
- 筋の良い打ち手が残っている
僕の場合は、下記のような項目で質問を整理することで、良い質問ができると考えています。
■ 概要 + Context の共有
どのような目的でこのタスクが存在していて、いまこのタスクに取り組む背景は○○という情報を必ず共有します。
■ (不具合の場合)再現手順
不具合について、本来はどうあるべきかという部分と、現時点で分かっている事実 + 再現手順を詳細に記載します。
実行環境に関する情報やログも共有します。
■ 自分が理解できていない点
自分が理解できている点と、理解できていない点を明確に切り分けて記載します。
■ 自分で試したこと・調べたこと
既に実施済みのプロセスとその結果を記載します。
付随して調べた情報ソースも共有します。
■ この後の作業予定
(万策尽きた場合は正直に申告してください。)
この後の作業予定が1つ以上ある場合は、それを詳細に記載します。回答者からみてその作業予定に問題が無ければ、「そのまま続けて作業してください」という返事だけで済みます。以上です。
誰かしらの参考になれば幸いです！！
宣伝
フリーランスのエンジニアとして活動してます。エンジニアとしてシステム開発に参画することもできますし、取引先によっては若手の育成をしながら開発したり、アドバイザーに近いポジションで入ったりもしています。最近は外部PMのような形で開発に関わることも増えてきました。
カジュアルに話す場をご用意できますので、下記のフォームよりご連絡ください。
