- 調査の目的を把握する
- 問題と課題を把握する
- 課題に優先度づけをする
- 課題の期日を把握する
- 途中で報連相する
- 調査結果を報告する時は、自分の考えを添える
- 調査の目的に立ち返る
調査の目的を把握する
「自分はなぜこの調査をする必要があるのか」を把握する。
- 調査A「この調査に意味はない。ただ時間を潰す為だけにある」
- 調査B「機能X / 機能Y どちらを次のリリース候補とすべきかの判断材料を持ちたい。なので機能の利用統計を調査する」
同じ時間を使うならば、どちらの調査をやりたいだろうか。
目的がわからない場合は依頼者へ「なぜやるのか」と聴く。
問題と課題を把握する
目的を土台にして、問題と課題を設定する。
問題と課題の違い、洗い出し方の詳細は別の記事 に書いてある。
付け加えて大事なのは「設定した問題と課題に誤りがないか」である。
立場や役割が何であろうが、設定した問題と課題を他の人(特に依頼者)にレビューしてもらう。
調査やり直しの大半は、問題と課題の設定誤りが原因だ。
課題に優先度づけをする
課題には優先度の高いもの、低いものがある。
- 優先度の高い課題
- 知見もなく応用も利かないので、文献調査や実験をする
- 知見のある人に聞き込みをする必要がある
- 結果を得るために単純に時間がかかる(場合によっては優先低になる)
- etc.
- 優先度の低い課題
- これまで得られた知見を応用すれば、数分で片付く
- 目的から外れる
- etc.
各々分類して先に調査すべきものを見極める。
優先づけが正しいかどうかも、他の人(特に依頼者)にレビューしてもらう。
ここで優先順を誤ると、時間を浪費する。
課題の期日を把握する
調査に限らないが、課題に期日を決めて取り組む。
決まっていない場合は、依頼者に聴く。
時間はカネだ。浪費を許すな。
途中で報連相する
「10 個の課題に関して、結果をまとめて報連相する」 というのは
「100ファイルの差分をまとめてコードレビュー依頼する」
と同様のことだ。そんなコードレビューをレビューワーとしてやりたいだろうか。
区切りをつけて報連相することを奨める。やる目安を掲載しておく。
- 一つの課題を解決したら報告する
- 一日調査して、どの課題が解決しそうかしなさそうかの目処を連絡する
- 課題解決の困難さが見え始めたら連絡、期限の相談する
- etc.
調査結果を報告する時は、自分の考えを添える
「こういうことが分かりました」
それは結果報告の資料やコメントを見れば分かる。
報告から分かる自分なりの考えを添えて、報告を一段階レベルアップする。
- 課題は解決するのか、しないのか
- する場合はどういう手立てを今後踏むべきか
- しない場合は代替案がないのか
- その数値は良い値なのか、悪い値なのか
- 良い値を継続するには現状の仕組みで良いのか
- 悪い値を改善するには策が考えられるのか
調査の目的に立ち返る
調査の目的を忘れない。目的に立ち返れば調査すらしなくて良い場合がある。
依頼者: 機能A を実現したいんだけど、機能A が使うライブラリBの操作方法を調査してくれないか。
あなた: はい。ちなみに、なぜ機能A が必要なのか、目的を教えてもらえますか。
依頼者: 投稿者のデータを特定ユーザーにメール送信させたいんだ。
あなた: なるほど。ちなみに、それは半年ぐらい前に作った 内部向けメーラー機能Z で流用できないでしょうか。
依頼者: そういえばそんなのあったな。。ライブラリBのことは横に置いてくれ。内部向けメーラー機能Z ってどんな仕様だったか教えてくれるか。