採用面接での説明量を減らして、採用面接で互いの質疑応答の分量を増やそうとか、面接後でもこの辺の情報にアクセスしやすくしようという事で作ってみる記事。

とは言えAI普及期の現在、コロコロ新しいの出てくると思うし、とりあえず今（2026.03.16）の前提で、ガバっとね。

バックエンド

言語：Kotlin, Java, Go, Python, Ruby
フレームワーク：SpringBoot, Gin,GORM, FastAPI,

こんな感じ。

≪解説≫

もともとはJavaの会社だったのですが、サーバサイドKotlinとGo言語の比率が増えて行った感じ。特に大手SI経由（BAMVが2次）のプロジェクトでこの辺が多いです。
パターンとしては、（SIerがプライムに立つ必要がある）そこそこの規模のあるシステムなので、それなりの実行速度、コンパイル言語、静的型付け言語、強力な広報互換性などが重視されてのチョイスと言う事ではないかなあ。

逆に自分たちがエンド直接の場合は、BAMVの規模的にも小規模チームが前提になる為、小規模なシステム開発という事になります。PoC要素の強いものが多く、言語ではPythonなどの登場頻度が高くなります。最近は業務側からシステムを介してデータを取ってきてローカルAIに渡すなどの処理も増えていますので、今後はPythonの出番がさらに増えて行くのかな...？

≪Javaやってりゃなんでもできるやろ≫理論に基づき、なんでもやらされます。

フロントエンド

言語：JavaScript, TypeScript
フレームワーク：React, Vue

≪解説≫
言語はほぼTypeScript　React系とVue系の登場頻度は半々くらいかな....？　どうも他社と比べ、フロントエンドの実装経験があるメンバーの比率がかなり高いようです。
原因のひとつは、『BAMVさん、フロントとバックどっちがいいスか？』とクライアントに聞かれたときに、『どっちでもいいスよ』と答えていたことと思われ。他社さんのチームは基本的にバックエンドを希望されることが多いのですな。　もう一つは、そんなに大きなシステムではないので、BAMVでフロント・バックどちらも担当することなるから。という感じ。

DB

MySQL, PostgreSQL, MariaDB, Redis, MongoDB　などなど

≪解説≫
もう特徴としては、『OracleDBが無い』ことかなと。なんかしばらく見ていない。
これはシステムの規模の影響ですかねえ。　社内にPL/SQLの経験者がほぼいません。　やってできるとは思いますが、長大なストアドなんか見た日には、ＰＣの前で固まったりせんやろか。

Server

AWS, GCP

≪解説≫
ウチに入社してもオンプレ経験はできませぬ...。　アジャイル担いでるせいですかね。
ほか、お気づきかもですが、マイクロソフト系の技術はほとんど登場しません。Azureの登場頻度もかなり低いです。

その他

Kafka, gRPC, Kubernetes ,Memcached,HBase などなど

≪解説≫
ここまでの技術の組み合わせでイメージできてしまうかもですが、モノリスのシステムを好んで作るという事はほとんどないです。（たぶん、ウチよりももう少し小さい受注規模では増えるんじゃないかな感）マイクロサービス的に疎結合に設計されたアプリがコンテナの上に乗っかる形のものがほとんどで、規模があるシステムの場合はKubernetes等のオーケストレーションツールが登場してきます。SIが登場する様な近年の新規システム開発では、だいたいそんな感じのが多いのではないでしょうか。

今後の技術的な方針

まあ、ふつう？　
新規開発が多いとこうなる的なものを集めると、どの会社さんでもこういう感じになる気がしますね。

逆に言えば、昔ながらの大規模レガシーシステムの運用保守の話などが皆無な訳ですので、AIエージェントが入ってくるのは早いです。
業界全体の中でも、真っ先に競争に突入していく領域であるともいえます。

競争突入が早いのは厄介ですが、会社組織の仕組みや個人の経験の面で言えば早めにAIエージェント時代に対応したほうが良いのは間違い無く、競争を避けるよりはガンガン参入して幾でよいと思います。

アーキテクチャ思想的な面ではほとんどコダワリは無く、【用途に合ったものを使えばいい】程度です。　DDDや、オニオンアーキ・クリーンアーキ、会社としてはいろいろ経験してきておりますが、特段【これ推し！】とかのものは無いです。　プロジェクトのアーキの人が『これでいく』というのがあれば、それに合わせるくらいですかな。
今後、AIエージェント前提での開発の在り方などが議論されていくかと思いますので、その中で推しができたりはするかもしれません。