エンジニアリングはバスケットボールに少し似ている

今日は、エンジニアリングチームの目標である成果を届けることに焦点を当て、Snykでそれを実現するために役立っていることを紹介します。開発サイクルの中で実践している、相性がよく、継続的に成果を届けるのに役立つ取り組みがいくつかあります。私たちのアプローチを支える考え方を説明し、実践している継続的デリバリーの手法を紹介します。

常に成果を届ける

成果を届けるとは、ユーザーに価値をもたらすことです。優れたエンジニアリング組織は、常に成果を届けています。「デプロイする」「リリースする」「本番環境に反映する」と呼ぶこともありますが、どれも意味は同じです。優れた技術、効果的なプロセス、そしてチームワークを後押しする環境が、この目標の達成に役立ちます。

大規模な組織では、数か月に一度リリースするのが一般的です。それはサッカーの試合を思い起こさせます。サッカーでは、フィールドを行ったり来たりする時間が長い一方で、ゴールはわずかです。プレーのたびに多くのエネルギーを費やしますが、成功するのはそのうちの一部です。

継続的デリバリーの例えとしてぴったりなのは、バスケットボールです。チームがボールを持ったら、シュートを打って得点するまでに使えるのは24秒。この動きが試合中に何度も繰り返され、当たり前になっていきます。常にゴールを狙い、時間をかけすぎない、目の前のプレーだけを考えます。ここでは時間の制約が極めて重要で、試合の性質にも大きく影響しています。

あらゆる成果を届けよう！

では、どうすれば成果を届けることを習慣にできるでしょうか？今日出社して「2時間以内にすべてリリースしよう！」と宣言したら、本当にうまくいくでしょうか？そうは思えません。

この考え方は、いくつかの原則に集約できます。

1. 障害に立ち向かう - 難しいことを先延ばしにするのは得策ではありません。先延ばしにすると、早くではなく遅くリリースする理由が増えるだけです。リリースに関する難題には、プロセスのできるだけ早い段階から取り組みましょう。バスケットボールで言えば、ディフェンダーに立ちはだかられたとき、後で対応しようと引き返してはいけません。

2. ゴールから目を離さない - 機能は、ユーザーにより大きな価値を届けるための手段であって、ゴールではありません。要件を理解し、機能の価値とコストのバランスが最もよくなる方法を考えましょう。バスケットボールで言えば、ボールを持ったらゴールを見て、シンプルなプレーを選ぶことです。

3. 早く失敗する - どんな機能にもリスクはあります。絶対に失敗しない計画を求めてはいけません。うまくいかないことがあれば、早く気づいてやり直せるようにしましょう。バスケットボールで言えば、24秒後に審判に笛を吹かれるより、シュートを打って外すほうがましです。

優れたマージとは、マージしないこと

すぐに取り組まないと、リリースがさらに難しくなる課題にはどんなものがあるでしょうか？

その一つが、ほかのメンバーの変更とのマージです。マージは厄介なものになり得ます。「コードの共同所有」についてどれだけ語っていても、何十ものコンフリクトがあるファイルを10個も前にしたら、そんな話は吹き飛んでしまいます。バスケットボールの選手を思い浮かべてください。コートを駆け抜けてゴールに向かっていたのに、ボールを脇に置き、シャベルを手にして、土の山を掘り返さなければならなくなったのです。試合の勢いは失われ、次にボールを持ったときには、ゴールではなくシャベルを探すようになるでしょう。

これを避ける方法の一つは、責任範囲を厳密に分け、スプリント中にメンバー同士が同じコードに取り組まないようにすることです。管理された環境ではうまくいくかもしれませんが、私たちが働いているのはそのような環境ではありません。このような厳格な分担はコードの共同所有に反し、エンジニアリングをサイロ化させます。チームの力を引き出せず、個人の成長にもよくありません。避けたほうがよいでしょう。

私たちのアプローチは、作業を小さく分けることです。大量のコンフリクトを解消しなければならない大規模なマージを、最後に経験したときのことを思い出してください。マージまで、どのくらいコーディングしていましたか？数週間？数日？その間にコードが変更されていたとしても不思議ではありません。周囲の人も作業を進めているからです。次の機能で最初の1行を書くときは、先を見据えましょう。どこにシュートを打つのか、つまり、いつ機能ブランチに反映するのかを考えてください。さらに言えば、いつ本番環境に反映するのか。作業に半日以上かかる答えなら、計画を見直しましょう。24秒後に審判の笛を聞くことになってはいけません。

フィーチャーフラグでスピードアップ

Snykでは、個人ブランチで作業し、ブランチの作成、プッシュ、レビュー、マージ、デプロイまでを数時間で完了しています。数日かけて段階的に進める大規模な機能には、フィーチャーフラグを使います。機能が完成していなくても、同じペースで本番環境に反映できます。ここでの前提は、コードそのものが最良のドキュメントであり、アーキテクチャ設計書ではないということです。計画を非公開のブランチにしまっておけば、短期で成果を出せないだけでなく、周りの人がより速く進める助けにもなりません。24秒を忘れずに。

優れたテストは早い段階で行う

リリース時にもう一つ問題になるのがテストです。テストは重要ですが、実施するタイミングによって大きな違いが生まれます。デプロイの数分前に、想定と違うことが分かるのは、完璧とは言えないコードを書いた直後に同じことが分かる場合より、はるかに大変です。バグの原因を探し、バスケットボールの試合を途中で止めるなど、コンテキストの切り替えも発生します。よくありません。

私たちは厳密にTDDを実践しているわけではありませんが、ローカル環境で実行でき、すべてのプルリクエストで動く包括的なテストスイートを整えています。テストを簡単に書けて、すばやく実行できるようにすることを重視しています。簡単そうに聞こえますが、細やかな注意と、何よりも当事者意識が必要です。試合前に靴ひもを結ぶようなものです。それが得点につながると分かっていれば、手間をかけるはずです。

具体的な取り組みを紹介します。新機能にはテストを追加し、本番環境に入り込んでしまった厄介なバグを修正するときも、特にテストを追加します。私たちのGitHubリポジトリはTravis CIと連携しており、すべてのプルリクエストと、developおよびmasterへのマージ後にテストスイートを実行します。developとmasterでテストに成功すると、それぞれdev環境とprod環境への自動デプロイが開始され、継続的デリバリーのサイクルが完了します。コミットメッセージに秘密の文字列を入れれば、マージ後のデプロイを手動で「オプトアウト」できます。「オプトイン」ではなく「オプトアウト」方式なのがとてもよいと思っています。最後に使ったのがいつだったか、思い出せないほどです。

チームワークが鍵

すべてをうまく機能させるのは、素早く成果を届けるというチーム内の合意です。マージを簡単にするのはチーム全員の取り組みであり、テストスイートを支えるのと同じです。時間と労力、そして当事者意識が必要です。チームのリリースプロセスにおける課題について話し合い、段階的に改善していきましょう。全面的な見直しより、すぐに効果が出る改善を優先してください。

私のバスケットボールの例えよりよい例えを思いつきましたか？チームをうまく動かすコツを共有しませんか？Twitterでぜひ教えてください。