【CTO×VPoE対談】お客さまへ価値提供できるエンジニア組織へ—AI、自動化による開発スピードアップと組織構造の変革を目指す

※このストーリーは、noteで発信した記事を転載しています。

こんにちは！ カンリーでエンジニア採用を担当している宮本です。

今回は、ボードメンバーに”カンリーの未来”について話を聞いてみる企画の第5弾、いよいよ最終回となります。

テーマは、2025年2月にリリースした「カンリー店舗集客」のリニューアルプロジェクトについて。プロジェクトの立ち上げから関わっていたVPoE長谷川と、プロジェクトの途中からジョインしたCTO小出に、当時を振り返りながら話をしていただきました。

執行役員CTO　小出 幸典

慶應義塾大学大学院修了。アクセンチュア株式会社を経て、2014年7月に株式会社Gunosyへ入社。メディアプロダクトの配信アルゴリズム開発や、全社データ基盤構築等を担当し、2019年7月にCTOに就任。2022年より業務委託としてカンリーの事業に携わり、2024年9月に執行役員CTOに就任。エンジニア部を管掌。

▼参考記事：カンリーのエンジニアかくあるべし

VPoE　長谷川 稜

大学卒業後、システム開発会社にてサービスの開発に従事。主にインフラ設計、サーバーサイドの設計を担当し経験を積む。その後、アプリ広告 ASPの会社の立ち上げに関わったのち、独立。フリーランスエンジニアとして3年間活動。カンリーの創業初期にCTOとして成長し続けるチーム作りを目指す。

▼参考記事：カンリーのCTO譲りました！自分よりも優秀な人を採用していく組織カルチャーとは

​​苦渋の決断？それとも合理的判断？ リニューアルプロジェクトでビッグバンリリースを選んだワケ

宮本：
まずは、リニューアルプロジェクトの経緯をお聞かせいただけると嬉しいです。

長谷川さん（以下、長谷川）：
実は、「カンリー店舗集客（※1）」をリニューアルしようという話が最初に出たのは、今から3年前、2022年でした。リニューアルの背景、目的は、大きく3つありました。
（※1）カンリー店舗集客：ホームページやGoogleマップなどを効率的に管理できるツールで、広告に頼らず自社の力で集客できるよう支援するサービス

ひとつめは、バグやエラーの増大により、エンジニアとカスタマーサクセス（以下、CS）の対応工数が増えてしまっていたこと。特に、リリースをしてから1年ほどは、新機能開発を優先していたので、技術的負債が溜まってしまっていたんですね。この問題を根本的に解決するために、バグやエラーを生み出さないシステムの構築が必要だと判断しました。

ふたつめは、中長期視点でプロダクトの成長を加速できる体制作り。バグやエラー対応に多くの時間を取られるようになってしまっていて、お客さまの要望への対応やグロースに向けた施策がほとんどできていない状態でして。そこで、アーキテクチャ・データベースなどを見直し、再構築することで、プロダクトの成長を基盤から支えられるようにしたいと考えました。

もうひとつは経営的なところで、プログラムや品質に問題があったためです。インシデントが起きないようセキュリティの見直しをしたり、継続的な運用体制を作るべきだという判断に至りました。

小出さん（以下、小出）：
このときはたしか、カンリーホームページ（※2）の立ち上げも同時に進めていたんですよね？
（※2）カンリーホームページ：「カンリー店舗集客」に付随して利用できるサービスで、自社ホームページ内に使いやすい店舗検索ページを作成できる

長谷川：
おっしゃるとおりです。もちろん同時に進めたかったのですが、当時の予算や開発体制では、どうしても2つのプロジェクトを両立するのはむずかしかったんですね。このときカンリーホームページの開発を優先し、リニューアルプロジェクトはいったんペンディングになりました。

残念ではありましたが、無理して両方進めて共倒れになったら元も子もないですからね。それに今現在、カンリーホームページは大きな事業の柱になっているわけですから、この時の意思決定はあっていたのかなと思っています。

このあと、2023年の1月にカンリー店舗集客に新しいEMがジョインしてくださったのが、大きなきっかけになった気がします。

プロダクト部とも相談した上で、「やはり、リニューアルはしたほうがいい」という提案をしてくださって。その後、2023年7月にリニューアルプロジェクトが再始動したという流れだったかなと思います。

小出：
僕自身、途中で参画したときに考えたのですが、やっぱり段階的リリースのほうがよかったのでは、と思うことがあったんですよね。そもそもなんで、ビッグバンリリースで進めることになったんでしたっけ？

長谷川：
小出さんのおっしゃるとおり、段階的リリースのほうが影響範囲も少ないし、心理的な安心感もあるというところで、検討はしていたんですよね。

一方で、段階的リリースにすることで、考慮しなくてはならないことや工数が膨大になってしまう可能性があったんですね。たとえば、カンリー店舗集客だけで完結しないことが、ひとつ大きな壁になっていました。カンリーホームページなど付随するサービスにも影響が出てしまうので、しっかり考えるべきだなと。

ほかに懸念点となっていたのが、データベースのところですね。かなり大幅にデータベース構造を変えようとしていて、そうなると、新しいデータベースと運用しているデータベースをどう並行稼働していくのか、どのように移行させてしていくのか、といった問題がどうしても出てきてしまいます。

こうしたところを考慮しながら開発や改修を行っていくのは、工数があまりにも膨大になってしまう。というわけで、それならビッグバンリリースで一気に進めていこうという判断をしました。段階的リリースよりはビッグバンリリースの方が、考えるスコープは狭まるだろうと。

小出：
悩ましいところですよね。僕はどちらかといえば段階的リリースがいいと考えていました。全部スクラッチで作り直せば最短で理想形に向かえますが、その間の機能開発や改善を止める必要があります。段階的リリースであれば、機能開発や改善と平行できる一方で、最終的な理想形までの中間状態を考慮しなくてはならないので、難易度がかなり上がってしまう。そう考えると、あの時の状況やリソースで段階的リリースをやるのは、厳しかったかもしれないですね。

リニューアルプロジェクトの途中で、あえてGoのラインを増やした話

宮本：
そういえば、プロジェクトの途中からGoのラインを増やしたと聞いたのですが...。

小出：
そうですね。自分が参画した後で、PHPだけで開発していたところを、途中から一部コンポーネントをGoでも作り始めるという意思決定をしました。

背景は、大きく3つあります。ひとつは、PHPでスキルフルなエンジニアを探すのは、難易度がが高かったこと。以前、PHPをやっていたけど今は違う言語を使っているという方の場合、PHPを敬遠される方が多いという感覚がありまして。あくまでも僕の感覚ですが。このままPHP一本でやり続けるのは、人を確保するという観点からむずかしいと感じたからです。

別の観点でいうと、カンリーホームページはGoで作っていたので、社内の別のチームですでにGoを使っているという事実も、意思決定に大きく影響したと思います。

もうひとつ大きな要素として、カンリープロダクトの特性があります。数十〜数百店舗の投稿を一括で変更するといった機能など、GoogleやYahoo、Appleといった媒体のAPIを呼び出す回数がものすごく多いんですね。外部のAPIへの依存が強く、コール数も多いとなると、インターフェースの型やスキーマの整合性を維持していく必要があります。

また、外部のAPIに対して数百・数千ものリクエストをする場合、直列に処理をしてしまうとレスポンス待ちの時間が積み重なってしまうため、並行で処理をしたくなってきます。その点、Goは言語レベルで並行処理が簡単に書けるので、スループットを出しやすいメリットがあるかなと思いました。

より多くの価値を、より早くユーザーに届けるために—開発スピードアップに向けた取り組みを加速させる

宮本：
2025年2月にリニューアルの第一弾がリリースされましたが、今後やるべきこと、やりたいことについても、お聞かせいただけると嬉しいです。

小出：
旧カンリーと比較した際に、まだ実装できていない機能があるので、ここを作り切るのが短期的な最重要課題です。加えて、お客さまの新カンリーへの移行、カンリーホームページやカンリーカスタムシリーズなど周辺プロダクトのリニューアルも最優先で取り組んでいきたいと考えています。

この先にようやく、プロダクトとしての進化があるのかなと。友近さんがおっしゃっていたAIエージェント構想（※3）であったり、プロダクト＋CSのトータルパッケージではなくプロダクト単体でも価値提供できるようにすることだったりですね。
（※3）AIエージェント構想：AIやAIエージェント（本来、人的資源を必要とする複雑なタスクを自動化できるAIツール）を取り入れて、お客さまやCSが考えを極限まで減らしつつ効果を最大限にしていくこと

ひとつの価値提供としてお客さまの生産性向上を目指したときに、まずは僕らが早く作らなきゃいけない。つまり、エンジニア組織の生産性を上げなくちゃいけないという課題があるのかなと思っていまして。これを解決することによって、短期的には目の前の開発スピードアップ、さらにはデリバリー（お客さまに付加価値を提供する）の速度も上がっていきます。

その先にも、まだまだやりたいことがたくさんあって。これも友近さんがおっしゃっていた例を挙げると、直接的な集客につながる概念を取り入れるとか、複数領域にまたがるデータを集めてパーソナライズして利益を生み出すとかですね。

宮本：
はじめに開発スピードを上げることが必要だという話だと思ったのですが、開発のスピードアップに向けて、すでに取り組んでいることはありますか？

小出：
ここ最近だと、スキーマを元にしたコードの自動生成の積極的な活用に取り組んでいます。データベースの設計やAPIを決めれば、スキーマができますよね？ このスキーマからコードを自動生成しています。また、AIやAIエージェントを活用して、なるべく自分でコードを書かずに、AIの助けを借りることによってスピードを高めるという取り組みも始めています。

もちろん、これまでも個人として取り組んでくれていた方はいると思うのですが、今後は組織として、より「当たり前」にAIを活用することで生産性を高めていきたいなと考えています。

宮本：
となると、カンリーのエンジニアは今後、ほとんどコードを書かなくなると。

小出：
少なくとも、今よりは。
もうひとつ別のアングルで、本当に作る必要があるのかどうか、代替できるものはないのかを考えるのも大事ですよね。行動指針（※4）のビジョンでもある「当たり前の水準を高める」ことが、より重要になってくると思っています。
（※4）行動指針：カンリーでは、エンジニア組織としてのビジョンと5つの行動指針を定めています。
ビジョン：当たり前の水準を高め続ける
行動指針：「目的を見失わず、価値ある解決策を追求しよう」、「実践から学び、知識を知恵に変えよう」、「時間を言い訳にせず、根本解決に挑もう」、「知識を共有し、組織の成長を促そう」「人を責めず、仕組みを改善しよう」

長谷川：
行動指針の話が出たので、組織づくりみたいな話もできたらいいのかなと。

小出：
そうですね。リニューアルプロジェクトで新しくGoのコンポーネントを立ち上げましたが、初めからマイクロサービス化する前提で進めていたわけではなかったことや、時間的制約もあり、現在のシステムの境界と、今後理想とするチーム構成との間に少しちぐはぐな部分ができてしまっていまして。逆コンウェイ戦略（※5）を意識してはいたものの、やりきれなかったんですね。
（※5）コンウェイの法則：組織とアーキテクチャの関係性を表した概念で、「アーキテクチャ（システム）は、組織構造を反映させたものになる」という法則。逆コンウェイは、コンウェイの法則を逆側の視点で利用し、「理想となる組織構造に対し逆算的にアーキテクチャを設計することで、意図的に組織構造に影響を与えていく」という考え方。

ファーストリリースが終わり、これからエンハンスしていくフェーズになった今は、チームを分割・スケールさせていくために、機能（郡）単位でチームを作っていきたいのですが、いまお話したように、作りたいチームの構造とアーキテクチャの構造が若干ズレてしまっている状態です。

こうなってしまうことも想定しつつGoのコンポーネントを立ち上げたのですが、これから開発を加速させていくには、チームの生産性が高くなるよう、アーキテクチャの形を理想とするチームの形に合わせていくというのをやっていきたいなと思ってます。