調査系タスクの取り組み方について

新卒2年目の tkm_kj です。

ソフトウェア開発をしていると往々にして以下のような課題が出てくることがあります。

• このツール（ライブラリ）使ったこと無いから技術検証してほしい
• こんなエラーが起こるんだけど、原因特定できないからしっかり調べてほしい
• とても性能悪い処理あるから原因特定して改善してほしい

↑のようなものを僕はざっくりと 調査系タスク と呼んでいる（調査した上で改善が込みのものもそう呼んでます）のですが、この手の課題は時間がかかりがちで色々試行錯誤しても求められてる成果が出せないリスクの高いものだと思っています。 過去にズルズルと調査して進捗も芳しくなくまともに共有も出来なかった時は、すごくつらい気持ちになりました。

その状況をなんとかしたいと思って色々試してみた結果、以前よりも少しずつ良い結果を出せるようになってきたと感じています。

そこで、最近意識してる調査系タスクの取り組み方を書きたいと思います。以下の順で書いていきます。

• 調査に着手する前にしてること
• 調査中にしてること
• 調査が終わった後にしてること

調査に着手する前にしてること

目的・完了条件をしっかり明示する

調査をしていくにあたって、目的と完了条件をしっかり把握している状態にしておくことは必須だと思ってます。

技術検証だったら、何のために調べるのか・何がわかれば完了なのかは決めるようにします。

エラーの原因調査だったら目的は明確なのですが、エラーを直すところまでやるのか、エラーの原因を突き止めたところを完了として解決は別途チームで話し合ってから着手するかということを決めます。 性能改善もエラー調査と同じようなアプローチを取っています。

目的と完了条件が曖昧なままだとチームのメンバー間で認識の齟齬が生じやすいですし、着手した時にグダグダになりやすいのでしっかり合意を取っておきたいところです。

調査中にしてること

試したことで上手くいったこともいかなかったことも、自分の手元にメモしていきます。僕はKobitoにメモしてることが多いです。 あくまで自分の手元なので、自分が見たら分かる程度のものです。

調査が進んですごく重要だなと思ったことは、適宜他の人にも見えるところにメモしてます。僕の場合はプロジェクトで ZenHub を使ってチケット管理しているので、GitHubのissueコメントに残してます。

調査が終わった後にしてること

調査が終わったら調査結果をまとめて共有を行います。 その時使っているテンプレート（適宜変えてはいるのですが）があって、

## 目的

（最初に決めた目的・完了条件を書く）

## 結果

（目的・完了条件に書いた内容を満たした結果が得られたのか得られてないのかを簡潔に書く）

## 調査内容

（調べた内容を具体的にまとめる。最終的には結果に書いたところに結びつくようにする）

## 今後の動き

（結果を元に今後どうしていくかを書く）

をベースに書いています。

調査内容に関しては自分の手元に残したメモから重要だと思ったこと、他の人に見えるように残したコメントを引用しながら書くようにしてます。 ここは他のメンバーに読んでもらってフィードバックを頂きたいので、人に読んでもらうということを意識します。

終わりに

以上が僕が最近意識してる調査系タスクに着手する時の流れになります。 とりわけ目新しいことは無いのですが、意識しないと忘れがちになるなーと思い今回書いてみました。 何か参考になりましたら幸いです。