シェア
はてブ
めまぐるしく変化するテックの世界。技術を身に着けるうえで学ぶべきポイントや学習環境なども年々変わっています。 そこで「もしもいまの環境で、テックのことをイチから学び直すことになったら、自分はどんな風に勉強したいか」というIFストーリーを通じて、技術との向き合い方を考え直してみる企画「テック転生」。
今回は、ykws（@ykws__）さんに“自分だったらこう進めたい、モバイルアプリ開発の学習ロードマップ”を伺いました。
自己紹介
2004年から携帯電話向けの Java アプリ開発に携わり、2007年には携帯キャリア向けのコンテンツ提供やアプリ開発を行う会社を設立しました。スマートフォンの登場以降は Android/iPhone 向けアプリへと活動の中心を移し、現在は Kotlin Multiplatform を活用したクロスプラットフォーム開発を軸に、コードレビューや採用支援、育成、コーチングにも取り組んでいます。
本稿におけるモバイルアプリは Android/iPhone 向けアプリとしていますが、これまでの歴史にも触れるため、iアプリ/Vアプリ も含みます。
今回は「これまでのモバイルアプリ開発の経験をすべて失ったとしたらどう学び直すか」というテーマで、まず失うものとしてのモバイルアプリ開発を振り返り、その上でどこに注力して学び直すかを書きました。
20年のモバイルアプリ開発の歴史
今からおよそ20年前、筆者のモバイルアプリ開発のキャリアが始まった頃です。2005年、モバイルアプリ開発は Java で書いていました。モバイルアプリの動作する携帯電話は、NTT DoCoMo / Vodafone（のちの SoftBank） / au の3社から提供されていました。それぞれ iアプリ、Vアプリ（のちにS!アプリ）、EZアプリと呼ばれていました。いずれも各キャリアと企画段階からの承認を受けたのちにオフィスに専用回線を引いて開発と配信が可能になるクローズドな環境でした。
DoCoMo と Vodafone は組み込み機器向けの軽量な Java ME 基盤として、その上で Java アプリがモバイルアプリとして動いていました。各社それぞれアプリ開発向けに拡張する API を提供してくれていました。現在の Android と大まかな仕組みは変わらないです。開発環境には Eclipse を使用していて、各社提供のプラグインを導入して Emulator を利用して開発していました。Eclipse は結構不安定なところもあって、開発環境でつまづくことも多かったです。Java アプリといっても100KBの容量制限があったため、極力クラスは作らずに、画像リソースも複数の画像を一枚の画像にまとめて必要な領域を座標で指定するようなことをしていました。
当時、 OS の更新はオンラインではなくオフラインで行われていました。発売前の携帯電話向けにプリインストールされるアプリを開発している会社には、 OS の更新の度に更新済みの検証端末をバイク便に頼んで人力で送っては、古い検証端末を回収していました。
2008年にそれまでのクローズドな環境が一変します。iPhone SDK が日本にも展開され始め、Apple 社の iPhone 向けにモバイルアプリを誰でも配信できるようになりました。発表を受けて macOS でしか開発できないと知り、すぐに購入しました。それまでは Windows で開発をしていました。同年に Android SDK も正式に公開され、時代が一気にオープンな流れに変わり始めました。iPhone はハードキーを前提としたモバイルアプリをディスプレイにタッチして操作するユーザインターフェースも一変させ、ユーザがアプリを触る没入感を得られる体験そのものを変化させました。
2013年頃から Android アプリ開発の統合開発環境として Android Studio が利用できるようになり、Eclipse から脱却し、Google 主導で開発者体験が飛躍的に向上していくようになりました。
2014〜2017年にかけて、モバイルアプリは規模が大きくなり、データフローも複雑になる中、リアクティブな考えが RxJava / RxSwift として移植されて爆発的に流行ります。
2018年頃から Kotlin Coroutines によってスレッドをより安全に簡潔に扱えるようになっていきました。
2019年、Apple は宣言的 UI フレームワーク「SwiftUI」を発表しました。これにより UIKit に代わる新たな UI の構築方法が提示され、同時に非同期データフローのためのフレームワーク「Combine」も登場することで、UI とデータフローの設計が大きく変わり始めます。
一方 Google も「Jetpack Compose」を発表し、従来の XML ベースの UI から宣言的な UI 構築に変わっていきます。あわせて、Google は Kotlin を Android アプリ開発の推奨言語に指定すると発表し、Android アプリは Kotlin で書くのが主流になっていきました。
2020年はコロナ禍でクライアントのビジネスが縮小し、開発体制も縮小することを経験しました。Kotlin でも Flow が安定版になり、Swift と同様に非同期データフローが変わっていきます。Kotlin が主要言語になったことと相まって RxJava を置き換える動きが活発になりました。
2021年、Apple からは Swift Concurrency が発表され、非同期処理と並行処理を安全に記述できるようになりました。iOS の方も複雑になっていく RxSwift を置き換えていくようになっていきました。
2022年は Kotlin Multiplatform Mobile のベータ版が公開され、マルチプラットフォーム開発に取り組み始めました。
2023年、コロナ禍を経て iOSDC / DroidKaigi / FlutterKaigi がオフラインで開催され、初めて現地参加し、対面でのコミュニティ活動が活発になりました。そこでの縁もあって、Flutter から Native への移植案件に関わることにもなりました。
また SwiftUI の状態管理に特化したデータフローとして Observation が登場します。
2024年、Server-Side Swift コミュニティから Swift と Java を相互運用するための Swift for Java が発表されました。新しいコードを Java で書くというよりは、古い Java ベースのコードを Swift に置き換えていくための移行のための取り組みのようです。モバイルアプリの表舞台から消えようとしていた Java ですが、 Swift と相互運用する形で再登場したのは感慨深いです。FlutterKaigi に参加して、どの言語も成熟してきており、メンバー構成に合わせて言語を選択できる時代になってきていると感じました。メンバーの得意な言語が Kotlin なら KMP、Dart なら Flutter、JavaScript なら React Native とメンバーに合わせて決めても良さそうに思いました。
2025年、生成AI を活用するのが一般化してきました。各社 AI を開発やコンテンツに扱えるように注力し、コンテキストがより重要になってきて、ユーザの体験としてもアプリを開いて操作するのではなく、ユーザの目的に応じて、アプリが裏側で機能を提供する形に変わっていきそうな流れを感じました。
この20年で変わったこと
- 開発マシン： Windows → Mac
- プログラミング言語： Java → Objective-C → Kotlin / Swift
- 開発環境： Eclipse → Android Studio / Xcode
- パッケージマネージャ：Ant / CocoaPods → Maven / Carthage → Gradle / Swift Package Manager
- レイアウト記述： 座標指定 → GUI（XML / Storyboard） → 宣言的 UI（Jetpack Compose / SwiftUI）
- データフロー： パラメータ → リアクティブ → 宣言的データフロー（Flow / Combine + Observation）
- スレッド管理： 直接 → キュー（GCD） → 宣言的非同期（coroutines / Swift Concurrency）
- ユーザインターフェース： ハードキー → ディスプレイタップ
- デバイススペック： ディスプレイサイズ、メモリ領域、処理速度
- ネットワーク： 通信速度、通信量
- OS アップデート： 有償 / オフライン → 無償 / オンライン
- アプリ配信： 携帯キャリア（NTT DoCoMo / Vodafone / au） → OS プラットフォーマー（Apple / Google）
- 開発体制： 一人開発 → チーム開発
この20年で変わらなかったこと
- コンピュータの基本原則（入出力、状態遷移、非同期処理など）
- クライアントサーバの構造（モバイルは UI を提供し、データはサーバに蓄積される）
- プラットフォーム至上主義（プラットフォーマーの承認なしにアプリは配布できない*1）
- 携帯電話の特性（一人一台、パーソナルなデータを扱う、携帯する）
- モバイルアプリのライフサイクル（Create / Resume / Pause / Destroy）
- JVM ベースのアプリケーション
プラットフォームを理解する必要性
ここで言うプラットフォームはアプリの配信基盤を指しています。この20年間、配信基盤を担うプラットフォーマーを理解する必要があることは変わっていないことの一つです。PC / Web 系の開発とは一番違うところだと思います。
20年前は、アプリを配信するためには携帯キャリアに企画の承認をもらう必要がありました。現在もアプリを配信するためには Store のオーナーである Apple / Google の審査をパスする必要があります。モバイルアプリを配信するためには、プラットフォーマーの意向を汲み、それに従った上で表現を追求していくことが求められます。
幸い、各社のガイドライン、サポートは充実しているため、互いに実現したいことの理解を擦り合わせるには良い環境になってきています。そういったことに振り回されたくない場合は、モバイルアプリの市場を避けるのも選択肢の一つになります。またプラットフォームの運営側に回ることがとても強大な力を持つこともしみじみと感じます。
ここには少し隙間があって、プラットフォーム・オン・プラットフォームを成功させている事例も見られます。古くは、モバゲーやグリーなどアプリの中に市場を形成してアイテム課金を成功させました。現在では、LINE、メルカリ、PayPayなどアプリの中に市場を形成して金銭のやり取りが可能になっています。
個人開発からチーム開発へ
当時は、開発するアプリの規模が小さかったこともあり、一人で担当することが常でした。現在は、一人で担当することは稀で、チームで開発することが増えています。GitHub を土壌としたレビュー文化が浸透しているのが大きいです。誰か一人に属人化せずに、メンテナンスが可能な状態を維持する考えが広く普及しています。動くコードよりも理解できるコード。継続的にそのコードの作者以外も修正できるようにすることが求められています。
自分はどの部分を担当するのか
モバイルアプリは、その市場の拡大と、端末スペックの向上に伴い、表現の幅が広がりました。そのため、一人でその全てを把握し切るのは難しくなっています。 iOS の UI だけでも UIKit / SwiftUI OS バージョンごとの制約、Human Interface Guidelines の把握、そのいずれも毎年更新されます。
そのほかに各種 framework や サードパーティのライブラリ、SaaS との連携、CI / CD、開発環境としての Xcode の新機能とあって、自分がどの部分に対して特に苦もなく楽しんでキャッチアップを続けることができるか、そういう専門性を持ち、それぞれの専門分野のメンバーが集まることで、チーム全体として取り組む。すべてを網羅せず、自分の得意・やりたい領域に絞っても良いだろうし、そうしないとキャパオーバーになりかねません。
今からモバイルアプリを開発するなら
ここまでを前提として、もし今記憶喪失になりモバイルアプリ開発を学ぶとしたら、結論としては、モバイルアプリを開発するためには学ぼうとは思いません。モバイルアプリはこの数年で確実に変化していく部分だと予想します。モバイルアプリは形を変えて別の何かに置き換わるでしょう。新しいプラットフォーマーとして既存のプラットフォームを置き換える側に回るためにモバイルアプリ開発を学ぶと思います。
まずこの20年で変わらなかったことを中心に学び直します。逆にこの20年で変わっていったものは、最初の段階では深くは踏み込まないようにします。特に SDK や OS 周辺の framework やライブラリの変化は目まぐるしいものがあります。
モバイルアプリに限定せずプログラムの基本をもう一度学びます。でも基本を学ぶのは難しいと思います。それを純粋に楽しめる自信はありません。そこで、やはり今手元で動く iPhone か Android デバイス向けに小さなアプリを作成して動かしながら学びます。手元のデバイスで動くのはモバイルアプリの不変の面白さだと思います。幸いどちらも Apple と Google からチュートリアルのドキュメントとビデオは充実しています。その過程で自分の表現したいものがどちらのマーケットで、あるいは両方でリリースしたいか、理解を深めて判断し取り組みます。
その小さなアプリを看板にして、その過程で自分がどのプロセスに強みがあるかを把握して、チーム開発に参加します。
そして、プラットフォームを作る側に回れるように挑戦したいです。次の構想はモバイルアプリレスなアプリケーションをイメージしていて、アプリを開いて何かをする体験ではなく、何かしたいことがあって、アプリの機能を利用する形になっていくでしょう。イメージとしては App Intents ですが、それに限定しなくても良いと思います。その先にはモバイル機器そのものを個人が携帯しなく済むようになるでしょう。
町中にデバイスは溢れています。特に落とすと割れてしまうようなディスプレイを個人が持ち歩くのはリスクが高すぎるし、その必要性も小さくしたいし、それが実現できるようになってきていると思います。そのための下地として、モバイルアプリ開発を学びます。
次の20年でモバイルアプリの形は確実に変わると思うし、変えていかなくてはいけないことだと思っています。
*1:承認なしに配布する方法はありますが、広くユーザに安全に配布する観点からあえて断定的な表記にしています。
