Ops主導で進めた、内製プロダクト立ち上げとDevSecOpsの実践

こんにちは。iret MSPの後藤田です。

「セキュリティは大事だが、早い段階で入れると開発が遅くなる」。運用や開発の現場では、今でもそう捉えられることがあります。しかし、日々の運用課題を解決するための内製プロダクトを立ち上げた今回の経験では、むしろ逆でした。
Opsがプロダクトオーナー（PO）として課題を定義し、Secを初期段階から巻き込み、MVPに絞って進めたことで、結果として手戻りが減り、リリースまでの流れもスムーズになったのです。

本記事では、運用現場の課題を起点に、Dev・Sec・Opsが連携して内製プロダクトを立ち上げた過程を振り返ります。
その中で見えた失敗と学びを通じて、これからDevSecOpsを取り入れたい方、あるいは運用現場の課題を開発につなげたい方に、現場で使えるヒントを持ち帰っていただければと思います。

1. なぜ「運用アプリ」を内製したのか？

私たちMSPチームでは、日々さまざまな監視ツールやSaaSを活用しながらオペレーションを行っています。
既存のツールは多機能で汎用性が高く、運用を支えるうえで欠かせない存在です。実際、現在も重要な基盤として活用しています。

一方で、組織の規模が拡大し、求められる運用水準やセキュリティ要件が高まるにつれて、標準機能だけではつなぎきれない領域も見えてきました。

たとえば、次のような点です。

• 複数のツールをまたいだ運用フローを、現場にとって自然な形でつなぎたい


• 自社の運用ルールや判断基準を、日々のオペレーションに無理なく反映したい


• セキュリティやアクセス制御を、自社ポリシーに沿って継続的に管理したい

そこで私たちは、既存のSaaSを置き換えるのではなく、それらを活かしながら、運用の裏側を支えるアプリケーションを内製することにしました。目指したのは、単なる機能の穴埋めではありません。運用現場に自然にフィットし、かつ継続的に改善していけるアプリケーションです。
そして、それを実現する進め方として、私たちはDevSecOpsの体制を選びました。

2. なぜOpsがPOを担ったのか

このプロジェクトで最も大きかったのは、現場の解像度が最も高いOps自身がPOを担ったことです。

運用現場の課題は、数値化や言語化が難しいことが少なくありません。「なんとなく使いにくい」「この手順だけ妙に手間がかかる」「毎回この確認がつらい」といった違和感は、実際に現場にいる人にしか見えないことが多いからです。

だからこそ今回は、Opsが単に要望を出す立場ではなく、何を作るべきかを定義する立場に入りました。役割分担は、主に次のように整理しました。

• Dev（開発）：実装、設計、技術選定を担当


• Sec（セキュリティ）：後から止める役ではなく、初期段階からリスク整理と実装支援を担当


• Ops（運用）：POとして課題整理、要件定義、画面イメージの整理を担当

このように役割を明確にしたうえで、上の図の下部にあるように「Opsの運用課題（フィードバック）」を起点とし、常にSecをサイクルの中心に据えた開発フローを回していきました。
特に効果が大きかったのは、Ops側でワイヤーフレームのたたき台まで作ったことです。「この画面で何を判断したいのか」「どの順番で情報が見えれば操作しやすいのか」といった現場感覚を早い段階で共有できたことで、開発側との認識ずれを減らした状態で進めることができました。

社内ツール開発では、せっかく作っても「現場で結局使われない」ということが起こりがちです。その意味でも、OpsがPOを担ったことは単なる体制上の工夫ではなく、使われるプロダクトにするための前提条件だったと考えています。

3. 最初の失敗は、要件を盛り込みすぎたこと

とはいえ、この体制にしたからといって、最初から順調だったわけではありません。むしろ最初にぶつかったのは、要件を盛り込みすぎたことでした。

現場には、日々たくさんの不満や改善要望があります。OpsがPOになると、それだけ課題を深く理解しているぶん、「せっかく作るなら、あれも入れたい。これも解消したい」となりやすくなります。私たちもまさにそうでした。

その結果、初期段階から要件が膨らみ続け、開発スケジュールを圧迫し、このままではなかなかリリースできない状態になりかけました。ここで痛感したのが、「何を作るか」ではなく、「何を作らないか」を決めることの重要性です。

そこで、機能の優先順位づけにあたっては、次の3つを判断軸にしました。

• 業務成立に対する必須度：その機能がなければ、新しい運用フローそのものが成立しないのか。それとも、単に便利になるだけなのかを切り分ける。


• 実装コストの見積もり：Devチームと対話しながら、どの機能にどれだけの時間と負荷がかかるのかを整理する。


• 代替案の有無：システム化しなくても、一時的に手作業や既存ツールの併用で吸収できるものはないかを検討する。

たとえば、発生頻度が低く、実装負荷が高いものについては、初回リリースでは見送りました。その場では不完全に見えても、MVP（Minimum Viable Product：最小限の価値を提供するプロダクト）としてまず出し、実際の利用を通じて改善するほうが前に進めると判断したためです。

この経験から学んだのは、現場起点であっても、理想を最初から全部入れようとすると前に進めなくなるということでした。OpsがPOを担うからこそ、課題を多く知っていること自体が強みにも弱みにもなります。だからこそ、捨てる判断が重要でした。

4. Secを後工程に置かないことで、手戻りを減らせた

ビジネス機能は思い切って絞り込みましたが、その一方で、開発を止まりにくくするための技術的な土台は、初期段階から整備しました。具体的には、セキュリティテストの自動化、CI/CDパイプラインの整備、インフラ変更のコード化などです。

結果として、これが終盤の手戻りを減らし、リリースまでの流れをスムーズにすることにつながりました。

以前の感覚では、セキュリティチェックはどうしても「最後に確認するもの」になりがちでした。しかし、その進め方だと、終盤で問題が見つかったときに設計や実装までさかのぼる必要があり、開発スピードを落とす大きな要因になります。

そこで今回は、Secを後工程の確認役ではなく、設計初期から伴走する役割として巻き込む、Shift Left（シフトレフト）の考え方を徹底しました。つまり、セキュリティ確認を後ろに寄せるのではなく、できるだけ前工程で扱うようにしたのです。

具体的には、次のような取り組みを進めました。

• セキュリティ上の論点を、設計初期の段階で洗い出す


• 脆弱性チェックや静的解析など、機械的に確認できるものをCI/CDに組み込む


• インフラ変更をIaC（Infrastructure as Code）として管理し、再現性とレビュー性を高める

ここで重要だったのは、Secが「あとで止める人」ではなく、最初から事故を起こしにくい形を一緒に考える人として機能したことです。

セキュリティが最後に登場すると、現場からはどうしても「また差し戻された」という印象になりがちです。一方、初期から一緒に設計していれば、そもそも危ない実装や運用を通しにくくなります。今回の実践では、セキュリティを早く入れることが、結果として開発を遅くするのではなく、後戻りを減らしてむしろ進めやすくすると実感しました。

5. セキュリティと運用性は、適切に設計すれば両立しやすい

今回の取り組みでは、表に見える機能だけでなく、運用し続けられることも重視しました。

社内向けプロダクトでは、つい「まず動けばよい」と考えがちです。しかし、その考え方のまま進めると、あとから運用負荷や技術的負債として返ってきます。

そのため今回は、運用を人手に依存させすぎないことを前提に、管理しやすい実行基盤、再現可能なインフラ管理、認証・認可の整備を進めました。また、シークレット情報の扱いも個人依存にならないようにし、アクセス制御やシークレット管理の方法を標準化しました。

ここで強く感じたのは、セキュリティと運用性は、適切に設計すれば対立しにくいということです。
認証基盤やシークレット管理、レビュー可能な構成管理は、一見すると制約が増えるように見えるかもしれません。しかし実際には、属人化や手作業によるミスを減らし、運用の安定性も高めてくれます。

つまり、DevSecOpsとは単に“厳しくすること”ではなく、安全かつ継続可能なやり方にチーム全体をそろえていくことなのだと思います。

6. “なんとなく不調”を、改善できる指標に変えた

運用改善を継続するうえで、もうひとつ大きかったのが、ログやメトリクスを整備し、プロダクトの状態を継続的に把握しやすくしたことです。

運用現場では、ツールに対して「なんとなく遅い」「たまに調子が悪い気がする」といった不満が出ることがあります。ただ、そのままでは開発側にとっても、何をどう改善すべきか判断しづらいのが実情です。

そこで私たちは、プロダクトの挙動を継続的に観測し、エラーの発生状況を数値で把握するようにしました。たとえば、HTTPステータスコードの5xx系エラー率は、システム側の問題を把握するうえで重要な指標です。一方で4xx系エラーについても、単純に「ユーザーのミス」と片づけるのではなく、操作導線やUIの分かりにくさを見直すための手がかりとして扱うようにしました。

これによって、以前のような感覚的な会話だけでなく、次のような観点をDevとOpsのあいだで共通認識として持ちやすくなりました。

• どの種類の問題が増えているのか


• システム連携に異常がありそうなのか


• UIや導線に改善余地があるのか

データがあることで、「なんとなく使いにくい」を「ここを直せば改善できそうだ」に変えられます。可視化された指標は、単なる監視のためだけでなく、チーム間の対話を前に進めるための共通言語としても機能するようにしています。

7. まとめ：Ops主導のDevSecOpsで得た学び

今回の取り組みを通じて、私たちが得た結論は以下です。

セキュリティを後回しにしないほうが、結果として速い。 そして、その状態を現場で機能させるには、Opsが受け身ではなく主体になることが重要でした。

Opsは、現場の痛みを最もよく知っています。だからこそ、課題を挙げるだけでなく、何を優先し、どこまでを最初に実現するかを決める役割まで担うことで、プロダクトは現場に根づきやすくなります。

一方で、Opsだけでは前に進みません。Devの実装力、Secの伴走、そして共通の指標に基づく対話があってこそ、継続的に改善できる形になります。

運用の現場は、単に決められた手順をこなす場所ではありません。ビジネスや顧客への影響が最も現れやすいフロントラインであり、本来は多くの改善の種が眠っている場所です。だからこそ、Opsが自ら課題を定義し、DevとSecを巻き込みながら形にしていく。
そのサイクルを回し続けることが、これからのDevSecOpsには欠かせないのだと感じています。

おわりに

今回の実践を通じて、私たちは次のことを学びました。

• 現場起点のプロダクトにするには、OpsがPOを担う価値が大きい


• 理想を全部入れようとすると前に進まない。MVPに絞る「捨てる決断」が必要


• セキュリティを後工程に置くと手戻りが増える。初期から自動化とともに組み込んだほうが結果として速い


• 指標をもとに会話できるようになると、DevとOpsの改善サイクルが回りやすくなる

これからDevSecOpsを導入したい方、あるいは運用現場の課題をもっと開発に接続したいと考えている方にとって、少しでも参考になればうれしいです。