LINE株式会社およびヤフー株式会社は、2022年11月17日・18日の2日間にわたり、技術カンファレンス「Tech-Verse 2022」をオンライン（ライブストリーミング形式）にて開催しました。特別連載企画「Tech-Verse 2022 アフターインタビュー」では、発表内容をさらに深掘りし、発表で触れられなかった内容や裏話について登壇者たちにインタビューします。今回の対象セッションは「Feature Toggleを用いた大規模改修への開発アプローチin LINEスキマニ」です。
企業とユーザーの「スキマ」時間をマッチングする単発雇用サービス 「LINEスキマニ」では、2022年5月から大規模な機能改修を行っています。大規模な改修でビッグバンリリースをする際に起きる問題として、コード修正の競合が発生することによるリファクタリングの難しさや他チームとの開発連携があります。そこでLINEスキマニのあるSquadではFeature Toggleという開発手法を導入し、この問題に対処しました。今回はセッション発表内容についての秘話を、LINE Growth TechnologyのHRS Development Teamに所属するフロントエンドエンジニアの磯村建司郎にインタビューしました。
実現したい要件はシンプルだったため、Feature Toggleを自作する方針をとった
――HRS Development Teamの担っている役割と磯村さんの業務内容を教えてください。
HRS Development Teamは、LINEスキマニやLINEバイトなど、LINEにおけるHRサービス事業に関するアプリケーションの開発・運用をするチームです。もともとLINEスキマニは、LINE FukuokaやLINE Growth Technology、LINEのフロントエンド開発センター（UIT）など、複数の組織によって開発が進められていました。
ですが、LINEのHR系サービスの開発を一丸となって進められるよう体制を変更し、HRS Development Teamが作られました。私はそこでフロントエンドエンジニアとして、LINEスキマニの求職者向けのWebアプリケーションと、企業向けCMSのWebアプリケーションの開発を担当しています。
――今回のインタビューでは「Tech-Verse 2022」のセッション内容をふまえ、その裏話を伺います。Feature Toggleと一口に言っても、その設計・実装パターンはさまざまです。LINEスキマニの事例では、自分たちのプロダクトに即したFeature Toggleのパターンを、どのような方法で検討しましたか？
セッションの発表でもお話ししたのですが、まず前提として課題に直面していた当時の私はFeature Toggleという概念を知りませんでした。その後、同僚からFeature Toggleについて教えてもらい、Feature Toggleに関するWeb記事なども読み進めました。
今回のプロジェクトでは、そうした記事などに掲載されている既存の設計パターンに当てはめるというよりも、自分たちのプロダクトの機能要件や開発期間、開発体制、A/Bテストの要否、ユーザーごとの機能切り替えの要否などを鑑みて自分たちで設計を検討し、チームでも話し合っていく方針を選びました。
LINEスキマニでは最終的に、新機能のコードをデプロイしておきユーザーに提供するタイミングでトグルを切り替えるRelease Toggleと、ユーザーに応じてトグルの切り替えをするPermission Toggleが必要だということになりました。
――検討したもののボツにした案などはあるでしょうか？
調査を進める過程で、サードパーティー製のソリューションやOSSなどにFeature Toggleを導入できるツールがあることを知りましたが、それらは採用しませんでした。Feature Toggleの利点として、さまざまな機能の有効・無効を任意のタイミングで切り替えられることが挙げられます。ですが今回のプロジェクトにおいては、大規模な改修を行う過程で他のSquadの開発に影響を出さないことが重要であり、多機能なFeature Toggleは必要ありませんでした。
サードパーティー製のソリューションやOSSなどは導入や学習に時間がかかります。簡易的なFeature Toggleを導入するだけであれば、あえてそれらのツールを使う必要はなく、自作すればいいと考えました。私たちの作ったFeature Toggleは、環境変数の値を見てToggleを切り替えるという簡易的な設計になっています。
小規模かつ個々のエンジニアの意見が反映される環境
――先ほど述べたような方針を、どのような流れで決めていきましたか？
Feature Toggleを導入することを提案したのは私で、盛り込む機能や想定される開発フローなど、ある程度の方針を洗い出したうえで、Squadのメンバーとのミーティングを複数回設けました。ミーティングではフロントエンドエンジニアやサーバーサイドエンジニア、QA担当者、企画担当者などが集まって意見を出し、方針を決めていきました。LINEスキマニはSquad体制をとっており、開発組織が複数の小さなチームに分かれています。開発方針についてはSquad内のメンバーで決め、その内容を他のSquadに共有するケースが多いです。
また、今回のセッションでは仮想リリースという概念を導入したことについて話をしましたが、その方針を決めたのもSquad内での話し合いがベースになっています。Toggleがオフになっている状態の機能は本質的にはユーザーに価値を提供しないので、あえて正規のリリース手順をとる必要はありませんでした。他のSquadとの開発連携さえできればよかったので、仮想リリースを行う方針になりました。
HRS Development Teamの組織として、誰かが何かを提案したときに「できない」と否定的に考えるのではなく「やってみる前提で、どのように行動すべきかをみんなで検討する」という空気感があります。それから、フロントエンドエンジニアがサーバーサイドやDevOpsなどについても忌憚なく意見を言えるといった、サービスや組織を良くするためならば役割を越境した発言でも歓迎される文化があります。
――今回のプロジェクトで磯村さんは初めてSquadのフロントエンドのリードエンジニアを務められましたが、その感想を教えてください。
リードエンジニアは初の経験でしたが、それほどガチガチにならず役割を担うことができました。それは、先ほど述べたような心理的安全性の高さや少人数だからこその動きやすさなどが影響していると思います。
リードエンジニアを務めて、勉強になることも多かったです。これまで担ってきたエンジニアの役割と今回のリードエンジニアの役割とでは、担当する業務内容がかなり異なります。リードエンジニアの場合、他のメンバーにタスクを割り振ったり作業の工数見積もりをして進行方針を考えたりと、設計や実装以外のことにもかなり頭を使う必要がありました。
せっかくならば他のエンジニアに前向きな気持ちで仕事に取り組んでもらいたいので、割り振るタスクの内容には気をつけました。またプロジェクトが全体的にスケジュール通りに進んだことで、自信につながりました。もちろん反省点もありますが、それも含めて大きな学びです。
――LINEスキマニというプロダクトの開発に携わる面白さはどのような点にあると思われますか？
LINEスキマニは、私が今まで携わったLINE社内のプロダクトの中でも、個々のエンジニアがオーナーシップを持って開発を進められる感覚があります。先ほど述べたように他の職種のメンバーと密にコミュニケーションをとりながら開発を進めていくわけですが、そのなかで自分の言った意見を積極的に採用してもらえるからです。
また、少人数で方針を決めてプロジェクトを動かしていくので、スピード感もあります。自分がプロジェクトの手綱を握って、責任を持ちながら進められるのがLINEスキマニの業務の醍醐味です。
――では最後に、磯村さんの今後の目標を教えてください。
フロントエンドエンジニアとして、さらにReactやTypeScriptなどのスキルを伸ばし、より複雑な要件を実現できるようになりたいです。また、今回のFeature Toggleの事例のようにリリースプロセスの改善やDevOpsなどにも興味があるので、積極的に取り組んでいきます。将来的にはより規模の大きなプロジェクトのテックリードを担って、フロントエンドのスキルで開発組織を引っ張っていけるようになりたいです。
――磯村さんがさらに成長されることが楽しみです。今回はありがとうございました。
