RevComm Tech Blog

コミュニケーションを再発明し 人が人を想う社会を創る

登壇レポート『NIKKEI Tech Talk』にて 研究開発部門のFeature Flag の検討と導入についてお話ししました

RevComm Research Dept. Development Groupの高橋典生です。先日開催された、NIKKEI Tech Talkの【日経×コドモン×RevComm】サービスの安定性、信頼性を高めるDevOps/SREの取り組み に登壇しましたので、紹介させていただきます。

NIKKEI Tech Talkとは

NIKKEI Tech Talkとは、日本経済新聞社 CDIO室が開催する技術勉強会です。毎回テーマを変えて様々なトピックで開催されています。私が登壇したのは以下の回でした。

nikkei.connpass.com

これ以後も、

nikkei.connpass.com

nikkei.connpass.com

と興味深いラインナップで続いてますので、興味があればぜひご参加ください。

発表内容の概要

Feature Flagを私のチームで導入した経験を踏まえて、どのように検討、導入、運用したかという点についての説明が発表の大まかな内容です。

私の所属するRevComm Research Dept. Development Groupというチームは、研究開発の部門の中にあります。「機械学習の研究成果を製品に組み込み、ユーザーに価値を届ける」というのがチームのミッションの一つになっています。RevCommは音声解析分野の機械学習の研究を社内で続けており1、そういった研究成果を MiiTelの製品群に組み込み、ユーザーに新たな価値を提供し続けられるように努めています。したがって、私のチームが開発するサービスの多くは機械学習を使ったサービスになります。

こういった背景の中、機械学習サービス固有の機能・非機能面の不確実性への対応をとりつつ、他のチームの開発に依存せず開発が継続できるようにするためにFeature Flag を導入しました。このあたりのモチベーションは、こちらのスライド付近にまとめています。また、そもそもFeature Flagと言ってもその役割や性質に応じて質的に異なるものと認識した方が良いということを検討フェーズで学びました。この点は「Feature Flagって4種類あんねん」というキーワードとともにMartin Fowlerの引用を元にこちらのスライド以降にまとめています。最後のハイライトは導入後の運用面です。Feature Flag導入後、使わなくなったFeature Flagを消すための工夫に関してこちらのスライドにまとめました。

スライドの最後にも書きましたが、今後はA/Bテストや全社的な切り替えをPdMが行えるような仕組みに発展させていく可能性があるので、ここで検討した内容を踏まえ、よりユーザーに価値を安定的に届けていける形を目指そうと思います。

登壇資料はこちらにアップロードされていますので、ご興味のある方はご覧ください。

speakerdeck.com

チームに仕組みを入れてDevOpsを加速させる

RevComm Researchでは、SREというロールはなく、EM(Engineering Manager) を除くIC(Individual Contributor) 個々人が主体となって、SRE的な視点を持ってDevOpsの改善を図っています。

最近では、Platform Engineeringというキーワードもよく目にするようになりました。もちろん、大規模な組織の場合Platform Engineer(or SRE) 専任、のようなパターンはありますが、そのようなパターンであっても(社外の)ユーザーの使うアプリケーションを作っている開発者がSRE的な視点を意識することがより良いDevOpsの改善に重要だと私は考えています。

とはいえ、「ちゃんとDevOpsやっていこう」という精神論だけでは、再現性もないですし、チームとしてうまく行動することができません。そうならないためには、チームに仕組みを入れる必要があります。私のチームでは、「小さな改善活動」というルールがあり、それがDevOpsを推進する仕組みの一例になっています。チームとしてのコミットメントは最優先なものの、チームの合意が必要になるような大きな変更でなければ、自由にこういった運用の改善、バグの修正、CI/CDの改善などを行うことができます。Feature Flagの対応もこの「小さな改善活動」の中から生まれたものでした。

登壇のメリット

RevCommではDevRelを支えてくださっている方もいらっしゃいますし、個人的にもこういった登壇の機会はメリットが大きいのでどんどん挑戦しようと考えています。

こういった場での発表を行うことで、知っていることを共有して、知らないことを共有してもらうことができます。ソフトウェアの進化の歴史がまさしくそうであったように、これはソフトウェアエンジニア全体の利益になると思います。

あまり意識されない登壇者のみのメリットもあります。発表内容に詳しくなるのはもちろんですが、私はここで、別の点も強調したいと思います。まずは、社内に閉じた専門知識を世の中における一般的な水準で位置付ける良い機会になります。これによって、視野が広くなり、社内の問題解決にも新たな視点で対応できる可能性が増えます。また、発表することで、良い点・悪い点を指摘してもらうことができます。これにより自分一人では思いつかなかった観点での考えを知ることができ、より深く技術を見つめることができます。

こういった場は大好きなので、今後も発表したり参加者として楽しんだりできればうれしいなと思っています。

以下は発表後の最後の締めの様子です(みんな楽しそう)

発表後の Zoom の画面。登壇者とコーディネーターが手を振っている。
発表後の Zoom の様子

最後に

最後にNIKKEI Tech Talkの参加者のみなさま、運営者・登壇者のみなさま、社内でDevRel対応をしてくださった方、レビューしてくださった方に感謝の意を示して締めさせていただきます。

我々は “コミュニケーションを再発明し、人が人を想う社会を創る” というミッションを掲げて日々励んでいます。そのためにはたくさんの優秀な仲間が必要です。今回のこういった活動を見て、RevCommに興味を持ってくださった方は採用ページもぜひご確認いただけると幸いです。


  1. 「Forbes AI 50 2023」に選出 アジアで唯一、最も有望なAI活用企業として表彰されました (https://prtimes.jp/main/html/rd/p/000000158.000037840.html)