目次
「ARUNASエンジニアの奮闘記」をいつもご覧いただきありがとうございます。
私は、当社に新卒で入社してから制御系の組込みシステムのソフト屋さんを主にやっていて、もう30年になります。
今回は、十年以上前に産声を上げたソフトに潜んでいたバグ（プログラムの誤りを、一般的には「害虫」を意味する「バグ」と言います）に端を発し、派生製品にまでそのバグが波及した時の苦い思い出について書きたいと思います。
１．発売後に見つかったバグ
今から十数年前に開発した、とある制御装置。ここでは「製品X」とします。
自社商品ではなく、お客様からの受託開発品ですので、詳細の説明ができないことはご了承下さい。
この製品には、Webサーバ機能が搭載されていて、ＰＣやスマホのブラウザから接続する際には、ブラウザのアドレスバーに特定のアドレスを入力します。例えば、
http://aru-nas.co.jp/
のようにすると、制御の状態がブラウザにリアルタイムで表示されます。
Webサーバに接続するにはアドレスに加えてポート番号が必要ですが、ポート番号の記載を省略した場合は自動的に80番が指定されたことになります。
もし80番以外のポート、例えばポート番号を8888番で接続したい場合は、
http://aru-nas.co.jp:8888/
と入力すれば接続が可能です。
当然、Webサーバ側でも、どのポート(この例では8888番)での接続を受け付けるかを事前に設定しておく必要があります。
このWebサーバ機能はお客さまにも好評で便利に使ってもらっていたのですが、実はソフトの一部にバグがあり、設定上はポート番号を8888番で受け付けるようにしているにもかかわらず、実際にはこの設定が無視され、初期値の80番でしか待ち受けしない欠陥があり、ブラウザから見ることができない状態になっていたことが分かりました。
（ブラウザから指定したポート8888で表示されない画面）
デバッグ中に見つけられればよかったのですが、残念ながら製品が世に出た後にエンドユーザからの指摘で見つかってしまいました。
２．このバグ、別の製品でも前にあったぞ
バグが流出してしまったのは痛恨なのですが、起こってしまったものは仕方がない。
速攻で修正してお客様にお詫びをして修正済みのソフトを装置に書き込んでひとまず事なきを得ました。
ところが話はこれで終わりませんでした。
後になって分かったのですが、このバグ、今回の製品Xの元となった別の製品、ここでは「旧製品」としましょう。
実はさらに遡ること３年前にこの旧製品でも同じバグが見つかっていて修正されていたのです。
製品Xのソフトのソースコードのかなりの部分は旧製品を流用しており、該当部分のバグも旧製品から引き継いでいたものでした。
３．どうしてこうなった？
ここで、製品開発に携わっておられる皆さんの頭の中にはいろんな「なぜ？」が浮かんでいるのではないでしょうか？
①旧製品で修正されているのなら、それを引き継いだ製品では修正されたソースコードを使うよね？
旧製品でバグが見つかったころ、製品Xがちょうど開発に着手したころでしたので、バグが見つかり修正される前のソースコードを元にしていたのでした。
もし、旧製品のバグの発覚が数か月早ければ、修正済みのソースコードをもとに製品Xの開発が行われたかもしれません。
②旧製品の修正情報が共有されていれば、引き継いだソースコードがバグ入りでもそれに気づけたよね？
これが全く共有されていなかったのです。
旧製品のソフトはすでに開発が終了して保守フェーズに入っていた中でのバグ発覚でしたので、特定の製品で発生したバグはその製品の中で完全に情報が閉じていて、ソースコードの流用先にまで全く反映されていませんでした。
③たとえバグ入りであっても、デバッグやテストをちゃんとやっていれば見つけられるよね
旧製品のテストでは、ポート設定の変更が反映されているかどうかを確認する項目が無く、バグを検出することができないテスト設計になっていました。
製品Xはソースコードだけでなくテスト設計も旧製品から流用しており、同じようにバグを見逃してしまうという大変恥ずかしいものとなっていました。
３つの要素のうち一つでもちゃんと気付いて手当されていればバグが流出することはなかったと思うと、本当に残念でなりません。
４．水平展開が何より重要
①～③に共通するのは、ひとつの問題や改善点を見つけたときに、それを関連する製品や設計に「水平展開」することが十分行われていなかったことだと考えています。
十数年前は、開発規模も今と比べて小さく、開発プロジェクトがほぼ特定の個人で運営されていて、そのなかで情報が閉じてしまう傾向が強かったように思います。
また、当時はお客様からのオーダーメイドの依頼で開発を進める受託開発がメインでしたので、製品と製品との関連性が薄く、水平展開が意識されづらい環境であったのも理由に挙げられると思います。
ほかにも要因はあるのですが、この出来事で一番痛感したのはやはりこの水平展開の至らなさで、今でもこの手痛い経験をよく思い出し、日頃遭遇する問題について常に「ほかの製品は大丈夫か？」と意識するようにしています。
５．今だからこそさらに重要性を増す水平展開
当社のホームページの製品情報を見ていただければ分かると思いますが、今は自社で企画したものを主力に据え、日々開発をしています。
受託開発メインのころとは違い、ソフトウェア開発のスタイルも大きく変わってきており、一品一様で最初から作り直す割合は少なくなり、商品コンセプトや品質面・開発生産性の面で、より再利用性を高めた戦略的なソフトウェア資産の構築が進められています。
ソフトウェアの再利用の比率が高まると、見つかった一つのソフトバグが、より多くの派生製品に影響することとなり、今回述べました水平展開を確実に実施し、問題の波及を最小限かつ確実に抑えることがますます重要となることは言うまでもありません。
もちろんバージョン管理・テスト管理・バグ管理のシステムなど、テクノロジーで対処できる部分もあり、さらに今後は生成ＡＩによる支援も有望ではありますが、やはり製品に携わる一人一人の水平展開への意識が根底にあってこそ品質は保たれるのだと考えています。
