「3年くらいは食っていける」と言われて、スマホアプリで15年食べている

Posted at 2026-11-01

「これからスマホアプリをやれば、3年くらいは食っていけるよ」

そう言われて、ガラケーの組み込みエンジニアから、スマホアプリ開発に移りました。転向したころに扱っていたのは、Android 2.1やiOS 4.3です。

あれから15年ほど。いまだに、スマホアプリで食べています。

Qiitaも2026年で15周年。同じくらいの年月を、同じ業界の片隅で過ごしてきたことになります。Qiita 15周年記念カレンダーのテーマに合わせて、当時と今を振り返ってみます。

道具はずいぶん変わりました。自分の先を見る目が、それに追いついたかどうかは別の話です。

転向前：ガラケーの端末側と通信まわり

もともとは、ガラケーの端末側で通信まわりを担当していました。

USIMまわり
3.5Gや3.9Gと呼ばれていた世代の対応
SIPや、PoC（Push-to-talk over Cellular）に関わる仕事

世代に「.5」や「.9」が付く時代でした。あと少しで4G、というところを、小数点で刻みながら進んでいました。

そして、読んでいた通信の技術仕様は英語です。

学生時代の自分は、こう考えていました。いずれ、ほんやくコンニャクのようなものが出てくる。そうなれば英語の勉強は意味がなくなる。なので、あまり勉強していません。

技術の進歩には期待していました。自分が勉強しなくて済む方向に限っては。

英語の仕様書を前にして、こんなに英語がついて回るなら真面目にやっておけばよかった、と思いました。

そこへ、冒頭の一言です。

Android 2.1：Eclipseと、性能との格闘

Androidの開発環境は、EclipseにADTプラグインを入れたものでした。Android Studioの最初のプレビューが発表されるのは、2013年です。

言語はJava。ただ、当時の端末では、Java側の処理の重さが気になっていました。

当時のAndroidの実行環境はDalvikです。JITコンパイラが導入されたのはAndroid 2.2からで、2.1にはまだありませんでした。Javaという言語全体の話というより、当時の端末と実行環境の話です。

細部の記憶は少し曖昧ですが、重い処理はNDKを使ってネイティブ側に書いていた気がします。

Javaのアプリを作りに来たのに、気づけばネイティブコードを書いていました。組み込みから抜けたつもりが、半分くらい戻っています。

iOS 4.3：retain/releaseと、英語の審査

iOSはObjective-Cでした。Swiftが発表されるのは2014年です。

当時の自分の開発環境では、retain、release、autorelease を使って、オブジェクトの寿命を自分で管理していました。

ここは、組み込み出身なので、概念を理解するのに苦労した覚えはありません。Objective-Cでは参照カウントを使い、自分が所有した分を適切に手放す。管理の方式は違っても、確保と解放に責任を持つ感覚にはなじみがありました。

ARC（自動参照カウント）がXcode 4.2に入ったのは、iOS 5が登場した時期です。ただし、ARCはコンパイラの機能で、iOS 4向けにも利用できました（weak参照は非対応）。正確には「iOS 4.3だから手書き」ではなく、「そのころ自分が使っていた環境では手書き」でした。

苦労したのは、審査のほうです。

リジェクトの理由も、こちらの説明も、当時のやりとりは英語。ガラケーの仕様書に続いて、ここでも英語でした。転向先までは変えましたが、仕様書と審査の言語までは変えられません。

当時のWeb翻訳は、まだ頼りないと感じていました。Google翻訳で英語と日本語の間にニューラル機械翻訳が導入されるのは、2016年11月です。

英語でリジェクト理由を読み、英語で説明を返す。メモリよりも、こちらのほうがよほど解放してもらえませんでした。

15年で変わったもの

項目	当時（2010〜2011年ごろ）	今（2026年）
Androidの開発環境	Eclipse＋ADTプラグイン	Android Studio
Androidの言語	Java。必要に応じてNDKも利用	Javaに加えてKotlin。Kotlinの公式サポートは2017年から
Androidの実行環境	Dalvik。JITは2.2から	ART。Android 5.0から標準
iOSの言語	Objective-C	Objective-Cに加えてSwift。Swiftの発表は2014年
iOSのオブジェクトの寿命管理	Objective-Cでretain/releaseなどを手書き	ARCによる自動管理
画面の作り方	AndroidのレイアウトXML、iOSのInterface Builderなど	Jetpack Compose、SwiftUIも加わる。既存のViewsやUIKitとも併用できる
英語の仕様書と審査	辞書とWeb翻訳	機械翻訳と生成AI
通信サービス	3Gが現役	ドコモのFOMAとiモードも、2026年3月31日に終了

当時の道具が、すべて一斉に引退したわけではありません。JavaやObjective-Cも、従来の画面の作り方も、新しいものと並んで残っています。

一方、ガラケーの端末側で仕事をしていたころの3Gは、今年の春にドコモでもサービスを終えました。いちばん時代の区切りを感じるのは、開発環境よりも、この行かもしれません。

15年たっても、変わらなかったもの

参照カウントの考え方は、今も残っています。

Swiftでも、クラスのインスタンスの寿命を管理するのはARCです。手で retain や release を書かなくなっても、互いに強参照を持ち続ければ解放されない問題は残ります。関係に応じて weak や unowned を選ぶなど、参照の設計は今も必要です。

NDKも、今も現役です。

処理の性質に応じてネイティブコードを使ったり、既存のC/C++の資産を持ち込んだりする入口として残っています。昔お世話になったものが、ちゃんと今の道具箱にも入っています。

審査も、今もあります。

英語を読む苦労は、翻訳とAIでだいぶ減りました。ただ、リジェクトの通知を開くときの緊張だけは、翻訳では消せません。

年代・技術事項の参考資料

3年と言われて、15年

「3年くらいは食っていける」という話は、少なくとも当たりました。3年で終わるとは言われていません。

その3年を大きく超えて続いた間に、JavaからKotlinへ、Objective-CからSwiftへ、手書きの release から自動へと、道具を持ち替えてきました。

一方で、学生時代の自分の予言も、だいぶ当たりに近づきました。機械翻訳と生成AIのおかげで、英語の仕様書も審査の文面も、今はかなり楽に読めます。ほんやくコンニャクは、だいたい来ました。

ただし、来たのは、仕様書と審査でひととおり苦労したあとです。

技術の到来は予想していました。納期を確認していませんでした。

AIを見くびる根拠が、ラーメン屋だった

2011年は、IBMのWatsonがアメリカのクイズ番組「Jeopardy!」で、人間のチャンピオンに勝った年でもあります。

当時はそのWatsonを見ても、まだまだだなと安心していました。機械学習が話題になっても、はいはい、と聞き流していました。

いちばん安心したのは、ChatGPTが出てきたばかりのころです。

「近くのおすすめのラーメン屋は？」と聞いてみたら、存在しないラーメン屋を挙げてきました。それを見て、プログラマの仕事はまだまだ取られないな、と安心しました。

店が見つからないという話から、自分の職業の将来まで判断していました。AIの回答にも問題がありましたが、こちらの推論もずいぶん大胆です。

ChatGPTの公開は2022年11月30日。2026年の今、まだ4年ほどしかたっていません。今では、この記事の構成と文章も、そのAIと一緒に作っています。

英語は、いずれ機械が訳してくれると思ってサボった。AIは、まだまだだと思って聞き流した。

その後、ニューラル機械翻訳や生成AIという形で、軽く見ていた技術が、待っていたほんやくコンニャクに近づいてきました。こちらの期待と油断は、同じところにつながっていたようです。

なので、過去の自分に一つだけ言えるなら。

「AIを、なめるな」

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up