オーバーエンジニアリングから学んだこと
技術的には「正しい」構成だったはずが…
少人数のチームで運用していた社内向けサービスに、Slackから操作できる便利な自動化インターフェースを構築したことがありました。
そのアプリケーションは、一般的なものよりも大容量のストレージを必要としており、クラウドストレージを使うとかなりのコストがかかるため、オンプレミスで運用することに決めました。
このアプリケーションは24時間365日稼働が前提であり、ダウンタイムやエラーが発生した際には、週末であってもできるだけ早く対応する必要がありました。
そのため、簡易的なインターフェースから、アプリケーションのステータス確認や再起動ができる仕組みが必要でした。
当時の責任者と協議した結果、次のような構成でシステムを構築することになりました。
- Slack Slash Command
- AWX
- Ansible Playbook
- アプリケーションサーバー上の手動起動プロセス
この構成は、「効率的」「再利用可能」「DevOps的に正しい」と当時は評価していました。しかし、結局この仕組みは使われなくなりました。使われなくなった時に、チーム内で会議したところオーバーエンジニアリングだという話になりました。
なぜこのようなことが起きたのか？この記事では、実際の運用現場で起きたことと、そこから得た教訓をまとめます。
なぜこの構成にしたのか？
- アプリケーションは24/7で稼働させる必要がある
- 冗長構成にすると不具合が発生するため、自動再起動ではなく、人の操作が必要だった
- 少人数のチームで、できるだけ効率よく起動・停止を行いたかった
そのため、「簡単にプロセスを制御できる方法」を模索し、SlackのSlash Commandによる運用に決定しました。
Slackはすでに社内全体で導入されており、操作インターフェースとしても自然でした。
また、アプリケーションはコンテナではなくVM上で直接動かしたかったため、構成管理はAnsibleで行い、AWXを経由して実行することにしました。
運用者は使えなかった
実装自体には問題はなく、エンジニアはSlackのSlash Commandを使って操作できていました。
しかし、エンジニア経験のない運用担当者にとっては、難解で使いづらいインターフェースになってしまいました。
- Slack Slash Command の構文は Bashに近く、GUIのような直感的な操作ができなかった
- 「簡単な仕組み」と思っていたが、実際には操作の前提知識が求められた
- 結果として Slash Command は廃止され、アプリケーション操作は元の手動管理に戻された
- 各ホストにSSHして作業することもあったので、その意味でも今回導入したサービスの利便性はあまり高くなかった。
なぜオーバーエンジニアリングだったのか？
1. 本質的な要件の誤認識
- 求められていたのは「便利なインターフェース」ではなく、誰でも確実に扱えるシンプルさだった
- 運用担当者はエンジニアではなく、障害対応や再起動に慣れていないため、技術的な操作は現実的でなかった
2. チーム体制と運用方針の未整理
- 運用方針が曖昧だったため、特定のメンバーに負荷が集中した
- 開発中も明確な方針がないまま進み、結果として開発者が開発・運用・保守まで背負う形になった
3. 調査不足
- 運用対象アプリケーションの特性や、他社・他チームでの運用例についての調査が不十分だった
- 事前に運用のベストプラクティスを調べていれば、この構成自体を選択しなかった可能性がある
少人数のチームこそ「責任ある設計」と「合意形成」が必要
この経験から、私が学んだのは以下の3つの教訓です。
- 少人数のチームでは、完璧な自動化より「許容できる運用」を選ぶ判断も必要
- 「動かなければ人が起動する」ぐらいで十分な場面もある
- インターフェース設計は、「一番詳しくない人」を基準にすべき
- 実際に操作するのが自分でないなら、誰にでも使えるUIが不可欠
- チーム全体での合意形成がないまま進むと、責任と負荷が特定の人に偏る
- 特に少人数体制では、技術リーダーが責任を持って方針を定める必要がある
- そのためには、事前の十分な調査・検討フェーズが不可欠
技術的に正しい ≠ 現場で使われる
オーバーエンジニアリングとは、単に「やりすぎた」ということではありません。
今回のケースは、手段が目的化し、現場の文脈や制約を無視して設計されたことで、使われない仕組みになってしまった典型例でした。
もし最初に、関係者全員に全体像を説明し、運用の前提や制限を共有した上で設計していれば、よりシンプルかつ持続可能な仕組みにできたかもしれません。つまり、適切なサイズのプロジェクトにしておけば、オーバーエンジニアリングにならなかったと思います。考慮事項が多かったため、オーバーエンジニアリングになってしまったと思いますが、ビジネス的にも何を優先させるかを明確にさせることで、より簡潔にできたのではないか、ということがこのプロジェクトからの教訓です。