新人技術者のためのロジカル・シンキング入門（1） ―― いかにしてバグの原因を突き止めるか

【2】全体で100％になるイメージを描く

　現象を再現できたら，問題の切り分けを進めていくことになるのですが，そこでのポイントは大きく二つに分かれます．

　まず，全体で100％になる絵を自分の頭に描くことが必要となります．これはどういうことかというと，エラーにかかわる機能ブロックをすべて自分の頭の中に描き，それらの関係を明らかにしたうえで，どのように絞り込みをかけていけば切り分けが進むのかというイメージを描くことです．

● データの「流れ」でシステム全体をとらえる

　イメージを描く場合，「流れ」で全体をとらえることがコツだと思います．例えば音響装置であれば，「入力信号が処理されて出力される」という一つの流れがあるはずです．映像を扱う装置でも扱うデータが画像になるだけで，この基本的な流れは変わりません．

　図3に，Aさんが開発したシステムの概略図を示します．認証制御ブロックの中に認証モジュール，すなわちこのシステムのかなめである虹彩認証アルゴリズムが実装されているとします．左のカメラ・デバイスから映像を取り込み，認証制御ブロックで解析を行った後，そのデータは通信制御ブロックで外部機器との通信に用いられると考えられます．

図3　虹彩認証システムの例
カメラから画像を取り込み，「認証制御ブロック」と呼ばれる機能ブロックで認証し，「通信制御ブロック」から認証情報を通信するものとする．虹彩認証アルゴリズムは真ん中のブロックにあるのだが，単体モジュールの問題の切り分けでは「全体像」と「流れ」をつかむことが重要となる．

　このようにデータの流れでシステム全体をとらえることで，考えの偏りによる漏れをなくすことができます．ソフトウェア技術者にはありがちなことですが，例えばハードウェアに原因があってエラーが生じているのに気づかず，切り分けにとまどうことなどもあります．ソフトウェアのことが頭の中のほとんどを占めているため，どうしてもハードウェアについては考えから抜け落ちてしまいがちです．この世にあるソフトウェアは，そもそも組み込みソフトウェアでなくても，実際にはすべてハードウェアのうえで動いていることを忘れないようにしましょう．

● 過去の事例にとらわれない

　また，デバッグする際，過去の成功事例（つまりスムーズに切り分けを行えた），あるいは逆にとても苦しんだ事例など，本人にとって印象深い経験があると，そこにしがみついてしまう人がいます（図4）．そのような状況に陥ることなく，原因がわかりにくいものであっても切り分けを進めていけるようにするためにも，上述の「全体で100％になる絵を描く」とか，「流れでとらえる」という方法を生かしましょう．とにかく，過去の事例にとらわれないということが重要です．

図4　デバッグは客観性がたいせつ
組み込みシステム開発に何年も携わっていると，だれでも武勇伝（徹夜など，さんざんな目に会いながらデバッグした経験）を持っている．その記憶があまりにも強烈だと，どうしてもそれにとらわれがちになる．過去の武勇伝に他人を巻き込まないこと．

　今回の例でいえば，例えば過去にシステムがハングアップしたとき，その原因があるモジュールのメモリ・リークであった経験があるとしましょう．その場合，今回もなにはなくともメモリ・リークを疑って，メモリ・リークがないかと部下を動員してソース・レビューを始めてしまう人がいたら，このパターンに陥っているといえます．結果的にメモリ・リークが原因であれば，それが問題解決の最短経路になるのですが，そうでなかった場合は，行き詰まることになってしまいます．