こんにちは、株式会社カンリーの波多野（@hatamasa1988）です。
カンリー店舗集客プロダクトのエンジニアリングマネージャー（EM）をしています。

今回は、最近社内外でわりと話題になる「AI時代においてのEMって、結局なにをやる人なんでしたっけ?」という興味深いテーマかと思うので、そこに対してカンリー店舗集客チームでの取り組みについて書こうと思います。

ChatGPTやClaudeが普及してからこの2〜3年、開発の前提は変わり続けています。実装スピードは明らかに上がり、少人数のチームでも、以前なら考えられないような規模の機能を出せるようになりました。このあたりは、多くの方が実感されているところかと思います。

ただ、スタートアップの現場でEMをやっていて、自分なりに感じているのはそれだけではありません。

AI時代に起きているのは、単なる開発速度向上ではなく、ボトルネック移動速度と負債蓄積速度の高速化だと感じています。

作れることが増えたぶん、設計のズレや責務の崩れ、コンテキストの欠落といった「以前からあった問題」が、以前より速く広がるようになりました。

そうなってくると、EMの仕事は何なのか、というのが自分の中でわりと真剣な問いになりました。
進捗管理者として人を細かく見るのか。レビューの最終ゲートを担うのか。それともそれ以外なのか。

この記事では、カンリー店舗集客の現場でやっていることを起点に、その問いに対する自分なりの整理を書いてみます。

先に結論だけ言うと、自分の中では「AI時代のEMの仕事は、組織のハーネスエンジニアリングである」というのが現時点の答えです。
AIエージェントを安全かつ高速に走らせるための装具（ハーネス）を整える、という意味でのハーネスエンジニアリングを、人と組織のレイヤーで実践している、という感覚に近いです。

株式会社カンリーのAI利用状況についてはテックブログをざっくりでも見ていただければ把握できると思うので、よければどうぞ！
https://zenn.dev/p/canly

カンリー店舗集客の現在のフェーズ感

最初に会社、プロダクト、チームのざっくりなフェーズ感をお伝えしておきます。

株式会社カンリーについて

株式会社カンリーは「店舗経営を支える世界的なインフラを創る」をミッション、「人とAIの力で店舗の集客力を上げる」ビジョンを掲げ、店舗事業者向けに複数プロダクトを開発運営している現在8期目のスタートアップです。
https://biz.can-ly.com/
社員数は180名、エンジニアは業務委託を含めると60名の規模の組織になっています。

カンリー店舗集客について

https://jp.can-ly.com/?_fsi=FD4JZHnq

カンリー店舗集客は2025年2月にフルリニューアルのMVPがカットオーバーし、その後機能追加と顧客移行を順次行っているタイミングです。
この記事を執筆している2026年6月上旬で40%程度の顧客を移行済みの状態です。

プロダクトチームはEM4名、エンジニア18名、QAエンジニア3名。
計3チーム（QAチームは別）に分かれており、1チーム5,6名程度といった規模になります。
デザイナー、PdMは横断的な関わりになっているので関わっている人数は前後しますが、それぞれ3名程度が関わっています。

初期の課題感

私がEMとして関わり始めた初期の課題感としては下記のようなものがありました。

• スクラムは導入して回っていたが、中長期のゴールがモヤっとしている状態
• メンバーのモチベーションや主体性は高いが、どこかしら自信がない状態
• 職種間やチーム間での連携に課題は感じているが、何から初めて良いのかわからない状態
• 技術品質に課題は感じているが、何から手をつけて良いのかわからない状態

EMの私も全てのスクラムイベントに出席し、チームの意思決定を支えるような自律自走のレベルとしてはもう一歩な印象でした。
AIが一部の人に浸透し始めており、コーディングのマインドシェアから解放されたメンバーからも上記のような相談が目立つような状態でした。

MTGやコミュニケーションにてEMの工数がかさみ、ボトルネックになり得る状態であったため、ここで一念発起してEMとして交通整備を始めることにしました。

AI時代に必要になる「自律自走する組織」

最初に置きたい主張があります。

AI時代には、EMがすべての判断やレビューを握る組織はスケールしません。

少し前までは、EMがレビューと意思決定の最終受け皿になる構造で、まだ何とか回っていたと思います。実装スピードとレビュー量が、そこまで非対称ではなかったからです。

ただ、AIによって実装スピードが上がり、意思決定の回数も増え、問題解決のサイクルも速くなった結果、EMがレビュー・判断・調整を全部抱える形は、わりと一瞬で詰みます。EMそのものがボトルネックになる速度も、明らかに上がっていると感じています。

なので、各メンバーやチームが、自分たちで判断して前に進められる状態を作るのが、まずは前提になります。

個人的に大事にしているのは、「自律自走」を、組織のミッションからチーム戦略、アーキテクチャ、最終的に書かれるコードに至るまで、すべてのレイヤーがアラインしている状態として捉え直すことです。

このアラインが取れないままAIで実装スピードだけが上がると、

方向性のズレや構造的負債が、これまでとは比較にならない速度で拡大します。

逆にいえば、組織からコードまでアラインしているからこそ、それぞれが自分で判断して前に進めます。

自分の中での自律自走の定義は、

組織からコードまでがアラインした状態で、それぞれが自分で判断できる組織

です。
このアラインを作るためにEMとして何を整備すべきか、というのがここから先の話になります。

方向性を揃えるためのオンサイト合宿

カンリー店舗集客では、四半期ごとにオンサイト合宿をやっています。

合宿というと、いわゆるチームビルディングを想像されることが多いんですが、自分たちのなかでは少し違う位置づけにしています。

合宿は、「振り返り」と「向き直しの場」として設計しています。
そしてエンジニアだけでなく、PdMも含めた場にしているのもポイントです。

最初の合宿のテーマは、「我々はなぜここにいるのか」でした。
判断基準を作るためではなく、プロジェクトとして目指す方向をすり合わせるために、このテーマを置きました。

直近のフェーズの話で言うと、いま店舗集客プロダクトはリニューアルのカットオーバー後で、既存顧客の移行フェーズに入っています。地味に重たい時期です。
新機能をどんどん出すフェーズではなく、移行を完遂しにいくフェーズなので、人によって温度差が出やすい局面でもあります。

直近の合宿では、CPOによるトークセッションを実施しました。
そこで共有したのは、

• なぜ移行完遂が重要なのか
• リニューアルそのものの意義
• 移行完遂後にどんな未来が待っているのか
• 顧客と事業にとって、これがどういう価値になるのか

といった、「何をやるか」より一段手前の話です。

ここでEMとして大事にしているのは、自律自走には「目的理解」が要る、ということです。
何をやるかだけでは、AIで実装スピードが上がった分だけ早く迷子になります。
なぜやるかが揃っている状態で初めて、各自の判断が同じ方向を向きはじめる感覚があります。

高速に動ける組織ほど、定期的に向き直す場が必要になります。

合宿を「やってる感」のあるイベントとして消費するのではなく、PdM/EM/エンジニアが、毎四半期ちゃんと同じ方向を向き直す場として運用していること自体が、わりと大事だと思っています。

自律自走を支えるOKRの再定義

また最近は、OKRの整備も進めています。
以前から目標管理制度としてOKRを運用していましたが、このタイミングで本来のOKRとしての運用を強化することを意思決定しました。

AI時代のスピード感に追従するには、EMが逐一管理するのではなく、各チーム・各メンバーが自分で判断できる状態を作る必要があります。

「今、組織としてどこへ向かうのか」

を同期する仕組みが以前より重要になっています。

自分たちにとってOKRは、管理強化のためではなく、自律自走する組織が同じ方向を向くためのフレームの一部と考え、今まで取り組んでいたOKRをより本来のOKRに近い形で再定義しました。

詳しい内容は以前投稿した記事を参照していただければと思います。
https://zenn.dev/canly/articles/31d3cae0bf5755

方向性だけでは足りない。構造も必要になる

ただ、方向性を揃えただけでは、高速に動く開発組織は維持できません。
これも現場感としてはっきりあります。

AIによって実装速度が上がるほど、

• 他チームからの修正
• 横断的な変更
• AIによる大量実装
• 認知負荷
• 暗黙知への依存

このあたりが、めちゃくちゃ速く負債化していきます。
メンバーが細かいコードへのマインドシェアを割かなくなった分、設計やアーキテクチャの揺れが頻繁に言及されるようになってきました。
アーキテクチャの揺れがコミュニケーションコストになり、新しくボトルネックとなった状態です。

そこでEMとして、アプリケーションアーキテクチャの整備を進めました。

目的は、技術標準化そのものではありません。

• 開発速度を維持しながら、
• 他チームからの修正も受け入れやすい状態を保つこと

が、本来の目的です。

具体的には、

• どこに何を書くか
• 責務をどう分離するか
• 依存関係をどう整理するか

を、チームの共通言語として定義しました。

ここで個人的に意識しているのは、

自由に開発できることと、他者が変更可能であり続けることは別の問題です。

ということです。自由に書くだけなら誰にでもできます。AIに任せればさらに速い。ただ、半年後に別のチームから直せるかどうかは、構造を整えていない限り保証されません。

アーキテクチャは、自律自走を支えるためのインフラ、つまりハーネスの一部だと位置づけています。

アーキテクチャをClaude Codeのコンテキストに落とす

ここからAIに踏み込んだ話になります。

定義したアプリケーションアーキテクチャを、Claude Codeのコンテキストに落としています。

CLAUDE.mdや関連ドキュメントを通して、

• このプロジェクトはどんな責務分離をしているか
• どこに何を書くべきか
• どういう依存関係を許容しないか

を、AI側にも前提として共有している状態です。
言語化されていない慣習に従うことは難しいですが、それを規約に落とし込むことができれば生産性は上がることは、人もAIも同じという考え方です。
規約なしにAIでコード生成しまくると、チームの設計思想とどんどん乖離していきます。これをやると、AIで実装速度が上がるほど、設計崩壊も速くなる、というあまり嬉しくない現象が起きます。

AIを活用する組織では、人間だけでなく、AIともコンテキストを共有する必要があります。

ここの感覚はEM視点だとわりと重要で、AIを「外部のすごい人」ではなく、「チームに新しく入ったメンバー」として扱っているイメージに近いです。新メンバーにオンボーディングをするのと同じように、AIにもオンボーディングをする。雑に言うとそういう話です。

このコンテキスト整備は、ハーネスエンジニアリング的にいうと「AIエージェントに与える環境とルール」の部分にあたります。AIを縛りつけるのではなく、AIが組織と同じ方向に走るためのレールを敷く、というニュアンスです。

Claude CodeによるAIレビューをガードレールにする

ここまでで、

• 方向性
• 構造

までは整えた、という前提の話に進みます。

自律自走には、自由だけでなくガードレールも必要です。

カンリー店舗集客では、Claude CodeによるAIレビューをガードレールとして整備しています。
レビュー観点として置いているのは、たとえばこのあたりです。

• アーキテクチャ逸脱
• 責務崩壊
• 意図しない依存
• 設計方針からのズレ

目的としては、

• EMやリードだけが全レビューを担う構造をやめる
• ただし無秩序にもしない
• 一定の構造と品質を、AIレビューで保つ

というところに置いています。

人間レビュアーを増やすのは大事ですが、それだけだとレビュー観点の属人化を生みますし、AIによる実装速度に対して、人間レビューが追いつかない場面も出てきます。そこを、AIレビューに「一段目のフィルター」として入ってもらう構成にしています。

AIは開発を高速化します。ただ、ガードレールなしで高速化すると、設計崩壊も高速化します。だからこそ、自律自走には「壊れないためのフレーム」がセットで必要になる、というのが現場での実感です。

自律自走する組織には、自由だけでなく、壊れないためのガードレールが必要です。

ガードレールはハーネスの中でも、いちばん手触りに近い部分です。AIに走ってもらう範囲を決め、外れたら気づける仕組みを持っておくことで、人間の認知資源を本当に必要な判断のほうに残せる、と感じています。

AI時代のEMは「管理者」ではなく「ハーネスを作る人」になる

ここまで書いてきたことを、自分なりに抽象化しておきます。

AI時代のEMの役割は、

人を細かく管理することではなく、

組織が壊れず高速に進み続けられるハーネスを設計すること

に変わっていく、と個人的には強く感じています。

カンリー店舗集客でやっていることを、ハーネスエンジニアリングの構成要素として整理すると、結局この3つに収束します。

1. 方向性を揃える

• 四半期ごとのオンサイト合宿
• 振り返りと向き直し
• PdM/CPOを含めた方向性共有
• 「なぜやるのか」の共有
• OKRの強化

2. 構造を揃える

• アプリケーションアーキテクチャの定義
• 変更容易性の確保
• 他チームからの修正可能性
• 認知負荷の低減

3. ガードレールを作る

• Claude Codeへのコンテキスト投入
• AIレビュー
• アーキテクチャ逸脱の防止
• 高速化しても壊れないフレーム

そして自分の中で、結論として持っているのがこれです。

自律自走する組織とは、何も管理されていない組織ではありません。

方向性・構造・ガードレールというハーネスが共有されているからこそ、それぞれが自分の判断で前に進める。

そういう組織です。
自由と統制の対立ではなく、両立を「ハーネス」で実現する話なのだと思っています。

まだまだ道半ば、だが変化が出てきている

幅広く様々な対応をしてきましたが、徐々に変化を感じ始めています。
私はほぼ全てのスクラムイベントから解放され、中長期の未来や、本当に重要な課題や意思決定に時間を割けるようになりました。

職種やチーム間の連携についても、お互いに歩み寄るという意識づけができたことで、連携MTGがより密度濃く実施されたり、以前よりも相互理解と深いコミュニケーションができて連携が改善されつつあるとメンバーからも評価をもらうことができました。

合宿でメンバーが自らディスカッションする中で、リニューアルカットオーバー後の顧客移行を「顧客に対して本当の意味でのリニューアルのリリースになる」と価値の再定義を行ってくれました。
合意を結んだ個社ごとに移行していき、1社ごとにコツコツとした作業が必要でモチベーション低下の懸念がある時期です。
メンバー自ら価値を見出して取り組めている価値はとてつもなく大きいです。
それぞれのメンバーもチームと自身の価値が明確になったことにより、自信を持って業務に取り組めていると感じます。

アプリケーションアーキテクチャとハーネス/ガードレースを定義したことにより、開発生産性は飛躍的に上がっています。
現状計測できている指標で、lead time が 47%に短縮し、deployment count も 1.78倍になっています。
カンリー店舗集客のリポジトリに他チームで改修を行う場合に、アーキテクチャが慣習に留まっており、言語化されていなかったため、他チームからの修正ではPRレビューのタイミングでアーキテクチャ・設計レベルの指摘が多発して大幅な修正コスト（または、やむを得なく負債）になっていました。
それが、現在ではリポジトリのアーキテクチャを言語化し、それをハーネス/ガードレールに落とし込んだことにより、ほぼワンプロンプトでAPI一本仕上げられています。
かつPRレビューでも大きな指摘することなく生産可能になっています。
もし、アーキテクチャが定まっていなければハーネス/ガードレールの完成も困難だったでしょう。

おわりに

AIによって、「どう作るか」のコストは、確実に下がり続けています。
一方で、

• なぜ作るのか
• どこへ向かうのか
• どういう構造で作るのか
• どう壊れずに進み続けるか

の重要性は、以前よりむしろ増していると感じます。

AI時代のEMに必要なのは、管理を強めることではなく、組織が自律的に進めるための方向性・構造・ガードレールを整えること。
ひと言でいえば、組織レイヤーでのハーネスエンジニアリングなのだと思います。

カンリー店舗集客では、これからもこのハーネスを磨きながら、PdM/EM/エンジニアが同じ方向を向きつつ、それぞれが自分の判断で前に進める組織を作っていきます。

このあたりの話に興味のあるEM・テックリード・スタートアップのエンジニアの方は、ぜひXあたりで雑談しましょう。
カンリーの開発組織に興味を持っていただいた方は、採用ページもチラッと覗いていただけると嬉しいです。

ではでは、またよろしくお願いします!