パイプライン構築の前に必要な3つの要素
数ヶ月前、あるチームが新しいCI/CDパイプラインに興奮して計画会議に臨んでいた。彼らは数週間かけてツールの設定、YAMLファイルの作成、自動テストの構築に取り組んできた。パイプラインはグリーン。デプロイは高速。全員が良い気分だった。
そこで誰かが尋ねた。「これで実際に何を達成しようとしているのか？」
会議室は静まり返った。リリースを高速化したいと言う人もいれば、バグを減らしたいと言う人もいた。手作業を減らしたいと言う人も数名いた。誰も同じ答えを持っていなかった。パイプラインは動作していたが、成功の定義を説明できる者はいなかった。
そのチームは、3つの根本的な問いに答える前にパイプラインを構築してしまった。そして、どれだけ優れたエンジニアリングが施されていても、そのパイプラインは正しい問題を解決していなかったのだ。
なぜから始める：ビジネス成果
すべてのエンジニアリング活動には目的地が必要だ。目的地がなければ、チームは漂流する。誰も求めていない機能を構築し、重要でないプロセスを最適化し、ダッシュボード上では良く見えるが実際の成果とは無関係な指標を測定する。
ビジネス成果とは、機能リストではない。技術仕様書でもない。それは、製品を使う人や対価を払う人にとって重要な、測定可能な結果である。
ビジネス成果の例：
- 新規ユーザーが2分以内に登録を完了できる。
- 月次レポートの生成時間が3日から1時間に短縮される。
- ログイン問題に関するカスタマーサポートチケットが40%減少する。
これらが何でないかに注目してほしい。「OAuthを実装する」や「Kubernetesに移行する」ではない。それらは技術的な解決策だ。ビジネス成果は、実現したい効果を記述するものであり、その実現方法ではない。
チームが明確なビジネス成果を持っていれば、意思決定は容易になる。この新機能を追加すべきか、それとも安定性の問題を修正すべきか？ビジネス成果を見よ。どちらの選択肢が目標に近づくのか？このアンカーがなければ、各チームは異なる成功の定義を持つ。フロントエンドチームはページ読み込み時間を測定し、バックエンドチームはAPIレイテンシを測定し、プラットフォームチームはアップタイムを測定する。誰もが忙しく、誰も一致団結していない。
フローをマッピングする：バリューストリーム
達成したいことが決まったら、アイデアからユーザーに届くまでの実際のワークフローを理解する必要がある。これがバリューストリームだ。
バリューストリームはCI/CDパイプラインとは異なる。パイプラインは技術的な実装である。バリューストリームは、コードを書き始めてから、テスト、ビルド、レビュー、承認、デプロイ、検証を経て、最終的にユーザーが価値を得るまでの全行程である。
バリューストリームには、パイプラインがしばしば無視するものも含まれる：
- コードレビューと承認プロセス
- 手動検証手順
- ハンドオフ間の待機時間
- 問題発生時のフィードバックループ
- チーム間のコミュニケーションオーバーヘッド
バリューストリームのマッピングとは、「コードが書かれてからユーザーが価値を得るまで」に発生するすべてのステップをリストアップすることだ。各ステップについて、3つの質問を投げかける：
- このステップは何を生み出すのか？
- 誰が関与しているのか？
- それが価値を付加しているかどうかをどう判断するのか？
多くのチームは、バリューストリームの半分のステップがビジネス成果に直接貢献していないことに気づく。それらは「昔からそうやってきたから」存在している。誰も参加しない週次の承認ミーティング。形だけの手動承認。自動化パイプラインと同じチェックを実行するテストフェーズ。
これらのステップは無駄だ。品質を向上させることなく、デリバリを遅らせる。バリューストリームでそれらを見つけたら、2つの選択肢がある：削除するか、再設計するか。
オーナーシップを割り当てる：チーム
目的地と地図ができた。次に必要なのは、動く人々だ。
チームの要素は、バリューストリームの各部分を誰が所有するかに関するものだ。これは組織図や報告ラインの問題ではない。責任の明確さの問題である。
バリューストリームの各ステップには、明確なオーナーがいるべきだ。そのオーナーは以下を把握している：
- 何を生み出す責任があるか
- 自分のアウトプットがビジネス成果にどう結びつくか
- 誰が自分の作業に依存しているか
- 自分の仕事をするために他者から何が必要か
責任が不明確だと、ギャップが生じる。アプリケーションチームはデプロイはインフラチームの仕事だと考え、インフラチームはデプロイはアプリケーションチームの仕事だと思う。新しいバージョンがステージングに何週間も置かれたままになるのは、本番への最終プッシュのオーナーシップを誰も取らないからだ。
組織によってチーム構成は異なる。開発者、QA、運用を1つのグループに含むフィーチャーチームを採用する組織もあれば、アプリケーションチームにインフラとツールを提供する別個のプラットフォームチームを持つ組織もある。どちらのアプローチが本質的に優れているわけではない。重要なのは、バリューストリームのすべての部分に名前の付いたオーナーがおり、そのオーナーが自分の作業がビジネス成果にどう貢献するかを理解していることだ。
3つの要素のつながり
ビジネス成果、バリューストリーム、チームは独立しているわけではない。それらはシステムを形成する。
以下の図は、これら3つの要素がどのようにシステムを形成し、パイプライン設計を導くかを示している。
- ビジネス成果は方向性を与える。これがなければ、チームは個人的な好みや局所的な最適化に基づいて意思決定を行う。
- バリューストリームは経路を示す。これがなければ、チームは遅延や無駄がどこに潜んでいるかを見極められない。
- チームは実行力を提供する。明確なオーナーシップがなければ、作業は隙間から落ちていく。
これらのうち1つが欠けると、他も機能しなくなる。ビジネス成果を知らないチームは、間違ったものを最適化する。マッピングされていないバリューストリームはボトルネックを隠す。明確な責任を持たないチームは、ハンドオフの遅延と責任のなすり合いを生み出す。
これら3つの要素が明確になって初めて、プラットフォーム、パイプライン、デプロイ戦略について議論を始めるべきだ。ツールと自動化はプロセスを加速する。しかし、プロセス自体が誤って調整されているなら、加速は問題をより速く悪化させるだけだ。
構築前のクイックチェック
次のパイプラインを設計したり、次のデプロイツールを選んだりする前に、チームでこの短いチェックリストを確認してほしい：
- チーム全員が、自分たちが取り組んでいる上位1〜2のビジネス成果を挙げられますか？
- コードからユーザーに至るまでのバリューストリーム全体を、手動ステップや待機時間も含めてマッピングしましたか？
- そのバリューストリームの各ステップに明確なオーナーがいますか？
- 各オーナーは、自分の作業がビジネス成果にどうつながるかを説明できますか？
いずれかの答えが「いいえ」なら、まずそれを修正しよう。パイプラインは後回しで構わない。
まとめ
パイプラインはツールだ。デプロイ戦略は手法だ。どちらも、何を達成しようとしているのか、そのために作業がどのように流れるのか、そしてそのフローの各部分に誰が責任を持つのかという明確さの代わりにはならない。
ビジネス成果から始めよ。バリューストリームをマッピングせよ。明確なオーナーシップを割り当てよ。そして、そのシステムに奉仕するパイプラインを構築せよ。逆にしてはいけない。