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
17k
スタートアップを支える技術戦略と組織づくり
"アーキテクチャカンファレンス 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
420
技術好きなエンジニアが "リーダーへの進化" によって得たものと失ったもの
pospome
5
1.6k
DMMプラットフォームにおけるTiDBの導入から運用まで
pospome
8
4.7k
DMMプラットフォームがTiDB Cloudを採用した背景
pospome
10
6k
DDDはなぜ難しいのか / 良いコードの定義と設計能力の壁
pospome
43
21k
マイクロサービス環境におけるDB戦略 in DMMプラットフォーム
pospome
12
4.7k
組織全体で開発生産性に取り組むために 専門チームを作った話
pospome
2
2.1k
DMMプラットフォームにおける GKE を利用した プラットフォームエンジニアリングへの 取り組み
pospome
1
890
DMMプラットフォームにおけるコード品質を改善する取り組みの理想と現実
pospome
3
2.8k
Other Decks in Programming
See All in Programming
「コードは上から下へ読むのが一番」と思った時に、思い出してほしい話
panda728
PRO
39
26k
Java 25, Nuevas características
czelabueno
0
120
Rubyで鍛える仕組み化プロヂュース力
muryoimpl
0
220
[AtCoder Conference 2025] LLMを使った業務AHCの上⼿な解き⽅
terryu16
6
920
リリース時」テストから「デイリー実行」へ!開発マネージャが取り組んだ、レガシー自動テストのモダン化戦略
goataka
0
150
メルカリのリーダビリティチームが取り組む、AI時代のスケーラブルな品質文化
cloverrose
2
410
Combinatorial Interview Problems with Backtracking Solutions - From Imperative Procedural Programming to Declarative Functional Programming - Part 2
philipschwarz
PRO
0
120
gunshi
kazupon
1
120
Implementation Patterns
denyspoltorak
0
140
AI時代を生き抜く 新卒エンジニアの生きる道
coconala_engineer
1
470
AI Agent Dojo #4: watsonx Orchestrate ADK体験
oniak3ibm
PRO
0
110
PC-6001でPSG曲を鳴らすまでを全部NetBSD上の Makefile に押し込んでみた / osc2025hiroshima
tsutsui
0
200
Featured
See All Featured
Introduction to Domain-Driven Design and Collaborative software design
baasie
1
520
What's in a price? How to price your products and services
michaelherold
246
13k
What Being in a Rock Band Can Teach Us About Real World SEO
427marketing
0
150
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
3.3k
Bridging the Design Gap: How Collaborative Modelling removes blockers to flow between stakeholders and teams @FastFlow conf
baasie
0
410
Why Mistakes Are the Best Teachers: Turning Failure into a Pathway for Growth
auna
0
30
svc-hook: hooking system calls on ARM64 by binary rewriting
retrage
1
32
Understanding Cognitive Biases in Performance Measurement
bluesmoon
32
2.8k
Into the Great Unknown - MozCon
thekraken
40
2.2k
Embracing the Ebb and Flow
colly
88
4.9k
Designing Powerful Visuals for Engaging Learning
tmiket
0
190
How to Align SEO within the Product Triangle To Get Buy-In & Support - #RIMC
aleyda
1
1.4k
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