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