レガシープロジェクトで意図せずSRE的役職を体験したエンジニア2年目の話
― 組み込み制御ソフトウェアと「最大の技術的障壁」―
はじめに
私はエンジニア1年目のとき、
長年運用されている組み込み制御ソフトウェアのレガシープロジェクトに配属されました。
配属から1年ほど経った頃、制御ソフトウエア開発だけでなく、
- ビルド環境の改善
- デバッグ環境の整備
- 開発者体験（DX）の向上
といった、今思えばSRE的な仕事を任されるようになりました。
この記事では、
その中で経験した ビルド環境移行の試みと失敗、そして学び を共有します。
プロジェクトの前提（組み込み制御ソフトウェア）
- 言語：C / C++
- 実行ファイルが複数存在
- 実行ファイル間は以下で強く結合
- IPC用メッセージキュー
- 共有メモリ（設定データ、状態管理）
- ビルド環境は VirtualBox上の専用VM
典型的な「動いているが、誰も全体を説明できない」状態でした。
VirtualBoxベースのビルド環境が抱えていた課題
当時のビルド環境には、次のような問題がありました。
- 新規メンバーの環境構築に時間がかかる
- VMが壊れると誰も直せない
- どの依存関係が必要かドキュメント化されていない
- GUIありの環境でめちゃくちゃ重い
特に致命的だったのは、
「なぜこの環境で動くのか」を誰も説明できない
という点でした。
Dockerへのビルド環境移行を試みた理由
私がDocker移行で本当にやりたかったことは、
単なる「新技術の導入」ではありません。
目的としていたこと
- 開発体験の向上
- デバッグ環境の浸透
- ビルド環境のドキュメント化
- 新規技術を受け入れる体制の強化
- ビルド環境イメージを容易に修正できる状態
Dockerfileは、
- ビルド手順
- 依存関係
- 前提条件
をコードとして残せるため、
組み込みのレガシー環境と相性が良いと考えました。
Dockerビルド環境は「技術的には」成功した
実際に以下を実現しました。
- Dockerfileによるビルド環境定義
-
.envを使用したスクリプトでイメージのビルドとコンテナの起動が一発 - VM不要で即ビルド可能
技術的な問題は、ほぼありませんでした。
しかし、Dockerは全く受け入れられなかった
現場の反応は、想像以上に厳しいものでした。
- 「今のVirtualBoxで困っていない」
- 「Dockerはトラブル時に誰が見るのか」
- 「新しいことを覚える余裕がない」
- 「今のやり方を変える理由がない」
Docker環境は正式には採用されませんでした。
この時点で私は、
技術的合理性 ≠ 組織的合理性
だということを強く実感しました。
結局、VirtualBox環境で大きな問題が発生した
我々の開発ではお客様となる実際の販売元にソースコードを提供する形となっていました。
その客先でソースコードをビルドして装置に載せて使用します。
その工程で以下のような問題が発生しました。
- 客先でビルドした実行ファイルと自社でビルドした実行ファイルに差分が発生する
この問題は客先のVirtualBoxでのビルド環境と自社のVirtualBoxでのビルド環境のライブラリのバージョン違いにありました。
このとき初めて、環境がブラックボックスであること自体がリスクとして認識されました。
実行ファイル単体でデバッグできないという致命的問題
もう一つの大きな課題が、
実行ファイル単体でのデバッグができないことでした。
理由は明確で、
- IPC用メッセージキュー
- 設定データを書き込む共有メモリ
- 暗黙的な起動順依存
により、単体起動すると即座に異常終了するためです。
結果として、
- 全体起動が前提
- デバッグ1回のコストが高い
- 試行回数が極端に減る
という状態に陥っていました。
Docker環境に「実行ファイル単体デバッグ」を組み込んだ
私はDockerを ビルド用途ではなく、デバッグ用途 に絞って再設計しました。
実施したこと
- IPCリソース（メッセージキュー・共有メモリ）を最小構成で再現
- デバッグ用設定を明示化
これにより、
- 実行ファイル単体でのデバッグ
- 再現性のある障害調査
- 新人でも同じ環境を即再現
が可能になりました。
この経験から学んだ一番大きなこと
この記事で一番伝えたいことは、
技術の話ではありません。
レガシープロジェクト最大の障壁は「人」である
特に、
- 長年プロジェクトを支えてきた
- 暗黙知を多く持つ
- 強い発言力を持つ
いわゆる 「長老的存在」 の影響は非常に大きいです。
その人が使わない技術は、
- 正しくても
- 便利でも
- リスクを下げても
プロジェクト全体には浸透しません。
そして多くの場合、大きな問題が発生して初めて、「使ってみるか」という判断が下されます。
SRE的視点で振り返って思うこと
- SREの仕事は「新技術導入」ではない
- システムと組織の不確実性を下げること
- 技術よりも「再現性」「属人性」「リスク」を語ること
- 全体導入ではなく、部分導入で信頼を積むこと
エンジニア2年目でこの経験ができたのは、
今振り返ると非常に貴重でした。
まとめ
- 組み込み × レガシー × VM は属人化しやすい
- Dockerは目的を絞れば有効
- 技術的に正しいだけでは導入されない
- 最大の技術的障壁は、往々にして「人」
- 問題が起きてからでないと、変化は起きにくい
おわりに
同じようにレガシープロジェクトで悩んでいる方の、
何かしらの参考になれば幸いです。
「うちも同じだった」「分かりすぎる」などあれば、
ぜひコメントで教えてください。