Release:2025.11.05 Update:2025.11.05
「どの技術を選ぶか」は、開発組織にとって最も重要な意思決定の⼀つです。特に組織⽴ち上げ期において、この選択は数年〜10年先のDX（Development Experience, 開発体験)やチームの成⻑速度を左右します。
本記事では、ヤマシタの技術責任者の中川が、なぜこの技術スタックを選んだのか、その理由と背景をお話しします。
【開発体制】
正社員：約20名
業務委託：約10名
ユーザー規模：現在最⼤で約2,000名（社内サービス中⼼）
今後、社員数増加および社外向けサービス展開を予定
■技術選定の基本⽅針：「メンテナンス性」を最重視
技術選定において最も重視したのはメンテナンス性です。これを分解すると、以下の要素になります：
・学習コストの低さ：新しいメンバーがすぐにキャッチアップできるか
・人財採⽤のしやすさ：その技術を使える/使えるようにすぐになりそうな⼈材が労働市場にいるか
・サポートの継続性：コミュニティやエコシステムが健全か
・軽量性：過度に複雑でないか、開発者体験としてスムーズに動くか
・捨てやすさ（⼊れ替えやすさ）：数年後にトレンドが変わったとき、移⾏できるか
特に「捨てやすさ」は⾒落とされがちですが、重要な観点です。技術トレンドは数年で変わります。依存性を最⼩限にし、必要に応じて部分的に⼊れ替えられる設計を⼼がけています。
■バックエンド：Go + chi + OpenAPI
・なぜGoなのか？
バックエンド⾔語としてGoを選んだ理由は、シンプルさに尽きます。
Goは⾔語仕様がシンプルで、学習コストが低いと考えています。そのため、新規参⼊者のJoinハードルを下げられます。
私たちの採⽤ターゲットは、スタートアップやITベンチャーで活躍するソフトウェアエンジニア層です。これらの企業ではGoがバックエンド⾔語として広く採⽤されており、経験者を⾒つけやすくなります。よって、新規エンジニアの採⽤ハードルを下げられます。
仮にNode.jsなどの経験が中⼼のエンジニアでも、Goは学習コストが低いため、Joinして短期間で戦⼒化できます。
これは既存社員にとっても同様で、数年ぶりにSWEとして復帰する⽅、開発経験のほとんどが別の⾔語だった⽅やフロントエンド開発が中⼼のエンジニアがバックエンドに触れる際のハードルも下がります。
・なぜchiなのか？
ルーティングフレームワークとしてchiを選んだ理由は⼤きく2つあります。
1つ⽬は捨てやすさ。chiは依存性が最⼩限で、標準ライブラリの net/http の思想に近い設計です。数年後に別のルーターが覇権を握った場合でも、移⾏が⽐較的容易です。
2つ⽬はモジュール化のしやすさ。chiの r.Route 、 r.Group 、 r.Mount といったルーティング表現により、機能単位でモジュール化しやすい構造を作れます。これにより、過度にマイクロサービス化せず、モジュラモノリスでも開発を進められます。エンジニアリソースが潤沢でない当社にとって、これは⼤きなメリットです。
・OpenAPIの採⽤
OpenAPIの採⽤により、フロントエンドが中⼼のエンジニアがエンドポイント定義のPRを上げるといった、職域を超えた協働がしやすくなりました。また、API定義からのコード⾃動⽣成も⼤きなメリットです。
組織⽴ち上げ期だったこともあり、誰もが触ったことのあるREST APIを採⽤したため、⾃然とOpenAPIを活⽤する流れにもなりました。
■フロントエンド：Next.js と Nuxt.js の使い分け
フロントエンドでは、Next.js（React）とNuxt.js（Vue）を⽤途に応じて使い分けています。
・⼤規模‧基幹系 → Next.js
2025年現在、React/Next.jsは事実上の業界標準に近い位置にあります。また、 Next.jsは柔軟性が⾼く、機能が多く⼤規模構成になりやすい基幹系システムに適しています。
・⼩規模‧周辺系 → Nuxt.js
⼀⽅、Vue/Nuxt.jsには学習コストの低さとエコシステム内での迷いにくさというメリットがあります。基幹周辺の⼩規模システムでは、こちらの利点が活きます。
・TypeScriptは全⾯採⽤
両フレームワークともTypeScriptで記述しています。型推論による開発体験の向上はもちろん、昨今は素のJavaScriptよりもTypeScriptを使うケースが主流になっているため、これも採⽤ハードルを下げる要因になっています。
■モバイル：現在はSwift、将来的にクロスプラットフォームを検討
モバイルアプリについて、正直にお話しします。図には3つの技術が載っていますが、現在実際に使っているのはSwiftのみです。
社⽤携帯がiPhoneのため、社⽤アプリケーション開発は⾃ずとiOS開発になり、Swiftで開発しています。
ただし、今後利⽤者様やそのご家族向けのアプリを作る際は、iOS/Android両対応が必須になります。その場合、React NativeまたはFlutterの採⽤を検討しています。
どちらを選ぶかはまだ決めていませんが、以下の観点で判断する予定です；
・OSのネイティブAPIをどこまで深く使うか
・レンダリング仕様の違いによるOS update への追従性
■インフラ/DevOps：Datadogを中⼼とした可視化
・Datadogの採⽤理由
APM（Application Performance Monitoring）としてDatadogを採⽤しています。採⽤のポイントは3つ：
1.リクエストから横串で可視性が⾼い：問題の切り分けがしやすい
2.慣れているメンバーが多かった：少しエンジニア採⽤が進んだタイミングで導⼊
3.すべてを⼀箇所で可視化できる便利さ：導⼊のしやすさも含めて
「ベンダーロックインになるのでは？」という懸念はありますが、監視ツールはどれを選んでも性質の違いはあれどロックイン⾃体に⼤差はないと考えています。また「コストが⾼い」というデメリットもありますが、基幹系システムのダウンは業務ストップを意味します。過度にコストを気にする部分ではないと判断しました。
・Vercelは限定的に使⽤
実はVercelは本番環境では使っていません。v0などを使って⾼速にモックを作り、ステークホルダーに触ってもらうといった、プロトタイピング⽤途で限定的に活⽤しています。
■まとめ：技術選定は「⼈」を中⼼に
技術スタックを振り返ると、すべてに共通しているのは「⼈を中⼼に考えた選定」だということです。
・学習コストが低く、新しいメンバーがJoinしやすいか
・労働市場で人財を採⽤しやすいか
・チームが成⻑しても持続可能か
・必要に応じて⼊れ替えられるか
技術は⽬的ではなく⼿段です。どんなに優れた技術でも、チームが使いこなせなければ意味がありません。
私たちは今後も、この「メンテナンス性」という軸を⼤切にしながら、技術スタックを進化させていきます。
執筆者プロフィール：技術責任者 中川卓⺒
2024年4⽉に⼊社し、ヤマシタの開発組織⽴ち上げを担当。モジュラモノリスとメンテナンス性を重視した開発体制構築を推進。
募集職種一覧
