はじめに
この記事ではメンバー目線（特に1、2年目）での調査対応の乗り越え方を書いてみました。
自分なりにやってよかったことをまとめております。
大きく以下の3つに分けて書いております。
①調査の依頼が来た時
②調査中に気を付けること
③調査結果をまとめる時
①調査の依頼が来た時
基本的に調査依頼というものは必ず目的があって依頼されますが、
その目的を「理解しておく」ことが大切だと考えております。
理由としては、
調査内容にお互いの認識相違があった場合、
せっかく調べたものも無駄になってしまったり
顧客からも「大丈夫かな？」と不安に思われてしまいます。
調査依頼が来たときは依頼内容をそのまま実施だけではなく、
目的を理解しつつ、必要であれば認識をすり合わせながら進めていくことが大切です。
②調査中に気を付けること
調査依頼の目的を理解して調査を進める際、
以下の点には気を付けた方が良いと思いました。
-
- 調査した内容はテキストなどにメモしながら進めていく
頭の中を整理するのに必要です。
経験があればメモしなくても大丈夫にはなってきますが、
見返すことができるようにメモしておいた方が他の調査で参考にしやすいです。
-
- それぞれの設計書の意味を理解しておく
ここは障害対応と同じです。
情報を効率的に集めるにはどんな時に使用する設計書か理解する必要があります。
-
- 足りない情報は提供していただく
調査依頼は顧客から提供されたデータ（ログやエビデンスなど）を
もとに実施することも多いです。
しかし、調査に必要な情報がないことや顧客にしかわからないものも存在しますので
その際は随時確認して情報を提供していただく必要がございます。
-
- 依頼の対応期限に合わせて柔軟に動けるようにする
調査依頼の対応期限は必ず把握しておくことが必要です。
対応期限に間に合わなさそう、であれば調査結果を小出しにしながら
進めていくなどで顧客側の不安を抑えるようにしたり、
他メンバーの力を借りるなどの対応も必要となります。
-
- 調査結果の裏取りをしておく
機能の調査などについては設計書だけで調査することも可能ではありますが、
ソースコードも併せて確認することで情報が確実なものとなります。
設計書などのメンテナンスがしっかり行われるプロジェクトであればよいですが、
万が一現行の実装と違った内容を伝えてしまう可能性もありますので、
裏取りをしておくことは重要です。
③調査結果をまとめる時
調査依頼を提出する先の顧客は自分たちと同じエンジニアではないことが多いです。
そのため、調査結果を報告する際の文章・資料の作成については、
エンジニアでなくともわかる内容（何もわからない状態で見ても理解できるような）にする必要があります。
そのため、私は以下のことを意識しております。
・文章構成は「調査依頼内容への回答⇒理由⇒補足⇒質問（必要であれば）」にする
・資料作成時はシンプルかつ「見やすさ」を意識する
まとめ
調査対応は慣れるまでは時間がかかる作業だとは思います。
しかし、調査した内容は今後の遺産にもなりますので、
説明力が重要な作業だと思いました。
今回の記事で初学者の方などの参考になればとても幸いです。