Case Study
開発元不在の保安システム改修（地方空港 様）
開発元は倒産し、仕様書もなく、書いた本人もいない。残されていたのは納品時のソースコードだけ。そこから原因を特定し、誤検知と未検知の双方を解消しました。
「場当たりの修正で症状が消えても、それは直ったことになりません。保安のシステムでは、なぜそうなるのかを説明できないまま動かすほうが、よほど危険です。」
—— 門王
本事例は、お客様および元請企業様との守秘の観点から、施設名・所在地・システム構成を伏せて記載しています。
また、保安に関わるシステムであるため、検知の仕組み、判定の条件、当時発生していた事象の具体的な内容には触れていません。
本件は十年以上前の案件です。使用技術は当時のものですが、「資料も開発元も残っていないシステムをどう引き継ぐか」という進め方は現在も変えていません。
解決した課題
直面していた状況
- 滑走路への不正侵入を検知するシステムで、誤検知と、検知されるべきものが検知されない事象が発生
- なぜそうなるのかが分からず、施設側でも切り分けができない状態
- 継続してメンテナンスを任せられる事業者が見つからない、という相談でもあった
技術・体制の壁
- 開発元が倒産し、連絡がつかない。仕様書はなく、書いた本人もいない
- 手元にあるのは納品時のソースコードのみ。長年の追加で複雑化していた
- 保安設備という性格上、作り直しの判断ができず、既存のまま直す必要があった
複数の防犯システムが並列に稼働しており、そのうちの一つがVisual Basicで組まれていました。ご依頼は、法人歴の長い元請企業を通じてのものです。その元請企業でも手に負えないシステムである、という前置きから始まった相談でした。
門王の処方箋
この案件でやるべきことは、機能を足すことでも、作り直すことでもありませんでした。まずソースコードを最後まで読み切り、「いま何が起きているのか」を説明できる状態にすること。そこからしか始められない仕事です。
調査・改修のポイント
- 症状ではなく、コードから原因を特定：再現条件から追うのではなく、納品されたソースコードを読み解いて処理の流れを再構成。開発当時の性能制約を回避するために選ばれていた検知方式そのものに原因があることを突き止め、根拠を添えてレポートしました。
- 判断を一段から多段へ：誤検知については、単一の判断で結論を出していた箇所を多段的に判断する形へ変更。検知されない事象については検知パターンを調整し、二つの症状を切り分けて対処しています。
- 動いていない処理を、流れから外す：開発途中で止まったと思われる機能や、使われた形跡のない処理が散見されました。削除ではなく処理が到達しないようにすることで、動作を軽くしています。
- 二名体制での相互レビュー：保安に関わるシステムのため、単独作業は避けるべきと判断し、VB技術者に協力を依頼。互いが書いたコードを相互にレビューする体制で進めました。
- 触らない範囲を、先に決める：複雑化したコード全体の整理は、費用と、動作確認にかかる負荷の両面から見合わないと判断。協議の上で「今回は手を入れない」と明示的に決めています。
- 次の会社に渡せる形で納品：仕様書のない状態を繰り返さないよう、簡易なドキュメントと、検知パターンを調整する際の手順資料を作成して納品しました。
技術解説：資料のないシステムを、どう引き継ぐか
—— 引き受けるかどうかは、どう判断したのですか。
条件としては最悪に近いものでした。開発元は倒産、仕様書なし、書いた人もいない。あるのは納品時のソースコードだけです。ただ、逆に言えばソースコードは残っていました。動いているものには、必ず理由がコードの中に書いてあります。読み切る時間さえ確保できるなら、原因は必ず特定できる——そう判断してお受けしました。
—— どこから手をつけるのですか。
読むことからです。この種の相談では、まず症状を再現させて当たりをつけたくなりますが、今回はそれをやりませんでした。滑走路への侵入検知という性格上、場当たりの対処で症状が消えても意味がないからです。たまたま出なくなっただけなのか、原因が取り除かれたのかを区別できないまま運用に戻すのは、直っていないより悪い。処理の流れを最初から最後まで再構成して、説明できる状態にするところまでを先にやりました。
—— 原因は何だったのでしょうか。
具体的な条件は保安に関わるため書けませんが、性質としては「当時としては妥当だった割り切り」です。開発当時のマシン性能では処理が追いつかないため、負荷を抑える形の検知方式が選ばれていました。その割り切りが、ある条件下で誤検知と見落としの両方を生んでいた、というのが結論です。バグというより設計上の選択で、だからこそ症状だけを追いかけても辿り着けなかったのだと思います。
—— なぜ二名体制にしたのですか。
私自身もVBは扱えますが、このシステムを一人で見るべきではないと考えました。侵入検知の判断に手を入れる以上、書いた本人が気づかない見落としが致命的になります。VB技術者に協力をお願いして、互いに書いたコードを相互にレビューする形をとりました。人手を増やして速くするための二名ではなく、確認の目を二つにするための二名です。
—— コード全体の整理はしなかったと。
しませんでした。長年の追加でかなり複雑化していたので、整理したい気持ちはありました。ただ、手を入れれば入れるほど、動作確認しなければならない範囲が広がります。稼働中の保安システムでその範囲を広げるのは、費用の面でも、リスクの面でも見合いません。「今回はここまで、ここから先は触らない」と協議の上で決めて、記録に残しました。直せることと、直すべきことは別です。
—— 引き継ぎ資料まで作られたのはなぜですか。
今回の相談は、目の前の不具合を直してほしいという話であると同時に、「今後メンテナンスを頼める会社が見つからない」という話でもありました。そこで自分が抱え込む形にしてしまうと、開発元が消えて困った状況を、そのまま繰り返すことになります。簡易なドキュメントと、検知パターンを調整する際の手順書を残して、次にどこが引き継いでも作業できる状態にするところまでを、この案件の仕事だと考えました。
この案件について
十年以上前の案件ですが、門王が請け負う仕事の性格をよく表しているものとして掲載しています。使用技術は当時のものであっても、「資料がない」「開発元と連絡が取れない」「作り直せない」という条件は、いまも現場から消えていません。
門王は25年以上にわたるLinux・OSS開発の実績を持ち、他者の書いたコードをメンテナとして引き継ぐ経験を重ねてきました。仕様書のないシステムの調査、開発元不在のシステムの改修や引き継ぎも、お引き受けしています。まず「いま何が起きているのか」を説明できる状態にするところから、ご相談ください。