Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
スタートアップを支える技術戦略と組織づくり
Search
pospome
November 20, 2025
Programming
8
18k
スタートアップを支える技術戦略と組織づくり
"アーキテクチャカンファレンス 2025" の登壇資料です。
https://architecture-con.findy-tools.io/2025
pospome
November 20, 2025
Tweet
Share
More Decks by pospome
See All by pospome
生成AIを利用するだけでなく、投資できる組織へ
pospome
2
440
技術好きなエンジニアが "リーダーへの進化" によって得たものと失ったもの
pospome
5
1.6k
DMMプラットフォームにおけるTiDBの導入から運用まで
pospome
8
4.8k
DMMプラットフォームがTiDB Cloudを採用した背景
pospome
10
6k
DDDはなぜ難しいのか / 良いコードの定義と設計能力の壁
pospome
44
21k
マイクロサービス環境におけるDB戦略 in DMMプラットフォーム
pospome
12
4.7k
組織全体で開発生産性に取り組むために 専門チームを作った話
pospome
2
2.1k
DMMプラットフォームにおける GKE を利用した プラットフォームエンジニアリングへの 取り組み
pospome
1
900
DMMプラットフォームにおけるコード品質を改善する取り組みの理想と現実
pospome
3
2.9k
Other Decks in Programming
See All in Programming
例外処理とどう使い分ける?Result型を使ったエラー設計 #burikaigi
kajitack
16
5.1k
クラウドに依存しないS3を使った開発術
simesaba80
0
220
SQL Server 2025 LT
odashinsuke
0
140
AI Agent Dojo #4: watsonx Orchestrate ADK体験
oniak3ibm
PRO
0
130
0→1 フロントエンド開発 Tips🚀 #レバテックMeetup
bengo4com
0
480
AIによるイベントストーミング図からのコード生成 / AI-powered code generation from Event Storming diagrams
nrslib
2
1.2k
TestingOsaka6_Ozono
o3
0
270
Combinatorial Interview Problems with Backtracking Solutions - From Imperative Procedural Programming to Declarative Functional Programming - Part 2
philipschwarz
PRO
0
140
実は歴史的なアップデートだと思う AWS Interconnect - multicloud
maroon1st
0
310
脳の「省エネモード」をデバッグする ~System 1(直感)と System 2(論理)の切り替え~
panda728
PRO
0
130
AI Agent の開発と運用を支える Durable Execution #AgentsInProd
izumin5210
7
1.2k
DevFest Android in Korea 2025 - 개발자 커뮤니티를 통해 얻는 가치
wisemuji
0
180
Featured
See All Featured
A brief & incomplete history of UX Design for the World Wide Web: 1989–2019
jct
1
270
The Mindset for Success: Future Career Progression
greggifford
PRO
0
210
Leveraging Curiosity to Care for An Aging Population
cassininazir
1
140
How Fast Is Fast Enough? [PerfNow 2025]
tammyeverts
3
420
The Straight Up "How To Draw Better" Workshop
denniskardys
239
140k
How to Build an AI Search Optimization Roadmap - Criteria and Steps to Take #SEOIRL
aleyda
1
1.8k
Statistics for Hackers
jakevdp
799
230k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
32
2.8k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
34
2.6k
SEO Brein meetup: CTRL+C is not how to scale international SEO
lindahogenes
0
2.3k
Winning Ecommerce Organic Search in an AI Era - #searchnstuff2025
aleyda
0
1.8k
Efficient Content Optimization with Google Search Console & Apps Script
katarinadahlin
PRO
0
280
Transcript
スタートアップを支える技術戦略と組織づくり @pospome
自己紹介 • 名前:pospome(ぽすぽめ) • 所属:株式会社カミナシ • 職種:VPoE • Xのアカウント:@pospome 2
社名だけでも 覚えて帰ってください
アーキテクチャは技術要素だけで最適解は決まらない 3
アジェンダ 4 • カミナシのエンジニアリング文化 • エンジニア組織について • サービスチームというバーチャルチーム • エンジニアのスキルセット
• 技術的な意思決定について • システムアーキテクチャ • エンジニアリング組織の採用方針について • メガベンチャーとの違い
アジェンダ 5 • カミナシのエンジニアリング文化 • エンジニア組織について • サービスチームというバーチャルチーム • エンジニアのスキルセット
• 技術的な意思決定について • システムアーキテクチャ • エンジニアリング組織の採用方針について • メガベンチャーとの違い
カミナシのエンジニアリング文化 6 • カミナシには以下の “エンジニアリング文化” がある。 ◦ オーナーシップ 裁量と責任を与えることである。 裁量によって素早い意思決定ができる。
責任によって本気で課題解決に取り組める。 ◦ サステナビリティ(持続可能性) 短期的な価値だけでなく、中長期的な価値も考慮する。 例:システムのスケール、属人化の排除、負債返済など
カミナシのエンジニアリング文化 7 • “文化は戦略に勝る” ◦ カミナシのエンジニアリングは “文化” によって成り立っている。 • エンジニアリング文化が根づいていることに驚いた。
◦ 明文化されているものではなく、CTO 原トリの思想が組織に浸透している。 • オーナーシップとサステナビリティを意識しながら発表を聞いてもらえると 各種戦略の意図が伝わりやすいかと思います。 生産者の顔 私が作りました
アジェンダ 8 • カミナシのエンジニアリング文化 • エンジニア組織について • サービスチームというバーチャルチーム • エンジニアのスキルセット
• 技術的な意思決定について • システムアーキテクチャ • エンジニアリング組織の採用方針について • メガベンチャーとの違い
エンジニア組織について 9 • 組織体制図上の話である。 • エンジニア、EMの数は合計で30名程度である。 ◦ 会社全体の従業員数は200名程度である。 *以下の図は簡略化したものです。
エンジニア組織について 10 • 早い段階からセキュリティに投資している。 ◦ セキュリティに対する考え方や仕組みを組織に根付かせることで 持続可能性の高い組織を目指す。
アジェンダ 11 • カミナシのエンジニアリング文化 • エンジニア組織について • サービスチームというバーチャルチーム • エンジニアのスキルセット
• 技術的な意思決定について • システムアーキテクチャ • エンジニアリング組織の採用方針について • メガベンチャーとの違い
サービスチームというバーチャルチーム 12 • カミナシには “サービスチーム” という概念がある。 ◦ プロダクト開発をするために必要な人材を集めた仮想チームである。 ▪ 組織体制図上には存在しない。
◦ サービスチームの人数は最大でも6~8名程度に収まる。 例:エンジニア3名、PM1名、デザイナー1名
サービスチームというバーチャルチーム 13 • 要件定義から運用までの開発サイクルをサービスチームで完結させる。 ▪ 職種間のコミュニケーションコストが低い。 ▪ 信頼関係を構築しやすい。
サービスチームというバーチャルチーム 14 • サービスチームがプロダクトに対するオーナーシップを持つ。 例:ロードマップの作成、技術的な意思決定など ◦ 裁量と責任を与えることで素早い意思決定ができる。 • 経営からのトップダウンな指示は基本的にはない。 サービスチームの意思決定に対するレビューがあったり、
経営レベルでの何かしらの方針変更があった場合に影響を受けることはある。
サービスチームというバーチャルチーム 15 • 1つのプロダクトを複数のサービスチームで開発することもある。 ◦ この場合はドメイン型のチーム体制を選択する。 ◦ 実はカミナシレポートは2つのサービスチームによって開発されている。
サービスチームというバーチャルチーム 16 • ドメイン型のチーム体制 ドメイン(特定の機能群)ごとに開発チームを配置し、 中長期的に開発・運用を担当する。 例:会員チーム、決済チーム • プロジェクト型のチーム体制 プロジェクト(開発対象の機能)ごとに都度チームを作り、
開発が終わったら解散する(もしくは別のプロジェクトにアサインされる)。 例:負債返済チーム、検索機能改善プロジェクトチーム
サービスチームというバーチャルチーム 17 • ドメイン型のチーム体制 ◦ メリット ▪ 持続可能性高いエンジニアリングができる。 開発した機能の運用、負債返済、顧客要望対応まで担当する。 ▪
深い知見が溜まりやすい。 オーナーシップを与えやすくなる。 ◦ デメリット ▪ ドメインを分割する境界を定義するのが難しい。 ▪ 非注力なドメインがある場合に開発チームを継続的に配置するのが 難しい。 • 注力対象が変わるスタートアップだとこれが難しい。
サービスチームというバーチャルチーム 18 • プロジェクト型のチーム体制 ◦ メリット ▪ チーム組成が簡単である。 ▪ 開発作業に集中することができるので、物事の進みが早い。
運用作業や負債返済などをしないことが多い。 ◦ デメリット ▪ 持続可能性が低い。 負債返済や運用は誰がやるのか? ▪ チームに深い知見が溜まりづらい。 オーナーシップを与えることにリスクがある。
サービスチームというバーチャルチーム 19 • 1つのプロダクトを複数チームで開発する場合は “ドメイン型” を選択する。 ◦ 特定のチームが特定の領域の開発・運用を一貫して担当することで 持続可能なプロダクト/チームを目指す。 •
プロジェクト型のチーム組成もあるが、事前に持続可能性を考慮する。 例: 実装者による開発後のオンボーディング 各サービスチームから人を派遣し、解散後に元のチームに戻して知見共有する あらかじめ運用をする人やチームを決めておく
アジェンダ 20 • カミナシのエンジニアリング文化 • エンジニア組織について • サービスチームというバーチャルチーム • エンジニアのスキルセット
• 技術的な意思決定について • システムアーキテクチャ • エンジニアリング組織の採用方針について • メガベンチャーとの違い
エンジニアのスキルセット 21 • サービスチームのエンジニアはフルスタック & フルサイクルを前提としてい る。 ◦ コミュニケーションコストの削減 ◦
職能におけるボトルネックの排除 ▪ 属人化の軽減(持続可能性の向上)
高度なエンジニアリングに対する対策 22 • 高度な専門性はどのくらい必要か ◦ テクノロジーのコモディティ化による恩恵がある。 例:クラウド、OSS、AI ◦ 専門性の高い領域は横断チームとして切り出す。 例:セキュリティチーム、ID管理基盤チーム
• エンジニア個々に強みがないわけではない。 そもそも “全部同じくらいできます” という人の方が珍しい。 実際には “幅広くできるけど、特にここに強い” という T字型、下駄型のような人材で構成されている。
高度なエンジニアリングに対する対策 23 ◦ 必要に応じて専門職を採用してもいい(採用のオーナーシップ) サービスチームとしての持続可能性が損なわれなけばよい。 専門職が持つノウハウをチームにインプットすることで、 持続可能性の高いチームになる。 例:カミナシレポートはインフラ運用が大変なので、クラウドインフラエン ジニアを配置している。
アジェンダ 24 • カミナシのエンジニアリング文化 • エンジニア組織について • サービスチームというバーチャルチーム • エンジニアのスキルセット
• 技術的な意思決定について • システムアーキテクチャ • エンジニアリング組織の採用方針について • メガベンチャーとの違い
技術的な意思決定について 25 • サービスチームごとにオーナーシップを持っている。 プロダクトごとに素早く、最適な意思決定をすることができる。 ◦ システムアーキテクチャ ◦ アプリケーションアーキテクチャ ◦
テクノロジースタック • フルスタック & フルサイクルだからこそオーナーシップを与えることができる。 ◦ 「サービスチームとしてはxxxをやりたいけど、インフラ部がNGって言ってる からできない」ということがない。
技術的な意思決定について 26 • なんとなく組織全体で統一されているものもある。 プロダクト間でバラつくと組織全体のエンジニアリング効率が下がる。 例:Go言語, TypeScript/React, AWS, Datadog, etc.
アジェンダ 27 • カミナシのエンジニアリング文化 • エンジニア組織について • サービスチームというバーチャルチーム • エンジニアのスキルセット
• 技術的な意思決定について • システムアーキテクチャ • エンジニアリング組織の採用方針について • メガベンチャーとの違い
各プロダクトのシステムアーキテクチャ 28 • プロダクトごとに違いはあれど、基本的にはモノリスである。 システムアーキテクチャもこれといって特別なものではないはず。
カミナシ全体のシステムアーキテクチャ 29 • ID管理基盤を中心としたシステムアーキテクチャになっている。 • プロダクト横断のデータを扱う社内データプラットフォームを構築している。
アジェンダ 30 • カミナシのエンジニアリング文化 • エンジニア組織について • サービスチームというバーチャルチーム • エンジニアのスキルセット
• 技術的な意思決定について • システムアーキテクチャ • エンジニアリング組織の採用方針について • メガベンチャーとの違い
エンジニアリング組織の採用方針について 31 • 採用もサービスチームがオーナーシップを持って進める。 ◦ チームに欲しい人材を獲得する選考プロセスを実現できる。 例:募集要項の作成、スカウト送信、1次面接の進め方 ◦ モチベーション高く採用の活動量を維持できる。 •
HRのサポート ◦ 候補者とのやりとり(面接のセッティングなど)。 ◦ 隔週でサービスチームとミーティングをしている。 ▪ サービスチームとHRが直接やりとりすることで課題の共有と解決を目指す。
アジェンダ 32 • カミナシのエンジニアリング文化 • エンジニア組織について • サービスチームというバーチャルチーム • エンジニアのスキルセット
• 技術的な意思決定について • システムアーキテクチャ • エンジニアリング組織の採用方針について • メガベンチャーとの違い
メガベンチャーとの違い 33 • コミュニケーションコストの低さ(独立性の高さ) ◦ オーナーシップ文化によって、よりスピーディーな意思決定ができる。 • 技術と組織のエコシステムが不足している ◦ 技術
▪ プラットフォームエンジニアリング ▪ SRE ▪ AI ◦ 組織 ▪ サービスチーム横断の知見共有 & 全体最適化 • 技術的なエコシステムがないので効率的な知見共有や 最適化がしづらい。
今後の取り組み 34 • 技術と組織のエコシステムに投資する価値があるか? ◦ 規模の経済を効かせる必要があるので大きな組織であることが必須である。 ▪ 大きくなるまで待つとエコシステムの導入が難しくなる。 ◦ 専門性の高いエンジニア組織を運営するのは大変である。
• どのタイミングで舵を切っていくのか?
まとめ 35 • カミナシのエンジニアリングは “文化は戦略に勝る” 形で実現されている。 ◦ オーナーシップ ◦ サステナビリティ
• 持続可能性の高いサービスチームにオーナーシップを与える。 ◦ スピーディに適切な意思決定ができるようになる。 • 今後の課題 ◦ 組織横断のエコシステムにどのタイミングで投資すべきか?
ブースを出しています 36 • 本イベントで “株式会社カミナシ” がブースを出しています。 ぜひお越しください。
おわり おわり 37