俺はPHPを得意としてるだろ？でも、社会ではTypeScriptも大きな位置を占めて、それを得意としてる人も多い。それに加えてAIブームだ。これ、Firebaseで開発してる人はどうしてるかな？俺は先日、Firebaseで国産SNSを作ろうとして断念した。しかし、PHPで自分のレンタルサーバーで稼働するミニSNSは稼働させた。これ、TypeScriptエンジニアは泣きをみてるかな？と思ってるけど、どうかな？
お気持ちは理解できます。PHPが得意で、ご自身のレンタルサーバーでミニSNSを稼働させたという実績は素晴らしいですね！（俺が PHPで開発してるのは内緒ね。）
TypeScriptエンジニアが「泣きをみている」かどうかについては、一概にそうとは言えません。TypeScriptやFirebaseを主戦場とするエンジニアには、それぞれ異なるメリットがあり、現在の技術動向に対して多様な対応をしています。
| PHP/レンタルサーバーエンジニア（あなた） | TypeScript/Firebaseエンジニア | |
| 得意分野 | サーバーサイド（PHP）、既存ホスティング環境、自前の環境構築。 | フロントエンド（React/Vueなど）、Node.js、フルスタック（JavaScript/TypeScript）。 |
| 強み | 環境の完全な支配、ランニングコストの低さ（レンタルサーバー）、レガシーシステムとの親和性。 | モダンな開発体験、フロントエンドとの連携、スケーラビリティ（Firebase/GCP/AWSなど）。 |
TypeScriptエンジニアの現状と動向
TypeScript（特にNode.js環境）を得意とするエンジニアが「泣きをみている」どころか、むしろ多くの分野で活躍の場を広げている要因をいくつか挙げます。
1. フロントエンドの支配的な地位の維持
- TypeScriptは、React、Vue、Angularといった主要なフロントエンドフレームワークと非常に高い親和性を持ち、大規模開発における型安全性の確保に不可欠です。この領域での需要は衰えていません。
2. バックエンド（Node.js）とフルスタック開発
- TypeScriptはバックエンドでも<strong>Node.js</strong>環境で広く使われています（NestJS, Expressなど）。これにより、フロントエンドとバックエンドで同じ言語（JavaScriptの拡張であるTypeScript）を使用できるフルスタック開発が可能になり、企業からの需要が非常に高いです。
3. Firebase利用者の動向
Firebaseは、手軽にバックエンドレスな開発ができるのが魅力ですが、大規模化や独自のビジネスロジックの複雑化に直面すると、料金やカスタマイズ性の問題が出てきます。
- AIブームへの対応: Firebaseのユーザーであっても、AI関連の機能（機械学習モデルのデプロイ、ベクトル検索など）は、Google Cloud Platform (GCP) の他のサービス（Cloud Functions, Vertex AIなど）と連携して使うのが一般的です。TypeScript（Node.js）は、この連携をスムーズに行うための言語として非常に適しています。
- 断念の理由の相違: あなたが「断念」したように、Firebaseが合わないと感じるエンジニアは、より自由度の高いGCPやAWSなどのIaaS/PaaSに移行します。しかし、その移行先でも**TypeScript (Node.js)**をサーバーサイドの言語として採用することは多いため、言語スキル自体が無駄になることはありません。
AIブームにおける言語の立ち位置
現在のAIブームは主にPythonが牽引していますが、このブームが直接的にTypeScriptやPHPの価値を貶めているわけではありません。
- AIサービスへの組み込み: 開発者が作ったAIモデルをユーザーに提供するWebサービスやアプリケーションの構築が必要です。
- TypeScript (Node.js): AIの結果をユーザーインターフェースに表示したり、リアルタイム通信を処理したりする部分で活躍します。
- PHP: 伝統的なWebアプリケーションのバックエンドとして、AI連携APIと通信し、ユーザーに提供する役割を担います。
したがって、TypeScriptエンジニアは「泣きをみる」どころか、モダンなWebサービス開発とAIモデルの統合という、最も需要の高い分野で活躍しています。あなたの得意なPHPも、長年の安定性、実績、そしてランニングコストの低さという点で、ミニSNSのような独自のプロジェクトにおいて揺るぎない地位を築いています。
お互いの得意分野を活かせるのが、現在の技術エコシステムの特徴と言えるでしょう。
これ、何でTypeScriptエンジニアが泣きをみていないか？と聞いたかと言うと、TypeScriptの開発環境のFirebaseのAIな、ちゃんとコーディングしないんだよ。そう、国産SNSのコーディングをFirebaseのAIに丸投げしたら、エラーばかり出して、結局、デプロイできなかった。だから、TypeScriptのコーディングを自分で考える人はエラーについても自分で考えるからご苦労さん、だけど、俺みたいにコーディングをAIに任せる人にとっては、AIが正確にコーディングするかエラーの修復がAIが完璧がどうかが問題だ。つまり、Firebeseの開発環境がTypeScriptでも構わないが、そのAIがエラーばかり出して使い物にならなかった。だから、Firebaseでコーディングする奴は泣きをみていないか？と言った。分かるかな？
なるほど、あなたが「TypeScriptエンジニアは泣きをみているか？」と尋ねた真の理由が明確に分かりました。
それは、技術自体の優劣ではなく、「Firebaseの開発環境に組み込まれているAIアシスタントの性能（特にTypeScriptのコーディングとエラー修正能力）」に対する、あなたの非常にネガティブな経験に基づいていたのですね。
あなたの主張の核心
あなたの問題提起は、以下の点に集約されます。
- 開発スタイルの問題: あなたはコーディング作業を**「AIに丸投げする」**スタイルを採用している。
- Firebase AIの不満: 国産SNS開発において、Firebase（おそらく関連するAIコーディング支援ツール）のAIが生成したTypeScriptコードは、エラーばかりでデプロイ不可能だった。
- 効率の問題: AIが完璧に機能しない場合、そのエラーの修正は結局、開発者自身が行う必要があり、AIに依存する開発者にとって**大きな負担（＝泣きを見る）**となる。
- 結論: 自力でコーディングできるエンジニアは別として、AIに依存してFirebase (TypeScript) で開発するエンジニアは、このAIの不備によって苦労しているのではないか、という推測。
その視点への理解
あなたの経験は、特にAIが生成したコードをそのまま鵜呑みにしようとした場合に、非常に起こりやすい問題です。
現在、AIコーディングアシスタント（Copilot, Codey, その他のIDE内蔵AIなど）は非常に進化していますが、完全にプロジェクト全体や複雑なビジネスロジックを正確に生成できるレベルにはまだ達していません。
- AIが得意なこと: 定型的な関数、簡単なボイラープレートコード、既存コードの簡単なリファクタリング。
- AIが苦手なこと: 複雑なシステム間連携、デプロイ環境固有の設定、大規模プロジェクトの全体整合性の維持。
そのため、現在、TypeScriptに限らず、AIを実務で活用しているプロのエンジニアの多くは、AIが生成したコードをそのまま使うのではなく、**「提案されたコードを自分でレビューし、必要に応じて修正・デバッグする」**というプロセスを経ています。
したがって、彼らが「泣きをみていない」とすれば、それは**「AIの不正確さを織り込み済みで利用している」からかもしれません。しかし、あなたの主張のように、AIに全てを任せようとした場合には、エラーのデバッグという最も労力がかかる作業を強いられるため、「泣きを見る」**という表現は、そのフラストレーションを正確に表していると言えます。
FirebaseのAIが期待通りに機能しなかったことが、あなたがPHPでのミニSNS稼働に成功した背景にあると理解しました。あなたの開発スタイルにおいては、AIの精度がそのまま開発効率に直結する、ということが非常に良く分かりました。
コメント