はじめに：こんな質問、経験ありませんか？
新しい開発プロジェクトが立ち上がるとき、技術選定は避けて通れないですよね。
設計や要件定義はもちろん大事ですが、「どの技術で作るか」も同じくらい重要なテーマです。
チーム内で時間をかけて議論し、「今回はこれが一番合っているよね」と納得して決めたはずなのに、会議やレビューの場でこう聞かれた経験はありませんか。
「なぜこの言語を選んだの？」
「他の言語ではダメだったの？」
心当たりがあるなら、このままスクロールしてください（笑）
エンジニア的にはグサッとくる質問ですが、これは決して意地悪でも、あなたの技術力を疑っているわけでもありません。
聞いてる側が知りたいのはシンプルで、「その判断、ビジネスとして妥当なの？」 ということなんです。
最初に大前提をひとつ述べておくと、
プログラミング言語に、絶対的な優劣はありません。
あの言語はこの言語より劣っている、優れている――そういうことを言いたい記事ではないです。
ただ、どの言語にも 「選ばれる理由」 は必ず存在します。その理由を ちゃんと言語化 できるかどうか。それが今回のテーマです。
ちなみに筆者は今までのエンジニア人生で、このタイトルにあるような問いを何度もされてきました。そのたびに理由を並べたのですが、毎回どうにも納得いってない顔をされていました。
そしてある時、気づいたんです。
技術選定で本当に問われているのは、「一番モダンか」「一番速いか」ではなく、「なぜそれを選んだのかを、第三者にビジネス観点で説明できるか」 であるということを。
本記事では、技術的な正しさだけでなく、組織やビジネスの文脈で納得してもらえる技術選定 について整理していきます。
読み終えたときに、あなたが 「明日、上司に提案してみよう！」 という気持ちになってくれたら嬉しいです。
技術選定で"本当に"見られているポイント
技術選定というと、「性能」「モダンさ」「トレンド」に目が向きがちですよね。
もちろんそれらも大事です。でも、実際に意思決定者や上司が気にしているのは、もっと 現実的で、長期的な視点 だったりします。
例えばこんな問いを投げかけられたこと、ないでしょうか。
- 将来にわたって 採用・引き継ぎ ができるのか
- 数年後も 無理なく保守 ができるのか
- 仕様変更や組織変更に 耐えられる のか
- コストは本当に 見合っている のか
- 特定の人に 依存しない 構成か
筆者が個人的に開発現場を振り返ると、「キックオフの時は気にしてなかったけど、後からジワジワ効いてきたな…」と感じるものばかりです。
たとえば、学習コストが高い言語は立ち上がるまでに時間がかかります。最初は数人で回せていても、メンバーが増えた途端にオンボーディングが重荷になることもあります。
また、人材が限られる技術だと、誰か一人が抜けただけでプロジェクト全体が不安定になるリスクを抱えがちです。
こうして考えると、技術選定とは 「今この瞬間の最適解」を選ぶ行為ではなく、「数年後の自分たちにも同じ説明をして納得できる選択をする行為」 なんじゃないかと思っています。
「最近この言語人気だし、使ってみたいな〜」という理由で提案してしまうと、後悔することになるということですね。
言語が「選ばれ続ける」には理由がある
世の中には数多くの言語がありますが、長く現場で使われ続けている言語には共通した特徴があります。
- 学習しやすい — 新しいメンバーが早く戦力になれる
- 実装しやすい — やりたいことに集中できる
- 運用しやすい — 作ったあとも無理なく維持できる
他にも、「セキュアなしくみが作りやすい」「ハードウェアのパフォーマンスを発揮しやすい」などもあるかと思います。
流行り廃りが激しいこの業界で、それでも 生き残っている技術には「惰性」では説明できない強さがあります。
筆者はPHPの現場が一番長かったので少し一例を出すと、WordPressやEC-CUBE、MediaWiki（Wikipediaのフレームワーク）なんかはPHP製です。これらに共通しているのは、「作って終わり」ではなく、長くメンテされ続けている ということ。言語の寿命は、そこで作られたプロダクトの寿命にも直結します。
ただこれはPHPに限った話ではありません。Pythonの機械学習エコシステム、TypeScriptのフロントエンド基盤、Goのインフラ・クラウドネイティブ領域。それぞれの分野で「選ばれ続けている理由」が明確にあります。
大切なのは、自分が選ぼうとしている言語の 「選ばれ続けている理由」を、自分の言葉で説明できるかどうか です。
技術選定の4つの観点
ここからは、言語を問わず使える技術選定の観点を4つ紹介します。上司に「なんでこの言語なの？」と聞かれたとき、この4つの軸で答えられれば、大抵の場合は納得してもらえるはずです。
観点1: 人材の厚み - 属人化を防げるか
技術選定で見落とされがちなのが 「その言語を書ける人が、どれだけ市場にいるか」 という視点です。
エンジニア人口が多い言語は、新規採用・途中参加・引き継ぎの場面で選択肢を確保しやすいです。逆に言えば、ニッチな言語を選んだ時点で 「この人がいなくなったら回らない」 というリスクを抱えることになります。
例えば：
- Python — データサイエンスだけでなくWeb開発でも人口が多い。未経験からの学習者も多く、採用の裾野が広い
- TypeScript — フロントエンド開発者のほぼ共通言語になりつつある。JavaScript経験者からの移行もスムーズ
- Go — インフラ寄りのエンジニアを中心に人口が増加中。ただし業務系Web開発ではまだ層が薄い地域もある
「この言語が好きだから」ではなく、「チームとして開発を続けられるか」 という視点で選ぶ。地味ですが、これがプロジェクトを長く支える土台になります。
観点2: 目的との一致 - 遠回りしない技術か
言語にはそれぞれ 得意な領域 があります。
汎用的に何でもできる言語も増えてきましたが、「やりたいこと」に対して最短距離で到達できるかどうかは、生産性に大きく影響します。
「本当は業務ロジックを作りたいのに、環境構築と周辺設定で時間が溶けていく…」
こんな経験、ありませんか？
- Webアプリケーション を作るなら、HTTP・セッション・テンプレートと自然に結びついている言語が強い
- データ処理・分析基盤 なら、Pythonのエコシステム（pandas, numpy等）に敵う選択肢は少ない
- 高スループットなAPIサーバー なら、Goの並行処理モデルが威力を発揮する
- 型安全にフロントもバックも統一したい なら、TypeScriptという選択が現実的になる
「その言語は、自分たちのやりたいことに 特化しているか、少なくとも相性が良いか」。
これを説明できると、選定の説得力がグッと上がります。
観点3: エコシステムの成熟度 - 車輪の再発明をしないか
現代の開発で、フレームワークやライブラリの存在は無視できません。
認証・認可・バリデーション・メール送信・ジョブ管理・・・業務アプリケーションで必要になる機能が、最初から整った形で提供されているかどうか は生産性に直結します。
- Python ・・・ Django, FastAPI。特にDjangoは「バッテリー同梱」の思想で、管理画面からORMまで揃っている
- TypeScript ・・・ Next.js, NestJS。フロントからバックエンドまでTypeScriptで完結できるエコシステムが成熟してきた
- Go ・・・ 標準ライブラリが充実。フレームワークに頼らずとも書ける一方、業務系の「あれもこれも」は自前実装が必要になることも
ここで大事なのは、「速く作れること」だけではありません。
変更が前提の開発に、どれだけ耐えられるか。
フレームワークやエコシステムが成熟していると、仕様変更のたびに大改修するのではなく、少しの調整で済む。結果として、プロジェクトを躊躇なく前に進められます。
観点4: コストと運用の現実解 - 続けられるか
技術選定の最後のピースは トータルコスト です。
インフラ費用だけでなく、運用・障害対応・人件費を含めたROIで考える必要があります。
- 特別な実行環境が必要か
- シンプルなインフラ構成で動くか
- 小さく始めて、スケールできるか
「最初はコストを抑えて始められます。将来、大規模になっても対応できます」
これが言えるかどうかは、ビジネス側の意思決定において大きいと思っています。派手さはなくても、「無理なく続けられる」 という安心感は、長期運用を前提としたプロジェクトでは計り知れない価値になります。
「パフォーマンス大丈夫？」にどう答えるか
他の言語と比較される場面で、ほぼ確実に出てくるのがこの質問です。
確かに、CPU性能を最大限に引き出しやすい言語と、そうでない言語は存在します。
例えば、多くのWebアプリケーションで処理時間の大半を占めるのは：
- データベースアクセス
- 外部API通信
- ネットワークレイテンシー
言語そのものの実行速度差が問題になるケースは、実は限定的です。
もちろん、リアルタイム処理や大量の並行接続が前提のシステムであれば話は変わります。でも多くの業務システムやWebサービスでは、言語のベンチマーク差よりも、アーキテクチャやクエリの最適化のほうがよっぽど効きます。
大事なのは「この言語は速いか遅いか」ではなく、「今回の要件で、パフォーマンスがボトルネックになるか」 を冷静に見極めることです。
比較されたとき、どう説明するか
技術選定の場で「他の言語と比べてどうなの？」という質問は避けられません。
ここで大事なのは、技術論争に勝つことではなく、ビジネスとして最適な選択を説明すること です。
参考までに、よく比較に挙がる言語の特徴を整理してみます。
| 言語 | 強み | 選定時の注意点 |
|---|---|---|
| Python | 学習コスト低い、AI/データ領域と親和性高い | Webアプリの大規模運用ではアーキテクチャに工夫が必要 |
| Go | 高パフォーマンス、並行処理に強い | 業務系Webでは機能が素朴すぎて自前実装が増えがち |
| TypeScript | フロント・バックの統一、型安全 | エコシステムの変化が速く、依存管理に注意 |
| Rust | 安全性と性能を両立 | 学習コスト高め、人材確保の難易度が上がる |
（異論は受け付けます（笑）これはあくまで筆者の経験に基づく見解です）
どの言語にも長所と注意点があります。完璧な言語は存在しません。
だからこそ、「今回の前提条件では、どれが一番合っているのか」 を、相手の立場に立って説明できるかが勝負です。
上司に聞かれたらこう答えよう → そのまま使える説明テンプレート
ここまで読んで「なるほど、考え方はわかった。で、実際にどう言えばいいの？」と思った方のために、そのまま使えるテンプレートを置いておきます。
説明テンプレート（1〜2分で落ち着いて話せる量）
今回の開発では、性能やトレンドだけでなく、長期運用と組織へのフィットを重視して技術選定を行いました。
[選んだ言語] は [その言語の実績・シェア] があり、[具体的なプロダクト例] など長く運用されている実績も多い技術です。
エンジニア人口が多く採用や引き継ぎのリスクが低いこと、[言語の得意領域] に特化していて学習・実装・保守のバランスが良いことが選定理由です。
他の言語も検討しましたが、今回の要件では スピード・コスト・継続性 の観点で [選んだ言語] が最もリスクの低い選択だと判断しました。
使用例：Goを選んだ場合
上記の例で例えばGo言語を選んだ場合はこんな感じで説明するのはどうでしょうか。
今回の開発では、性能やトレンドだけでなく、長期運用と組織へのフィットを重視して技術選定を行いました。
Goは、KubernetesやDockerをはじめとするクラウドネイティブ領域で広く採用されており、長く運用されている実績も多い言語です。
言語仕様がシンプルでエンジニア間のコードのブレが少ないこと、高い並行処理性能を持ち今回のAPI基盤の要件と合致していることが選定理由です。
PythonやTypeScriptも検討しましたが、今回の要件ではスピード・コスト・継続性の観点でGoが最もリスクの低い選択だと判断しました。
ポイントは 「一番すごいから選んだ」ではなく「一番リスクが低いから選んだ」 という伝え方にすること。意思決定者が安心できるのは、後者の言い方です。
また上記のような説明がちゃんと出来た場合。
もし仮に意思決定者があなたの提案に対して否定的な意見を持った時でも、どこがその人の懸念事項（気にしてるポイント）で、どこが改善できたら承認までもっていけるのか、をすり合わせるのがぐっと楽になります。
一発OKが狙えなくても、2回目のトライ・修正が容易になるのです。
まとめ：技術選定は「未来の自分への説明責任」
これまでの話をまとめると、技術選定とは結論、「今一番すごいものを選ぶこと」ではなく、「あとから見ても納得して説明できる判断をすること」 です。
よく開発現場で「あの人、開発はまあできるけど、運用のこと考えてないよね」という声を聞くことがあります。お恥ずかしい話ですが、自分も言われたことがあります。今が良いだけではダメなんです。未来も見てどうなのかをジャッジして、提案できるようになりましょう。
そして、もしあなたが「流行っているから」「新しい技術に触れたいから」という理由で言語を選びたくなったとしたら（その気持ち自体は大事にしてほしいですが）それだけでは、上司は首を縦に振ってくれません。
本記事で紹介した4つの観点を使って、ビジネスとして妥当な理由 を添えてみてください。
- ✅ 人材の厚みがあり、属人化しにくいか
- ✅ 目的に対して遠回りしない技術か
- ✅ エコシステムが成熟しているか
- ✅ コストと運用の現実解があるか
この4つを押さえて説明すれば、どの言語を選んだとしても、自信を持って提案できるはずです。
さあ、次の開発プロジェクトでは胸を張って技術選定を提案しましょう。
注記
この記事はPHPerKaigi2026に私自身が寄稿したパンフレット記事を元にQiita用に再構成・アレンジしたものです。