■

　午前中は出荷品のリストを作ったり書類を書いたりの雑用。
　午後になって、とある制御装置の組み込みソフトをある状態にしたときに出力電圧にノイズが乗ると上司から連絡があった。現物をいろいろ調べてみたところ、どうも組み込みソフトに後から追加したタイマー割り込みの周辺に原因がありそうだった。
　このタイマー割り込みは上司が仕様に書き忘れていた機能を後から無理やりねじ込むために追加したもので、信号線の制御で競合が起こる可能性があった。実装の時点で問題のあるコード（少なくとも問題が起こる可能性が高い）なのは分かっていたが、上司が癇癪を起こして急かす上に、既存のコードに手を入れることを許可しないと言い張るので仕方なくそのままになっていた。

　もちろん問題が起こる可能性については上司にも訴えたが、いつもの通り聞き入れてもらえなかった。どうも上司は何か不具合が起こっても基本設計を見直すことなしに、すぐに局所的な手直しに走る傾向がある。
　おそらくこれは電子回路の基板作りと同じ意識でソフトウェア作りを考えているせいだろう。電子回路基板の設計変更や作り直しにはそれなりの費用ががかかるため、試作品などでは部品の空中配線やジャンパ線で凌ぐことが少なくない。おそらくソフトウェアも同様に個別にモグラ叩きで済ませる方が低コストだと考えているのだろう。
　ところがソフトウェア、特に制限の多い組み込みソフトウェアでは局所的な修正は上手くいかないことが少なくない。
　例えば後からタイマー処理を一つ追加する場合、パソコン上で動作するソフトウェアならほとんどの場合ＯＳの提供するAPIでタイマーを作れば事足りる。ところが機能の貧弱な組み込みマイコンではことはそう簡単ではない。その処理をどの割り込みレベルで行うのが適切か・他の処理とリソース競合を起こさないか（排他）・処理を追加することで他所で速度の低下や処理時間の不足などが起こらないか、などなど様々な配慮が必要になる。ろくに考えずにその場しのぎで安易な方法を取ると後で予想外の不具合を起こす恐れがある。実際今回の不具合も予想の斜め上の現象だった。

　と言ったことを何度も説明したのだけど、「動いてるところは触るな」の一点張りで、どうしても設計の見直しは許可されなかった。どうせ上司はソースコードを読めないので、こっそり直してしまうという選択肢もあったが、もしそれがバレたら余計に厄介な事態になるのは明白だったので、不本意ながら指示に従ってお座なりの手当で済ませることにした。
　ちょうど毎日のようにネチネチと理不尽な文句を言われ続けて精神的に疲れていた時期でもあり、つい易きに流れてしまった。この点については、技術者としての誠意を欠く判断だと言われても仕方ない。もっとも、「じきに不具合が見つかって仕方なく根本から直すことになるだろう」という算段もあった。（実際は予想は外れてずいぶん長い間不具合が発覚しなかったが。）
　とまあ、そういう経緯もあり、不覚にもついうっかり「だからあの時何度もそう言ったのに…」とぼやいてしまった。するとまたまた上司は「最初からこの機能（タイマーを必要とする機能）と付けるように指示をしていた。（だから自分は悪くない）」とムキになって言い訳をし始めたので、適当にごまかす羽目になった。つくづく口は災いの元だ。

　納得いかないので後で開発記録を見返してみたらやはり上司の仕様書（もどき）にはそんな記述は一切無い。自分の記憶が絶対に正しい自信もないが、おそらく上司が都合よく記憶を改変しているのだと思われる。どちらでもいいことだが。

　ところで今回開発記録を見返して気づいたが、この装置はもう１年以上前からダラダラと開発が続いている。上司の１.５ヶ月のスケジュール遅れのツケを責任転嫁させられて３日でソフトを仕上げろとか、社会人失格だとかさんざんに責められてきたのは何だったのか。それに１１月にはできる予定の上司のタスクは未だ白紙のままなのはなぜなのか。実に不可解で不愉快な仕事である。

　ちなみに上記の不具合を調べている途中で上司が他所に呼ばれて行ってしまったので、待っている間に後輩社員に相談されて仕様書書きの手伝いをしていた。仕様書の方がが一区切りついても上司が戻って来なかったので、こちらから出向いて一言断ってから帰宅した。ふう。