はじめに
ITコンサルタントのKです。以前、Webサービスの新規開発に関わっておりました。機能開発の段階だったので、機能やビジネスロジックが正しいことの評価が大半で、運用の評価はもっと先という段階でした。 昨今のモダナイゼーションにおいて、開発と運用は切り離せない関係にあります。クライアントサーバー方式からクラウドネイティブなWebサービスへと進化させるプロジェクトを例に、「継続的な価値提供」を支えるプロセスと品質の考え方を、鉄道の仕組みになぞらえて紐解いてみたいと思います。
プロジェクトの背景：目指すのは「リカーリング型」への転換
プロジェクトは、レガシーな業務アプリをフルスクラッチでクラウド化するものです。単に「動けばいい」のではなく、ビジネスモデルをフロー型（切り売り）からリカーリング型（継続収益）へ転換することを目的としています。
開発体制は社員が要件を作成後、開発と評価をそれぞれ別の会社に委託するという建付けです。開発会社が要件をプロダクトバックログに落とし込み、Agile開発で設計から結合テストまで実施します。評価会社はシステムテスト以降の担当です。 運用は自社で担当していましたが、サーバーの監視、障害対応、セキュリティ対策（パッチ適用、ウイルス対策）、バックアップというレガシーなインフラエンジニアでした。
顧客満足度を支える5つの要素
継続的な収益を得るためには、ユーザーにとっての「負」を排除し続けなければなりません。
- 直感的なUI/UX: 迷わず使える操作性
- 過不足ない機能性: 障害やムダがなく、必要十分な機能
- 高速なレスポンス: ストレスのない処理速度
- 信頼性: 高いSLAと安定稼働
- 保守の迅速性: 障害修正や機能追加のスピード感
これらの価値を「当たり前」のものとして提供し続けることが、LTV（顧客生涯価値）の最大化に直結し、解約率の低減を実現します。
DevOpsの「8の字ループ」を鉄道に見立ててみる
開発と運用の連携を語る際によく使われる「DevOpsの8の字ループ」は、子供の頃に遊んだ 「プラレールの線路」 を思い出します。左右のループは、それぞれ「開発」と「運用」という別の組織（鉄道会社）が運営し、繋がった線路を相互に乗り入れます。
- 開発ループ： 新たな価値を積んだコンテナ（機能）を載せ、運用へ送り出す。
- 運用ループ： 現場の利用状況や障害という「情報」を載せて、開発へフィードバックする。
鉄道における「安定稼働」と「迅速さ」を両立させる知見は、そのままDevOpsのプラクティスに当てはめることができると思い、鉄道での取り組みを調べてみました。
鉄道の仕組みとDevOps施策の比較
鉄道の仕組みとDevOps・Agile・SREの施策を比較すると、同じような仕組みがあることがわかります。 顧客満足度の向上を目的に据え、「SLI/SLOと基盤整備」・「エラーバジェットにより自動制御」・「開発と運用の相互協力」・「継続的な強靭性向上」といったステップで上記施策を選択・実行し、成熟度を高めていくことになるでしょう。
| 項目 | 鉄道における仕組み | DevOps (全体像) | Agile (開発側の動き) | SRE (運用側の動き) |
|---|---|---|---|---|
| 衝突防止 | 信号・閉塞 (区間内の車両制限) | CI/CDパイプライン (自動テスト/ゲート) | WIP制限 (開発速度の維持) | カナリア・Blue-Greenデプロイ (段階的リリース) |
| ATC (自動速度制御) | 継続的モニタリング (ログ/メトリクス) | スプリントの中止 (PO判断) | エラーバジェット (SLOに基づくリリース制限) | |
| 相互乗り入れ | 車両規格統一・乗務員訓練 | シフトレフト/ライト (開発・運用境界の解消) | シフトライト (運用考慮の設計・非機能要件) | シフトレフト (開発段階での信頼性への関与) |
| 無線/信号共通化 (リアルタイム監視) | APM (性能監視/最適化) | アジャイルKPI (進捗・ベロシティ計測) | SLI・SLO (可観測性の監視) | |
| 貨物効率化 | 規格化コンテナ (積み替え容易) | コンテナ化 (環境依存解消・スケーリング) | マイクロサービス化（機能の独立・パッケージ化） | コンテナ運用 (安定運用と負荷・効率の最適化) |
| コンテナ/列車位置管理 (リアルタイム情報提供) | バリューストリームの可視化 (進捗のリアルタイム共有) | カンバン (作業フローの可視化) | コンテナ運用ツール (デプロイ・監視・スケーリング・保守) | |
| 強靭性 | 災害時の迂回・縮退運転計画 | マルチクラウド・マルチリージョン (即時に稼働移動) | フィーチャーフラグによる縮退運転機能 (基幹機能の維持) | カオスエンジニアリング (耐障害性テスト) |
品質管理の変革：評価部門は「門番」から「パートナー」へ
この「鉄道網」のようなプロセスを回すとき、品質保証のあり方も変わらなければなりません。 前プロジェクトにおける評価部門は、リリース直前に立ちはだかる「門番」でしたが、保守運用が中心となるモダナイズ後の世界では、 「信頼性のガードレールを構築するパートナー」 への転換が求められます。
具体的な施策
- SLO（サービスレベル目標）の共有: 「不具合ゼロ」ではなく、SLOを全員の共通ゴールにします。これにより、全員が「攻め（新機能）」と「守り（信頼性）」のバランスを自分事として考えられるようになります。
- エラーバジェットとバックログの連動: エラーバジェット（許容できる失敗の枠）が枯渇した際、即座に「信頼性向上タスク」を優先するルールをバックログ運用に組み込みます。POが責任を持ち、新規機能と改善を両立します。
- テストの自動化とテスト環境のコード化: 評価部門はテストを代行するのではなく、開発・運用がセルフまたはCI/CDで利用できる「高精度なテスト環境（IaC、AIエージェント指示書（AGENTS.md））」と「自動テストスイート」を提供します。AI駆動開発では評価ハーネスを構築します。
SRE視点での信頼性テスト
独立した評価部門が関わる場合、以下のようなテストを「開発の早い段階（シフトレフト）」と「リリース後の運用段階（シフトライト）」に分けて組み入れます。継続的にテストできるよう「テストを自動化し、開発・運用に環境をフィードバックする仕組み」を構築することで「安定稼働」と「迅速さ」に貢献できます。
| テスト種別 | 内容 | SREにおける目的 |
|---|---|---|
| 負荷・ストレステスト | 限界値やスパイクアクセスを確認 | SLOを維持できる最大キャパシティの把握 |
| カオスエンジニアリング | 意図的に障害を注入 | 自己修復能力と監視・発報の妥当性確認 |
| DR（災害復旧）テスト | リージョン切り替え等を試行 | RTO（目標復旧時間）がSLO内かの確認 |
| オブザーバビリティテスト | 擬似異常によるアラート確認 | 「未知の異常」を検知できるかの確認 |
最後に：外部委託における「SRE」の法的リスクと対策
ここまではプロセスや文化の話でしたが、実務上の大きな壁となるのが 「委託契約」 です。安全な運行を支えるのは、車両や信号（技術）だけでなく、鉄道会社間の『運行規定（ルール）』であるのと同様に、ITの世界でも『契約』が重要です。SREのアプローチを外部委託する場合、以下の4点に注意が必要です。
- 準委任契約における「善管注意義務」： エラーバジェット枯渇による「開発停止」が、委託範囲に含まれていないと、発注側から「予定の成果が出ない」とクレームになり、受注側は「契約外の改善を強いられた」と紛争化するリスクがあります。
- 請負契約における納期遅延： SREの判断でデプロイを止めた場合、法的観点では「発注者側の都合による履行不能」とみなされ、ベンダーから納期延長や追加費用を請求される根拠になり得ます。
- 偽装請負の懸念： 発注側のSREチームが、ベンダーの開発者に対して直接「予算が尽きたからバグ修正に全リソースを割け」と細かく指示を出すと、指揮命令権の問題（偽装請負）が生じる可能性があります。
- 納品物の著作権： AI駆動開発における評価基盤の構築（ハーネスエンジニアリング等）において、AIエージェントを活用して評価プロセスを自動化する際に、テスト観点等をルールとして提供することがあります。再利用性が高い知見をそのまま納品することになるので、著作権への配慮や暗号化するなどの対応が必要となります。
解決のためのアクション
これらのリスクを避けるためには、契約段階で 「SLA/SLOの仕組みそのもの」を合意事項に組み込む ことが不可欠です。「エラーバジェットが枯渇した際は、優先順位を動的に変更する」というルールを業務範囲として定義しておくことが、健全なDevOps運用の第一歩となります。
モダナイゼーションは、単なる技術の刷新ではありません。開発・運用・そして契約を含めた「文化の刷新」であることを、改めて意識していきたいものです。
