調査タスクを割り当てられたけど、正直きつい。行き詰っている。。。
どうすればクリアに近づくんだろう？
普段開発業務に携わっているエンジニアでも、急に調査タスクを振られることがあります。
調査タスクは、難解かつ正解が見通しづらいものであることが多く、きついものです。
プレッシャーも大きく、そのような中で行き詰ってしまうと、精神的に消耗してしまいますよね。
僕も、普段はおもに機能開発を担当していますが、時々調査タスクに取り組むことがあります。
それらの経験をふまえ、エンジニアの調査タスクがきつい理由や、行き詰まって「もうダメだ！！」となった場合の対処方法を考えてみました。
以下の経験に基づき、記事を書いています。
- プログラミングを独学し、30代で未経験からSIerに転職。
- 業界知識、プログラミングスキルが半人前のため、調査タスクがきついです。
- 試行錯誤したり周囲にアドバイスをもらったりしながら、タスクをクリアできた経験をまとめました。
調査タスクがきつい理由
調査タスクは、主に以下のような状況で発生します。
- 開発中のシステムで、想定外のエラーが発生した
- テストフェーズで、設計と異なる動作をするケースが発覚した
- 運用中のシステムで、お客様からの不具合問い合わせがあった
いずれも、現行の作業への影響が大きく、至急の原因特定が求められる状況です。
このような特性のあるエンジニアの調査タスクが、難しくなる理由は、以下の通り。
正解は専門的かつ難解なところにある
そもそも、チームには複数のエンジニアがいます。
エンジニアは一定以上の技術力を持っているはずなので、簡単な事象ならすぐに解決しているはずですよね。
つまり、調査タスクが生じるまでには、以下の過程を辿っているはずなんです。
調査タスクは、既に複数のエンジニアが考えたものの解決できなかった課題をクリアしなければならない、と言えます。
正解に至る道筋が困難であることが、調査タスクが難しい最大の要因です。
状況の把握が難しい
テストフェーズや運用フェーズで問題が起こった場合、その背景にある状況はたいてい複雑怪奇です。
メソッド（一つ一つの処理）やクラス（機能）はそれぞれ別のエンジニアが担当する場合が多く、さらにそれらをクラウドのような専門知識の必要なプラットフォームで走らせることが普通です。
- 処理間の連携がうまくいっていないのか？
- プラットフォームとの相性の問題なのか？
- ユーザーが、開発者の意図していない操作を行っているのか？
考えるべきことが無数にあり、何が原因でその問題が生じているのか、という状況把握が困難です。
至急の解決を求められる
調査タスクが挙がった時点で、それは何かしらのトラブルに起因しています。
納期が迫ったテスト中に不具合が発生したのか、リリース済みシステムでお客様からのクレームが入ったのか。
いずれにしても、至急の解決を求められる場合がほとんどです。
上記のように複雑で難解なタスクを、急いで何とかしろと振られる。
被害が大きいほどにプレッシャーが重くのしかかります。
クリアのために意識すべきこと
前述の通り、調査タスクは難しいのに急ぎの対応を求められる、大変な業務です。
僕もよく行き詰まり、あっという間に半日くらいの時間が過ぎ去って、「あぁ、もうダメだ……！！」、となっています。
そうなったときに状況を少しでも良くしていくために、意識していることをまとめてみました。
問題およびゴールを明確にする
まずは、タスクの内容およびゴール地点を明確にしておくことが重要です。
タスクによっては、発生した状況を口頭のみで伝えられ、手がかりとなるエビデンスが提供されない場合があります。
そういった場合でも、何をしようとして何が起こっているのか、ということは自分で試行したうえで冷静に把握しておくべきです。
また、タスクの終着点も要確認。
- 問題の原因を特定すればよいのか？
- 回避策（ソースコードを変更せず、操作のみで凌ぐ）を提示するのか？
- 改修案（プログラムの修正方針）を提示するのか？
- 実際に改修作業まで行うのか？
見落としがちですが、ここが曖昧だと、調査途中で「結局何をすれば良いのだっけ……？？」、と道を見失ってしまいます。
現在地点を常に確認する
難解な状況に向き合うのですから、手を動かしたり参考資料を集めたりしながら、試行錯誤を繰り返していくことになります。
よくありがちなのが、本流の調査から試行で脇道に逸れたところでドツボにはまり、そこで時間を費やしてしまう。
そうしているうちに、本流の次にやるべき試行を忘れてしまう、という状況。
そうならないよう、「今何をしているのか、何のためにこれを試しているのか」ということは常にメモし、調査の本流を見失わないようにするべきです。
何とかしてエラーログを取得する
不具合が生じた具体的な状況や操作、ログなどのエビデンスが提供されない場合（非IT系のお客様からの問い合わせで多い）、報告を手掛かりに同じ状況を自分で再現するしかありません。
調査タスクの解決のために欠かせない最大の手掛かりは、エラーログです。
エラーログにはソースコード中のどの処理でコケたかが記載されていることが多いため、これを入手できるかどうかがタスクをクリアできるかどうかの分かれ道。
何とかして問題と同様の状況を自分の開発環境で再現し、エラーログを取得することを目指します。
直近の変更履歴を見直す
これまで問題なかったのに、あるとき突然不具合が起こった。
このような状況は、直近の変更との干渉で起こっているケースが経験上多いです。
その改修の単体テストでは想定していなかったようなパターンが起こり、既存機能との連携に失敗している……
直近のGitのコミット履歴を見返し、どのような改修が行われているのか把握。
不具合が起こっている箇所と関係性のある変更は怪しいので、重点的にチェックするべきです。
状況をオープンにする
調査タスクがうまくいっていても、行き詰っていても、状況はチーム内に都度オープンにしていったほうが良いです。
進捗状況に関する打合せが毎日あるようなプロジェクトならその場で共有すれば良いですし、そうでなければ1日1回は調査状況を資料にまとめ、展開していくのがおすすめです。
調査タスクの発生当時はチーム内でわかるメンバーがいなかったとしても、調査が進んで原因が絞り込めてくると、その箇所により詳しいメンバーからアドバイスをもらえるかもしれないためです。
無理なときは無理と言う
そして、どうあがいても無理な場合は、素直に上長に言いましょう……笑
一人で抱え込んで精神ばかり消耗しても、良いことはありません。
そこまで困難な状況であれば、上長やプロジェクトマネージャーから、スケジュールの見直しやお客様への報告に動いてもらったほうが確実です。
調査状況を適切に整理し、これまでの仮説や確認したこと、時間を要している理由を説明すれば、きっと理解してくれるはずです。
まとめ：きついけど大きくスキルアップ、是非前向きに！
この記事では、以下の内容を紹介してきました。
- 調査タスクはたいていの場合難しい。
- 行き詰ったら、本記事で紹介したポイントを重点的にチェック。
- 一人で抱え込みすぎない！ダメなら周囲に協力を依頼し、また上長に動いてもらう。
調査タスクを振られて案の定なかなか解決できず、焦っている状況は、エンジニアなら間違いなく何度も経験するはずです。
そのような状況ではプレッシャーから精神を消耗しますが、落ち着いて現在地点およびゴールを把握し、足元から調査を進めていくべきです。
また、このように正解の見えない課題に仮説を立てて向き合い、解決に至るという経験は、エンジニアとしてのスキルを大きく向上させます。
調査タスクに取り組むことになった際には、成長のチャンスだと捉えて、是非とも前向きにチャレンジしてみることをおすすめします。
本記事が、そのような状況の一助となれば幸いです。
