背景
メガベンチャーでエンジニアをしています。
弊社では社内標準言語としてTypeScriptが指定されており、原則としてすべてのプロジェクトでTSを使用することになっています。
TSを標準とするメリット（型安全性、人材流動性、ナレッジ共有など）は理解しています。
一方で、以下のような疑問も感じています。
- パフォーマンスなどが重要な場面ではGoやRustの方が適しているのでは？
- MVPをスピード感を持って実装したい場合なども、TSに限らず最適なBaaSなどを選ぶべきでは？
- 優秀なエンジニアほど「技術選定の自由がない」ことに不満を持つのでは？
質問・意見交換したいこと
皆さんの会社では社内標準言語は設定されていますか？
設定されている場合、例外はどのように扱っていますか？
「標準言語を設定すべき／すべきでない」について、ご意見をお聞かせください
自分の現時点での考え
完全に自由にすると技術スタックが乱立してカオスになる一方、厳しすぎるとスピード感が失われる気がしています。
また、自分の所属するようなメガベンチャーでは、スピード感や最新技術の導入による差別化はとても重要だと感じており、どんな会社かによるところはあるとは思っています。
個人的には、基本的に「インフラ・セキュリティ層は厳格に、アプリケーション層は推奨レベルで」くらいが落とし所かなと思っていますが、他社の事例や皆さんの考えをお聞きしたいです。
回答7件
#1
総合スコア118268
投稿2025/12/01 03:58
会社が小さいうちは社内統一はありかもしれませんが、基本的にはプロジェクト別でしょうね。
案件ごとに発注者の意向も違うでしょうしライブラリの利用についての制限もあります。上位互換を含めメンテナンスをどの期間補償する契約があるかによって安易に環境を変更できない場合もあります。
プロジェクトごとに開発環境のバージョン管理責任者を任命して個人がプロジェクトルールを逸脱しないようチェックも必要でしょう。またもっと効率的な手法があるというのであれば個人からの提案は会社の技術部門（おもに情シス）にボトムアップで集約できるようにして、定期的に検証するようにしてもらえば会社全体のスキルアップやナレッジにつながります。
ただし個人がいくら「この環境でやりたい」と主張しても根拠のないワガママとして却下されるので、プロジェクトの主要メンバーになるまではなかなか提案も通らないでしょう。
#2
総合スコア86505
投稿2025/12/12 15:36
会社全体で標準言語を決めるのは、一種類の事業しかしていないような企業くらいかと思いますが、事業単位や部署単位で定める場合も含めて考えるということなのでしょうね。
「標準言語を設定すべき／すべきでない」について、ご意見をお聞かせください
定めることのメリットが大きければ定めればいいし、デメリットが大きければ定めない方がいいという当たり前の結論かと思います。
(A) 標準言語を定める。例外を認めるプロセスは定めない
(B) 標準言語を定めるが、例外として他の言語を使うことを認めるプロセスは定めておく
(C) 標準言語を定めていないが、社内有識者人口や社内採用事例数、ツールの整備状況、社内作成のライブラリ充実度などから、「（対象分野ごとに）特に理由がなければこれだろう」と多くの人が思う言語やフレームワークがある
(D) 標準言語を定めておらず、毎回担当者が自由に決めていいし、実際バラバラである
と、ケースを分けてみると、4ケースのメリット・デメリットを挙げるのが面倒なので、AIに聞いてみると割とそれらしい回答がありました。意外なものは特に挙がらず。
これらメリット・デメリットと、組織の人員構成、採用や育成の方針、新規事業方針、プロジェクト数、プロジェクト規模、開発スピード、稼働年数（作ったシステムの寿命予想）などを考慮の上で考えるのでしょう。例えば広い視野で物を考えることが出来る人が少ない場合は(C)(D)は厳しいとか。
設定されている場合、例外はどのように扱っていますか？
標準言語を定める場合、「例外は絶対に認めない」はありえないでしょうね。
例外許可プロセスを定めるとすると、「”これこれの理由でこの言語の方が適しているので～～”というのをｘｘ会議に掛けて承認を得る」とか、もっと簡易に「部長が良いといえばＯＫ」とか。
例外が多いと、「標準言語を定めることによるメリット」が弱まってしまうので、そこを何らかのカバーすることが必要なのかどうかとかも例外許可検討時の考慮事項でしょう。
#4
yambejp さん
ご回答ありがとうございます！
技術選定の話だけでなく、組織的な仕組み（バージョン管理責任者の任命や、ボトムアップでの提案フローなど）についてもご教授いただき、大変参考になりました。
確かに、「プロジェクト別」という視点は重要ですね。発注者の意向やメンテナンス契約期間など、技術的な最適解だけでは決められない要素があるというのは、自分の視野が狭かったなと感じました。
弊社でも提案を集約・検証するような仕組みがあるのか、あるとすればどの程度機能しているのか、一度調べてみようと思います。もしかすると、自分が知らないだけで既にそういったチャネルがあるかもしれませんし、なければ提案してみる価値もありそうです。
プロジェクトの主要メンバーになるまではなかなか提案も通らないでしょう
ここも耳が痛いですが、おっしゃる通りですね…。まずは目の前のプロジェクトで信頼を積み上げていくことが先だと改めて思いました。
#6
総合スコア86505
投稿2025/12/19 11:41
もう少し頑張るとすると、「標準言語を定めていることが、全体の生産性にちゃんと寄与しているのか？」を定期的に見直すプロセスを定義してそれを実行するとかですね。
例えば、測りやすい尺度では、「半年(or1年)単位で、その期間の新規プロジェクトでの標準言語採用率」が、年とともに低下しているようであれば、①例外承認が甘い、②標準言語が時代に合わなくなっている のどちらかの可能性が高いので、調査して①なら例外承認基準の見直し、②なら標準言語の変更 などの対処を行うとか。
測りにくい尺度だと、「標準言語を定めることで成し遂げようとしたことが、ちゃんと達成できているか」とか。
#7
総合スコア210
投稿2025/12/23 12:12
特に理由なければこれ使ってねぐらいがいいですね...
事業から求めたれていることや非機能要件によって解が集約する場合があり、その時に「社内標準にして」の返答で落ち着いちゃうと、なんのための技術なんだろうって思っちゃいそうです。
ただ、「AでもBでもできるよね！なら社内標準のAにしよ！」ぐらいで決めれる判断軸として機能できてればいいなです！
そういう技術を社内標準にしてほしいみたいな気持ちもあります。
あなたの回答
tips
プレビュー