前置き
BizDevOpsにDevSecOpsやテスト駆動開発などを組み合わせた、現代的な「∞（インフィニティ）型」のデリバリーサイクルは、ビジネスから開発、セキュリティ、運用までが断絶なく、継続的に連携するモデルです。
以下に、その各ステップを詳細に解説します。
BizDevSecOps：∞型デリバリーサイクルの全体像
このモデルは、左側の「ビジネス・開発ループ」と右側の「開発・運用ループ」の2つのループが無限大（∞）の形で繋がっているのが特徴です。
セキュリティは、特定のステップではなく全てのステップに組み込まれます。
（引用元：ネットにあったJiraの画像）
⬅️ ビジネス・開発ループ（アイデアの製品化）
1. アイデア / 戦略 (Idea / Strategy)
役割：Biz (ビジネス部門)
内容
市場のニーズ、ビジネスゴール、競合分析などから、新しい製品や機能のアイデアを創出します。ここでは「何を作るべきか」という大きな方向性を定めます。
2. 分析 / 計画 (Analyze / Plan)
役割：Biz & Dev (開発チーム)
内容
ビジネス部門と開発チームが協力し、アイデアを具体的な要求に落とし込みます。
ユーザーストーリーマップの作成、優先順位付け（バックログ管理）、そして実現可能性の検討が行われます。
3. 設計 / モデル化 (Design / Model)
役割：Dev & Sec (セキュリティチーム)
内容
・アーキテクチャ設計：ユーザーストーリーを実現するための技術的な設計を行います。
・脅威モデリング (DevSecOps)：
設計段階で「このシステムはどのように攻撃される可能性があるか？」を洗い出し、
セキュリティ要件を設計に組み込みます。
これにより、手戻りの大きい開発終盤でのセキュリティ問題発覚を防ぎます。
4. 開発 / テスト (Code / Test)
役割：Dev & Sec
内容
・テスト駆動開発 (TDD/BDD)：
まず失敗するテストコードを書き、そのテストをパスするための最小限のコードを実装し、リファクタリングする、という短いサイクルを繰り返します。
これにより、品質の高いコードを効率的に生み出します。
・静的アプリケーションセキュリティテスト (SAST)：
コードを書きながら、IDEのプラグインなどを通じて既知の脆弱性がないかを継続的にスキャンします。
5. 継続的インテグレーション / リリース (CI / Release)
役割：Dev, Sec, Ops (運用チーム)
内容
・ビルドとテストの自動化：開発者がコードをリポジトリにプッシュすると、自動的にビルド、単体テスト、結合テストが実行されます。
・動的アプリケーションセキュリティテスト (DAST)：
CIパイプラインの中で、実際に動作しているアプリケーションに対して擬似的な攻撃を行い、脆弱性をテストします。
・リリース候補の作成：
全てのテストをパスした成果物（コンテナイメージなど）が、いつでもデプロイできる状態の「リリース候補」として作成されます。
➡️ 開発・運用ループ（製品の価値提供と改善）
6. デプロイ (Deploy)
役割：Ops & Dev
内容
・Infrastructure as Code (IaC)：
TerraformやAnsibleなどを使い、インフラの構成をコードで管理します。
これにより、手作業によるミスを防ぎ、一貫性のある環境を迅速に構築できます。
・継続的デプロイメント (CD)：
CIをパスしたリリース候補を、ブルーグリーンデプロイメントやカナリアリリースといった
安全な手法を用いて、自動的に本番環境へデプロイします。
7. 運用 / 監視 (Operate / Monitor)
役割：Ops & Sec
内容
・オブザーバビリティ：
メトリクス、ログ、トレースを収集し、システムの健全性をリアルタイムで監視します。
・インシデント対応：
SLO（サービスレベル目標）に基づいてアラートを設定し、問題が発生した際には迅速に対応します。
この記事を参考にしてください。
・継続的なセキュリティ監視：
SIEMなどを活用し、本番環境での不審なアクティビティを常に監視します。
8. 学習 / フィードバック (Learn / Feedback)
役割：Biz & Ops
内容
・データ収集：
運用監視データ（パフォーマンス、エラーレートなど）と、ビジネスデータ（ユーザーの利用状況、コンバージョン率など）の両方を収集します。
・フィードバックループ：
この定量的・定性的なデータを分析し、
「リリースした機能は本当にビジネスゴールに貢献したか？」
「次の改善点はどこか？」
という学習を得ます。
この学習が、次の「1. アイデア / 戦略」へと繋がり、サイクルが再び回り始めます。
デリバリーの継続的業務改善
よくスクラムなどを導入している開発組織でも、以下のようなことが起きている組織って見かけませんか？
開発（左のループ）のアジリティは高いものの、運用（右のループ）が追いつかず、結果としてビジネス価値の提供速度全体が制約されているケース。
これって結局、運用部分の循環がボトルネックとなり、結局全体としてのデリバリー速度は
ビジネス側の要求する速度が出せない現象のメカニズムです。
そして、この問題を解決するためには、
TOC（制約理論）とECRS原則を組み合わせた継続的な改善プロセス
は極めて重要な業務改善の考えです。
1. 定量的な監視ツール
まず、ボトルネックを客観的に特定するためのツールが必要です。
Findy Team+のように、開発プロセスを可視化するエンジニアリングインテリジェンス
または Value Stream Management (VSM) ツールがこの領域に該当します。
これらのツールが提供するFour Keys (DORAメトリクス) は、デリバリーパフォーマンスを測る上での共通言語と、共通の指標として考えましょう。
決して、１つの指標に複数の意図を混ぜてはいけません。
１つの指標は、たった１つの目的に特化したものにしましょう。
・デプロイの頻度
・変更のリードタイム
・変更障害率
・平均修復時間 (MTTR)
2. TOCとECRSを用いた継続的なボトルネック解消
ステップA：TOCによるボトルネックの特定
目的
デリバリーサイクル全体の中で、最も流れを滞らせている単一の制約（ボトルネック）を
データで客観的に特定する。
メカニズム
TOC（制約理論）は、システム全体のパフォーマンスは、その中で最も弱い部分（制約/ボトルネック）によって決定されるという考え方です。
デリバリーサイクルという一連の業務フローの中で、最も時間がかかっている、あるいは
最も停滞している工程をデータで特定します。
方法
上記のツールを使い、バリューストリーム全体の各工程のリードタイムを計測します。
特に変更のリードタイム（コードがコミットされてから本番にリリースされるまでの時間）
の内訳を詳細に分析します。
事例
①. 上記のツールを使い、変更のリードタイムを計測したところ、平均10日間かかっていることが分かりました。
②. データをドリルダウン分析すると、その内訳は
プルリクエスト作成からマージされるまで」に平均7日間
を要していることが判明しました。
③. この場合、デリバリーサイクル全体のボトルネックは、「コードレビュープロセス」 であると客観的に特定できます。
ステップB：ECRS原則による改善活動
メカニズム
特定されたボトルネック（コードレビュープロセス）に対して、ECRS原則（排除、結合、
交換、簡素化）を適用し、具体的な改善策を立案・実行します。
例として、「コードレビュープロセス」がボトルネックの場合で各工程を見てみましょう。
Eliminate (排除)
課題
全ての変更に対して、形式的なQAチームの承認待ちが発生している。
改善
リスクの低い変更（例: ドキュメント修正）については、QAチームの承認プロセスを排除し、自動テストをパスすればマージ可能にする。
Combine (結合)
課題
レビュー依頼後、レビュワーが手動で静的解析ツールやテストを実行している。
改善
静的解析（SAST）、ユニットテスト、リンターをCIに結合し、プルリクエスト作成時に自動実行されるようにする。フィードバックを即座に得られるようにする。
Rearrange (交換・順序変更)
課題
セキュリティスキャンが、全てのレビュー完了後の最終ステップにあり、そこで問題が見つかると大きな手戻りになる。
改善
時間のかかるセキュリティスキャンを、ビルドや他のテストと並行して実行するように順序を変更する。
Simplify (簡素化)
課題
レビュワーの指名が手作業で、誰に依頼すべきか迷う時間が発生している。
改善
GitHubのCODEOWNERSファイル を活用し、変更箇所に応じてレビュワーが自動で割り当てられるようにプロセスを簡素化する。
ただ、これのためには、そもそものコンポーネントのオーナーがどのチームか？
の割り当てがなされていることが前提条件です。
ステップC：効果の検証と次のボトルネックへの対応
メカニズム
改善策の効果を定量的に測定し、改善サイクルを継続します。ボトルネックは常に移動するため、このプロセスは一度きりではありません。
効果の検証方法
改善策を1ヶ月間運用した後、再び「変更のリードタイム」とその内訳を計測します。
事例
「プルリクエスト作成からマージまで」の時間が平均7日間から2日間に短縮され、
「変更のリードタイム」全体が5日間に短縮されたことをデータで確認します。
これにより、改善が有効であったことが証明されます。
次のボトルネックへ
コードレビューが高速化された結果、今度は「ステージング環境へのデプロイ時間」が新たなボトルネックとして浮かび上がってくるかもしれません。
TOCの原則に従い、改善の焦点をこの新しいボトルネックに移し、再びECRSを適用します。
この時に、同じ戦略のまま継続していては、単なる金の無駄遣いです。
このサイクルを継続的に回し続けることが、変化に強いアジャイルな運用体制を構築する鍵となります。
ちなみに、この
ステージング環境へのデプロイ時間がボトルネックである
ということが長い期間続いてしまうと、その結果ビジネスチャンスを逃すことになります。
これが、マイクロサービス化を検討する大きな動機です。