はじめに
技術選定の話をすると、つい「新しい技術を選ぶべきか」「流行っている技術を採用すべきか」といった話が先に浮かびがちです。
でも、私は実務の現場で一番大事なのは、その技術を“人が使い続けられるか” という点だと考えています。流行があるのは当然ですが、技術選定は“今の会社やチームで長く使えるか”を軸に考えるべきです。
特に最近は AI の進化が速く、コード自体を書くことはだいぶ楽になっています。とはいえ、最終的にそのコードが正しいかどうかを判断するのは人間です。ライブラリーの選定が適切か、設計が安全か、運用上の制約がないかを見極めるのも人間です。
その意味で、選定の軸を整理しておくのはとても重要です。
私は技術選定の優先順位を次のように考えています。
- その言語や技術を、今のメンバーが使えるか
- 運用と保守を、人間が継続できるか
- 依存先やクラウドが、将来も扱いやすいか
- 最後に、流行や新しさをどこまで取り入れるか
この順番が大切です。
言語は“人間の土台”で決める
まず最優先なのは言語です。
言語は単なる文法の話ではなく、チームの知識・経験・判断基準そのものです。実務で使っている言語が違えば、設計の考え方も、ライブラリーの選び方も、エラーハンドリングの感覚も変わります。
例えば、C# で長く開発しているチームに、いきなり別言語を採用することを考えると、以下のようなコストが発生します。
- 既存コードとの接続の難しさ
- ライブラリーやフレームワークの選定にかかる学習コスト
- 相談できる人が限られる
- デバッグ時の観点が変わる
- 実運用で発生する不安が増える
AI がコードを書いてくれる時代になっても、「人が正しいかどうか判断できる」前提は変わりません。
今の組織が使い慣れている言語があるなら、そこから選ぶのが合理的です。言語選定は、最初に現実的な習熟度を見て決めるべきです。AI が使えるからといって、熟練者が少ない言語に踏み出すのは、短期的な見栄えだけでなく長期的な運用負荷を増やします。
逆に、言語そのものが既にチームで十分に消化されていて、世の中のライブラリーやコミュニティも安定しているなら、そこに基づいて技術を選ぶほうが安全です。
言語は「最先端かどうか」よりも、「今のチームで正しく判断できるか」が大事です。AI でコード生成ができるようになったからといって、技術選定の土台が変わるわけではありません。
フレームワークは「学習の広がり」より「適合度」を見て選ぶ
フレームワークは言語よりもやや条件が緩いですが、やはり同じように「使い慣れているか」が大事です。
ここで大事なのは、フレームワークごとの差分は比較的小さいことです。特に Web 系の技術では、
- HTTP の扱い
- 認証の実装
- ORM や DB 接続
- UI の構造
- テストの考え方
といった部分が、実は似たようなパターンでまとめられます。そのため、言語の違いほど大きな学習コストにはなりません。
なので、私はフレームワークの選定は「今のチームが慣れているか」という基準を最初に見るべきだと思っています。
ただし、フレームワークは言語ほど固定的ではないので、比較的柔軟に切り替えられるのが特徴です。
たとえば、React を使っていたチームが Next.js に切り替える、または ASP.NET Core の構成を少し変える、といったことは技術的には可能です。言語自体を変えるよりも変えやすい分、業務の進行と合わせて調整しやすいです。
逆に、言語が変わると、設計思想・エコシステム・コミュニティ・デバッグ戦略まで変わるため、選定の影響が広がります。
なので、フレームワークは次のように捉えるのがよいです。
- 言語よりは「現実的な入れ替えがしやすい」
- しかし、採用しているライブラリーや依存関係が変わると、運用コストも変わる
- そのため、まずはチームの既存知識と、現場での保守しやすさを重視する
つまり、フレームワークは“技術の流行”より“チームが持続できるか”を見て選ぶべきです。
クラウドは保守的に見るべき
クラウドサービスは、技術選定の中でもかなり慎重に見るべき領域です。
理由は単純で、クラウドは セキュリティやガバナンスに直結する からです。認証基盤、ネットワーク、IAM、監視、バックアップ、障害対応など、運用面に影響が大きく、少しの選定ミスが長期的なコストに跳ね返ります。
また、クラウドサービスの多くは「マネージドサービスに寄るほど運用が楽になる」というトレードオフがあり、その反面、ベンダーロックインのリスクも高まります。
たとえば、特定クラウドのマネージドサービスに依存しすぎると、
- 運用手順がそのクラウド固有になりやすい
- 監視やログの設計がベンダー依存になる
- 移行コストが大きくなる
- 監査やガバナンス対応が難しくなる
といった問題が出てきます。
ここで重要なのは、「マネージドにするか、OSS ベースで運用するか」 を、短期的な手軽さではなく、長期的な運用負荷で比較することです。
1. マネージドサービスのメリット
- 運用負荷が低い
- 導入が速い
- 専門知識が少なくても使いやすい
2. マネージドサービスのデメリット
- 仕様変更や制約が大きい
- 依存先が特定ベンダーに偏る
- 運用や監査がベンダー依存になる
3. OSS ベースのサービスのメリット
- 互換性が高く、移行しやすい
- 目的に応じて設計を調整できる
- 既存インフラとの整合性を保ちやすい
4. OSS ベースのサービスのデメリット
- 運用コストが高くなる
- 導入や保守が複雑になる
- 調整やカスタマイズが増えると知識が分散する
このあたりのバランスを見て、「何を自分たちで守るべきか」 を決めるのがクラウド選定の本質です。
たとえば、コンテナや Kubernetes 系の基盤を中心に構成しておくと、クラウド間でのポータビリティは上がります。ただし、クラウドごとの差分やカスタマイズが入ると、結局「どこかのベンダー特有の運用設計」になってしまうことがあります。
いちばん大事なのは、“運用をどこまで自分たちの責任にするか” を明確にし、その責任範囲に合う選定をすることです。
実務での選択の例：ASP.NET Core MVC / Blazor Server / Blazor WASM
ここでは、過去の選定と現在の考えを分けて書きます。私がこの 3 択で悩んだのは、.NET 6 のころの新規プロジェクトです。
.NET 6 のころに選んだ技術
候補は、ASP.NET Core MVC、Blazor Server、Blazor WebAssembly（WASM）+ ASP.NET Core Web API でした。
MVC は技術的に成熟していて、安心感がありました。Microsoft Learn でも、ASP.NET Core MVC は Model、View、Controller を分離するパターンとして説明されています。この責務分離は、テストや保守のしやすさにつながります。Overview of ASP.NET Core MVC
一方で、当時のリポジトリや周辺の動向を見ると、私は MVC を「成熟した技術として安定運用するもの」と捉えました。これは Microsoft Learn が MVC を保守フェイズと評価していたという意味ではなく、あくまで当時の状況に対する私の判断です。
このプロジェクトは画面数が少なくなかったため、画面の状態を扱いやすいコンポーネント指向の UI にも魅力を感じました。Blazor Server では、Razor コンポーネントがサーバー上で実行され、UI 更新やイベント処理が SignalR 接続を介して行われます。接続中のクライアントごとに、サーバー側の状態（circuit）も管理されます。ASP.NET Core Blazor hosting models
Blazor Server は、画面の状態をサーバー側で保持しながらリッチな UI を作りやすい点が魅力でした。しかし、ユーザー操作ごとにネットワーク通信が発生し、接続数に応じてサーバー側で circuit とコンポーネントの状態を管理する必要があります。従来のリクエスト単位のサーバーサイド MVC と同じ感覚で、状態管理を考えられるわけではありません。
また、Blazor Server は自由度が高く、コンポーネントから DB アクセスを直接呼び出す実装もできてしまいます。設計を誤ると、UI とアプリケーションロジックの境界が曖昧になります。これは Blazor Server 固有の制約ではなく、コンポーネントの書き方とプロジェクト構成によって起こる問題です。
新規プロジェクトだったため、私は「正しくテストできる構造を、チームの規約だけに頼らず維持できるか」を重視しました。Web API を 3 層で設計する方針に加え、少なくとも UI と API・アプリケーションロジックを別プロジェクトに分けやすい Blazor WebAssembly + ASP.NET Core Web API を選びました。
なお、Blazor WebAssembly がアーキテクチャ上の分離を自動的に強制するわけではありません。Blazor WebAssembly は、ブラウザー上で Razor コンポーネントを実行するホスティングモデルです。コンポーネント、依存関係、.NET ランタイムがブラウザーへダウンロードされます。私の場合は、その性質を利用して API と UI を別プロジェクトにする構成を採用しやすかった、という判断です。ASP.NET Core Blazor hosting models
現在、ゼロベースで選ぶなら
.NET 8 以降には Blazor Web App があり、静的 SSR、Interactive Server、Interactive WebAssembly、Interactive Auto という render mode をコンポーネント単位で選べます。ASP.NET Core Blazor render modes
現在の Blazor Web App は、当時の Blazor Server と Blazor WebAssembly を単純に 1 つへ統合したものではありません。サーバー側とクライアント側のどこでコンポーネントを実行するかを、render mode として設計するアプリモデルです。
特に Interactive Auto は、最初は Interactive Server で動作し、その後 WebAssembly 用のバンドルがダウンロードされるとクライアント側で動作します。そのため、サーバーとクライアントの両方で動かす前提、WebAssembly 用のクライアントプロジェクト、プリレンダリング、状態や依存関係の境界を考える必要があります。便利な反面、開発者が考慮すべき設計判断は増えます。
そのため、現在でも私がゼロベースで選ぶなら、まず Interactive Server と Interactive WebAssembly のどちらを要件が求めているかを確認します。接続数に応じたサーバー負荷、オフライン対応、クライアントへ配布するコード、初期表示などを比較し、必要な場合にだけ複数の render mode を採用します。複雑さそのものを目的にしない、というのが現在の私の考えです。
過去の案件で Blazor WebAssembly を選んだ理由も、現在の選び方も共通しています。Blazor WASM が常に正解だったからではなく、View とそれ以外の責務を、プロジェクト構造として分けやすくしたかったからです。
技術選定には「比較軸」を持つべき
技術選定で迷うとき、私は次の観点を必ず見ます。
| 観点 | 見るべきこと | 重要度 |
|---|---|---|
| 🧑💻 人材 | チームに使える人がいるか | 最重要 |
| 🧩 既存資産 | 既存コードと自然に接続できるか | 高 |
| 🛠️ 運用 | 監視、ログ、障害対応が継続できるか | 高 |
| 🔐 セキュリティ | 認証、権限、監査、依存関係の安全性 | 高 |
| 📦 エコシステム | ライブラリーやコミュニティが成熟しているか | 中 |
| 📈 将来性 | 長期的にアップデート可能か | 中 |
| 💸 コスト | 運用コストと導入コストのバランス | 中 |
ここで大事なのは、技術そのものの価値よりも、運用体制と人材の有無・余力を見て決める点です。
新しい技術が優れていても、チームで安心して使えるならよいですが、逆にすでに使い慣れている技術があっても、運用が危ういなら採用は慎重に考えるべきです。
流行は“選択肢”であって“正解”ではない
最近は技術の流行が非常に速く、関心を持つのも自然です。
でも、技術選定において“流行”は、最終的な結論を決める主役ではありません。流行はあくまで、比較対象の候補を増やすための材料です。
特に注目したいのは、技術の流行は 実装の手軽さ と 運用の真剣さ が別物であるという点です。新しい技術は、短期的には便利に見えますが、長く運用するには別の知識や設計が必要になることがあります。
だから私は、選定時に次のような問いを大切にしています。
- その技術はチームで今すぐ使えるか
- 1 年後、3 年後も人が継続して扱えるか
- 何が変わったときに、チームが破綻しないか
- 依存先が増えたときに、意思決定ができるか
この問いに対して安定して答えられる技術を選ぶのが、現実的な技術選定です。
まとめ
技術選定は、どれが「流行っているか」ではなく、どれが人と組織にとって継続できるかで決めるべきです。
- 言語は、チームが使えるかが最優先
- フレームワークは、慣れたものを活かしつつ最適化できるかを見て選ぶ
- クラウドは、ガバナンスと運用の責任範囲を十分に考える
- 流行は選択肢として見るが、最終判断の軸にはしない
結局、技術選定の大事な基準は「人間が正しく扱えるか」です。AI が進化しても、技術を選ぶのは人間であり、使い続けるのも人間です。
その前提を忘れず、実務で持続可能な技術を選ぶことが、長く安心して開発を続けるための一番大きな判断材料になるのだと思います。
技術は時代とともに変わりますが、チームが使いこなせる技術を選ぶ姿勢だけは、時代を超えて変わりません。