1. droidkaigiとiOSDCの企業ブースでKMPって言いすぎて
こんにちは。ディップ株式会社でバイトルというアプリを開発している黒田です。
droidkaigi 2026とiOSDC 2026で、私たちディップ株式会社は企業ブースを出させていただいて、トータル5日間、本当にたくさんの方と技術交流させていただきました。本当にありがとうございました。
弊社のブースでは弊社のモバイルアプリエンジニアがシフト制で代わる代わるブース前に立ち、Kotlin Multiplatform(KMP)を中心とした技術の採用事情や意思決定にまつわる話題をテーマとし、5日間毎日違う設問でアンケートをさせていただいておりました。皆さんたくさんお話を聞いてくださり、またたくさんお話していただけたので、ブース前の空間の占有率的に他のブースの方々に御迷惑をおかけしたのではないかと深く反省しているところです。
もともと社内の他チームと比べてもおしゃべりなメンバーが多い印象のあるアプリチームですが、とにかく毎回毎回ブースに来ていただいた方に「KMP」を連呼することになるので、後日、日常の色々なシーンで油断すると口から『KMP』が出てきてしまいそうになる症状に数日見舞われました。
「お支払いは？」
「KMPで！」
実際のブースでの体験レポートについては、以下のテックブログにて紹介されていますので、もしよろしければご一読ください。
【DroidKaigi 2026】「バイトル」リニューアルでの技術&アーキテクチャ選定の意思決定を全解説します！
【iOSDC 2026】「バイトル」iOSアプリ全面リニューアルの意思決定を、ブースのアンケート結果と並べて全解説します！
また、iOSDCでは弊社のiOSエンジニア・宮川がスポンサーセッションに登壇しました。「Kotlin Multiplatformを軸にした求人アプリ全面リニューアルの技術戦略」こちらも当日のセッションのアーカイブや登壇資料などがございますので、よろしければぜひご視聴、ご一読ください。
この後のお話に備えてブースにて紹介していたバイトルアプリリニューアルに採用しているアーキテクチャについて軽く触れておきます。私たちが採用しているアーキテクチャは、業務ルールを含むDomain層、それからデータ層についてはKMPで統一し、UIを含むPresentation層は各プラットフォームのネイティブに寄せるという形になっています。
今回このテックブログでテーマとしたいのは、iOSDCにてブース前でこのアーキテクチャについていただいたあるコメントです。
「KMPで組むと、用途が常に両OS分ある領域ができるじゃないですか。すると認知負荷が上がるからKMP入れたくないんですよね。」
「iOS側から見たら、当然Swiftで全部書いてあるほうが読みやすいので。新しい人が入ってくることを考えると、部分採用はデメリットが大きいと思うんですよね。」
iOS側は画面をSwiftで書いて、その下のロジックはKotlinを読むことになります。ひとつの機能を追うだけでも言語をまたぐわけで、そりゃ負担だよな、と。
私はそのようなコメントを頂いて、「そうそう！そうなんですよ！」と言いつつ、内心では
「一応対策はしたつもりだし、AIに聞けば解消できるようにドキュメントや意思決定のログなども残しているし、iOS/Android間で越境もおきてるという意味ではそれほどその認知負荷が障壁になっている素振りもない。」
「最初5人だったアプリチームは今10人。確認する機会が少なくとも5回もあったはず。でも実際に新規参画者絡みたらどう見えるのかって一度も確認したことない気がするな。気づいたらみんなスルッと適応してたイメージなんだよなぁ。……何にも言えないな。」
と言葉に詰まっていました。
しかし今振り返ってみると、ちょうど答えを持っていそうな人たちが、本当にちょうどdroidkaigiとiOSDCの期間に存在していたことに気づきました。
2. その正体は？
出来すぎたタイミングでした。実はサマーインターンとして、DroidKaigiの会期中に1週間のインターン生が1人、そしてiOSDCの前後には、2週間のインターン生が2人も来てくれていました。
まず1人目。1週間のインターンに来てくれた小北さんについて。小北さんは1週間できっちりとPRを出すところまでたどり着けています。つまり「1週間でPRが出てるってことは、少なくとも入口が完全に塞がっているってことはないはず」と判断できます。
(ご本人がテックブログに書いてくださっているので、ぜひそちらもご覧ください！)
表示できるだけでは終わらない - 何を作り、何をつくらないか考えた５日間
ただ実際の困難について事細かに聞いたわけでもありませんでしたし、本人がたまたま優秀だっただけかもしれない。（事実小北さんはとても優秀でしたし。）
iOSDCが終わって「小北さんに話聞いとけばよかったな」と後悔しながら、ふと気づきました。「今来てくれてる二人はまだまにあうじゃないか！」
というわけで、2週間のインターンに来てくださっていたお二人のインターン最終日、の前日にインタビューにご協力いただきました。
(お二人もそれぞれテックブログを書いてくださっています！)
理由を持って決断してチームで実装し切る -バイトルアプリ開発で学んだ仕様検討と共有-
「どう作るか」と「なぜ作るか」に向き合ったバイトルアプリ開発
聞きたかったのは、次の5つです。
- 最初の説明を聞き終えての、プロジェクトやKMPの印象はどうだった？
- 手を動かしてみての印象。簡単だったところ、難しかったところ、うまくやれたところ、工夫が必要だったところ
- 改善してほしいところ
- 自分だったら、どこをどう改善する？
- 自分がそのまま開発に残ったら、1ヶ月後どのくらいアプリを触れていそう？（UIからDomain、Data、果てはBFFまで全部？）
あいにく私はインタビュー当日に予定が入ってしまい、同じチームのiOSエンジニア・土屋さんに聞き手をお願いしました。
そして返ってきた内容は、ブースでいただいた指摘とも、私が身構えていた方向とも、少し違うものでした。
3. 生の声を聞く
以下、当日のやりとりから抜粋します。
Q1. 最初の説明を聞き終えて、プロジェクトやKMPへの印象は？
土屋 | 最初の説明を聞き終えて、プロジェクトやKMPへの印象はどうでしたか？ まずは上村さんからお願いします。 |
上村 | KMPってワードは知っていたんですけど、具体的にどうかはあまり良くわからず、どの様にKMPを使用するのかという説明を聞いて、このチームで働くにはアーキテクチャの知識が必要なのではないかと気づいて、アーキテクチャの勉強から始めました。それでKMPがなんとなく理解できてきたという感じです。 |
土屋 | なるほど。ありがとうございます。東出さんはどうですか？ |
東出 | DroidKaigiに参加した際にdipのブースで、UIやViewModel、いわゆるPresentation層をOS固有にして、それ以外がKMPで共有になるよということは聞いていて、ただiOSとAndroidでPresentation層のパターンに個性があって、それとKMPをどの様に組みわせるのかを想像してワクワクしていました。 |
土屋 | ありがとうございます。お二人の意見を聞いて、どちらも印象としては『アーキテクチャの理解が重要』というところは一緒なのかなと思いました。 |
Q2. 実際に手を動かしてみて、簡単だったところ・難しかったところは？
土屋 | では次の質問です。実際に手を動かしてみての感想を、思ったより簡単だったところ、難しかったところ、うまくやれたところ、工夫が必要だったところなどをお聞きしたいです。まず上村さん、どうですか？ |
上村 | 一つの機能を東出さんとAndroidとiOSに担当を分けて開発していたのですが、その過程で認識を合わせたと思ってもちょっとずつズレてくるようなことがあって、その積み重ねがあると最終的には大きな差になってしまうということを感じていて、これがもし両方フルネイティブだったらと考えると、結構恐ろしいことになるなと思いました。その点KMPによる共通領域があることでそういったリスクを実際に減らせているという感想を持ちました。逆にOSそれぞれで実装している範囲での認識は、SwiftとKotlinという別々の言語で書いているからこそ、合わせることが難しかったなと思いました。 |
土屋 | それはKMPを採用しているから難しかったという感じですか？ |
上村 | いえ、この難しさはフルネイティブで開発していても同じだったと思います。 |
土屋 | ありがとうございます。では東出さんもお願いします。 |
東出 | 僕も大体同じ感想なんですが、特にネイティブとKMPの境界条件、どこまでがKMP層で、どこまでがネイティブの層なのかを決める合意形成が難しかったなと思いました。今までAndroidで実装する中で何がどの機能を担当するのか、ソースコード上でそれぞれの役割の配置が自分の中で曖昧だったのだと思います。そういう意味では、今回のインターンでの開発を通して、それらが自分の中である程度明確になったことは大きな学びになったと思います。 |
Q3. アプリ開発チームに向けて、改善してほしいところは？
土屋 | ありがとうございます。続いて、今回のインターンを通して、アプリ開発チームに向けて改善点など、もしあれば教えていただけたらと思います。 |
上村 | うーん……KMPというよりはまたUIの話になってしまって申し訳ないのですが、Android/iOSのそれぞれのUIの実装を、Androidの実装はAndroidのメンバー、iOSの実装はiOSのメンバーにレビューしていただいていたと思うのですが、そうするとAndroidとiOS両方見る観点が漏れてしまいがちになると思っていて、今回は実際に同じ機能を二人で開発していて、OS間で出来上がったものに差分が発生してしまったことがあって、OS間の差を確認するフェーズは必要だと思いました。もしかしたら余計な手間になってしまうかもしれないですが、同じ人が両方のPRを見るとかですね。 |
土屋 | そうなんですよ。まさにアプリチームではその問題に直面していて、すでにAndroid/iOSの境界を越境できているエンジニアも増えてきたので、両方とも同じ人が実装するなどの話は出てきていて、上村さんの意見と同じ様にレビューに関しても一人が両方のPRをレビューする体制を取ろうという意見も出てきています。 |
土屋 | 東出さんはどうでしたか？ |
東出 | 自分も上村さんと同じで、OS間で同じ基準がないことが問題を難しくしているなと感じていました。明確な基準を決められたなら、お互い同じ実装にできると思いますし、判断基準も同じになって、開発を進めやすくなると思いました。ただそのOSそれぞれで実装者が異なる前提であれば、上村さんが言っていた相互レビューだったりということも必要で、そのすり合わせは人間でないと解決が難しいなと感じました。 |
上村 | 私は逆にAIを使ってどう解決できるかを考えていました。一度PRが出揃ったら、AIに差分のチェックを観点にしてレビューさせるとか。 |
Q4. 1ヶ月後、どのくらいの範囲を担当できていそう？
土屋 | なるほど。ありがとうございます。では次が最後の質問です。お二人がそれぞれ一ヶ月うちのチームで開発メンバーとして開発に携わったとして、今はUIを中心に開発に関わっていると思いますが、その後ろにあるドメイン層やデータ層、またその後ろにあるBFFまであるので、そのくらいの範囲の開発を担当できるようになっていると思いますか？ |
上村 | え～、1ヶ月後？ そうですね。1ヶ月立っても、アーキテクチャを完璧に説明できるようにはなってない気がします。で、今AIがあるからこそ自分はコードを書けているんですけれども、レビューするのは多分まだ自分はできないと思っていて、どんな観点でコードを見たら良いかとかは、まだ判断するための知識が一ヶ月では身につけられないんじゃないかと思っています。 |
土屋 | 東出さんはどうですか？ |
東出 | そうですね。SwiftのUIの話からすると、自分は書けないと思いますし、世の中的にUIの実装はAIが書く流れになっているから、わざわざ自分が書こうとは思わないと思うので、少なくともUIのところはないかなと思っています。 |
土屋 | じゃあ、1ヶ月後はKMP側のところをもうちょっと触っていてって感じですかね？ |
東出 | そうですね。勝手な印象ですが、Android側のほうがアーキテクチャに対して明るい実装に感じたので、Androidエンジニアであれば、もっと深いところまでいけるのかなと。 |
KMPの話を聞くつもりで始めた取材でしたが、お二人の口からKMPそのものの話は、ほとんど出てきませんでした。
4. で、どうするか
インタビューのすぐ翌日、iOSメンバーの土屋さん、宮川さんとランチに行って、インタビューで聞いた話を踏まえて、うちのプロジェクト、チームへの参画障壁について話すことにしました。土屋さんはインタビューの聞き手、宮川さんはiOSDCでスポンサーセッションに登壇していたメンバーです。
まず一致したのは、Swiftであるか、Kotlinであるか、KMPを使っているか、ということがそのまま参画の難しさになっているわけではなさそうだ、ということでした。上村さん、東出さんから「Kotlinが読めない、読みにくい」という趣旨のコメントは出てきていませんし、上村さんはOS間で認識を合わせる難しさについて「フルネイティブで開発していても同じだった」と言っています。難しいのは設計原則やSOLID原則の話と、それにまつわるアーキテクチャの話でした。
東出さんの「どこまでがKMP層で、どこまでがネイティブの層なのかを決める合意形成が難しかった」は、一見するとKMPの境界の話に見えます。ただ、この線はうちではとっくに決まっていて、合意形成の余地がありません。Presentation層がネイティブで、それより下がKMPです。つまり東出さんが難しかったと言っているのは、Presentation層とDomain層の責務の境界がどこにあるか、という話だと思われますし、上村さんが最初の説明を聞いた時点で「アーキテクチャの知識が必要なのではないか」と判断したのも、同じところを見ていたのだと思われます。
KMPとネイティブの境界が、そのままアーキテクチャの層の境界と一致していることで、新しく入った人から見ると、責務の境界で迷ったことが、KMPの境界の話として出てくるわけです。
アーキテクチャの理解にコストがかかること自体は、その構造を選んだことの対価です。実際、アーキテクチャについてある程度の経験がある場合には、それほど障害になっていません。中途で入ってきたメンバーが困っている様子はありませんし、旧アプリ側で長く開発していたメンバーも、参画にあたってフォローがそんなに必要でもなかった印象です。経験の浅い人が入ってきたときにどう見えるのかは、これまで観測する機会がありませんでした。
この課題に対してこれまで私たちのチームでは実践とコーチングによって対応してきました。ただ、これは時間がかかります。2週間でアーキテクチャを理解し、それに合わせて設計を行う技能を習得する、などという都合の良いものはないので、お二人に対しては、先に理解を前提にしないところまでタスクを割っておくことが本当は必要でした。Presentation層の責務がどこまでか、を渡すのではなく、渡す必要がないレベルまでタスクを分割して、やることを明確にしておく。Presentation層の理解がなくとも触れるようにはできるはずなんです。
これは短期のインターンに限った話でもありません。長く関わる人でも、最初はアーキテクチャに慣れてもらうためにタスクを分割しておくのは有用です。そしてそのタスク分割の世話を既存のメンバーが対応することは、実質的にアーキテクチャのオーナーシップを高める効果が期待できます。今後の新規参画者に対しては、積極的にそういう手段を採用していこうと考えています。
もうひとつ話したのが、差分のことです。上村さんからは、こういうコメントが出ていました。
今回は実際に同じ機能を二人で開発していて、OS間で出来上がったものに差分が発生してしまったことがあって、OS間の差を確認するフェーズは必要だと思いました。
これはインタビューで初めて出てきた論点ではなくて、その場で土屋さんが答えているとおり、チーム内でもすでに議論が進んでいるところです。
ただ、差分が出る場所自体は限定できています。Domain層より下は共通化されているので、実装仕様の差が生まれるのはPresentation層だけです。そしてその差が生まれる直接の原因は、同じ仕様を2回解釈していることです。AndroidとiOSでUIの設計と実装を分けている以上、解釈も2回発生します。
例えば越境によって一人が両方のOSを担当する場合には、解釈は基本的に一度で済むでしょう。しかしそれではせっかくOSそれぞれでUIの設計実装を分けた意味が希薄になる可能性も含んでいます。
ユーザーに提供する価値としてぶれてはいけない部分は同一の仕様を守るべきですが、設計・実装の過程で出てくる差分すべてが悪ではないはずです。つまり守るべき仕様が何であるかを明らかにし、それをできるだけ後手に回らないようにどの様に管理するのかが本質的な課題です。
私たちのチームでは現状それをPRレビューで見ているので、だいぶ後手に回っている状態です。レビュアーによって拾える観点が変わるので品質が一定にならないですし、両OS分を見比べるコスト自体も高く、シフトレフトをどの様に行っていくのか、活発にチーム内で議論がされているところです。
今現在で有力な手として整備を進めようとしているのは「ふるまい」の管理の強化です。差分が発生する箇所がPresentation層であるため、「ふるまい」という単位で守るべき価値を表現しやすいと考えられるからです。
具体的には受け入れ条件に紐づく「ふるまい」仕様としてPOやデザイナー、開発者の間で合意しておきます。そのうえで「ふるまい」にIDを振っておき、以後の開発でどのIDに紐づく設計・実装かをトレースできるようにしておくことで、設計・実装・PRレビュー時に守るべきラインを明確にします。
5. 「キツいのか」に対するアンサー
結論をまとめます。
- KotlinとSwift、AndroidとKMPとiOSの領域があることそれ自体はAIがある以上は手が留まる理由にはならず、KMP採用自体が大きな障害になっているというよりは、むしろ採用されているアーキテクチャの理解と運用のほうが、新規参画者にとって障害としては大きい。
- アーキテクチャの経験がある人は、責務の置き場所を判断するところで困っていない。中途のメンバーも旧アプリ側が長いメンバーも、フォローはあまり要らなかった。逆に経験が浅いメンバーからは、アーキテクチャのレイヤーとKMPの境界が重なって見えて、結果として混乱を招くことがあった。
- Presentation層をネイティブ実装層とすることで仕様差分が発生する危険に常にさらされることになるが、差分が発生する箇所自体は限定されている。うまく対応するための方法はいまだ開発の途上で、現状は「ふるまい」の管理でどこまで改善できるかに期待している。
以上を踏まえて、ブースでいただいた「KMPを採用することで認知負荷が高まる」というコメントに対して、いま私たちが返すとすれば、
「KMPを採用することで認知負荷が上がるというのは、そのとおりだと思います。」
「ただ、新しく入る人にとって一番キツいのがその認知負荷なのかというと、そうではなさそうだというのも見えています。実際に私たちのチームにインターンに来てくれた学生たちにインタビューしてみた内容から判断すると、読みにくさとしてはさして問題にならず、むしろアーキテクチャ、責務の境界の判断のほうがずっと難しい問題じゃないかという感じでした。」
「中途ではいってきたメンバーなどはアーキテクチャの判断にも慣れていましたし、それほど参画時に苦労していた様子はなかったですし、アーキテクチャの理解の問題だとすれば、マルチプラットフォームをどこまで採用しているかはあまり関係なさそうな気がしています。」
といったアンサーになるかなと思います。
終わりに
Kotlin Multiplatformの採用を決めた際、私たちのチームは新しい技術への期待感と少しの不安感で大冒険に出るように開発を始めました。それを振り返ってみて、KMPに限らず新たな技術にもらっていた熱に本当に様々な面で助けてもらいつつ、開発に向き合い続けられていることに、深い感動と感謝でいっぱいです。
そして小北さん、上村さん、東出さん、本当にありがとうございました。次に来てくれる方のためにちゃんと手を打っておきます。
インターン生二人のインタビュアーをやってくれた土屋さん、インタビューを受けての私たちのチームの現状の振り返りに付き合ってくださった宮川さん、ブログ原稿の下書きをレビューしてくれた吉本さん、チームメンバーの皆さんも、ありがとうございました。まだまだ開発は続きますが一緒に頑張っていきましょう。
そしてブースでたくさん私たちの話を聞いてくださり、たくさんコメントを下さった方々にもとても感謝しています。コメントが無ければこの振り返りもなかっただろうと思います。ありがとうございました。
