仕事上なにかしらの失敗はあるし、悔しいと思える失敗をすることがある。一番大きな失敗はなにかと考えた時に思い出すのは、複数のどうにもならないことと自分の力不足が重なった結果起きてしまった、前職でのある案件のことである。
Warning
内容にはフェイクが含まれているので、この内容をそのまま受け取らないでください。この話も登場人物もすべてフィクションで、実際の案件とは関係がありません。
はじまり
東日本大震災が起きた結果、官民問わず防災への意識が高まったのは肌でも感じる事実ではある。そんな中でどういう話の流れでそうなったのかはわからないが、我が社ではとある防災関連の機器の開発を受注した。どうやらU社という某商社のM氏に唆されてI常務が持ってきた案件だった。
この案件は経営層からのプロジェクトということで優先度が高く設定された。即座に開発チームが発足し、隣の部署のB主任がプログラム担当、N主任が基板設計担当となった。機器設計もいたが、誰が作ったかは忘れてしまった。B主任はこの案件のために、組込み向けのオブジェクト指向プログラミング講座というものに参加したらしい。あとで資料も見せてもらったが結構充実したものだったようだ。
新たな知識を習得したB主任は、モジュール指向止まりだった我が社のプログラミング技術にオブジェクト指向という強く新しい風を取り入れ、また、その成果物である一号機は予定通りに出荷されていった。
そこまでは順調だった。
二号機・三号機の開発がやってきた
高度に情報統制が敷かれている会社だったので、あとから知ったのだが、これは一点ものではなく、少しずつ異なる仕様と納期がある案件だった。一号機の出荷からしばらくすると、二号機・三号機を開発する話が持ち上がったが、そのころB主任は別件で手が離せないということになり、私が所属する部署に開発依頼が飛んできた。つまり隣の部署に体よく仕事を押し付けられる形になった。
担当することになったのは部署のエースのT先輩だった。T先輩は技術的にはズバ抜けたものはないが、忍耐力があり、並行作業のプロフェッショナルだった。おだやかな性格も相まって社内での評判は良かった。
課長はのんきなもので「すでに一号機のソースコードがあるからそれを調整するくらいの仕事」と言っていた。T先輩はコードの修正中にときどき「ウーン、ウフッフｗ」のような意味ありげな独り言を発していた。私はB主任のコードが少しアレだったのかな？と思うくらいで、他人ごとでもあったので、そのときは特に気にしていなかった。
四号機の開発がやってきた
T先輩が改修した二号機・三号機も無事出荷されていった。複数の案件を抱えていても必ず期限に間に合わせるT先輩は尊敬に値する。そんな風に思っていたところに四号機の開発依頼がやってきた。今回はB主任もT先輩も手が空いておらず、序列的に私が担当することになった。人間誰しもそうだが、ほとんどの場合、自分事になってから慌て始めるのだ。
相変わらず課長は「ちょちょいと直すだけだから大丈夫。一号機のソースコードをB主任からもらって開発を始めてくれ」と言っていたが、T先輩が二号機・三号機を開発しているときの姿を見ていた私は一抹の不安を覚えた。そしてそれは現実のものとなった。
オブジェクト指向ってナニ？
B主任が書いたコードはひどかった。表現することが難しいが、オブジェクト指向になりきれていないナニカであって、とてもオブジェクト指向に則ったものではなかった。「お前、東京まで行って講義受けてきたんじゃねーのか」と思った。
カプセル化なんてものはなく、サービスから直接あるオブジェクトのプロパティが変更されていたし、逆にあるオブジェクトから直接サービスのプロパティが変更されていた。名は体を表していることももちろんなく、意味もなく複雑に入り組んだ値の引き回しばっかりのコードは私を手品のように惑わし、初日はコードの全容を捉えることができずに終わった。
この時点で出荷2週間前で、機器もまだ出来上がっていなかった。
定数を書き換えるだけの簡単な仕事
しかも、今回は少し仕様が異なって、機器と通信する周辺機器が3台から4台に増えるらしい。周辺機器の状態はシリアル通信で取得し、それを構造体に保存するようになっていて、その情報をもとに制御が行われる仕組みになっていた。課長もT先輩もB主任もみんな「#defineで切ってあるところを3から4に変更すればいいと思うよ」と言っていた。
プログラミングの世界では計算量や空間量を表すためにランダウの記号を用いる。これに則れば が になったところでさして問題にはならないはずだ。私もそう思っていた。
嘘つけお前
このプロジェクトに関してはまだ右も左もわからない私は、まずその言葉を鵜呑みにして、定数を書き換えてビルドしてみた。するとなにか警告が出るではないか。
ふむふむ…？メモリが足りない？いやそんなバカな話があるわけねーだろ？だって通信台数を4台にしただけだし、構造体のサイズからしても30バイトくらい増えただけだぞ？
よくよく調べたらこのSoCには128KBのROMに対してRAMが3KBしかなかった。一号機の技術選定の失敗で、SoCをケチりすぎた結果だった。SoCをケチるくらいならほかにケチるところがありそうなものだが。B主任とN主任を呪った。コードの状態をB主任からもらったときと同じにして再度ビルドしてみたところ、残りRAMが数バイトと表示された。バカじゃねーの？
ただ、それをどうにかするのが私の仕事である。とりあえず小手先でどうにかならないかと思い、ダメ元でB主任に相談したところ、「ウーン。俺も忙しいから…なんとか頑張って、じゃ！」と逃げられた。テメーしばくぞ。
これまで課長のことを楽観的に書いていたが、いざというときには頼れる上司であった。事情を説明すると「同じファミリのSoCは調べてみたか？容量が大きいものがあるかもしれない」とヒントをくれた。早速調べてみたが、このファミリでは128KB ROMと3KB RAMが最大容量だった。SoCを作っている某R社も恨んだ。3KBのRAMとか目覚まし時計でも作るのかよ。課長は「なんとか切り詰めるしかないな」と言い残して帰宅していった。
カチコンカチコン
そうは言っても動くものを作らなければならない。なにもわからないながらも、なんとかコードを切り詰め、通信台数を増やすことに成功した。この時点で出荷まで1週間だった。同時期くらいになって実機の準備ができたというので、早速作ったプログラムを書き込んでみた。
「カチコン カチコン カチコン カチコン」
リレー装置が意図しない動作をしているのは明らかだった。N主任は「やべやべやべ」と言いつつ機器の電源を止めてくれた。
使っているSoCではRAM領域の先にGPIO(標準入出力ポート)の領域があり、RAMを使い潰すと意図しないGPIOへの書き込みが発生する。汎用機用のOSのようにメモリプロテクトの機構はないので、RAMの取扱いには常に注意が必要である。まあ普通のOSでもSEGSIGVなどを発してプログラムが強制終了するのだが。
これは約3日間私を悩ませた。メモリが足りていないことはわかるのだが、その原因がわからないのだ。どうしようもないので、とにかくRAMの確保に注力した。読み取り専用でいいものはROM領域に移し、使っていないグローバル領域の変数は潰すか切り詰めた。パフォーマンスは下がるが、構造体のパックも施した。あまりやりたくはないが、コンパイラの最適化オプションもメモリ最優先で指定した。
そこまでして、ようやくリレーが暴走することはなくなった。
動かない4台目の周辺機器
メモリの問題も解消したし、リレーも正常に動くようになった。通信台数は4台になったが、しかし1台だけうまく動作しないのだ。それがわからない。N主任に確認してもらっても故障しているようではないとのことだ。
すでに出荷前日となりパニックになりかけていた。もうダメかもしれない。動かない製品を納品することになるかもしれない焦りに支配されかけていた。
残業時間になり、今日があと6時間ほどになった。もう無理かと思ったところでふと天啓がやってきた。「通信時の周辺機器の台数の定義と、周辺機器状態を保持するインスタンス数の定義は異なるのでは？」と。
ふたつの定数の名前がとても似通っていた上に別のファイルに定義されていたので、気づけなかった。通信台数が増えたものの、構造体のインスタンスの数が増やせていなかったので、意図しないメモリを書き換えてうまく動かないロジックがあったのだろう。助かった。多分これに違いない。すぐに直し、機器のテストをしているN主任のところにプログラムを持って行った。
動いた。N主任も「いいね」と言ったが、テストの終わりに「時間切れです」とも言った。すでに24時を回っていた。ついに明日(時間としては今日)には梱包され出荷されるのだ。こうして1度しかテストされていない機器は出荷されていった。
その後
納品
機器の納品のため出張しろと言われ、N主任の上司のC課長とふたりで納品先に向かった。そのときもU社のM氏といろいろ一悶着はあったのだが、悪口が多くなってしまうので割愛する。納品先でのテストも成功して無事この案件は終了した。
プログラムにバグが存在しないことを保証することは不可能であるが、どうか今も正常に動作しているか、あるいは、すでに改修または置換えされていることを祈りたい。幸い四号機は特別仕様扱いで、1台しか出荷されなかったところと、用途としても直接人命に関わるものではなかったことが救いである。
果たして私は悪かったのだろうか？もっとどうにかできたところはあるのだろうか？いや、会社という組織の中でのことなので、みんなが共犯者なのではないか？
今でもふとしたきっかけで思い出して考えに耽ることがある。
初期設計は重要である
最初の設計思想や初期コードはのちに大きく響く。そのときどんなに最善策をとったつもりであっても、事情の如何によっては新しい概念を導入したり、変更を加えなくてはならなくなったりする。それに至って「もっとこうすればよかったはずだ」「このやりかたでは考慮不足だ」などはいくらでも言える。
しかし、事情は変わるし、歴史的経緯には敬意を払うべきだ。あとから発言する者は議論において優位に立てる。とはいえ、会社という組織の都合上、担当が変わることや引継ぎは往々にして発生するので、もう少し考えてくれていれば、と思うことはある。なかなか難しいところだ。
私も最近は初期コードを書く際にとても気をつけている。ただ、これが私だけのものになってもいけないので、後進にコードを書かせながら育てる必要性も感じていて悩ましい。