【新人SE】さっぱり原因のわからない問題の原因調査はこう進めよう！

本記事では、システムに問題が発生した際に、問題原因の調査を効率的におこなう方法を紹介します。特に、これまでIT業界での経験が浅く、問題の原因を手探りで探しても全く検討もつかないよ！という人でも、少しずつ着実に問題解決を進めるために有効な方法を紹介します。

問題解決（トラブルシューティング）に関しては、下記のシリーズも参照ください。

問題原因の調査の進め方を体系化しよう

SEとして働く以上トラブルシューティングは避けては通れません。システムが想定通り動かない、ネットワークがつながらない、エラーの原因がわからない。。。

経験を積んだSEであれば、どこを調べればよいか勘所も持っていますが、経験の浅いSEにとっては難しいのがトラブルシューティングです。また、ITの世界は日進月歩であり、SEとして働く以上、常に新しい技術や製品を学び続けなければなりません。熟練のSEであっても時にはトラブルシューティングの方法に迷うこともあるかもしれません。

トラブルシューティングのステップ

問題の原因を突き止めるためには、闇雲に進めるのではなく、最初にプロセスを設計することで効率的に対応を進めることが出来ます。

問題解決のための３ステップ

問題解決は以下の図のような流れで進めることが有効です。

　STEP１　仮説の立案

　SETP２　仮説の検証

　SETP３　第三者の助言

それぞれのステップを順番に見ていきましょう。

STEP１　仮説の立案

＜まずは仮説の立案＞

STEP１は、仮説の立案です。仮説とは、「これが原因の可能性がある」というネタであり、仮説を検証することで原因の調査を進めていくことが出来ます。仮説を立てることは、システムの点検箇所を挙げていくことにあたります。

このステップは「やることをリスト化して記録する」とも言いかえることができます。

ちょうど、車検で点検項目をリスト化して一つ一つ調べていくようなイメージですね。最初に仮設を立てて、記録しておくことで「何を調べたか」「何を調べていないか」ということが明らかになるため「色々調べたけど結局何も進まなかった。。。」という自体を避けることが出来ます。

＜仮説立案はログが出発点＞

基本的には、システムは処理中に何か異常があればログを出力します。自社で作り込んだシステムで発生した障害であればシステム管理者への問い合わせや、資料を参照するなどの方法で、ログの場所を確認しましょう。あなたが他社の製品を自社のITサービス内に組み込んでいる場合は製品のログを確認しましょう。ログの確認が、問題解決の出発点です。

特定の製品、例えばOracleで障害が発生した場合を例に考えてみましょう。まず、上記のお作法に則りalertログを見てみます。当然ですがエラーが出力される場所は製品によって異なるので、個別に確認が必要です。

ログは過去から連綿と記録されているため、最初は処理に不具合が発生した時刻を元にしてログを調査します。おおよその発生時刻の前後に、何かログに出力されていたら、トラブルに関連している可能性が高いです。

＜検索エンジンをフル活用しよう＞

ログの内容から原因がすぐに特定できる場合もありますが、そうでない場合、（特に他社製品を使っている場合は）そのログの文言をGoogleで検索しましょう。Oracleのエラーであれば、例えばORA-XXXというようにエラーコードで検索することで、どんな時にそのエラーが発生するのか、どうすれば解消するのか、などの情報を得ることが出来ます。

もし、エラーコードで検索して有用な情報が得られなければ、発生している事象・事実をキーワード化して調べます。ただし、この方法は上記のエラーコードから原因を特定する場合と比べて仮説の精度は落ちます。試しに、Oracleの例であれば、“Oracle　データ型　変換　エラー”などが、事象をキーワード化して調査する方法です。

試しに上記のキーワードで検索すると、２ページ目までに表示される３～４個のサイトで、「エラーが発生したけど、こうしたら解消したよ！」というような記載が見つかりました。この３～４個のサイトの事例が仮説にあたります。それを検証することは仮説の正しさに関わらず、成果となります。（間違ってたことがわかるだけでも一歩前進。）まずは、こうして見つけた想定原因を仮説として書き留め、記録しておきましょう。

SETP２　仮説の検証

STEP２は、仮説の検証です。STEP１で挙げた想定原因に対して、対策を実施して、その結果を記録していきます。

STEP２は「やったこと・結果のリスト化して記録」していく作業といえます。

仮説をたてたら次はそれを検証します。調べたサイトに解決方法がセットで書いてある事が多いのでそれらを試して、結果を記録していきましょう。また、Nicolはかかった時間もアバウトに記録しています。この情報は、あとで自分の生産性を測ることで今後同じようなトラブルが発生した際にどれくらいの時間で対処できるのかという、「見通しの正確性」を高めるために活用します。

＜仮説が誤っていても、それは成果となる＞

仮説が正しくてトラブルが解消すれば一番ですが、もし仮説が誤っていたとしても、「仮設が誤っていて、エラーが解消しなかった」という事実も一つの成果です。これらの仮説を、結果を記録しながら一つ一つ潰していくことによって、さっぱり原因のわからない問題に対しても、少しずつ前進していくことが出来ます。もし、仮説や結果の記録を行っていなければ、時間が立ってから同じ問題に遭遇した際に、同じ解決方法を試して同じように失敗してしまうかもしれません。それは時間の無駄ですよね。

自身が立てた仮説や、それを検証した結果を記録しておくことで、道に迷って途方に暮れている感は和らぎます。

SETP３　第三者の助言

問題解決は仮説の立案の検証を繰り返して答えに近づいていくことになりますが、最後にSTEP３として定期的に「第三者の助言」を取り入れることで飛躍的に効率アップすることができます。ここでの第三者とは上司、有識者やその分野の経験豊富な人であると効果が高いです。

第三者に助言を仰ぐ際には、これまでのSTEPで行ってきた問題解決の記録を共有しましょう。立案した仮説と、その対処に関する結果は揺るぎない「事実」ですので第三者が見た時に客観的な判断が立てやすいです。また、複数の仮説がある場合には、どれが最も可能性が高そうか、という当たりがつく人に見てもらえば、効率的な着手の順番を知ることができます。

また、何かトラブルが発生したとき、あなたは対処を行っている張本人なので状況がわかっていますが、上司や周囲はトラブルの原因究明が進んでいるかということが不安になります。定期的な進捗報告を行うことで、周囲もあなたの状況を把握できるため安心ですし、適切なサポートも受けやすくなります。