崩壊する神話と、新たな「組み合わせ」の夜明け
「また、APIの繋ぎこみでエラーか……。」
海外のオフィス、少し冷房が効きすぎた部屋で、僕はC#のコードを前にため息をつくことがあります。WPFでリッチなクライアントを作っているはずが、裏側のマイクロサービスの迷宮に迷い込み、本来の「価値ある機能」を作る時間の倍以上の時間を、依存関係の解決や、サービスの発見（Discovery）に費やしている。そんな経験、ありませんか？
こんにちは。海外でITエンジニアとして働いている者です。普段はC#やWPFをメインに、デスクトップアプリからバックエンドの連携まで設計開発を行っています。
今日は、僕たちエンジニアが直面している「アーキテクチャの限界」と、その先にある**「コンポーザブル・アーキテクチャ（Composable Architecture）」**という、2030年に向けた新しい設計図について話をさせてください。これは単なる流行りのバズワードじゃありません。これからの10年、僕たちが海外の荒波の中でエンジニアとして生き残るための、文字通り「生存戦略」になる話です。
◆ マイクロサービスという「夢」の続き
少し時計の針を戻しましょう。僕たちがモノリシック（一枚岩）な巨大システムに絶望し、「マイクロサービス」という救世主飛びついたのは、もう何年も前のことですよね。
「機能ごとに小さく分割すれば、開発は速くなり、デプロイも自由になる！」
そう信じていました。確かに、それは間違いではありませんでした。しかし、現実はどうでしょう？
僕が海外の現場で目の当たりにしているのは、**「分散されたモノリス（Distributed Monolith）」**と呼ばれる悲劇です。サービスは分割されたけれど、それぞれの結合度が強すぎて、結局ひとつの修正が全体に波及する。あるいは、あまりにも細かく分割されすぎて、どのサービスがどこにあり、何をしているのか誰も把握できていない「サービスの迷子」状態。
WPFでUIコンポーネントを作るときを思い出してください。ボタン一つ、リスト一つを再利用可能な UserControl にしますよね？ でも、そのコントロールが特定の親ウィンドウのViewModelにガチガチに依存していたらどうなりますか？ それはもう「再利用可能」とは言えません。ただ「別ファイルに書いただけ」です。
今、多くのバックエンドシステムで起きているのは、これと同じことです。
◆ 2030年のブループリント：コンポーザブル・アーキテクチャとは？
そこで登場するのが、「コンポーザブル・アーキテクチャ」です。
ガートナーなどの調査会社が提唱し、エンタープライズの世界で急速に注目を集めているこの概念。一言で言えば、ビジネスを構成する要素を**「発見可能で、再利用可能で、独立してデプロイ可能な『ビジネス機能（Business Capabilities）』」**へとシフトさせる考え方です。
ここで重要なのは、「技術的な関数」ではなく「ビジネス機能」であるという点です。
例えば、「在庫確認」という機能があったとします。
従来の考え方だと、「データベースから Inventory テーブルをSelectするAPI」を作りがちでした。
しかし、コンポーザブルの文脈では、「在庫を確認し、引当可能かを判断し、必要なら発注トリガーを引く」という、**それ単体でビジネス価値が完結するブロック（PBC: Packaged Business Capabilities）**として定義します。
これをレゴブロックのように捉えてください。
これまでの僕たちは、レゴブロックを作るためのプラスチックの原料（コード）や、金型（インフラ）にこだわっていました。でも、ビジネスサイドが求めているのは、「お城を作りたいなら、城壁ブロックと塔ブロックを持ってきて組み合わせる」というスピード感です。
コンポーザブル・アーキテクチャは、システムを**「構成可能（Composable）な部品の集合体」**として再定義します。
- Discoverable（発見可能であること）：作った機能がどこにあるか、カタログ化されていて、チームの誰もがすぐに使える状態にあること。「あの機能、あの人が作ったリポジトリの奥底にあるよ」ではダメなんです。
- Reusable（再利用可能であること）：特定の文脈（コンテキスト）に依存せず、別のプロジェクトや別の画面でも、プラグを挿すだけで動くこと。WPFで言うなら、どんな DataContext が来ても動くように設計された、疎結合なカスタムコントロールのようなものです。
- Independently Deployable（独立してデプロイ可能であること）：これこそが肝です。ある機能ブロックを更新しても、システム全体を止める必要がない。他のブロックに影響を与えない。
◆ なぜ今、「2030年」なのか？
「また新しい用語かよ、エンジニアを疲れさせるなよ」
そう思う気持ち、痛いほどわかります。僕も最初はそう思いました。ですが、このシフトは不可逆です。なぜなら、ビジネスの変化のスピードが、もはや人間のコーディング速度を超えようとしているからです。
2030年に向けて、AIによるコード生成や、ローコード/ノーコードツールがさらに普及します。その時、僕たちプロのエンジニアに求められるのは、「ゼロからコードを書く力」以上に、**「高品質なブロックを設計し、それを適切にオーケストレーション（指揮・統合）する力」**になります。
海外のテック企業では、すでにこの動きが加速しています。「車輪の再発明」は徹底的に嫌われます。「認証機能？ Auth0を使え」「決済？ Stripeだ」「検索？ Algoliaだ」。これらはすべて、コンポーザブルな部品です。これらを組み合わせ、自分たちのコアとなる「独自のビジネスロジック」だけを、これまた再利用可能なブロックとして作り込む。
これが、2030年のエンジニアの「設計図（Blueprint）」です。
C#使いの僕たちにとって、これはチャンスでもあります。C#は元々、コンポーネント指向が強い言語です。インターフェース、DI（依存性注入）、ジェネリクス。これらの武器は、コンポーザブルな世界を作るためにあるようなものです。WPFでMVVMパターンを使って、ViewとLogicを綺麗に切り分けてきたあの感覚。あれを、システム全体、企業全体のアーキテクチャに適用する時が来たのです。
◆ 変化への序章
この「起」のパートで僕が伝えたいのは、**「今の延長線上に未来はない」という危機感と、「パズルを解くような面白さが待っている」**という期待感です。
スパゲッティコードと格闘する日々から、洗練されたブロックを組み合わせ、驚くべきスピードで価値を生み出す日々へ。コンポーザブル・アーキテクチャは、マイクロサービスの失敗から学び、その理想を現実的な形へと昇華させたものです。
「でも、具体的にどうやって？ マイクロサービスと何が違うの？」
その疑問こそが、次のステップへの鍵です。
次回の「承」では、このアーキテクチャがどのようにマイクロサービスの弱点を克服し、文脈（Context）と目的（Purpose）に焦点を当てることで、システムを劇的にシンプルにするのか。技術的な深掘りをしていきましょう。
僕たちが海外で生き残るため、そしてエンジニアとして楽しみ続けるための旅は、まだ始まったばかりです。
マイクロサービスの亡霊を乗り越えて：文脈と目的の再発見
前回の記事で、僕は「分散されたモノリス」という、今のシステム開発現場にはびこる病について触れました。今回は、そこから一歩踏み込んで、なぜ僕たちが愛したマイクロサービスが「亡霊」のように僕たちを苦しめるのか、そしてコンポーザブル・アーキテクチャがどうやってその呪いを解くのか、という話をします。
正直、ここからの話が一番「設計脳」を使うところです。コーヒーでも飲みながら、リラックスして読んでください。
◆ 「小さければいい」という勘違い
C#でクラス設計をするとき、「単一責任の原則（SRP）」を意識しますよね？ クラスは変更する理由が一つであるべきだ、と。
マイクロサービスの初期、僕たちはこの原則をそのままアーキテクチャ全体に適用しようとしました。「ユーザーサービス」「商品サービス」「注文サービス」……と、名詞単位でデータベースごと分割していったんです。
でも、これが落とし穴でした。
実体験を話しましょう。あるEコマースプロジェクトでのことです。
「ユーザーの購入履歴を表示する」という単純な画面（WPFのDataGridで表示するようなやつです）を作るのに、フロントエンド側で5回も6回も別のAPIを叩く必要がありました。
ユーザー情報の取得、商品名の解決、価格の現在値の確認、在庫ステータス……。
それぞれのマイクロサービスは「純粋」で「小さい」状態でした。でも、それらを繋ぎ合わせる「文脈（Context）」がどこにもなかったんです。結果、フロントエンド（WPFアプリ）の中に、本来バックエンドにあるべき複雑なビジネスロジック（データの結合ロジック）が大量に漏れ出してきました。ViewModelが肥大化し、修正のたびにAPIチームと「どっちが直すんだ」と揉める日々。
マイクロサービスの弱点は、「技術的な分割」を優先しすぎて、「ビジネスの文脈」を見失いやすいことにあります。
◆ Packaged Business Capabilities (PBCs) という「解」
コンポーザブル・アーキテクチャは、ここでPBCs (Packaged Business Capabilities) という概念を持ち込みます。直訳すると「パッケージ化されたビジネス能力」。
これはマイクロサービスと似ていますが、決定的な違いがあります。それは、**「目的（Purpose）」**が含まれているかどうかです。
- マイクロサービス（従来の粒度）：
GET /users/{id}- これは「データ」へのアクセスです。何のために使うかは呼び出し元次第。
- PBC（コンポーザブルな粒度）：
OnboardNewEmployee（新入社員オンボーディング）- これは「ビジネスの目的」そのものです。この中には、ユーザー作成、メールアドレス発行、権限付与、初期研修の割り当てといった、複数のマイクロサービス的な処理が内包されています。
C#のコードで例えるなら、プロパティのGetter/Setterだけが羅列された貧血気味のクラス（Anemic Domain Model）と、しっかりと振る舞い（メソッド）を持ったドメインモデルの違い、と言えば伝わるでしょうか。
コンポーザブル・アーキテクチャでは、極端に小さなマイクロサービスを作るのではなく、**「ビジネスとして意味のある単位」**で機能をカプセル化します。これにより、利用する側（僕たちアプリ開発者）は、中の複雑な配線を知る必要がなくなります。
◆ 文脈（Context）が境界を決める
ここで「ドメイン駆動設計（DDD）」の知識が活きてきます。
コンポーザブル・アーキテクチャがマイクロサービスの強みを引き継ぎつつ、弱点を克服できるのは、**「境界づけられたコンテキスト（Bounded Context）」**を徹底的に意識するからです。
海外の現場でよく議論になるのが、「Customer（顧客）」の定義です。
配送チームにとっての「Customer」は「住所と電話番号を持つ人」です。
マーケティングチームにとっての「Customer」は「購買履歴と嗜好性を持つ人」です。
これを一つの「Customer Microservice」に押し込めようとすると、巨大な泥団子ができます。
コンポーザブルなアプローチでは、これらを別のPBCとして定義します。「配送機能PBC」と「マーケティングキャンペーンPBC」。それぞれが独自のデータスキーマを持ち、独立しています。
これらが疎結合であるおかげで、例えば「配送パートナーをDHLからFedExに変えたい」と思った時、マーケティング側のシステムには1ミリも影響を与えずに、配送機能ブロックをごっそり入れ替えることができるのです。
◆ 技術的な依存から、機能的な契約へ
WPFをやっている人なら、「Interface」の重要性は骨身に沁みているはずです。
ILogger をDI（依存性注入）しておけば、裏側がファイル出力だろうが、クラウドのログ基盤だろうが、アプリのコードは変わりません。
コンポーザブル・アーキテクチャは、これを企業システム全体のスケールでやろうとしています。
各PBCは、APIスキーマやイベント定義という「契約（Contract）」だけを公開します。中身が.NET 8で書かれていようが、Go言語だろうが、あるいはSaaS（SalesforceやSAPなど）だろうが、関係ありません。
従来のマイクロサービスは、REST APIという通信プロトコルで疎結合にはなりましたが、**「データ構造」で密結合になりがちでした。
対してコンポーザブル・アーキテクチャは、「ビジネスイベント」と「高粒度な機能」**で繋がります。
「注文が確定した」というイベントが飛べば、「請求PBC」と「配送PBC」が勝手に動き出す。お互いの存在を知る必要はありません。
これが、「コンポーザブル（構成可能）」と呼ばれる所以です。オーケストレーター（指揮者）がイベントを制御することで、ブロックの組み換えが驚くほど容易になります。
◆ 設計者へのシフト：コードを書かない勇気
さて、ここまで読んで「なるほど、粒度を大きくして、文脈を大事にするのか」と理解してもらえたなら、一つ残酷な（でもワクワクする）事実を伝えなければなりません。
このアーキテクチャが進むと、僕たちが「ゼロからガリガリとロジックを書く量」は減っていきます。
以前なら、認証機能を自前のDBとJWTトークンで実装していたかもしれません。でも、コンポーザブルな世界では、「認証PBC（Auth0など）」を持ってきて、設定（Configuration）を行い、自分のアプリとコネクトする。これが開発になります。
「それじゃあエンジニアじゃなくて、ただの設定屋さんじゃないか！」
そう思うかもしれません。僕も最初はそう思って焦りました。
でも、違うんです。
ここで求められるのは、「何を作るか（What）」ではなく、「どう組み合わせるか（How）」を設計する高度なスキルです。
ブロックの中身を作るエンジニアと、ブロックを組み合わせて城を作るアーキテクト。この境界線がより明確になり、僕たちアプリケーションエンジニアは後者、つまり「ビジネス価値の直結する組み合わせ」を考える役割にシフトしていくことになります。
マイクロサービスの亡霊は、「細かすぎる管理コスト」と「見えない依存関係」でした。
コンポーザブル・アーキテクチャは、**「適切な抽象度」と「明確なビジネス目的」**という光を当てることで、その亡霊を追い払い、システムを人間が扱えるサイズ感に取り戻そうとしているのです。
この「承」のパートでは、概念的な「なぜ」と「どう違うのか」に焦点を当てました。
しかし、皆さんが一番知りたいのは、「じゃあ実際にどうやって開発が変わるの？」「プラグ＆プレイって本当にできるの？」という具体的な未来図ですよね。
次回の「転」では、いよいよこのアーキテクチャがもたらす**「プラグ＆プレイ開発」の衝撃**と、それによって加速するイノベーションの形について、かなり突っ込んだ話をします。APIファースト、ヘッドレスといった技術キーワードも飛び出しますので、お楽しみに。
プラグ＆プレイの衝撃：開発者という職能の再定義
起と承で、コンポーザブル・アーキテクチャの理論はなんとなく分かった。「ビジネス機能をブロックみたいに扱う」ってことね、と。
でも、皆さんが本当に知りたいのは、「で、俺たちの仕事はどう変わるの？」ってことですよね。
正直に言います。この変化は、USBメモリをPCに挿すような感覚で語られますが、現場で起きることはもっと劇的です。それは**「開発」という行為そのものの再定義**です。
◆ 真の「プラグ＆プレイ」は、コードを書かない
C#エンジニアの皆さん、NuGetでパッケージをインストールすることを「プラグ＆プレイ」だと思っていませんか？ Install-Package Newtonsoft.Json と打って、コード内で JsonConvert.SerializeObject を呼び出す。
これはまだ「コーディング」です。依存関係はコードの中に焼き付けられています。
コンポーザブルな世界での「プラグ＆プレイ」は次元が違います。
ある日、マーケティング担当が僕のデスクに来てこう言います。
「検索機能、今のやつ精度悪いから、来週からAI搭載の『Algolia』に変えるね。契約しといたから。」
従来なら「は？ ふざけんな」案件です。DBのインデックス張り直し、APIの書き換え、WPF側のモデル修正……最低でも1ヶ月は欲しい。
しかし、コンポーザブル・アーキテクチャが完成している現場では、こう答えることになります。
「OK。じゃあ、検索PBC（Packaged Business Capability）の接続先を切り替えておくよ」
設定ファイル（あるいは管理コンソール）で、検索プロバイダの向き先を変更する。インターフェース（契約）は統一されているので、WPFアプリ側は一切の修正なしに、突然「AI検索」の能力を手に入れます。
これが、2030年のブループリントが描く**「真のプラグ＆プレイ」**です。
機能を「開発」するのではなく、市場にある最高クラスの機能を「調達」して「接続」する。僕たちの仕事は、ハンダごてを持って基板を作ることから、HDMIケーブルで最強のモニターと最強のPCを繋ぐことに変わるのです。
◆ ヘッドレス（Headless）がもたらすWPFの復権
ここで、僕たちC#er、特にWPFやXamarin/MAUIを触っている人間に朗報があります。コンポーザブル・アーキテクチャの普及とともに、**「ヘッドレス（Headless）」**という技術トレンドが爆発的に伸びています。
ヘッドレスCMS、ヘッドレスコマース（Shopifyなど）。これらは「画面（Head）」を持たず、APIだけで機能を提供するサービスです。
これが何を意味するか分かりますか？
これまでWeb全盛期の中で、「Webブラウザで動かない技術」は肩身が狭い思いをしてきました。でも、バックエンドが完全にAPIファースト（ヘッドレス）になれば、フロントエンドは何でもいいんです。
Webでもいい、モバイルでもいい、そしてリッチなWPFデスクトップアプリでもいい。
コンポーザブル・アーキテクチャにおいて、バックエンド（PBCs）は「純粋なビジネスロジックとデータの供給源」に徹します。UIの制約を一切押し付けてきません。
これにより、僕たちはWPFの強力なデータバインディングや、DirectXを活用したヌルヌル動くUI表現を、最新のクラウドSaaSと直結させることができます。
「レガシーな業務アプリ」扱いされていたWPFアプリが、裏側では最新のAI検索エンジンや決済プラットフォームと繋がっている。そんな「モダン・デスクトップ」の開発が可能になるのです。
◆ 「イノベーションの加速」という残酷なスピード
しかし、良いことばかりではありません。開発スピード、いや「試行錯誤のスピード」が異常に速くなります。
海外の現場では**「Fail Fast（早く失敗しろ）」**が合言葉ですが、コンポーザブル・アーキテクチャはこれを極限まで加速させます。
例えば、「新しいリコメンドエンジンを試したい」となった時。
これまではエンジニアが実装するまで結果は分かりませんでした。でもこれからは、リコメンド機能のPBCを「A社製」から「B社製」に、A/Bテストのように差し替えて実験することができます。
コードのデプロイすら不要かもしれません。
エンジニアが「技術的な難易度」を理由にビジネスの要求を断ることは、もはやできなくなります。
「実装が大変だから無理です」
「え？ ブロックを入れ替えるだけだよ？ なぜできないの？」
このプレッシャーは凄まじいです。
技術的な「How（どう作るか）」の価値が暴落し、ビジネス的な「What（何を組み合わせれば勝てるか）」の価値が高騰する。
もはや僕たちは「プログラマー」ではなく、**「ビジネス・アーキテクト」あるいは「テクニカル・コンポーザー（作曲家）」**にならなければならないのです。
◆ コンポーザー（作曲家）としてのエンジニア
ここでタイトルの「Composable（構成可能）」に戻りましょう。
音楽において、コンポーザー（作曲家）は自分で全ての楽器を演奏するわけではありません。優れたバイオリン（検索機能）、優れたドラム（決済機能）、優れたピアノ（顧客管理）を連れてきて、それらが調和するように指揮を執ります。
2030年のエンジニア像は、まさにこれです。
画面（WPF）というステージの上で、世界中から集めた「最高のAPIたち」を共演させる。
あるAPIが出した出力を、別のAPIの入力に繋ぐ。そこで型が合わなければ、C#で薄いアダプター（Adapter Pattern）を書く。エラーが起きたら、サーキットブレーカー（Circuit Breaker）で全体が落ちないように守る。
コードを書く量は減りますが、システム全体を見渡す「視座」は、以前よりも遥かに高いものが求められます。
「この機能は自作すべきか？ それともSaaSを買うべきか？」
「このPBCとあのPBCのデータの整合性はどう保つか？」
この判断こそが、AIにもローコードツールにもできない、僕たちプロのエンジニアに残された聖域です。
◆ 変化の波に乗るか、飲まれるか
「そんなの、大企業だけの話でしょ？」
そう思うかもしれません。でも、AWSやAzureが「サーバーを買う」という行為を過去のものにしたように、コンポーザブル・アーキテクチャは「業務ロジックをゼロから書く」という行為を過去のものにしようとしています。
海外のスタートアップでは、すでにCTOがコードを書かず、SaaSの組み合わせ図（トポロジー）を描いてビジネスを立ち上げるケースが増えています。
WPFで基幹システムを作っている日本の現場にも、この波は必ず届きます。ある日突然、経営陣が「DXだ！」と言い出して、SalesforceやSAPとの連携を求められる。その時、スクラッチ開発しか知らないエンジニアは、途方に暮れることになります。
でも、恐れることはありません。
僕たちには「オブジェクト指向」で培った「疎結合・高凝集」のセンスがあります。「インターフェース」の重要性を知っています。
その知識の適用範囲を、クラス設計からシステム設計へ、コードからアーキテクチャへと広げればいいだけです。
さて、ここまで「起」「承」「転」と進めてきました。
現状の課題、解決策としての概念、そして現場への衝撃。
最後となる「結」では、これらを踏まえて、僕たちが今（2025年現在）、具体的に何を学び、どうマインドセットを変えれば、2030年に「笑って活躍できるエンジニア」になれるのか。
その結論と、明日からできるアクションプランをお伝えして締めくくりたいと思います。
2030年、僕たちは何を作っているのか？
ここまで、「起」で現状の泥沼を嘆き、「承」でコンポーザブルという解決策を知り、「転」で開発スタイルの激変を予感してきました。
読みながら、「おいおい、俺の仕事なくなるんじゃないか？」と不安になった人もいるかもしれません。
「コードを書かなくなるなら、エンジニアの楽しみって何だよ？」と。
でも、安心してください。
海外の最前線でこの波を浴びている僕が断言します。
僕たちの仕事は無くなりません。むしろ、もっと面白く、もっと人間らしくなります。
最終回となる今回は、2030年に向けて僕たちエンジニアが今すぐ装備すべき「3つの武器」と、C#使いとしての「勝ち筋」について話して、このシリーズを締めくくりたいと思います。
◆ コードの向こう側にある「本質」
まず、マインドセットの話をさせてください。
コンポーザブル・アーキテクチャが目指しているのは、**「退屈な作業からの解放」**です。
認証画面をまたゼロから作ること、CSVインポートのバグを直すこと、DBのマイグレーションで冷や汗をかくこと……。これらは確かに「エンジニアの仕事」でしたが、本当にやりたいことでしたか？
これらは「コモディティ（日用品）」です。誰が作っても大差ない機能です。
2030年のエンジニアは、こうしたコモディティをPBC（パッケージ化されたビジネス機能）として外部から調達し、**「自分たちのビジネスにしかない独自の価値（コア）」**を作ることに100%の時間を注ぎます。
例えば、WPFで工場のライン管理システムを作るとします。
在庫管理や勤怠入力はSaaSのPBCに任せる。その代わり、現場の職人さんが一番こだわっている「異常検知のグラフ描画の滑らかさ」や「直感的なタッチ操作のUI」に、僕たちの技術力を全振りするんです。
「何でも作る」時代は終わりました。「最高のものを選び、最高の体験を組む」時代の到来です。
◆ 今、僕たちが装備すべき3つの武器
では、具体的に何を学べばいいのか。C#の文法書を閉じて、次に開くべきページはここです。
1. 「繋ぐ力」：インテグレーション・リテラシー
これからのコーディングの主戦場は、ロジックの記述ではなく、通信の制御です。
単に HttpClient でGETするだけじゃ足りません。
- 認証・認可: OAuth2.0、OIDCのフローを完璧に理解していますか？
- API仕様: OpenAPI (Swagger) を読み解き、クライアントコードを自動生成できますか？
- レジリエンス: 繋いだ先が落ちていたらどうしますか？ C#なら「Polly」というライブラリがあります。リトライ、サーキットブレーカー、タイムアウト。これらのパターンを使いこなし、システムを「死なない」ようにする技術が必須になります。
2. 「分ける力」：ドメイン駆動設計 (DDD)
「承」でも触れましたが、どこまでを一つのブロック（PBC）にするか、その境界線を引く力がアーキテクトの資質を決めます。
コードを書く量は減りますが、設計の難易度は上がります。
「この機能は在庫コンテキストか？ 配送コンテキストか？」
この問いに答えるためのDDDの知識は、2030年には「教養」レベルになっているでしょう。
3. 「英語力」：情報とツールの調達源
耳が痛いかもしれませんが、海外で働いている身として言わせてください。
優れたPBCやSaaSのドキュメントは、最初はすべて英語です。日本語化されるのを待っていたら、競合に負けます。
「英語を話せる」必要はありません。「英語のドキュメントを読み、英語のエラーメッセージで検索し、英語のサポートにチャットで質問できる」力。これが、利用できるブロックの数を桁違いに増やします。
◆ C#エンジニアとしての「勝ち筋」
「じゃあ、C#やWPFはオワコン？」
とんでもない。むしろ、**C#こそが最強の接着剤（Glue）**になります。
コンポーザブルな世界では、ブロック同士の隙間を埋める「オーケストレーション」が必要です。
Pythonなどのスクリプト言語も人気ですが、エンタープライズの堅牢性が求められる場面では、静的型付けを持つC#の信頼性は圧倒的です。
- Azure Functions / AWS Lambda:ブロックとブロックを繋ぐ小さなロジック（サーバーレス関数）を書くのに、C#の起動速度とパフォーマンスは非常に優秀です。
- Blazor & MAUI:Webもモバイルもデスクトップも、C#で統一して書ける。これは、フロントエンド（ヘッド）を量産する上で強力な武器です。バックエンドがPBC化されているからこそ、C#でUIを作ることに集中できます。
- LINQ:バラバラのPBCから取得したデータを、メモリ上で結合・加工する。この処理において、LINQほど強力で表現力豊かな機能を持つ言語を、僕は他に知りません。
僕たちは、WPFで培った「データバインディング」という概念を、クラウド全体に拡張するんです。ViewとViewModelを繋いでいたように、SaaSとSaaSをC#で繋ぐのです。
◆ ラストメッセージ：冒険を楽しもう
2030年、僕たちは「システムエンジニア」から**「ビジネス・コンポーザー（事業構成家）」**へと進化しています。
画面の前で唸りながらバグと戦う時間は減り、ホワイトボードの前で「このAPIとこのAIを組み合わせたら、すごい体験が作れるんじゃないか？」と、チームで議論する時間が増えているはずです。
それは、レゴブロックでお城を作っていた子供の頃の感覚に似ているかもしれません。
制約から解き放たれ、創造性（Creativity）が試される世界。
海外の現場から見ていると、この変化は波のように押し寄せてきています。
怖がる必要はありません。サーフィンと同じで、波の性質を知り、適切なボード（スキル）を持っていれば、この波は僕たちを遠くまで運んでくれます。
さあ、準備はいいですか？
手元のVisual Studioを開いて、新しいプロジェクトを作りましょう。でも今回は、全部自分で書こうとしないでください。
世界中に散らばる最高の部品を探しに行きましょう。
それが、2030年の設計図を描く第一歩です。
Good luck!
コメント