Harness は CI/CD・Feature Flags・セキュリティテスト・クラウドコスト管理・カオスエンジニアリングなどを統合した AI ネイティブな Software Delivery Platform です。
Harness を導入すれば DevOps は確実に改善します。しかし、すべての組織が今すぐフルプラットフォームを採用できるわけではありません。大事なのは Harness が「なぜ」効果的なのか を理解し、その背後にある原則を既存の開発フローに取り入れることです。
この記事では、Harness が体現する DevOps の原則を 10 個抽出し、それぞれ Harness なしで OSS ツールや既存ツールで実現する方法 を紹介します。
1. デプロイとリリースを分離する（Progressive Delivery）
Harness の思想: コードを本番にデプロイすることと、ユーザーに機能をリリースすることは別のイベントである。
Harness の Feature Flags モジュールは、デプロイ済みのコードに対してフラグで段階的にリリースを制御します。1% → 10% → 50% → 100% と拡大し、問題があれば即座にフラグを OFF にできます。ロールバックではなく「フラグの切り替え」で済むため、数秒で復旧します。
Harness なしで実現する方法
- Feature Flag ライブラリを導入する: Unleash（OSS）、Flagsmith（OSS）、または自前の設定駆動フラグ
- トランクベース開発を採用する: 未完成の機能はフラグの裏に隠してマージし、長寿命ブランチを排除する
- 段階的ロールアウトを定義する: 「全員に一斉リリース」をデフォルトにしない。ロールアウト率とメトリクスゲートを明示する
問い: 直近のリリースで「デプロイ = リリース」になっていなかったか？
2. デプロイを「イベント」にしない（安全なデプロイ戦略）
Harness の思想: デプロイが怖いなら頻度が下がり、変更が大きくなり、さらに怖くなる悪循環に陥る。デプロイを退屈で安全なものにせよ。
Harness はカナリア、Blue-Green、ローリングの各戦略をパイプラインの設定だけで切り替えられます。Harness のドキュメントは「100% に一斉デプロイする Big Bang は非推奨」と明言しています。
Harness なしで実現する方法
| 戦略 | OSS ツール |
|---|---|
| カナリアデプロイ | Argo Rollouts、Flagger |
| Blue-Green | Kubernetes の Service 切り替え、AWS ALB のターゲットグループ |
| ローリング | Kubernetes のネイティブ Rolling Update |
原則: トラフィックの 100% に同時にデプロイしない。最初は一部のノードやトラフィックに限定し、メトリクスを確認してから拡大する。
問い: 現在のデプロイ戦略は「一斉に全台入れ替え」になっていないか？
3. デプロイの成否をメトリクスで判定する（Continuous Verification）
Harness の思想: デプロイの成功は「プロセスがエラーなく完了した」ことではなく、「システムが正常に動いている」ことで判定すべき。
Harness の Continuous Verification は、デプロイ後に APM（Datadog、Prometheus など）に接続し、エラー率やレイテンシがベースラインから逸脱していないかを ML で判定します。異常を検知したら自動ロールバックします。
Harness なしで実現する方法
- SLO を定義する: すべてのサービスに対して p99 レイテンシ、エラー率の閾値を明文化する
- デプロイ後の自動検証をパイプラインに組み込む: デプロイ完了後に一定時間（bake time）メトリクスを監視し、閾値を超えたらロールバック
- ツール: Argo Rollouts の Analysis + Prometheus、Flagger + メトリクスプロバイダ
問い: デプロイ後の「成功」を何で判定しているか？ kubectl rollout status だけで終わっていないか？
4. パイプラインをコードとして管理する（Pipeline as Code）
Harness の思想: パイプラインが Git に入っていなければ、それはインフラではなく属人知識である。
Harness のパイプラインは YAML で定義し、Git リポジトリに保存します。パイプラインの変更もコードレビューの対象になり、履歴が残り、再現可能になります。
Harness なしで実現する方法
- すべての CI/CD 設定を YAML/コードで管理する: GitHub Actions、GitLab CI、Tekton Pipelines
- GUI でのパイプライン定義を避ける: GUI で作った設定は Export して YAML に変換する
- パイプラインの変更にもコードレビューを適用する:
*.ymlの変更も PR 必須にする - テンプレートを共有リポジトリで管理する: チーム間で再利用可能なパイプライン定義を一元管理する
問い: パイプラインの設定は Git に入っているか？変更にレビューが入る仕組みになっているか？
5. Git を唯一の真実の源とする（GitOps）
Harness の思想: 本番環境のあるべき状態は Git に宣言されるべきであり、マージが即デプロイトリガーになるべきである。
Harness GitOps は Argo CD ベースで、以下を実現します:
- Pull 型デプロイ: CI がプロダクションに push するのではなく、クラスタ内のエージェントが Git の状態を pull する。プロダクションへの書き込み権限を CI に持たせない
- ドリフト検知: 手動変更（
kubectl editなど）を検知し、Git の宣言状態に自動修復する - Git が監査証跡: すべての変更が commit として残り、誰が・いつ・なぜ変更したかが追跡可能
Harness なしで実現する方法
- Kubernetes 環境: Argo CD または Flux を導入する
- 非 Kubernetes 環境: Terraform / Pulumi の state を Git 管理し、PR マージで
applyを実行する - 原則: 本番への変更は手動コマンドではなく、必ず Git の PR 経由で行う
問い: 本番環境に kubectl edit や手動の管理画面操作で直接変更を入れていないか？
6. ガバナンスをコードで自動化する（Policy as Code）
Harness の思想: コンプライアンス要件が遅延を生むのは、要件自体が悪いのではなく、人間の承認キューがボトルネックだからである。ポリシーをコードにすれば、人間を待たずに自動で強制できる。
Harness は Open Policy Agent（OPA） を統合し、パイプラインの保存・実行時にポリシーを自動評価します。例:
- 「本番デプロイには必ず承認ステップが必要」
- 「金曜 17 時以降のデプロイは禁止」
- 「コンテナイメージは承認済みレジストリからのみ」
Harness なしで実現する方法
- OPA / Conftest を CI パイプラインに組み込む: Kubernetes マニフェスト、Terraform プラン、Dockerfile をポリシーで検証する
- ブランチ保護ルールと Required Status Checks を活用する: 軽量なポリシー強制として
- コンプライアンス要件をテストケースとして記述する: 「ドキュメントに書いてある」ではなく「CI で自動チェックされる」状態にする
問い: デプロイ前のチェックは人間の承認待ちだけか？自動化できるチェックを人手で回していないか？
7. セキュリティを左にシフトする（DevSecOps）
Harness の思想: 本番で見つかった脆弱性の修正コストは、開発時に見つけた場合の 10〜100 倍。検出は可能な限り左（早期）に寄せよ。
Harness STO は SAST・SCA・コンテナスキャン・シークレット検知・IaC スキャンをパイプラインのステージとして組み込みます。50 以上のツールの結果を正規化・重複排除し、クリティカルな脆弱性を検出したらデプロイをブロックします。
Harness なしで実現する方法
| カテゴリ | OSS ツール |
|---|---|
| SAST（静的解析） | Semgrep、CodeQL |
| SCA（依存関係スキャン） | Snyk、Dependabot、OSV-Scanner |
| コンテナスキャン | Trivy、Grype |
| シークレット検知 | GitLeaks、truffleHog |
| SBOM 生成 | Syft、CycloneDX |
最低ライン: これらのスキャンを CI の Required Check として設定し、Critical / High の検出時にマージをブロックする。
問い: セキュリティスキャンはリリース後の監査で初めて実行されていないか？CI パイプラインに組み込まれているか？
8. テストを賢く選択する（Test Intelligence）
Harness の思想: 全テストを毎回実行するのは無駄である。変更に関連するテストだけを実行すれば、安全性を保ちつつサイクルタイムを劇的に短縮できる。
Harness CI の Test Intelligence はコールグラフ解析でコード変更の影響範囲を特定し、関連テストだけを実行します。Kafka で 37 分 → 3 分、RocketMQ で 39 分 → 8 分という事例が報告されています。
Harness なしで実現する方法
| 言語/フレームワーク | ツール |
|---|---|
| Python | pytest-testmon |
| JavaScript | Jest --changedSince |
| モノレポ全般 | Bazel の依存関係追跡、Nx の affected |
| Go | go test + 変更パッケージの特定スクリプト |
最低ライン: テストスイートを unit / integration / e2e に分離し、feature ブランチでは unit + 関連 integration のみ実行、main マージ時にフルスイートを実行する。
問い: CI で毎回全テストを実行して 30 分以上待っていないか？
9. 開発者セルフサービスを実現する（Platform Engineering）
Harness の思想: プラットフォームチームがボトルネックになるのは、標準がないからではなく、標準に従う道が難しいからである。正しい道を最も簡単な道にせよ。
Harness IDP（Internal Developer Portal）は Backstage ベースで、サービスカタログ・ゴールデンパステンプレート・スコアカードを提供します。開発者はチケットを切らずにセルフサービスで環境やパイプラインを構築できます。
Harness なしで実現する方法
- サービスカタログを整備する: Backstage（OSS）を導入するか、最低限 README のインデックスを整備する
- ゴールデンパステンプレートを作る: Cookiecutter や Yeoman で新規サービスのスキャフォールディングを用意し、CI/CD 設定・監視設定・セキュリティスキャンを含める
- 環境プロビジョニングを自動化する: 「JIRA チケットで DB を依頼」を「セルフサービスワークフローでガードレール付きプロビジョニング」に置き換える
問い: 新しいサービスを立ち上げるとき、何日チケット待ちが発生しているか？
10. DORA メトリクスを計測する（Measure What Matters）
Harness の思想: ストーリーポイントやコード行数ではなく、ソフトウェアデリバリーシステムの実際のパフォーマンスを測定せよ。
Harness はプラットフォーム全体で DORA メトリクスを計測し、可視化します。
| メトリクス | Elite の基準 |
|---|---|
| デプロイ頻度 | 1 日複数回 |
| 変更のリードタイム | 1 時間未満 |
| 平均復旧時間（MTTR） | 1 時間未満 |
| 変更失敗率 | 0〜15% |
Harness なしで実現する方法
- デプロイ頻度: CD パイプラインのログから取得
- リードタイム: Issue 作成 → PR マージ → デプロイ完了のタイムスタンプを連携
- MTTR / 変更失敗率: デプロイイベントとインシデント管理（PagerDuty、OpsGenie）を紐付け
- ツール: Four Keys（Google OSS）、LinearB、Swarmia
問い: 今のチームのデプロイ頻度とリードタイムを即答できるか？
まとめ：Harness の統一哲学
これら 10 の原則を貫く Harness の哲学は一つです。
正しいことを、最も簡単にやれるようにする。
従来の DevOps ツールチェーンは、ベストプラクティスを「可能」にはするが「簡単」にはしない。カナリアデプロイは実装に専門知識が要り、セキュリティスキャンは別チームが別ツールで回し、ガバナンスは人間の承認キューで律速する。Harness はこれらを一つのプラットフォームに統合することで摩擦を取り除きます。
しかし、プラットフォームを導入せずとも 原則そのもの は取り入れられます。
| # | 原則 | 核心 |
|---|---|---|
| 1 | Progressive Delivery | デプロイとリリースを分離する |
| 2 | 安全なデプロイ戦略 | 100% 同時デプロイを避ける |
| 3 | Continuous Verification | メトリクスでデプロイ成否を判定する |
| 4 | Pipeline as Code | パイプラインを Git で管理する |
| 5 | GitOps | Git を唯一の真実の源にする |
| 6 | Policy as Code | ガバナンスを自動化する |
| 7 | DevSecOps | セキュリティを左にシフトする |
| 8 | Test Intelligence | テストを賢く選択する |
| 9 | Platform Engineering | 開発者セルフサービスを実現する |
| 10 | DORA Metrics | デリバリーのパフォーマンスを計測する |
まず自チームの現状を上記 10 項目で診断し、最もギャップが大きい 1〜2 項目から着手することをおすすめします。
以上、Harness を導入せずともそのエッセンスを既存の開発フローに取り入れる方法をまとめた、現場からお送りしました。