Flutterの誕生前夜：ブラウザ開発の限界と新たな問い
こんにちは、OSSのレキシラジオです。このポッドキャストでは、エンジニアであり、最近いろんな人と話す機会が増えて楽しくなっているhentekoは、毎週一つのOSSプロジェクトを取り上げて、そのプロジェクトにまつわる歴史を紹介する番組になります。
最近ですね、いろいろな人と喋る機会が増えてきまして、初めましての方とお話しすることも多くなってきたんですけど、やっぱり人と話すって新しい視点もらえるし、単純に楽しいんですよね。
もっと積極的に外に出ていきたいなと思う今日このです。さて、今週のテーマはFlutterについてです。見ていきましょう。
今回の主人公は、ブラウザを10年間作り続けたエンジニアがブラウザを捨てて始めたプロジェクトのお話です。
Flutterを使ったことがある方も多いんじゃないかなと思うんですけど、Googleが開発したオープンソースのUIフレームワークで、一つのコードベースからiOSやAndroid、Web、Windows、MacOS、Linuxのアプリを作れるものです。
GitHubのスター数は17万5000以上、月間アクティブ開発者が約280万人もいるクロスプラットフォーム開発の分野で最も多く使われているフレームワークです。
普段、Flutterをランしてホットリロードで画面がバッと変わるのは当たり前に使ってるかなと思うんですけど、じゃあFlutterがどうやって生まれたのか、なんで今の景色になったのかっていうのを苦手知らない方も多いんじゃないかなと思います。
実はFlutterってGoogle Chromeを作っていたチームから生まれたんですよね。ブラウザのレンダリングを極めた人たちが、もうブラウザの枠に収まらなくていいんじゃないかっていうようなことを考えて、画面そのものを再発明した。今日はそんな物語を見ていけたらなと思います。
2014年、Googleのオフィスが一角で、Chromeチームのエンジニアたちがある実験をしていました。Chromeのレンダリングってどこまで速くなるんだろうっていうものです。
彼らはですね、大胆なことをやっていました。Chromeの膨大なコードベースから、ごく一部のウェブサイトとの互換性のためだけに存在するコードを取り除いてみました。
Blynkというレンダリングエンジンのコードを半分以上速く落とした形になります。結果はですね、HTMLのパースが19倍も速くなりました。
これがこのチームの心に火をつけたんです。ウェブの互換性を維持しながら速くするのは限界がある。でも、そもそもウェブの制約から自由になれたら、というような問いです。
この実験の中心にいたのが、エリック・サイデルさんとテックリードのアダム・バースさんです。
サイデルさんはウェブの世界で長年活躍してきたエンジニアでした。ChromeやBlynkの開発を通じてブラウザの限界を知り尽くしていました。
そんな彼の中に渦巻いていたのはある素朴な問いだったんです。
なぜ同じ画面を作るという仕事なのに、iOSやAndroidウェブでこんなにもやり方が違うのか。
ゲーム業界では一つのコードから何十ものプラットフォームに出すのが当たり前なのに、アプリ開発ではそれができない。
何を作りたいかから始めるブレーキなのに、最初に考えるのはどうやって作るのかというところです。
このフラストレーションがですね、Flutterの原動力となったわけです。
2014年10月、サイデルさんは決断します。
Chromeチームから離れて、Skyという新しいプロジェクトを立ち上げました。
Ian Hicksonさんという、HTML5の使用策定にも関わった重要人物が後にこう振り返っています。
Flutterは旧Googleの文化から生まれた最後のプロジェクトの一つだった。
当時のGoogleには社員が新しいプロジェクトを自由に立ち上げられる文化があったんですね。
アルファベット設立前の実験の推奨がされていた時代です。
Skyはその最後の波に乗ったプロジェクトでした。
Flutterの設計思想：独自レンダリング、Square、Dart言語
Skyチームは3つの大胆な賭けに出ます。
一つ目は独自レンダリングです。
OSのUIコンポネントを一切使わずに、自前で全ピクセルを描画するというような選択です。
普通はiOSならUIキット、AndroidならAndroidのUIフレームワークを使いますよね。
それを全部捨てて画面の全てを自分たちで描く。
自由度は圧倒的なんですけど、全てを自分で作らなきゃいけないというデメリットもあります。
二つ目はSquareというGoogleの描画ライブラリを土台にしたことです。
ChromeやAndroidでも使われている実績のあるエンジンです。
そして三つ目がDartという言語を選んだことです。
当時JavaScript全盛の世界でですね、あえてDartを選んだんです。
JITコンパイルで開発中はホットリロードができて、AoTコンパイルで本番では高速に動く。
両方できる言語ってなかなかなかったかなと思うんですよね。
でも決め手はですね、技術的な理由だけではなくて、共に進化できることでした。
DartチームもGoogle社内にいたからこそ、Flutterのために言語を書いてくれというような頼める環境だったんですね。
これは後の展開で重要になってくるので、少しだけ覚えておいてください。
そして2015年4月、DartDeveloper SummitでサイデルさんがSkyを初めて世界にデモします。
Android上でしか動かなかったんですけど、掲げた目標は120fpsです。
当時のスマートフォンアプリでは60fpsが標準の時代にその倍ですね。
画面のスクロールやアニメーションが人間の目で見てもはっきりわかるくらい滑らかになる水準を目指すと宣言しました。
そしてもう一つの目玉がホットリロードです。
従来のアプリ開発って陶芸みたいなものだったんですけど、コードを書いてビルドして焼き上がるまで待つというような感じですね。
そして画面を確認してダメだったらまたやり直すという。
それがホットリロードだったら粘土を指で触りながらリアルタイムに形を変えていけるというような形で、
この体験は革命的でした。
ただですね、この発表の当時コミュニティの反応は最初控えめでした。
ダート自体がニッチな言語とみなされていましたし、
サイデルさん自身もプロジェクトが勢いを得るまでに数年応用したと認めています。
Flutterの成長と普及：1.0リリースからクロスプラットフォームへの拡大
そして2016年、スカイはFlutterと名前を変えます。
羽ばたくという意味の名前が示すように、Android限定だった世界から翼を広げ始めました。
ここで伝えたいのはですね、普段使っているツールに不満を感じたとき、
そもそもなぜこうなっているのかというところまで遡って問い直すことで、
まったく新しいアプローチが生まれるというようなことです。
Flutterの創設者たちは苦労も10年作ってきたからこそ、
Webの互換性レイヤーこそがボトルネックだと見抜けました。
深く知ることが壊す力になるというような例ですね。
さてここからFlutterの成長期に入っていきます。
2017年8月、意外な場所からFlutterへの追い風が吹くことになりました。
ブロードウェイミュージカルハミルトンの公式アプリがFlutterで構築されました。
Google外で作られた初の主要な商業Flutterアプリ。
まだアルファ版のフレームワークで本番アプリを出すって、なかなか冒険のことかなと思います。
そして2018年12月4日、ロンドンのサイエンスミュージアム、
Flutter Liveというイベントで、Flutter 1.0の正式リリースが発表されます。
4年前、Googleのホワイトボードの前で始まった実験が、
ついに本番で使えますよというような形で、世界に宣言された瞬間でした。
Google Adsアプリをはじめとする社内プロジェクトでの採用事例も公開されて、
Googleが自分たちのプロジェクトで使っているという、
何よりも強い信頼の証が示されました。
2015年の静かなデモから3年半ですね。
本当にうまくいくのという会議を実績で答えた瞬間でした。
ここで少し面白いエピソードがあるんですよね。
さっきダートチームがFlutterのために言語を変えてくれる環境だったというお話をしたじゃないですか。
実はですね、Flutter採用時にはダートにAoTコンパイラがなかったんです。
本番で高速に動くための仕組みがまだ存在していませんでした。
するとですね、ダートチームは何をしたかというとですね、
FlutterのためにAoTコンパイラを開発してくれました。
これ例えるならですね、自分の料理に合わせて隣の醤油屋さんが新しい醤油を仕込んでくれたみたいなものなんですよね。
他の言語では絶対にあり得ない、うちのフレームワークのために言語を変えてくれ、
なんてJavaScriptの世界で頼めるわけないじゃないですか。
この共に進化していく構造こそがFlutterの最大の強みでした。
そして2021年3月、Flutter 2.0をリリースします。
Web安定版を含む6つのプラットフォーム、iOS、Android、Web、Windows、MacOS、Linuxへの対応を宣言しました。
デスクトップ版はまだベータ段階でしたが、1つのコードベースであらゆる画面を作るという、
サイゼルさんの夢が形を取り始めたというような形です。
同時にですね、Dart 2.12で導入されたのがSound Null Safetyです。
普段Flutterでハテナマークとかビッグマークを書いている方多いかなと思うんですけど、あれですね。
変数がデフォルトで、Nullを持てない状態になりました。
そして2022年5月、Flutter 3.0で、ついに6プラットフォーム全てが安定版になりました。
この時期ですね、企業での採用も爆発的に加速していきます。
例えば、ラテンアメリカ最大のデジタルバンク、Nullバンクは、
1億人以上の顧客にFlutterアプリを提供して、生命保険商品をわずか3ヶ月で立ち上げました。
Google Payは、170万行のコードベースを統合して35%削減。
BMWやAlibabaでも大規模な採用が広がっていきました。
iOS App Storeの新規アプリの約28%から30%近くがFlutterで構築されるまでに成長していきます。
クロスプラットフォームイコール妥協の産物というような常識が完全に覆されました。
ここで大事なのは独自レンダリングという設計判断のことなんです。
当初はアプリサイズが大きいやネイティブの見た目を再現しにくいというトレードオフがありました。
でもこの判断があったからこそ、モバイルからウェブ、デスクトップへと一貫性を保って拡張ができました。
トレードオフを引き受ける覚悟がFlutterの差別化を生んだんです。
Flutterの試練：技術的進化と組織的課題
さてここからはFlutterにとっての試練の時期です。
技術的に最も充実した時期に組織的な機器が同時進行するというなかなか厳しい展開になっていきます。
まず技術面からです。
2023年5月ダート3.0がリリースされました。
ダート史上最大のリリースで100%のサウンドのセーフティ、それからパターンズという新機能が入りました。
例えばスイッチでウィジェットを返すときにパターンマッチが使えるようになったりして、
フラッターの画面は状態の関数であるという哲学を言語レベルで表現しやすくなりました。
フラッターとダートの強調的な進化がここでも発揮されたわけです。
一方でフラッターの成長の裏でずっと開発者の悩ませていた技術的な課題がありました。
シェーダーコンパイルジャンクと呼ばれる現象です。
スキャンエンジンが新しい秒誤パターンに初めて出会うと画面が一瞬カクつくというような問題です。
これを根本から解決するために開発されたインペラーという新しいレンダリングエンジンです。
2019年に開発が始まって、AoT方式でシェーダーをビルド時に処理するというような仕組みでした。
さらにiOSではメタル、Android、VulkanというモダンなGPU APIを直接活用していました。
そして2023年にiOSでデフォルトとなり、
2024年12月には最新のAndroid端末でもデフォルトになりました。
ここで注目してほしいことなんですけど、Flutterは創設時に選んでいたSquareさえもより良いものに作り変えていったというようなことです。
壊して作り直す。これがFlutterのDNAなんですよね。
Chromeのコードを削ぎ落とすところから始まって、Webのレンダリングモデルも捨てて、そしてSquareさえもインペラに置き換えました。
さてここからが組織の話です。
技術的に最も充実した時期に重要人物たちが次々とプロジェクトを去っていきました。
2022年、創設者のサイデルさんがGoogleを退職します。
自らFlutter向けのコードプッシュサービス、Sharebirdを創業しました。
コードプッシュというのはアプリストアを返さずにコードを更新する仕組みのことで、Flutterには標準で備わってはいませんでした。
自分が作ったフレームワークの欠点を自ら埋めにいったというような形ですね。
そして2023年、Hicksさんが18年間ストームでGoogleを退職。
開講ブログでは、Google内部の文化の変質について率直に語っていました。
そして同年6月には、Flutterをアルファから3.10まで導いたプロダクトマネージャーのTim SneesさんがGoogleを離れてAppleへ移籍しました。
例えるならですね、人気ラーメン店の商業者、味を決めるスープ職人、そして名物店長が相次いで独立転職していくようなものです。
店は残っているんですけど、味は変わらないと言われていますし、なんですけど、でも常連客の心には不安が広がるというような形でした。
そして2020年4月に決定的な出来事が起きます。
Google IOの直前という最悪のタイミングで、GoogleがFlutterだとPythonチームを含む約200人のレイオフを実施しました。
Googleは戦略的変更はなしと表明しましたが、約50人のチームで100万人以上の会社をサポートしていたFlutterにとってこの影響は大きかったです。
さらにですね、GoogleはFlutterを福祉屋OSのUIフレームワークとして採用して、Google Nest Hub、第一世代のインターフェース全体をFlutterで実装していたんですけど、福祉屋プロジェクト自体が縮小してしまいました。
これもFlutterのGoogleにとっての戦略的重要性に疑問符をつける一因になりました。
そして2024年10月27日、ついにFlutterのフォークが誕生します。
フロックと名付けられたプロジェクトです。
フロックの目標はですね、Flutterとの互換性を維持しつつ、レビューとマージを加速するということでした。
分裂ではなくてですね、開発を加速してFlutterリポジトリに還元することを目的とした、愛しているからこそのフォークだったんです。
ここで伝えたいのはですね、OSSは技術だけではなくて、ガバナンスやコミュニティの持続可能性が生命線だというようなことです。
Flutterは技術的に最も充実した時期にですね、Google依存モデルの限界からの停止しました。
使う人は増やせても、作る人を増やすのは桁違いに難しいということです。
エコシステムの周辺はPubDevというパッケージ共有サービスで約5万8千パッケージまで豊かに育ちましたけど、中心への参加は困難なままでした。
これは企業主導のOSSが抱える構造的なジネマかなと思います。
そしてレイオフの不安、ソーセスメンバーの退場、フォークの誕生、でもですね、Flutterの技術的進化はこれでは止まりませんでした。
Flutterの未来：技術進化と広がる応用分野
2025年8月のFlutter 3.35ではインペラがジャンクフレームを30から50%削減しました。
そして11月のFlutter 3.38ではWebアセンブリが安定版になって、Webアプリのロード速度が最大40%向上します。
Web上でのホットリロードもデフォルト化されました。
そしてFlutterはですね、スマートフォンの画面を越え始めています。
トヨタが2026年型RAV4の書斎インフォテイメントシステムにFlutterを採用します。
LGがWebOS Smart TVにFlutterを展開。
XiaomiのEV CompanionアプリもFlutterです。
画面があるところならどこでもFlutterみたいな、そういう領域に到達しつつあります。
ここで競合のお話もしておくと、FlutterとReact Nativeの競争は面白くてですね。
Flutterの対等に刺激を受けて、React Nativeもアーキテクチャを大幅に一新しています。
お互いに高読み合った結果ですね、かつてネイティブVSクロスプラットフォームといわれた議論はですね、事実上集結しつつあります。
小鳥マルチプラットフォームも急成長していて、クロスプラットフォーム開発の選択肢がかつてなく豊かになってきているかなと思います。
最後にですね、斎藤さんの問いに戻りたいと思います。
2014年、Googleのホワイトボードの前で立てた問い。
なぜ同じ画面を作るという仕事なのに、プラットフォームごとにやり方が違うのか。
あれから11年、その問いに対するFlutterの答えはまだ完成してはいません。
Webアセンビリのデフォルト化、インパラの全プラットフォーム展開、Flutter GPA、APAの安定化、やるべきことはやめずにです。
でも一つだけ確かなことがあります。
Flutterはたった一つのなぜから始まったということです。
当たり前を疑って、ゼロからエンダリングエンジンを作り直すという無謀な挑戦を選び、仲間を集め、3年かけて1.0にたどり着き、やがて世界中の開発者の手に届きました。
何を作りたいかから始めよう、どう作るかは後から決めればいいという、斎藤さんのこの哲学はFlutterというプロジェクトの中で今も生き続けています。
それでは最後にまとめたいと思います。
Flutterの教訓：壊して作り直すDNAとOSSの持続可能性
Flutterの歴史はですね、壊して作り直すの繰り返しでした。
Chromeの行動、創業としてウェブのレンダリングモデルを捨て、スキャーさえもインパラで置き換えました。
深く知り、大胆に壊して一緒に育てる。
そしてその道のりは技術だけではなくて、ガバナンスの難しさも浮き彫りにしました。
OSSにおいて使う人を増やすことと作る人を増やすことは全く別の課題なんだなということを、
これはFlutterに限らず多くのプロジェクトに当てはまる教訓かなと思っております。
さて、今回のお話は以上となります。
もし少しでも今回のお話がためになったなと思ったら、お聞きのプラットフォームでの高評価とフォローの方をお願いします。
また、XなどでハッシュタグOSSの歴史ラジオをつけて感想をつぶやいてもらえると、僕のモチベーションになりますので、ぜひよろしくお願いします。
次回はBIMスクリプトのリンターツール、Bintの歴史について、作者の国明さんをお招きしていろいろお話を聞いてみたいなと思っております。
それではまた次回お会いしましょう。バイバイ。
