わずか3ヶ月で「組織とシステム」を再構築。“理屈”以上に現場を動かす“納得感”のつくり方

急成長を遂げるスタートアップにおいて、避けて通れないのが「アーキテクチャや組織の負債」です。かつてはシンプルで見通しのよかったシステムや組織も、規模の拡大に伴い複雑化し、認知負荷や調整コストが増大するケースは少なくありません。

しかし、こうした状況を打破するためのリアーキテクチャや組織改革を成功させるのは、非常に難しいものです。抜本的な刷新を成し遂げるには、いったい何が必要なのでしょうか。

今回焦点を当てるのは、キャディ株式会社が挑んだ大規模刷新プロジェクト「BLITZ（ブリッツ）」です。2025年7月から9月にかけての集中期間でシステムや組織の構造を大幅に変え、現在も継続的に改善を続けています。いかなるマネジメント手法で、現場を動かしたのでしょうか。プロジェクトを牽引した取締役CTOの小橋昭文さんとCTO室長の山田圭一さんに話を聞きました。

事業成長を加速させるために。痛みの伴う大規模刷新を決断

――まず、「BLITZ」を実施した背景について伺います。事業と組織が拡大する中で、どのような課題が顕在化していたのでしょうか？

小橋：一言でいえば「システムや組織があるべき構造から乖離し、開発速度が思うように上がらなかった」という状態でした。前提として、ソフトウェアのアーキテクチャや組織の設計は、事業の構造と一致し、連動していることが望ましいです。しかし、事業の急激な変化に構造の再編が追いつかず、その乖離が大きくなると、さまざまな歪みが生じます。

「BLITZ」に取り組む前のキャディも、まさにその状態にありました。当時、私たちが認識していた主な課題は、調整コストの増大です。一つの施策を実現するために、常に複数チームの連携が必要な状況になっていました。

山田：それ以外にも、チームごとに品質基準や開発プロセスの考え方、取り組みに濃淡があり、それがプロダクト品質のばらつきとして現れていました。チームトポロジーの考え方を取り入れて自律的なチーム編成を推進していましたが、その反面、望ましくない方向で各チームのサイロ化も生じていたんです。これも当時の大きな課題の一つでした。

――大規模な刷新を行うのではなく、小規模なリファクタリングやチーム編成の変更を漸進的に進める選択肢もあったかと思います。あえて、組織とシステムの構造を根本から変えるプロジェクトを立ち上げた狙いは何だったのでしょうか？

山田：実は「BLITZ」を始動する前から、小規模なリファクタリングや基盤機能の設計には取り組んでいました。ただ、機能開発と並行しながら、こうした施策を進めるのには限界がありました。サイドプロジェクトとして進めてはいたものの、思うようにスピードが出ない状況が続いていたんです。

小橋：私たちは「モノづくり産業のポテンシャルを解放する」というミッションを掲げ、国内のみならず世界の製造業を変えようとしています。目指す事業成長のスピードはかなり速いです。アーキテクチャや組織の制約が、事業のボトルネックになってはいけません。そこで、変化には痛みを伴うことを受け入れた上で、一気に再構築することを決断しました。

▲小橋昭文さん

「製造業特有のデータの扱い」を主眼に。事業ドメインの特性や制約を、設計に落とし込む

――どのような基準で、アーキテクチャや組織の「境界」を定めていったのでしょうか？

小橋：こうした設計を行う際には、事業ドメインの特性や制約を考慮することが重要です。私たちの場合は「顧客のデータをどう守るか」を主眼に置いて、システムや組織の境界を定めていきました。

多くのテック企業にとって顧客データは重要ですが、キャディが特徴的なのは「製造業特有のデータの扱いの難しさ」がある点です。製造業では、各国の法規制やルールがデータの取り扱いと密接に関連します。例えば自動車産業であれば、各国の国交省にあたる機関が定めた法律を遵守しなければなりません。機密性の高い図面データなどは、輸出規制の対象にもなり得ます。

加えて、個人情報の取り扱いに関する法律も国ごとに異なります。仮に、個人情報を国外に持ち出すことが禁じられている国へ事業展開するのであれば、グローバル共通の認証基盤ではなく、国ごとに独立した基盤が必要になりますよね。

山田：こうした「事業としてデータを取り扱う上で、どのような制約や前提条件があるか」「それらを反映したアーキテクチャや組織の形は何か」を起点に、構造を考えていきました。

――大規模な構造改革となると、現場の反発や混乱も予想されます。メンバーに方針転換を伝える際、お二人がコミュニケーションにおいて心がけていたことはありますか？

小橋：こうしたプロジェクトを推進する際、マネージャーはメンバーに対して「決まった方針」や「正論」を伝えるだけでは不十分だと思っています。受け取る側が何を不安に感じているのかを、想像することが重要です。

例えば「チーム編成が変わって上長が別の人になると、評価基準はどうなるのか」「これまで一緒に働いてきた仲間との関係性は維持されるのか」といった、現場のメンバーが抱く懸念と向き合うことを意識しました。

山田：情報伝達という観点では、私も「一度伝えて終わり」にしないことを徹底していました。初回の説明で、方針を100%理解できる人はいません。そこで、ミーティングにて言い換えながら伝えなおしたり、個別に議論の時間を取ったりするなど、納得してもらえるまで対話し続けました。

小橋：こうした「メンバー一人ひとりに方針を伝える」というプロセスで欠かせないのが、各部門のマネージャーとの連携です。経営層など一部の人間がどれだけ発信に尽力しても、組織の規模が大きくなれば、社員全員に意図を浸透させるには限界があります。

社員が日常的に接しているのは直属のマネージャーです。そこで、マネージャーたちが方針を正しく理解し、納得した上で、自分の言葉でチームに説明できる状態をつくることに注力しました。現場にいるマネージャーやリーダーたちに、可能な限り権限と情報を託すことを重視していました。

余談ですが、キャディにはエンジニア組織の設計・採用・評価・育成を担うVPoE室という部署があります。VPoE室が「開発組織をよい状態に保つ」という役割を常に担ってくれたからこそ、大きな変化の中でも組織の混乱を最小限に抑えられたのだと考えています。

――大きな変化を起こす際には、「組織を良好な状態にするための体制や仕組み」もセットで用意する。他の企業にとっても非常に参考になる考え方ですね。

山田：また、今回の刷新と並行して技術組織のプリンシプル（思考や行動の指針）を策定・発信したことも重要なポイントでした。技術選定やアーキテクチャ設計における思考の土台を言語化し、エンジニア全員に判断基準を共有したことで、現場での意思決定が非常にスムーズになりました。

▲山田圭一さん

かかるコストは大きい。だが、「私たちはどうありたいか」が全員に伝われば組織は動く

――2025年7月から9月にかけての集中期間を経て、現時点ではどのような変化を実感されていますか？

小橋：チーム間の調整コストが劇的に下がりました。以前は一つの機能を修正するにも複数チームとの合意形成が必要でしたが、システムの境界を整理したことで、各チームが独立して動ける範囲が広がっています。

また、境界が明確になったことで、現場のメンバーも「この施策を実施する際、誰に相談すべきか」「誰が意思決定者なのか」を迷うことがなくなりました。この土台ができたことで、今後さらに事業が拡大しても柔軟に対応できる確信を持っています。

山田：アーキテクチャの再設計だけでなく、各チームの役割を再定義・明確化したことが功を奏しました。個々のチームに権限を委譲しても、彼らの行動が全社的な方針から外れることがありません。自由と統制が両立している状態です。

――今回の「BLITZ」の事例を踏まえて、読者に伝えたいことはありますか？

小橋：大前提としてお伝えしたいのは、今回のように構造を大幅に変えるプロジェクトは現場の痛みも大きいため、安易に真似をしないほうがよいということです。

プロジェクト名の「BLITZ」は、リード・ホフマンの著書『ブリッツスケーリング』から引用しています。これは、圧倒的な成長や異次元の結果を実現するために何が必要かを考える思考法です。

私たちには「世界中の製造業を変革する」という巨大なミッションがあり、それを自分たちの手で達成したいという強い意思があります。もともと全員がこの目標に対しての強い共感があるため、認識さえ揃えば前に進みやすい組織でした。

その背景があったからこそ、集中的にリソースを投下し、大幅な変化に踏み切りました。こうした「異次元の成長を目指す」という前提がなければ、むしろ混乱を避けるために実施しないほうがよい施策かもしれません。

その上で、同様の施策を推進する際に何より優先すべきは、「組織をどう動かすか」に尽きます。今回痛感したのは、言語化とコミュニケーションの重要性です。プロジェクトを推進する人たちの思考をわかりやすく言葉にし、携わるメンバーの全員が同じ認識を持てるようにする必要があります。

山田：重要なのは、現状の組織構造やアーキテクチャ、業務フローなどを徹底的に分析し、境界線が複雑に絡み合っていないかを見極めることです。複雑度が高い箇所があるのなら、境界を整理することで業務効率が向上する可能性があります。

加えて、どれだけ仕組みを整えても、開発組織の全員が同じ方向を向いていなければ、結局は非効率なコミュニケーションが発生してしまいます。全員の目線を合わせるために、ビジョンを定め、組織としての判断基準を設け、チームの役割と責任を明確にすること。それが、複雑な構造を改善する第一歩になるはずです。

――最後に、今後同様の取り組みを行う技術リーダーたちへアドバイスをお願いします。

小橋：会社のミッションやビジョンを「自分たちの組織やシステムにおいてどう表現するのか」に落とし込み、目指すべき品質を確立することが重要です。そして、品質についての認識がメンバー全員で揃っている必要があります。「私たちはどうありたいか」というスタンスが明確になれば、さまざまな施策の是非を判断しやすくなるはずです。

山田：世間一般のベストプラクティスをそのまま取り込もうとしても、うまくいきません。自社が置かれているコンテキストを深く理解し、それに合わせて施策を泥臭くカスタマイズしていく必要があります。

そして、改革を進めようとすると、想像以上に多くの困難にぶつかります。プロジェクトを推進するリーダーは孤独になりやすいものです。私自身も、「この伝え方でよいのか」「この方向性で合っているのか」と常に悩み続けています。

だからこそ、技術面でも組織面でも「信頼して背中を預けられる仲間」を早めに見つけてください。共に悩み、助け合いながら進める仲間の存在は、何よりも大きな力になると思います。

※2026年4月2日 13:00　本文の一部を更新しました。

取材：中薗昴、池田恵実
執筆：中薗昴
編集：池田恵実
撮影：山辺恵美子