Flutterへのリプレースを通し、クライアント開発を「ワンチーム」で推進

適性診断を行って進学先を調べ、資料請求までを行える学校向け進路選択サービス「スタディサプリ for SCHOOL」は、Webページのほか、AndroidとiOSのアプリでも利用できますが、同じ機能を提供しながら、OSによって開発チームも、ソースコードも別々でした。新規開発を継続しつつ、クロスプラットフォームでの開発が可能なFlutterへ置き換え、一つのチームとして一本化することに成功したFor SCHOOLモバイル開発グループの皆さんにお話を伺いました。

Q：皆さんはどのような経緯でFor SCHOOLモバイルアプリに関わり、さらにFlutterを採用してのリプレースに携わることになったのでしょうか。

渡辺：私はベンチャーを中心に色々な会社を経て、エンジニアとしてリクルートにやってきました。For SCHOOLのiOS開発グループで開発に携わった後、サーバサイドやインフラも含め、グループ全体をカバーするようになり、さらにマネジメントの観点からグループ全体の開発効率化も考えるようになっています。

若宮：自分も転職組で、ずっとモバイルアプリの開発に携わってきました。今回のプロジェクトでは、Flutterに関する技術研究や推進を担ってきました。Flutterはオープンソースで開発されているため、その不具合に関するIssueを上げたり、時には自分で修正したりして技術的な課題を解決し、導入を推進していきました。

山本：自分はデザイナーとしてベンチャーに入社し、その後すぐにエンジニアに転じて働いてきました。For SCHOOLモバイルアプリのチームには2022年3月から加わり、その後すぐにFlutterリプレースのプロジェクトが始まりました。このメンバーの中で一番長く、メインで担当していた形です。

福岡：自分は2018年に新卒で入社し、別のプロジェクトでiOSとAndroid、両方のネイティブ開発を経験しました。その1〜2年後にこのプロジェクトに加わりましたが、リプレース開発にがっつり関わるというよりも、並行して進んでいた新規開発、エンハンス関連を主にリードしてきました。

西野：自分も福岡くんと同じ2018年にリクルートに新卒で入社しました。For SCHOOLには3〜4年ほど関わり、主にAndroidアプリの開発を担当してきました。Flutterリプレースでは、ネイティブアプリからの橋渡しをいかにスムーズに行うかを担当する他、スクラムマスターとしてチームがスムーズに回るよう見てきました。

濱田：自分は転職組です。これまで主にAndroidアプリの開発を担当しており、Flutterは未経験という状態でした。こちらのプロジェクトでは、別にあるQA（Quality Assurance）チームとの橋渡し役を担当し、今は実際にFlutterのプログラムを書きながら習得を続けています。

Q：なぜFor SCHOOLモバイルアプリをFlutterに移行し、一本化することになったのか、経緯を教えてください。

渡辺：元々はiOSとAndroidとで別々にアプリが開発されていました。チームも別々で、Android開発には業務委託の方々も関わっていました。使う技術も異なれば、スキルにもばらつきが生じており、また市場でモバイルエンジニアが不足している中でエンジニアの採用難度も高いといった課題がありました。
もう一つ、元々のForSCHOOLアプリについても仕様変更が多く、改修を重ねた結果、増築による増築でコードが複雑化していました。その一方でメインで開発に携わっていた方々が異動や退職となり、「複雑なんだけれど、どういう意図でこうしているのかがわからない」状態でした。直したいところがあっても、下手に触れるとバグりそうでできない、という状況になっていたんですね。
そこで自分がマネージャーになったタイミングで「責任を取るから、Flutterでリプレースして一本化しよう」と呼びかけ、プロジェクトが始まりました。

Q：提供する機能やサービスは同じであるにもかかわらず、二つの別々のコードベースがあり、それぞれ開発する面倒さがあったんですね。

渡辺：そうですね。加えてiOS/Android間でも微妙な仕様の違いもあって、「iOSだとできることが、Androidだとできない。何でこうなってるの？」といった問い合わせも度々あり、運用面でも不便を強いていました。
そこでエンジニア自身がしっかり設計も考える体制にしていくことも視野に入れ、複雑化している設計を全て見直して、あらためて自分たちのアプリケーションとしてリプレースしたいという思いも含め、取り組んでいきました。

Q：2つのコードをFlutterに置き換えていくプロジェクトを進める際、どのような課題にぶつかったのでしょうか。

渡辺：当時はエンジニアからの提案で始めるプロジェクトがほとんどなかったため、まず根回しに苦労しました。既に提供しているサービスですから、新規機能の開発が止まれば売り上げにも影響します。「予算はどうするんだ」「リソース配分はどうするんだ」といった声に対し、ビジネス的な観点で整理し、資料を準備しました。
触ったことも、聞いたこともない技術のため、「そもそもFlutterって何？」「ちゃんと動くの？」という疑問がFlutter採用検討の段階から関係各所から寄せられました。打開するきっかけとなったのが、山本さんが作ってくれたプロトタイプでした。実際に動くものを作り、プレゼンしてくれたことで「あ、いいじゃない。普通に動くね」と納得してもらい、プロジェクトが一気に加速しました。

山本：自分もFlutterには触ったことがなかったため、まず自分の手で「For SCHOOLに適用したらどんな感じになるんだろう」というのを確認してみたいと考え、2週間くらいでバーっと作ってみたら、「こんな感じのものが簡単にできそうだ」と手応えが掴めました。それをメンバーにも見てもらうことで、「こんなにすぐにできるんだな」という印象を持ってもらえたと思います。
それにFlutterでは、iOSやAndroid開発における最新の思想が適用されているので、モバイルエンジニアとして優れた開発体験が得られるなという実感もありました。

Q：その「最新の思想」とは具体的にどのようなものですか。

山本：iOSでは「SwiftUI」、Androidには「Jetpack Compose」という、「宣言的UI」という新しいユーザーインターフェースの作り方が採用されたフレームワークがあります。Flutterはそれらと同様に宣言的UIに沿って作られたフレームワークで、クライアントアプリ開発の最新の考え方に基づいています。
自分としては以前担当していたiOSアプリでもSwiftUIを使って設計、開発をしていた経験があるため、全く別物ではなく、安心して踏み込むことができました。しかも開発者にとってより便利な機能が数多く盛り込まれているので、iOSネイティブ開発と同等かそれ以上の環境で開発することが可能だなという感触が得られました。

Q：そうした作業は、通常の業務と並行して進めていたのですか。

渡辺：ちょうどFlutterへのリプレースに取り組み始めた年度から、まなび領域全体で、エンハンスとは別に「負債解消枠」を持とうという方針が決まりました。新しい開発ばかりにリソースを注いでしまうと、直したいところがあっても直せない状況になってしまいます。ですので、エンハンスとは別に稼働工数のうち三割の負債解消枠を設けており、山本さんにはその枠内でFlutterに張り付いてもらいました。

Q：プロトタイプを確認した後は、スムーズに移行が進んだのでしょうか。

渡辺：やはり、Flutter経験者がいないことが壁でした。そこで色々アドバイスしてもらったのが若宮さんです。自分は若宮さんと前職が一緒で、その縁で「Flutterをやりたいので教えて欲しい」と、当初は技術委託の形で指導をお願いしました。最終的には一緒に働くことになり、引き続き色々アドバイスしてもらっています。

若宮：自分は正式にリリースされる前から、Flutterに触れてきました。これは国内でも早い方だと思います。また、いくつかの技術カンファレンスにも登壇しています。当初は外部の有識者という立場で、Flutterに関する質問を受け、不安に思うことがあれば解消しますよ、という役割を引き受けました。
とはいえ「何がわからないかわからない」というところからのスタートだったため、最初の頃は質問も全然出ませんでしたね。そこで「Flutterではこんな感じでアプリが作れますよ」という勉強会を開催したり、山本さんと「ここはこうした方がいいんじゃないか」とお話ししたり、という形で支援を始めました。

Q：第三者的な目から見て、今回のリプレースは難易度の高いものだったのでしょうか。

若宮：規模感や使っている機能、仕組みでいうと、世間一般でもよくあるケースだとは思います。AndroidとiOSに分かれていたアプリを、まとめるケースとしては典型的なものかなと。ただ、実際にプロジェクトに入ってみて感じたのは、For SCHOOLにはモバイルアプリっぽくないところがあるなということです。モバイルアプリよりWebページっぽいといった方がいいかもしれません。さらに、For SCHOOLは先生が生徒に見せながら使うプロダクトでもあるので、フローに特殊な部分がありました。これらは、考慮が必要になりやや難しい部分でした。

Q：そうした支援を受け、少しずつナレッジを蓄積しながら移行を進めていったんですね。

山本：今回のプロジェクトの特徴の一つが、機能開発を止めることなく、並行してリプレースを進めることでした。機能開発を同時に進めながら、先ほど触れた負債解消枠の三割でリプレース作業を進める必要がありました。「三割の枠でできる限りのことをやる、それ以上のことはできない」という制約があったため、ある意味、優先順位がつけやすかったのかもしれません。
またFlutterが信頼できる技術であることを、部分的にリプレースを行うことで証明する取り組みも行っていました。Flutterでリプレースしたものをいきなり100まで作り上げてリリースするのではなく、既存のiOSやAndroidのアプリにFlutterで作った機能を混ぜ、少しずつリリースすることで、技術の安全性に対する信頼を積み重ねていきました。ちょっと大変ではありましたが、リスク分散を兼ね、「本番環境でリリースしても大丈夫だよ」と実績を重ねながら、かつ機能開発も進めながら進めていきました。

Q：他の皆さんは、どんな役割を果たされたのでしょうか。

西野：先ほど山本さんが、既存のアプリの一部にFlutterで開発した機能を組み入れて少しずつリリースしたと説明しましたが、まさにそのネイティブアプリにFlutterを組み込む土台の設計や実装を担当しました。当初は「ちゃんと動くかな」と不安なところもありましたが、QAエンジニア（Quality Assurance Engineer）の方々と調整し、さまざまな端末で検証しながら進めることで安全に部分的なリプレースができました。

山本：7月に正式に開発がスタートした後、9月ごろにはAndroidアプリに混ぜたものをリリースし始めることができました。これだけ早いタイミングで実現できたのは、西野さんに手伝ってもらったおかげだと思います。

福岡：自分は、並行して進んでいたエンハンス開発を主に推進していました。負債解消枠でFlutter移行を進める一方で、iOS、Androidネイティブコードでの新規開発も進んでいました。そこをリードしながら、リプレースをメインで行うメンバーがなるべくFlutterに力を注げるように自分はエンハンスの方に集中しました。

Q：縁の下の力持ちというか、どちらが欠けてもいけない役割ですよね。

濱田：自分はQAチームやTPM（Technical Program Manager）の方々とのやりとりを担当しました。iOSとAndroidとでは、既に実装されていたアプリ仕様に細かな差があったり、OSの違いでアプリの表示や挙動が違う部分が出てきます。Flutterで1つのコードベースにするときにどちらにすべきかを、過去の経緯を調べたり、TPMの方々と相談しながら取りまとめていきました。

山本：新しい技術を用いて設計から実装まで自分たちでできるのはとても贅沢な体験です。それを可能にした方々にもすごく感謝しています。

Q：それぞれが役割をしっかり果たしていったことで、Flutterへのリプレースがうまくいったわけですが、さらに成功の要因を挙げるとすれば何でしょうか。

若宮：リプレースである以上、今あるすべての画面を作り、既存のネイティブアプリとほぼ同じものを作らなければなりません。実装に関しては山本さんがリードし、「この画面をこの順番で作っていけば、後で確認しやすいはずだ」と計画を作ってくれました。
これらを表側の画面の開発と呼ぶのであれば、アプリ全体で共通に利用する下回りの機能が裏側になります。この裏表で開発を分担し、うまく調整してもらったことで、「誰かの作業を待たなければ、自分は手を動かせない」というブロッキングが生じることなく開発できました。それがスムーズに進んだ大きな要因かなと思います。

山本：もう一つ、最初の方でパワープレイ的にものすごい速度で画面を実装していったことも効いたかもしれません。テスト環境での検証中、動くものをぽんぽん作っていき、触れてみて「この挙動は既存アプリと違うな」という部分があれば修正するサイクルを、早いタイミングで何回も回すことができました。これもリリース後に大きな不具合が出なかった理由ではないかと考えています。

Q：話はいいから、動くものを作ろうという意味でスタートアップっぽい動きでしたね。

山本：そうですね。よくある話ですが、今回はリプレースと言いつつも既存アプリの仕様書はありませんでした。今動いているコードが仕様書ということで、コードを一つ一つ見ながらFlutterに置き換えていきました。最初から完璧なものを作ろうとしても無理な話で、漏れは起きるだろうという前提で、まずはいったん動かしてみて、想定と違う部分が出てきたらそこで直そうというサイクルで進めました。

Q：間違っていることを過度に恐れず、試してみるマインドが大切なように感じました。

山本：約1年半という息の長いプロジェクトということもあり、最初の頃は「本当にこのスピードで進捗は大丈夫なのかな」と不安を感じることもありました。けれど、だからこそ「今できる最善のことは手を動かし、動くものを作ることだ」と、特に序盤はすごい速度で実装していったように思います。不安だからといって手を止めてまでスケジュールを見直すよりも、手を動かしていき、実際に問題が起きたら修正する、という方向で進めました。もちろん最初にしっかりとしたスケジュールを作ること自体は不可欠ですが、スケジュールの節目までは目の前の実装に集中するというのが気持ちの上で大事だと思います。

渡辺：実は過去に一度、Flutterへのリプレースにチャレンジして頓挫したことがありました。今回は、私がこの先三年間は責任持って進めますと宣言し、さらにプロジェクトの推進については山本さんが、コード品質は若宮さんが、仕様面は西野さんが、エンハンス面は福岡さんが、濱田さんは仕様差分に責任を持って進めてくれました。メンバー全員が各々のタスクにきちんと責任を持ち、進めてくれたおかげだと思います。

Q：リプレース終了後の効果は感じていますか。

山本：Androidは2023年8月に、iOSも12月に完了しました。やはりFlutterはとても完成度が高く、コミュニティ活動も活発でどんどん進化している技術であり、安心感や開発体験の良さを感じています。
また、以前はiOSとAndroidとでチームが分かれていることもあり、ソースコードも違うし、ミーティングも別々でした。それが一つのソースコードにまとまったことで、皆が同じソースコードを見て同じ認識を持ち、話し合えるようになり、チームとして一本化されたと感じています。議論もより活発になって生産性もすごく上がっていると思います。iOSとAndroidとで差分が出る確率も下がり、運用面でも工数が下がっていると思います。

若宮：チームにポジティブな影響があっただけでなく、ユーザーにきちんと使われていることにも安心し、嬉しく思っています。

Q：それぞれ個人として、やりがいや成長を感じたところはありますか。

山本：自分は外からやってきた人間で、技術力も、どういう人間かもよくわからない状態にも関わらず、「やりたい」と言ったらそこにアサインしてもらえ、最終的にはプロジェクトのリーディングまで任せてもらうほど大きな裁量を持たせてもらえたことに感謝しています。率先して動けば、大きな裁量を持ってやりたいことがやらせてもらえる環境であり、楽しみながら仕事ができる場所だと思います。

渡辺：やらずに済ませるよりはやってみて、うまくいかなければ謝ればいいという組織風土が根本にあるかもしれません。特にまなび組織に関しては「やってみればいいじゃん」という文化が浸透していますよね。

濱田：自分も今はFlutterでコードを書く立場になりましたが、皆さんのコードを見るにつけ、非常に読みやすく、本当に責任感を持って作られているなと感じています。この先、もしかしたら負債になるかもしれないな、というニオイも共有しつつ、新しい機能を追加しているところですが、Flutterそのものも開発者としても本当に勉強しやすい環境だなと思っています。

福岡：コードレビューを皆で協力して素早く行うなど、様々な工夫をして、開発しやすい環境になっていると思います。自分はこれまで複数のチームでの開発を経験させていただきましたが、その経験を踏まえても、今のチームは、開発環境の面でも、人のコミュニケーションの面でもとてもやりやすいと感じています。

西野：転職経験者も多く、外のいろんな雰囲気やいいところを持ち込んできてくれるので、いい意味で、常に新鮮な環境になっていると思います。

Q：今後、どのようなことにチャレンジしていく予定でしょうか。

若宮：今回はAndroidとiOSのアプリをFultterで一つにしましたが、WebページもFlutterで作ろうというプロジェクトを今進めています。AndroidとiOS、Webページと三つのチームに分かれていたのが一つになり、これまでモバイルアプリをメインで開発していた人がWebページも作るようになるという、より広い挑戦です。私たちのチームの名称からも「モバイル」が取れ、「クライアントグループ」という一つのチームとして、一つのサービスをきちんと作っていくことに正面から取り組んでいきます。

西野：iOSとAndroidの二つをFultterに置き換える取り組みは世間でも見聞きするようになってきたのですが、これに加えてWebも置き換えるのはチャレンジングな取り組みです。それをポジティブに捉え、楽しみにしています。すでに動作するレベルのものはできており、どんどん開発を進めているところです。

若宮：一歩進んだ取り組みであり、コミュニティに対しても、Flutterエンジニアにもアピールできることだと考えています。

記事中で紹介した事業（名称や内容含む）や人物及び肩書については取材当時のものであり、現時点で異なる可能性がございます。