MIXIのiOSアプリ開発最前線〜みてね・minimo・TIPSTARのエンジニアに”今”聞いてみたいこと〜
めまぐるしく変化するモバイルアプリ開発。日々新たな技術や開発言語が登場する中で、開発現場のエンジニアたちはどのような視線でそれらの変化を捉えているのでしょうか。
現場のリアルな声をお届けするべく、『家族アルバム みてね（以下みてね）』から飯塚、『TIPSTAR』から寺田、『サロンスタッフ予約アプリ minimo』から穴水の、3人のiOSエンジニアにインタビューを行いました。
本インタビューでは、MIXIの各サービスの最前線にいるiOSエンジニアに聞いた最近の取り組みから、”今” iOSエンジニアに聞いてみたい3つの質問、目指す理想のエンジニアの姿までを座談会形式でお届けします。
みてね・minimo・TIPSTARにおける最近の取り組み
━━みなさんの業務内容と、各サービスの取り組みについて教えてください
穴水（minimo）：私は、今年10周年を迎える「サロンスタッフ予約アプリ minimo」のメンバーで、現在は開発業務はあまりやっていません。では何をしているのかというと、主にminimoのモバイルアプリ全体の技術的負債解消のための戦略を立て、舵取りをする役目を担っています。また、メンバーの担当しているタスクの仕様や設計をどう実現するかについてや、ユーザーからの問い合わせ対応の優先順位づけなどの相談に乗るサポート的な業務もあります。
最近では、Androidアプリのフルリプレイスを決定し、目下Androidエンジニアのメンバーにリプレイス作業を進めてもらっています。iOSについては、どのような方針で動くか検討中です。
━━アプリ開発全体の技術的負債解消のための戦略を練るポジションにいらっしゃるんですね。
寺田（TIPSTAR）：僕は、TIPSTARという、友達と一緒に競輪やオートレースなどへのベッティングを楽しむことができるアプリのiOSエンジニアをしています。
TIPSTARはところどころでUnityを使って開発しているのが特徴で、昨年末にリリースした「すごろくダンジョン」という新機能もUnityで開発しました。ネイティブのコードからUnityを組み込みのライブラリとして呼び出して、Unityの画面を出すという構造になっています。
━━複雑なつくりになっていそうですね。
飯塚（みてね）：僕は「家族アルバム みてね」のエンジニアで、iOS開発をメインとしつつ、Android開発をやることもあります。デジタルアルバム機能など、みてねの基礎部分の機能開発を担うDADチームに所属しています。
みてねのiOS開発では、2、3年ほど前からSwift Package Managerを使ったマルチモジュール化を進めています。最近では、UIのモジュールを切り出して単体でビルドできるようにすることで、Xcodeのプレビューを高速化して、開発速度を向上させることに取り組んでいます。
穴水（minimo）：マルチモジュール化では、共通処理をどこに置くかという問題があると思いますが、どんな考え方をされましたか？
飯塚（みてね）：モジュールを縦に分割すると共通処理が発生すると思うのですが、みてねの場合は横のレイヤーで区切っています。そのため、その問題はまだ発生していません。現状はあくまでも依存関係の厳格化を主な目的としたマルチモジュール化という位置づけになっていますね。
穴水（minimo）：なるほど。そこを強制するためのマルチモジュール化なんですね。
”今” iOSエンジニアに聞いてみたい3つの質問
ここからは、「”今” iOSエンジニアに聞きたいこと」をテーマに、3つのトピックについて詳しく聞いていきます。
コード生成AIツールの利用状況
━━ここからは座談会的に、さまざまなテーマでお話を聞いていきたいと思います。まずは各サービスにおけるAIの活用状況をお聞きしてもいいでしょうか？
穴水（minimo）：minimoでは、今まさにGitHub Copilotを導入するための体制を整えている最中です。移行作業が終わったら、活用できる箇所では積極的に使っていけるよう、本格的に導入を検討する予定です。
飯塚（みてね）：みてねでは既に使える状況になっていて、体感ではエンジニアの1/3〜1/2くらいが利用申請を出して使っていると思います。ですが、僕個人としてはまだ使っていません。
穴水（minimo）：学習がWebベースな気がするので、学習ソースの少ないiOSでどこまで使えるコードが生成されるのか気になりますよね。
飯塚（みてね）：そうですね。Rubyを使っているメンバーからはポジティブな声を聞きますが、iOSエンジニアからはまだそういった声は聞いてないです。
寺田（TIPSTAR）：TIPSTARでは、事業部全体でかなり使っているメンバーが多いですね。特にWeb開発の方でかなり活用しているようです。アプリ開発では、僕個人としては、スニペットや数行単位でサジェストしてくれるものを使ってみています。レイアウトを組むなど、定型的な内容に関してはそれなりのものをサジェストしてくれる印象です。ファンクション単位ではまだ試せていませんが、AIの活用によって一応タイピング数は減っている、という状況ですね（笑）
新しい技術を導入する際の姿勢
━━AIに限らず、新たな技術が次々と登場していますよね。こういった新しい技術を導入するタイミングはどう判断されていますか？
飯塚（みてね）：みてねのアプリ開発では、Appleが提供する機能であれば前向きに検討することが多いです。ただし、いきなり全て導入するわけではなく、場合によっては現状維持する箇所もあります。例えばSwiftUIなら、画面遷移周りはまだ実運用面での課題も多かったため、その部分だけUIKitを維持するような方法を取りました。
導入のタイミングは、新しい技術が出た2〜3年後くらいになることが多いです。というのも、サポートOSのバージョンの関係で新しく出た技術をすぐに導入することが難しくて。そのため、発表から導入までの期間は他社事例を見つつ、知見をためているような状況です。
穴水（minimo）：minimoでは少し違う考え方をしているかもしれません。現在minimoのアプリ開発全体で技術的負債の解消に取り組んでいるところなのですが、特にAndroidアプリで一部だけに新しい技術を導入した箇所がいくつもあり、そこが大きな技術的負債となっています。メンテナンスコストもかかりますし、新旧両方のバージョンを知っている人でないと触れないコードになっているんですよね。
結果的にAndroidをフルリプレイスすることになったという事情もあり、リスクヘッジを重要視して、新しい技術が出ても一旦様子見することが多いです。みてねと同じく他社事例を見つつ、最後まで導入し切れるか？導入戦略が作れそうか？などを慎重に見極めるという方針です。
飯塚（みてね）：それで言うと、サポートOSが切れるまでの2〜3年のラグが、みてねの開発メンバーにとっても、ちょうどいい見極め期間になっていると思います。また、みてねでも小さく始めることを意識して、試しに一画面作ってみて現状の課題やメリデメを洗い出した上で導入するなどのステップは踏んでいますね。
寺田（TIPSTAR）：新しい技術を使うには、古いバージョンのサポートを切ることも必要になってきますよね。リリースから1年後には最新バージョンを使っているユーザーが7、8割だと思うので、保守的に考えても2年前のバージョンまでを残しておけば十分だと考えています。
新しい技術の導入としては、Apple公式が推奨しているものやリスクの少ないものはどんどん進めるようにしています。特にApple公式から推奨されているものは、突然古いバージョンのサポートが終了してしまうこともあるので、早め早めに動くことが多いですね。Swiftのバージョンアップについても、コードが書きやすくなるものなどはほとんどノーリスクなため、すぐに取り入れています。
Flutterの盛り上がりについてどう思う？
━━近頃はFlutterで開発されているサービスも多いですが、皆さんはFlutterでのプロダクト開発についてどう考えていますか？
寺田（TIPSTAR）：世の中のトレンドでもありますし、新規プロダクトの開発時に、iOS/Androidの両輪かつ高速で開発を進めたいのであれば選択肢に入ってくるかなと思います。プロジェクトの規模感やメンバーの数にもよりますよね。
穴水（minimo）：Androidのフルリプレイスを検討した際に、ストアリリースやプロジェクト設計など、要所要所ではネイティブアプリ開発の知識が必要になるという話をいろいろな方から聞きました。寺田さんがおっしゃったように、少ないメンバーで多くの価値を提供することにフォーカスするのであれば、Flutterも良い選択肢だなと思います。
ただ、既存サービスでは既にメンバーが揃っていることが多いため、わざわざFlutterに移行するメリットは小さいかもしれません。プロダクトの時期によって意思決定が変わってきそうですね。
━━今後需要が高まることを見据えて、Flutterエンジニアのキャリアを選ぶ可能性もありますか？
穴水（minimo）：私はまだ様子見をしています。KMPのロードマップにおいて、iOSでもComposeが使えるようになると公開されているため、今後KotlinでもiOS/Android両方のUIを実現できるようになるかもしれません。Flutter以外のクロスプラットフォームの選択肢が増えることで、どのような変化が生まれるのか注意深く見ていきたいです。
寺田（TIPSTAR）：既にWebが立ち上がっているものと同様の動きをするアプリをリリースしたい場合は、ほとんどフロントエンド開発だけになると思うので、Flutterでかなり効率化できると思います。一方で、アプリ固有の価値を重視しているサービスの場合は、まだまだネイティブの知識が必要だという印象です。
━━Flutterエンジニアとはいえ、ネイティブアプリの知識も必要なんですね。
飯塚（みてね）：Flutterはプライベートで少し触ったことがあるぐらいなのですが、Flutterエンジニアの採用が難しいとたまに聞きますね。
穴水（minimo）：ネイティブの知識をそれなりに持っていて、かつFlutterも書ける人となると少しハードルが上がると思っています。minimoもFlutterを採用しなかった一因として採用の課題がありました。
寺田（TIPSTAR）：Flutterの諸々の課題というのは、時間が解決する話か、それとも本質的な違いか、どちらなのでしょうね。Swiftもリリース当初はそこまで評価されず、Objective-Cに戻るような方もいました。ですが、今ではSwiftがiOSアプリ開発のスタンダードになっています。いつの間にかFlutterが主流になる未来もあるのかなと考えてしまいますね。
穴水（minimo）：開発言語的にはすごい勢いで成長していますよね。現状、ユーザー体験の側面ではネイティブアプリに軍配が上がる気がしますが、将来的には分からないと思います。2本指での高速スクロールなど、Flutter固有の機能を活用してネイティブアプリよりも良い体験を提供できる場合もありますね。
━━数年後に、答え合わせしたいですね。
寺田（TIPSTAR）：その時には、もうAIが僕らの仕事を全部奪ってくれているかもしれませんね（笑）
MIXIのiOSエンジニアが目指すエンジニア像とは
━━最後に、目指すエンジニア像について教えてください。
飯塚（みてね）：普段注目されないけど実は重要なことに目を向けて、そっと改善してあげられるようなエンジニアになりたいです。その実現のために、やった方が良いと思いつつ放置されていたことに取り組んでみたり、現在進行系でデザインシステムの改善をチームを組んで動かしていたりします。
みてねには、新技術の導入やキャッチアップに精力的な頼もしいメンバーがたくさんいます。そのため、自分は新しい技術へ目を向けつつも、チーム全体を見た時に価値が最大化するような働きをしていきたいです。
穴水（minimo）：私は、ユーザー体験こそがモバイルアプリの強みだと考えています。そのため、そこを意識した価値提供をしていきたいですし、専門性を持って取り組みたいポイントでもあります。
あとは、これまで改善思考で物事に向き合ってきたので、今後もObserve（観察）、Orient（方向づけ）、Decide（意思決定）、Act（行動）のOODAで改善サイクルを回すことを意識したいです。全てを「改善できるかも」という視点で見れば、何かしら気づくことがあるかもしれません。それが自分が精通していない分野であれば詳しい人に相談すればいいですし、改善のきっかけを作れるよう、そういった視点を持つことを大切にしたいです。
寺田（TIPSTAR）：僕は、いつの間にかアプリ開発を始めて15年も経っていました。その間ずっと自分のコアとしてきた行動指針として、UI/UXの専門家としてきちんと意見するということがあります。特に、アプリの画面に関しては誰よりも長く見てきたという自負があります。
MIXIにはWebサービスに長く携わってきた方が多いです。そのため、アプリのUI/UXをやってきた自分ならではの知見を共有できるように努めていますし、これからもそうありたいです。
MIXIでは様々な事業やポジションで仲間を募集中です。
こちらの記事を読んでいただき、MIXIで働くことに興味を持ってくださった方がいましたら、ぜひ採用情報をご覧ください。MIXIエンジニアの公式X（旧：Twitter）でもMIXIで扱う技術やエンジニアに関する情報など、随時発信してますので、フォローしていただけると幸いです。
それでは、最後までお読みいただき、ありがとうございました！
