コーディングをしている際、順調に開発が進むということは、ほとんどありません。
多くの場合は、何かを変えたせいで予想外の不具合が発生したり、全然関係ないと思っていたところからエラーが発生したりして、慌てて元に戻すということが多々あります。
しかし、元に戻していれば、いつまで経っても先には進めません。
エラーを調査し、解消し、機能を改善させていかなければ、コーディングは完了しません。
今回は、このエラー調査の手順を示しながら、必要な観点や調査範囲を考えていきたいと思います。
エラーの原因調査
初めに行うことは、エラーの調査です。
何かエラーが起きた際、「えっ！どこに問題があるの？分からない、とりあえず元に戻そう」
このようなことをしていると、何も変えられません。
エラー文を読む
まずは、エラー文を読むことです。
エラーの原因が分からないということで相談を受けることが多々ありますが、
「いきなり英語の文章が大量に出てきてビビってプロセス終了させました」
「エラー文？読んでないです。とにかく何とかしてください」
「ログ読んでないです。どこに出力されているんですか？」
このような対応は論外です。
エラー文は、プログラム側が出してくれている、問題個所のヒントです。
たとえば、Amazonや楽天で買い物をするとき。カートに商品を入れて必要事項を記入して購入ボタンを押すでしょう。
そのとき、購入できずに「エラーが発生しました。入力内容を確認の上、やり直してください」とのメッセージしか画面に表示されなかったらどうでしょうか？
あなたは、どこの入力を直せば商品を買えるかが分かりますか？おそらく、買うのをあきらめてそっとスマホを机に置くことでしょう。
実際はこのようなことはなく、「パスワードが間違っています。」「氏名が入力されていません。」などの、「問題個所が分かる具体的なメッセージ」が出力されます。あなたは、このメッセージに従って、入力内容を修正してもう一度購入ボタンを押すだけです。
コーディング時も同じことです。プログラム側が、問題個所が分かる具体的なメッセージを出してくれているにもかかわらず、このメッセージを読まずに自分の想像に任せて調査するのは、無駄に時間を浪費する行為に他なりません。
エラー個所を特定する
エラー文の中には、エラーの原因・発生個所・エラーが発生個所までの呼び出し履歴など、多くの情報が含まれています。
ほとんどの場合、何が理由でどこでエラーが起きたのかは読めば分かります。
自分が何かを書き換えたことで、エラーが発生しているはずです。
自分が変更したことと、発生したエラーを見比べれば、何に問題があるかは分かるでしょう。
ここが分からないというのであれば、「自分の修正が、どこにどのように影響するかを理解せずに、コードに手を加えた」ということになります。これは、システムエンジニアとして活躍していく上では非常に大きな問題を含む行動パターンです。必ず改め、影響範囲を調査してから手を加えるように、手順を整理し、知識を補ってください。
また、発生するエラーの中には、頻発するものもあります。
次第に、今まで何度も見覚えがあるというエラーも複数発生するでしょう。
このようなエラーは、対策と合わせて自分の中でメモとして残していくことをお勧めします。
次、同じ過ちを犯さないために、何度も間違える点は事前に防げるようにしていきましょう。
また、「システムエンジニアとして、発生させたら少し恥ずかしいエラー」もあります。
Out of index や Null point exception といったエラーは、発生させるたびに結構反省してください。
これらのエラーは、ほとんどすべての場合で開発者の作成したフローチャートに問題があります。ループや分岐、リストの扱いなどを中心に自分のロジックのどこに問題があるかを見直し、自力で解消させるのがベストです。
これらのエラーを人に相談して解決してもらうということは、自分の考え出したフローチャートの問題を自分で解決できない、つまり、「自分にはこの機能を開発する論理的思考力が足りていない」ということを示すことになるので、相談するときは非常に注意してください。度が過ぎると、難しい仕事を任せてもらえにくくなります。
エラーの個所を特定できれば、次はその原因を突き止めて解消するだけです。
ただし、単なる機能の開発ではなく技術検証など深いレベルでの調査ごとをしている際にエラーが発生した際は特にですが、ひとつ注意するステップがあります。
修正対象の特定
たとえば、同期処理を非同期処理に書き換えていた場合。
非同期処理に書き換えたことで、今まで動作していた部分がうまく動かなくなりました、ということは起こりえます。
その際、今回の変更点は同期から非同期に変えたことだからと言って、エラーを解消するためにまた同期に戻すわけにはいかないですよね。非同期処理に変えるという目的を達成できなくなってしまいます。
このように、目的やエラーの発生原因によっては、必ずしも今回のコーディングに問題があるとは限らないということです。上記の例では、非同期処理に変えたことで動作しなくなった部分を修正するしかありません。予想していなかった修正工数が発生します。遅れが発生する可能性もあります。
エラーが発生したからといって、自分の変更内容だけを見ていても問題が解決しないことは意外と多いです。特に最近は、一度作ったアプリを何度も改修して進化させていきます。その過程で、どこかに問題を含ませていることなど、日常茶飯事です。
自分が手を入れたところだけでなく、「コード全体として、目的に適った動きをさせるにはどうすればよいか」という目線から修正対象を判断しましょう。
修正案の検討
修正対象を特定できれば、次に行うことは、修正案の検討です。
「ここを直せばいい。ということはこうしてこうして、はい、できたー」というように、すぐにコードに手を入れて見えていることだけ対処して完了というのは、危険な考え方です。
エラーとしては単純であっても、その裏には大きな問題を含んでいる可能性があります。コードの問題だけでなく、データの整合性が取れていなかったり、規約として不正な呼び出しを必要とする修正となってしまっていたり、思いもよらないところに問題が広がっていることがあります。
必要に応じてプロジェクトの他のメンバーや上位者に確認を取りながら修正案を検討しましょう。もちろん、何でもかんでも相談するのではなく、「これ、この修正方法だったらできる気はするけど、やっても大丈夫なのか？」と不安になったときに相談するように絞ることがベストです。
このような不安が生じるということは、コーディングの前フェーズ（設計・要件定義・DB設計）に問題があるということを暗に示しています。この不安に気付けるということは、あなたは単なるコーダではなく、設計にかかわってもらえそうなより貴重なメンバーとして評価してもらえるようになります。
修正の実施
ここまでいけば、あとは修正するだけです。
エラーの原因と修正対象を特定し、修正案を決定したら、コードに手を加えるなどして修正していきます。
修正自体はすぐに終わるものもあれば、時間がかかるものもありますが、テストをする際は必ず「修正案が実現できているか」という観点でテストしてください。
Aさんはコーダとしてプロジェクトに参画しています。Aさんは自信が開発している機能でエラーが発生しました。上司に相談しながらエラー原因と修正対象を特定し、修正案を決定した後、修正をしてテストをしました。
しかし、その後上司がプログラムの動作を確認すると、期待通り動いていません。 正しくテストをしたのかとAさんに確認したところ、「修正したところはテストしました」と回答を受けました。
Aさんのような方は、どのプロジェクトにもたいてい一人はいますが、何が問題かは分かると思います。
コーディングに夢中になると、どうしても「どう直すのか」という視点から「何を直すのか」という視点に思考が切り替わってしまいがちです。
落ち着いて考えたらすぐに分かることも見逃してしまい、せっかくエラー調査時に上がった評価を台無しにしてしまうこともしばしば。
正直なところ、修正案の検討時は設計時ほど具体的な会話をしません。上司は聞かれたことに対して「この方法なら大丈夫なはず」ぐらいの感覚で案を出します。
そのため、修正案の検討時に出た話だけを鵜呑みにして手を加えると、意図したとおりに直っていないということが発生します。
コードに手を加える前に、必ず自分でももう一度考え直し、必要があれば上司にもう一度話を持って行くなどして、修正内容を明確にしてから作業に取り掛かりましょう。
ここまで確実にこなすことで、最後レビューの段階で「ここまで直してくださったんですね。ありがとうございます。」という感謝をもらって開発を終えることができます。
まとめ
自分で起こしたはずのエラーが、図らずも評価をしてもらえるようなきっかけにもなると考えれば、エラーに対しても前向きに取り組めるようになります。
実際は、プログラム的にエラーが出てくれる方が、まだうれしいです。「プログラムは動いた、でもデータが正しくない」などの暗黙的なエラー、不具合の方がやっかいです。
これらのエラーも含めて、すべてに対処して正しく機能を作れるようになること、その過程で設計上の問題を指摘したり、規約違反を防ぐ取り組みをしたりすることで、より早く単なるコーダから優秀な人材、かけがえのない人材へと成長することができます。
どのプロジェクトに入っても、このあたりのプロセスを着実にこなせている人は、責任のある業務や立場を任されていますね。その分、単価も高いです。
エラーの調査ひとつとっても、自分の価値を高めるためにできることはまだまだあります。ぜひ、日々の業務の中で大切だと思ったことは続けるようにしましょう。
