MIXIは、2024年8月3日（土）〜8月4日（日）に開催されたSRE NEXT 2024にダイヤモンドスポンサーとして協賛しブース出展を行いました。本記事では当日ブースで実施したアンケートの集計結果を中心に、ブースの様子をお伝えしていきます🙌

開発本部 CTO室 SREグループ多羽田が登壇しました

『徹底的な自動化とトイルの撲滅で実現する効率的なSREの実践例』と題して、開発本部 CTO室 SREグループの多羽田が登壇いたしました。

MIXI GROUPではさまざまなサービスを提供しており、各サービスで公式サイトやキャンペーンのLPなどを準備する必要があります。コーポレートサイトをはじめとした、これら数十のウェブサイトは、横断組織である開発本部 CTO室 SREグループによって構築・運用されています。

SREグループでは、それらのサイトを少人数で運用していくための基本方針として「自動化とトイルの削減」「共通化・標準化」「システムに対しての割り切り」を掲げており、本発表では、多羽田がその具体的な実践内容についてお話しました。

👇詳細は登壇資料をぜひご覧くださいhttps://speakerdeck.com/bbqallstars/che-di-de-nazi-dong-hua-totoirunopu-mie-deshi-xian-suruxiao-lu-de-nasrenoshi-jian-li-sre-next-2024

MIXIの出展ブースのご紹介

ブース運営を手伝ってくれたMIXI SREs

今回、ブース運営を手伝ってくれたのは、開発本部 CTO室 SREグループの多羽田（@bbq_all_stars）、同じく開発本部 SREの大野（@i2tsuki_）、みてねプロダクト開発部 プラットフォームグループ 杉本（@kohbis）でした。

3人とも勉強会やカンファレンスへ参加慣れしていて、特に何もお願いせずとも（ぇ）、ブースにいらっしゃった方々にアンケートをご案内したり、ノベルティ類を配ってくれたりしていました🙌 感謝！

ノベルティ＆スタンプ

ノベルティとして、ラングドシャクッキーと缶バッジを用意しました。参加者の方から好評かつ個人的にとても美味しかったので、また機会があればお願いしたいと思います。

缶バッジはアンケートと連動させた5種類の柄を準備しました。ほとんどの方がアンケートで選択した領域のバッジを選んでいたのですが、少しだけ結果が偏ることになりました😂 気になるアンケート結果はこのあとご紹介します。

アンケートの集計結果

DAY1とDAY2でそれぞれ異なるアンケートを実施しました。ここでは、各アンケートの結果をご紹介します。

<DAY1>

• いまSREチームを再度立ち上げ直すならどうする？
• SREの立ち上げで悩んでいる/困っていることは？
• あなたが「ワクワクする」領域は？

<DAY2>

• SREチームとして導入したものの中で、一番効果が出たと感じたことは？
• あなたが「助けて欲しい」領域は？

DAY1：①いまSREチームを再度立ち上げ直すならどうする？②SREの立ち上げで悩んでいる or 困っていることは？

👇①のアンケート結果

既にSREに取り組まれている方向けのアンケート結果としては、チームの文化づくりや、ビジネスサイドおよび開発チームとの協業に注力したいという意見が大半でした。SREとしてサイトの信頼性向上に取り組む前に、SREの意義を周囲のメンバーに理解してもらい、協力体制を築き上げることがいかに重要であるかがよく分かる結果になっています。

◎文化づくり・Enablement（10件）

• SRE文化醸成×2
• チーム（会社）を辞めない文化
• SREの定義づくり
• SWEとSREの役割について言語化する
• SREの役割を全社的に啓蒙
• SREの啓蒙
• Enablementをがんばる
• ケイパビリティベースの職能横断チームにSREingを伝授していく
• ストリームアラインドとしての文化醸成

◎ビジネスサイドとの協業（8件）

• ビジネス部門に初期から説明する
• 責任者への説明をしっかりやる
• ビジネス側ともっと一つになる
• PdMとタッグを組む
• ビジネスサイドと組む
• ビジネス、PdMとの協業をより強化する
• ビジネスKPIとSLOの連携
• エンジニアじゃないチームとうまくやる

◎採用（7件）

• 2人目を採用する×2
• もう一人プレイヤーが欲しい×2
• 採用をもっとがんばる×2
• SREのエキスパートを採用する

◎開発チームとの協業（5件）

• 開発チームの話をちゃんと聞く
• 開発チームと目指したいゴールの目線を合わせる
• アプリチームと協業できる体制をつくりたい！
• プロダクトチームの協力者を募ったり育成したり
• 現場の仲間をチームに入れておく（多めに）

◎その他（11件）

• やることとやらないことを分別する
• 片手間じゃなく時間を使って初速を出す
• えらくなって権限を持つ！
• SREとして働きたい
• ポストモーテムする
• システムの安定を目指すSREチームが欲しい
• 統計をまじめに勉強する
• 現状理解
• SREingのケイパビリティを与える
• わたしがリーダーをやる
• セキュリティツールの導入

👇②のアンケート結果

これからSREに取り組む方/現在立ち上げ中の方に対するアンケート結果としては、採用や育成など、人員不足に関連した意見が目立ちました。採用に関しては①の質問でも複数回答いただいていたため、それぞれのフェーズに共通の課題であることが分かります。一方で、②では文化づくりに関する意見が4件と①と比較して少なくなっています。立ち上げフェーズでは、文化づくりの重要性は理解しているものの、実務が多く啓蒙活動に手を回す余裕がないなどの課題を抱えていそうだと感じました。

◎採用（11件）

• 人材不足・SRE採用×11

◎SLI/SLO（7件）

• SLI/SLOの決め方+4
• SLI/SLOの理解
• マルチテナントのデータ量が違うときのSLI/SLO
• SLOの実装

◎SREのロールが不透明（5件）

• 間に落ちたタスクがすべてSREに来る×2
• SREがやってくれるんでしょ？感がある
• 何でも屋になりつつある
• つよつよにSRE業務が吸収されている
• ロールの明文化

◎ビジネスサイドとの協業（5件）

• ステークホルダーとの調整
• ビジネス側に重要性を理解してもらうのが大変
• 経営の理解
• 予算×2

◎育成（4件）

• 教育×3
• SREの育成

◎文化づくり・Enablement（4件）

• メンバーへの文化の醸成
• Enabling SRE
• DevOpsの加速（インフラ部分も開発にやってほしい）
• 開発チームとの連携

◎業務量が多い（3件）

• やることが多い×3

◎課題解決（2件）

• 課題設定
• 課題解決力

◎その他（13件）

• 仕様が分かる人がいない×2
• 立ち上げ以前の問題！他社ベンダーが構築したIaC
• E2Eの方針整えたい
• オブザーバビリティ基盤の整備
• Grafanaが職人芸
• 上モノのアプリが難しい
• SREのやる気維持
• SREと組織的連携
• マネージドサービスへの移行
• SREタスクとの優先順位付け
• チームのマネジメント
• さまざまな会社でのSRE文化の発展

DAY1：あなたが「ワクワクする」領域は？

こちらは、「監視・分析」「インシデント対応」「パフォーマンス改善」「信頼性向上」「自動化・効率化」の5つの領域から、ワクワクする領域を選んでいただくアンケートです。

このアンケートへの回答結果は下記で、自動化・効率化やパフォーマンス改善など、比較的開発業務に近しい領域へ票が集まる結果となっています。インシデント対応は、一部の方々から「アドレナリンが出るのである意味ワクワクする」といったご意見をいただきました🙌笑

＜集計結果（全139票）＞

• 監視・分析：26票
• インシデント対応：20票
• パフォーマンス改善：33票
• 信頼性向上：15票
• 自動化・効率化：44票
• その他：1票

DAY2：SREチームとして導入したもののなかで、一番効果が出たと感じたことは？

👇アンケート結果

このアンケートへの回答では、可視化に関連するコメントが一際多い結果となりました。その他にも、自動化やSLI/SLOの定義など実務的な要素に関するコメントが多い中、文化づくりの一環と言える輪読会を挙げる方も数名いらっしゃいました。

中でも、「Enterprise Roadmap to SRE」は、SREへの取り組み方の実践的なステップが分かるドキュメントとのことで、ブース運営に入ってくれたエンジニアメンバーの杉本からも「これいいですね」という声が出ていたので、私も読んでみようと思っています👀！

◎可視化・オブザーバビリティ関連（17件）

• 可視化（DataDog）×4
• 可視化（Grafana） ×2
• 可視化（New Relic）×2
• 可視化（Sentry）
• 可視化（ダッシュボード構築）
• 可視化
• オブザーバビリティツールの導入
• テナント別レイテンシダッシュボード
• 信頼性ダッシュボード
• メトリクスの可視化とモニタリングの運用
• Tracing導入
• モニタリング定例会

◎自動化・生産性向上（10件）

• トイル削減×3
• トイルの可視化
• AWSとGit（自動化）
• CI/CDの効率化＆実行履歴の通知
• CI/CD 導入・効率化
• CI導入サポート
• デプロイの自動化
• Runbookの整備

◎インシデント・アラート関連（9件）

• ポストモーテム×3
• ポストモーテムをみんなで読む
• インシデントコマンダーの実践
• インシデントレスポンス
• PagerDuty導入（アラートの整理も）
• アラートのリッチ化
• 不要なアラートの削減

◎クラウドの導入（5件）

• IaC×3
• クラウドに身を任せる
• EKSによる共通基盤の構築

◎SLI/SLO（4件）

• SLI策定
• SLOの導入
• SLOによる定量化
• SLI/SLOの定義

◎輪読会（4件）

• SRE本の輪読会×3
• Enterprise Roadmap to SREの輪読会

◎ツールの統一化（2件）

• ツール統一
• プロセス・ツールの統一（標準化）

◎その他（10件）

• 深夜のアラートが少なくなった
• 継続的プロファイル
• 私がお客様の支援に入ったこと！
• 「SRE」という名前をチーム名に付けたこと
• スクラム
• PR-Agent（AIによるコードレビューツール）の導入
• 共通負荷試験、クライアント基盤
• 配信メールのサービス横断監視
• パフォーマンスの定期レポート
• 他チームがSRE用語を使うようになった

DAY2：あなたが「助けて欲しい」領域は？

DAY1とは趣向を変えて、最も困っていて手助けを必要としている領域を聞きました。DAY1とは反対に、監視・分析やインシデント対応の票が多い結果となりました。

＜集計結果（全67票）＞

• 監視・分析：14票
• インシデント対応：14票
• パフォーマンス改善：12票
• 信頼性向上：11票
• 自動化・効率化：13票
• その他：3票（セキュリティ対策、技術負債の解消、人的インシデント対応）

集計結果は以上となります✏️

おわりに

最後に、今回もMIXIからたくさんのエンジニアがSRE NEXT 2024に参加しました。毎年、セッションや参加者のみなさまとの交流からさまざまな刺激を受け、自らのチームに還元してくれています。

運営、そして登壇者のみなさま、今年も素晴らしい機会をありがとうございました！

・・・

最後に、公式のX(旧Twitter)アカウントでもMIXIで扱う技術やエンジニアに関する情報など、随時発信してますので、フォローしていただけると幸いです。

それでは、最後までお読みいただき、ありがとうございました！

MIXIはSRE NEXT 2024に協賛しました！出展ブース＆アンケート結果をご紹介します was originally published in MIXI DEVELOPERS on Medium, where people are continuing the conversation by highlighting and responding to this story.

今回、iOSDC Japan 2024の参加者へのノベルティとして、MIXIではチラシを用意しました。また、公式パンフレットにも記事を掲載させていただいております。カンファレンスの参加者以外の方々にもMIXIのエンジニアの考えを知っていただけたらと思い、本記事ではチラシやパンフレットの中身を簡単にご紹介させていただきます。

また、iOSDC Japan 2024に参加中のみなさまへ向けて、『iOSDCチャレンジトークン』も記事内に掲載しております😍❣️ トークンをお探しの方は、ぜひ最後まで読んでみてくださいね。

iOSDC Japan 2024について

▼イベント概要

開催日：8/22（木）〜8/24（土）
場所：早稲田大学理工学部西早稲田キャンパス （東京都新宿区）
イベントサイト: https://iosdc.jp/2024/

また、今年は新たな催しとして、『iOSDC Japan 2024 Swiftコードバトル』が開催されるもようです👀

「Swiftコードバトルはお題で指示された動作をするSwiftコードをより短く書けた方が勝ち、という競技です。 お題は決して難しいものではなく、少し練習すればSwiftプログラマであればどなたでも参加できる難易度を目指しています。」引用元：https://iosdc.connpass.com/event/326837/

まずは8/12（月）に予選が開催され、勝ち残った方はiOSDC Japan 2024会期中に開催される本戦に出場が可能となるようです！！ぜひ、興味のある方は参加してみてくださいね🔥

チラシのコンテンツをご紹介──iOSエンジニアへの2つのQ&A

今回、iOSDC Japan 2024の参加者への配布物として、MIXIではチラシを用意し、4名のiOSエンジニアに聞いたiOS開発に関するQ&Aを掲載しました。

●「現在注目しているiOS開発のトレンド」と「iOS開発でわくわくする瞬間」

みてねプロダクト開発部の轟、佐藤、hicka04、開発本部 たんぽぽ室 たんぽぽグループの久野の4名に上記2つの質問に答えてもらいました。「現在注目しているiOS開発のトレンド」では、Xcodeのアップデート内容やWWDC24で発表された内容、そしてiOSのアーキテクチャなどについての回答がありました。同じ会社や事業部で働いていても、各メンバーが違ったことに注目していることがわかり、それぞれの個性が出ていて面白いなと思います。

ぜひ、チラシ本文を読んでいただけたら嬉しいです！

パンフレットのコンテンツをご紹介──iOSエンジニアの座談会トーク

iOSDC Japanが公式で出しているパンフレット記事には、「新しい技術への向き合い方」をテーマに、MIXIのiOSエンジニアの座談会トークを掲載しております。パンフレット記事も、ぜひご覧いただけると幸いです🙌

チャレンジトークンはこちらっ💁‍♀️

iOSDC Japan 2024 の開催まで残り2週間を切りましたね！

毎年オフライン会場が大盛り上がりしているので、iOSエンジニアで集まってワイワイしたい方はぜひ参加してみてください。オフライン、オンライン問わず、参加される方はタイムテーブルの予習を忘れずに😎

そして・・iOSDCチャレンジトークンのお知らせです！

・・・

株式会社MIXIのエンジニアは、

#ユーザーサプライズファースト

なサービスを提供するべく、日々開発に取り組んでいます！

・・・

トークンはこの他にもノベルティのチラシ内に隠されています。ぜひ、隅々までチェックしてみてくださいね〜！

おわりに

MIXIではコミュニケーションを軸に多様なサービスを展開しており、その多くがiOS/Androidで開発したモバイルアプリを提供しています。今後もより良いサービスを提供し続けるために、iOSDCをはじめとした技術コミュニティの支援を通じて、業界の技術力発展に貢献できれば幸いです。

最後に、公式のX(旧Twitter)アカウントでもMIXIで扱う技術やエンジニアに関する情報など、随時発信してますので、フォローしていただけると幸いです。

それでは、最後までお読みいただき、ありがとうございました！

MIXIは今年もiOSDC Japan 2024にプラチナスポンサーとして協賛します＆チャレンジトークンはこちら💁‍♀️ was originally published in MIXI DEVELOPERS on Medium, where people are continuing the conversation by highlighting and responding to this story.

こんにちは。MIXIのDevRelの益山です！

MIXIは、SRE NEXT 2024にダイヤモンドスポンサーとして協賛させていただきます。本記事では、MIXIからの登壇情報、カンファレンスのMIXIブース運営メンバーが気になっているセッションをご紹介するとともに、当日のオフラインブースについてもチラ見せいたします。

SRE NEXT 2024 について

SRE NEXTは「信頼性に関するプラクティスに深い関心を持つエンジニアのためのカンファレンス」です。（引用元：https://sre-next.dev/2024/）

2022年の「SRE DIVERSITY」、2023年の「Interactivity」「Diversity」「Empathy」に続き、2024年のテーマは「Beyond NEXT」となっています。SRE活動が世間に浸透してきた今だからこそ、これまでのSREの枠組みを超え、新たな価値を創造していくような取り組みへフォーカスするような意思を感じました。

▼イベント概要

イベント名：SRE NEXT 2024
開催日時：2024/8/3–4（土日）
開催場所：Abema Tower
スケジュール：https://sre-next.dev/2024/schedule/#

MIXIから登壇するメンバーの登壇情報

MIXIからは開発本部 CTO室 SREグループの多羽田が登壇しますので、セッション情報をご紹介します🎉

『徹底的な自動化とトイルの撲滅で実現する効率的なSREの実践例』

本発表では、数十のウェブサイトを限られた人数で構築・運用するための徹底した自動化とトイルの撲滅手法を紹介します。

1. IaCのモジュール化とテンプレート化: terraformのテンプレート化により、大量のインフラを効率的に構築・管理する手法を解説します。
2. モノレポによるCI/CDの効率化: terraformコードをモノレポで一元管理し、CI/CDリソースを最適化した方法を紹介します。
3. 脆弱性の継続的な予防・検知・対応: アップデートツールやクラウドサービスを駆使して、脆弱性検知と自動アップデートを実現した手法を説明します。
4. モニタリングとアラート、障害対応: 少人数運用に必要十分なモニタリングとアラート設計、障害例とその対応について紹介します。
5. 信頼性を担保する組織体制: 少人数での運用を支えるルールや体制、組織との連携について解説します。

これら発表を通じて、少人数での運用の効率化と信頼性向上をどのように実現したかを共有します。

⏰ 登壇日時：8/4（日） 13:00–13:20
🌍 場所：TrackA
🗣️登壇者：開発本部 CTO室 SREグループ 多羽田 俊 @bbq_all_stars

MIXIのブース運営メンバーが選ぶ『SRE NEXT 2024』で気になるセッション👀

明日・明後日、MIXIのブースを盛り上げてくれる予定の運営メンバーに、『SRE NEXT 2024』で気になるセッションについて聞いてみました。

杉本 @kohbis（みてねプロダクト開発部 プラットフォームグループ SREチーム）

気になるセッション：工学としてのSRE再訪

SRE NEXT 2023ではyuuk1さんの『エンジニアのためのSRE論文への招待』を大変楽しく聴講させていただきました。

SRE関連のイベントは当然のことながら各社のプラクティスが多く、もちろん勉強になります。しかし他にはない角度からの「SRE」のお話を聞く機会は貴重なので、より一層楽しみにしております！

大野 @i2tsuki_（開発本部 CTO室 SREグループ）

気になるセッション①：Enabling Client-side SLO

サーバサイドの SRE では SLI/SLO の導入といったプラクティスや目指す先が確立されています。一方で、クライアントサイド (iOS, Android) の SRE では、経営課題やサービスにもよりますが SRE の導入によるゴールの設定はサーバーサイドとは違ったものになると思っています。MIXI でもモバイル向けに多様なサービスを提供していることや、私自身がクライアントサイドの信頼性にこれまで注目できていないため、事例の一つとして大変興味があります。

気になるセッション②：Becoming SRE — SREって何から始めればいいの？

7 年前に自分が SRE になったときは Web オペレーションエンジニアから、 SRE 本のプラクティスや考えを取り入れて信頼性に対してコミットメントを行なっていました。サーバインフラの専門知識を持ちながら SRE になったため、低レイヤの技術やアーキテクチャについて貢献したり責任を持つことが多いのですが、クラウドプロバイダーが提供するマネージドサービスが数多く普及しサービスアーキテクチャのパターンが多く例示される今、どのように SRE の分野に関わっていくことが求められるのか気になります。経営戦略として IaaS を使われることも多く、上位のマネジメントから見て SRE に何が求められているか、どのようにビジネスロジックとの棲み分けがされるのかといった色々な考えをオフライン限定の場で聞いてみたいです。

多羽田 @bbq_all_stars（開発本部 CTO室 SREグループ）

気になるセッション①：工学としてのSRE再訪

自分は元々機械工学系の学科でシステム工学などを学んでいたため、SRE における工学的なアプローチには度々興味がありました。SRE は主に文化的な側面と、実務的な側面が多く語られがちな印象ですが、一方で理論的・工学的に語られる側面はあまりないという印象です。そのため、工学的な視点で SRE を捉えるという本セッションは非常に興味を持ちました。

気になるセッション②：Central SREとEmbedded SREのハイブリッド体制で目指す最高のSRE組織

弊社でも「家族アルバム みてね」を始めとする Embedded な SRE 組織と、開発本部の Central な SRE 組織が混在している組織です。2つの組織が混在しているのは、利点もあれば欠点もあり、組織の形態として何がベストなのかは判断が難しいです。そのため、他社の事例を紹介しているこちらのセッションは、弊社での組織の形態を考える上で参考になるのではと思いました。

気になるセッション③：SRE文化の導入とプラットフォームの信頼性向上の取り組み

弊社の開発本部 SRE グループでは、事業部の支援の一環として、プロジェクトの開発メンバーとして参画して SRE 文化を根付かせるということを行なっています。この SRE 文化をチームに根付かせるというのは、チームやメンバーによっても方法が違い、決まった方法があまりないという印象です。こちらのセッションはその一つの事例として、どういう流れでチームに文化を浸透させ、定着させてきたのかという部分に興味を引かれました。

────

明日、MIXIブースではアンケートパネルとSREのみなさまに聞いてみたい質問をご用意しています。ブースメンバー一同、皆様とお話できるのを楽しみにしておりますので、ぜひ遊びに来てくださいね。

おわりに

MIXIでは、SNS「mixi」にはじまり、世界累計利用者数が6,000万人を突破した「モンスターストライク」（2023年6月時点）や、利用者数が世界で2,000万人を突破した「家族アルバム みてね」（2023年11月時点）など、さまざまなサービスを提供してきました。

数々のサービスを長期間にわたって運用してきた経験から、私たちMIXI GROUPではSREの重要性を深く実感しています。SRE NEXTへのスポンサーを通して、SREコミュニティとの連携を強化し、SREコミュニティの発展に寄与できれば幸いです。

それでは、明日みなさまとお会いできるのを楽しみにしております！！

MIXIは SRE NEXT 2024 にダイヤモンドスポンサーとして協賛＆1名登壇します！ブース運営メンバーが気になるセッションもご紹介 was originally published in MIXI DEVELOPERS on Medium, where people are continuing the conversation by highlighting and responding to this story.

2024年6月22日（土）に開催されたKotlin Fest 2024 に、MIXI はことりスポンサーとして協賛いたしました。

MIXIのブースでは「Kotlinクイズ」を実施し、午前・午後あわせて200回以上の回答をいただきました。ブースに遊びに来てくださったみなさま、ありがとうございました！

本記事では、出題したクイズの解答と解説および正答数の分布、そして当日のMIXIブースについてご紹介させていただきます。

クイズ

まずは、今回出題したクイズの解答と解説をご紹介します。クイズは午前と午後で3問ずつ出題しました。

午前：1問目

問.以下のコードの実行結果は次の選択肢のうちどれでしょうか？

import kotlinx.coroutines.delay
import kotlinx.coroutines.flow.MutableStateFlow
import kotlinx.coroutines.flow.combine
import kotlinx.coroutines.flow.map
import kotlinx.coroutines.flow.update
import kotlinx.coroutines.runBlocking
import kotlinx.coroutines.withTimeoutOrNull

fun main() {
    val f1 = MutableStateFlow(0)
    val f2 = MutableStateFlow(1)

    runBlocking {
        withTimeoutOrNull(1000) {
            f1.map {
                f2.update { 2 }
                delay(500)
                3
            }.combine(f2) { f1, f2 ->
                f1 + f2
            }.collect {
                println(it)
            }
        }
    }
}

選択肢

1. 「1」, 「2」, 「5」の順に表示される
2. 「2」, 「5」の順に表示される
3. 「3」のみ表示される
4. 「5」のみ表示される

正答：「5」のみ表示される

解説

StateFlowは最新の値が流れてきます。そのため5のみ表示されます。

午前：2問目

問.以下のコードはBroadcastReceiverで受け取ったIntentをFlowに変換するコードです。[ ※※※ ] に入る文字は次の選択肢のうちどれでしょうか？

override fun onCreate(savedInstanceState: Bundle?) {
    val intentFlow = [ ※※※ ]<Intent> {
        val receiver = object : BroadcastReceiver() {
            override fun onReceive(context: Context, intent: Intent) {
                trySend(intent)
            }
        }
        registerReceiver(receiver, IntentFilter("SAMPLE_ACTION"), RECEIVER_EXPORTED)
        awaitClose {
            unregisterReceiver(receiver)
        }
    }
}

選択肢

1. suspendCoroutine
2. produce
3. flow
4. callbackFlow

正答：4. callbackFlow

解説

問題文を見ると、Intentを受け取った時BroadcastReceiver.onReceiveが呼び出されますが、その中でtrySendを呼び出しています。またreceiverの登録を解除する箇所ではawaitCloseを利用しています。どちらもChannelで利用するメソッドのため、produceかcallbackFlowに絞られますが、produceは呼び出しにCoroutineScopeが必要なためcallbackFlowが正解になります。

午前：3問目

問.以下のコードにおいて、[ ※※※ ] に入る適切なコードは選択肢のうちどれでしょうか？

interface Logger {
    fun log(message: String)
}

class ConsoleLogger : Logger {
    override fun log(message: String) {
        println(message)
    }
}

context(Logger)
fun logWithPrefix(message: String, prefix: String = "INFO: ") {
   [ ※※※ ]
}

fun main() {
    val logger = ConsoleLogger()
    with(logger) {
        logWithPrefix("Hello") // "INFO: Hello" と出力されることを期待
    }
}

選択肢

1. log(prefix + message)
2. this.log(prefix + message)
3. logger.log(prefix + message)
4. println(prefix + message)

正答：1. log(prefix + message)

解説

Context Receivers を使用すると、拡張関数の内部でレシーバーオブジェクト (Logger) のメソッドやプロパティに直接アクセスできます。 logWithPrefix() 関数内で log() 関数を呼び出す際に、レシーバーオブジェクトの log() 関数が暗黙的に使用されます。

1. 正解

2. Build Failed : ‘this’ is not defined in this context. Unresolved reference ‘log’.

3. Build Failed : Unresolved reference ‘logger’.

4. 出力の条件は達成となりますが、Context Receivers を利用した適切なコードと考えると1が正解となります

午後：1問目

問. 以下のコードの出力は選択肢のうちどれでしょうか？

fun main() {
    Constructors()
}

class Constructors {
    init {
        print(1)
    }

    constructor() : this(0) {
        print(2)
    }

    constructor(a: Int) {
        print(3)
    }

    init {
        print(4)
    }
}

選択肢

1. 1234
2. 3214
3. 1432
4. コンパイルエラー

正答：3. 1432

解説

このクラスには二つのイニシャライザと二つのセカンダリコンストラクタがあります。

イニシャライザはセカンダリコンストラクタより前に実行されます。イニシャライザが複数ある場合、それらはクラス内での定義順に実行されます。したがって、クラスを初期化すると 1、4 の順に出力されます。

main 関数では引数なしのコンストラクタが呼び出されています。引数なしのコンストラクタは引数を一つ取るセカンダリコンストラクタを呼び出します。このときに 3 が出力されます。その後、引数なしのコンストラクタの残りの部分が実行され、2 が出力されます。

午後：2問目

問. 以下のテストを実行すると選択肢のうちどの結果となるでしょうか？※Joda-Time 2.12.7 の環境で作問

// Page.kt
package us.mitene

import org.joda.time.DateTime

data class Page(val createdAt: DateTime)

// PagesByMonth.kt
package us.mitene

import org.joda.time.DateTimeZone
import org.joda.time.YearMonth

data class PagesByMonth(
    val month: YearMonth,
    val pages: List<Page>,
) {
    companion object {
        fun make(pages: List<Page>): List<PagesByMonth> =
            pages.sortedByDescending {
                it.createdAt
            }.groupBy {
                YearMonth(it.createdAt.withZone(DateTimeZone.getDefault()))
            }.map {
                PagesByMonth(it.key, it.value)
            }
    }
}

// PagesByMonthTest.kt
import androidx.test.ext.junit.runners.AndroidJUnit4
import io.mockk.mockk
import org.junit.Assert.assertEquals
import org.junit.Test
import org.junit.runner.RunWith
import us.mitene.Page
import us.mitene.PagesByMonth

@RunWith(AndroidJUnit4::class)
class PagesByMonthTest {
    @Test
    fun make() {
        val pages: List<Page> = List(3) {
            Page(createdAt = mockk(relaxed = true))
        }
        val result = PagesByMonth.make(pages)
        assertEquals(3, result.size)
    }
}

選択肢

1. テストは問題なく通る
2. NullPointerException が起きる
3. IllegalArgumentException が起きる
4. ArrayIndexOutOfBoundsException が起きる

正答：4. ArrayIndexOutOfBoundsException が起きる

解説

org.joda.time.YearMonth は org.joda.time.base.BasePartial を継承しています。

BasePartial は iValues: int[] というプロパティを持っており、 YearMonth の場合は年月を「年、月」の順に格納しており本来であれば必ず値がセットされるように定義されています。

ところが、 mockk を使用して YearMonth を初期化すると本来は格納されるはずの iValues が空のままとなってしまいます。

この状態となっている YearMonth の配列に対し groupBy を実行すると java.util.HashMap 経由で YearMonth のハッシュを求める実装（ hashCode() ）が呼び出されます。 YearMonth の hashCode() は BasePartial が継承している AbstractPartial に実装されており、その実装は次のようになっています。

    /**
     * Gets a hash code for the ReadablePartial that is compatible with the 
     * equals method.
     *
     * @return a suitable hash code
     */
    @Override
    public int hashCode() {
        int total = 157;
        for (int i = 0, isize = size(); i < isize; i++) {
            total = 23 * total + getValue(i);
            total = 23 * total + getFieldType(i).hashCode();
        }
        total += getChronology().hashCode();
        return total;
    }

この実装において size() はプロパティのサイズを返しており YearMonth の場合は年月の2つ、つまり 2 が返り、 getValue(i) の部分では上述の iValues へアクセスし「年」と「月」を取り出します。

これは例えば YearMonth が 2024年6月 のような場合は getValue(0) で 2024 、 getValue(1) で 6 が入りそれぞれ計算されハッシュ値として返す、というような実装です。

設問ではここで mockk を使用したことで iValues が空配列となり getValue(0) が失敗し結果的に「ArrayIndexOutOfBoundsException が起きる」という状況となったのでした。

午後：3問目

問. 以下のコードの出力は選択肢のうちどれでしょうか？

fun main() {
    val languages = listOf(
        "Kotlin",
        "Java",
        "Swift",
        "Objective-C",
    )
    val result = languages
        .partition { it.contains('a') || it.contains('C') }
        .let { (contains, notContains) ->
            contains.zip(notContains) { a, b -> "$a-$b" }
        }
        .sortedByDescending { it.length }
        .joinToString(", ")
    println(result)
}

選択肢

1. Objective-C, Swift-Java, Kotlin
2. Objective-C-Swift, Java-Kotlin
3. Java,Kotlin-Objective-C,Swift
4. Java,Kotlin-Objective-C-Swift

正答：2.Objective-C-Swift, Java-Kotlin

解説

① .partition でリスト内の各要素を ‘a’ または ‘C’ を含むかどうかで2つのリストに分割します。

・contains リスト： Java, Objective-C

・notContains リスト： Kotlin, Swift

② .let ブロック内でcontainsとnotContainsを.zipで結合します。

結合結果：[“Java-Kotlin”, “Objective-C-Swift”]

③ .sortedByDescendingで長い方の文字列から降順でソートします。

[“Objective-C-Swift”, “Java-Kotlin”]

④ .joinToString(“, “)でリストを結合します

出力結果：”Objective-C-Swift, Java-Kotlin”

正答数の分布

今回実施したクイズの正答数の分布は下記となります。

午前

午後

当日のMIXIブース

Kotlin Fest 2024では、クイズに回答してくださった先着100名様（午前、午後で50名ずつ）に公式ロゴを用いたマイクロファイバークロスをノベルティとしてお渡ししました。

ちなみにブース出展時は、ノベルティのみならず、企画に応じてさまざまな制作物が必要になります。これまでブース展示用の制作物は手弁当でなんとかしていたのですが、今回より、デザイナーの加藤がブースづくりを本格的に手伝ってくれることに・・！

おかげで一気にブースに統一感が出た気がします。今後もより一層MIXIらしさが伝わるようなブースにしていきたいです🙌✨

最後に、今回クイズを作成＆ブーススタッフを担当してくれたMIXI ENGINEERSをパシャリ📸📸

最後まで読んでくださったみなさま、ありがとうございました〜！

MIXIでは様々な事業やポジションで仲間を募集中です。

こちらの記事を読んでいただき、MIXIで働くことに興味を持ってくださった方がいましたら、ぜひ採用情報をご覧ください。MIXIエンジニアの公式X（旧：Twitter）でもMIXIで扱う技術やエンジニアに関する情報など、随時発信してますので、フォローしていただけると幸いです。

それでは、最後までお読みいただき、ありがとうございました！

MIXIはKotlin Fest 2024に協賛＆ブース出展しました！出題したクイズとブースをご紹介します was originally published in MIXI DEVELOPERS on Medium, where people are continuing the conversation by highlighting and responding to this story.

MIXIは、昨年に引き続き、Go Conference 2024にブロンズスポンサーとして協賛します！

Go Conference 2024 について

まずはイベント概要を簡単にご紹介します。

Go Conferenceは、一般社団法人Gophers Japanが運営する、プログラミング言語Goユーザーのためのカンファレンスで、Goエンジニア、エンジニア志望の方、Goに興味のある方を対象としています。MIXIではGo Conference 2022 Springからスポンサーをさせていただいています。

日時：2024年6月8日 (土)
場所：Abema Towers
公式サイト：https://gocon.jp/2024/
参加登録（connpass）：https://gocon.connpass.com/event/314876/
参加費：無料

MIXI DEVELOPERSの注目セッション

Go Conference 2024のセッションで特に気になるものと、その理由について、弊社エンジニアからコメントをもらいました。

江畑（ソーシャルベッティング事業本部 開発室 新規開発グループ）

気になるセッション①
イテレータによってGoはどう変わるのか
https://gocon.jp/2024/sessions/2/

理由
弊社のサービスの一つであるTIPSTARでは競輪・オートレース・PIST6のレース情報や車券購入の基礎を共通のデータ構造で扱おうと試みる中で、Generics やそれを利用するためのイテレータについて注目しています。本セッションではイテレータの基礎について Go のコミュニティと目線を合わせるとともに今後の Go の進化についてキャッチアップができるのではないかと考えています。

気になるセッション②
Custom logging with slog: Making Logging Fun Again!
https://gocon.jp/2024/sessions/4/

理由
弊事業部では Go を用いたツール開発は当たり前の後継となっていますが、そのロギングについては既存の前例踏襲として log package を利用することがほとんどです。slog パッケージについては導入を検討しているもののどのような利点があるのかを整理しきれておらず、このセッションが一定の判断軸を提供してくれるのではないかと考えています。

洗川（minimo事業部 開発グループ バックエンド開発チーム）

気になるセッション
Mapのパフォーマンス向上のために検討されているSwissTableを理解する

理由
mapの実装がhashmapからSwissTableに置き換わることにより、insertやdeleteなどが20~50%、iterateが10%改善されることが以前上がっていたかと思います。

そしてそれが、今現在どのような議論がなされているのかとても興味があることや、将来高速化したい状況になった場合の知見の一つとして、聴講できれば嬉しく思っています。

おわりに

Go Conference 2024は、Goの最新技術や活用事例について学ぶことができる貴重な機会になっています。MIXIは、Goを使って開発されたサービスを提供する企業として、今後もGo言語の発展に貢献してまいります。

MIXIでは様々な事業やポジションで仲間を募集中です。

こちらの記事を読んでいただき、MIXIで働くことに興味を持ってくださった方がいましたら、ぜひ採用情報をご覧ください。MIXIエンジニアの公式TwitterでもMIXIで扱う技術やエンジニアに関する情報など、随時発信してますので、フォローしていただけると幸いです。

それでは、最後までお読みいただき、ありがとうございました！

MIXIはGo Conference 2024に協賛＆MIXIのエンジニアが注目するセッションをご紹介します was originally published in MIXI DEVELOPERS on Medium, where people are continuing the conversation by highlighting and responding to this story.

MIXIは、技術書典16にゴールドスポンサーとして協賛します🎉 また、MIXIエンジニア有志による新刊「MIXI TECH NOTE #11」を出典します！

今回もオフライン会場にてスポンサーブースを出展予定となっております。ブースでは、新刊の「MIXI TECH NOTE #11」の物理本を、”数量限定” で頒布します！もちろん無料です。

本記事では、新刊「MIXI TECH NOTE #11」の内容についてご紹介いたします。

興味を持っていただいた方は、ぜひオフライン会場のブースに遊びに来てください＆オンラインマーケットで電子版を無料DLしてみてくださいね。

イベントの詳細

オンライン開催

会期：2024/5/25 (土) 〜2024/6/9（日）
会場：技術書典16 オンラインマーケット

オフライン開催

会期：2024/5/26 (日) 11:00～17:00
会場：池袋サンシャインシティ 展示ホールD（文化会館ビル2F）、MIXIのブースは入口すぐの「協01」です！
参加：入場無料

👇公式ページのURLはこちら👇
https://techbookfest.org/event/tbf16

🗺MIXIのブースはこちら（赤丸の箇所）🗺

「MIXI TECH NOTE #11」のご紹介

今回は全5章からなる、86ページの冊子となっております。

目次はこちら：
１章：マスタデータとGitFlow
２章：Haskell とテスト
３章：UnityでDiscord内マルチ通信ゲームを作ろう！
４章：Scala.jsでFigmaプラグイン開発入門
５章：TIPSTARアーキテクチャの探索

執筆者コメント

第１章：「マスタデータとGitFlow」
ビジネス側とエンジニア側の両者で協力して開発・運用されるマスタデータ。お互いが気持ちよくマスタデータを管理できるように設計・実運用したワークフローの整備手法を紹介します。

第２章：「Haskell とテスト」
プログラミング言語 Haskell でのテストの書き方について、簡単な四則演算パーサをサンプルプログラムにして紹介します。

第３章：「UnityでDiscord内マルチ通信ゲームを作ろう！」
2024年3月公開の Discord 埋め込みアプリ SDK で対戦ゲームを作り、ユーザ名・アイコンのゲーム内表示や、VC 内での自動マッチング機能、Node.js でのゲームサーバー開発で学んだこと等を紹介します。

第４章：「Scala.jsでFigmaプラグイン開発入門」
Figma はプラグインによって独自の機能拡張ができ、それは標準的な Web の技術で構築可能です。今回は Scala.js を用いてどのように Figma のプラグインを開発できるか紹介します。

第５章：「TIPSTARアーキテクチャの探索」
TIPSTAR の全体像をアーキテクチャ図ベースで紹介します。全体像をイメージできた後に、今回はマスタデータと非同期処理について焦点を当てて紹介します。

おわりに

電子版は、5/25（土）〜オンラインマーケットにて頒布を開始しますので、どうぞお楽しみに！下記ページの「💚（グリーンのハートマーク）」を押して、お待ちくださいね。

https://techbookfest.org/product/7DLTppLS5fXb8b8S1PPeUT

それでは、みなさんと会場でお会いできるのを楽しみにしております！

・・・

MIXIでは様々な事業やポジションで仲間を募集中です。

こちらの記事を読んでいただき、MIXIで働くことに興味を持ってくださった方がいましたら、ぜひ採用情報をご覧ください。MIXIエンジニアの公式X（旧：Twitter）でもMIXIで扱う技術やエンジニアに関する情報など、随時発信してますので、フォローしていただけると幸いです。

それでは、最後までお読みいただき、ありがとうございました！

MIXIは、技術書典16に協賛＆新刊「MIXI TECH NOTE #11」を無料頒布します！ was originally published in MIXI DEVELOPERS on Medium, where people are continuing the conversation by highlighting and responding to this story.

2024年3月22日（金）〜24日（日）に開催された try! Swift Tokyo 2024 にて、MIXI はPLATINUMスポンサーとして協賛いたしました。

MIXIのブースでは、1日目、2日目ともにエンジニアが考えた「iOSクイズ」を実施し、2日間の合計で、397名の方にご回答いただきました。ブースに遊びに来てくださったみなさま、ありがとうございました！！

本記事では、出題したクイズの解答と解説および正答数の分布、そして当日のMIXIブースの様子をご紹介させていただきます。

クイズ（1日目）

1問目

Swift5.10の次に予定されているバージョンは、次のうちどれでしょう？

選択肢

• Swift5.11
• Swift5.10.1
• Swift6
• Swift5.11RC

正解：「Swift6」

解説：Swift5.10のリリースノートに次はSwift6を予定しているという記載があります。
https://www.swift.org/blog/swift-5.10-released/

2問目

Swift 5.9では以下のコードの結果はどうなりますか？

var number = 1
print(++number)

選択肢

• 1が出力される
• 2が出力される
• コンパイルエラーが発生する

正解：「コンパイルエラーが発生する」

解説：Swift3 でインクリメント / デクリメントは削除されました。
Swift Evolution Proposal SE-0004

error: repl.swift:14:7: error: cannot find operator '++' in scope; did you mean '+= 1'?
print(++number)
^~

3問目

期待通りの出力になるように空欄を埋めてください。

let numbers = [1, 2, 3, nil, 4, 5]
numbers.[???] // [1, 4, 9, 16, 25]

選択肢

• map { $0 * $0 }
• map { number in number * number }
• filter { $0 != nil }
• compactMap { $0 }.map { $0 * $0 }

正解：「compactMap { $0 }.map { $0 * $0 }」

解説：numbers の型は[Int?]です。nil に対して四則演算を行うことはできないため、compactMap で nil を取り除いてから演算を行う必要があります。

4問目

SwiftにおけるUInt8型が取り得る最大の値はいくつでしょう？

選択肢

• 255
• 256

正解：「255」

解説：Swift の UInt8型は符号なし8ビット整数であり、0から255までの整数を格納できます。

5問目

以下のようなProtocolのデフォルト実装がされている時、出力される結果として正しいのはどれですか？

protocol TotoProtocol{
    func foo()
}

extension TotoProtocol {
    func bar() {
      print("bar() - Protocol")
    }
}

class TotoClass: TotoProtocol {
    func foo() {
        print("foo() - Class")
    }
    func bar() {
        print("bar() - Class")
    }
}

let toto: TotoProtocol = TotoClass()
toto.foo()
toto.bar()

選択肢

• foo() — Class, bar() — Protocol
• foo() — Class, bar() — Class

正解：「foo() — Class, bar() — Protocol」

解説：bar()メソッドはプロトコル拡張で提供されており、TotoClass でも実装されています。しかし、変数 toto は TotoProtocol 型であり、プロトコル型の変数を通してプロトコル拡張のメソッドを呼び出すと、型に関連付けられた実装ではなく、プロトコル拡張にある既定の実装が使用されます。

6問目

メソッドのどこにもに付与できないアトリビュートは、次のうちどれでしょう？

選択肢

• @objc
• @IBInspectable
• @escaping
• @inlinable

正解：正解は「@IBInspectable」

解説：@IBInspectable のみプロパティに付与するアトリビュートで、Interface Builder(Storyboard, Xib)を使ったUIを実装する際に利用できます。

7問目

Swift2.xからSwift3.xへのバージョンアップで起こった変化は、次のうちどれでしょう？

選択肢

• fileprivate導入
• guard
• enumの頭文字が小文字
• Codable

正解：「enumの頭文字が小文字」と「fileprivate導入」

解説：『guard』はSwift2、『Codable』はSwift4になります。

クイズ（2日目）

1問目

以下のコードのコンパイル結果はどうなりますか？

let tooBig: Int8 = 128

選択肢

• 正常にコンパイルできる
• コンパイルエラーが発生する

正解：「コンパイルエラーが発生する」

解説：SwiftのUInt8型は符号なし8ビット整数であり、-128から127までの整数を格納できます。Arithmetic operation ‘127 + 1’ (on type ‘Int8’) results in an overflowが表示されます。

2問目

Swiftの正しい構文になるように、空欄を埋めてください。

//定数宣言
（ ① ）hoge （ ② ）String = "hoge"

//メソッド定義
（ ③ ）fuga() （ ④ ）String { return "fuga" }

選択肢

• ①let ②: ③func ④->
• ①val ②: ③fun ④:
• ①let ②: ③function ④:
• ①val ②-> ③fun ④->

正解：「①let ②: ③func ④->」

解説：2番目はKotlin、3番目はTypeScript、4番目は架空の言語になります。

3問目

MediaPlayer Package の中にMediaConfiguration Module, MusicPlayer Module を定義しました。 MediaClient#get(_:) を App Target からは呼び出せないが、MediaPlayer Package の中では参照できるようにするとき、（???） には何を入れる必要があるでしょうか？

// Module `MediaConfiguration` in `MediaPlayer`
public class MediaClient {
    public init() {}
    [???] func get(_ url: URL) -> Data {…}
}

// Module `MusicPlayer` in `MediaPlayer`
import Foundation
import MediaConfiguration

public class MusicPlayer {
    let client = MediaClient()

    public init() {}

    public func play(_ url: URL) {
        let data = client.get(url)
        // Play music based on the Data object
    }
}

// App
import Foundation
import MediaConfiguration
import MusicPlayer

let url = URL(string: "…")!
MusicPlayer().play(url) // can access `play` since it's a public symbol
MediaClient().get(url) // 'get' is inaccessible

選択肢

• open
• package
• private
• package(private)

正解：「package」

解説：
package はSwift5.9、SE-0386で導入されました。

・open を使用するとMediaClient#get(_:) を App Targetから呼び出せてしまいます
・MediaDecoder などを private で宣言すると、MusicPlayer module からはもちろん、MediaConfiguration module 内の別のファイルからも参照できなくなります。
・package(private) は Swift5.9現在存在しませんが、将来packageopen、open(package)、package(override)などが導入される可能性があることが示唆されています。

4問目

Swift5.5 で iOS15以降で使える Swift Concurrency が登場し、その後 iOS13 以降で使えるようになりましたが、iOS13 で使用可能な条件はどれですか？

選択肢

• Xcode13.0
• Xcode13.2
• Swift5.6

正解：「Xcode13.2」

解説：Swift Concurrency は Xcode13.2 で iOS13まで拡張されましたhttps://developer.apple.com/documentation/xcode-release-notes/xcode-13_2-release-notes#Swift

5問目

以下のコードの結果はどうなりますか？

class Person {
    var name: String
    init(name: String) {
        self.name = name
    }
}

let firstPerson = Person(name: "Alice")
let secondPerson = firstPerson
secondPerson.name = "Bob"

print("First: \(firstPerson.name), Second: \(secondPerson.name)")

選択肢

• First: Alice, Second: Alice
• First: Alice, Second: Bob
• First: Bob, Second: Alice
• First: Bob, Second: Bob

正解：「First: Bob, Second: Bob」

解説：クラスのインスタンスである firstPerson と secondPerson は、同じ参照を共有しています。secondPerson.name を変更すると、同じインスタンスの firstPerson.name も変更されるため、両方の name プロパティには “Bob” が格納されます。

6問目

以下のコードに使われているマクロの種類で正しいのは、次のうちどれでしょう？

func myFunction() {
    print("Currently running \(#function)")
    #warning("Something's wrong")
}

選択肢

• Freestanding Macros
• Attached Macros

正解：「Freestanding Macros」

解説：Freestanding Macros は#から始まり、クラス等の宣言に付与されることなく単独で使用します。Attached Macros は@から始まり、付与されたクラス等の宣言に対してコードを生成します。
https://docs.swift.org/swift-book/documentation/the-swift-programming-language/macros/

MIXIブースのレポート

ここからは、当日のMIXIブースの様子について簡単にご紹介します。

まず、MIXIブースの場所はコーヒー☕などを提供しているブレイクエリアでした。

iOSクイズの出題

ブースでは、前述のiOSクイズを出題し、日本語版と英語版の2種類を用意しました。

クイズの正答数の分布は下記となります。中央値は2日間ともに4点となりました。

1日目は5問以上正解、2日目は4問以上正解でノベルティをプレゼントしていたのですが、両日ともに3,4,5点に分布が集中しており、ギリギリでノベルティをお渡しできなかった方も大勢いらっしゃったのではないかと思います。

1日目に惜しくも正答数が足りなかった方が2日目にリベンジしてくださり、無事ノベルティをゲットされることもありました。楽しんでいただけたようで、とてもうれしかったです🙌

1日目（日本語版）回答数の合計：144件

1日目（英語版）回答数の合計：90件

2日目（日本語版）回答数の合計：106件

2日目（英語版）回答数の合計：57件

ノベルティ

クイズの成績が良かった方にはノベルティとして、Swiftに関連付けて「値型」タオルをプレゼント🎁海外の方も多いので、何か日本らしいものを…と思い漢字でデザインしました。こちらもエンジニアにアイディアを出してもらい、余談ですが、他にも「並行処理」や「拡張」などの案も出ていました。

ブースづくりに協力してくれたMIXI ENGINEERS

最後に、今回ブースのコンテンツおよびノベルティ作成を中心となって進めてくれたMIXI ENGINEERSをパシャリ📸📸

・・・

MIXIでは様々な事業やポジションで仲間を募集中です。

こちらの記事を読んでいただき、MIXIで働くことに興味を持ってくださった方がいましたら、ぜひ採用情報をご覧ください。MIXIエンジニアの公式X（旧：Twitter）でもMIXIで扱う技術やエンジニアに関する情報など、随時発信してますので、フォローしていただけると幸いです。

それでは、最後までお読みいただき、ありがとうございました！

MIXIはtry! Swift Tokyo 2024にブース出展しました！出題したiOSクイズとブースをご紹介します was originally published in MIXI DEVELOPERS on Medium, where people are continuing the conversation by highlighting and responding to this story.

「家族アルバム みてね（以下みてね）」では、2023年3月にプロダクト開発部 部長に平田が就任して以来、チームにスクラムの考え方を浸透させるべく、さまざまな取り組みを行ってきました。

この取り組みにより「考え方の軸が強固になった」とiOSエンジニアの飯塚は語ります。

本インタビューでは、スクラムの浸透による変化を経たいま、みてねのiOS開発メンバーに共通する考え方や、自主性を重んじるカルチャー等についてiOSエンジニアの飯塚・佐藤・阿部に聞きました。

メンバーの紹介

飯塚（写真左）：2019年にミクシィ（現MIXI）に新卒入社。現在までみてね事業部で、iOSを中心にアプリ開発や、技術的負債の解消などに携わる。みてねプロダクト開発部 プロダクト開発Dグループ所属。

佐藤（写真中央）：新卒入社した会社で主にiOSアプリ開発を担当し、2021年11月にミクシィ（現MIXI）に入社。 iOS・Android・バックエンドの開発を幅広く担当。みてねプロダクト開発部 プロダクト開発Dグループ所属。

阿部（写真右）：新卒入社した会社でiOSアプリ開発を担当し、 2023年6月にMIXIに入社。 iOS・Android・バックエンドの開発を幅広く担当。みてねプロダクト開発部 プロダクト開発Mグループ所属。

幅広い技術に携われる環境

──佐藤さんと、阿部さんは中途入社されていますが、みてねにジョインしたきっかけを教えてください。

佐藤：新卒で入社した会社では主にiOS開発に携わっていて、技術の幅を広げたいと考え、「みてね」にジョインしました。「みてね」でもiOS開発をメインに担当しつつ、Androidやサーバーサイドのタスクも取っていて、一つ前のスプリントではほぼAndroid開発のみ行っていました。

阿部：僕も佐藤さんと同じで、技術の幅を広げたかったのが転職の理由です。前職ではずっとiOS開発に携わっていて、最後の方はサーバーサイド開発にも携わらせていただく機会はあったのですが、もう少し深く飛び込んでいきたいと考えました。今は主に「みてね」関連の商品を扱うMERCHというチームに所属しています。MERCHチームは、時期にもよりますが比較的サーバーサイドの開発が多いので、最近はもっぱらRubyを書いています。

ただ、iOSから完全に離れたわけではなく、チーム横断でiOSエンジニアが集まって「みてね」をより良くするために会議する、週次の”iOS定例”の中で出てきたタスクは今も拾うようにしています。

──”iOS定例”について、もう少し詳しく教えてください。具体的にはどんなことを話されているのでしょうか？

飯塚：”iOS定例”は、週次で「みてね」内のiOSを得意とするメンバーが集まって、iOS開発に関することを話す場です。主に「みてね」のiOS開発における課題をリスト化して、新しい課題が出てきたら報告したり、ひとつひとつの解決方法を議論したりしています。新しい技術に関する話題も多いです。特に主催者がいるわけではなく、僕の入社前から脈々と続いている会です。

──”iOS定例”で出てきた課題は、どのように分担し、解消しているのでしょうか。

飯塚：各々が自主的に取っていくことが多いです。みてねでは「20%ルール」を採用していて、業務時間の内20%はメイン業務以外の好きな開発業務に充てることができるので、”iOS定例”のタスクもその時間に取り組んでいます。

阿部：定例で上がってきた課題や取り組むべきことはタスク化してあるので、各々が興味のあるタスクを取っているイメージですね。

「スクラム研修」がもたらした変化とは

──自主性を持ったメンバーが多い印象を受けたのですが、他にも皆さんが思う、みてねのiOSエンジニアの特徴などはありますか？

阿部：新しい技術に敏感で、積極的に取り入れる姿勢があると思います。単に気になるで終わらせるのではなく、導入までの道筋を考えて実際に導入して…と行動に移すことができる方が多いです。

また、人柄でいうとみなさんすごく穏やかです。議論の場でも冷静で理路整然と話される方ばかりで、議論が苦痛じゃないですし、建設的に話せる環境だと感じています。

飯塚：結論が出るのも、すごくスムーズで早いですね。議論の場でA案、B案を持ち寄ったとしたら、必ずしもそのどちらかに帰結するのではなく、話し合いの結果を踏まえて次のアクションを決めています。例えば、「◯◯がまだ曖昧なことが分かったから、次のアクションとしては◯◯を深堀りして調査してみましょうか」、といった感じで。

阿部：自分の意見を通すのが目的ではないという共通認識がありますよね。あとは、みなさん「みてね」のことがとてもがすごく好きで、より良くしたいというブレない軸を持たれている印象です。

━━他にも、何かありますか？

佐藤：皆さん、課題を解決することと、より良くすることを分けて考えることができているため、物事を小さくして前に進めるのがすごく上手いと思います。まずは小さく、最低限これをやれば課題が解決できるというところまで持っていく。そしてそれをベースにより良くする、というサイクルが染み付いているような気がします。

━━みなさん、最低限のポイントを押さえて、小さく始めることが身についているんですね。

飯塚：スクラムの考え方が浸透してきていますよね。みてね プロダクト開発部 部長の平田の主導で「スクラム研修」が開催され、ドメインチームごとに参加したのですが、これが本当に良くて。

佐藤：スクラムの認定資格を持っている「みてね」のメンバーが講師をしてくれました。この研修のおかげで、「みてね」全体にスクラムの考え方がとても浸透しました。入社しただけでこの研修が受けられるなんて、最強の福利厚生だと思います。

飯塚：元から「みてね」のメンバーはとてもすごく自主性があり、自分で課題を見つけ、チームにももちろん相談しつつですが、どんどん改善を進めていました。研修を受けてからはさらにその傾向が加速していて、今までも薄っすらあった考え方の軸が、より強固になったように感じます。

佐藤：スクラムの考え方を学んで、実践して、少しずつ「みてね」のチームに合わせて改善して…を繰り返すことで、少なくともスクラムにおける守破離の”守”の部分はできているように感じます。

さらに職域間の垣根を低くすることを目指す

━━みてねのiOS開発で、これから取り組んでいきたい課題について教えてください。

阿部：「みてね」では職域問わずさまざまな領域のタスクを取れるので、普段あまりiOS開発に携わらない方でも、迷いなく実装できるようにしたいです。

佐藤：その課題の解決方法としては件は、SwiftUIが手段の一つになり得ると思います。例えばAndroidエンジニアの方であれば、既にJetpack Composeを使われているので、SwiftUIであれば書き方が似ていて使いやすいはずです。現在、「みてね」のiOS開発全体の約10%のファイルがSwiftUIで書かれていて、知見が溜まってきており、iOSエンジニアはSwiftUIが書けるようになってきています。次のステップとして、普段iOSをあまり書かない人にもSwiftUIでの実装がやりやすいと感じてもらえるよう、ドキュメントの整備を進めていきたいです。

ちなみに余談ですが、SwiftUIの導入時に開発の進め方・考え方をまとめたドキュメントを書いて全体に展開したのですが、まだ一度も修正せずに済んでいます。これまで最初の設計のままで上手くいくことがあまりなかったので嬉しかったですし、すごく誇らしいです（笑）

飯塚：たしかに、全く手直ししてないですね。

──実現したら、さらに職域間の垣根が低くなっていきそうです。最後に、未来の仲間へのコメントをお願いします！

阿部：「みてね」は、得意分野を軸としつつ、更に別の領域にも挑戦したい方にはぴったりな環境だと思います。

飯塚：少し補足すると、入社前にフルスタックエンジニアとして完成している必要はありません。技術・知識の幅を増やしたいという気持ちがあればチャレンジさせてもらえます。なので、これからフルスタックを目指す方にとって良い環境だと思いますね。

新卒入社の観点からもお話しすると、今のスクラムの考え方が浸透した「みてね」でファーストキャリアを過ごすことは、必ず今後のキャリアの糧になると思います。

佐藤：一つひとつのタスクが小さいのも、チャレンジのしやすさに繋がっていますよね。「みてね」では、タスクが細分化されていて、小さく、急ぎじゃないタスクを選ぶことができるので、チャレンジのハードルが低いんです。

──空気感だけでなく、仕組みとしても異なる技術領域にチャレンジしやすくなっているんですね。他にもありますか？

阿部：もし今「みてね」というプロダクトや組織に対して良い印象を抱いてくださっている方がいたら、それはこれまで「みてね」に携わってきた方々のおかげだということです。ここから先の数年はきっと自分たちにかかっているはずなので、もっと良くしたいと思ってくれる人がいたら、ぜひ一緒に働きたいです！

──一緒にこれからの「みてね」を背負ってくださる方が見つかると嬉しいですね。それでは、ありがとうございました！

MIXIでは様々な事業やポジションで仲間を募集中です。

こちらの記事を読んでいただき、MIXIで働くことに興味を持ってくださった方がいましたら、ぜひ採用情報をご覧ください。MIXIエンジニアの公式X（旧：Twitter）でもMIXIで扱う技術やエンジニアに関する情報など、随時発信してますので、フォローしていただけると幸いです。

それでは、最後までお読みいただき、ありがとうございました！

自律的に考え、行動する。スクラムの考え方がより強固になった「家族アルバム みてね」 iOSエンジニアのいま was originally published in MIXI DEVELOPERS on Medium, where people are continuing the conversation by highlighting and responding to this story.

今回お送りするのは、そんなTIPSTARのiOS/Androidアプリ開発を担う、3名のエンジニアへのインタビュー。彼らが育むチームのカルチャーから、独自性の高いUIとの付き合い方等の開発の特徴、そしてTIPSTARのアプリ開発はどんな方に向いているか？などについて聞きました。

寺田（写真左）：携帯電話のゲームアプリ開発を経験し、2008年のiPhone 3G登場時よりiOSアプリ開発に携わり始める。ミクシィ（現MIXI）には2016年2月に入社し、複数事業でiOSアプリ開発を担当した後、2019年にTIPSTARにジョイン。

山田（写真中央）：2015年にミクシィ（現MIXI）に新卒入社。複数事業でAndroid開発やアプリ開発チームのリーダを経験し、2019年にTIPSTARへジョイン。TIPSTARではAndroid開発のテックリード兼 iOS, Android, Web開発を行うクライアントチームのリーダーを担う。

真田（写真右）：複数社でiOSアプリ開発をメインにAndroid, API, Webフロントエンドなど様々な開発に従事し、2022年1月にミクシィ（現MIXI）に入社。minimoでAndroidアプリ開発を担当した後TIPSTARにジョインし、現在はiOSアプリ開発を担当。

経験豊富なアプリ開発エンジニアが集うチーム

━━まずは、チーム構成について教えていただけますか。

山田：部署としては、Androidエンジニア4名、iOSエンジニア4名、Webエンジニア2名、Unityエンジニア1名の計11名のチームになっています。ただ、実際には各プラットフォームごとに分かれて仕事を進めることが多いです。

━━チーム内では、どのようにコミュニケーションをとられていますか？開発に詰まった時などのことも教えてください。

山田：今は全員が揃って出社することは中々ないので、仕事に必要なコミュニケーションはオンラインで完結するようにしてますね。

真田：開発で詰まった時のことですが、実は技術的に困って誰かに相談することがあまりなくて。二つの選択肢があるがどちらが良いか？くらいの軽い相談は雑談的にSlackチャンネルにポストしたり、ハドルで聞いたりしています。

寺田：たしかに、技術的に困って相談することはあまりないですね。相談するにしても、大体自分の中で答えを持っていることが多いですよね。

━━なんと、そうなんですね。基本的に、開発では困らないということでしょうか…？

真田：デザインが上がってきた時点で、実装が難しそうなものがあれば調整してもらっています。そのため、実装する段階で困ることが少ないという感じです。

山田：そのやり方が上手くまわっているのは、経験のなせる技ですよね。

━━経験を積んだからこそ、という感じがしますね。Androidの方はどうでしょう？

山田：Androidも割とベテランが揃っているので、開発で困る場面はそう多くないと思います。

ちなみに、Androidのメンバーの特色で言うと、新しい技術を取り入れる時は勉強会を開くことが多いです。たとえば、現在Jetpack Composeの導入を計画しているので、最近ではその勉強会を開きました。

“TIPSTAR特有のUI” 、そのアプリ開発の裏側とは

━━チームの雰囲気やカルチャーについて、もう少し教えてください。

真田：カルチャーというほどでは無いかもしれませんが、最近はアプリストアのレビューを気にする空気が生まれてきています。アプリストアのレビューが流れるチャンネルを作ったことで、メンバー間でどのようにアプリを改善すべきかの会話が生まれ、レビューへ返信するようになりました。

山田：事業部全体のメンバーが見ているので、職種を超えたコミュニケーションのきっかけにもなっていますよね。

━━ひとり一人が、より一層ユーザー体験向上について考えるようになったんですね。他にもありますか？

山田：デザイン含む仕様書がきっちり揃っているので、誰でも開発に入りやすい環境だと思います。経緯としては、TIPSTARは機能が多く情報が散らかってきたので、きちんと仕様書に残すようになりました。

━━「TIPSTARは機能が多い」とのことですが、UIも特殊な作りになっていますよね。。

真田：ヒューマンインターフェイスガイドラインは最低限抑えつつ、そこにとらわれすぎない作りになっていると思います。

寺田：ガイドラインからは、かなり逸脱してますよね。TIPSTARのコンセプトは”共遊型ベッティングサービス”です。”共遊型”という言葉から読み取れるように、ゲームのような体験の提供を重要視しているため、TIPSTAR特有のUIになっています。実際、すごろくやガチャなどのミニゲーム的な機能が備わっていて、その辺りの実装にはUnityが使われていたりします。

━━サービスのコンセプトに沿った結果なんですね。UIがTIPSTAR特有のつくりになっていることで、苦労されることはないのでしょうか。

山田：やはり、技術的なハードルは高いと感じます。演出として度々サウンドエフェクトやアニメーションを用いるのですが、ネイティブ側で実装することもあるので、大変なこともありますね。

あとは、世界観を表現するためにUIパーツのカスタマイズを行うことも多いです。例えばボタンは一色で塗りつぶして終わりではなく、TIPSTARでは色や効果を複数重ねてデザインされています。こういった独自のデザインは標準SDKに用意されていないので、カスタマイズが必要になります。

寺田：ここ10年ほどの、フラットデザインのトレンドを全て無視するようなUIになっていますね。なので、プラットフォームが用意してくれているパーツは、そのままだとほとんど使えなくて。

真田：一つひとつのパーツが作り込まれていると思います。ボタン以外にも、ナビゲーションバーのデザインも割と独特なので、実装は少し複雑ですね。

━━世界観を表現するために、色々と工夫されているんですね。

新しい技術の導入にあたり、抱えている課題

━━iOS、Android開発それぞれで、現在課題に感じていることについて教えてください。

真田：iOS開発側では、RxSwiftへの依存をなんとかしたいです。SwiftUIやSwift Concurrencyの導入ハードルが下がってきて、TIPSTARでもそろそろ…と思っているのですが、RxSwiftに深く依存していることで導入が難しくなっています。

━━新しい技術の導入の妨げになっているんですね。SwiftUIの導入は、現在検討中ですか？

真田：少しずつ導入していきたいね、という話は出てきています。

寺田：ただ、既存のUIを全てSwiftUIに対応する場合、普段の開発業務と並行して進めるのは大変ですよね。全画面を一気に書き換えることは難しいので、どうしてもSwiftUIに切り替わっている画面とそうでない画面が混ざるタイミングが出てきます。そうした時に、メインの開発業務に混乱をきたさないように進める方法を模索中です。

真田：以前、別のサービスでAndroid開発に従事していた時に、似たような状況になりました。新しい技術への書き換え前後の画面が混在することで、割と困った記憶があるので、慎重に進めていきたいです。

━━Android開発側は、いかがでしょう？

山田：Android開発では、現在Jetpack Composeの導入を進めようとしています。先ほど、UIパーツをカスタマイズしていると話しましたが、これが曲者でして。これまでAndroid Viewでカスタマイズしていた実装を、Jetpack Composeでも同様に置き換えていく必要があるので、なかなか大変です。

真田：開発現場に共通の課題だと思いますが、新しい技術に置き換えないとこれから登場する便利な機能が使えないため、なんとか進めていきたいですね。

「普通のアプリ開発に飽きてきた」方におすすめの環境

━━最後に、どんな方がTIPSTARの開発チームで活躍できそうか聞かせてください。

寺田：その性質的にスタートアップ等ではなかなか難しい事業ですし、サービス内容的にも珍しいので、少し変わった事業に携わりたい方にとって良い環境だと思います。ギャンブルは特に好きじゃなくても、拒否反応さえなければ。

山田：技術的には、UIのカスタマイズ好きの方は楽しんでいただけるかもしれません。既にあるパーツを使うのではなく、作る側にまわれるので。

真田：レース映像の表示や認証に関しても、MIXI Mが今度SDKに対応するのでそれを使うみたいな話になっていて、そういった珍しい技術を触りたい方にとっては面白いかもしれないです。

━━サービス面でも技術面でも独自性が高いので、珍しいことをやってみたい方に向いていそうですね。

真田：そうですね。よくあるiOS開発には飽きてしまった、という方におすすめできるかも。

寺田：競輪って割とレガシーな業界なので、そういったレガシーなマーケットにアイデアをぶつけて、色々挑戦してみたいというモチベーションがあると尚いいかなと思います。

━━技術的にも事業的にも、様々なハードルを乗り越えて挑戦していきたい方に楽しんでいただけそうに感じました。それでは、ありがとうございました！

MIXIでは様々な事業やポジションで仲間を募集中です。

こちらの記事を読んでいただき、MIXIで働くことに興味を持ってくださった方がいましたら、ぜひ採用情報をご覧ください。MIXIエンジニアの公式X（旧：Twitter）でもMIXIで扱う技術やエンジニアに関する情報など、随時発信してますので、フォローしていただけると幸いです。

それでは、最後までお読みいただき、ありがとうございました！

『共遊型ベッティングサービス TIPSTAR』の世界観を実現するために─特有のUIを採用するアプリ開発の裏側に迫る was originally published in MIXI DEVELOPERS on Medium, where people are continuing the conversation by highlighting and responding to this story.

めまぐるしく変化するモバイルアプリ開発。日々新たな技術や開発言語が登場する中で、開発現場のエンジニアたちはどのような視線でそれらの変化を捉えているのでしょうか。

現場のリアルな声をお届けするべく、『家族アルバム みてね（以下みてね）』から飯塚、『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で扱う技術やエンジニアに関する情報など、随時発信してますので、フォローしていただけると幸いです。

それでは、最後までお読みいただき、ありがとうございました！

MIXIのiOSアプリ開発最前線〜みてね・minimo・TIPSTARのエンジニアに”今”聞いてみたいこと〜 was originally published in MIXI DEVELOPERS on Medium, where people are continuing the conversation by highlighting and responding to this story.