matsuri technologiesの事業紹介と登壇者自己紹介

前島：こんにちは、前島です。暑い中お越しいただきありがとうございます。AI前提における組織の進化というところで、本日お話しさせていただきます。

自己紹介の前に、まずmatsuri technologiesについて知っていただきたいと思います。スタートアップとして10年の会社で、最近赤坂の永田町、議員会館のほぼ真裏に移転しました。テクノロジーを活用して意味ある新産業を作り続けることをミッションに置いていて、宿泊だけを見据えているわけではなく、目指す世界線として「旅とすまいの自由を全ての人に」を掲げています。

普通の物件に社内のインテリアデザイナーが企画した家具等を配送して宿泊施設として立ち上げ、物件のオーナーには収益性の向上を、ゲストには1日単位でお得に借りたり短期賃貸として使えることを提供しています。裏側のオペレーションもソフトウェアで支えていて、集客・プライシング・在庫管理・無人チェックイン・ハウスキーピング管理まで自前でやっています。今110億円ほどの売上まで成長し、ニューヨークにも進出しながら4,000室運営しています。

改めまして私、前島と申します。matsuri technologiesでVPoEを務めています。最初ITコンサルからキャリアをスタートし、2016年からスタートアップの世界で開発の部門長をやりながら、2021年には人事責任者も1年半ほど経験しました。2025年にVPoEとして参画し、先月まで人事部長も兼任していました。ではここから、執行役員CTOの石橋にお渡ししたいと思います。

石橋：ではここからは石橋からお話しします。私は2019年8月からmatsuri technologiesにCTOとして入社し、今は執行役員CTOをやらせていただいています。予約管理システムや清掃管理システム、マンスリーマンションのプラットフォームのようなもののシステム開発をアーキテクトや開発者として牽引してきました。直近ではAIによる生産性向上に取り組んでおり、マネージャーとしてだけでなく自分でも手を動かしながらやってきたので、そのあたりを今日お話しできればと思います。

AI前提で問い直す開発生産性指標 — Four KeysとConwayの法則

石橋：まず今日の問いですが、AI時代の開発と組織の問いを考えるということで、AIによって今後の開発はどう変化していくのかを一番考えています。Four Keysのような指標は今も果たして有効なのか、コンウェイの法則は今後も生き残っていくのか、という問いを立ててみました。

これまで生産性の指標は、いずれも人間が作業の主体だったわけです。ただAIが進化してきたので作業の主体が人間からAIに移ってきていて、生産性の指標も今一度考え直す時期に来ていると思っています。弊社はエンジニアが15人ほどの組織なんですが、この2年でエンジニアの数は1.5倍くらいになりました。それに反してプルリクは5倍、新しいアプリの数は8倍になっています。これは人の数が増えているからではなく、変化が起きているということです。

Four Keysだけでは感度が足りないので新しい指標を作っていく必要があると考えていますし、コンウェイの法則についても人間からAIへのシフトが必要で、AIのコンテキストに詰め込める範囲が今後チームを切る境界になると考えています。そうなったとき、開発チームに切るAIは加速装置というよりは増幅装置です。すごくよく使いこなす人とそうでない人の差がより広がる仕掛けになっているということです。

私の直近1年ぐらいのプルリクエストの数を見てみると、今年の4、5月あたりを境に広がっていて、平均で今までの20倍を超えるプルリクの数になっています。気にしてほしいのは、4月あたりを境に働き方、開発の仕方がそもそも変わっていることです。プロンプトを与えていたところから、ループを設計する方向に話が変わっています。1回のルーチンでとあるスキルが起動し、リポジトリのissueをスキャンして取り組み、調査やissueの分解が必要ならrefineし、実装ができると思ったら実装し、レビューコメントが付いたものは自動で修正する。これを数時間おきに回しているだけになります。

レビュー・リリースの自動化とエンジニアに残る仕事

石橋：これをやるにあたって、どこにボトルネックがあったかという話をします。AIが出てきてコーディングエージェントがコードを書けるようになると、まず最初に詰まるのはレビューです。プルリクがたくさん出てきて、出す側は待ち時間が長く感じ、レビューする側は大変な状態になります。

弊社の場合、AIレビューを自作しました。プルリクのリスクが高いものと低いものをAIのボットが識別し、リスクが低いものはAIがそのままアプルーブして一定時間後にマージする仕組みです。全体の8割ぐらいはAIが承認していて、人間が見るのは2割。レビュー量が5分の1になっているということです。

レビューの負荷が下がると、次はリリースのリードタイムが詰まるようになりました。メインブランチには入ったけどデプロイブランチに入っていない待ち時間が長くなってきたので、リリースプルリクを自動化しました。

毎日リリースプルリクを出してマージしていいかを判定し、リスクが低いものは自動でマージします。内部統制的な要件もあるので何でもマージしていいとは思っていませんが、それでも全体の4割ぐらいは自動でできています。

リリースができるようになると、今度はissueを起票してからrefineしたり、大きなissueをどう分割するかが問題になります。issueを自動で分割する仕組みや、フェーズ分けしてゲートを作る仕組みを入れて、きれいに動くようになりました。最後に残ったのはissueを起票する部分、つまり意思決定です。何をこの機能としてアプリに入れるか入れないか、この意思決定は最終的には人間がやる作業になります。

人間の関与領域はどんどん左に移っていって、なるべく上流の時点で問題が起きるのを防いだり方針を正しく設定したりすることを考える必要が出てきます。エンジニアの最終的に残される仕事は、この2つに集約されると考えています。1つはPdMのような、シャープな意思決定をする能力。もう1つはハーネスエンジニアリングのような、AIが最速で走っていける環境を作れる能力です。それ以外は全部AIが主体になっていくだろうと思います。

KPIダッシュボードで見えた組織全体の変化

これぐらいアウトプットが増えてくると、KPIも作り直さなければいけないと思っています。Four Keysも指標の1つとして使えますが、感度が足りないと感じることがあります。Four Keys自体のスコアはほぼ横ばいですが、ボトルネックが実装から会議や作業待ちに移ってきています。コードだけでなくもっと上流の、プロジェクトやタスクそのもののボトルネックを追いかける指標が必要だと考え、弊社では独自にKPIダッシュボードを構築しています。

ここまでで人間がアウトプットする量は増え、測るための指標もできました。次に開発部のマネージャーとして考えるべきは、これをどう広くコモディティ化するか、同じことができる人を何人増やせるかです。組織全体のプルリクの数を見ると、5月ぐらいを境に平均5倍ぐらいになっています。1人が頑張っているだけかというとそうでもなく、月100本ペースの人が上位4人、50本に拡大すると全体で12人という形で、アウトプットが増えている人はたくさんいます。組織の中に伝播が始まっている状態だと考えています。

これを実現するために、Claude Teamプランを希望者全員に配布し、全社で100ちょっとアカウントを導入しています。レビューbotや自動リリースの仕組みも、どのリポジトリでも使えるように展開し、ループエンジニアリングの部分もリポジトリにして全員に配っています。個人の学習をいかに組織の資産に変換するかが今後重要になってくると考えていて、AIの課金額とそれでどれだけのリポジトリをメンテナンスできているか、ROIを正確に理解して出していくことが我々開発部の一つのミッションになると思っています。

採用・オンボーディングから作り変えるレバレッジ型組織

前島：エンジニア何人必要なんですかってところですが、この急スピードでトレンドが変わっていく中で、一人当たりのレバレッジをどう最大化し、処理能力をどうスケールさせるかという組織設計が必要になってきます。

少人数で処理能力が高い組織にしていかないといけません。AIが人員として計算される中で、少数精鋭で高レバレッジな人が意思決定に集中する、という形で組織を大きく作り変えていく必要があります。

そのためにはどこから始めればいいのかというと、採用から変えないといけません。途中から変えても大きな変化にはならないので、採用・オンボーディング・アクセラレーション・キャリア設計を全て見直し、投資することが重要になります。会社理解とドメインの理解を最優先し、理解が早いほど立ち上がりが早くなって、エンジニアが出すLTVが上がってきます。採用基準も引き上げて、カルチャーフィットやROI視点をしっかり見ていく必要があります。

投資回収期間はAIがここまで発達していない状態だと大体約11ヶ月かかっていました。オンボーディングも最低3ヶ月かかっていたところを、AIがある前提で全部変え、立ち上がりは1ヶ月で立ち上がっていないと遅い、という判断基準にした方がいいと思っています。効率化して生まれた時間は未来の仕込みに再投資するところが重要で、効率はゴールではなく開発資本をどれだけ増やせるかです。キャリアパスも再定義し、PO・PdM・EMの計画的な輩出を、これまで以上に設計してあげる必要があります。

実際にプルリクの数を見ると、6月からチームを増やして1チームの人数を減らしたところ、全体のプルリク数もデリバリーも増えています。何より重要なのはコミュニケーションラインを少なくすることです。人数が多いと意思決定のスピードが遅くなるので、ここはちゃんと仕組みを作ってあげる必要があります。

開発資本と開発生産性の指標は、経営レイヤーで見るものとチーム層で見るものが圧倒的に違います。開発するアウトプット・アウトカムがPLにつながり、最終的にBSとして資本が積み上がらなければ意味がないということで、指標をかなり再整理しました。エンジニアLTVも、何をもって障害活動するのかという設計をこれまで以上に解像度高くできるようにならないといけません。ここをしっかりやることで、AIのトークンも含めてどれだけ投資すればどれだけのリターンがあるかを、これまで以上に精度高く計算できるようになります。エンジニアの人件費は固定費でしたが、これからはAIの投資・コストを人件費とセットで考えると、変動費としてROIマネジメントする形になるかなというところです。

まとめ

最後にまとめですが、組織作りというところでは、採用からキャリア設計まで大きく変えていきましょうということです。ここまでお話ししてきた通り、AIを前提にした開発生産性の指標作りと、レバレッジ型の組織設計はセットで進めていく必要があると考えています。

石橋：開発のワークフローに関しては、さっきお話ししたような、全員が10倍になるのが当たり前の世界がやってきます。それをベースにした中で、どうやって開発フローをチーム内で作っていくか、そういったところを考えていく必要があるかなと考えています。

前島：エンジニアの皆さん、仕事を奪うものではなく資産を上げるものだという捉え方をしていただいて、ぜひmatsuri technologies、事業を一緒にドライブしてくれる仲間を募集しております。

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

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

▼動画はこちら

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