「1on1でクリアに不満を言ってくれる人は、ほぼいない」　「言っても意味ないな」で終わらないための信頼関係の築き方　

1on1の頻度

猿田貴之氏（以下、猿田）：「1on1を毎週全員やるとメチャクチャ大変なんですが、効率化の工夫などありますか？」なるほど。常松さん、1on1はメンバーというか、どれぐらいやっていますか？

常松祐一氏（以下、常松）：1週間に1回、30分。今はVPoEになったので少し減ったんですけれども、9月までは社員のメンバーが16人ぐらいいたのかな。

猿田：16人を1週間に1回だと、週8時間ぐらいやっていたということ？

常松：1日に4回とか5回とか、1on1でずっと話していて。1日の半分というか、週の半分くらい1on1で話しているような状態になる。

猿田：すごいな。それは手厚いですね。僕は隔週でしかやっていないです。そこまではやっていないですね。僕はどうしても事業側としゃべったりもして、事業側のメンバーとの1on1も入っているので、メンバーとの1on1はそこまではやっていなくて。まぁ2週間に1回とかですね。

常松：効率化というよりかは、どちらかというと1on1をどう活かすかが大事だと思っています。メンバー成長もそうだし、会社の問題の早期発見もそうかもしれないし。早めにキャリアの相談や働き方の相談を1on1でちゃんとできていると、長い目で見て離職防止だったり退職率を低く保ったりとか、そういうことにも効いているとは思います。

猿田：なるほどですね。すごい。すばらしいな。そうですね、効率化。一般的だと思いますが、Google Docsでその人だけとのメモを作って、あらかじめアジェンダを作っておいて、ちゃんとアクションに落とすこともやっていますかね。

1on1が形骸化しないようにするとか、業務相談にならないようにちゃんとやっていますね。あ、効率化の工夫じゃなかったっけ？（笑）。僕はそれなりに人数は絞って委譲している感じですかね。ありがとうございます。

1on1で不満が上がってこない原因

猿田：次に「1on1で不満が上がってこないのは、どんな要因があると思いますか？」ですが、1on1で不満が上がってこないかが、みんなけっこう気になるんですね（笑）。

常松：関係性が築けていないんじゃないですかね？　信頼が築けていないのはありそう。

猿田：そうですね。信頼感を作る作業はやはりメチャクチャ大事ですよね。

常松：だからそのためには、やはり頻度を上げて（1on1を）やる必要があるし、不満や要望があった時に、翌週の1on1までに「じゃあ、こういうふうにしておきました」「まだ完璧じゃないけどこういう手を打ちましたよ」みたいなことは、ちゃんと途中経過で伝えてあげないと（いけない）。

「言っても意味ないよな」と思われると、「今週もなんもないです」で終わっちゃうから。すごくよくあることです。

猿田：それもわかります。（でも）最初は言ってくれないから、こっちから開示する。いわゆる1on1の本に書いてあるような自己開示をするとか、常松さんがお話されたとおりで、小さな不満でもインプルーブしてあげる。それは小さいことかもしれないけど、やってくる。アクションをきちんとするとか。そうですよね。

常松：なんもなしにいろいろと意見を言ってくれる人は、そんなに割合は多くない。1割、2割。2割もいないかなって感じがします。

猿田：そうですよね。うまく言語化できないケースもあるし。

常松：あぁ、確かに。

猿田：ありますよね。クリアに不満を言ってくれるのは、ほぼないと思っているのがけっこう正しいような気がする。という感じで、1on1を真面目にやっていますということでした（笑）。

キャディのエンジニア組織の歴史と今後

猿田：「キャディにおいては、エンジニア組織が現在の形になる前の歴史・背景をお話ししてもらえますか。特にPlatformの1チームの経緯が気になります」。あぁ、なるほど、ありがとうございます。

私自身が（キャディに）1年前に入ったので、すべての歴史を知っているわけじゃないんですけれど。けっこう紆余曲折しているのが正直なところで、Platformチーム自体もできたのは1年ぐらい前だと思います。それまではキャディのMANUFACTURING側の事業だけがあって、プロダクトチームがポコポコポコある感じでした。

正直、各プロダクトが自主開発をしていて、認証認可の問題とか非機能要件の問題があるようなことがあって、このままだとスケーラビリティを持てないという危機感がけっこうあって、Platformチームを作った経緯があります。

AI Labは実は2021年12月ぐらいにできたチームで、そこからAIに力を入れて、図面の解析に力を入れている歴史があります。（常松氏を見て）さらに今は……あっ、どうぞ。

常松祐一氏（以下、常松）：今後のチーム数とか、「ここは増やしていきたい」とか、「ここは少し移していきたい」みたいなこともあったりするんですか？　割合、比率なのかもしれないですけれど。

猿田：ありがとうございます。今はもっと増やしたいと思っています。先ほどチラッと言いましたが、キャディは今、取引先である加工会社の支援を進めていたり、海外のグローバルサプライチェーンを構築しています。海外の輸送や海外で材料を仕入れるなど、いろいろな新しいオペレーションが増えていて、それに対応するプロダクトというか、効率化が求められています。

あまりモジュールごとの開発ができていなくて。わりと密結合したプロダクトになってしまっているので、そこをもうちょっとモノリシックというか、モジュールごとに分けたい。それでちゃんと単体で価値を提供できるようにしたいですね。

やはり日本で採用するのはなかなか難しくもなっているので、グローバルで採用していきたいのもあって。それもあって、やはりけっこう小さい単位で価値を提供していけるようにしたいというのが今です。

常松：2つの製品。まぁ、製品群というか、DRAWERとMANUFACTURINGがあったじゃないですか。

猿田：そうですね。

常松：その中でいくつかモジュールで分けていく。DRAWERの中のモジュール1、2、3みたいな。そういうイメージなの？

猿田：それもあるし、今の問題意識はMANUFACTURING側で、MANUFACTURINGと一口に言っても、お客さまから受注を受けるとか見積りをするとか、そういう項目とサプライチェーンを構築する、それを管理するみたいな話があったり、実はキャディに拠点があるから……。

その前にサプライパートはどう管理したり支援したり（する）という話があるし、拠点のオペレーションを効率化する話があって。それは一応全部つながってはいるんだけど、それぞれあるという感じですかね。

常松：よくほかの会社を見ていて、例えばマニュファクチャーの見積りだけだったらキャディ見積りで「キャディサプライチェーンです」みたいな感じで分けていくイメージなのか、そうじゃなくて、後から組み合わせて別の機能ができるように疎に作るイメージなのかな？

猿田：まず前者だけど、後者にしたいという感じですかね。例えば、簡単なところだと、図面解析みたいな機能はDRAWERでも使えるし、MANUFACTURING側でも使えるみたいな話があったりするので、もうちょっと細かい単位でもやりたいと今は思っています。

常松：できるのかな？　できている会社って知ってる（笑）？

猿田：できている会社を知っているか？　それはいい質問だなと思ったんですけれど（笑）。キャディはけっこう難しくて。事業がまだきれいに固まっていないんですよね。

今から海外グローバルサプライチェーンを構築しにいくと言っているし、顧客が今は日本だけじゃなくてアメリカや海外に持ちたいという話がある。

イシューが変わる、微妙にビジネスモデルが変わる可能性が実はまだあって、根幹は変わらないけれど、やはりお客さんが求めていることはそれぞれ違うので、その中で変わってくる可能性はあります。

それを見ながら、かつマイクロサービスにするかどうかは別にして、そういうモジュール化する話をやらなければいけないので、僕もいろいろな人の話を聞いたり勉強もしたりしますが、けっこう難しいです（笑）。

常松：弊社も言葉上ではそのとおりなんだけれど、実際「これ無理じゃねぇのか」というか、複数の機能単位で分けておいて、例えば、「これは要らなくなったので取り外します」みたいなものが簡単にできるものは要るんだろうけれど、基本的には「1度作ったらほかと連動して使います」というのは、SaaSのようなものだとやはりマストだと思ってはいるんですよね。

例えば弊社でいうと、少し前、コロナがあった後ぐらいに、モバイルオーダーの機能でスマホからお店の店員さんを呼ばずに注文できるという、「Retty Order」というサービスをローンチしたんですが、最初は管理画面が別だったんですよね。

Retty Orderを使うお客さんと、集客支援のサービスを使うお客さんとで管理画面が別でした。でもユーザーから見たら「同じRettyでしょ」ということで、ワンクリックで管理画面を変更できる機能ができて、（その後）「管理画面が一緒のほうがいいじゃん」みたいな（笑）。

言われてみれば当たり前なんだけれど、でもどうしても作るとか設計する時に、最初は「別だよね」みたいなふうになっちゃうんだよなって。

猿田：なるほどね。すごくわかりますよ（笑）。ユーザーから見た時には1個にしたいんですよね。

常松：そうそう。

猿田：でも、中はモジュール化したいという。

常松：そうそう。

猿田：言うのは簡単だけれど実はけっこう難しいというのは、そのとおりだなと思いますね。なるほどです。

常松：マイクロサービスで分割しておきます。管理画面としては、フロントは今けっこうくっついていて、メディアのフロントと、おそらくtoBのフロントで着地するのかなと思ってはいます。それも「分けるの？」と言われると、解も持っていないんだけれど、分けるメリットもあまりわからないかなというか、悩ましいです。

猿田：なるほどですね。いや、わかります。そこは僕もぜんぜんまだ解は持っていなくて、一方で、やはり人手のオペレーションやデータのやり取りはあるので、その整備はさすがにしないとまずいと思っていて、それからやるのが一番いいのかなという感じですかね。

オペレーションとデータフローを定義した上で、そこにプロダクトを当てていく。普通で当たり前のことを言っています。

常松：当たり前のこと（笑）。

猿田：当たり前のことをやっていくしかないよな、と思っています。

チームを大きくする初期段階で気をつけたほうが良いこと

常松：1個チャットで質問もらえているね。「これからチームを大きくする段階ですが、初期段階でこれだけは気をつけたほうがよいこと（を教えてください）」。

猿田：これは難しい質問だな（笑）。

常松：私は、けっこうすぐに「これだな」と答えられます。

猿田：本当ですか？　さすが。ではまずは常松さんからお願いします。

常松：大きくする前に、うまくいく状態を作ったほうがいいです。「小さいからうまくいく」じゃなくて、1チームでうまくいっている状態を作っておかないと、2チームになったらよりうまくいかなくなるので、まず絶対にうまくいく状態を作ったほうがいいです（笑）。

猿田：なるほどです。自分たちで自走もできて、スクラムとかをもっと回せて、というような。

常松：「これが成功状態だよね。うまくいっている状態だよね。うちの会社でスタンダードだよね」という状態を作った上で、人が増えてうまくいかなくなったら、そのスタンダードに近づけられるようにしていかないと、どれが正解なのかわかんなくなっちゃいます。「2チームに分けたから下がったんですよ」みたいな、よくわかんない理屈が出てきます。

猿田：すっごくよくわかる（笑）。それを若干踏んでいる気がします。

常松：Rettyでやった時は、最初スクラムを立ち上げた時に、1チームで成功して、「これが成功している状態ですよ」というものをちゃんと認識してもらった上で2チームにしました。2チームにそれぞれ経験者がいて、「これはうまくいってないじゃない？」ということを言ってもらいました。（これで）2チームができます。

今はもう、いろいろな人がいろいろなチームを経験しているので、なんか変なチームに入ったら「このチームおかしくね？」みたいな。「言っていることもおかしいし、成果もおかしくね？」とたぶん言ってくれると思います。

猿田：それはすごくわかるなぁ。なるほど。だから、あるチームを分解して、そこのメンバー込みで新しい事業を（作る）。本当に新しい事業をいきなりポコッて、ダンッて立ち上げちゃうと、結局ナレッジがぜんぜん違うからうまくいかないというのは、そのとおりな気がします。

なるほどなぁ。それはすごくよくわかった（笑）。DRAWERというサービスはけっこう急速に立ち上げたから、わりと新しいメンバーを入れていったんですよね。MANUFACTURING側はずっと何年もやっています。もちろんその中でいろいろな改善や、いろいろな失敗ももちろんあるんだけれど、チームは成熟していっています。

DRAWERは新しいチームだから、MANUFACTURINGとDRAWERのチームはぜんぜん違うチームになる。ぜんぜん違うとまでは言わないけど、こっちのメンバーがこっちに行くみたいなことがそんなになかったので、お話されたことはそのとおりだなと思いました。

常松：（笑）。

猿田：1個ちゃんと立ち上げるのは大事です。そこを慌てないのが大事

常松：そうそう。慌てないのが大事で、こういう組織相談の話は各社からもらってすることがあります。

例えばLeSSを入れます。一気に「LeSSを4チームから始めます」と言われると、「大丈夫かな？」とすごく思いながらも、やはり「がんばってください」としか言えない（笑）。

猿田：組織変更やリアーキテクトみたいな話は、絶対急いではいけないというのは本当にそのとおりですよね。

常松：そうそう。うまくいかなかったら戻せばいいのにと思うけれど、みんな後戻りできないかたちで進めていくから、「すごく不安だな」と思いながら相談に乗っている。だけど、「やめたほうがいいですよ」って言いづらいよね（笑）。

猿田：いや、でもそれは僕自身もこの間ちょっとしくじったことがあります。結局、事業スピードを求めるとものすごくリソースをかけたい。会社トップから「リソースを増やしていい」と言われるからダンッてリソースを増やしたいんだけど、そうすると一気にチームの人数が増えちゃって、チームが機能不全に陥ってしまうというのは、なんかすごくあるあるなしくじりです。

これはたぶん、たいていのスタートアップの人は、みんな1回は陥る落とし穴だと思います。

常松：よくやるよね（笑）。

猿田：という感じで、お時間になったので、1回お返しします。

常松：用意していたテーマをぜんぜん話せないままに（笑）。

猿田：実は事前にテーマを十何個と僕と常松さんで話していたんですけれど、まったくもって違う展開になってしまいましたが、良かったかなと思います。ありがとうございました。