"サービスチーム" での技術選定 / Making Technology Decisions for the Service Team

2025/06/25
プロダクト成長を支える技術選定と開発文化 〜現場の知見LT大会〜
https://canly.connpass.com/event/357205/

"サービスチーム" での技術選定

内田 淳博
ソフトウェアエンジニア

Transcript

1. “サービスチーム ”での技術選定 2025.06.25 バランスを意識した判断と現場への価値提供
2. • 大学院で深層学習（AI）の研究 • freee に SWE として新卒入社 • 2023 年にカミナシ入社 • カミナシでは「カミナシ従業員」の立ち 上げメンバーとして最初から開発 • AWS Community Builder • 今日は技術選定の話 + コンテキスト補足 自己紹介： 内田淳博 / a2 カミナシで初めて “サービスチーム” という言葉を知る @A2hiro_tim
3. カミナシのサービスチームとはサービスに対して “オーナーシップ” を持つチーム 価値提供のために必要な技術選定から採用まで全てチーム内で考える 採用 技術選定 開発 インフラ構 築 課題探索/ 特定/定義 要件定義 デザイン UX設計 サービス
4. なので今日は、 「カミナシ」ではなく 「カミナシ従業員」の技術選定
5. 技術選定の基本方針 置きにいくところとチャレンジするところのバランス 枯れた / 慣れた 技術 👍 学習が不要で早い・安定 ❌ 学びがない・中長期の採用リスク 知らない / 新しい 技術 👍 過去の課題を解決した技術 ❌ メンテされなくなるリスク・未発見の課題
6. 技術選定の基本方針 置きにいくところとチャレンジするところのバランス 枯れた / 慣れた 技術 知らない / 新しい 技術 事業の不確実性 会社・チームの状況
7. カミナシ従業員サービスの技術スタック 既存カミナシの技術スタックを考慮し、言語や DBは他チームと同じものを選定しています。 フレームワークやライブラリ等に関しては、開発体験・効率が高くなるような技術選定をしています。 7 プログラミング言語 フロントエンド・モバイル API定義 データベース コード管理・実行環境・ SaaS モニタリング GO TypeScript React PWA Next.js Remix MySQL Datadog GitHub Terraform PostgreSQL Sentry Docker SendGrid
8. カミナシ従業員サービスの置きにいくインフラ構成 (内製認証基盤)
9. カミナシ従業員の Application 技術選定 Application 技術選定 9 API定義 GO バックエンド フロントエンド（管理画面） TypeScript TypeScript React React PWA Ogen Orval TanStack Query/Router TanStack Query/Router go-chi 若いライブラリの一例 フロントエンド（従業員・モバイル画面）
10. OpenAPIのスキーマからのコード生成に新しいライブラリを採用 • Controller 部分のみのコード生成なので、困った時に後から置き換え可能なレイヤー • OAPI v2 では Swagger が使えたが、OAPI v3 に対応していない • Go の型をつけてくれるコード生成ライブラリは他になかった ◦ → 型がスケール時に大きな違いを生む OAPIv3 対応で型がつく Go のスキーマ生成ライブラリ “Ogen” の採用 →スキーマ駆動で開発を進められている
11. Ogen HTTP Status ごとの関数が生成される parameter に型がついている
12. フロントエンドは SSR か SPA か • 選定をしたのが2023年の8月頃 • AWS からSSRデプロイの十分なサポートがなかったため、インフラに工夫が必要だった • 開発者が 2人 + クラウドインフラ1人 の状況で、SSR の採用は見送った — • その後、AWS からサポートが発表（時すでに遅し） 当時のデプロイ周りの整備状況を考えて硬く SPA を選択
13. 未来はわからない • 半年ずれていたらNext.jsを選んでいた可能性もある • それでもベンダーロックインを考慮して SPA を選んでいた可能性もある • 技術選定のタイミングでは、「いつか来る」ことはわかっていても、「いつ来るか」までは不明 • 大事なのは、その段階で見えている情報、織り込める未来の不確実性を踏まえて選択して、その決 定にオーナーシップを持つこと（＝ここでは、自分で自分の ”ケツを拭く” こと） 今時点でのベストな選択が半年後にはベストではない可能性は十分にある
14. 最初の想定通りにはいかないこと、予想外も起こる PWA 上で複数プロダクトにログインした状態にさせるので、 ログイン状態の保持やサービス権限管理（セッション管理）どうしよ う？？ PWA に他のチームのクライアントも相乗りすることになった カミナシ従業員 カミナシ教育 before after
15. 他プロダクトにもアクセスできるようにしたい カミナシ教育 カミナシ 従業員
16. α案： PWA 上で二つのセッションを管理 他プロダクトにもアクセスできるようにしたい カミナシ教育 カミナシ 従業員 β案：BFF を立ててクラ イアントは単一セッショ ンで複数のプロダクト を叩く
17. β案の場合 リクエストの流れ β案：BFF を立ててクラ イアントは単一セッショ ンで複数のプロダクト を叩く BFF BFF はどのチーム が管理するんだろ う...
18. α案： PWA 上で二つのセッションを管理 α案を選択 カミナシ教育 カミナシ 従業員 こちらを選択
19. フロントエンドで複数のセッションを管理する決定 • モバイル専用の BFF を置いて routing するパターン（β）も考えたが、BFF のオーナーシップが浮 いてしまう • 会社として複数の新規プロダクトを並行で走らせていて、今後も相乗りするプロダクトは増える可 能性が高い • 「隣のチームとの優先度調整がうまくいかず、お客さんへの価値提供が遅れます」が起きにくいの がサービスチームの強み • 最低限の手間で相乗りを実現 サービスチームができるだけ独立するような意思決定
20. エンジニアとしての面白さ 複数新規プロダクトが同時に立ち上がって同時に走っている環境 • それぞれサービスチームとしてオーナーシップを持つので物事が素早く進んでいく • エンジニアがお客さんの現場を訪問して一次情報を取得するカルチャー • 複数プロダクトが絡むなかで如何に物事を仕組みで解決するか • ドキュメントをしっかり書いて運用まで見据える開発文化
21. 他にも、エンジニアとしての面白さ プロダクトを通して価値を届けたいエンジニアに最高の環境 カミナシはフルスタックな開発をしていますが、要素を分解すると、 • 複数の新規プロダクトが同時に立ち上がって同時に走っている環境は珍しい ◦ バックエンド・インフラが好きなエンジニアにとってはキャリアに箔がつく • フロントエンドは複数プロダクトが絡むなかで如何に物事を仕組みで解決するかが大事 • サービスの価値を継続的に届けていくために、ドキュメントもしっかり書いています ◦ ADR は 50 以上
22. 特徴的な現場訪問という文化 • ディスカバリー・デリバリーのフェーズ問わず、エンジニアもお客さんを訪問できる • 現場ドリブン = 究極の顧客ドリブン • 一次情報を取得することで解像度が圧倒的に上がる • お客さんとの関係が良好だからこそできること 実際にプロダクトを使ってもらっている “現場” を見にいく
23. 今後何をやっていくの？ 足元が落ち着いて機能追加と拡張に全振りしていく • 機能としては本当に0→1が終わったぐらいの段階 • 新しい機能追加 • 初期はエンジニア 2 人で開発したりしていたが、今は開発者 4(+2) 人で、しっかりした基盤の上 で高速に機能を追加していっている段階
24. 今回割愛した話は他の媒体でも発信しています インタビュー記事 Podcast 技術ブログ
25. カミナシ従業員（他のチームも）採用中です！
26. https://kaminashi.jp 株式会社カミナシ