2023/04/08 このエントリーをはてなブックマークに追加 はてなブックマーク - ソフトウェア開発チームにおける質問と回答のクオリティの上げ方(についての模索)

ソフトウェア開発チームにおける質問と回答のクオリティの上げ方(についての模索)

カテゴリ:

テキトウにつけたら、それっぽいタイトルになってしまいましたが、大した話ではないです。

今回は、質問と回答について。
割と当たり前の話ばかりで、簡単な話ではあるのですが。


色々な企業の開発においてはチームで普段から発生しうる大事なコミュニケーションの部分かなと思い、
なんか自分の中の整理を書いてみる。


前提、仕事において、
チーム内外で気軽に質問し合う&質問し合える文化があるのはとても良いと思うし、自分も推し進めたいと言うスタンス。

しかし、人類の質問の仕方や質問のクオリティにはバラつきがある。
特に、質問のクオリティが上がらないとどうなるか。
回答者に比重が高くなることになるのではないか。


結局「質問する人←→回答する人」「生徒←→先生」という関係性が継続的に出来てしまい、
いつまで経っても回答者依存、先生依存となる。


これは世に言う属人化って問題かもしれない。


厳密には詳しい人に頻繁に質問することで、知識は徐々にシフトしていくと思う。
しかし、質問のクオリティを上げていかないと知識のシフトを鈍化させるのではないかなと考えている。

ただ単に困ったことを質問しに行くだけでなく、
欲を言えば、質問のクオリティを上げたい。


クオリティが上がるとどうなるか。
知識のシフトを鈍化しにくくなり、本来したい会話ができるはず。


その方がより良いコミュニケーションになったり、
建設的(本当に知りたいところの話を出来るよう)な会話になったりすると思う。

気持ちよくコミュニケーション出来る人は意識的か無意識的かは分からないが
質問のクオリティが高い状態、もしくはクオリティをリアルタイムですぐに上げてくれると思っている。




実際どうすれば良いか。考えるために 質問する側としてこうありたいな
質問される側としてこうだったら嬉しいなと思うこと
を書いてみる。



仮に何か開発で躓いたというケースで考えてみる。
自分の場合、考えてみると

  • 発生事象の整理
  • コードの確認
  • 考えうる原因を複数考えてつぶす

というアプローチをとる。
そのアプローチ途中で分からないことがあれば相談に行くかもしれない。
順番に考えてみる。


例えばエラーを読む。

  • 発生条件
  • エラーの発生箇所
  • 発生タイミング

を質問者は理解しているのが望ましい。

つまり

  • 何をしていて(例：どのチケットの開発をやっていて)
  • 何のタイミングで(例：アプリを実行したら)
  • どこでどういうエラーが発生したか（例：hogehogeってAPIでxxxExceptionのエラー）

が相手に言えれば良い



この整理を回答者に求め(すぎ)るのは自分は質問者の怠慢だと思ってしまう。
充分に整理しきらないとダメということはないけど、その努力をする姿勢を常に持ちたい。
せめて上記ぐらいの情報は質問者であれば提示したいし、回答者側であれば提示してほしい。



しかし、人類、エラーを読むこと自体も個人差があることらしい。
出来ればみんな読めてほしいが、、、

  • 発生した瞬間見落としていたり
  • 他の部分に気が向いていたり
  • 読んだけど分からんかっただったり

なのかなと想像している。まぁそういうことは自分もある。
他人の場合どうなのだろうというと分からないので困る。


問題が起きた瞬間に周辺コードを1〜2分ぐらいで読む。

人類、コードを読みこむということは、結構個人差の出ることらしい。なので、なんで読まないの？とは全ての人に求めにくい。
ただ自分はある程度暇な時とかも読んだりする。

そういう個人差はあるにせよ、質問者が該当コード周辺の理解があるかどうかはどうしてもケースバイケースになると思う。

なので

  • 日頃から満遍なく読んでおきつつ
  • 問題が起きた瞬間に数分で読む

という二段構えになるかなと思う


エラーを見てコードを読めばある程度原因となりうるものは絞り込める

  • 設定が間違っていた
  • さっき書いたコードが間違っていた
  • 直近のコミットによってテストが壊れていた
    など。

探る時に、ステップ1〜ステップ3のどこでハマるかは分からないので、困った時点で質問するとかが良いかなと思う。


困ってても粘って調査し出して深みにハマることもあるので、タイミングは結構あきらめというか見極めが必要。
自分は結構粘って調べがちだけど、どうにもならん！ってなるべくはやめに質問 or 相談しに行くようにしている。
質問しても解決しないことはあるけど「解決しないことが分かった」という収穫になる。


質問する時にステップ1〜3のどこにいて、何で困っているのか、何が知りたいかを話す。

ステップ1の段階で質問する場合は

  • 何をしていて
  • 何のタイミングで
  • どこでどういうエラーが発生したか

を話せば良いので割とシンプルな気がする。


自戒を込めて。

やりがちなのは、ステップ1やステップ2を端折ってステップ3の話を始めたりすること。これは避けたい。

何故かと言うと、ステップ1やステップ2で得た情報は推測と事実が混ざっていたり、事実だと思っていたものが正しくなかったりするから。

かなり確信を持っている場合なら省略しても良いかもしれないが、あまりオススメはしない。
結局、順々になぞるの方が質問を受けた側の理解にもなるし、どの段階で問題が起きているか解決できるかを早期にフィードバックする機会になり得るので。
むしろ、ステップ1〜3を要約して手短に伝える方を向上させた方が良いと思う


理想はそうであれど
大体において、質問は整理されていないことが多い。

前述したようなステップ1〜3の整理をしてあげることで適切な回答をすることが必要になる。

これ、ただどこまで整理すれば良いんだろうみたいなところはある。
とりあえずステップ1が整理できていないのであればステップ1までかな、と思っている。
そうじゃないと、結局質問する側のクオリティが変わっていかないんじゃないかな…というところがある。
ステップバイステップで壁打ち役になる、ぐらいで良いかなみたいな。このあたり、自分もどうするのが良いかまだ迷っている。

解だけ見ても方程式は身につかないみたいな何かあるよね。


  • 相手がスッと理解しやすい質問や相談をしたいぜ
  • 質問のクオリティを上げて、お互いに「それは良い質問ですね」って言い合える感じにしたいぜ
  • でも、まぁ雑な質問も受け止めてあげる器量もみんな持てたらそれはそれで素晴らしいぜ
    • これはどっちかというと聞く側のスキル








Posted by at
このエントリーをはてなブックマークに追加
カテゴリ:

0 件のコメント:

コメントを投稿

GA