「toCとtoBの垣根は時間をかけて解消」「評価に“個人への期待”を入れてバランスをとる」　Retty×キャディが語る、事業・エンジニア組織拡大で起きた課題とその向き合い方

猿田氏と常松氏について

猿田貴之氏（以下、猿田）：ここからはキャディの猿田が進行します。あらためてVPoE就任、おめでとうございます。

常松祐一氏（以下、常松）：ありがとうございます。

猿田：正直いうと（ぜひキャディにジョインして欲しいと思っていて、）常松さんにご連絡したのが、3ヶ月ぐらい前ですかね。（そこから）「VPoEになるんだよ」という話になって（笑）。「それはそれは、おめでとうございます」ということで、今回ぜひイベントをさせてもらえればとなっています。

僕から見ても、キヤノン時代から組織のスループット最大化を意識していて非常に（組織運営や改善に）熱意がある方だなと（思っていました）。当時から（常松さん）はたぶんスクラムマスターを取ってたと思います。かなり前の話だと思いますが、先見の明があるというか、かなり早い段階からそういうことを取り入れていました。僕なんかその頃はぜんぜん……。

常松：一緒にやっていたのは確か5年くらい前だったっけ？　2016、2017年くらいだった気がするから、5年前。

猿田：そうですね。（一緒に仕事をしていたのは）5年前くらい（だと思います）。「カメラに新しい価値を提供しよう」という取り組みの中で常松さんはわりと事業部に近いところにいました。僕はキヤノンでいうAI（技術を開発している部署）にいて、（常松さんは）隣（の部署）にいた感じですね。

常松：なんだかんだ会社が変わり、プロジェクトが変わったけれども。猿田君もビジネスに加えてAIとか新しいものを（主軸に）おいていて、「そんなに変わりはないな」と今ちょっと話していて思いました。

猿田：そうですね。僕も最近になって事業と技術の間に入ることが多いんですが、その中でやはり組織を整流化するとか、開発組織のスループットを上げることの重要性にはやはり気づきますね。それぞれ大事だなという。結局自分一人じゃなにもできないのでそういうことはけっこう学んでいます。

社員増員における課題

猿田：ちょっとお待ちくださいね。「キャディさんは従業員の数がすごい数で伸びているかと思いますが、どれくらいの規模で伸びていますか？」と質問が来ています。ちょっと従業員の数の話をしましょうか？

常松：先ほどの開発組織の話でいくと、今、（キャディさんの組織は）エンジニアで80人だったっけ？　けっこう人数が多い……。

猿田：そうですね。80人くらいいると思います。

常松：ちなみに、1年前とか半年前はどれくらいの人数だったんですか？

猿田：1年前。ちょっと待ってくださいね。1年前のエンジニア……。

常松：どれくらいのペースで増えているのかという。どのくらいだったらみんな「なるほど」とか「おぉっ！」て思うのかなと（笑）。

猿田：なるほどです。1年前。全社でいうと、実は倍以上増えているんですね。

常松：ではエンジニアも同じ感じのペースで増えている？

猿田：いや、エンジニアはたぶん50人ぐらいから80人という感じ。なのでビジネス側の増え（方）のほうが（早いです）。

常松：割合としては大きい。

猿田：割合としては大きくて、それはけっこう課題ではあります。要するに、今はビジネス側とテクノロジー側の比率がちょっと乖離してきている感じで、そこに課題感みたいなものはありますね。

常松：でも、開発でも50人から80人（に増えている）というのは、けっこうな人の増え方だよね。

猿田：そうですね。

常松：ある程度「こういう組織でやっていきますよ」みたいなのが見とおせていないと、増えた分だけわちゃわちゃしがちというか。わりとそういう会社を見聞きすることがあるというか、多いです。そういう苦しみは現在進行形でけっこうあったりする？

猿田：ありますね（笑）。

常松：（笑）。

猿田：先ほど、「DRAWER」というサービスを立ち上げた話をしましたが、それはすごく爆速で進めたので、やはり非機能要件的な部分での課題はあります。

「DRAWER」と「MANUFACTURING」という2つの事業があるんですが、わりと急激に人数を増やして（いるので）、DRAWER側とMANUFACTURING側の連携やナレッジの共有みたいなものは、まだまだ課題があるのが正直な話です。ちょっと二重開発っぽくなってしまっていて。APIプラットフォームや人材の交流は、今けっこう強く意識していますかね。

そういう意味だと、Rettyさんが「1個のプロダクトなんだよ」「会社が1個のプロダクトを持っているんだよ」という意識を持たせられているのは、僕はすごいなと思います。

常松：でも私が入社した時から（そうだったわけ）じゃなくて。Rettyも会社が大きくなるに従って棲み分けしています。まず、toCのメディアとして、ユーザーさんにお店探しに使ってもらうというのがあります。そして、toBのRettyはお店の管理画面や集客支援管理機能を出していて、そこはお店を大事に考えます。あとはスマホアプリのRettyもあって、スマホアプリはやはり「Webじゃない、スマホアプリなんだ」というところがあって。

いろいろと独自の打ち出し方や機能をやっていきたいんだけれど、例えばWebと辻褄が合っていなくて「変だよね」と言われたら、それはそうだと思うんですよ。

いきなり横並びに揃ったかというと（そうではなくて）、toC WebとtoCアプリ、toC WebとtoB Webみたいな感じで、だんだんと人材の交流も緩やかに、触るサービスも少しずつ広がっていきました。

両方わかる（人）とか過去に経験がある人が増えた結果、「やはり1つのプロダクトでしょ」と言われて「それはそうですね」だったり、「ちゃんと足並み揃えて一緒に開発していったほうがよいでしょ？」と言われて「そうですね」と（なったり）。けっこう時間をかけて変わっていきました。

それこそ「そういうふうに変えていきますよ」となって組織変更もして、半年間はtoCとtoBで完全に別のままだったし、1年ぐらいかけてようやくなじみというか、「こういうことか」となってきたぐらいです。実際には3年ぐらい、メチャクチャ時間をかけて（きたことで）、toCとtoBでかなり垣根が低くなってきました。

Rettyとキャディ、それぞれのLeSSの現状

猿田：ここで先ほどの話に戻って、ちなみに今エンジニアは何人ぐらいいるんですか？　

常松：今、社員で44人。

猿田：その44人が基本的に1個のLeSSにいるというイメージで合っていますか？　

常松：インフラやデータ基盤のエンジニアもいるので全員ではなくて、そのうちの半分強くらいかな。20人後半から30人くらいの人数がLeSSの開発の中に入っています。キャディさんでいうと、AI Lab、プラットフォームの上にLeSSチームがポコポコあるイメージです。

猿田：toCとtoBは別のLeSSなんですか？　それとも1個のLeSSですか？

常松：厳密にはバックログとしては分かれてしまっていますが、チームとしては対等になっています。例えば、会社が「今後はtoC一本でいきましょう」と言ったら、たぶんみんなにtoCをやってもらえると思っているし、「toBが大事なのでtoCはちょっと置いておきましょう」となったら、全員toBです。

ちょっとびっくりするかもしれないけれど、それくらい極端な振り方もできるようになってきたかなという感じです。

猿田：なるほど。弊社もMANUFACTURING側ではLeSSを導入したんですけれど、とはいえキャディのサプライチェーンを支えるプロダクトをいくつか作っています。

どうしても最小のプロダクト単位でチームが分かれていて、結局スクラムチームが3つ4つあるみたいな感じになってしまって。そこをスムーズにリソースをフォーカスするみたいなことは、あまりできていないところがあります。

開発組織と評価

猿田：エンジニアのスタック的な問題や、ナレッジの問題、ドメインモデルの話も含めてけっこう難しくなっているんですけれど、そこはわりとうまくいっていますか？

常松：「それを最初にやりたい」と（社員に対して）言っているのがたぶん大きいと思う。これを会社としてやりたいと思っているし、会社が最重要だと思っていることに事業として、開発としてアサインされるわけだから、みんなも当然「最重要のことをやりたいでしょ」となると思うんですよ。

1人か2人に、「今は会社として（別のことに）注力中だけど、あなたはこちらの担当だからここのところをちょっとやっといてね」と言われて、そんなに喜ぶエンジニアっていないじゃないですか（笑）。

だから守備範囲が広いし、認知負荷も大きいけれども、でもそういう開発組織でやっていきたいというのが最初にありました。

猿田：なるほど。さらに突っ込んだ質問をすると、けっこう評価や人事制度的なところにも踏み込まないと難しかったりしないですか。要は、そういう動き方を会社として推奨しないといけないと思っていますが、そういうのはないですかね？

常松：評価や目標の持ち方は、けっこう変わったところがあります。前はやりきり目標だったのかな。例えば「あなたはこの四半期では、この機能の開発にアサインされていて、リリースされたら評価がこれくらいですよ」「成果が出たらこれくらいですよ」（という評価）でした。

けれど、結局チームで仕事をやってもらうとなると、チームの中でどれを担当するかは事前にわからないわけなので、そのあたりはどうしてもちょっとぼかした書き方になってしまいます。

一方で、エンジニアにとっては、やはりそれなりのグレードを期待します。例えば、シニアエンジニアとジュニアエンジニアで同じことを期待するのはおかしいし、シニアの中でも「この人はフロントエンドに強いから、フロントエンドのここの技術負債なのか、ここの課題解消なのか、期待していますよ」というものがやはりどうしてもあります。

そういうところはチーム目標とは別で、「個人としてこういうことを期待しています」みたいなかたちでバランスをとるというか、工夫をしながら全社の評価制度の中で運用してきました。

猿田：なるほど。

常松：「これが最高だ」と思っているわけでもなくて、例えばOKRのような、もう少しリスクをとって大きなリターンが得られるやり方も合うのかなと思いつつ、けっこう悩ましいと思ってはいます。

猿田：そうなんですね。じゃあOKRは導入されていない感じなんですかね？

常松：OKRではないです。MBOというのかな。Management by Objectivesです。

猿田：なるほど。OKRは全社でも置いていないですか？　弊社は置いているんですけど。

常松：全社でも置いていない。

猿田：あっ、そうなんですね。

常松：Rettyは全社がMBOになっています。

猿田：なるほど。そういうことか。弊社は今、全部OKRでやっていて。スピード（重視）で、非連続な成長をとっていきましょうというのはすごく良いと思う。良い面だしそれはいいんですけれど、他方でそれによる負債みたいなものも、やはり一定生まれてしまっています。

例えば3ヶ月ごとに（事業における）意思決定が変わっていったり、事業性の不確実性がどんどん変わっていったりするので、開発側が納期優先となりがちなケースがあります。その中で、プロダクトマネージャーやエンジニアは、ちょっと意思決定が難しくなっていたりします。そのあたりも最近ちょっと改善していこうと（しています）。

常松：組織としてまとめていくことをやる前は、やはりそういう問題がありました。例えば、あるサービスの特定開発チームがありました。その開発はいったん注力しなくなったので別のプロダクトをやるとなった時に、「じゃあ、このプロダクトでバグがあったり運用の問題があったら誰がやるの？」というのがやはりどうしてもあって。

（その課題が）だんだん浮いていって、手も入れられなくなってしまうことがけっこうありました。今でもそういうことで悩むことはありますよね。だんだんと横串になるに従って、例えば同じPHPを使っているけれど、あまりにも違うのは変だし、用語も違う。変数名が違うのも変だし。

例えばマイクロサービスに移行しても、「こことこことでぜんぜん作りが違うと、毎回キャッチアップが大変だから、同じにしていかないといけないよね」とか。そういうことが自分ごとになってくるので、揃えることにちゃんとメリットが出てくるのはあると思います。

猿田：なるほど。それをやらないといけないな。ありがとうございます。

（次回につづく）