デバッギング・ミステリー

デバッグ効率の重要性

ハードウェアでも、ソフトウェア、ファームウェアでも、おおよそ技術者にとってデバッグ作業は簡単なものではありませんし、設計とならんで、重要な開発過程です。

一般のソフトウェア開発の工数などについて語られる時、大体２つのことに集約されていると言えると思います。

1. 開発工数の多くの影響はデバッグ作業が多大な影響を与える。
2. 設計時点でのレベルが、デバッグ工数に多大な影響となる。

流行のＸＰ手法などでも、設計手法やテスト手法に対する開発手法をグループ化し、設計段階からの精度を高めることや、開発管理することが重要なポイントになっていて、テストやデバッグの効率が改善されることが主張されているように、デバッグは、開発作業の重要課題です。

作業者による効率の差

デバッグ作業は、人の能力差が極端に出る作業工程であると感じています。また、デバッグ作業の能力差は、手法管理だけでは、克服できないのではないかと感じています（ある程度の初歩的な差は埋めることはできそうですが）。

デバッグという作業は、原因を突き止めることと、改善のための分析が主な作業となります。オシロスコープ、ICE(インサーキットエミュレータ−)、デバッガなどの開発ツールや測定器などで、直接的な原因となる因子を見つけることが容易な場合には、それほどでもありませんが、リアルタイムでマルチタスクだからこそ起こる障害や、原因の直接的な現象が見れない場合には、原因を推測、仮定して考える能力が必要となります。

機器組込みのデバッグ

DSPやデジタル機器を開発する場合には、ハードウェア・デバッグといえども、CPUやDSPのデバッグ用コードがないと基本的な現象確認すらおぼつかない場合があります。

ハードウェアの設計者がＤＳＰコードを書かなければいけないわけではありませんが、ソフトウェアによって制御されているＩＣ（デジタルのカスタムチップなど）やＣＰＵ、ＤＳＰがどのように動作しているかや、テストや対策確認のためにどのように制御することが必要かなどの知識がないと、ソフトウェア担当者のハードウェア知識が高くないと障害を克服するのに時間を要します。

ＤＳＰの開発などですと、ICEがなかったり、デバッガではデバッグできない場合などもありますし、マルチチップ構成の機器などになると、複数のＣＰＵやＤＳＰが同時に動作していますから、開発ツールを使う技能だけでは、デバッグ作業はできません。

犯人探しと推理

デバッグ作業は、大半が原因を突き止めること（犯人探し）だといわれるように、証拠（現象、症状、もしくは、設計書やソースコード）から、犯人を推理（または仮定）してロジカルに謎解きを行うミステリー小説の探偵のようだと感じます。

再現性の低い不具合を追及する場合など、その障害がどのようにして発生するのかを開発ツールなどで調べるばかりでなく、推理するように考察することで解決することが多いと思います。

この仮定（推理）が正しく、原因を見つけた時は、結構うれしかったりしますし、作業中は、憂鬱な問題であっても解決できた時は、ミステリーの難事件を解決したような気分になります。

仮定や推理の能力と、現象や症状が何を表しているかを見抜く能力、消去法などで、原因と考えた仮説を消去して行き、本当の原因を特定できる能力などが要求されるため、人による差が大きくなるのだと思いますし、この差は開発手法だけでは完全に埋めることができないかもしれません。

デバッグのこの探偵能力の差を埋める開発手法が提案されるとよいのですが……