「DevOpsをやる」ことを試みるあらゆる組織は、遅かれ早かれJenkinsを導入し、Kubernetesを採用し、Terraformを書くようになりますが、それでもなおリスクの高いデプロイ、過負荷のチーム、そして改善されないMTTR（平均復旧時間）に苦しみ続けます。ツールだけでは、基盤となる誤ったアーキテクチャと文化の問題を解決することはできません。これがThe Five Ideals（5つの理想）の出発点です。この概念フレームワークは、DevOpsを「ツールセット」から切り離し、本来あるべき姿、つまり仕事・チーム・システムを組織する異なる方法として扱います。

概念の起源

5つの理想は、Gene KimがThe Unicorn Project（2019年）で提示しました。この技術小説は、DevOpsの「3つの道」（フロー、フィードバック、継続的学習）を普及させたThe Phoenix Project（2013年）の概念的続編として機能します。The Phoenix Projectが運用側の視点からDevOps変革を描くのに対し、The Unicorn Projectは開発側の視点から同じ物語を語り、5つの理想はまさに、過度に結合したレガシーシステムで単純な変更を試みる開発者のフラストレーションから生まれました。

このフレームワークは3つの道に取って代わるものではありません。プロセス、アーキテクチャ、チーム文化を評価する際のチェックリストとして使いやすい、より具体的な原則へと詳細化しています。

5つの理想、要約

# 理想 一言で
1 局所性とシンプルさ チームが数十の他チームに依存せずシステムを変更できる
2 集中、フロー、喜び 仕事が絶え間ない文脈切り替えなく進む
3 日常業務の改善 配信だけでなく、プロセスを修正するための時間が確保される
4 心理的安全性 ミスを犯し報告しても罰せられない
5 顧客重視 すべての技術的決定は、製品を利用する人々にとっての価値で評価される

1. 局所性とシンプルさ

Locality and Simplicity

この理想は、あるチームが他チームとの調整・交渉・待機を必要とせずに変更を行える度合いを表します。単純な変更が通過するサービス・チーム・依存関係が増えれば増えるほど局所性は低下し、リスク・配信時間・予測不能な障害の可能性が高まります。

設計の悪いマイクロサービスアーキテクチャは、この問題の典型例です。結合度を下げるどころか、コード内の結合をネットワークに移すだけで、1つのビジネス変更が5〜10個の異なるサービス（それぞれ独自のチーム・パイプライン・デプロイ期限を持つ）に触れることを要求します。

低い局所性                    高い局所性
─────────────────                   ────────────────
1つのビジネス変更      →         1つのビジネス変更
   ↓ 8サービスに触れる                   ↓ 1サービスに触れる
   ↓ 5チームが関与                ↓ 1チームが関与
   ↓ 3つのデプロイパイプライン             ↓ 1つのデプロイパイプライン
   ↓ 期限: 3週間                  ↓ 期限: 2日

Enter fullscreen mode Exit fullscreen mode

実践的には、明確に定義された境界づけられたコンテキスト（ドメイン駆動設計）、チケットを必要とせずにセルフサービスを提供するプラットフォームチーム、「この変更で何チームを動かす必要があるか？」を技術設計承認前に尋ねる規律といった具体的なアーキテクチャ決定に翻訳されます。

2. 集中、フロー、喜び

Focus, Flow, and Joy

エンジニアリング業務には、複雑な問題を最初から最後まで解決できる深い集中状態である「フロー状態」が必要です。この状態は中断後、平均15〜20分で到達するとThe Unicorn Projectで引用された研究によります。10分ごとに会議・緊急メッセージ・プロジェクト間の文脈切り替えで中断される開発者は、決してフロー状態に入れず、「一日中働いたのに何も生み出せなかった」という感覚が直接の症状です。

この理想は、この状態を保護するために作業環境（スケジュールだけでなくシステム自体）を設計することです:

  • タスクのために開発者が触れる必要があるシステム数の削減（理想1との直接的な関係）
  • 分単位ではなく日単位で起動する開発・テスト環境、待機によるブロックの回避
  • プロセス中に絶え間ない注意を要求する手動チェックリストの代わりの自動デプロイ
  • 深い作業のための会議なし時間ブロックの保護

期待される結果は生産性だけでなく、文字通りの「喜び」です。官僚主義による消耗ではなく、問題を解決し仕事が顧客に届くことによる本物の満足です。

3. 日常業務の改善

Improvement of Daily Work

Mike RotherはToyota Kataで、この理想をGene Kimが直接引用する一文で要約しています。「日常業務の改善は、日常業務を行うこと自体よりもさらに重要である」。絶え間ない配信プレッシャーの下にあるチームは、手動プロセスや劣悪なツールを「そういうものだ」と受け入れ、根本原因を修正する時間はなく、毎週火消しをするだけになります。

この理想は、以下のために明示的かつ定期的に時間を確保することを要求します:

  • 繰り返しの手動タスクの自動化（例: 手動実行スクリプトで行われるデプロイステップ）
  • 毎週摩擦を生むコードやパイプラインの部分のリファクタリング
  • 毎週同じように回避するのではなく、繰り返し発生する問題の根本原因調査 
# 例: コードだけでなくプロセス技術的負債のための
# スプリント内で確保された時間ブロック
sprint_capacity:
  feature_work: 70%
  bugs: 15%
  improvement_of_daily_work: 15%

Enter fullscreen mode Exit fullscreen mode

この保護された時間がなければ、チームはGene Kimが「プロセス負債」と呼ぶものを蓄積します。これはコードにおける技術的負債に相当する運用摩擦です。

4. 心理的安全性

Psychological Safety

ハーバード大学の研究者Amy Edmondsonによって作られ、GoogleのProject Aristotleによって高パフォーマンスチームの最も決定的な要因として確認された用語です。専門家がミスを認め、上級者の決定に疑問を呈し、本番環境の問題を提起することが報復を恐れずに行えることを意味し、これが問題が安価に修正できる早い段階で報告されるか、重大インシデントになるまで隠されるかを決定します。

DevOpsチームでこの理想に最も関連する実践は非難なきポストモーテムです。インシデント後分析の目的は、誰が間違ったかを特定するのではなく、その人的エラーが損害を引き起こすことをシステムが許した原因の連鎖を理解することです。

責任追及ポストモーテム 非難なきポストモーテム
「レビューなしでデプロイしたのは誰？」 「なぜパイプラインが必須レビューなしのデプロイを許可したのか？」
個人への罰に焦点 システムの修正に焦点
類似インシデントが次に隠される 類似インシデントが次に即座に報告される

心理的安全性は品質基準の欠如ではありません。ミスが起きたとき、それが個人の罰の理由ではなくチーム全体の学習になる保証です。

5. 顧客重視

Customer Focus

最後の理想は、他のすべてのためのタイブレーカーです。すべての技術的決定は、製品を利用する人々にとっての価値で評価される必要があります。技術的解決策の優雅さやチームの技術的嗜好ではありません。Gene Kimは、顧客に知覚可能な価値を生まないエンジニアリング時間の消費を「技術的虚栄心の仕事」（vanity engineering work）と呼びます。より新しいスタックを採用するためだけに安定したサービスを書き換える、誰も使わないルートを最適化する、仮定的な要件のための抽象化レイヤーを構築する、などです。

この理想に導かれるチームは、技術的配信をビジネス結果に結びつけるメトリクスで自らの仕事を測定する傾向があります。アップタイムやデプロイ速度だけでなく、保持率、満足度、顧客が価値を認識するまでの時間です。

5つの理想がDevOpsプラクティスにどのように結びつくか

理想 実践での出現箇所
局所性とシンプルさ マイクロサービスアーキテクチャ、境界づけられたコンテキスト、インフラストラクチャのセルフサービス
集中、フロー、喜び 自動化されたCI/CDパイプライン、一時的な開発環境、会議の削減
日常業務の改善 自動化とプロセス負債のためのスプリント内確保時間
心理的安全性 非難なきポストモーテム、判断のないコードレビューの文化
顧客重視 ビジネスメトリクスによる優先順位付け、ユーザー知覚信頼性の指標としてのMTTR削減

5つが一緒に現れるのは偶然ではありません。自動デプロイパイプライン（理想2）は、誰かがそれを構築するための時間を確保したから存在します（理想3）。そしてその時間がうまく投資されるのは、背後のアーキテクチャが局所的な変更を可能にする場合です（理想1）。理想は相互に強化し合います。1つでつまずくと他のものが侵食される傾向があります。

5つの理想を適用するための良いプラクティス

  • 理想を文化だけでなくアーキテクチャのチェックリストとして使用する。新しいサービスを設計する際、そのサービスで単純な変更を行うために何チームが必要になるかを尋ねる
  • velocityだけでなく中断を測定する。1日の文脈切り替え回数は、配信されたストーリーポイントと同程度に関連する指標である
  • 日常業務改善の時間を計画で保護する。「時間が余れば」ではなく、固定パーセントのキャパシティで
  • 自社のポストモーテムが本当に非難なきものかを監査する。「なぜシステムがこれを許可したのか？」より先に「誰がこれをしたのか？」という質問が出る場合、心理的安全性は紙の上だけに存在する
  • 理想5の質問で技術的バックログをレビューする。「これが顧客にどのような価値を生むか？」への回答が曖昧な場合、それは技術的虚栄心の仕事の兆候である

結論

5つの理想はステップバイステップの実装フレームワークではありません。そしてこれがまさにその強みです。企業が正しいツールをすべて購入した後でも、なぜDevOps変革が停滞したのかを診断するレンズとして機能します。チームがKubernetes、CI/CDパイプライン、完全な可観測性を持っていても、チーム間の高い依存を強いるアーキテクチャ（理想1）や、ミスを恐れて問題がインシデントになるまで隠される場合（理想4）、デプロイは遅くリスクの高いままです。

次のツールを購入する前に、自チームの現在のプロセスに対して5つの理想を振り返る価値があります。今日最も弱いものが、ほぼ常にDevOps変革が期待される結果を配信していない理由への答えです。

参考文献

  • Kim, Gene. The Unicorn Project (2019) — IT Revolution Press
  • Kim, Gene; Behr, Kevin; Spafford, George. The Phoenix Project (2013) — IT Revolution Press
  • Rother, Mike. Toyota Kata (2009) — McGraw-Hill
  • Edmondson, Amy. The Fearless Organization (2018) — Wiley