社内の人への質問の仕方
自分ならどう聞くかみたいなのをまとめてみます。
弊社内ではSlackでやり取りしているので、挨拶や回答期限の設定はしていません。
同じプロジェクトに参画していて同じ業務をしているチームメンバーに対して
現在、入力画面で入力された値をチェックするタスクをしています。 ○○さんは編集画面の入力値チェックを実装されたと思いますが、 文字数チェックと数字かどうかのチェックはどちらを先に判定しましたか？
①質問の背景
②質問
を記載しています。
同じような業務をしているので、ざっくりめな質問を投げても通じ合えると思っているからです。
同じプロジェクトに参画しているリーダーやチームメンバーに対して
自分自身がプログラマーで、仕様の担当者に質問を投げる想定
入力画面の仕様について質問があります。 現在、入力画面で入力された値をチェックするタスクをしています。 入力画面の入力値チェックでは、nullチェックと文字数チェックと数字チェックをする仕様になっていると思います。 チェックする順番は、 1-nullチェック 2-文字数チェック 3-数字チェック で問題ないでしょうか？
①何についての質問か
②現在の状況
③質問
を記載しています。
自分とは違う視点で仕事をしている人に対しては、最初にトピックを絞りにいきます。
こうすることで、「何に対して回答がほしいか」が明確になって、回答者側も思考の狭い範囲から回答を探せるので楽なんじゃないかなと思っています。
上司に対して
自分自身が設計者で、上司はこのプロジェクトのことは案件概要くらいしか知らない想定
実装時の入力値チェックについて、会社として方針があるか質問です。 現在、○○というプロジェクトで入力値チェックの作業をしています。 OKボタンを押したときにメッセージダイアログを出すよりも、 値が入力された時点でテキストボックスの下に赤文字でエラーメッセージを出すほうが良いと思いました。 複数の別の案件を確認したところ、テキストボックスの下に赤文字でエラーメッセージを出す実装はほぼありませんでした。 テキストボックスの下に赤文字でエラーメッセージを出す実装は避けたほうが良いのでしょうか？
①何についての質問か
②現在の状況
③調べたこと
④質問
を記載しています。
最初にトピックを絞りにいくのは先ほどと同じですが、何を調べたかも伝えることで上司の工数を1つ減らせるかなと思っています。
まとめ
私はこのテンプレートで質問することが多いです。
人によっては背景とか要らないという人がいるけど、私は、なぜ質問してきたかが分からないと答えるのが難しいタイプなので、背景を書くようにしています。
背景要らない人は読み飛ばせばいいだけの話なので。
また、
(前略) テキストボックスの下に赤文字でエラーメッセージを出す実装は避けたほうが良いのでしょうか？ それとも、実装しても問題ないでしょうか？
という質問はしないようにしています。
複数人から何度か、「はい、お願いします」というような返事を受け取ったことがあるためです。
「Yesですか？Noですか？」と聞くのではなく、「Yesですか？」または「Noですか？」とだけ聞くようにしています。
この質問テンプレートは、情報が整理できてとてもよい一方で、
記載するのに時間がかかる点はデメリットです...
P.S.
「設計書終わった？」みたいに声かけてくる人が苦手です。
どのプロジェクトの？
基本設計？機能設計？詳細設計？
期限いつまでだったっけ？
みたいに考えることが多くてパニックになるので...(;^ω^)
