モノリスの終焉と「コンポーザブル」との遭遇：なぜ今、私たちは変わらなければならないのか？
こんにちは！海外のとあるカフェで、今日も今日とてVisual Studioを開いている現役ITエンジニアです。
ここでの生活にも慣れてきましたが、相変わらずC#とWPF（Windows Presentation Foundation）は私の相棒です。XAMLのタグをカチャカチャと叩き、MVVMパターンで綺麗にデータバインディングが決まった時のあの快感、わかりますよね？
「WPFなんてレガシーじゃない？」なんて言う人もいるかもしれませんが、デスクトップアプリの堅牢さと、あのリッチなUI表現力は、産業用システムや業務アプリの現場ではまだまだ現役バリバリです。特にここ海外のエンタープライズな現場では、信頼性が何より重視されるので、枯れた技術（いい意味で！）としてのWPFの需要は底堅いものがあります。
でも、正直に告白します。
ここ数年、海外の現場で揉まれる中で、強烈な危機感を覚える瞬間が増えてきました。それは、技術そのものの古さというよりは、「作り方」と「考え方」の古さに対する危機感です。
「巨大な一枚岩（モノリス）」の居心地の良さと、その代償
私たちは長らく、すべての機能がひとつの巨大なプロジェクトに詰め込まれた「モノリシック」なアプリケーションを作ることに慣れすぎていました。
UIも、ビジネスロジックも、データアクセスも、すべてが密結合した巨大な .exe ファイル。WPFで開発していると、これがまた作りやすいんですよね。参照関係さえ通せば、どこからでもどのクラスでも呼べる。修正もデプロイも、その巨大な塊を「ドン！」と置き換えるだけ。
日本で働いていた頃は、それでなんとかなっていました。仕様変更は数ヶ月に一度。リリースサイクルも年単位。
しかし、海外の、特にアジャイルが「概念」ではなく「当たり前の呼吸」として定着している現場に来て、その居心地の良さは完全に崩れ去りました。
「Hey, この機能、明日までに別のサードパーティAPIに切り替えてくれない？」
「来週からモバイルチームも同じロジックを使いたいから、UIから切り離してクラウドに上げて。」
「この部分だけ、別のチームがPythonで書き直したいってさ。」
こんな要望が、日常茶飯事なんです。
そのたびに私は、巨大なソリューションファイルを開き、スパゲッティのように絡み合った依存関係を解きほぐし、冷や汗をかきながらリファクタリングをする羽目になります。「ここを直すと、あっちの画面が動かなくなるかも…」という恐怖と戦いながら。
ここで痛感したのは、「変化への対応速度」が、エンジニアの価値そのものになっているという現実です。
どれだけ美しいXAMLが書けても、ビジネスの変化についていけないアーキテクチャは、海外では「負債」と見なされます。
「コンポーザブル（Composable）」という衝撃
そんなある日、とある技術カンファレンスの動画を見ていて、ガツンと頭を殴られるような言葉に出会いました。それが**「Composable Business（コンポーザブル・ビジネス）」、そして「Composable Architecture（コンポーザブル・アーキテクチャ）」**という概念です。
Gartnerなどが提唱しているこの考え方は、簡単に言えば**「ビジネスやシステムを、レゴブロックのように組み立て可能な部品（コンポーネント）の集合体として捉える」**というものです。
これを聞いたとき、最初は「ああ、マイクロサービスのことね」と高を括っていました。
でも、深く調べていくうちに、これは単なるサーバーサイドの分割話ではないことに気づきました。これは、私たちWPFエンジニアも含めた、すべての開発者が持つべき**「思考のOS」のアップデート**だったんです。
「コンポーザブル」の本質は、**「交換可能であること」と「再構成可能であること」**です。
想像してみてください。
もし、あなたの作ったアプリケーションの機能の一つ一つが、独立したブロックとして存在していたら？
認証機能、在庫検索機能、決済機能…それぞれが、UI（WPFだろうがWebだろうが）に関係なく、必要な時に必要な場所で「カチャッ」と組み合わせて使える状態になっていたら？
これまでの私たちは、一度作ったら二度と動かせない「コンクリートの城」を建てていました。
しかし、今求められているのは、戦況に応じて即座に組み替えられる「前線基地」なのです。
海外エンジニアとして生き残るための「武器」
なぜ私が、わざわざこのブログで「コンポーザブル」を熱く語るのか。
それは、これから海外を目指すエンジニア、あるいはすでに海外で戦っているエンジニアにとって、これが最強の生存戦略になると確信しているからです。
海外の現場はシビアです。
「君は何ができるの？」と聞かれたとき、「C#で大きなアプリが作れます」と答えるのと、「ビジネスの変化に合わせて、システムを柔軟に組み替えられるアーキテクチャを設計できます」と答えるのでは、雲泥の差があります。
特にWPFのようなクライアントサイドの技術を扱っている私たちこそ、この意識改革が必要です。
「UIはただの『窓』であり、真の価値は背後の『機能ブロック（Capabilities）』にある」と捉え直すこと。
そして、その機能ブロックをいかにして「使い回せる形（Composable）」にするか。
これができるようになると、不思議なことに、技術スタックが変わっても怖くなくなります。
WPFが廃れても、Mauiになっても、あるいはWebになっても、私たちが設計した「ビジネスの核」は、ブロックとしてそのまま生き続けるからです。
次のステップへ：準備はいいですか？
ここまでは、私が直面した「壁」と、そこに見えた「光」の話をしました。
「じゃあ具体的にどうすればいいの？」「いきなりマイクロサービスなんて無理だよ」という声が聞こえてきそうです。
安心してください。私もいきなり全てを変えられたわけではありません。
大切なのは、**「小さく始めること（Start Small）」**です。
次章の【承】では、私が実際に現場で行った、
「巨大なWPFアプリをいかにしてコンポーザブルな思考で再構築し始めたか」
その具体的な最初の一歩について、泥臭い失敗談も交えながらお話しします。
キーワードは、「コア機能の特定（Identify Core Capabilities）」と「継続的な学習（Embrace Continuous Learning）」です。
さあ、あなたの持っているその「巨大な一枚岩」、そろそろハンマーで叩き割って、自由なブロックに変えていきませんか？
小さく始めて、コアを見極める：WPFエンジニアが実践する「コンポーザブル」への具体的な第一歩
「よし、コンポーザブルだ！明日から全てのアーキテクチャをマイクロサービスにして、Kubernetesで管理して、WPFはただのThin Clientにするぞ！」
前回の記事を読んで、もしあなたがこう意気込んでしまったとしたら、ちょっと待ってください。深呼吸しましょう。
かつての私がそうだったように、その情熱は素晴らしいですが、そのアプローチは十中八九、大炎上して終わります。
海外の現場に来て痛感したのは、理想のアーキテクチャを語ることと、動いているシステムを止めずに進化させることの間には、グランドキャニオン並みの深い溝があるということです。
この「承」のパートでは、WPFというレガシーな技術スタックを抱えながら、私たちがどうやって現実的に「コンポーザブルな世界」へ移行していくか。その具体的な戦術について、私の失敗談と成功体験を交えてお話しします。
キーワードは3つ。「Start Small（小さく始める）」、「Identify Core Capabilities（コア機能の特定）」、そして**「Embrace Continuous Learning（継続的な学習）」**です。
1. Start Small：いきなり作り直そうとするな
私が海外のチームにジョインして最初に取り組んだプロジェクトは、10年選手のスパゲッティコード満載な在庫管理システムの改修でした。
当時の私は、「日本の品質を見せてやる！」と意気込み、マネージャーのトムに提案しました。「このコードはメンテナンス不可能です。一度全部捨てて、最新のアーキテクチャで書き直すべきです（The Big Rewrite）。」
トムはコーヒーを一口飲み、静かに言いました。
「いいアイデアだね。でも、その『書き直し』ている半年間、ビジネスはどうやって利益を生むんだい？ そして半年後、君が書き直したそのコードが、その時のビジネス要件に合っている保証はどこにある？」
私は言葉に詰まりました。
トムが教えてくれたのは、**「進化は革命ではなく、改善の積み重ねであるべきだ」**という教訓でした。
「ストラングラー・パターン」をデスクトップアプリに応用する
そこで私たちが採用したのは、**「ストラングラー（絞め殺し）パターン」**の考え方です。
これは通常、Webサービスの移行で使われる言葉ですが、WPFアプリ開発にも十分に適用できます。
巨大なモノリス（既存アプリ）を生かしたまま、新しい機能を「小さな独立したコンポーネント」として外付けで作っていき、徐々に古い機能を置き換えていくのです。
例えば、WPFアプリの中に、数千行に及ぶ巨大な OrderManager というクラスがありました。
これをごっそり書き直すのではなく、その中から「送料計算」という極めて小さな機能だけを切り出しました。
IShippingCalculatorというインターフェースを定義する。- その実装を、WPFプロジェクトとは別の、純粋な .NET Standard のクラスライブラリ（Class Library）として作成する。
- 既存の
OrderManagerから、その新しいライブラリを呼び出すように書き換える。
たったこれだけです。UIも変わりませんし、データベースもそのまま。
でも、この小さな一歩が革命の始まりでした。
「送料計算」が独立したことで、この部分はUIの都合に関係なくテストが可能になりました（Unit Testing）。さらに、将来的にこの計算ロジックをAzure Functionsなどのクラウドへ移行したくなったら、このクラスライブラリをそのまま持っていけばいいのです。
アドバイス：
まずは、あなたのプロジェクトの中で「一番依存が少なそうな小さなロジック」を見つけてください。それを別プロジェクト（アセンブリ）に切り出す。そこから始めてみましょう。UIから切り離されたコードの「軽さ」に感動するはずです。
2. Identify Core Capabilities：UIは水物、ビジネスは資産
WPFエンジニア（あるいはフロントエンドエンジニア全般）が陥りがちな罠があります。
それは、「画面 = 機能」だと思ってしまうことです。
ViewModelの中にガッツリとビジネスロジックを書いていませんか？
ボタンのクリックイベントハンドラの中に、データベースへの接続コードが紛れ込んでいませんか？
「コンポーザブル」な思考において最も重要なのは、「コア機能（Business Capabilities）」を見極め、それをUIから徹底的に隔離することです。
ある日、マーケティングチームから「来週の展示会用に、在庫検索機能だけiPadで見れるようにしたい」という無茶振りが飛んできました。
もし私が、ViewModelの中に在庫検索ロジックを埋め込んでいたら、私は「無理です、作り直しになります」と言うか、徹夜でロジックをコピペしてWeb APIを作る羽目になっていたでしょう。
しかし、その時の私はすでに「コア機能の分離」を進めていました。
「在庫を検索する」という行為は、WPFのものでもiPadのものでもなく、純粋な**「ビジネスの能力（Capability）」**です。
私は、WPFプロジェクトから独立させていた InventoryService というライブラリを、ASP.NET Coreのプロジェクトから参照し、簡単なREST APIラッパーを被せました。
iPadアプリ（PowerAppsで作りました）は、そのAPIを叩くだけ。
実質、半日で対応が完了しました。
「これはビジネスの資産か？ UIの都合か？」と問いかける
コードを書くとき、常に自問自答してください。
「この if 文は、ボタンの色を変えるためのものか？ それとも、割引率を決めるためのものか？」
前者はUIの都合なので、ViewやViewModelに留めるべきです。
後者はビジネスのルールであり、企業の資産です。これは、UIフレームワークが何であれ、再利用可能な状態で保存されるべき「ブロック」なのです。
この「資産」をブロック化（コンポーネント化）しておくことこそが、コンポーザブル・アーキテクチャの真髄です。
WPFが廃れようが、Windowsが無くなろうが、あなたが抽出した「ビジネスロジック」というブロックは、次のプラットフォームでそのまま使えるのです。
アドバイス：
WPF固有の型（DependencyObject, ObservableCollection, ICommand など）を一切使わないクラスライブラリを作ってください。そこにビジネスロジックを移動させる練習をしましょう。それが、あなたのコードを「ポータブル（持ち運び可能）」にする秘訣です。
3. Embrace Continuous Learning：永遠のベータ版であること
コンポーザブルなアーキテクチャを目指すと、必然的に直面することがあります。
それは、「技術のつまみ食い」が必要になるということです。
モノリスな世界では、C#とWPFとSQL Serverだけを知っていれば王様になれました。
しかし、システムをブロックに分けていくと、「この認証ブロックだけはAuth0を使おう」「このログ収集ブロックだけはElasticsearchに投げよう」といった具合に、適材適所で様々な技術を組み合わせることになります。
これを聞いて「うわ、勉強することが増える…」と絶望しないでください。
むしろ逆です。コンポーザブルな世界では、「浅く広く知っておくこと」の価値が上がります。そして、必要な時に必要なブロックだけを深く学べばいいのです。
私の同僚に、ベトナム出身のエンジニア、ミンがいます。
彼はC#のスペシャリストではありません。でも、彼は「繋げること」の天才です。
「C#で全部書く必要はないよ。Pythonのライブラリに優秀な画像処理があるから、そこだけコンテナ化してgRPCでWPFから呼べばいいじゃないか」
彼はそう言って、サクッとプロトタイプを作ってしまいます。
彼から学んだのは、**「自分の得意なハンマーだけで全てを解決しようとしない」**という姿勢です。
海外のエンジニアたちは、新しい技術を学ぶことを「コスト」ではなく「投資」だと捉えています。
そして、彼らは完璧を求めません。「とりあえず動くブロック」を作り、それを繋げてみて、ダメならそのブロックだけ捨てて別の技術で作り直す。
コンポーザブルな設計だからこそ、この「技術的なトライ＆エラー」が低リスクでできるのです。
インプットを変える、マインドを変える
私は日本にいた頃、分厚い技術書を最初から最後まで読まないと気が済まないタイプでした。
でも今は違います。
「この機能を実現するために使えるAPIはないか？」「クラウドのマネージドサービスで代用できないか？」という視点で情報を探します。
- APIファーストの思考: 自分で作る前に、世の中に既にその「ブロック」がないか探す。
- クラウドネイティブな視点: オンプレミスのWPFアプリであっても、クラウドの恩恵（認証、ログ、解析など）をどう取り込むか考える。
これらを意識するだけで、あなたのエンジニアとしての市場価値は劇的に上がります。
「WPFしかできません」というエンジニアから、「WPFを入り口にして、様々なクラウドサービスや技術をオーケストレート（指揮）できるエンジニア」へ進化するのです。
アドバイス：
週末に少しだけ、自分の専門外の技術に触れてみてください。Dockerコンテナを一つ立ち上げてみる、簡単なWeb APIを書いてみる、クラウドのチュートリアルをやってみる。
「あ、これ、あの機能の実装に使えるかも？」という気づきが、点と点を結び、あなたのアーキテクチャの引き出しを広げてくれます。
次なるステップへ：ブロックはどうやって会話する？
ここまで、「小さく切り出すこと」「ビジネスロジックを資産化すること」「新しい技術を柔軟に取り入れること」についてお話ししました。
これで、あなたの手元には、巨大な岩から切り出された、いくつかの綺麗な「ブロック（コンポーネント）」が並んでいるはずです。
でも、ちょっと待ってください。
バラバラになったブロックたちは、どうやって協調して一つのシステムとして動くのでしょうか？
巨大な .exe の中ではメソッド呼び出し一つで済んでいたことが、ブロックに分かれた途端、通信の問題、タイミングの問題、整合性の問題として立ちはだかります。
そこで登場するのが、次章のテーマである**「イベント駆動（Event-Driven）」と「オーケストレーション」**です。
単にブロックを作るだけでは不十分。
それらをまるでジャズバンドのように、あうんの呼吸で連携させるための「指揮」と「リズム」が必要です。
次回の【転】では、技術的な連携パターンの話に加え、それがもたらす「チーム構成」や「開発プロセス」への劇的な変化について、さらに深掘りしていきます。
WPFエンジニアの皆さん、まだXAMLの記述に戻らないでください。
私たちの変革の旅は、ここからが面白くなるところです。
技術だけの話じゃない？イベント駆動とオーケストレーションが教えてくれた「組織とマインド」の変革
「よし、機能を切り出したぞ！ これで俺たちもマイクロサービスだ！」
…と喜んだのも束の間、私たちはすぐに次の壁にぶつかりました。
バラバラになった機能ブロック（コンポーネント）たちが、お互いにどうやって会話すればいいのか、という問題です。
かつての一枚岩（モノリス）時代は簡単でした。隣のクラスのメソッドを呼ぶだけ。同期処理で結果が返ってくるまで待ち、エラーが出たらその場でキャッチする。
しかし、ブロックが物理的・論理的に分かれた世界でそれをやり続けると、いわゆる**「分散モノリス（Distributed Monolith）」**という最悪の怪物が生まれます。
ネットワーク越しにメソッドを呼び合い、どこか一つがコケたら全体が止まる。これでは、苦労して分割した意味がありません。
ここで登場するのが、コンポーザブルな世界を支える二つの魔法、**「イベント駆動（Event-Driven）」と「オーケストレーション」**です。
そして、この技術的なシフトに取り組む中で、私はもっと重要なことに気づきました。
アーキテクチャを変えることは、チームのあり方、そしてエンジニアとしての働き方そのものを変えてしまうという衝撃的な事実です。
1. 「電話」をやめて「チャット」にする：イベント駆動というリズム
従来のシステム連携は「電話」のようなものでした。
「もしもし、在庫確認したいんだけど？」「ちょっと待ってね…（検索中）…あったよ」「OK、じゃあ注文確定するね」
相手が電話に出るまで待たなければならないし、相手が忙しければ話が進まない。これが「密結合（Tightly Coupled）」です。
一方、海外のモダンな現場で主流になっている「イベント駆動」は、「SlackやTeamsのチャット」のようなものです。
- 注文機能ブロックが**「注文が入ったよ！（OrderPlaced）」**というメッセージ（イベント）を、共有のチャットルーム（メッセージブローカー）に投げ込む。
- 注文機能は、それで仕事終わり。「あとは誰かよろしく！」と次の注文処理に移る。
- そのチャットルームを監視している「在庫管理ブロック」や「配送手配ブロック」が、自分のタイミングでメッセージを拾い、それぞれの仕事（在庫引き落とし、伝票作成）を開始する。
WPFエンジニアの皆さんなら、ピンとくるはずです。
そう、これは私たちが画面側でやっている ICommand や INotifyPropertyChanged、あるいは .NET Events の仕組みを、システム全体に拡張したようなものです。
C#エンジニアにとっての「イベント駆動」
私が最初にこのパラダイムに触れたとき、C#で慣れ親しんだ「手続き型」の頭を切り替えるのに苦労しました。
「結果が返ってこないなんて不安じゃないか？」「エラーが起きたらどうするんだ？」
でも、一度このリズムに慣れると、その**「疎結合（Decoupling）」**の心地よさに病みつきになります。
WPFアプリから「保存ボタン」を押したとき、裏側で何十個の処理が走ろうが、UIスレッドは即座に解放される。
在庫システムがメンテ中で止まっていても、メッセージブローカーにイベントさえ投げておけば、システム復旧後に処理が再開される。
この「相手の状態を気にしなくていい」という感覚こそが、コンポーザブルなシステムを安定させる鍵だったのです。
アドバイス：
いきなりKafkaやRabbitMQを導入するのが怖ければ、まずはアプリケーション内部で**「MediatR」**のようなライブラリを使ってみてください。
インプロセス（メモリ内）でのPub/Subパターンを実装することで、「命令（Request）」と「通知（Notification）」を分けて考える思考のトレーニングになります。これはWPFのViewModel設計を綺麗にするのにも役立ちますよ。
2. コンダクターの存在：モダンなオーケストレーション
しかし、全員が勝手にイベントを投げ合うだけでは、複雑なビジネスプロセスは迷子になります。
「注文完了メールは、決済が終わってから送りたいんだけど、誰がそれを管理してるの？」
ここで**「オーケストレーション」**の出番です。
かつては、何万行ものC#コードで書かれた「ワークフローマネージャー」みたいなクラスを作っていました。
しかし、コンポーザブルな時代には、もっとスマートな方法があります。
海外の現場に来て驚いたのは、エンジニアたちが**「コードを書かないこと」**に誇りを持っていることです。
「この承認フロー、Azure Logic Appsで繋いでおいたよ」
「エラー時の再試行ロジックはPower Automateで組んだから、コード修正はいらないよ」
彼らは、独立したブロック（Azure FunctionsやAPI）を、GUIベースのオーケストレーターで繋ぎ合わせ、一つの大きなプロセスを「作曲」していたのです。
これを見たとき、私は**「コーディング偏重主義」の敗北を悟りました。
C#で一生懸命 try-catch やリトライ処理を書くよりも、クラウドネイティブなオーケストレーターを使った方が、可視化もできるし、修正も速い。
WPFエンジニアとしての私の役割は、「全てのロジックを書くこと」から、「オーケストレーターが使いやすい『良い部品』を提供すること」**へと変化したのです。
3. コンウェイの法則の逆襲：アーキテクチャが組織を変える
そしてここからが、今回の「転」のハイライトです。
システムを「独立したブロック」に分け、「イベント」で会話させ、「オーケストレーター」で繋ぐようにした結果、何が起きたと思いますか？
チームの会話と組織図が変わりました。
IT業界には有名な**「コンウェイの法則」という言葉があります。
「システムのデザインは、その組織のコミュニケーション構造を模倣する」というものです。
しかし、私たちはその逆、「逆コンウェイ戦略（Inverse Conway Maneuver）」**を体験しました。
以前は、「DB担当チーム」「サーバーサイドチーム」「WPF画面チーム」という、技術レイヤーごとの横割り組織でした。
これだと、一つの機能追加のために、3つのチームの承認と調整が必要で、とにかく遅い。
しかし、コンポーザブルなアーキテクチャ（特定のビジネス機能を持ったブロックの集合体）に移行してからは、チーム構成が自然とこう変わりました。
- 「注文ケイパビリティ（能力）チーム」
- 「在庫ケイパビリティ（能力）チーム」
それぞれのチームには、バックエンドもフロントエンド（WPF含む）も分かるエンジニアが混在し、**「自分たちのブロック（製品）の価値を最大化する」**ことだけに集中するようになったのです。
「納品して終わり」から「育て続ける」マインドへ
以前の私は、「仕様書通りにWPF画面を作って納品すればゴール」だと思っていました。
しかし、ケイパビリティチームの一員になってからは違います。
「自分たちの在庫検索ブロックが、他のチームから使いにくいと言われている。APIのインターフェースを変えようか？」
「モバイルチームも俺たちのブロックを使いたいらしい。イベントの形式を汎用化しよう」
私の視座は、単なる「C#プログラマー」から、**「サービスオーナー」へと引き上げられました。
これが、冒頭で述べた「海外エンジニアとしての生存戦略」の正体です。
技術スタックが変わっても生き残れるのは、この「ビジネス機能の責任者としての視点」**を持っているエンジニアだけだからです。
予期せぬ副作用：孤独からの解放
最後に、個人的に嬉しかった変化を一つ。
レイヤー別チームだった頃、WPF担当の私は孤立しがちでした。「サーバー側のことはよく分からないから任せるよ」と線を引かれ、画面のバグは全部自分のせいにされる。
しかし、機能別（垂直）チームになってからは、サーバーサイドのエンジニアと密に連携するようになりました。
「このデータ、イベントで非同期に渡すから、WPF側ではローディング表示を工夫してくれない？」
「OK、じゃあSignalRで通知が来たら画面更新するように組むね」
共通言語が「C#」ではなく**「ビジネスイベント」**になったことで、技術スタックの壁を超えた真のコラボレーションが生まれたのです。
英語でのコミュニケーションに不安があった私でも、「コード」と「アーキテクチャ図」を真ん中に置くことで、対等に議論ができるようになりました。
次なるステップへ：そして未来へ
技術的な分断を乗り越え、組織の壁さえも溶かし始めた私たちの「コンポーザブル」な旅。
ブロックは揃い、リズム（イベント）も生まれ、チームの意識も変わりました。
しかし、物語はここで終わりではありません。
この変化の激しい時代、私たちが作ったこのシステムを、どうやって**「陳腐化」**から守り抜くのか？
そして、これからエンジニアを目指す人、あるいはキャリアに迷っている人は、明日から具体的に何のアクションを起こすべきなのか？
最終章となる【結】では、これからの時代を生き抜くための「Call to Action（行動喚起）」と、私が海外で見つけた「エンジニアとしての幸せの定義」についてお話しして、このシリーズを締めくくりたいと思います。
未来へのコール・トゥ・アクション：アーキテクチャを将来にわたって守り抜くために今すべきこと
海外のカフェで、冷めたコーヒーを飲みながらこの記事の最後を書いています。
窓の外を行き交う人々を見ていると、技術の世界も同じだなと思います。止まっているように見えて、実はものすごいスピードで流れている。
これまでの連載で、私たちは「巨大な一枚岩（モノリス）」を叩き割り、「コンポーザブル（構成可能）」なブロックに作り変える旅をしてきました。
「小さく切り出し（Start Small）」、「コア機能を見極め（Identify Core Capabilities）」、「イベントで会話させ（Event-Driven）」、そして「全体を指揮する（Orchestrate）」。
最終回となる今回は、なぜこれが単なる流行り廃りではなく、あなたのキャリアを守る「盾」となり、未来を切り開く「剣」となるのか。そして、明日からあなたは何をすべきなのかを熱く語らせてください。
変化こそが唯一の安定である：Future-Proof Your Architecture
「WPFはいつまで使えますか？」
この質問をよく受けます。でも、コンポーザブルな思考を手に入れた今、私にとってその質問はあまり意味を持ちません。
なぜなら、私たちが設計した「ビジネス機能（ブロック）」は、WPFというUIフレームワークから独立して生き続けるからです。
もし明日、会社が「次はWebだ」「いや、VRだ」と言い出しても、私たちは慌てません。「OK、じゃあそのUIブロックだけ差し替えよう。背後のロジックとデータフローはそのまま使えるから」と涼しい顔で言えるのです。
これを**「Future-Proof（将来にわたって通用する）」なアーキテクチャと呼びます。
未来を予知することは誰にもできません。だからこそ、「何が来ても交換可能な状態にしておく」**ことこそが、最強の生存戦略なのです。
特に海外の現場では、技術の新陳代謝が激しい。
昨日までスターだったライブラリが、今日は非推奨になるなんて日常茶飯事です。
そんな荒波の中で、一つの技術にしがみつくのは、沈みゆく船の手すりを必死に磨いているようなもの。
船（プラットフォーム）が変わっても、荷物（ビジネス価値）をすぐに次の船に移せる準備をしておく。これが、プロフェッショナルなエンジニアの責任です。
AI時代における「コンポーザブル」の真価
そして、忘れてはいけないのがAIの存在です。
GitHub CopilotやChatGPTのようなAIコーディングアシスタントが台頭する今、エンジニアの役割は激変しています。
「コードを書く」という作業自体の価値は、残念ながら下がっていくでしょう。AIは私たちよりも速く、正確に定型コードを書けますから。
では、私たちの価値はどこに残るのか？
それは、**「ブロックを設計し、選定し、組み合わせる能力」**です。
AIに「ECサイト作って」と頼んでも、今のところまともなものは出てきません。
しかし、「在庫管理のマイクロサービスと、決済APIと、WPFの管理画面を、Azure Service Busで繋ぐアーキテクチャを提示して。インターフェース定義はこれ」と指示すれば、AIは素晴らしい働きをします。
コンポーザブルなアーキテクチャは、AIにとって理解しやすく、扱いやすいのです。
機能が明確に分割されているため、AIに「このブロックのリファクタリングをして」「このブロックのテストコードを書いて」と依頼しやすい。
つまり、コンポーザブルな思考を持つことは、「AIに仕事を奪われる側」から「AIを部下として使いこなす側」へ回るためのチケットなのです。
Call to Action：コンポーザブル革命に参加せよ
さあ、話は十分しました。次は行動の時です。
「難しそうだな…」と尻込みする必要はありません。私も最初は、たった一つのクラスを切り出すところから始めました。
海外で戦う一人のエンジニアとして、あなたに明日から実践してほしいアクションリストを提示します。
1. “Delete” Key is Your Best Friend（捨てることを恐れるな）
作成したコードを「永遠に残る記念碑」だと思わないでください。コードは「生鮮食品」です。
**「このコードは捨てやすいか？」**と常に自問してください。
もし、ある機能を修正するために、関係ないクラスまで触らなきゃいけないなら、それは「腐っている」兆候です。
次にリファクタリングする時は、「将来この部分を丸ごと捨てて、別の技術に置き換えるとしたら？」と想像しながらインターフェースを切ってみてください。
2. Learn the “Edges”（境界線を学ぶ）
C#の文法を極めるのもいいですが、これからは**「つなぎ目」**の技術を学んでください。
REST API、gRPC、GraphQL、そしてメッセージキュー（RabbitMQ, Azure Service Busなど）。
ブロックの中身（実装）よりも、ブロックとブロックの間（契約）をどうデザインするかが、アーキテクトとしての腕の見せ所です。
WPFエンジニアなら、まずは「ViewModelとModelの間を、完全に疎結合にする（DIコンテナを使い倒す）」ことから始めてみましょう。
3. Talk “Capabilities”, Not “Features”（機能ではなく、能力を語れ）
ビジネスサイドの人と話すとき、「画面」の話ばかりしていませんか？
「在庫を検索する能力（Capability）」、「顧客を認証する能力」。そういった抽象度でシステムを捉え直してください。
そうすることで、UIという皮を剥いだ、システムの「本質的な価値」が見えてきます。それが、あなたが守るべき「コア・ブロック」です。
最後に：エンジニアとしての「Ikigai（生きがい）」
最後に、少しだけ個人的な想いを。
私は日本で生まれ育ち、今、海外で働いています。
日本のエンジニアが持つ「職人気質」や「細部へのこだわり（Takumi spirit）」は、世界でも称賛される素晴らしい資質です。
一方で、変化を恐れ、一度作ったものを壊せない「完璧主義」が、足枷になることも見てきました。
コンポーザブルなアプローチは、この両方のいいとこ取りができると私は信じています。
一つ一つのブロックの中身は、日本の職人魂で高品質に作り込む（Kintsugiのように、壊れたら直して価値を高める）。
そして、それらのブロックを繋ぎ合わせる時は、海外流に**柔軟かつ大胆に（Agileに）**構成する。
これができれば、あなたはどこへ行っても、どんな技術が流行ろうとも、
「君が必要だ」と言われるエンジニアであり続けられます。
「Stay Ahead of the Curve（時代の先を行け）」
「Future-Proof Your Architecture（未来に備えた設計をしろ）」
そして、
「Join the Composable Revolution（コンポーザブル革命に参加せよ）」
あなたの持っているその巨大なハンマー（一枚岩）を置き、レゴブロックを手に取りましょう。
創造の自由と、変化を楽しむ余裕が、そこには待っています。
また、世界のどこかのカンファレンスで、あるいはGitHubのプルリクエストでお会いしましょう。
Happy Coding!
コメント