はじめに
こんにちは！業界トップシェアのSaaSを提供しているThinkings株式会社でプロダクトエンジニアを務めているnaotoEngです。弊社Thinkingsでは「誰もが意志ある仕事をするために 誰もが使える方法をつくる」というミッションの元、採用管理システムsonar ATSを開発しています。 そんなsonar ATSに開発者向けのFeature Flagという機能を実装したので、本日は実装までの流れをシェアしたいと思います。
Feature Flag実装例
実装したFeature Flagは下記のようにキーを指定してtrue/falseを取得し、分岐に利用するだけのシンプルな機能です。Feature Flagの値はDBに格納してあり、コードのデプロイをせずともプログラムの挙動を変更することができます。
const Page = (props: Props): JSX.Element => {
// Feature Flag取得
const isFeatureFlagEnabled = useFeatureFlag("featureFlagKey");
return (
<>
{/*Feature Flagで分岐 */}
{isFeatureFlagEnabled ? (
<div>{"New Feature"}</div>
) : (
<div>{"Current Feature"}</div>
)}
</>
);
};
Feature Flag導入の経緯
Feature Flag導入前のThinkingsではデプロイとリリースが分離されていなく、デプロイしたものがすぐにユーザーに見えてしまう状態でした。そのため規模が大きいリリースについては都度深夜メンテにしてリリースしていたのですが、下記のような課題がありました。
- メンテは月1であり、リリース日の自由度が低い
- メンテで切り戻しとなった場合、次のメンテまでリリースを待たなければならない
- メンテに参加したエンジニアは睡眠サイクルが乱れ、翌日以降の生産性にネガティブな影響がある
デプロイ後にフラグのON/OFFでリリースができるFeature Flagであれば、上記の課題が改善できると思い導入することにしました。
導入の方針
LaunchDarklyやAzure App ConfigurationなどのFeature Flagのサービスを利用することも検討しましたが、スピード感を持って導入を進めたかったのと、Feature Flagの実装自体はそんなに難しくなさそうだったので、自社で実装することにしました。
実現した機能
- DBの値に応じてフラグを有効・無効化できる
- 指定したプロジェクト（テナント）だけフラグを有効化できる
- フラグ有効化の開始日/終了日を指定できる
データ構造
1つのFeature Flagに対して、複数のプロジェクトが紐づくデータ構造になっています。これにより、複数の指定したプロジェクトでフラグを有効化できます。
全体的な導入の流れ
1. プロジェクト結成
弊社では半期ごとに目標を立てて人事評価の対象にすることができます。Feature Flag導入を目標にしたエンジニアが私の他にもう一名いたので、共同して導入を進めることにしました。
2. 設計
プロダクトにどのようにFeature Flagを組み込むのか、どんなAPIを用意するのかを議論しました。sonar ATSはSPAで、フロントエンドはReact+Redux+TypeScript、バックエンドはASP.NETを利用しています。
フロントとバックそれぞれにFeature Flagを利用できるメソッドやAPIを用意することにしました。
3. コミッティレビュー
弊社のエンジニア組織ではフロントエンド・バックエンド・DBの各分野にコミッティが存在しており、お悩み相談室のようになっています。2で考えた設計をバックコミッティに持ち込んでレビューしてもらいました。レビューの際に受けた確認事項としては下記のようなものがありました。
- キャッシュの有無。Feature Flagは即時反映でなくても良さそうなので、キャッシュがあったほうが負荷分散になる
- ロギングの有無。想定外の動作をロギングできるようにしておく
- フロントエンドはフラグを都度取得するのか、それとも初期表示時に全取得するのか。後者はバックとの通信が1回になるが、フラグが切り替わったとき反映できるか
上記を踏まえ、設計を修正しました。
4. 実装・テスト
作業範囲をフロントとバックで分けて実装し、テストを行いました。またリスクレビューを行い、想定されるリスクを洗い出して検証しました。
5. リリース
約1ヶ月で実装・テストを終わらせ、本番環境にFeature Flag機能をリリースしました。
6. 試験運用
自チームの比較的小規模な開発プロジェクトに、Feature Flagを適用してリリースしました。結果として不具合は特になく、組織内に周知して大丈夫だろうという感覚を得ました。
7. 周知
社内向け解説記事を作成し、エンジニア全員を招待してFeature Flagの周知会を行いました。この時点で根本的な指摘とかもらったらどうしようなど考えていましたが、指摘というよりは質問やポジティブな意見がほとんどだったので一安心しました。
導入結果
まだ周知して1ヶ月程度ですが、すでに他チームでもFeature Flagを利用いただいているみたいです。うれしい！当初の目的だったメンテ課題もこれからですが、組織的な解決に向けてFeature Flagを推していきたいと思います。
導入する上で重要だと感じたこと
協同するエンジニアとの定期的なコミュニケーション
たった2人のプロジェクトメンバーといえど定期的なコミュニケーションは重要だと感じました。今回のプロジェクトでは毎週30分の定期予定を入れていましたが、その中で状況確認とネクストアクションを決めていました。結果として週単位での進捗が生まれ、半期というやや長いスパンを走り切ることができました。
テックリードやベテランエンジニアの力を借りる
弊社にはプロダクトに関わって長いテックリードやベテランエンジニアがいるので、設計段階でプロダクト固有の考慮事項を教えていただき、事故ることなく進めることができました。社歴の浅いエンジニアでも上記の方々と積極的にコラボレーションすることで、危なげなくプロジェクトを進められると感じました。
社内の周知といえどユーザーへの価値提供だと思ってやる
これはやってみての反省なのですが、周知会にはほぼエンジニア全員に参加してもらおうと思っていたのですが、一部理由のなさそうな欠席がありました。周知会開催の連絡を1週間前にしたきりだったので、直前でリマインドを挟むべきだったと思います。実装した機能は誰かに使われなければ意味がないので、ユーザーへの価値提供だと思って、実装するだけでなく機能を使ってもらう活動にも力を入れるべきだと思いました。
一通り導入を終えて
私は記事執筆時点で入社2年目で、比較的社歴が浅いメンバーですが、プロダクト全体に関わるFeature Flagの導入を主導権をもって進めることができました。弊社のエンジニア組織は、個々人が自分の意志で業務改善ややりたいことに取り組むカルチャーなのですが、自分には合っているなと感じました。
自分が関わっている組織・プロダクトを素早く改善することで気持ちよくなれるエンジニアにとってはオアシスだと思います。
最後に
この記事ではSaaSプロダクトにFeature Flag機能を実装した話をしました。比較的簡単に実装できる割にはインパクトが大きい機能だと思うので、自社サービスにFeature Flagないよって方は導入を検討されてみてはいかがでしょうか。
参考にさせていただいた記事
Discussion