【開発生産性カンファレンス 2025】開発生産性を測る前にやるべきこと：組織改善の実践

マルチテナントSaaSへの変更&職能別組織の誕生

富所：CTO室でバックエンドエキスパートという肩書で仕事をしている富所亮です。よろず屋といった感じで、幅広く対応しています。趣味はマラソンで、Xなどでは「hanhan1978」という名前で活動しています。

私が所属しているCTO室は、日々のプロダクト開発だけではなく、長期的かつ横断的な視点で技術戦略や開発組織全体に関わる技術課題の解決を担う組織です。プロダクト開発をする部署と横並びで独立している組織であり、各部署に介入できます。

働き方についてもご紹介します。弊社は勤務の柔軟性が非常に高く、ハイブリッド勤務でリモートか出社を自由に選べます。スイッチワークも導入しており、保育園の送り迎えや介護など、状況に応じて勤務時間とプライベートの時間を切り替えられます。

このような働き方を取り入れている中で、どのように組織改善をして、企業活動を回してきたのか、が本日の主題です。

内容は大きく分けて二つあります。まずは、組織改善は企業の成長フェーズによって対応が大きく変わってくるため、弊社が現在どの成長フェーズにいるのかを明確にします。

次に、その事例と効果についてお話しします。本日お話しする事例の中で「会社に持って帰って、やってみよう」と思うものが一つでもあれば良いなと思います。

それでは、本題に入ります。


「カオナビ」は2012年にサービスを開始しました。サービス開始から3年後の2015年には、リプレイスプロジェクトが発足しています。これは、利益が上がりシステムが売れたために発足されたものです。2017年には、現行システムへの移行が開始され、2019年の大カイゼン時代を経て、現在に至ります。

本日は、2019～2025年頃にフォーカスしてお話しします。ちなみに、私は2020年入社のため、大カイゼン時代の大部分を経験しています。

2019年までの大まかな流れについてもお話しします。2012年のサービス開始直後（0→1フェーズ）は、100%外注でシステムを開発していました。また、当時の「カオナビ」は、顧客ごとに機能をカスタマイズしていました。売上を伸ばすためには顧客要望を柔軟に取り入れる必要があり「100社あれば100個の『カオナビ』がある」状態だったのです。

運用が非常に大変だったため、2015年頃にリプレイスプロジェクトが開始されました。マルチテナントSaaSとして同じシステムを各社に使ってもらう方針に転換し、機能カスタマイズは販売メニューに収束させる形に変更しました。

この方針転換が成功し、2017年には運用が大幅に安定しました。サービスのスケールが容易になり、個社対応が不要になったことで売上は大幅に向上。さらに、このタイミングで組織体制を強化して職能別組織が誕生しました。

こういった流れは、マルチテナントSaaSサービスを開始した会社の“あるある”だと思います。



この職能別組織は、企画職、開発職、QAの三つに分かれており、これらをまたいでリリースまで進める体制でした。

この職能別組織を取り入れたマルチテナントSaaSの「カオナビ」は、2017年に利用企業数が500社を超え、翌年には倍の1,000社を突破しました。しかし、急成長に伴う組織課題も発生していました。

利用企業社数が急増した2018年頃に課題が表面化したことで、2019年の大カイゼン時代につながるのです。

急成長に伴う課題を解決するべく、大カイゼン時代に突入

富所：2019年頃の開発組織の課題は「セクショナリズム（派閥主義・縄張り意識）」です。また、期日を遵守することがゴールになっていたことに加えて、職能間のコミュニケーションがスムーズに取れていないという課題もありました。

ものをつくる際、企画職も開発職も仕様書を書きますが、実際に作ってみないと動きが分からない部分がありますよね。そういった部分は仕様書では曖昧にしておくものですが、職能別組織ではそれが許されません。つくる側は「仕様をきちんと決めてほしい」からです。

曖昧な仕様書でも、うまくつくってくれる人は確かに存在しますし、その状態が続けば職能別組織はうまくいきます。しかし、一般的には許されることではありませんし、カオナビでも非常に詳細な仕様書が作成されていました。詳細な仕様書ほど変更点が多くなりがちなため、結果としてリリース直前のビッグバンマージによる失敗もありました。

開発スピードの鈍化も課題でした。成功したシステムはモノリスで増えていくことが多いと思います。モノリスの開発は、初期フェーズのスピード感があるものの、しがらみが増えるにつれて開発スピードが鈍化していきます。当時の開発組織には「とはいえ、鈍化しすぎているのでは？」という実感があったそうです。



こちらは当時の様子です。このような状態だったため、リリース前に問題が爆発してしまっていました。また、職能別に分断されたことで、トライアルアンドエラーの柔軟性にも欠けていました。

当時を振り返って「あれは社内受託開発だった」というメンバーもいます。自分の担当をこなすことに必死で、納期に間に合わせることが目的となってしまい、意思疎通が不全でコミュニケーションハードルが高い状態でした。

企画職の人が、エンジニアを神聖化するようなところもありました。エンジニアのことを「エンジニアさん」と呼ぶ人は他社にもいらっしゃるかもしれませんが、これは危険な兆候だと思います。エンジニアは神聖な存在ではありません。“パソコンが得意なメンバー”として普通にコミュニケーションを取るべきなのに、神聖化されてしまっている良くない状態でした。

『サイロ・エフェクト』という有名な本がありますが、私たちの場合は、職能がサイロ化してしまっていたのです。最適化しようとした結果、それぞれのグループが独自ルールで作業を行い、協調できない状態でした。

その頃に生まれたプロジェクトが、部門横断の選抜チームです。各部署からメンバーを選抜してクロスファンクショナルなチームを組成し、リニューアルや改善を行う最初のパイロットプロジェクトで、これは開発組織に良い結果をもたらしたようです。

▼参考記事：部門を超えた選抜チーム──「UIリニューアルプロジェクト」の裏側を語る
https://www.wantedly.com/companies/kaonavi/post_articles/175731

ちなみに、2019年の大カイゼン時代にも、開発生産性指標（チケット起票からリリースまでのリードタイム、デプロイ回数・個数など）を取得していました。ただ、この時点では「開発生産性を安定・改善していく土台が、カオナビにはないのではないか？」という課題感がありました。

開発組織としては、更なる体制変更があり、ミッションベースの組織へと変更されました。



企画・開発・QAが一体となったチームA、B、Cが、それぞれのミッションやタスクを持つ形です。これは、サービス事業会社が最終的にたどり着く形なのではないでしょうか。

ミッションベースの組織への変更は、現段階ではハッピーエンドだと言えます。2023年には利用企業社数が3,000社以上にまで増加し、現在は4,000社を突破しました。

組織改善の始まりは、数字ではなく「ノリ」だった？

富所：カオナビが、なぜ組織改善に取り組んできたのかについてもお話しします。

クロスファンクショナルチームによるマルチテナントSaaS運用で、売上・利益ともに大きく向上しましたが、この大カイゼン時代に行った体制変更は、数字を見て取り組んだものではありません。

カイゼン方針の背景について、キーパーソンだった人にインタビューしたところ「なんとなくノリで」という回答だったため、私は困惑してしまったのですが……（笑）。

真面目な言葉に言い換えると「変化に適応しやすい体制への変更」が理由の一つだったと聞いています。開発者は職能別組織での社内受託開発に面白さを感じられず「これでは顧客に良いものを届けられないし、状況を改善したい」という雰囲気が社内に満ちていたと。そして、それが体制改善への取り組みにつながったそうです。

あとは「現場主導への転換」ですね。売上と利益が伸びて会社が大きくなる中で、優秀な人材が加わり、自然と組織が変わっていったという側面もあるそうです。また、同時期にアジャイル界隈の人々が企画職に加わったこともあり、非連続な変化が徐々に起きていたようです。

ちなみに、経営層は「生産性を上げるのではなく、改善をしながら生産性を下げないこと」を意識していたと聞いています。

3日に行われたKent Beck氏の「開発生産性測定のトレードオフ 『グッドハートの法則』はもっと悲観的に捉えるべきだった」から一部を抜粋すると「Instill purpose（目的を植え付ける）」と書かれているスライドがありましたね。



弊社でも、アジャイル・スクラム界隈から来た人々は、顧客中心主義の理念を持っていました。有名な『みんなでアジャイル』に書かれているような話ですね。開発は最終的に顧客へ価値を届けるためのものであり、そのために皆で大きな目的を持つと。その考えを大切にする人が、社内に増えていったのです。

計測された数値を見て浅い解決策を繰り返しても効果が薄いですし、弊社には「状況を引き起こす根本が職能別組織にあるのだから、組織構造を変えよう」といった大きな改善に目を向ける人が多かったのだと思います。

取り組み事例：チーム間のコミュニケーション支援

富所：「組織改善するには、どうしたら良いですか」と聞かれると「頑張ってください」としか答えられないのですが、カオナビの取り組みとその効果はご紹介できます。

最初にお話しするのは、コミュニケーション支援です。

チーム開発に移行して、企画・開発・QA間のコミュニケーションは改善したはずなのですが、今度はチーム間のサイロ化という最悪の事態が発生しました。

不思議なことに、チームAはチームBの活動を知らず、チームBもチームAの活動を知らないという状況が頻繁に発生します。開発チームが20、30と増えていくと、他チームのことはほとんど分からなくなります。

これが原因で不具合が生じるだけでなく、機能間で重複した開発をしたり、他チームの成果を前提にすれば容易にできたはずの作業が無駄になったりすることが起きます。

情報は自然には伝播しません。チーム開発への移行は銀の弾丸ではなく、私たちは課題を解消するために施策を講じ続けなければいけないのです。

では、どんなコミュニケーション改善をしているのかというと、取り組みの一つに「オアシス」というものがあります。OST（オープンスペーステクノロジー）形式で、毎月会社に集まり様々な話をする場です。



毎回20～30名が参加していて、営業職やカスタマーサクセスなど、多様な職種の人々が集まります。

普段リモートで開発していて接点のない人がいるエンジニアの場合、一度顔を合わせる機会があるだけでも、開発者体験が大きく変わります。例えば、別部署の人とコミュニケーションを取りたくても、接点がないとなかなか難しいですよね。しかし、「オアシス」のような場所で顔を合わせる機会があれば、気軽に話しかけられるようになります。

▼オアシスの詳細：チームを超えた学び合いの場「オアシス」を社内開催しました
https://www.wantedly.com/companies/kaonavi/post_articles/891885

このような草の根活動は、遠方からの参加や新入社員に良い影響を与えます。弊社はフルリモートも可能ですが、対面機会が少ないメンバーは、初期コミュニケーションが大変な側面もあります。その際に「オアシス」のような場があると、出社の理由ができますし、その後のコミュニケーションが円滑になるのです。

当初の目的は「チームを超えた学び合いと学びの循環を促す場を設けること」だったのですが、横のつながりが醸成されるという素晴らしい効果がありました。

また、私見ですが、出社したからといって、コミュニケーションの課題が改善されるものではないと思います。このような仕組みを活用してコミュニケーションを促さないと、横のつながりは生まれません。

▼参考資料：リモートワーク中心の組織を活性化させるリアル接点の力
https://speakerdeck.com/kaonavi/the-power-of-real-contacts

もう一つの取り組みが「Agile Open Door」です。リモートでの打ち合わせ形式で、参加者からテーマを募って深掘りすることで学びを共有しています。

テーマ例としては「それぞれが取り組む挑戦とその課題」「AI活用ノウハウ」といったものから、弊社の深い課題やチーム間コミュニケーションの改善策まで、多岐にわたります。

これは中途入社者がコミュニケーションのハブとして活用できるため、非常に重要な役割を担う素晴らしい取り組みだと感じています。

その他にも、弊社では多くの施策を実施しており「kaonavi Friday Night」というカジュアルな社員交流イベントもあります。飲酒を伴うイベントで、やはり横のつながりを作ることを目的としています。このように、とにかく多様なコミュニケーション施策があるのです。

私個人のお話をすると、自分が手掛けるプロダクトを営業担当者に知ってほしいのに、スプリントレビューに来てもらえないことがあります。そういった場合、こうした場で営業担当者に話しかけて、10分ほどプレゼンするようにしています。

次に技術的な話として、私がカオナビに導入したアーキテクチャデシジョンレコード（以下、ADR）があります。ADRには「チームのサイロを破壊する書類」としての役割を持たせています。



町の掲示板のような役割として「今度こういう改善をしますよ」と約1ヶ月間掲示して、異論があれば申し出ててもらう、というのが弊社のADRです。

「それはADRか？」とツッコまれることもありますが、私は「ADRです」と胸を張って答えています。みんなに認めてもらうためには、立派な名前を付けることが非常に重要です。

▼ADRに関する詳細：ADRを一年運用してみた
https://speakerdeck.com/hanhan1978/adr-after-a-year

その他に、リモートでの全社スプリントレビューも行っています。

▼スプリントレビューの詳細：全社スプリントレビューで社員一人ひとりがプロダクトを自分ごとにする。
https://vivivi.kaonavi.jp/articles/sprint-review-230803/

取り組み事例：価値提供スピード支援

富所：次に、価値提供スピードへの支援として、フィーチャートグルについてお話します。

以前のようなビッグバンリリースでは、多数のチームが存在する環境で、チームAが3ヶ月かけて開発した大規模機能を一気にマージすると、チームCが大きな影響を受けたり、時にはチームA自身が機能しなくなったりする事態が普通に発生していました。

「このようなことはやめませんか？」というのがフィーチャートグルであり、これはメインブランチベースの開発を促すものです。

フィーチャートグルの導入により、各チームは大きな変更に怯えずに済むようになりました。またビッグバンマージによるデプロイ失敗を回避することもできます。

フィーチャートグルはデータベースの値などを参照して機能するため、任意のタイミングでの試験的リリースが可能になります。弊社はマルチテナントのため、自社環境のみトグルをオンにするといったこともできます。

機能リリースだけでなく、各種の改善作業にも流用できます。例えば、機能変更がないはずのリファクタリングでも、突然デプロイすると予期せぬ問題が起きるかもしれないような「怖いリリース」がありますよね。そうした際にフィーチャートグルを使用すれば「とりあえず自社だけ壊してみるか」という感覚でトグルをオンにできます。これは非常に有効な手段であり、大規模モノリスを運用する会社には導入を強く推奨します。

SaaSとして提供されているフィーチャートグルもありますし、一度見てみるのもオススメです。開発体験の向上とリリース頻度の増加につながります。技術的な取り組みが、開発や企業活動全体に影響を与える良い例だと思います。

▼フィーチャートグルの詳細：ビッグバンリリース対策でFeature Toggleを導入したら、開発チームが「デプロイできる状態」をより深く考えるようになった
https://hatenanews.com/articles/2023/06/27/103000

次にお話しするのは、モノリスを運用する会社ならではの、Package By Featureによる複雑性管理です。

弊社では「巨大なモノリスの開発が複雑で辛いからマイクロサービスにしたい」という声もある中で、私は、「モノリスも御せない者が、マイクロサービスは御せないぞ」という考えを一貫して持ち続け、モジュラーモノリスに至りました。

現在は、ルーズカップリングを目指しています。



モジュール間の複雑性を減らすのではなく、結合を特定の場所に集約させる考え方です。

現在、パッケージとして独立したモジュールのテスト数は、モノリス全体のテスト数を完全に超えています。これは、テスト作成が容易で、コードの見通しが良いことを示しています。テスト実行時間の増加といった課題もあるのですが、それはまた別の話ですね。

モノリスからモジュラーモノリスへ移行したことで、改修範囲の明確化、廃棄の容易さ、認知負荷の軽減につながりました。 導入当初は理解されませんでしたが、3年ほど経ってようやく5年目の社員から「モジュラーモノリス良いですね」と評価してもらえました。

使ってみて初めて良さが分かるものですが、複雑さや開発速度の低下に悩んでいる方にはオススメです。フィーチャートグルと同様に、技術面で導入可能かつコストパフォーマンスに優れ、企業活動や生産性を低下させにくい施策の一つだと思います。

次は早期発見の仕組み化についてご紹介します。

アイゼンハワー・マトリクスに照らすと、CTO室の役割は「重要だが緊急ではない」領域です。



赤色は必ず対応する人がいて、黄色は顧客の怒りを避けるために実行されます。青色は無意味なので行いません。しかし灰色については、放置し続けると、あっという間に問題が顕在化します。

横断チームは「重要だが緊急ではない」課題への取り組みを意識する必要があります。ただ、実際には日々の機能開発に追われていて、こういった課題にまで手が回りません。そこで私たちは、メンバーに向けて「CTO室便り」を発信しています。



「カオナビというサービスの価値提供を改善するためのヒントになりそうな指針を月イチで報告します。継続的にウォッチしていくことで、全体的な仕事のフローも改善され、働いている人たちが健やかになれることが目標です。」という文章は、2日かけて考えました。

というのも、報告された指標を指摘されて「CTO室便りで悪口を言われている。改善しなくては」と安易な解決に走る人が必ず現れることを私は知っているからです。そのため「これは単なる健康診断だから、気にしすぎないでね」という雰囲気づくりが非常に重要だと考えています。



内容はいたって真面目で、SPACEというフレームワークに基づいています。三つ以上の軸を選ぶことでバランスを取り、複数の要素を重ねて全体最適となる指標を選定しています。

また「カモペンズ」という謎のグループも存在します。これは書籍『カモメになったペンギン』から名付けたもので、中長期課題に勇敢に対応し続ける異色のグループです。有志が集い、週に一度「この中長期課題に取り組まなければ」と議論しながら活動しています。

「考える会」というのもあり、バックエンドとフロントエンドそれぞれに存在します。設計相談から中長期課題まで幅広く語り合う会で、カモペンズよりも実装面に寄っています。

このように、 普段の業務とは異なる場を意図的に設けることが重要です。 有志で集った活動が続く限り、企業は健全ですし、こうした仕組みは非常に大切だと思います。

また、誰でも利用可能な設計壁打ちの仕組み「設計レビュー」もあります。Slackワークフローから設計相談を起動すると、ベテラン社員が集まりレビューをしてくれるというものです。ただ、この「レビュー」という部分の改名が検討されています。というのも「レビュー」という名前だと、ちゃんとした資料を作らないとレビューしてもらえないのではないかと感じさせるようで、資料の提出が遅くなってしまいがちなのです。「若者の悩みを相談する場」のような、より気軽に利用できる名称を募集しています。

そのほか、私が所属するCTO室にはBERT（BackEnd Rearchitecturing Team）があり、垣根の低い相談会として「BERT相談会」も行っています。資料なしでも相談可能な仕組みです。本当は気軽に声をかけてほしいのですが、仕組み化した方が相談が来るため、Slackなどで「BERT相談会を開催しています」と通知するようにしています。

採用広報、教育などでも非常に多くの活動をしており、今回の講演もその一つです。社内勉強会も活発で、新入社員向けの「テラコヤ」という活動もあります。ちなみに、弊社では活動名を4文字のカタカナにする雰囲気があり、皆それに倣っています。

最も自慢の勉強会が、主に開発者が集まる「カタリバ」です。AIエージェント活用やユーザー目線の落とし穴といったテーマ例があり、時にはカンファレンス並みの質の高いトークが多数飛び出します。隔週開催のため年間24回行われる計算で、現在の開催数は143回ほどです。入社当初は発表者探しに苦労しましたが、最近ではメンバーから「そろそろ私も話したいのですが、枠を開けてもらえますか？」と逆提案してくれるようになりました。継続は力なり、ですね。

これまで各社で社内勉強会を企画してきた経験から伝えたいのは、 最低3人いれば何とか回せるということ。1人では厳しいですが、3人いれば再放送を交えつつ、なんとか場を維持できます。
長続きさせたい方は、ぜひご相談ください。

このほか「バーニャ」「イレヂエ」「マエムキ」など、分野別の社内勉強会や、野良読書会、グループ内勉強会などが多数立ち上がっています。講演活動も活発です。

CTO室主導の「kaonavi Tech Talk（カオナビテックトーク）」というYouTubeライブも配信しています。目的は、アウトプットや登壇練習、社内情報のアーカイブ化です。求職者の方がYouTubeアーカイブを見て応募してくれることもあるため、こうした活動を地道に続けることは非常に重要です。このライブ配信は社内共有としても機能していて、例えばチームAの活動をチームBに届けられる可能性があります。関わるメンバー全員が配信技術を習得できましたし、配信も上達しました。

カンファレンス参加も奨励しており、個人で「PHPerKaigi 2025」に参加したら弊社の仲間が15人ほどいました。非常に頼もしいです。若い世代には「外を見ることの重要性」を伝え続けていて、スポンサリングも大切にしています。カンファレンス参加実績はkaonavi developersでも公開されています。

▼kaonavi developers
https://note.com/kaonavi_devs

「数字」に囚われない愚直な改善を続けていく

富所：まとめに入ります。カオナビの開発組織が取り組んできたのは、愚直な組織改善です。

横断コミュニケーションを改善するにはどうしたら良いか、いろいろと知恵を絞りました。ただ声をかけるだけでは話してくれませんし、どうしたら自然に話してくれるかを考えました。

アイゼンハワー・マトリクスのような横断課題への対応を進めていくことも大切です。ほんの少しでも続けることで、チーム開発をしている人たちが「うちの会社はこういうものを改善する意識があるんだ」と夢と希望を持ってくれます。それは非常に大切なことだと思います。

他にも地味な採用活動を続けて、派手なことはせずに、ひとつずつ改善を積み重ねました。私以外にもたくさんの人が、RSGT（Regional Scrum Gathering Tokyo）に参加したり、スポンサーをしたり、ブログを書いたりといったことを少しずつ積み重ねてきました。

なお、楽しいことだけではなく、計測も当然行っています。利用実績データからアウトカムにつなげるようなことは当然やっています。ただし、ここが主軸にならないように注意しています。

▼計測に関する詳細：カオナビの利用実績をアウトカムへつなげる旅
https://speakerdeck.com/kaonavi/example-of-data-management-startup-in-kaonavi

また「アルゴス」というチーム成長サイクル支援も行っています。



他チームの成長のためにも各チームの活動を外に向かって発表してもらうなど、チームの成長を支援する活動です。

このように、カオナビでは本当に多くの取り組みを行っています。

開発生産性としての数値も取得はしていますが、アプリケーションは成長に伴い開発効率が落ちるものです。機能がたくさんあればあるほど、他の機能を気にしなければいけませんし、複雑性も増します。そのため、今の数値と過去の数値の単純比較には意味がないと考えています。

ただ、アルゴスの担当者たちと話していたら「大カイゼン時代を経てチームごとの開発体制が安定してきた今なら、健康診断の形でFour Keysなどをチーム成長の指標にするのはアリかもしれない」という意見がでました。そこで、現在はその辺りを検討しているところです。

ここに到達するまでに、6年ほどかかりました。不断の努力と改善活動、組織改善をした上で、ようやくFour Keysを使えるかもしれないという状態にまでいたるのです。

これが、リアルなSaaSの会社の姿だと思います。

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

アーカイブ動画も公開しております。こちらも併せてご覧ください。
※ご視聴には登録が必要です