カミナシの成長を支える「オーナーシップ」と「サステナビリティ」

「スタートアップを支える技術戦略と組織づくり」というテーマでお話しいたします。株式会社カミナシ VPoEのpospomeと申します。

このイベントは「アーキテクチャConference 2025」ということで、アーキテクチャは技術的な要素が強いものだと思います。

しかし、イベントの開催概要にもある通り、プロダクトの特性やチームのあり方によって最適解が変わるものです。私の発表では、技術だけではなく、組織にもフォーカスして「技術が組織に与える影響」「組織が技術に与える影響」という、相互作用の様子をお話しできればと考えています。

まずは、カミナシのエンジニアリング文化についてお話しします。カミナシには「オーナーシップ」と「サステナビリティ」という2つのエンジニアリング文化があります。オーナーシップとは、裁量と責任を与えることによって、個人やチームが素早い意思決定ができたり、課題解決に取り組めたりすることを指します。2つ目のサステナビリティとは、中長期的な価値も考慮するという思想で、負債の返済などがこれに当たります。

カミナシのエンジニアリングにおける組織的・技術的戦略は、すべてこの文化によって成り立っています。まさに「文化は戦略に勝る」といった形で、カミナシの開発力を支える非常に強力な要素となっています。

私が1年ほど前にカミナシに入社した頃には、すでにこの文化が根付いていました。これといって明文化されていたり、大々的に定義されたりしているものではないものの、CTOのメッセージによってこうした思想が組織に浸透しており、結果としてそれを前提とした戦略が生まれていく。この構造には非常に驚いたのを覚えています。

こうしたなにかしらの文化が根付いている開発組織は、実は少ないのではないでしょうか。カミナシはまだ規模が大きくなく、CTOのメッセージングが巧みなため浸透しています。しかし、組織が大きすぎて浸透させられなかったり、メッセージがうまく伝わらなかったりと、様々な理由から、カミナシのような文化を持っている組織は少ないように思います。

サービスチームが体現する「少人数・職種横断・フルサイクル」の強み

早期のセキュリティ投資が「持続性の高い組織」を創る

次にエンジニア組織についてお話しします。こちらは組織体制図上のお話です。カミナシはエンジニア、EMが合計30名程度在籍しており、プロダクト開発系の組織と横断系の組織に分かれています。プロダクト開発系は「カミナシ レポート」や「カミナシ 教育」といったプロダクトごとに専門の開発チームを作ってアサインしています。横断系は、ID管理基盤やセキュリティといった、各プロダクトを跨いでサポートする組織です。この図は簡略化したものですので、一見すると特に特徴はないように思われるかもしれません。

唯一特徴的なものを挙げるとすれば、早い段階からセキュリティに投資している点です。横断系のセキュリティチームは、エンジニアが20名に満たない頃からすでに存在していました。セキュリティに対する考え方や仕組みをプロダクト開発系の各開発組織にインプットして根付かせています。

セキュリティは何も起きなければ問題ありませんが、何かが起きた時には会社にクリティカルなダメージを与えかねません。そうしたダメージを中長期的に与えないよう、各エンジニアがリテラシーを持って活動できる「持続性の高い組織」を目指す思想がここにも現れています。

コミュニケーションの摩擦を解消する「サービスチーム」

次に「サービスチーム」という概念についてお話しします。カミナシには、プロダクト開発に必要な人材を集めた「サービスチーム」という仮想チームが存在します。図にあるように「カミナシレポートサービスチーム」では、エンジニア3名とデザイナー、PMが基本セットになって物を作っています。

このサービスチームは、先ほどの簡略化した組織体制図には存在しません。あちらはあくまでエンジニアの組織図であり、PMやデザイナーは含まれていないからです。実際にプロダクト開発をする際には、サービスチームを定義して、そこに必要な職能を持った人たちを集めています。人数は最大でも6～8名程度に収めています。これはAmazonの「ピザ2枚ルール（Two pizza rule）」という、チームの大きさを定義する考え方に沿ったものです。

このサービスチームは、要件定義から運用までのサイクルを完結させます。スクラムイベントだけでなく、顧客訪問にもエンジニアが同行し、開発～運用のすべてをこのチームで回します。

このような形にしている理由の1つ目は「コミュニケーションコストの削減」です。プランニングやデイリースタンドアップの場に各職種が集まってディスカッションを行っているため、例えば「仕様をPMに確認したい」となった際にも、すぐに質問できます。物理的・心理的な距離が近く、コミュニケーションコストが大幅に抑えられています。

2つ目は「信頼関係を構築しやすい」です。一般的に、PMの提案にエンジニアが反発するといった摩擦が発生する背景には、お互いのコンテキストの共有が浅かったり、日頃のコミュニケーション頻度が不足していたりすることが関係しています。一方で、カミナシのサービスチームは開発サイクルをチーム内で完結させる体制で日々情報を共有できているため、コミュニケーションの摩擦が少なく良好な関係性を築けています。

サービスチームにはプロダクトに対するオーナーシップを与えています。ロードマップの作成から技術的な意思決定に至るまで、サービスチーム自らが主導することで迅速な開発を実現しています。トップダウンによる細かな機能指定は基本的になく、経営層はチームの意思決定に対するレビューや、経営レベルの方針変更に伴う調整を担っています。このように、現場のチームが自分たちで考えて物事を決定できる体制が、カミナシの意思決定の速さを支える基盤となっています。

サステナビリティを軸としたドメイン型のチーム体制

なお、これまでの説明では、あたかも1つのプロダクトを1つのチームで開発しているかのような印象を与えてしまったかもしれませんが、プロダクトの規模が拡大するにつれて、当然ながら複数のチームで開発を進めることになります。具体的には、大きくなったチームを分割していくようなイメージです。実際に、主力プロダクトである「カミナシ レポート」も、現在は2つのサービスチームによって開発が進められています。

このようにサービスチームを増設する際、カミナシでは基本的に「ドメイン型」のチーム体制を選択しています。ドメイン型とは、特定の機能群ごとに開発チームを配置し、中長期的にその領域の開発と運用を担う体制のことです。例えば、会員に関する機能を専門に扱う「会員チーム」を組織するといったケースがこれに当たります。一方で「プロジェクト型」と呼ばれる体制は、開発対象となる特定の機能ごとにその都度チームを組成し、開発が完了した段階でチームを解散させる形態を指します。よくある例としては、技術的な負債を解消するために特別なチームを編成し、その返済が終われば解散するといった進め方がプロジェクト型の典型です。

ドメイン型のメリットは、持続可能性の高いエンジニアリングが可能になる点です。同じ領域を継続して運用し、顧客の要望に応え続けることでチーム内に深い知見が蓄積され、機能追加や負債返済の精度が向上します。結果として経営層からの信頼を得られるため、さらに大きなオーナーシップが委ねられ、開発スピードがさらに向上していくという好循環が生まれます。

一方でデメリットもあり、1つ目はドメイン分割する際の境界線をどこに引くかという定義の難しさです。先ほど例に挙げた「会員領域」でいうと、会員領域といっても、会員情報の管理から認証認可まで多岐にわたり、細分化すればきりがありません。そのため、認証を会員チームに含めるのか、あるいは別チームとして切り出すのかといった判断において、境界の定義は非常に困難です。

この境界設定を細かくしすぎると、今度はチームの数が増えるため、チーム間でのコミュニケーションコストが増大し、かえって開発効率が低下してしまいます。逆に、境界を大きく設定しすぎると、一つのチームが抱える開発アイテムや運用コストが膨らみ、開発が回らなくなってしまうといったリスクが生じます。このように、適切なバランスでドメインを定義することの難しさは、この体制における大きな課題といえます。

また、注力したいドメインがある場合に、開発チームを配置するのが難しくなります。これは特にスタートアップあるあるの課題かもしれません。スタートアップはそもそもの人数が少ないことに加えて、事業状況に応じて優先順位がドラスティックに変化します。例えば「今四半期は会員領域を改善したいが、次の四半期は決済領域に注力したい」といった状況になった際、優先度の高い領域に人員を投入したいですよね。しかし、ドメイン型の場合は中長期的にその領域の開発運用を担い続ける方針であるため、こうした急激な方向転換や人員の柔軟な配置とは、相性が悪い側面があります。

一方で、プロジェクト型はドメイン型とは正反対の特徴を持っており、チーム組成がとても簡単です。実現したいことや作りたい機能に合わせて人を集めるだけでよいため、特定の開発作業に集中でき、物事の進捗が非常に早いのが特徴です。また、通常は運用や負債返済といった業務を切り離して進めることが多いため、目の前の開発スピードを最大化できます。

一方でデメリットとして、持続可能性が低いという点が挙げられます。チームが解散した後に誰が保守するのか、あるいは不具合が発生した際に誰が対応するのか、といった問題が常に付きまといます。さらにチーム内に深い知見が蓄積されにくいという課題もあります。例えば、プロジェクト型で機能を開発して解散した場合、1年後にその機能を改修しようとしても、当時の担当者は仕様を詳細に覚えていない可能性があります。中長期的な視点で見ると、知見が残らないために開発効率が悪化してしまうリスクがあるのです。

カミナシではエンジニアリングの文化として「サステナビリティ」を重視しているため、基本的にはドメイン型を選択します。当然、プロジェクト型のチームを組成することもありますが、その際には事前に持続可能性について検討します。具体的には、プロジェクト解散後に誰が運用・保守するのか、不具合が発生した際に誰が対応するのかといった運用フローを明確に定めます。こうした懸念事項に対して解決策を出して、ある程度フィックスさせた上でようやく開発をスタートさせるというプロセスを徹底しています。

「フルスタック・フルサイクル」を支える組織戦略

職能のボトルネックを排除する「誰でも何でもできる」前提のチーム

次にエンジニアのスキルセットについてお話しします。カミナシのサービスチームのエンジニアは、基本的にフルスタック＆フルサイクルを前提としていて、テクノロジースタックはフロントからインフラまで、開発サイクルは要件定義から運用までを担当します。つまり「誰でも何でもできる」を前提としているわけです。

こうした体制にしている理由の1つ目は「コミュニケーションコストの削減」です。バックエンドとフロントエンドといった形で分業制にしていると、1つの機能を開発する際に、APIの定義をはじめとした詳細な調整のために職種間でのコミュニケーションが必要となります。しかし、フルスタックかつフルサイクルな開発を前提としていれば、そういったコミュニケーションは発生しません。最終的なチームレビューなどの要所における確認だけでスムーズに開発を完了できます。

2つ目の理由は「職能におけるボトルネックの排除」です。サービスチームが抱えるタスクの内容は、その時々の開発アイテムによってフロントエンドに偏ることもあれば、バックエンドが中心になることもあり、変動します。もしエンジニアを職能ごとに専任化してしまうと、フロントエンドのタスクが少ない時期にフロントエンドエンジニアがバックエンドのタスクを肩代わりする、といった柔軟な対応ができません。チームとしては、あらゆるタスクを優先度順に並べて全員で消化していく状態が理想ですが、職能で守備範囲を固定してしまうと、特定の領域がボトルネックとなり全体の進捗を停滞させてしまいます。

このような事態を防ぐために、カミナシではフルスタックかつフルサイクル開発を前提としています。職能のボトルネックを排除することで、結果的に属人性が軽減され、持続可能性の向上にも繋がっています。

テクノロジーのコモディティ化 × T字型・下駄型人材による補完戦略

このようなジェネラリスト中心のエンジニア組織についてお話しすると、「高度な専門性が必要な場合はどうするのか」という疑問がよく挙がります。これに対するカミナシとしてのスタンスは、まず「テクノロジーのコモディティ化」による恩恵を最大限に活用することにあります。

ここで言うコモディティ化とは、かつては高度な専門知識がなければ実現できなかった難しい事柄が、現代では誰でも比較的容易に扱えるようになっている状況を指します。具体的には、クラウドサービスやOSS、AIといった技術の進化がこれに当たります。

少し昔を振り返ると、私が新卒の頃は、高トラフィックなサービスのインフラを構築するのは非常に難易度の高い作業でした。当時はオンプレミス環境が主流だったため、専門的なスキルを持つインフラエンジニアが「秘伝のシェルスクリプトを駆使してデータベースのレプリケーションを組む」といった光景が一般的でした。しかし現在では、AWSのRDSのようなマネージドサービスを利用すれば、ボタン一つで同様の設定が完了します。

このように、かつては必須だった専門性が、技術の進化によって不要、もしくは代替可能になってきています。カミナシの開発現場においても、よほど特殊なケースを除けば、専門性が際立って要求されるシチュエーションが少なくなっています。そのため、ジェネラリスト中心の体制であっても、十分に開発を回していくことができるのです。

2つ目にあるのが「専門性の高い領域は横断チームとして切り出す」という考え方です。実際にカミナシでも、セキュリティやID管理基盤といった領域については専門チームを設けています。会社として優先順位の高い専門領域には投資をするスタイルであるため、ジェネラリスト中心の組織でも専門性の欠如が問題になることはないと。

また、そもそもカミナシのエンジニアに個別の強みがないわけではありません。全領域を等分にこなせるエンジニアはレアですし、多くが「全ての領域を最低限カバーしつつ、特定の強みを持っている」というT字型もしくは下駄型のスキルセットを持つメンバーが集まっています。多様な強みを持つ個人が集結することで、結果的にチーム全体で高い専門性を維持できるようになっています。

さらに、カミナシのサービスチームは採用に対してもオーナーシップを持っており、チームに必要な人材を自分たちで決めることができます。「チームとしての持続可能性が損なわれないこと」を前提に、必要であれば専門職を採用することも可能です。例えば「カミナシ レポート」は運用負荷の高いプロダクトでもあるため、クラウドインフラエンジニアを配置しています。そういった専門職が持つノウハウをチーム内にインプットすることで、他のメンバーがより高度なスキルを習得できるだけでなく、チーム全体の持続可能性も高まります。このように、状況に応じて専門職を採用できる柔軟なオプションもしっかりと用意しています。

オーナーシップを持たせることで実現するスピード感

承認待ちを排除する「オーナーシップ」に基づいた技術選定

次に技術的意思決定についてお話します。サービスチームにはオーナーシップを与えているとお伝えしましたが、当然ながら技術的な意思決定も各チームの裁量で行うことができます。

これを可能にしているのは、チームがフルスタックかつフルサイクルで動いているからこそです。もしこれが分業制であれば「サービスチームはこの施策を進めたいが、インフラ部門から許可が下りないため実行できない」といったことが発生し、迅速な意思決定ができない、もしくは決定自体が不可能になるという問題が発生します。

カミナシでそういった停滞がないのは、先ほどお話ししたクラウドやAIといったテクノロジーのコモディティ化の恩恵を受けているからです。インフラ部門を置かずとも、複雑な仕組みを運用できる余地があるからこそ、この形が成立しています。

一方で、組織全体である程度の統一感を持たせている部分もあります。全ての技術選定がプロダクト間でバラバラになってしまうと、組織全体のエンジニアリング効率が低下してしまうためです。例えば、あるチームはPython、別のチームはGoというように言語が分散していると、組織的事情でメンバーの異動があった際に言語のキャッチアップが必要となるため学習コストが発生します。そういったことにならないように、組織全体で標準化するべき領域については一定のルールを設けています。

ID管理基盤を中心としたシステムアーキテクチャ

次に、システムアーキテクチャについてお話しします。各プロダクトの詳細はそれぞれに異なりますが、基本的にはモノリスを採用しています。フロントエンドとしてクライアントアプリや管理画面があり、バックエンドのサーバーと1つのRDBが紐づいているといった形です。

プロダクトによってはLambdaやDynamoDBを組み合わせて活用しているところもありますが、カミナシ独自の特殊なアーキテクチャを構築しているわけでありません。AWSなどのクラウドサービスが一般化し、多種多様な構成事例が公開されている現代においては、オーソドックスな構成だと思います。

一方でカミナシ全体のシステムアーキテクチャはこのようになっています。各プロダクトが独立しつつ、ID管理基盤を中心とした構成にしています。ユーザーの認証はすべてID管理基盤に集約されており、各プロダクトがこれに依存する形です。

また、現在は社内向けのデータプラットフォームを絶賛構築中です。各プロダクトが持つデータがこのプラットフォームへ自動的に連携されるようにすることで、プロダクトを跨いだ横断的なデータ分析を社内で実施できるようにしています。

「自分たちで獲りに行く」採用活動がエンジニアの責任感を生む

続いて、エンジニアの採用方針についてお話しします。先ほどもお伝えしたように、カミナシでは採用に関してもサービスチームがオーナーシップを持っています。どういう仲間を必要としているかは、現場のメンバーが一番理解しているはずです。そのため、理想の人物像の定義から、募集要項への落とし込み、面接プロセスの設計、カジュアル面談でのアトラクト、スカウトメールの送付に至るまで、すべてをチームメンバーの判断で進めています。これにより、現場のニーズにマッチした人材を獲得できる可能性を最大限に高められています。

また、サービスチームが自ら動かなければ採用が進まないという力学が働くため、必然的に高いモチベーションと活動量を維持できるという側面もあります。採用には様々な効率化の手法がありますが、最終的には地道なスカウトやイベント登壇での認知獲得といった、活動量の勝負でもあります。ここにいかに人を投資できるかどうかで、人を1人雇えるかどうかが決まると。そういった背景もあり、チームに責任と権限を委ねるオーナーシップ型のモデルが、活動を自走させるエンジンとしてうまく機能しています。

なお、HRのサポート体制がないわけではありません。候補者とのやり取りや面接のセッティングなどはHRが担い、サービスチームと隔週でミーティングを実施しています。現場で採用に携わるメンバーとHRが直接対話を重ねることで、現場の課題感をHRが正しく認識でき、全社的な採用プロセスの最適化にもつなげることができています。このように、現場とHRが密に連携しつつ、現場が主体性を持って動くことがカミナシの採用における重要なポイントです。

メガベンチャーとの違いから見えた「技術エコシステム」への投資

知見共有とエコシステムの未熟さには課題あり

次にメガベンチャーとの違いについて、これまでの経験を踏まえてお話しします。私はメガベンチャー歴が長いのですが、カミナシでは「コミュニケーションコストの低さ」を感じました。まだ小さな組織であることも背景にありますが、それ以上にオーナーシップ文化が強いのだと思います。あらゆる物事がサービスチーム内で完結するようになっているため、意思決定から実行までが非常に速く、超小規模なスタートアップが持つようなスピード感を維持できています。

一方で、技術や組織におけるエコシステムには少し弱い面があるのも事実です。具体的には、プラットフォームエンジニアリングに代表されるような、技術のエコシステムがなく、組織の知見共有が難しいところがあります。プラットフォームチームが共通の仕組みを提供している組織では、各チームが同じ土台の上で開発を行うため、共通の課題に対して知見を共有しやすく、全体最適化もスムーズに進みます。カミナシでも知見の共有や全体最適化の取り組みはありますが、技術的なエコシステムが不足していることもあり、効率的には進められていないように思います。

今後の取り組みとして、こうしたエコシステムへの投資価値をどのように見極め、どのタイミングで実行していくかを検討していくつもりです。組織が大きくなってから構築しようとしても手遅れになりますし、早すぎるとコストパフォーマンスが見合いません。舵を切るタイミングを判断するのは、なかなか難しいことだと思います。

文化を戦略に勝らせ続けるために重要となる「投資タイミング」の見極め

まとめます。カミナシのエンジニアリングは「オーナーシップ」と「サステナビリティ」という2つの柱によって支えられており、まさに「文化は戦略に勝る」という言葉を体現しています。この独自の文化があってこそ、現在のカミナシがあるのだと思います。

持続可能性の高いサービスチームを組織し、そこにオーナーシップを与えることで、スピーディかつ適切な意思決定が可能になります。先ほどもお話しした「エコシステムに投資するタイミング」については、非常に悩ましく模索を続けているところです。

本日は、ご清聴ありがとうございました。

アーカイブ動画・発表資料

イベント本編は、アーカイブ動画を公開しています。また、当日の発表資料も掲載しています。あわせてご覧ください。

▼動画・資料はこちら
アーキテクチャConference 2025

※動画の視聴にはFindyへのログインが必要です。