こんにちは。やまさんです！
プログラミングやテストなど
開発していると、解決が難しいバグが
発生したりすることがありますよね^^;
やまさんもなかなかバグの原因が分からず
開発が進まなくて、
って、なったことがあります^^;
この記事ではバグ対応などの
問題解決に役立つ仮説思考という
考え方を紹介したいと思います。
無意識にやってる人も多いですが、
意識的にやると、
成長スピードがグンと伸びますよ！
この記事を読んで
ぜひ実践してみてくださいね！
Contents
バグ対応時の原因特定の流れ
最初にバグ対応時の大きな流れを
説明しますね。
エラーログの確認
バグが出ると、エラーログが出る
システムが多いです。
VBAなんかだと、エラーが起きたところで
処理が止まりますね。
そういったところから情報を集めるのが
最初のステップです。
初心者や慣れてきた頃は、このステップが
不十分なことが多いので要注意。
早く解決するためにロジックを見たい
気持ちは分かりますが、
早く解決するためには情報を
集めなければなりません。
エラー情報がのっているログは
しっかりと確認しましょう。
不具合箇所の検討
エラーログから得た情報で、
どこに不具合があるか検討するステップ。
この後のステップで
ロジック解析をしていく箇所を決めます。
正直なところ、不具合箇所の検討が
経験者と経験が浅い人の差が大きくます。
それはもうめちゃでます。
経験が浅い人から見ると
そう思うこともしばしば…^^;
結局、何か違うのかと言うと、
経験を積んでいる人はこれまでいくつもの
バグを解析してきたので、
いろんなパターンを知ってるんですよね。
経験を積んでいる人の予測やひらめきは
そこからきてます。
意識して思い出している場合もありますが、
無意識の場合も多いです。
ロジック解析
１つ１つコードを読んでバグの箇所を
探しにいくステップです。
ある程度経験を積むとこの解析速度は
実はデキるSEと一般的なSEで
そこまで差がつきません。
人間がコード（文字）を読む速度は
そこまで大きく変わらないからです。
実際はそう感じると思います^^;
なんで早いのでしょうか。
それは、デキるSEは処理を
パターン化して覚えているので、
しっかり読み込まなくても処理を
理解してしまうから。
簡単に言うと、
読む必要があるソースの量が少ないので
横から見てると早く見えるのです。
こんな感じで言うと、ズルしているように
聞こえてしまうかもしれませんが、
これをやるには長い経験と努力が必要。
ななめ読みでも内容が
分かっちゃうんですから
当たり前ですよね^^;
やまさんもそういう方は
本当にすごいと思います。
まさに職人です。
バグ原因がすぐにわかることはほぼない
と、ここまででバグ分析時の
大きな３ステップを紹介してきました。
でもこの３ステップを1回やるだけで
解決するバグなんてめちゃマレです。
実際は、
こんな感じではないでしょうか^^;
ちなみにこの後、
経験豊富なSEがあらわれて
”ん？ここじゃないの？”って
解決に至るのがよく見る開発現場の
風景だと思います(苦笑)
ちょっと長くなりましたが、
- エラーログの確認
- 不具合箇所の検討
- ロジック解析
この3ステップを何回も繰り返して
原因を特定していくのがバグ対応です。
つまり、トライ＆エラーですね。
ただ、このトライ＆エラー。
なんとなくやってませんか？
トライ＆エラーをなんとなくやって
解析していくのはとても非効率です…
バグ解析 ”なんとなく”でやってませんか？
バグ解析はトライ＆エラーだという
話をしました。
逆に言うと、トライ＆エラーの
高速回転させることが
バグ特定までのスピードを高める
といえるでしょう。
このトライ＆エラーですが、
なんとなくやってませか？
エラーログを見て
なんとなくバグがありそうな所を調べ
ロジックを確認。
そして、またエラーログを見て…
百戦錬磨のSEなら話は変わるでしょう。
彼らにはこれまで積み上げた
経験があるからです。
経験豊富なSEは
”なんとなく”調べているように見えますが、
彼らの”なんとなく”は経験からくる
パターンに応じた検証を
無意識にやっています。
では、とにかく経験を積まないと
バグ解析の速度は
上がらないのでしょうか…
仮説思考でバグ解析を高速化
経験が少なくても
バグ解析の速度を上げることができます。
やり方にコツがあるんですよね。
バグ解析速度UPのコツは仮説を立てて
バグの分析を行うことです。
この例だと、仮説を立てないと
エラーログで落ちているBの処理ばかり
ロジック確認してしまい、
なかなか解決まで進まないです…
他にも、例えば
何回か同じ処理が動いてるけど、
うまくいく場合といかない場合がでる
バグがあるとします。
このとき仮説を立てて進めると
→変数のクリア漏れではないか。（仮説）
→→落ちてる処理で使っている変数を
クリアしているロジックを確認しよう
などなど、こういった形で
仮説があると何を確認すればいいか
目的意識がはっきりします。
仮説が外れれば、その処理は
正しかったことが証明されるので
次の仮説を立てて調査すればOK。
なんとなく調べるより、仮説を立てると、
調査する箇所や確認ポイントが
明確になるので
トライ＆エラーの回数を増やすことが
できます。
ただ”なんとなく”調べるより
効率的ですね^^
このような考え方、思考法を
仮説思考と言います。
- 仮説思考
仮説を立て実行/分析を繰り返しブラシュアップ（方向修正）していく思考法
経験豊富なSEでも経験したことのない
バグに遭遇することはよくあります。
そういうとき、仮説思考を身につけていると
トライ＆エラーを素早く行える。
これはバグという問題を解決する上で
とても有利になります。
まとめ
この記事では以下のようなことを
紹介しました。
- バグ解析は３ステップ
①エラーログの確認
②不具合箇所の検討
③ロジック解析 - すぐに原因が分かるバグはほぼない
- ”なんとなく”のバグ解析は効率が悪い
- トライ＆エラーを高速回転させる
仮説思考でバグ解析を効率化
最後にこの仮説思考の身につけ方ですが、
この記事で説明した内容を理解して
実際に使ってみることが習得の近道です。
慣れないうちは
仮説の精度が低くなってしまう
かもしれません。
ですが、何回か繰り返すうちに
精度が上がっていきます。
最初のうちは精度を気にせずどんどん
仮説を立ててそれがあっているか
検証しましょう
例えば、
・難易度が高い処理の実装
・経験したことない機能の設計
・過去事例のないプロジェクトの運営
などなど。
仮説思考のポイントはトライ＆エラーの
高速化なので、
問題解決全般に役に立ちます。
”なんとなく”やるより、
問題解決が格段に速くなるので
ぜひ実践してみてください！
また、仮設思考以外にもSEに役立つ
ビジネススキルはたくさんあります。
その1つとして、論理思考を
以下の記事でまとめてみましたので
ぜひ読んでみてください！
それでは！
最後に（おまけ）
ボクは新人の頃、部署内でも有名なポンコツエンジニアでした^^;
プログラミングなど、ITに関するスキルが壊滅的だったのです。
ですが、今となっては社内で最短昇格を達成し、ボーナスも6回連続最高評価を達成しました。
こう言うと、なかなかの怪しさですよね（苦笑）
ということで、やまさんのエンジニア人生をプロフィールとしてまとめてみました。
ITスキル壊滅だったボクがどうやってエンジニアとしての活路を見つけたのか、気になる人は見てみてくださいね^^
プロフィールを読んでもらえれば察してもらえると思いますが、ボクはITスキル平凡な凡人SE。
めちゃくちゃプログラミングができるなど、特別なITスキルは持っていないです。
そのためか、昔は
- エンジニアになったはいいものの、IT技術に関して興味を持てない…
- 平凡なITスキルしかもってないのにエンジニアとしてやっていけるのだろうか…
- IT技術を身につけていくだけでエンジニアとして食べていけるのかな…
- 移り変わりの早いITの世界で永遠とIT技術の勉強を続けられる自信が…
このような悩みを抱えていました。
おかげさまで、プロフィールに書いたあるきっかけから↑のような悩みは解決してます。
ですが、実はバリバリのエンジニアの方でも「ITの勉強しない→エンジニア失格」という空気感にしんどさを感じてる人は多いみたいなんですよ…
というのも、「勉強しない→エンジニア失格」の空気感について、こちらの記事でまとめてみたところ、かなり人気なんですよね。
このブログの中でも人気の記事なので、気になった方は一度見てみてください^^
最後まで読んでいただきありがとうございました！！
仮説思考、処理をパターン化
同感です！