ソフトウェア開発において注目されるパフォーマンス指標には、デプロイに関係するものがあります。GoogleがDevOpsの取り組みから発表したFour Keysも、デプロイ頻度のほか、コミットからデプロイできるまでのリードタイム、デプロイにともなう障害発生率とその回復時間と説明されています。
そのためデプロイできるブランチへのマージは小さく、回数を重ねることが推奨されるようになっています。一方で、ビジネス用途のSaaSなどでは顧客との関係から、新機能は適したタイミングで完成度を上げてからリリースしたいという要求もあります。
タレントマネジメントシステム「カオナビ」の開発チームでも同様の課題感を抱えており、その解決のためFeature Toggle（機能トグル）を導入してデプロイとリリースの分離を図りました。その経緯や成果について、導入を主導したCTO室の富所亮さん、サービス開発部で実際にFeature Toggleを活用する宇谷有史さんと髙橋朝人さんの3人に伺いました。
※この記事は株式会社カオナビによるSponsoredContentです。
- 機能リリースをコードのデプロイから分離する
- ドキュメントをADRで共有して社内の合意を形成する
- 「これは怖いものではなく、僕らの味方らしい」
- デプロイできる状態とは何かを細かく考える
- カオナビではエンジニアを積極募集しています！
- Feature Toggleとは
- システムにデプロイされたある機能を動作させるかどうかを運用時に切り替える仕組みのことで、開発チームがコードを変更することなくシステムの振る舞いを変更できる。開発途中のコードを細かい粒度でトランク（メインブランチ）にマージしてもシステムに影響を与えずデプロイできるため、継続的デプロイ（Continuous Deployment、CD）の文脈において活用される。Feature Flag（機能フラグ）とも呼ばれる。
参考記事▶ Feature Toggles (aka Feature Flags) - martinfowler.com
機能リリースをコードのデプロイから分離する
── 「カオナビ」の開発チームがFeature Toggleを導入したお話を聞いていきたいと思います。最初に、導入のモチベーションを教えてください。
富所 もともとの動機は「ビッグバンマージがつらい」ことですね。開発チームが、それぞれ数カ月開発を行った変更をリリース直前のタイミングでメインブランチにマージしていて、大きな変更をマージしていたためコンフリクトも発生しやすく、リスクが高いやり方を繰り返していました。
宇谷 何カ月もかけた長い開発の成果物をリリースするので、新規ファイルが数十あるとか、既存ファイルに数十の変更が入るといったマージになります。リリース時には他チームとのコンフリクトもよく発生し、その解消をするために他の作業ができなかったり時間を奪われることが度々ありました。
富所 マージが失敗していなくても、リリースしてみたらうまく動いていなかったこともあります。それでリバートするとコミット履歴も汚くなってしまって、いいことがありません。
もちろん事前にステージング環境で確認しますが、そこで長い時間はかけられないので、本番環境にリリースした後に問題が顕在化しがちになっていました。いわば新機能リリースが「賭けに出る」ような状態です。そういう賭けは止めてほしい、というのがわれわれの思いでした。
富所 亮（とみどころ・りょう）@hanhan1978
株式会社カオナビ CTO室 エキスパート
SIerでの受託開発を経験後、口コミ系の自社サービス会社でマネジメントに従事。ベンチャー企業などを経て、2020年11月にカオナビ入社。プロダクト本部サービス開発部Platformグループから現職。
── 富所さんが所属されているCTO室では、そういった全社的な開発基盤の整備なども担当されているのですね。
富所 CTO室は部署としてプロダクト開発と分けられています。プロダクト本部のメンバーの開発体験を向上させて、顧客に良いプロダクトを届けるため「確実にやった方がいいけど、やれていないこと」をするのが役割です。課題を見つけた際に、優先順位を判断する裁量も与えられているので、Feature Toggleをやるとなったら他の仕事より優先度を高く取り組みました。
── 宇谷さんと髙橋さんは、そのように整備された開発基盤を利用して実際にプロダクトを開発する立場ですよね。
宇谷 はい。サービス開発部Strategyグループに所属していて、人事計画に関係するような機能を開発しています。私はテックリードとしてチーム開発を引っ張る役割ですが、Feature Toggleについては「チームが苦しみから解放されるのではないか」と考えて、チームに周知する動き方をしました。
宇谷 有史（うたに・ありふみ）@gennei
株式会社カオナビ プロダクト本部 サービス開発部 Strategyグループ テックリード
コンビニエンスストアの発注システムの受託開発、読書管理アプリ会社でサービスの企画から実装に携わった後、2022年4月にカオナビ入社。
髙橋 宇谷さんと同じStrategyグループで、スクラムマスターとプロダクトオーナーを兼任しています。実は宇谷さんとは同日入社の仲です。
今回の課題をプロダクトオーナーの視点から見ると、開発した成果には小刻みなフィードバックがほしいところですが、B2Bサービスでは頻繁なリリースよりもまとまったリリースが求められる場合があります。まとまったリリースの方がセールスやカスタマーサクセスの観点で顧客にインパクトを感じてもらいやすかったり、頻繁な変更による顧客の戸惑いや問い合わせを回避できるメリットもあるということです。
富所 そのため機能リリースとコードのマージが同時になってしまうことが問題でした。
髙橋 今はリリースとデプロイを分ける考え方が主流で、これを解決するにはFeature Toggleを導入するのがモダンなやり方です。
富所 仕組みで解決できることは、そうした方がいい。ソースコードの管理上も、リスクヘッジのためにも導入したいと考えました。
髙橋 加えて、例えばセールスが見込み顧客に対して「リリース予定の新機能のデモを見せたい」といったニーズにもフィットします。
髙橋 朝人（たかはし・あさと）@at_946
株式会社カオナビ プロダクト本部 サービス開発部 Strategyグループ プロダクトディレクター
通信事業会社で基幹システムや自社サービスの企画開発に従事。その後数社で、SaaSプロダクトのプロダクトマネージャーや社内のアジャイル開発の推進の仕事などを経て、2022年4月にカオナビ入社。現職ではスクラムマスターとプロダクトオーナーを兼任。
ドキュメントをADRで共有して社内の合意を形成する
── 開発チーム側からは、この動きはどのように見えていたのでしょうか。
宇谷 「あるといいな」という意見は開発チームからも出ていました。社内のあちこちで「現状のビッグバンマージはつらい」と感じたメンバーがいて「Feature Toggleのような仕組みを入れたいんだけど」というヒアリングも行われていました。
髙橋 「もう現場で独自にやろうか」という声が出ていたぐらいです。
富所 近年はセミナーなどでもFeature Toggleに関してたくさんのトークがあり、世間の盛り上がりを開発チーム側でも感じていたようです。ただCTO室としては、独自にハックするのはやめてほしい。そこで統一した機能を作りますと提案しました。
宇谷 CTO室からの提案に「これは積極的に使うしかない」と思っていました。
── 時間軸でいうと、いつごろ開発を始めたのでしょうか。
富所 大きなきっかけは、2022年8月に開催されたPHPカンファレンス沖縄2022におけるM&Aクラウドの久保田賢二郎（@kubotak_public）さんの発表ですね。我々の状況にちょうどマッチしそうだという感触を得て、社内で自然発生的に「やろうぜ」というノリが生まれました。
▶ FeatureToggle戦略と運用方法 - Speaker Deck
── 開発はどのように、どれくらいの期間で進めたのでしょう。
富所 弊社の開発チームでは、アーキテクチャの意思決定をADR（Architecture Decision Records）として記録・共有する運動を昨年の8月からしています。Feature Toggleも導入に先立って、8番目のADRになりました。
参考記事▶ 〜その意思決定を刻め〜「アーキテクチャ・デシジョン・レコード(ADR)」を利用した設計の記録 - スタディサプリ Product Team Blog
Feature Toggleについては、ADRの初稿を10月12日に作っています。リリースは12月2日でしたから開発期間は2カ月弱になりますが、コードの規模は大きくなく、テーブルも3つしかありません。むしろ設計の合意を取るプロセスに時間を使いました。CTO室の業務では、開発チームに理解して受け入れてもらうコミュニケーションが大切ですから。
── Feature Toggleを導入する合意は、どのように意思決定したのでしょうか。
富所 ADRに開発意図や実装サンプルなどもたくさん書き込んで、意見募集の期間を何週間か取りました。チームもADRに慣れてきていたので、単純な質問もありましたし、長いコメントをつけてくれる人もいました。
宇谷 関心があるメンバーはたくさんコメントしていましたね。
髙橋 機能を使える・使えなくするの制御に関しては、自社でドッグフーディングできるようにしたり、先ほどのデモ用途だったり、どういうアクセスが来たときに制御するかのパターンがいろいろと考えられます。サービス開発部側として「こういうふうに使いたい」というフィードバックを伝えました。
富所 現場の声をもとにかなり修正できました。反応があってとてもよかったです。
「これは怖いものではなく、僕らの味方らしい」
── 実装はどのように進めたのでしょうか。
富所 SaaSを使って実現するケースも多いのですが、フロントエンドのJavaScriptもトグルで切り替える必要があるなど、特有の考慮すべき点があったため自作する決断をしました。基本はサーバーサイド側で動き、フロントエンドからはAPIでトグルを確認します。
── 開発チームの側は、リリースされたFeature Toggleをどのように使ったのでしょう。
宇谷 実装途中から「Feature Toggleが来たらこういう開発ができる」みたいな仮説は持っていました。Feature Toggleは不要になったらコードから削除するので削除しやすいように設計をして、チーム内に共有しました。
髙橋 当時はちょうど半年ほどかかった長い機能開発の途中で、コンフリクトが起こりやすい状況でしたから、Feature Toggleを使って小刻みにリリースすればコンフリクトを回避できるのではないかと期待していました。
宇谷 「よし、イキのいい『銀の弾丸』が来たぞ」みたいなノリで使いはじめましたね。機能の半分まで実装したところで「いったん区切りを付けてデプロイまでしたい」ということがありました。なおかつ、デモ環境ではトグルをオンにして新機能の一部をデモできるようにしました。
髙橋 12月2日にFeature Toggleが使えるようになって、新機能がデプロイされる1月24日までは、機能開発と並行しながらトグルを入れていきました。
富所 宇谷さん髙橋さんのチームは当初から積極的に活用してくれましたが、実はFeature Toggleの最初のユーザーは、CTO室の同僚でした。検索基盤のリプレースという非常に大きな新規リリースがあり、「問題があったらすぐに切り替えられるようにしたい。Feature Toggleを早くリリースしてくれ」と言われていたんです。
── 社内へのFeature Toggleの浸透の度合いはどうですか？
宇谷 10の開発チームのうち、デプロイまで進んでいるのは僕らを入れて2チームぐらいですが、5〜6チームで導入の話をしています。導入の機運はかなり高まっています。
富所 「これは怖いものではなく、僕らの味方らしい」と思ってもらえるようになりましたね。
── Feature Toggleで機能のオン・オフを切り替えるのはどんな局面ですか？
髙橋 機能リリースでオンにして、不具合が起きてもオフにすれば一次対処できるリスクヘッジとしても利用をしています。ほかにも自分たちでも「カオナビ」を使っているので、自社の「カオナビ」のみ新機能をオンにして、自分たちが触ってフィードバックをもらっています。
セールスメンバーがデモをするときにも便利です。「直近でこんな新機能を開発しています」と見せることができます。ユーザーへのヒアリングにも使います。
デプロイできる状態とは何かを細かく考える
── Feature Toggleが導入されたことで、開発現場はどう変わりましたか？
髙橋 Feature Toggleがあると、極論すると「リリースしないんだから、どんな状態でもマスターにマージできるよね」ということになります。なので、「どのような状態ならマージしていいのか」を考えないといけません。デプロイはリリースではないけど、いつでもリリースできる状態をキープするのが理想です。そこで「僕が間違ってFeature Toggleをオンにしても大丈夫？」と聞くと、みんなが考え出す。
例えばテストをどこまでやるか、性能評価はどこまでか、ドキュメント整備はどうか。どこまで終わればデプロイ単位になるんだろう。開発チームとして「Feature Toggleを勝手にオンにされてもいい状態」でデプロイするにはどうすればいいのか、という基準で考えるようになりました。
そして「これをやらないと完成じゃなかったんだ」とみんな気付いたことで、スクラムガイドにある「スプリントごとに利用可能なインクリメントを作りましょう」ということの解像度が上がった気がします。「Undone Work（スプリント内で完了していないが、リリース時までに完了しなければならない作業）が残っているとデプロイできないよね」「性能保証はどうするの？」という意識が生まれました。
参考記事▶ Done の定義 - Large Scale Scrum (LeSS)
宇谷 スクラムの「小さなインクリメントが積み上げる」ということを言葉では分かっていましたが、実際にスプリントでインクリメントを積み上げることを体験をすることで、より理解することができました。
それまでバックエンドとフロントエンドがそれぞれ別々に開発していて、「自分の担当分の開発が終われば終わり」という意識だったのが「ちゃんと動作を確認できるまで開発は終わっていないぞ」と変わっていきました。
── Feature Toggleの導入によりアジャイル開発の文脈でも現場が変わってきたわけですね。興味深いお話です。
富所 スクラムの文脈で有効活用できることは、私たちも後から知りました。積極的に利用してくれたのは心強かったですね。
髙橋 スクラムとの相性の良さは、私も想像していませんでした。取り組んでいる中で、「こういう説明がつくな」と見えてきました。Feature ToggleはDevOpsの文脈で語られることが多いのですが、DevOpsはスクラムにもつながりますから。
ほかにもデプロイの頻度を上げることができただけでなく、エンジニアとQC（Quality Control、品質管理）の関係が変わったり、開発者と運用が越境して会話できるきっかけになったり、良いことがいくつもありました。
── さまざまな面で改善が進められているようですが、一緒に働くエンジニアにもやはりそういったマインドが求められるのでしょうか。
富所 僕らが心掛けていることは、「やらなきゃいけないこと」ではなく「やった方がよくなること」をやる。価値提供するチームが価値提供をしやすくする役回りです。そんな主体性を持って取り組みたいエンジニアとぜひ一緒に働きたいですね。
宇谷 せっかくきれいなコードで作ったソフトウェアでも、使われないと意味がありません。顧客の姿が見えているので、使われるものを作ることを心掛けています。作って終わりにしたくない人と一緒に働けたらよいなと思います。
髙橋 顧客にポジティブな価値を提供したいと心掛けています。システム開発より、プロダクト開発に目を向けたい。そのためには顧客の価値を軸に話をできたりコードを変えられる、そういう仕事をしたい人に当社は向いているのかなと思います。
── 興味深いお話をありがとうございました。
カオナビではエンジニアを積極募集しています！
カオナビのエンジニア組織では、ともに価値提供していく仲間を募集しています。
プロダクト開発にご興味ある方は、以下のリンクよりご応募ください。
「まず話を聞いてみたい」という方は、カジュアル面談にぜひご参加ください！
[SponsoredContent] 企画・制作：はてな
取材・構成：星 暁雄（ITジャーナリスト、@AkioHoshi）
撮影：小野 奈那子（nanakoono_）
