100%を積み上げる
顧客とのシステム連携の打ち合わせで、「うちは100%を積み上げるから連携テストは要らない」と言われたことがあります。正直驚きましたが、その場では流しました。
後日、私の担当外のシステムで、縮退時パラメータの認識齟齬により、本来はフェイルセーフできたはずの障害が発生し、結果としてシステムが1日停止したと聞きました。
ITIL4の一般的マネジメントプラクティスの継続的改善とは
システムというものは稼働がゴールではなく、むしろスタートとして捉えるべくべきだと考えています。多くのシステム導入後が定着しきれない要因は、導入完了後の運用・改善フェーズに十分な設計がなされていない点にあります。
- 業務プロセスの変化は導入後も継続する
- 組織・市場・法規制・技術は常に変化する
- 利用部門の習熟度は時間とともに変わる
そのため、一度決めた要件や運用を固定化せず、変化を前提に管理する仕組みが不可欠です。
継続的改善とは
継続的改善とは、以下を恒常的な活動として回す考え方です。
- 業務・システム変更要求の可視化
- 変更の優先順位付けと影響評価
- 小さく・早く変更を反映
- 利用状況・効果のモニタリング
- フィードバックを次の改善に反映
これはITILやDevSecOpsの考え方とも親和性が高く、「変更を抑制する」のではなく変更を安全に回すことを目的とします。
システム導入後に起きやすい課題
部門最適の再発
- 各部門が個別に改善要望を出す
- 部門ローカル運用（Excel、手作業）が再発
- システム全体の整合性が崩れる
→ 全体最適の視点が失われやすい
IT部門／業務部門の分断
- IT部門：安定運用・変更抑制を重視
- 業務部門：スピード・柔軟性を要求
→ 「ITは分からない」「現場を理解していない」という対立構造に陥りがち
部門を超えた協業の設計ポイント
導入後を見据えたガバナンス体制
システム導入時点で、以下を明確に定義しておくことが重要です。
変更意思決定の場（例：運営委員会、プロダクト会議）
役割分担
- プロダクトオーナー（業務視点）
- ITアーキテクト（技術視点）
- 運用責任者（安定稼働視点）
判断基準
- 業務価値
- 全体最適
- リスク・コスト
部門横断の共通言語を作る
協業を阻害する大きな要因は「言葉の違い」です。
| 領域 | 業務部門 | IT部門 |
|---|---|---|
| 関心 | 業務効率、成果 | 可用性、保守性 |
| 言葉 | 手間、使いづらい | 技術制約、負荷 |
これを埋めるために：
- 業務KPIとIT指標を結びつける
- 「業務価値→システム機能→技術要素」の因果を可視化
- ドキュメントを部門共通の粒度・表現で作成
協業を前提とした運用プロセス
以下のような定常プロセスが有効です。
- 定期的な振り返り（Monthly / Quarterly）
- 部門横断の改善バックログ管理
- 小規模変更の迅速な承認フロー
- 利用データ（ログ・KPI）を用いた事実ベースの議論
CI/CDパイプラインと業務システム
DevSecOpsを前提としたWebシステム開発では、CI/CDパイプラインにより、継続的変更管理を意識せずにリリースやデプロイが行われることが多いと思います。
では、このようなCI/CDの考え方を、先の「協業を前提とした運用プロセス」として業務システムに適用できるのでしょうか。
結論から言うと、「業務アプリの継続的改善 × CI/CDパイプライン」は条件付きで実現可能です。ただし、Webサービスと同じやり方をそのまま持ち込むと、ほぼ失敗します。
なぜ無理なのか - 業務システム特有の制約
業務システム（基幹・周辺業務含む）には、CI/CDと相性が悪い要素が多く存在します。
- 業務停止＝事業リスク（止められない）
- 利用者が社内・特定部門に限定
- 仕様変更に業務ルール・規程・教育が絡む
- テストに業務知識が必要
- 外部ベンダ依存、ブラックボックス
この結果、「頻繁にデプロイするのは現実的ではない」「毎回調整と承認で数ヶ月かかる」という感覚が生まれます。この感覚自体は正しいです。
それでも「実現可能」と言える理由
ポイントは「CI/CD＝毎日自動デプロイ」ではないという再定義です。
CI/CDの本質は頻度ではなく回すことです。
- 変更を安全に
- 変更を小さく
- 変更を繰り返し可能な仕組みで
| Webサービス | 業務システム |
|---|---|
| 1日10回 | デプロイ月1〜2回でもOK |
| A/Bテスト | 承認後リリース |
| ユーザー即反応 | 業務KPIで効果測定 |
業務アプリ向けCI/CDの現実解
フルCI/CDを狙わない。いきなり以下を目指すと破綻しやすいです。代わりに有効なのが段階的CI/CDです。
業務システム向けではないCI/CD
- 完全自動リリース
- 承認なしの本番反映
- 利用部門を巻き込まない変更
「業務変更」と「システム変更」を分離する
失敗の最大要因はここです。これらを同時リリースするとCI/CDが破綻します。
- 業務ルール変更
- マスタ構造変更
- 画面・帳票変更
- ロジック変更
→「業務変更は業務のリズムで、技術変更は技術のリズムで」
部門協業がないと100%失敗する
CI/CDはツールの話ではありません。
よくある誤解
- IT部門だけでCI/CDを構築
- 利用部門は「完成物を受け取る側」
- 承認は形式的
→ 改善が止まる or 使われない
必要な協業モデル
最低限必要なのは：
- 業務代表（Product Owner）
- IT（開発・運用）
- 変更を判断する場（月次/隔週でも可）
ここで話すのは技術ではなく：
- 何の変更が業務価値を生むか
- 今回は出す／出さないの判断
- 次回に回す理由
結論：CI/CDは「対話を回す装置」でもある
補足1：では「対話が回らない」状態とは何か
多くの業務アプリ現場では、CI/CDが無い、または形だけある場合、対話はこうなりがちです。
よくある状態（CI/CDなし）
業務部門：「現場で困っている。まとめて改修してほしい」
IT部門：「影響範囲が大きい。要件を固めてからでないと無理」
結果
- 半年〜1年に1回の大型リリース
- 要望が“要求書”に変わった瞬間に対話が止まる
- リリース後に「思っていたのと違う」
→会話は“要求提出”で終わり、フィードバックが循環しません
CI/CDが入ると何が「装置」になるのか
CI/CDは「自動でビルド・デプロイする仕組み」ではなく、「変更を“話題にし続けられる状態”を作る仕組みであるということです。
- 小さな改善要望が「対話」になる
- 「出す／出さない」の判断が対話になる
- 障害・不具合が「責任追及」から「対話」に変わる
まとめ
CI/CDは技術基盤ではなく、会話基盤
- リリースは結論ではなく仮説
- デプロイは終わりではなく問い
- パイプラインは変更管理会議を毎回強制的に開く装置
冒頭の「100%を積み上げるから連携テストは要らない」という判断は、
変更の影響を横断的に可視化する場がなく「正しいかどうか」を対話で確認する回路が存在しなかったことの結果でもあると思います。もし、CI/CDの「変更を話題にし続ける装置」というものがあれば、この種の事故は構造的に減らせたのではないかと思います。
補足2：DevOpsではなくDevSecOpsとして捉えたときのセキュリティの考え方
なお、CI/CDを業務システムに適用する際のセキュリティやガバナンスについては、以前の記事ITIL4とPESTELで読み解く、企業セキュリティのあるべき姿
で解説しています。
一般的マネジメントプラクティス一覧
- アーキテクチャ管理
- 情報セキュリティ管理
- ナレッジ管理
- 測定と報告
- 組織変更の管理
- ポートフォリオ管理
- プロジェクト管理
- 事業関係管理
- リスク管理
10.サービス財務管理
11.戦略管理
12.サプライヤ管理
13.要因及びタレント管理 ← 今回はコレ
14.継続的改善
株式会社ジールができること(宣伝)
AIを活用するためには確かなデータ基盤とPDCAのそもそもPを始めるためのデータの可視化が必要です。ジールではZ-BISS BI製品選定サービスというものを提供しております。はじめてのデータ活用、もっとデータ活用したい方へ。また、数十以上のBI製品を取扱う安心安全のBI選定サービスをご利用になりたい方は、 BI・データ活用の窓口「Z-BISS」 へアクセスしてみてください。