エンジニア向け：「調査のための調査」でプロジェクトを成功に導く方法

こんにちは。ウォンテッドリーでバックエンドエンジニアをしている冨永康二郎です。

このストーリーは Wantedly Advent Calendar 2024 の7日目の記事です。エンジニアが知っておくと役立つ「調査のための調査」について紹介します。

「調査のための調査」とは

「調査のための調査」とはプロジェクトやタスクで調査対象としたものが、本当に適切か確認するためのプロセスを指します。考慮漏れや仕様変更が発覚しスケジュールが遅れた経験はありませんか？そのような問題は「調査のための調査」を行う事で低減する事ができます。

「調査のための調査」とは具体的にどのような事か

「調査のための調査」について私が大事だと考えている以下2つについて説明します。

調査対象のリスクを十分に整理できているか
調査対象の前提に誤りがないか

私はこれを意識した時からプロジェクトがスムーズに進む事が増えました。

調査対象のリスクを十分に整理できているか

プロジェクトの開始段階ですべてのリスクを潰す事は難しく優先順位を整理する必要があります。リスクの調査前に一度手を止めて以下を適切に把握できているか確認しましょう。

仕様の前提が変わってしまうもの
工数が大きく変化するもの

これらを把握し優先的に対応しないと、スケジュールの遅延や無駄な作業が発生する恐れがあります。
私はMiroのMind mapで情報の整理をする事が多く、以下のように「タスクの分解 → リスクの優先順位づけ」の流れで整理します。

この方法は以下のようなメリットがあります。

抜け漏れの発見
- 理解していると思っている事もまとめると意外なリスクに気が付く
優先順位づけが明確になる
チーム内での情報の共有がスムーズになる

調査対象の前提に誤りがないか

例えば、プッシュ通知処理に対応するために新たにジョブを実装すると定義されているとします。実装のため調査をする際にその機能のことだけに着目するのでは無く、「そもそもこの対応は本当に適切か」という調査対象の前提を疑う事が重要です。実はプッシュ通知はメールと共に送信される事が想定されており、メール送信ジョブに機能を追加した方が良い場合もあります。前提に誤りがないかは以下のような確認が有効です。

機能では無くユースケースや解決したい問題の視点で考える

類似の対応があれば過去のIssueやPR、またはその対応者に確認する
組織内のコードで追えるものであればGitHubのOrganization全体で検索する
外部のAPIなどを利用する場合は以下にて理解にずれが無いか確認する
- 一般的に利用されているAPIであれば、GitHub全体で検索する事で実装事例を確認する事ができ、ドキュメントと合わせて確認する事でより認識がクリアになる
- プロトタイプを作成する

このように前提を疑うことで調査の目的や方法が本当に適切であるかを確認できます。