１．ワクチン接種拡大により景気浮揚へ、新規案件で新規技術採用
（１）欧米の動向
欧米ではワクチン接種が進み景気拡大への動きがでています。日本も2021年後半から2022年にかけてワクチン接種の進展に伴い、欧米に引っ張られる形で景気が浮揚していくと思います。
（２）日本のDX優遇税制によるソフトウェア案件の増加
日本では、令和4年度末を期限としてDX優遇税制があり、その需要が今も出始めています。
当然景気がよくなれば、ソフトウェア業界の案件も増えると思いますし、新規事業という形で新しい技術をつかってスタートするものも増えると思います。
ちなみに、企業がICT対応する補助金もあるのでそれを使った案件も増えると思います。
実際、昨年度それによる仕事も多くありました。
（３）2022年の日本のデジタル関連の法改正
2022年1月より改正電子帳簿保存法が施行されました。２年の猶予期限がありますが、大手企業を中心に対応をしていっているようです。（認定タイムスタンプをつけて検索しやすく管理しないといけない）
こちらについては、少し調べた記事を投稿しています。
2022年4月は個人情報保護法が改正され、cookieを使った行動追跡に関しても扱いが変わりますので、サイトの仕組みや規定の修正が必要になると思います。
2022年度は法改正もあるので、デジタル関連のニーズはそこそこ増えると思います。
２．Webアプリのスクラッチ開発はサーバレスをインフラとしたものが主流になるのでは？
（１）JAMStack構成 + サーバレスでビジネスロジック実現に資源集中
すでに採用している企業も多くいますが、サーバレスを利用したインフラが今後はもっと増えると思います。
フロントエンドは、JAMStack構成でするのが増えていますが、React + Next.js + Vercelでフロントを構築し、Firebase、Fauna、AppSyncでバックエンドのAPIを作るというようにサーバレスで環境を構築するのがより加速していくと思います。
AWSのEC2で環境を作るのすらメンテが必要で大変です。それよりもっと進んで、サーバレスで環境自体を作らずアプリ作成にのみ注力することがこれからもっと広まると思います。
サーバレスはセキュリティを考慮しても採用する理由があると思います。
（２）サーバレスAPIの普及とGraphQL
AppSyncやFaunaでGraphQLを使うようにサーバレス化してくるとバックエンドをゼロから作ることが減るので、データを柔軟にとれるGraphQLの採用が増えると思います。
2022年1月追記：Supabaseも徐々に使われるかもしれないですね。
(2)-2 Blitz.jsが採用するZero-APIが限定的に流行る可能性もある？
React、Next、Prismaをつかった、フロントとバックエンドどちらも兼ね備えたフルスタックフレームワークのBlitz.jsはZero-APIを一つの特徴にしており、これが流行るとGraphQLはTypescriptでの開発では使われないのかもしれない。
これはBlitz.jsのようなフルスタックフレームワークの流行次第かもしれない。
仕組みとして、ビルド時にバックエンドへのリクエストをツールが入れてくれるので、プログラマーは意識する必要がなく、ローカルでDBを操作する感覚でコーディングができる。
但し、これはフロントとバックをTypescriptなど
同一の環境で作った場合であり、外部のAPIへのアクセスについてはこの限りではないと思います。
（３）GUI開発はやはりReactが強い
日本ではVueの採用がそこそこありますが、世界的にはやはりReactの利用が多いです。npm trendsのダウンロード数をみても一目瞭然です。
Reactを使っている有名サービスは多いです。Facebookは当然として、Netflix、Dropboxを始め数え上げたらきりがないぐらい。
Netfilxは2021年時点では、React、GrapQL、Typescriptを使える人材を探していますね。
（３）- 2：Reactのデプロイ先はVercelが人気？
ReactのデプロイはやはりVercelが手軽で、あわせて、Vercelが開発をしているNext.jsを使うのが多いと思います。
React + Next.js + Vercelというのが唯一ではないですが、有力な構成候補だと思います。
（４）スクラッチ開発の呼吸、壱の型「サーバレス」、ビジネスロジックに全集中
サーバレスを利用することで、インフラ構築・運用のコストを下げ、その分、ビジネスロジックを実現するアプリ開発に資源を集中し、より多くの機能をより早くリリースしていくことがこれから一般化すると思います。
アジャイル開発をする上でも、できるだけ小さくリリースできるサーバレス構成はマッチングしていると思います。
（５）スクラッチ開発はSaaSなどサービス開発での採用が主流に
現在、スクラッチ開発は特定の企業のシステム開発にも使われていますが、特定企業のシステム開発は、次章で取り上げるノーコード・ローコード開発が主流になると予想します。
ですのでスクラッチ開発は、サービス自体をつくることに使われるのが一般化すると思います。
そのとき、多数のリクエストをさばいたりすることが予想され、昨今人気のある並列処理が得意な、Go、Elixir、Scalaなどが採用されることが増えると思います。
ちなみ最近、新興ベンチャー企業を中心にGoやScalaの採用が多く、ScalaはJavaの資産を使えるという意味もあって採用が増えています。KotlinもAndroid開発だけにとどまらずWebのバックエンド開発にも利用されることがあります。
フロントエンドは引き続きJavascript、特にTypescriptがメインで使われると思います。ランタイムについては、Denoが注目を浴びてますが、Node.jsのエコシステムが大きいのでまだまだDenoの採用は2021年にはそこまで普及しないと思います。2022年の後半ぐらいにそういった話も聞くかもしれませんね。
Flutterも一応注目を浴びてますが、Webに関してはFlutter2.0でもまだ動作が怪しそうですね。Webの動作が遅すぎて、Webについては使い物にならないなと思いました。Flutterで使われているDartも必然的に、Flutterに限定された使い方しか今の所多くはみられないので、やはりフロント開発はTypescript + Reactというのが主流のままかと思います。
ただ、Fuchsiaが本格的にマーケットにだされてくるので、Flutterもそれに伴って今後伸びるかもしれないですね。
フロントエンドのビルドツールは、Webpackの遅さからesbuildを採用しているSnowpackやViteが注目されています。まだまだnpm trendsでのインストール数はWebpackに遠く及びませんが、来年あたりには採用が増えているかもしれません。Webpackが爆速になっていなければ。
バンドルツールは、2021年7月時点では、Viteが伸びてます。（Webpackはこれら以上のDL数なので比較から外しました。）
（６）サーバレスの台頭でRailsやLaravelなどフルスタックWebフレームワークの必要性が低下
RailsやLaravelのようなフルスタックなWebフレームワークは、JAMStack構成にあっては、Viewの処理など不要な部分も多く、JSONを返すAPI開発にのみ使われるようになってきています。
ただ、API開発は前述した通り、Fauna、Firebaseを使えばフルスクラッチでつくる必要はなく、クエリだけをつくればよいようになります。
それだけRails、Laravelの必要性は低下するでしょう。
おそらく、Rails、Laravelでつくっていたようなものなら、ノーコード・ローコード開発をした方がメリットが高くなると予想します。
（７）円高によるコスト増やサービス過多によるAWS疲れによりHerokuやRender.comなどのインフラがより採用されるかも？
Salesforceが保有するHerokuは駆け出しエンジニアがポートフォリオをアップしたりするのによく利用されているので知名度は高いと思います。また、似たようなサービスとしてRender.comもあります。
これらのサービスは、EC2/ECS、VPS、レンタルサーバとは違って、サーバ機能をホスティングさせてくれるけれど、DBや実行環境に応じた手軽なデプロイや管理の機能を提供しています。
こうしたAWSほど細かい設定はできないけれど、比較的小規模な場合に必要な機能が手軽に使えるインフラが今後は徐々に採用がふえると思います。金額も時間性での課金である程度プランごとに費用の目安があるので予算は立てやすいかと思います。
Vercelはこれらより更に特定のライブラリに特化したインフラであり、こうしたAWSやGCPよりやることを限定しつつも、楽にデプロイできるインフラが増えていくし、価格競争も始まりより使いやすくなる気がします。
３．ノーコード・ローコード開発 (App Builderによる開発）の普及
（１）米国を中心にサービス・ツールが群雄割拠
スクラッチ開発はサーバレスを利用したとしてやはりそれなりの学習コストと工数がかかります。最近は、Webの技術を利用したノーコード・ローコードのサービスやツールもでてきました。
有名なものであれば、Bubble、OutSystems、PowerAppsがありますね。
OutSystemsは米国のサイトをみると最低価格が数十万円するので大手企業向きですが、日本でも大手自動車メーカーが採用をしており、じわじわ普及しています。
Excelなどを絡めたものならMicrosoftのPowerAppsでスマホ、Webのアプリをつくるという方法もありますね。
スマホアプリ開発では、BuilderX、AppGuyberなどもでていますね。
現在、北米を中心にノーコード・ローコードのSaaSやツールが多くでています。これから主流になっていく予感がします。
MSと同様米国のビックテックもノーコード・ローコードのサービスを出していますね。GoogleはAppSheet、AmazonはHoneyCode。
（１）－２：AWS Aplify Studioによるローコード開発が徐々に増えるかも？
2021年12月にAWSからAmplify Studioの発表がありました。これは、UIデザインツールのFigmaで作った画面がReactのアプリになるというもので、AppBuilderとして位置づけられると思います。
AWS + Figma + Reactという有力な組み合わせなので、徐々に2022年に流行っていく気もします。
（２）ノーコード・ローコードに特化した案件も増加
海外ではノーコード・ローコードに絞った開発案件がありますし、日本でもOutsystemsの案件が徐々に増えています。
（３）ノーコード・ローコード開発SaaSはリモート開発に適している
ノーコード・ローコード開発ツールの多くはSaaSのものが多く、この場合リモート開発も可能になります。
スクラッチ開発の場合、環境構築などをする手間がありますが、ノーコード・ローコード開発SaaSの場合、その手間は有りません。
また、技術が属人化している部分も比較的少なく教育、仕様共有がしやすくこの点もリモート開発に向いています。
大手企業の案件でもノーコード・ローコード開発SaaSを利用してリモート案件をしているところもあります。
（４）早く形になり小さくリリースできるのでアジャイル開発向き
ノーコード・ローコード開発は、すでに動作プラットフォームができており、小さい機能をリリースするというのがスタート地点からしやすくなっています。
アジャイル開発は、小さく工程を区切ってリリースしていくことが一般的ですが、ローコード・ノーコード技術はこれに適しています。
開発工数自体を下げるのもさることながら、アジャイル開発に適しており、プロジェクト進行の上でもとても最適な手法であると思います。
（５）技術が属人化しにくく、教育コストが低い→人材採用の間口が広がる
ノーコード・ローコード開発は作り方が汎用化している部分が多く、スクラッチ開発のような属人化した部分が少なくなります。それは学習・教育コストの低下を実現するとともに、ひいては、採用人材の間口が広がります。
また、属人化を回避するということは人材の流動化に対応しやすいともいえます。
（６）開発効率を上げて費用抑制、納期短縮、機能多産
これまでみてきたように、ノーコード・ローコード開発は開発過程を効率化することができます。
そうしたことを背景に、すでに日本国内でも事例は多くありますが、費用・工期を短縮している事例は多くあります。
今後、新規事業の立ち上げに際しては、こうした効率的な手法が採用されるのは当然な流れかと思います。
スクラッチ開発と同じ予算でも、短い工数で実現できるため、その分より多くの機能実現もできます。
AI、ロボット、IoTとの連携など浮いた工数でより先進的な技術を取り込んだ機能実現ができるのもノーコード・ローコード開発の利点だと思います。
（７）ノーコード・ローコード開発技術を支えるWeb開発技術
ノーコード・ローコード開発は、近年始まったものではなく昔から存在していましたが、実際使い勝手がよくなく採用されることはすくなかったように思います。
それを変えてきたのが、JavascriptをベースにしたWeb開発技術の進展であると思います。
なかでも、npmのパッケージエコシステムによりフルスクラッチすることがなくなり生産効率が上がっています。
Webの技術はブラウザがOSの差違を取り除き、誰でもが使いやすいものになっています。また、インターネットを使ったビジネスが一般化しているため、Web開発に関する人材も多く、技術進展も早いです。
こうした技術的な進展をベースに、ノーコード・ローコード開発ツールの進化もめざましいものがあります。それ以外の設計手法などにも進化があり、それもツールの開発速度をあげているのかもしれません。
（８）ノーコード・ローコード開発ビジネスの増加
冒頭に話した通り、ノーコード・ローコード開発のSaaSは多くなっており、資金調達の情報もあり、今後ますます活気づいていくことが予想されます。
それによって開発のスタイルもスクラッチ開発だけでなく、ノーコード・ローコード開発が多くなるように思います。
（９）政府系の短納期対応でノーコード・ローコード採用が増えるかも？
政府系の補助金申請やワクチン接種に関するWebサイトのトラブルがニュースになることがあります。
問題の一因には短納期で設計、テスト、製造がままならないというのがあると思います。
これへの対応策として、ノーコード・ローコード開発があると思います。
少なくとも内部設計やインフラ構築などの工数は削減できますので、顧客と外部設計をする時間を多くし、形を見せながら開発を進めていき、テストをしっかりすることができると思います。
こうしたノーコード・ローコード開発は自治体系のシステム開発にもこれから多く導入されると思います。
フルスクラッチ開発では土台、短納期で炎上は必至です。もちろん、ノーコード・ローコードでも短すぎれば同様に炎上しますが、スクラッチ開発よりは短くなると思います。
繰り返しになりますが設計やテストはノーコード・ローコードでもしっかりする必要があります。
これからは、スクラッチ技術よりスクールでは設計やテストを教えて方がいいのではないかと思いますね。
４．JSやCSSでカスタマイズしやすいSaaSでシステム構築
ノーコード・ローコードよりさらに工数を下げて開発できるのがSaaSのカスタマイズです。
ECサイトではShopifyやBaseなどがカスタマイズしやすく、こうしたカスタマイズしやすいSaaSがプラットフォームとして使われることも増えると思います。
５．サーバレス、ノーコード・ローコード開発で気をつけること
スクラッチ開発ではサーバレスがより広まると思います。また、スクラッチ開発は、特定の企業のシステムをつくるよりは、SaaS自体の開発に採用されるのが主流になると思います。
一方で、特定企業のシステム開発ではノーコード、ローコード開発の採用が増えていくと思います。
サーバレス、ノーコード・ローコード開発は一見、良い点ばかりにも見えますが、落とし穴もありそうなので、その点は留意が必要かと思います。
（１）ネットワークトラフィックの増大とシステム巨大化によるサービスの障害発生
近年、動画サービスやリモートワークの普及によりネットワークのトラフィックは増えていっています。
当然、ネットワークが不安定化してトラブルが発生することも予想されます。また、Googleなど大手サービスでの障害も増えており、システムが巨大巨大化すればそれだけ障害のリスクも増えます。
クラウドサービスは便利な反面、稼働があがればそれだけ不安定化するリスクもあります。中央集権的なサービスにはしょうがないことであると思います。
とはいえ可用性を考えた場合、できるだけどんな状況でも利用できることが求められます。
（２）オフライン・オンプレミスでも利用できるサービスで可用性を担保
ネットワークやクラウドのサービスが止まったから仕事ができませんでは、システムとしては不完全だと思います。
クラウドでもローカルでもできるハイブリッドなサービスを選ぶことが可用性を考える上では必要かと思います。
最近では、クラウドだけでなくオンプレミスへの設置もすることができるものもあります。ローカルアプリでの対応、オンプレミスでの対応もできるハイブリッドなサービスが採用されていくと思います。
また他の対応としては、ライブラリはOSSで、ホスティングをサービス化するという構成が考えられます。
この場合、万が一サービスが止まっても、OSSで独自に環境構築して一時的に対応をするということもできると思います。
そういったOSS+SaaSというサービスも今後ふえてくるかもしれません。Wordpress.com(.org）のサービスはホスティングでお金をとっている形に近いですね。
ちなみに、独自でつくった環境を一時的にするのはメンテナンスの効率化のためです。
（３）データ形式はテキストベース、かつ、標準化したものでバックアップ
SaaSやツールの移り変わりは早く、いつか今のサービスから移行するときが来ます。
それを見越した場合、データが特定のサービスやツールにしか存在しない、または、それでないと読み込めないのではポータビリティに欠けます。
データは、CSV、XML、YAML、TOML、JSON、Markdownなどテキストベースで標準化して保存、書き出しできるものがよいと思います。
移行だけでなく機能拡張をする際に、他のサービスを利用するときにもメリットがあります。
（４）移行も視野にソフトウェアのDNAである外部設計・仕様を整理
サーバレス、ノーコード・ローコード開発はプログラマー視点の内部設計の部分が簡素になります。ただし、ビジネスロジックに該当するユーザー視点の外部設計は引き続き重要な位置を占めます。
むしろ、内部設計やそれに伴う基盤的な製造の工数が減るため、より外部設計・ビジネスロジックの設計に資源を振り向けることができます。
また、サービスやツールが変わろうと、外部設計は引き継いで行かれるものであると思います。つまり、外部設計・仕様はソフトウェアの心臓、DNAともいうべきところです。
工数削減をした分、ここの工数をあげてインフラやツールが変われど移行しやすいような対応をしておくべきだと思います。
（５）製造工数は下がれど設計・テスト工数はきっちりと確保
コーディングなどの製造工数は下がりますが、設計やテストが全面的に不要になるわけではありません。
ともすれば、スクラッチ開発では製造の工数しか見積もりに入っておらず、設計やテストの工数が少なくなることがあります。
製造の負担が楽になった分、設計やテストをしっかりする必要があると思います。また、サーバレス、ノーコード・ローコードならではの設計、テスト手法もでてくると思います。
設計やテストは引き続き存在しつづけますので、こちらのスキルのアップデートと見直しも必要かと思います。
６．AI需要の増加、AIとノーコード・ローコードの不可分の関係
AIの投資はここ近年かなり増加してきています。米国の調査では、2019年に約4兆円であった投資額が、2023年には倍近い10兆円になると予想されています。
海外のAI関連エンジニアの年収は1,000万円ぐらいあります。
最近、日本でも行政や大企業をはじめデータ分析を用いて政策決定、マーケティングなどを行うところがあり、それに関する人材募集も増えています。私もそうした打ち合わせに参加することが多くなってきました。AIを用いた自動運転などのニュースもよくみます。
AIやビッグデータ解析は特定の分野に限らず、今後、様々な分野で利用されていくと思います。そうしたとき、スクラッチ開発をしていたのでは到底工数が足りません。
Webやデスクトップアプリの開発は、DBや通知を操作するUIをつくているに過ぎませんが、それすら工数がかかりすぎています。AI、ロボット、IoTとの連携などがこれからもっと求められます。
そうしたときどうしても、工数削減は必要になり、ノーコード・ローコードというのは使わざるを得なくなると思います。
ちなみに、米国などのプログラム言語別求人ランキングなどをみると「SQL」が入っていることが多いですが、これはデータ分析をする上で必要なためで、それが上位に来ているということはそれだけニーズがあるということだと思います。
AI、データ分析の分野でつかわれるプログラム言語といえば、Python、Rがよく使われますが、最近では並列化もしやすく、高速だといわれているJuliaが注目されており、今後、伸びていくと思われます。
また、AIやデータ解析の分野では可視化などもふくめてツールを使うのが一般的で、多くのツールがあります。私が日本でよく聞くのは、MATLAB、SAS、SPSSなどがあげられます。
BIツールとしては、Tableau、PowerBIなどをつかう日本企業は多いと思います。
この分野のクラウドサービスとしては、やはりGoogle Cloud Platformの機能を使うのが一番人気があると思います。画像認識や音声認識などを使うにも、性能が高く、比較的コストも低めだと思います。
７．さいごに
景気が落ち込みましたが、それは一方で新しい案件、技術採用の予兆でもあります。
アメリカの投資動向をみると今後の技術普及のあり方がだいたい予想できると思います。その投資の理由も荒唐無稽ではなく、効率性などに基づいたものであり、受け入れられるには妥当性があります。
今後、効率的な技術を採用する企業が競争力を手に入れるとともに、できるだけ定時上がり、リモートワークができるホワイトな職場環境をつくりだせるように思います。
逆に非効率な開発手法をとっている企業はブラックにならざるをえず、やがて競争にまけてしまうでしょう。
企業経営者もさることながら、エンジニアの人もどんな技術を採用するとどのような仕事をするのかを考えて就職活動をするのがよいと思います。
８．おまけ：ツールや将来の方向性への備考
（１）Notionのグループウェア化、マネージメントツール化
昨今、メモSaaSのNotionが人気がありますが、Notionは単なるメモというより、情報にフォーマットをあてやすいことが売りだと思っています。
それを利用してタスク管理をする事例も多く、グループウェアとして使う方法が広まっています。NotionAPIもつかえるようになり、Notionを管理ツールとして採用する企業が増えそうですね。
（２）Anvil：ローコード開発SaaS：Gitでバージョン管理、ローカルデプロイ、Pythonで開発
ノーコード、ローコード開発SaaSは色々ありますが、開発者としてバージョン管理したいとか、障害があったときにどうするのかということを考えると、Anvilというサービスはおすすめです。
ドラッグ&ドロップで画面をつくるAppBuilderとしての機能はもとより、ソースがGitで管理されています。
さらに、GitのリポジトリをローカルにCloneしてローカルで動かすこともできます。
個人的におすすめのサービスです。
コードはPythonで書きますがコード補完もそこそこ動くので結構いいと思います。
Javascript、CSS、HTMLのカスタマイズも当然できますし、いいなと思います。
（３）Webフロントエンドのライブラリ競争はAppBuilderの確立で収束へ
現在、Reactが人気がありますが、VisualStudioやXCodeのようにAppBuilderを通してWebのGUIをつくることが一般化すれば、どんなライブラリを使っているかを意識する必要はなくなると思います。
そもそもGUIをコードだけでつくるという発想自体が過渡的なもので、それはAppBuilder自体をつくる人たちだけの関心事になっていくと思います。
今後どんなAppBuilderがデファクトスタンダードになるかはわかりませんが、有名なツール・サービスが確立した段階でフロントエンドライブラリという関心すらなくなると思いますし、作り方もまた変わると思います。
個人的には、Figma、AdobeXDのようなデザインツールをベースにそこにアクションやデータ更新をつけられるようになるという方向性もあるのだろうと思っています。（それらしいことは今でもできますが、まだまだメンテしやすいものではないと思います）
デザイナーからプログラマーへというワークフローが、デザインツールをベースにしたAppBuilderで実現する日も遠くないかもしれません。
Reactはコーディングする上では、JSXやStyled-componentによりプログラマーからすればJS/TSという同一のコンテキスト（ファイル形式）で管理できるのでストレスが少ないのは確かです。
ただ、それはコーディングする上でのメリットであって、GUIベースで開発する際にはそのようなことすら意識する必要はなくなります。
GUIエディタでコンポーネントを配置し、そこに必要に応じてコードを書く。視覚要素を記述するタグのような要素は不要になります。
AppBuilderの動向はとても重要だと思っています。
ReactでGUIをつかって作れるBuilderの参考記事。
※ 2021.5.27：コメントでご指摘を頂いたのですが、すべてGUIでつくるというより視覚的な要素がベースにあって適宜コーディングできるツールをAppBuilderとしてイメージしています。
（４）多くの個人がオンラインでOSを保持する時代。SaaS運営の中央集権構成から分散構成へ。
現在、SaaSの多くは中央集権的な構成でつくられています。AWSなどの仮想インフラなどを利用しているとトラフィックに応じてコストが上がりますし、システムの不安定化も考えられます。
SaaSは無料でユーザーを増やすという営業戦略をとることがありますが、中央集権的なシステムであると当然、売上もないのに費用だけかかることになります。
これは米国のような投資環境がないとなかなか難しい戦略だと思います。
これへの対策としては、個人ごとにインフラ環境を契約してもらい、そこにWebアプリをインストールするという構成も考えられます。
AppStoreのWebアプリ版ですね。こうすることで、サービス運営者はインフラコストから開放されます。
これは今でもできますが、流石に、個々人にレンタルサーバやAWSを契約してくれとはいいにくいと思います。
レンタルサーバやAWS内で、個人ごとにオンライン上のOS/PCリソースをもつというサービスが普及し、そこにWebアプリをインストールするという発想が普及してくれば、Web版AppStoreもできると思います。
個人がオンラインにもOS/PC、ストレージを持つ時代がきて、そこにWebアプリをインストールするようになれば、分散化したSaaSの運用も可能になると思います。
これはいろいろな環境条件をクリアしないといけないので、実現性は微妙ですが、可能性としては考えられると思います。
ただ、AWSなどの業者も個人がOSをサービス上でもってくれてお金が入るなら、今よりもユーザーを増やすことになるので、そうしたサービスを始める理由はあると思います。
SaaSインフラの分散化というのも今後でてくるかもしれないと思っています。
※ 追記：コメントにある、「AWS Maketplace」はイメージに近いです。
2022年1月追加：Web3.0の定義の中に、中央集権型サービスから分散型へという内容があります。今後、ますます分散型は現実味を帯びてくるかもしれません。