なぜデプロイとロールアウトの分離が重要なのか　柔軟な切り替えを可能にしてくれる「Feature Flags」

佐藤氏の自己紹介

佐藤丈生氏（以下、佐藤）：みなさん、こんにちは。

会場：こんにちは。

佐藤：ありがとうございます。「AWS AppConfigで低リスク・低ストレスなロールアウトを実現した話」ということで始めていきたいと思います。よろしくお願いします。

まず自己紹介をします。株式会社カミナシのソフトウェアエンジニア、佐藤と申します。2022年の12月にカミナシにジョインして、現在では日々開発に勤しんでいます。よろしくお願いします。

はじめに軽く会社とプロダクトについて紹介します。弊社カミナシは「ノンデスクワーカーの才能を解き放つ」というミッションの下、事業を行っています。ノンデスクワーカーというのは、例えば食品製造の工場で実際に食品を作っている方とか、ホテルとかで客室の清掃を行っている方とかのことを指しています。

弊社のサービスですが、現場DXプラットフォーム「カミナシ」というサービスを提供しています。先ほど紹介したようなノンデスクワーカーの方々が、日々紙のチェックリストとか点検表とかで行っているチェック業務や点検業務みたいなものをタブレットでできるようにして、デジタル化、DXを推進していくようなプロダクトとなっています。

（スライドを示して）こちらが実際に、現場の方が使われているようなイメージになります。こちらが、実際のUIとかのイメージです。

本セッションの対象者とゴール

佐藤：ここから本題に入っていきます。今日のセッションの対象者とゴールに関してなんですが、今回のセッションの対象者はタイトルにもあるとおり、「AWS AppConfig」とか、Feature Flagsに興味がある方を対象と考えています。

本日のセッションのゴールとして設定しているのが、今後Feature Flagsとかそういった仕組みを設計しようかなと思った時に、AWS AppConfigを設計の選択肢の1つにできることをゴールにしていきたいと思っています。

なので、背景となるFeature Flagsの技術の概要や、その必要となる理由とか、AWS AppConfigならではの特徴とか、それを使ったイメージについて主に話します。逆にFeature Flagsに関する網羅的な説明とか、詳細な仕様に踏み込んだ説明とかは行わないので、ご了承いただければと思います。

本日のアジェンダです。3章の構成になっていて、第1章で「Feature Flagsはなぜ必要なのか？」という、前提となる話をさらっとします。2章では「AWS AppConfigでFeature Flagsの仕組みを整備した話」というかたちで、AppConfigの話をしていこうと思います。3章で、そのようなことをして得られた学び、所感のようなことを話そうと思っています。

なぜデプロイとロールアウトの分離が重要なのか

佐藤：ではさっそく、1章の「Feature Flagsはなぜ必要なのか」という話をしていきたいと思います。

まずは、デプロイとロールアウトの分離の重要性について話していきます。デプロイとロールアウトといった時に、もしかしたらロールアウトという言葉にあまり耳になじみのない方もいるかもしれないので補足すると、新規で開発した機能があるとします。その新規で開発した機能をユーザーが利用可能な状態にすることを、ロールアウトと言ったりします。要するに、ユーザーに機能を開放することですね。

ちなみに本セッションでは、デプロイとの区別を明確にするために、ロールアウトという言葉を使おうと思います。巷間では、よく「デプロイとリリースの分離」という言い回しが使われることがあるんですが、デプロイとロールアウトっていう区別を明確にしたいので、このセッションでは意図的にリリースという言葉は使わず、ロールアウトという言葉を使っています。

では、デプロイとロールアウトが分離した状態を、もうちょっと具体的にイメージしていきたいと思います。（スライドを示して）下のほうに2つほど例を書いています

つまるところ、デプロイはされているんだけれど、新規で開発した機能はユーザーには公開されていない状態だとか、デプロイをしていなかったとしても、新規で追加した機能などの公開や非公開の状態が切り替えられる。そういった状態のことを、デプロイとロールアウトが分離した状態と考えていただければと思います。

では次に、なぜこのデプロイとロールアウトの分離が重要なのかという話を、開発の視点、ビジネスの視点で簡単に説明していきたいと思います。

開発の視点では、我々のようなSaaS企業でWebアプリケーションなんかを提供しているような人にとって、おそらく一番直感的にわかりやすいと思うのが、CI/CDとか継続的デプロイメントの文脈だと思います。

例えば、メインブランチがあって、そこで頻繁に修正をマージしたい。さらにそのメインブランチから高頻度で運用環境にデプロイしたいというような状況を考えます。そういった状況の中、一方で、機能追加とかに関してはある程度作る期間を要するような機能追加はやっていく必要があります。

そういった状況を考えた時に、デプロイはするんだけれども、ロールアウトはされていないという状況を作れることは、非常に重要になってくるわけです。

続いてビジネスの視点になります。これも経験したことがある方がいるかなとは思うんですが、開発チームが機能をデプロイしたいタイミングとビジネス施策で機能をユーザーに公開したいタイミングって、異なることが多いかなと思っています。こういうケースに対応するためにも、デプロイとロールアウトが切り分けられていることは、非常に重要になってくるわけです。

コードを修正せずにシステムの振る舞いを変える技術、Feature Flags

佐藤：じゃあ、デプロイとロールアウトの分離をどうやって実現するのかという話に入っていきたいと思います。

「Feature Flagsとは？」というところから話を始めるんですが、こちらはコードを修正せずにシステムの振る舞いを変える技術と言うことができます。ちなみに、martinfowler.comというサイトがあって。こちらにFeature Flagsの網羅的な説明があって、そこから引用した言い回しです。Feature Flagsに関して網羅的な情報が欲しい方は、こちらのサイトを見てもらえるといいかなと思っています。

ちなみに、このスライドは後から公開される予定なので、興味のある方は後からスライドを見てもらえればと思います。

Feature Flagsの実装でデプロイとロールアウトの分離が実現できる

佐藤：すみません、ちょっと脱線しちゃったんですが、Feature Flagsに関してもうちょっと具体的にイメージしていきたいと思います。（スライドを示して）こちらはですね、非常に簡易的にFeature Flagsを実装したコードのイメージになります。

先ほどのロールアウトの話に絡めるとどういうことになるのかというと、このisFeatureXEnabledという関数で分岐をかけているif-elseの部分。ここがロールアウトを切り分ける部分で、分岐の上のほうがロールアウトされた状態、分岐の下のほうがロールアウトされていない状態を表しているイメージになります。

こういったFeature Flagsを実装することで、デプロイとロールアウトの分離が実現できるわけですが、単に機能のオン・オフを切り替えるだけではなく、実装次第ではありますが、例えばユーザーの属性に応じて機能の利用可否を切り替えたり、そういった柔軟なこともできるようになります。

補足です。一口にFeature Flagsって言ってもいろいろな種類があるんですが、本セッションではその全部に触れるわけではなくて、主に機能をロールアウトしていく時の、新しい機能を追加してそれをロールアウトしていく時に使うFeature Flagsを念頭に置いて説明していきます。

Feature Flagsの仕組みを使って得ている利益

佐藤：1章の最後です。弊社カミナシがFeature Flagsの仕組みを使ってどんな利益を得ているのかという、所感みたいなことを話したいと思います。3つほどだーっと書いています。どれもよくある切り口なのかなと思っています。この中で真ん中に書いてある、お客さまへのβ版提供といった文脈で、詳しくお話ししていきたいと思います。

こちらでメリットを感じていることですが、プロダクション環境の実業務データでβ版を試してもらうことができるということに、非常にメリットを感じています。

これがどういうことなのかと言うと、例えばβ版環境を作って、そこにお試しデータを軽く作って、それで試してもらうなんてことも、もちろんやろうと思えばできるんですが、それだとお客さまが業務をイメージしづらく、かつ、そのような環境では、たいてい実業務で使うのは不可能だったりします。

ただ一方で、プロダクション環境の実業務データを使ってβ版を試してもらうことができると、お客さまも実業務をイメージしやすいし、場合によっては実業務で使ってもらうことも可能なんですね。このようなかたちでβ版を試してもらえると、骨身に染みるフィードバックがたくさんもらえて、非常にうれしいです。

Feature Flagsを使って一部のユーザーのみに柔軟にロールアウトするという仕組みがあるために、こういったことができているなと感じています。

第1章のまとめを行っていきます。開発・ビジネスの両面で、デプロイとロールアウトの分離が重要で、Feature Flagsによって実現できます。弊社カミナシでも、いろいろな面でFeature Flagsのメリットを享受できているという具合の話をしました。

次章以降のための補足

佐藤：次章以降の説明のために、ちょっと補足として話したいと思います。Feature Flagsの実装のイメージを、もう少し詳しく見ていきたいと思います。

（スライドを示して）こちらがFeature Flagsの全体的な実装、仕組みを非常に簡易的に表した疑似的なコードになります。内容的には、サービスとかシステムにアクセスしてくるユーザーの属性に応じて、機能のオン・オフを切り替えるようなイメージになります。

こちらの赤枠のところに注目してほしいんですが、これがなにかというと、機能をオンにするユーザーの属性を定義したもののイメージです。なので、例えばロールアウトしていくユーザーを増やしたい場合には、赤枠の部分に列挙する値を追加していくようなイメージになります。

実をいうと、次章以降で説明していくAWS AppConfigでFeature Flagsを実現する時に、AWS AppConfigに格納するデータが、ここの赤枠の部分に該当するわけです。こちらはToggle Configurationというふうに呼んでいます。

Toggle Configurationという概念は以降のスライドでちょくちょく出てきますが、唐突にこの言葉を持ち出してもあまり直感的ではないとも感じているので、適宜補足しながら説明をしていきます。そのあたりはご安心ください。

（次回に続く）