ダークローンチとは、継続的デリバリーのプラクティスで、新しい機能を一部のエンドユーザーだけにリリースし、その振る舞いやフィードバック情報を収集します。これにより、チームはこれらの新機能が現実に与える影響を理解することができます。これら新機能はユーザーから要求されなかったという意味で、ユーザーにとって予期せぬものであるかもしれません。製品/マーケットに新機能がフィットするかを検証するための最後のステップのひとつです。一度に全ユーザーを対象に機能を開始するより、この方法では、本番前にアプリケーションが計画通りに動作するかどうかを確認するためのテストを行うことができます。

これは、フィードバック・ループのプラクティスで、実際に変更した機能を使ってもらうことでチームは迅速にフィードバックを得ることができます。ダークローンチは、新機能の影響を一部のユーザーに限定することで、安全性を確保するものです。これにより、新機能が生み出すインパクトや、ユーザーとの関わり方について、より深く理解することができるようになります。チームが当初想定していなかったような新しい気づきが表面化することもよくあります。これはプラスにもマイナスにもなり、限定的な公開により、チームは実際の使用状況から結論を導き出し、その機能を広く利用可能にするか、さらに開発するか、中止するかを決定することができます。

本番前に考慮すべき最大のリスクは、ユーザーがアプリケーションに対してどのように反応し、どのように操作するかということです。本番前に、次の3つを自問自答してください。

questions:

1. ユーザーは新機能を見つけることができますか？
2. 彼らはこの変化に気づいていますか？
3. 彼らはそれを知る必要があるのでしょうか？

これらの質問に答え、本稼働の時期が来たと判断したら、（最初のステップでの発見がすべてポジティブであったと仮定して）あとは朝飯前になるはずです（簡単なはずです）。ほとんどの場合、本番稼動するためにしなければならないことは、あなたが書いた機能の古い機能を無効にするだけです。 これは、古いコードを削除するか、あるいは設定で無効にすることによって行うことができます。 本番稼動後は、アプリケーションとユーザーの行動変化を監視し、デプロイが成功したかどうかを確認します。すべてがうまくいっているのなら、自分をほめてあげてください。しかし、たいていの場合、そんなに簡単にはいかないものです。アプリケーションが正しく動作していることを100％保証することはできません。そのため、数日から数週間は古いコードを利用したり実行したりして、バグが発生していないことを確認することになります。

関連プラクティス

• Feature toggles は、既存のプロダクトの中にダークローンチを実装可能にするプラクティスです。
• ダークローンチは、新機能を一部の人にだけ公開するという意味では、A/Bテストと似ていますが、A/Bテストとは異なり、新機能は既存のものを少し調整しただけのものではなく、新機能、通常は全く新しい機能に適用することが可能です。また、A/Bテストは、既存の機能からビジネス上の成果を得るという意味で製品のパフォーマンスを向上させますが、ダークローンチは、新しい機能を追加して市場を拡張する可能性を探ります。
• ダークローンチはカナリアリリースと似ていて、どちらも一部のユーザーだけにある機能に公開するというものです。ダークローンチは、ユーザーが新しい機能にどのように反応し、使用するかを理解することに焦点を当てます。一方で、カナリアリリースは、変更したプロダクトや個々の機能（アーキテクチャで分離して使用できる場合）の技術性能に本来はフォーカスします。