フロントエンド開発のマルチプラットフォームとしてGoogleが推しているFlutterは、渋谷系の人々からも熱い注目を浴びていますが、飯田橋系1の人々こそ使うべきだと考えます。その理由を述べたいと思います。
なお渋谷系としてもFlutterを使う理由は多く、「Flutterとは？ エヌ次元が企業としてFlutter開発を採用する理由」が参考になります。（渋谷にオフィスを持つ典型的な渋谷系企業ですね・・）
1. モバイルファーストなマルチプラットフォーム
2000年代からWebシステムの常識であったMVCモデルは、非同期かつ複雑なWebシステムをViewとModel（ビジネスロジック）とに分離して、開発保守効率を上げることが目的でした。この方面で成功したフレームワークが、StrutsやSpringです。対象がPCだけでなくスマホやタブレットと増えてきても、画面サイズのバリエーションが増えたものと位置づけて、PC向けWeb画面をマルチウインドウを考慮したレスポンシブデサインにする、というやり方で対応できました。そのため、ネイティブアプリとは生態系が分かれていました。
2016〜7年から2010年代に入って、Webにモバイルファーストの潮流がやってきました。まずスマホ向けにインタラクティブに溢れたページをデサインし、それを横に並べた形でPC向けを作ります。Webの作り方も、従来のサーバーサイドレンダリングから、クライアントサイドでインタラクティブにレンダリングをする「SPA」が主流になり、ロジックの多くがクライアントサイドのUI向けに実行されるようになり、ネイティブアプリとの親和性も高くなりました。モバイルを、画面サイズのバリエーションではなく、一種のエッジコンピューティングと位置づけたことになります。また、Webバックエンド開発は、さまざまなPaaSやそれらを組み合わせたマイクロサービスアーキテクチャーが主流になり、ビジネスロジックの軽量化が進みました。その反面、クライアントサイドにビジネスロジックが流れ込んできて、従来のMVCモデルでは対応が困難になってしまいました。
2022年12月28日追記: 2020年ころから、SEO対策や体感性能向上のため、一部サーバーサイドに回帰する傾向があり、サーバーサイドとクライアントサイドのハイブリッドで開発できるフレームワークが普及してきました。まだFlutterは追いついてないようです。
このような中で台頭したのが、SPAに特化しつつ、Viewを、VM(View Model)とViewに分離することで新たな複雑性に対応しようとする、MVVMモデルです。Viewが複雑になり、デザイナーが一人でHTML/CSSを書きつつちょこっとJavaScriptを書いていた時代は過ぎ去りました。MVVMモデルは、Viewをデサイナー(View)とデベロッパー(View Model)で分担して作ることを容易にします。MVVMを実現するフレームワークとして、Angular、Vue、Xamarinなどが台頭しました。さらにMVVMよりもViewの複雑性に対応したのが、"Just the UI"を標榜したReact、さらにView Modelを加えたReact/Reduxであり、React(/Redux)をネイティブアプリ2まで対応できるようにしたのがReact Nativeです。これら（総称してReactと呼びます）が、現時点の渋谷系一番人気のフレームワークになっています。Reactのモデルは、Reactiveモデルと呼ばれます。
このあたりの議論がよく理解できない人は、「Flutterのアーキを図１枚で説明してみる」を参考にしてください。
Flutterは、そのReactにインスパイアされてGoogleが提供したフレームワークであり、Reactiveモデルを採用し、Webからネイティブアプリまでのマルチプラットフォーム対応3のフロントエンド開発フレームワークとなっています。
2. Java開発者が移行しやすいDart2
動的型定義でさくさく書けるJavaScriptは、渋谷系人気の言語です。Angular、Vue、ReactはいずれもJavaScriptを基軸4とするフレームワークであり、渋谷系の人気を博しました。Node.jsとかNode-REDが流行るのもこの流れです。
一方、きっちりとした開発を好む飯田橋系はJavaが大好きで、これらのJavaScript系フレームワークを、実証実験ではなく商用システムとして利用することには抵抗感があります。
Dartは、Dart1ではJavaScript的な動的型定義の言語であったのですが、Flutterとともに出したDart2において、実質的に静的型定義の言語に大幅リニューアルをしました。位置づけ的に「Better Java」（しかしScalaほどは跳躍しない）となり、Javaの古びたところを改善して開発効率を高めたものとして、Java開発者に受け入られやすいものになりました。
3. 安心のGoogleブランド
元来、飯田橋系はオープンソースに対して保守的であり、「保証のないものを使うのはいかがなものか」という文化でした。そうはいっても時代の流れには逆らえずオープンソースを使うわけですが、もとの文化の影響で、強い企業がしっかりとバックアップしているオープンソースを好む傾向にあります。その点で、FlutterはGoogleが強くコミットしており、万全です。
ReactにコミットするFacebookも負けず劣らず強力ではあります。しかし、FacebookはSNSを主事業としているため、同じプラットフォーム技術を長く提供しつづけるインセンティブは相対的に弱いです。実際、過去にCassandraという素晴らしいプロダクトをオープンソースに出しましたが、現時点のFacebookではあまり使われていない模様です。一方、Googleは、以前はプラットフォーム技術に関してはやや閉鎖的な印象があり、外部に最新のノウハウは出さない企業文化でした。しかし、ここ最近は様変わりをして、オープンソースコミュニティと積極連携し、Kubernetesをはじめとした素晴らしいプロダクトを提供しはじめました。GCPを、AWSやAzureに対しての競合として成長させようとしており、先行2社に対して競争力あるポジショニングをとろうとしているためと思われます。
現時点で、コミュニティ全体はReactの方が優勢ですが、FlutterはGoogleが精力的にコミットしているため公式のWidgetやドキュメントが手厚い状況です。渋谷系は自分自身がコミュニティに積極関与するためReactでも問題ありませんが、そこまでではない飯田橋系には「公式が強い」という方が魅力です。オープンソースって何なの？という根源的な問いが生まれてしまう悩ましい話ですが、そうなのです。
4. Reactに乗り遅れたからこそFlutter
2013年からの歴史があるReactは、項1で述べた潮流をつかんだ渋谷系を席巻しました。そのため、渋谷系ではReactの開発者や開発ノウハウがそれなりに蓄積されています。そのため、渋谷系がFlutterに移行するインセンティブはあまり高くありません。
しかし、Reactには無縁であった飯田橋系は事情が違います。これまでの蓄積がありませんので、Flutter or Reactで悩む必要はありません。SPAやネイティブアプリにそろそろ本腰を入れよう、と決断したら、選択肢はFlutterのみになります。むしろ、積極的にFlutterを使うことで、いわゆるリープフロッグ現象（途上国が最新技術により急激に発展する現象）により、一足飛びにフロントエンド開発の競争力がつくことが期待されます。
なお、「SPAやネイティブアプリなんて必要無い！ 5Gになれば高速低遅延になって今までのサーバーサイドレンダリングのWebアプリで十分！ Struts/Spring万歳！」などと考えているとしたら、それはファンタジーですので、「LTE→5Gはブレークスルーにはならない」を読んで考えを改めてください。
5. 若手技術者の雇用問題も解決
飯田橋系にとって深刻な問題は、若手の優秀な技術者の雇用維持です。若手の優秀な技術者は、新卒/中途ともに、渋谷系に流れていってしまっています。技術に自信と実績のある人ほど、今更COBOLの保守開発とか、技術者とは名ばかりの調整役というプロマネとか、やりたくありません。
Flutterに注力することで、そのような問題は解消できます。なにしろ渋谷系の傾倒するReactよりも新しいフレームワークです。最新フレームワークでバリバリと開発できることをアピールすることで、飯田橋系にも優秀な技術者が集まるでしょう。