スタートアップを支える技術戦略と組織づくり

"アーキテクチャカンファレンス 2025" の登壇資料です。
https://architecture-con.findy-tools.io/2025

Transcript

1. スタートアップを支える技術戦略と組織づくり @pospome
2. 自己紹介 • 名前：pospome（ぽすぽめ） • 所属：株式会社カミナシ • 職種：VPoE • Xのアカウント：@pospome 2 社名だけでも 覚えて帰ってください
3. アーキテクチャは技術要素だけで最適解は決まらない 3
4. アジェンダ 4 • カミナシのエンジニアリング文化 • エンジニア組織について • サービスチームというバーチャルチーム • エンジニアのスキルセット • 技術的な意思決定について • システムアーキテクチャ • エンジニアリング組織の採用方針について • メガベンチャーとの違い
5. アジェンダ 5 • カミナシのエンジニアリング文化 • エンジニア組織について • サービスチームというバーチャルチーム • エンジニアのスキルセット • 技術的な意思決定について • システムアーキテクチャ • エンジニアリング組織の採用方針について • メガベンチャーとの違い
6. カミナシのエンジニアリング文化 6 • カミナシには以下の “エンジニアリング文化” がある。 ◦ オーナーシップ 裁量と責任を与えることである。 裁量によって素早い意思決定ができる。 責任によって本気で課題解決に取り組める。 ◦ サステナビリティ（持続可能性） 短期的な価値だけでなく、中長期的な価値も考慮する。 例：システムのスケール、属人化の排除、負債返済など
7. カミナシのエンジニアリング文化 7 • “文化は戦略に勝る” ◦ カミナシのエンジニアリングは “文化” によって成り立っている。 • エンジニアリング文化が根づいていることに驚いた。 ◦ 明文化されているものではなく、CTO 原トリの思想が組織に浸透している。 • オーナーシップとサステナビリティを意識しながら発表を聞いてもらえると 各種戦略の意図が伝わりやすいかと思います。 生産者の顔 私が作りました
8. アジェンダ 8 • カミナシのエンジニアリング文化 • エンジニア組織について • サービスチームというバーチャルチーム • エンジニアのスキルセット • 技術的な意思決定について • システムアーキテクチャ • エンジニアリング組織の採用方針について • メガベンチャーとの違い
9. エンジニア組織について 9 • 組織体制図上の話である。 • エンジニア、EMの数は合計で30名程度である。 ◦ 会社全体の従業員数は200名程度である。 ＊以下の図は簡略化したものです。
10. エンジニア組織について 10 • 早い段階からセキュリティに投資している。 ◦ セキュリティに対する考え方や仕組みを組織に根付かせることで 持続可能性の高い組織を目指す。
11. アジェンダ 11 • カミナシのエンジニアリング文化 • エンジニア組織について • サービスチームというバーチャルチーム • エンジニアのスキルセット • 技術的な意思決定について • システムアーキテクチャ • エンジニアリング組織の採用方針について • メガベンチャーとの違い
12. サービスチームというバーチャルチーム 12 • カミナシには “サービスチーム” という概念がある。 ◦ プロダクト開発をするために必要な人材を集めた仮想チームである。 ▪ 組織体制図上には存在しない。 ◦ サービスチームの人数は最大でも6~8名程度に収まる。 例：エンジニア3名、PM1名、デザイナー1名
13. サービスチームというバーチャルチーム 13 • 要件定義から運用までの開発サイクルをサービスチームで完結させる。 ▪ 職種間のコミュニケーションコストが低い。 ▪ 信頼関係を構築しやすい。
14. サービスチームというバーチャルチーム 14 • サービスチームがプロダクトに対するオーナーシップを持つ。 例：ロードマップの作成、技術的な意思決定など ◦ 裁量と責任を与えることで素早い意思決定ができる。 • 経営からのトップダウンな指示は基本的にはない。 サービスチームの意思決定に対するレビューがあったり、 経営レベルでの何かしらの方針変更があった場合に影響を受けることはある。
15. サービスチームというバーチャルチーム 15 • 1つのプロダクトを複数のサービスチームで開発することもある。 ◦ この場合はドメイン型のチーム体制を選択する。 ◦ 実はカミナシレポートは2つのサービスチームによって開発されている。
16. サービスチームというバーチャルチーム 16 • ドメイン型のチーム体制 ドメイン（特定の機能群）ごとに開発チームを配置し、 中長期的に開発・運用を担当する。 例：会員チーム、決済チーム • プロジェクト型のチーム体制 プロジェクト（開発対象の機能）ごとに都度チームを作り、 開発が終わったら解散する（もしくは別のプロジェクトにアサインされる）。 例：負債返済チーム、検索機能改善プロジェクトチーム
17. サービスチームというバーチャルチーム 17 • ドメイン型のチーム体制 ◦ メリット ▪ 持続可能性高いエンジニアリングができる。 開発した機能の運用、負債返済、顧客要望対応まで担当する。 ▪ 深い知見が溜まりやすい。 オーナーシップを与えやすくなる。 ◦ デメリット ▪ ドメインを分割する境界を定義するのが難しい。 ▪ 非注力なドメインがある場合に開発チームを継続的に配置するのが 難しい。 • 注力対象が変わるスタートアップだとこれが難しい。
18. サービスチームというバーチャルチーム 18 • プロジェクト型のチーム体制 ◦ メリット ▪ チーム組成が簡単である。 ▪ 開発作業に集中することができるので、物事の進みが早い。 運用作業や負債返済などをしないことが多い。 ◦ デメリット ▪ 持続可能性が低い。 負債返済や運用は誰がやるのか? ▪ チームに深い知見が溜まりづらい。 オーナーシップを与えることにリスクがある。
19. サービスチームというバーチャルチーム 19 • 1つのプロダクトを複数チームで開発する場合は “ドメイン型” を選択する。 ◦ 特定のチームが特定の領域の開発・運用を一貫して担当することで 持続可能なプロダクト/チームを目指す。 • プロジェクト型のチーム組成もあるが、事前に持続可能性を考慮する。 例： 実装者による開発後のオンボーディング 各サービスチームから人を派遣し、解散後に元のチームに戻して知見共有する あらかじめ運用をする人やチームを決めておく
20. アジェンダ 20 • カミナシのエンジニアリング文化 • エンジニア組織について • サービスチームというバーチャルチーム • エンジニアのスキルセット • 技術的な意思決定について • システムアーキテクチャ • エンジニアリング組織の採用方針について • メガベンチャーとの違い
21. エンジニアのスキルセット 21 • サービスチームのエンジニアはフルスタック & フルサイクルを前提としてい る。 ◦ コミュニケーションコストの削減 ◦ 職能におけるボトルネックの排除 ▪ 属人化の軽減（持続可能性の向上）
22. 高度なエンジニアリングに対する対策 22 • 高度な専門性はどのくらい必要か ◦ テクノロジーのコモディティ化による恩恵がある。 例：クラウド、OSS、AI ◦ 専門性の高い領域は横断チームとして切り出す。 例：セキュリティチーム、ID管理基盤チーム • エンジニア個々に強みがないわけではない。 そもそも “全部同じくらいできます” という人の方が珍しい。 実際には “幅広くできるけど、特にここに強い” という T字型、下駄型のような人材で構成されている。
23. 高度なエンジニアリングに対する対策 23 ◦ 必要に応じて専門職を採用してもいい（採用のオーナーシップ） サービスチームとしての持続可能性が損なわれなけばよい。 専門職が持つノウハウをチームにインプットすることで、 持続可能性の高いチームになる。 例：カミナシレポートはインフラ運用が大変なので、クラウドインフラエン ジニアを配置している。
24. アジェンダ 24 • カミナシのエンジニアリング文化 • エンジニア組織について • サービスチームというバーチャルチーム • エンジニアのスキルセット • 技術的な意思決定について • システムアーキテクチャ • エンジニアリング組織の採用方針について • メガベンチャーとの違い
25. 技術的な意思決定について 25 • サービスチームごとにオーナーシップを持っている。 プロダクトごとに素早く、最適な意思決定をすることができる。 ◦ システムアーキテクチャ ◦ アプリケーションアーキテクチャ ◦ テクノロジースタック • フルスタック & フルサイクルだからこそオーナーシップを与えることができる。 ◦ 「サービスチームとしてはxxxをやりたいけど、インフラ部がNGって言ってる からできない」ということがない。
26. 技術的な意思決定について 26 • なんとなく組織全体で統一されているものもある。 プロダクト間でバラつくと組織全体のエンジニアリング効率が下がる。 例：Go言語, TypeScript/React, AWS, Datadog, etc.
27. アジェンダ 27 • カミナシのエンジニアリング文化 • エンジニア組織について • サービスチームというバーチャルチーム • エンジニアのスキルセット • 技術的な意思決定について • システムアーキテクチャ • エンジニアリング組織の採用方針について • メガベンチャーとの違い
28. 各プロダクトのシステムアーキテクチャ 28 • プロダクトごとに違いはあれど、基本的にはモノリスである。 システムアーキテクチャもこれといって特別なものではないはず。
29. カミナシ全体のシステムアーキテクチャ 29 • ID管理基盤を中心としたシステムアーキテクチャになっている。 • プロダクト横断のデータを扱う社内データプラットフォームを構築している。
30. アジェンダ 30 • カミナシのエンジニアリング文化 • エンジニア組織について • サービスチームというバーチャルチーム • エンジニアのスキルセット • 技術的な意思決定について • システムアーキテクチャ • エンジニアリング組織の採用方針について • メガベンチャーとの違い
31. エンジニアリング組織の採用方針について 31 • 採用もサービスチームがオーナーシップを持って進める。 ◦ チームに欲しい人材を獲得する選考プロセスを実現できる。 例：募集要項の作成、スカウト送信、1次面接の進め方 ◦ モチベーション高く採用の活動量を維持できる。 • HRのサポート ◦ 候補者とのやりとり（面接のセッティングなど）。 ◦ 隔週でサービスチームとミーティングをしている。 ▪ サービスチームとHRが直接やりとりすることで課題の共有と解決を目指す。
32. アジェンダ 32 • カミナシのエンジニアリング文化 • エンジニア組織について • サービスチームというバーチャルチーム • エンジニアのスキルセット • 技術的な意思決定について • システムアーキテクチャ • エンジニアリング組織の採用方針について • メガベンチャーとの違い
33. メガベンチャーとの違い 33 • コミュニケーションコストの低さ（独立性の高さ） ◦ オーナーシップ文化によって、よりスピーディーな意思決定ができる。 • 技術と組織のエコシステムが不足している ◦ 技術 ▪ プラットフォームエンジニアリング ▪ SRE ▪ AI ◦ 組織 ▪ サービスチーム横断の知見共有 & 全体最適化 • 技術的なエコシステムがないので効率的な知見共有や 最適化がしづらい。
34. 今後の取り組み 34 • 技術と組織のエコシステムに投資する価値があるか? ◦ 規模の経済を効かせる必要があるので大きな組織であることが必須である。 ▪ 大きくなるまで待つとエコシステムの導入が難しくなる。 ◦ 専門性の高いエンジニア組織を運営するのは大変である。 • どのタイミングで舵を切っていくのか?
35. まとめ 35 • カミナシのエンジニアリングは “文化は戦略に勝る” 形で実現されている。 ◦ オーナーシップ ◦ サステナビリティ • 持続可能性の高いサービスチームにオーナーシップを与える。 ◦ スピーディに適切な意思決定ができるようになる。 • 今後の課題 ◦ 組織横断のエコシステムにどのタイミングで投資すべきか?
36. ブースを出しています 36 • 本イベントで “株式会社カミナシ” がブースを出しています。 ぜひお越しください。
37. おわり おわり 37