前回のあらすじ

【連載第9回】技術指標が「売上」に変わる？SLOでビジネス価値を可視化する

前回、私たちはエンジニアの技術的成果を「売上」というビジネスの言葉に翻訳し、部門間の「言葉の壁」を打ち破るための“共通言語”、すなわちSLO（サービスレベル目標）についてお話ししました。

技術的な改善が、ユーザーの幸福度を通じてビジネスKPIにどう貢献するのか。それを一枚のダッシュボードで可視化することで、エンジニアの貢献はもはや単なるコストではなく、事業成長を牽引する「投資」として、その価値を多くの関係者が理解できるようになったのです。

さて、エンジニアの価値を正しく「翻訳」できるようになった今、物語は次の章へと進みます。価値を「可視化」した次の一手は、その価値創造のプロセス自体を「加速」させることです。「開発スピードを上げたい。しかし、スピードを上げればセキュリティリスクが高まる…」この古くからのジレンマこそが、ビジネスの成長を阻む最後の壁として立ちはだかります。

もし、セキュリティが開発のブレーキではなく、むしろ安全にアクセルを踏み込むための「ガードレール」だとしたら？

今回は、DevSecOpsという思想を武器に、クラウド都市のハイウェイから検問所を取り払い、誰もが安全に高速で価値を届けられる新しい都市設計を始めましょう。

 

この記事でわかること

  • なぜ、従来の「ゲートキーパー型」セキュリティが、クラウド時代の開発スピードを阻害してしまうのか。
  • 開発者の「自由と責任」を両立させ、安全と速度を加速させる「ガードレールとしてのセキュリティ」という新しい思想。
  • ITIL 4のサービスバリューチェーンに、DevSecOpsの思想を組み込み、セキュリティをビジネス価値創造のプロセスに統合する方法。
  • AWSのサービスを活用し、未来の「あるべき姿（To-Beモデル）」として、”攻め”のセキュリティ体制をどう構築するかのビジョン。

 

なぜ、セキュリティは「開発のブレーキ」になってしまうのか？

あなたの会社の開発プロセスを、一本の高速道路に喩えてみましょう。ビジネスの要求という目的地に向かって、開発チームは猛スピードで車を走らせています。しかし、その道路の至る所には、厳格な「セキュリティ検問所」が設置されています。

  • 設計フェーズの検問所
    • 「その設計では、承認できない」と、アーキテクチャが根本から覆される。
  • 実装フェーズの検問所
    • コードフリーズの直前に脆弱性スキャンが実施され、大量の修正依頼と共に差し戻される。
  • リリース直前の検問所
    • 最終承認プロセスで待たされ、市場投入のタイミングを逃してしまう。

これらは、セキュリティチームが「ゲートキーパー（門番）」として機能する、従来型のモデルです。増え続ける脅威からビジネスを守るという重大な責任を背負い、彼らは全力で職務を全うしていますが、その結果として意図せず開発のボトルネックとなり、ビジネス全体のスピードを著しく低下させてしまっています。

発想の転換：セキュリティを「多層的なガードレール」として再定義する

DevSecOpsの本質は、セキュリティを「検問所」から、開発者を支援する「ガードレール」へと役割を転換させることにあります。ただし、このガードレールは一枚岩ではありません。

事故を未然に防ぐ「予防的ガードレール」と、危険を即座に知らせる「発見的ガードレール」の二層で考えることで、その本質がより明確になります。

  1.  予防的ガードレール
    • 逸脱させない「建築基準法」
    • これは、逸脱してはならない安全な範囲をあらかじめ明確に示し、その範囲内での自由と速度を保証するものです。都市計画における「建築基準法」のように、そもそも危険なものが作られないようにする仕組みです。責任は開発者とセキュリティチームで共有されます。
  2.  発見的ガードレール
    • 異常を知らせる「都市パトロール」
    • これは、ルール違反や予期せぬ危険（脆弱性など）が発生した際に、それを即座に検知しフィードバックする仕組みです。24時間体制で都市を巡回する「パトロールチーム」のように、問題の早期発見・早期解決を支援します。

この思想の下では、開発者は「あれはダメ、これはダメ」と制限される存在ではありません。安全な運転方法（セキュアコーディングの知識）を学び、リアルタイムで危険を知らせてくれる計器（IDEに統合されたセキュリティツール）を使いこなし、ガードレールの内側で自由に最高のパフォーマンスを発揮する、プロのドライバーなのです。

セキュリティチームの役割も、リリース直前に問題点を指摘する監査役から、開発初期段階から安全で走りやすい道路を設計する都市計画家や、高度な運転技術を教えるインストラクターへと変わります。

これにより、セキュリティは「コストセンター」や「ブロッカー」ではなく、ビジネスの品質とスピードを両立させる「イネーブラー（実現者）」へとその役割を変えるのです。

 

設計図：「ITILの価値連鎖」にガードレールを組み込む

この「ガードレール」という思想を、どうすれば組織の血肉としていくことができるのでしょうか。ここで、私たちの羅針盤であるITIL 4のサービスバリューチェーンが登場します。ITILを「思考のOS」とすることで、セキュリティという重要な機能を、ビジネス価値創造の一連の流れの中に、シームレスに組み込むことができるのです。

これは、私たちが目指すべき未来の姿（To-Beモデル）であり、その設計図です。

 

1.計画 (Plan)

  • 思想
    • セキュリティは技術課題ではなく、経営課題である。これは、クラウド都市全体の「都市計画（マスタープラン）」そのものです。
  • ガードレール
    • 事業戦略の段階からセキュリティ要件やコンプライアンス要件を組み込み、投資判断を行う。経営層がセキュリティの重要性を理解し、文化変革をトップダウンで支援する。

 

 

2.エンゲージ (Engage)

  • 思想
    •  お客様やビジネス部門との対話の初期段階から、セキュリティは議題に上がるべきである。
  • ガードレール
    • 「この機能のCVRは？」と聞くのと同じ熱量で、「この機能で扱うデータの機密レベルは？」を問いかける。要件定義の段階で脅威モデル分析を行い、潜在的リスクを洗い出す。

3.設計と移行 (Design & Transition)

  • 思想
    • セキュリティは後付けするものではなく、設計に埋め込むものである（シフトレフト）。まさに、安全な「道路（アーキテクチャ）」を最初から設計することに他なりません。
  • ガードレール（予防的統制）
    • そもそも危険な建築物が建てられないよう、都市の「建築基準法」そのものをサービスとして実装します。例えば、AWS Control Tower や Service Control Policies (SCP) を用いて、「承認されていない地域でのインフラ構築を禁止する」「暗号化されていないストレージの作成を許可しない」といったルールを組織全体に適用します。これにより、開発者は意図せずとも安全な領域から逸脱することができなくなります。加えて、再利用可能なセキュアなアーキテクチャをコード化したテンプレート（AWS CloudFormation Guardなど）を整備し、設計段階からコンプライアンスを徹底します。

4.取得/構築 (Obtain/Build)

  • 思想
    •  人間の目視レビューへの依存を減らし、自動化された検査をCI/CDパイプラインに統合する。
  • ガードレール（発見的統制）
    • 開発者がコードをコミットすると都市のパトロールチームが巡回するように、Amazon CodeGuru Securityによる静的アプリケーションセキュリティテスト（SAST）や、Amazon Inspectorによるソフトウェア構成分析（SCA）が自動実行される。脆弱性が発見されれば、マージされる前に開発者に直接フィードバックが届く。これにより、セキュリティチームがボトルネックになる状況を大幅に減らすことができます。
      • SAST：Static Application Security Testing
      • SCA：Software Composition Analysis

5.提供とサポート (Deliver & Support)

  • 思想
    • リリースして終わりではありません。都市が完成した後も、脅威は常に変化し続けます。
  • ガードレール（発見的統制 と 対応）
    • 都市の安全を24時間体制で見守るインテリジェントな「総合防災センター」を稼働させます。脅威インテリジェンスを用いて不審な活動（例: 悪意あるIPからのアクセス）を検知する「Amazon GuardDuty」、そしてセキュリティベストプラクティスからの逸脱を一元的に可視化する「AWS Security Hub」が、常に都市全体を監視します。 また、違法建築や意図しない改築を自動で検知・是正する「都市パトロールチーム」（AWS Config）が構成変更を常時監視し、定期的な「建物の耐震診断」のように、Amazon Inspectorが継続的な脆弱性評価を実施。万が一のインシデント発生時も、コードとして定義された「自動化された消防・救急隊」（AWS Systems Manager Automation Runbookなど）が迅速に対応します。

このように、ITILの価値連鎖の各段階に「ガードレール」を設置することで、セキュリティは断絶された個別の活動ではなく、ビジネス価値創造と一体化した、流れるようなプロセスとなるのです。

 

まとめ：セキュリティを、ビジネスを加速させる“翼”に

「セキュリティは開発のブレーキである」――。その固定観念を今こそ打ち破りましょう。 DevSecOpsの本質とは、開発者に重荷を負わせることではなく、「ガードレールという名の翼」を授けることに他なりません。ITILという普遍的なフレームワークに沿って、この思想を組織のOSとして組み込むことで、私たちは初めて、クラウドがもたらす真の俊敏性と、ビジネスを守る堅牢性を両立させることができるのです。

これは、単にツールを導入すれば実現できる世界ではありません。開発、運用、セキュリティ、そしてビジネスサイドの全員が、共通の目的に向かって役割を再定義し、協働することで初めて、この新しい都市の礎が築かれるのです。

あなたの会社は、今日も「検問所」の前で手作業による予測不能な渋滞を起こしていますか？ それとも、「ガードレール」に守られたハイウェイを駆け抜け、競合他社を置き去りにするようなスピードで新しい価値を顧客に届けられていますか？

私たちが目指すクラウド都市は、誰もが安心して、思い切りアクセルを踏み込める場所でなければならない。そしてこのビジョンは、私たちMSP事業者がお客様に提供すべき「次世代の付加価値」そのものです。単なるインフラの保守運用に留まらず、お客様のビジネスのアジリティと安全性を両立させ、事業成長を共に加速させる戦略的パートナーとなる。そのための設計図は、すでに私たちの手の中にあるのです。

「まずは、あなたの開発パイプラインの中で、最も渋滞している『検問所』はどこでしょうか？ その検問所を一つだけ、自動化された『ETCゲート』に変えられないか、チームで話し合ってみる。その小さな一歩が、クラウド都市の交通を劇的に変える革命の始まりになるかもしれません。」

 

出典

¹ How AWS built the Security Guardians program, a mechanism to distribute security ownership (AWS Security Blog)

² How to build a Security Guardians program to distribute security ownership (AWS Security Blog)

 

次回予告

今回、私たちはDevSecOpsという思想を武器に、開発プロセスに「ガードレール」を設置し、安全性とアジリティを両立させるための設計図を手にしました。誰もが安全に、そして高速に価値を届けられるハイウェイが、今まさに開通しようとしています。

しかし、どんなに優れた交通システム（ガードレール）を導入しても、そのハイウェイ沿いに建ち並ぶ建物（アーキテクチャ）そのものが、時代の変化に取り残され、老朽化したり脆弱なまま放置されていたとしたらどうでしょうか？

安全な交通網は、その都市を構成する堅牢な建築物と一体となって初めて真価を発揮します。構築した当初は完璧だと思われたシステムも、新たな脅威の出現やビジネス要件の変化によって、気づかぬうちに「技術的負債」の塊と化してしまう…。一度きりの監査で「問題なし」のハンコをもらっただけの”形骸化した”Well-Architectedレビューに、果たして意味はあるのでしょうか。

次回は、この根深い課題に切り込みます。AWS Well-Architected Frameworkを、一度きりの「健康診断」で終わらせるのではなく、日々の運用に組み込み、継続的に改善し続ける「生きたアーキテクチャ」へと昇華させるための実践知を詳しく解説します。

【第10回】そのWell-Architected、「生きて」いますか？ MSPが実践する継続的改善

クラウド都市の価値が、時と共に失われるのではなく、むしろ増し続けるための秘訣がここにあります。

 

過去の連載はこちら

これまでのバックナンバーを見逃した方は、こちらからご覧いただけます。

クラウド運用に関するお悩みや、これからのパートナーシップのあり方にご興味をお持ちでしたら、どうぞお気軽にお声がけください。あなたのビジネスが直面している課題について、ぜひお聞かせいただけませんか。

クラウド導入実績 国内トップレベルの cloudpack クラウドの設計・開発・構築から 運用保守までトータルサポート