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

【5】あらかじめ切り分けの手段を整理する

　システム開発に慣れた人は，バグの症状ごとに最初に試してみる手段をあらかじめいくつか用意しているはずです．認証アルゴリズムの誤認識が疑われる事象についてはリファレンス・モデルとの比較を，ハングアップに関してはダミー・ルーチンでのコールを，といった感じです．

　ある程度パターン化できる切り分けの方法を論ずるために，もう一つ別のシステムを取り上げてみましょう．認証システムとはまったく別のシステムに対して，上述した考えかたを当てはめてみます．

　ここでは，音響装置の例を挙げてみます．図13に示すように，「ディストーション」，「リバーブ」，「ノイズ・ゲート」といった複数のエフェクト・モジュールが直列に接続されており，それぞれがソフトウェアで実装されているとします．入力と出力はなんらかのシリアル通信装置とDMA（direct memory access）が同期して通信するしくみをとっているとします．それらは評価（メイン）ボード上に実装されており，音源ICはそこにサブボードとして装着されているとします．

図13　あるエフェクト装置の例
ミュージシャンの演奏時にステージに並んでいるような，さまざまなエフェクト（音楽効果）を付けられる装置を思い起こしてほしい．実際にはもっと複雑と思われるが，ここでは説明のため，やや構成をシンプルに示している．

　ちなみに，図13の「ディストーション」というのは，エレキ・ギターなどでよく聞くひずんだ音を作るエフェクトのことです．「リバーブ」はお風呂に入ったときのようなエコーを思い浮かべてもらえればよいと思います．「ノイズ・ゲート」というのは，演奏されていないときに発する電子楽器のノイズ（ジーという音）を消すエフェクトです．

　あなたの担当は図の三つあるエフェクト・モジュールの実装とテストだったとします．そのような場合，システム・テスト中にバグ・レポートが上がってきたらどう対応すればよいのでしょうか．

● ハングアップしたらダミー・ルーチンを使う

　ハングアップした事象については，虹彩認識プログラムの場合と同じように，空ループのようなダミー・ルーチンに取り替えて試してみる方法がここでも使えそうです（図14）．

　エフェクト・モジュールが三つあるので，順番に取り替えていけばそれでOKです．

図14　ハングアップの場合の切り分け方法
虹彩認識プログラムの場合と同じく，適当な順にダミー化する方法が使えそう．ここでは，エフェクト・モジュールがソフトウェア実装されているので，これらを単純にダミー化すればよい．もしハードウェア実装ならモジュール部分のみダミー化できるテスト・ロジックが必要となるかもしれない．

● 音が出ないときは機能ブロックの境目に注目

　次に，「音が聞こえなくなった」という症状を考えてみましょう．ある特定の操作を続けた結果，音が聞こえなくなるというバグ事例が上がってきた場合を考えることにします（図15）．

図15　音が聞こえないときの切り分け
「音が聞こえない」ということは，要するに信号が「入ってこない」か「出ていかない」かなので，どちらの事情かをまず切り分ける．そのためのデバッグのポイントは図16に例示している．

　この場合もまず，再現を試みます．全体像はすでに明らかなので切り分けに移ります．ダミー・ルーチンを用意すればよいのですが，図13の構成であればもっと確実に"YES"か"NO"かが明らかになるポイントがあります．それは，サブボードとメイン・ボードの境目にあるシリアル通信回路と音源ICの間の信号線です．ここをロジック・アナライザなどでプローブして信号の流れをとらえることで，より確実に原因ブロックを特定できるはずです（図16）．

図16　音が聞こえないときのデバッグのポイント
「どのブロックに問題があるか」を突き止めることがデバッグでは重要．したがって，ハードウェア，ソフトウェアを問わず，機能ブロックの境目が重要なデバッグのポイントとなる．つまり，「入ってこない」か「出ていかない」かのデバッグのポイントは，ボードの境目になる．

　「音が聞こえない」ということは，信号がそもそも入ってこないのか，出ていかないのかの二つに一つです．エフェクト装置と音源ICの間の信号線をプローブすれば，どちらの現象が起こっているのかが明らかになります．音源ICからエフェクト装置に信号が来なければ前者，来ているのにエフェクト装置から音源ICに信号が返らなければ後者となります．前者であれば，音源ICにすでに問題があるケースです．逆に，楽音信号が入力されているのにもかかわらず，正常に出ていかない場合は，評価ボード側でなんらかの問題が生じていることになります．

● 「協力しつつ裏切る」作業がデバッグ

　最後に，まとめとしていくつか指摘しておきたいことがあります．現在，商用利用されているような巨大なシステムのデバッグは，複数の開発チームによる共同作業です．この過程はいわば，1枚のパズルのピースを埋める作業にたとえることができます（図17）．デバッグ作業に携わる人たちひとりひとりが共通の大きな1枚の絵（システムの全体）を頭に描きながら，自分が担当する部分のピースを埋めていくのです．そのため，全体像から自分の担当する部分をとらえ切れていない人がひとりでもいると，ほかの人たちもピースをうまくはめ込むことができないのです．

図17　1枚のジグソー・パズルを作っていく感覚
チーム開発におけるデバッグ作業は，1枚のパズルを埋める作業に似ている．これは，周りの手が見えていないとしごとが進まない共同作業であると同時に，自分以外のだれかを効果的に追い詰めなければならない作業でもある．「協力しつつ裏切る」のがゲームのルール．

　また，システム開発におけるデバッグ作業というのは，「協力しつつ裏切る」作業という側面も持っています．あるブロックで切り分けが進んで「自分たちが原因ではない」とわかったら，その情報はまだ切り分けの済んでいないほかのブロックの人にとっては，外堀が1ヵ所埋まってしまったことにつながるからです．もっともこの情報は，正しく提供されていればバグを抱え込んでいたブロックにとっては有益な情報になることは前述したとおりです．判明したとおりに情報をなぞってより深く掘り下げると，かなりスムーズに答えにたどり着けることもあります．優れた技術者ならそういう情報の出しかたをするように心がけるものだと思います．

さえき・はじめ
＜筆者プロフィール＞
冴木 元（ペンネーム）．システム・エンジニア．組み込みソフトウェア開発に携って何年もたつが，ハードウェア実装の実務経験はほぼ皆無．にもかかわらず，原稿を読んだ本誌の編集長は本人に直接会うまで，筆者がハードウェアの技術者だと思い込んでいたらしい．この出来事で少し自信がついたとのことでした（なぜか伝聞形）