本当に価値のある1つのアプリケーションから始める
チームが所有するすべてのものをリストアップしたとしよう。アプリケーション、データベース、インフラコンポーネント、スクリプト、cronジョブ。1週間かけて棚卸しをしたかもしれないし、ミーティング中にホワイトボードに走り書きしただけかもしれない。今、そのリストを眺めながら、こう自問している。「どこから始めればいいんだ？」
ここで多くのチームが動けなくなる。間違ったものを選ぶことを心配する。もっと重要なものを見逃すことを心配する。選んだものが目に見える成果を生まないことを心配する。その結果、分析を続け、議論を続け、行動を先延ばしにする。
秘訣は完璧な開始点を選ぶことではない。秘訣は、成功する可能性が高く、かつ成功したときに注目される可能性が高いものを選ぶことだ。
インフラやデータベースではなく、アプリケーションから始める
インフラは基礎的なものに感じられるため、そこから始めたくなる。あるいは、データベースの変更は怖いので、データベースから始めたくなる。しかし、最適な開始点はアプリケーションだ。
これはアプリケーションがより重要だからではない。アプリケーションが最も頻繁に変更され、その変更がユーザーに最も見えやすいからだ。アプリケーションのパイプラインを構築すると、結果は即座に現れる。ビルドが自動化される。すべての変更でテストが実行される。デプロイが、午後10時に3人でビデオ通話を必要とする手動の儀式ではなくなる。
その経験が自信を築く。パイプラインが動作するのを目の当たりにし、チームがそれを信頼し始めるのを感じる。そして、その自信こそが、データベースマイグレーションやインフラプロビジョニングといったより難しい部分に取り組む前に必要なものだ。
適切なアプリケーションを選ぶための3つの基準
インベントリを見て、以下の3つの条件をすべて満たすアプリケーションを1つ選んでほしい。
次のフローチャートは、3つの基準を判断するプロセスを示している。
第一に、そのアプリケーションが活発に開発されている、または頻繁に変更されていること。 誰も触らないアプリケーションからは何も学べない。実際の変更がパイプラインを流れることで、本当の問題が見つかる。数ヶ月に一度しか更新されないアプリケーションでは、学習するよりも待つ時間のほうが長くなる。
第二に、そのアプリケーションに実ユーザーがいること。 プロトタイプではない。誰かのノートパソコンで動くPoC（概念実証）ではない。実ユーザーがいるということは、実際のインパクトがあるということだ。パイプラインが機能すれば、ユーザーはより早くアップデートを受け取れる。パイプラインがデプロイ前にバグをキャッチすれば、ユーザーは障害を経験しない。チームはその違いを実感し、その実感が次のフェーズの作業をステークホルダーに売り込む力になる。
第三に、そのアプリケーションを所有するチームが協力的であること。 これが最も重要な基準だ。どんなに優れた技術計画があっても、チームが多忙で、 burnout 状態で、あるいは単に興味がなければ、パイプラインは定着しない。ある程度の余力と好奇心を持つチームを見つけ、一緒に作業しよう。すでに苦戦しているチームに新しいプロセスを押し付けてはいけない。
迅速に決定する
選定プロセスは、1～2回のディスカッションセッションで終わらせるべきだ。インベントリを集める。どのアプリケーションが最も頻繁に変更されているか確認する。チームと話す。新しいことに取り組む余裕があるか尋ねる。そして決定する。
これを何週間も引き延ばしてはいけない。分析麻痺は進歩の敵だ。まともな候補を選んで構築を始めるほうが、1ヶ月かけてすべての選択肢を分析して何も得られないよりはるかにマシだ。
このアプリケーションがゴールデンパスになる
アプリケーションを選んだら、それがゴールデンパスになる。ゴールデンパスとは、チームが文書化し、構築し、他のすべての参照点として扱う、最初の標準化されたデリバリーパイプラインのことだ。
パイプライン、テスト、デプロイに関するすべての決定が、まずここに適用される。ビルドスクリプトはどう構成するか？ CIでどのテストを実行するか？ シークレットはどう扱うか？ ステージングと本番ではどうデプロイを分けるか？ これらすべての質問が、この1つのアプリケーションに対して答えられる。
ゴールデンパスがうまく機能するようになれば、動作するテンプレートが手に入る。次のアプリケーションは同じパターンに従える。その次も。そして、データベース変更用にパターンを適応させ、インフラ用に適応させる。毎回ゼロから始める必要がないため、各ステップはより簡単になる。
ゴールデンパスは特別ではない
ゴールデンパスが何でないかを理解することが重要だ。これは、このアプリケーションが他より重要だという宣言ではない。永続的な特権でもない。リスクを最小限に抑え、成功の可能性を最大限に高めるために設計された、意図的な実験なのだ。
何か問題が発生しても、被害は1つのアプリケーションに限定される。ある決定が間違っていると判明しても、1つのアプリケーションで修正し、そこから学ぶ。その教訓は他のすべてに適用される。
テストベッドだと考えてほしい。パイプラインを構築するチームの能力、自動化に関する仮定、そしてアプローチが機能することをスケールする前に証明するためのテストベッドだ。
全員の認識を合わせる
パイプラインコードを1行も書く前に、どのアプリケーションがゴールデンパスで、なぜそれが選ばれたかを全員が理解していることを確認しよう。この合意があれば、後々の混乱を防げる。誰かが「なぜ他のアプリケーションにまだ手をつけていないのか？」と尋ねても、答えは明確だ。「まずこのアプリでパターンを実証し、その後残りに適用する」と。
それを文書化し、見える場所に置き、スタンドアップで言及しよう。目的は官僚主義を作ることではない。目的は、「なぜこれではなくあれをやっているのか？」という疑問が勢いをそぐのを防ぐことだ。
始める前の実用的チェックリスト
- 活発に開発され、実ユーザーがおり、協力的なチームがいる1つのアプリケーションが選ばれている
- 決定が文書化され、チームと共有されている
- 全員がこれがゴールデンパスであり、永続的な優先順位ではないことを理解している
- アプリケーションを所有するチームが協力に同意している
- 最初の動作するパイプライン（完璧ではなく、動作するもの）の大まかなタイムラインが設定されている
具体的な takeaways
頻繁に変更され、実ユーザーがおり、一緒に働きたいチームがいるアプリケーションを1つ選べ。そのアプリケーションのパイプラインを最初に構築しろ。動くようにしろ。そこから学べ。そして次のアプリケーションでも同じことを繰り返せ。それが、所有するすべてのもののリストから、実際にデリバリーするシステムへと移行する方法だ。