私はデバックが得意だった

未唯へ。処理速度改善のデバック（原因追究）をシステム屋さんにしてもらっています。そのやり方に不満を持っています。

私はデバックは得意です。電算部の時に、自動車の部品の内容（品番）と組み合わせ（構成）と車との関係（仕様）を表すデータベースを作りだしていました。一台の車には１万点以上の部品が使われています。その組み合わせのイメージでほとんどつかんでいました。

設計変更した時に、その下位の部品への影響、上位の車の仕様への変更を自動的に抽出するロジックとして、ヘッドロジックを作ったりしていました。今、考えると、それは完全に数学モデルでした。

事務電算の分野で、こんなダイナミックなシステムができるとは思っていなかった。開集合とかコンパクト性とかで、「部分」と「全体」の関係をシステム化していました。「部分が全体よりも大きい」というのを発見したのも当時です。

「なぜかうまくいってしまう」プログラム群を作り上げました。20年以上、中核で動いていました。

デバックで最初に行うことは、処理プロセスをイメージ化することです。ロジックはシーケンスで発生するので、数学者にとっては楽勝です。複雑性を習得してからは、同時に複数のモノが反応し合うことまでイメージできるようになりました。

次に行うのは、何が起こっているかの現象を見続けることです。これには忍耐が必要です。プログラムには色々な欠陥が入り込んでいます。一つでも欠陥を見つけると、それを原因にしたがる人が多い。早く、行動をしたがるのです。現象がその欠陥で証明できるまで、追い込まない。

特に、それが他人が作ったもの、パッケージとかOSならば、得意げにそちらに振ります。それが原因であることに「期待」します。

システム屋さんの「途中結果」を聞いていると、現象と欠陥がイメージとしてつながっていません。

私はイメージで、欠陥と現象が明確につながるところまで追い込むのが得意だった。これはシステム開発のプロセスそのものです。だから、原因が判明すると同時に、対策が出来上がるのです。とてもシンプルなシステムが作られます。

自分の中のデバック魂がよみがえってきました。デバックするのに遠慮はいらない。お金のこととか、組織のこととかを省きます。目的にためなら、手段を選ばないという「政治犯」のスタンスです。