hidekのエンジニアと長話 第5-2回【全文書き起こし】~ゲスト：ベルフェイス CTO zigorou氏~
「hidekのエンジニアと長話」は、メルペイVPoEのhidek（木村秀夫）さんをメインパーソナリティにお招きし、ゲストエンジニアとともに作っていくスペシャルトーク番組です。
第5-2回の今回は、ベルフェイス株式会社でCTOを務めている山口徹さんをお招きして、開発組織やプロダクトマネジメント、BotBなどについて語りました。
ゲスト
山口徹（zigorou）氏
ベルフェイス株式会社 CTO
メインパーソナリティ
hidek（木村秀夫）氏
株式会社メルペイ VPoE（Vice President of Engineering）
パーソナリティアシスタント
gami（池上）氏
株式会社プレイド エンジニア
※本記事は、2021年4月2日にstand.fmで配信を開始した番組を書き起こしたものです。
外部からCTOやVPoEとして入る大変さ
hidekさん（以下、敬称略）：今はベルフェイスに入って、CTOと言いつつ、VP of Engineering的な役割も兼ねている感じですか？
山口さん（以下、敬称略）：実は今月いっぱいでVPoE業を晴れて……。
hidek：お！ 誰かにバトンタッチできる？
山口：渡せる。はい、バトンタッチできるようになったんですよ。
hidek：おー、うらやましい。それは外部から取ってきたんですか？
山口：内部昇格ですね。
hidek：あ、一番いいパターンですね。VP of Engineeringね、僕、今回、外から入ったんですけど、だいぶ苦労しましたからね（笑）。
山口：いやー、だと思いますよ。うん。僕よりも先に入社した方を置こう、っていう話なんですけど。やっとね、ひとつ肩の荷が下りるというか。VPoE大変だよね、本当にね！
hidek：大変ですよー。一般的に、VP of EngineeringとCTOの違いっていうと、VP of Engineeringはいわゆる「組織」の方面から技術面を支えていく、っていう役割分担なんですけど。いわゆる「組織」っていうところは、やっぱり難しいですね。
山口：いやー、本当に難しいですね。特に、あとから入ってきた感じだと、組織が若かったりすると、若いっていうのは年数的なものもあるし、実力だとかそういったところとかも含めて。やっぱり、どこから攻めて行こうか、みたいな。で、まず真っ先に何やろうか、みたいなところからスタートじゃないですか？
hidek：うんうん。
山口：あそこの入りが一番大変でしたね。
hidek：そもそも外から来ると、たぶんCTOとして入るのも結構大変だと思うんですけど、いわゆる「信頼貯金」がないところから入らないといけないじゃないですか？
山口：そうそう。そうなんですよ。
hidek：言うたら、僕、今のメルペイのプロダクトコード、一行も書いてないわけですよね。一文字も書いてないわけです。そうすると、「こいつ技術わかってんの？」みたいな目で見られることも当然あるだろうし。
山口：うんうん。
hidek：やっぱり、その信頼貯金をコードではなくて、経験だとかチームビルディングだとか、そういうところで示していかなきゃいけない、というのは結構、ハードシングでしたね。
山口：いやー、それはすごいわかりますね。ただ、技術顧問で入ってた時間っていうのが5ヶ月あったんですよ、結局。
hidek：うーん、なるほどね。
山口：それは、助走期間としてはすごいよかったですね。
hidek：なるほどね。それこそ、DeNAのときだったら、「これはワシが書いたコードや！」みたいなことをドヤれたのが、そういうのが一切ないわけですから。信頼貯金がゼロ。辛いです、結構。
山口：そういう「技術力」みたいなところ、まあ「技術力ってなんだよ」っていう話もあるけど、いわゆるどれだけテクノロジーに精通してるかとかさ、あと妥当な技術的な判断ができるかどうかっていうのって、やっぱ、コードが一番わかりやすいっちゃわかりやすいけど。
hidek：そうなんですよね。うん。
山口：でも、仕事の中でアドバイスとか、あるいはお手本みたいなのは示せますからね。
hidek：そうですね。たまたま僕の場合、メルペイがリリースする前で、結構、ぶっちゃけ炎上してて、なかなかリリースできない、っていうところで。そこのプロジェクトマネジメントと、あとQA組織がリーダーがいなかったのでそこを見る、みたいな。結局、リリース前ってそこが大きいじゃないですか。なので、そこでちょっとバリューが出せて、なんとか信頼を勝ち得た、っていうところなので、それはそれでラッキーパンチだったな、という気はするので。
山口：いや、結構、それ、軽く言うかもしれないけど、そう簡単にできないよね。全体像が見えていて、足りてないところは何かってちゃんと見て、的確にフォローできる人って、実はそう多くないと思ってて。
hidek：うんうん。
山口：やっぱりhidekさんは、そういったところを適切にカバーできるから素晴らしいんじゃないんですか。
hidek：あら、ありがとうございます、なんか（笑）。
山口：ちょっと大人になったので、人のことを褒めることができるようになりました（笑）。
ベルフェイスの開発組織
hidek：よかった。成長を感じられました（笑）。今、ベルフェイスって、開発組織としてはどれくらいの規模なんですか？ 言える範囲で。
山口：今はエンジニアの組織が50ちょいくらいですね、正社員ベースで。業務委託が結構いるんで。派遣はいないか。業務委託とかパートナー企業とか、そういった開発を手伝ってもらっている人とかを諸々合わせるともっといる感じですね。
hidek：うんうん。
山口：で、あと、プロダクト組織が今、20弱くらいかな、たぶん。
hidek：うんうん。まずはCTOとしてジョインして、兼VPoEとして入って……。
山口：そうですね。
hidek：そのときの開発組織の問題・課題、どういうのがあった、とかってあります？
山口：なんだろうなぁ。言っても、技術顧問時代に関わっていたことって断片的だったので。
hidek：うん。
山口：まず、システム全容と、あと、組織がどういう風にマッピングしているのかとか、あと、どんなメンバーがいるのかとか、主要な問題は何か、っていったところを把握するっていったところが、一番真っ先にやろうとしたことですかね。
hidek：はいはい。
山口：純粋に「技術組織」っていう観点で言うと。「会社組織をどう変えよう」っていうのは大体決まってたんですよ。技術顧問をやっていた時代から、「ここは絶対変えなきゃ」って固く誓ってたことがあったので。それは即座に着手しつつだけど、まずは、「適切な情報が届く」っていう体制を作ることを最初に意識しましたね。
hidek：うーん。なるほど。逆に言うと、そこの「コミュニケーション不全」みたいなものが課題としてあった感じですか？
山口：あー、ありましたね。よくあるケースで言うと、「開発と運用」みたいな部分でズバーンってすごい雑に分けられるじゃん？
hidek：はい。
山口：システムの部門でも。で、そこが、そもそも最初、同じ組織じゃなかったんですよ。それぞれ別組織で。で、あまり横の連携がなされてなかった、っていう課題があったので、それはいきなり最初に同じグループにしたりとか、適切な会議体がなかったのでやったりとか。
hidek：うんうん。
山口：あと、特に開発だとEMが全然いなかったので、当初。適切なサイズ感でEMを配置しました。それこそ、スパン・オブ・コントロールをちゃんと意識して、「大体このくらいEMいた方がいいよね」っていう目標を掲げてやった、って感じですね。今、もう達成しているんだけどね。大体6人くらいかな、スパン・オブ・コントロール。
hidek：うんうん。あ、1マネジャーに対して6人のメンバーっていう？
山口：そうそう、大体そんな感じだと思う。
hidek：結構リッチですね。
山口：6〜7名くらい、たぶん。うん。EMのEMもいるので、正確に言うと。だから、その下がメンバーっていうのじゃないEMもいますよね。
hidek：うんうん。結構、2 pizza ruleっていうので、8人〜10人ってよく言うから、6人だと結構リッチだなぁ、と思うんですけど。EMの役割って、結構、会社によって違うと思うんですよね。
山口：あー。
hidek：もう完全に組織振り切っているところもあれば、うち、結構、意外と前はそうだったんですけど、最近だともうちょっとグラディエーションを持たせよう、というところで、もうちょっとプロダクトに入ってもらおう、とか。ただ、人数が多いところは、なるべく組織に振ってね、とか。
山口：へー。
hidek：だから結構、グラディエーション、今、あるんですけど。ベルフェイスにおける、エンジニアリングマネジャーの期待役割ってどういったところなんですか？
山口：そういう意味で言うと、やっぱりプロジェクトを回す、っていうところもそうだし、開発プロセスとかのところにも、まだ、統一的なルールっていうのが整備し切れていないところがあるので。要は、ルールがあまり整備されていないと、取りこぼしだとか、インシデントとまでは言わないけど、突発的なイベントとかがあるわけですよ。要は、安定していない、って言うのかな、開発自体が。といったところで、結構、差し込みの対応が多いと思うんですよ。
hidek：うん。
山口：そこら辺をフォローしてもらっちゃってるんですよね。で、あと、ベルフェイスで言うと、プロダクトマネジメントの強化が今年度の前半とかは全然できてなかったので。なので、プロダクト側もカバーしている点とかはありましたね。
hidek：うんうん。
山口：っていうかカバーしてる。今、なお。今、ちょうど、プロダクトのところも、僕も先月からCPOになったんだけど、ガラリとやり方を変えようとしていて。だから、EMの負担は結構大きいですね。
hidek：うん。じゃあ、いわゆるピープルマネジメントに閉じずにプロジェクトマネジメント、場合によってはプロダクトマネジメントみたいなところも期待役割としては持ってもらっているので、サイズ感としては6人とか。
山口：プロダクトマネジメントまでは言い過ぎだけど、プロジェクトマネジメントくらいだと思います。
hidek：なるほどね。
山口：あとは、プロセスの改善とかですかね。
hidek：うんうん。メルペイでも、メルカリもそうなんですけど、マネジャーが「職位」じゃなくて「役割」なんですよね。
山口：うん。
hidek：マネジャーという役割なので、マネジャーとIC（Individual Contributor）とメンバーを結構行ったり来たりするのは別によいよ、と。むしろ推奨されている中で、結構、コードを書きながら、でも、メンバーのマネジメントを今後のキャリアのためにやっていきたい、みたいな人もいて。そういう人って、どうしても、それこそさっき言った、僕も「コードを書くな」みたいなことを怒られたことがあったんですけど、いわゆるコードを書きながらとテックリード兼EMみたいな人がいて。
山口：あー。
hidek：役割なんでオーバーラップできるはずなんですよね。
山口：うん。
hidek：なので、そういうのを推奨すると……。ただ、そうすると組織マネジメントの規模としては4人とか3人とか、こうなっちゃうのは致し方ないのかなぁ、とか思いつつ。まあ、そういう話はありますかね。
山口：あー。今はね、テックリード兼EMみたいな感じの人はほぼいないかな。でも、たしかに、「職位ではなく役割」っていうところで言うと、ベルフェイスはまだ「役割」っていう風になってなくて。僕はそういう風にしていきたい、とは思ってるんですよね。別に「どっちがグレードが高い」とか、本来違うじゃないですか。単純にテクノロジーが純粋にすごい人だって、等しく評価されるべきだし。ただ、役割の違いによって、「求められることのグレードの違い」みたいなのはあると思うので。いわゆるジョブグレード的なやつとかで正しく評価できるっていうのはいいかな、とは思いますね。
hidek：うんうん。キャリア的にも、マネジャーって一回やってみないと、向き不向きとかもあるじゃないですか、ぶっちゃけ。
山口：あります。そうそう。
hidek：なので、「一回マネジャーになったら、もうその一方通行」「不可逆なキャリア」だとちょっとしんどいかな、と思ってて。役割になれば、そこがスイッチできるから、振り子のキャリアを歩めるので、そういった意味でも、マネジャーを役割とするのは結構いいんじゃないかな、と個人的には思っています。
山口：僕もそう思いますね。全体的にそうなればいいのになぁ、という風に個人的には思いますね。
プロダクトマネジメントのフレームワーク
hidek：うんうん。今、CPOにもなったということなんですけど、いわゆる開発フローだとか、もしくはプロジェクトマネジメントもそうですし、プロジェクトのスタンダード・標準化みたいなところも役割としてはやっている感じだと思うんですけど、その辺って今、どんな感じなんですか？
山口：まさにやっててですね、今、「Open Product Management Workflow」っていうフレームワークみたいなのがあって。これがすごいよくできてるんですよ。たぶん、あんまり日本では普及してないのかなぁ？ 僕も、なんでこれを知ったのか忘れちゃったんですけど。今、ちょっとリンク送りますね。ここに書いてある変な図があるじゃないですか？
hidek：はいはい。
山口：で、プロダクトマネジメントって、この3フェーズありますよね、みたいな感じの整理の仕方をしていて。「プランニング」と「実際の開発」と「それのデリバリー」みたいな感じ、っていう3フェーズで分けてる。
hidek：これって左から右に？
山口：ざっくり言うと左から右です。そうそう。
hidek：時系列で。
山口：時系列でいく、っていうやつなんですけど。でも、正確に言うと、この「GO-TO-MARKET」って、開発とパラレルで動く……。要は、開発している中でローンチ計画とか立てて、それをどういう風にプロモートしていくか、とか並行で動くじゃないですか？
hidek：はい。
山口：それぞれのフェーズにおいて各プロセスで何をやるべきかとか、どういう観点を気をつけるべきかとか。これ、実はフリーブックがあって、「Books」って左側にあると思うんだけど。
hidek：あー、はいはい。
山口：そこで、このフェーズごとのドキュメントがあってですね。これ、今ちょうどPM集めて輪読会してるんですよ。これ、掛け算すると40くらいプロセスがあるのかな、きっと。で、やっと35くらいまで来て、今。そろそろ読み切る、っていうところなんですけど。すごい、これ、学びが深くって、なるほどな、っていう。で、ちょうど、ビルドトラップ本って知ってる？ プロダクトマネジメントの。
hidek：いや、わからないです。
山口：これ、すごいいい本なのでエンジニアにも読んでほしいんですけど。『プロダクトマネジメントービルドトラップを避け顧客に価値を届ける』っていうこの本。
hidek：あー、これか。はいはい。
山口：まだ、紙の書籍しかないんだよね。これは、プロダクト組織作りをこれからやるような人にとっては、すごくいい本だと思います。
hidek：ふーん。
山口：プロダクトマネジメントの細かい本、手法を書いている、というよりかは、もうちょっと俯瞰的な視点と、あと、「どういう組織であるべきか」みたいな、っていう話が書いてあって。エンジニアだと広木さんの『エンジニアリング組織論への招待』とか、いい本があって。
hidek：はい。
山口：あれ、逆にEMとかに読んでほしい。CTOとか。あと、あの本とかは経営者とかにも読んでほしいじゃないですか？
hidek：もちろんそうです。
山口：「エンジニア組織ってこうだよ」っていう。これは、それのプロダクトマネジメント版だと思った方がいい。
hidek：へー。
山口：そういう観点ではすごくいい本だな、と思って。
hidek：はいはい。
山口：で、これも要は、仮説検証のプロセスだとか、そういったところを一足飛びに行かないとか、あとはいろいろな手法・オプション、それぞれの次のステップってさまざまなオプションのステップがありますよね、と。要は、次のステップってひとつしかないわけじゃないじゃん。例えば、「バイビルドパートナー」っていうプロセスがあるんですけど、じゃあ、「大体やりたいスコープが決まりました」っていったときに、いつもいつも作るっていうオプションだけじゃないよね、と。
hidek：ふーん。
山口：別にどこかから買ってきてもいいしとか、パートナーシップ組んでもいいしっていう。要は、「問題の解き方、それだけじゃないよね」っていう。
hidek：うんうん。
山口：っていう話があって、すごく慎重に進めるプロセスになってるんですよね。
hidek：ふーん。
山口：変な話、やっぱり上流の工程って、ミスってしまうとあとにものすごくいろいろな人を巻き込んで被害を与えるじゃないですか。
hidek：うんうん。
山口：金も使うし時間も使うし。だから、いかに少ないリスクで、で、少しずつ確信を持っていく。確信というか、これはたぶん、「根拠を積み上げるプロセス」って言ってもいいのかもしれない。特にストラテジーフェーズって。
hidek：うんうん。これ、いわゆるプロダクトマネジメントにおける、プランニングっていうところより、もうちょっと手前のストラテジーみたいなところの……。
山口：あ、ストラテジーからですね。でも、ざっくり言うとプランニングです。これ結構、読むのが難しくて。プロダクトマネジメントって言っても、例えば、プロダクトにおける特定の機能についてもフォーカス当たるし。例えばメルペイであれば、メルペイの「新しい決済手段」とかも、例えばPRDとか書いたりするじゃないですか？
hidek：はい。
山口：新しいものを追加するときとかに。でも、「メルペイ」っていうプロダクトを起こすときだってプロダクトマネジメントだし、みたいな。
hidek：はい。
山口：だから、規模のデカさとかさ、あと、「どういう時間軸でやります」「何人でやります」とかで、全然話が違うんですよね。でも、そういったことにあまり言及していないので、自分たちで解釈が必要なんですよね。
hidek：なるほどね。
山口：っていったところで、ちょっと読み解くのは難しいですけど。
hidek：いわゆるフレームワークですかね。
山口：フレームワークですね。
hidek：それによってはカスタマイズも必要だし、場合によっては付け加えるのも必要だし、っていうことですよね。
プロダクトの作り方とマーケティング方針の密接な関係
山口：そうそう。だから、これ、すごい面白かったのが、一番冒頭に「カスタマーの定義」みたいなのが書いてあるんですけど、カスタマーって「潜在顧客」と「評価顧客」と「既存顧客」っていう概念があるんですよ。で、定義で言うと、潜在顧客っていうのは、当然まだ、そのソリューションにたどり着いていない人々。で、評価顧客っていうのは、方向性としてこういったソリューションが必要だ、っていう感じなんだけど、どのソリューションにしようか決めてないっていう顧客。で、既存顧客っていうのは、自分たちのプロダクトを使っている顧客も当然既存顧客なんだけど、なんらかのソリューションにたどり着いた顧客のことを既存顧客って言うんですよね。
hidek：うんうん。
山口：だから、別に競合他社の製品使ってる人も既存顧客なんですよ。みたいな定義になるんですね。で、しかも今度、「新しい機能を提供する」っていうシチュエーションにおいては、今言った既存顧客・評価顧客・潜在顧客の辺りの考え方が変わるんですよね。例えば、先行リリースしたとするじゃないですか、特定の顧客に。で、ある程度揉んでもらったら、その人たちは既存顧客になって。で、ちゃんとしたオープンにリリースしたときっていうのは、スタートラインにはそれ以外の顧客は潜在顧客になるとか、そういう考え方をするんですよ。
hidek：うん。
山口：だから、いろいろな大きさの粒度とかによって、その顧客の捉え方も違うし、みたいな。結構、読んでて面白いんですよね。だから、「どういう切り口でマネジメントしていこうか」っていうのがすごくよくわかる。
hidek：今の話って結構、マーケティングに最も密接につながってるなぁ、っていうような感じで。
山口：うん。つながってるつながってる。そう。ここがマーケティングの話なんだよ。
hidek：あー、そうですよね。
山口：緑色のところがそうなんですよ。
hidek：そうなんですよ。僕、今、メルペイに来て、メルペイって結構、単一事業だったりだとか、結構、マーケティング重要だったりとかするんですよ。特に立ち上げ期だったりとか、競合他社が結構多いビジネス・ドメインでもあるので、マーケティングが重要なんですけど。そこは結構、プロダクトマネジメントというか、プロダクトの作り方・方向性とこのマーケティングの方向性っていうのが結構密接につながってるというのを、メルペイに来てはじめて体験して。
山口：めちゃめちゃ密接ですね。だから、このOpen Product Management Workflowにも、GO-TO-MARKETフェーズのやつって、「いや、もう、ストラテジーでちゃんと確信を持ったと思うんだけど、それを使うんだよ」っていうのが何回も書かれてて。
hidek：はい。
山口：だから、いかにこのストラテジーのときに根拠を積み上げたか。根拠とコンセプトっていうのを固めたか、なんですよね。だから、その根拠とコンセプトに基づいて、適切なセグメントとペルソナに対してマーケティングするべきだし、みたいなことが書いてあるんですよ。
hidek：うんうん。
山口：すごくいいですよ、これ。
hidek：やっぱり、その辺のことが、プロダクトドリブンな会社だとかよく言うと思うんですけど、あれって、ちょっとともすれば、「芸術品として作ったプロダクト、お前ら売ってこいや」みたいな、そういう絵図になりがちなんですけど。
山口：うんうん。
hidek：そこって、ちゃんとマーケティングも含めて設計されたプロダクトって、自然と届けられていくだろうし。逆にやっぱり、どっちかと言うとマーケティング側がしっかりとプロダクトを理解して出していくと、やっぱりそれはより広がっていくだろうし。その辺の関係性っていうのはすげー重要だな、っていうのは、僕もメルペイに来てすごい体験していますね。
山口：あー、大事ですね。そうそう。うん。最初は、たぶんインタビューとかを積み重ねて、ある程度、ペルソナだ課題だシナリオだ、っていうのを特定していって。で、その上で、例えば、ダーティプロトしたりとか、あとプロトタイピングとか言うんですけど、そういったものを繰り返していって、ある程度さ、「そのプロダクトを出したときにどういう使われ方をするのか」とか「ああ、ここが売りなんだな」とかっていうのが、だんだん確信めいてくるわけですよ。
hidek：うんうん。
山口：で、そういうのがわかってくると、マーケティングするときに、「このセグメントに対してこの機能をフィーチャーしたいんや」とかってだんだん決まってくるんで。そこら辺がね、まさにこういった風に書いてあって、我々のプロダクト組織として、そういったところを大事にしていきたいなぁ、っていう風にPM陣で意を固くしているところです。
BtoB、SaaSプロダクト開発の難しさ
hidek：なるほどね。そういった意味で言うと、今、zigorouさんがいるベルフェイスっていうところのプロダクトっていうのが、いわゆるBtoBのプロダクトじゃないですか？
山口：うん。
hidek：で、BtoBがBtoBで、今のOpen Product Management Workflowの使い方がやっぱり変わってくると思うんですけど。BtoBって、今までzigorouさんって経験したことありましたっけ、職場として？
山口：えーとね、ないですね。
hidek：はじめて？
山口：サイボウズ自体がBtoBではあるけど、僕自身、本体とか触ってるわけじゃないし、製品開発していたわけじゃないので、はじめてですね。ただ、サイボウズ・ラボの場合、サイボウズ製品を社内で使うから、身近ではありましたけどね、すごく。
hidek：なるほどね。BtoBプロダクトの難しさってたぶんあると思うんですけど、gamiさんもたぶん、まさにBtoBのところやってらっしゃると思うんですけど、この辺、なんか課題と言うか難しさ、BtoB SaaSの、特にSaaSってなるとまた難しいと思うんですよね。その辺の何か、gamiさん、課題とかあります？
gamiさん（以下、敬称略）：そうですね。たしかに。難しいところ。
山口：難しいですね、BtoB SaaS。SaaSってある程度、科学されている領域じゃないですか。KPIとかも大体決まっていて。で、そのKPIに対して、例えば、死の谷がどうのこうのとかさ。あと、「CACに対して12ヶ月以内に回収できないとアカン」とかそういう指標が、健全性を示すところがわかりやすいっちゃわかりやすいので、しかも積み上げモデルっていったところなので、着実性はありますよね。で、あと、どこを上げていけばいいのか、とかいう感じで論理的にやっていけば、そんなに本来難しいはずじゃない、って言ったらいいのかな。だから、いかにデータをちゃんと集めて、それを分析して、で、それの先行指標とかそういう指標をきちんと定めていけば、着実に成長させられるとは思うんですけどね。そこら辺はすごく面白いっちゃ面白いんですよ。エンタメとかだと、不確定要素がかなりあるじゃないですか。「面白いかどうか」とか。
gami：そうですよね。腰を据えて開発しやすいような気はしますね、BtoB SaaSの場合。
山口：そうそう。僕はそう思うんですよね。エンジニアから不人気じゃないですか、SaaSって。
gami：（笑）。そこは結構課題だな、と思っていて。「BtoBだから」「BtoCだから」っていうのできっぱり区切れるものでもないですけど、やっぱり、「toCやりたくてBtoBとかちょっと違うんですよね」みたいな人、結構多いなと思っていて。でも、SaaS領域だとかなり落ち着いて開発できたりとか、面白いところもあったりすると思うので、そういうところも魅力が伝わるといいな、というのは採用観点とかでも、日々思っていたりしますね。
山口：あー、それはありますよね。だから、いわゆる「問題解決そのものを楽しみたいエンジニア」とかはすごく楽しいと思うんですよ。で、あんまり事業にこだわりのない人って結構いるじゃないですか。こだわりがない、って言うとちょっと語弊があるかもしれないけど。要は、「自分の興味のある領域じゃないとイヤ」みたいな。たぶんhidekさんとか、それに近いですよね？
hidek：うーん、まあ、そうですね。どちらかと言うと。
山口：僕は、実はあまりこだわらないタイプなので。だから、別に抵抗感がないというか。
hidek：うん。BtoBで難しいとか敬遠されがちなところって、僕らも経験した気がするんですけど、どうしても、特定顧客に対してのカスタマイズを強いられることがあったりとか。特にパッケージだと多かったような気がしていて。
山口：あー。うんうん。
hidek：だからSaaSだと、そこは敬遠されないのかなとは思うんだけど。それって、イレギュラーなものを入れるのって、エンジニアはちょっとイヤじゃないですか。
山口：やだやだ。
hidek：なるべく作ったものをスケールされたりだとか、レバレッジ効かせたりとか、そこはひとつなのかなー、というのと、あと、BtoB SaaSになると、どうしてもSLAみたいなのが厳しいでしょ？
山口：あー。
hidek：先頭にお客様がいて、で、その先にもお客様がいるから、どうしてもひとつの障害の影響度が大きい。まあ、まさに僕らがプラットフォームで経験したことだと思うんですけど。
山口：そうですね。
hidek：なので、ここに対するSLAの厳しさ、障害に対する厳しさ、みたいなのが。そこを楽しめるエンジニアだといいんだけど、そこに腰が引けるエンジニアも一定いるのかな、という気はしますけどね。
山口：うん。後者の方は話が簡単だと思うんであれですけど。まず、SaaSとして、あんまりシステム的に手広くやり過ぎちゃうとよくないですよね。あれもこれもってなっちゃうと。そうすると、一定のサービスレベルを維持しなきゃいけない対象が増えちゃうと、それだけでもう終わりになっちゃうと思っていて。だから、たぶん手広くやるっていうのは、組織の能力とちゃんと成長度合いが一緒になっていかないと厳しいよな、と思うので。だから、そういう組織作りとか今の組織レベルみたいなものとプロダクトをどういう風にしていくかっていうところの両輪だと思うので、そこら辺を見誤ると組織が崩壊するよな、とは思っていますね。
hidek：なるほどね。あと、ビジネスというかマーケティング的な話でいうと、ベルフェイスもフリーミアムモデルですよね？
山口：いや、違うんですよ。フリーミアムモデルじゃない。うん。
hidek：あ、そうなんだ。いきなり1ライセンスでも有料なんですね。
山口：いきなり有料。だから、フリートライアルとかも基本はやって……、一時期やっていたりとかしたんですけど、今は公式にはやってないんじゃないかな、たぶん。
hidek：gamiさんのところは？
gami：うちもそうですね、基本、ほぼほぼ一緒ですね、今、おっしゃられてたのと。たぶん、昔はやってたけど、結構、価格をガーって上げて、エンタープライズに寄せて。でも、一部のプロダクトでちょっと安めの、1プロダクト切り出して使えるようにする、みたいなのを最近やっと始められそう、みたいな。
hidek：なるほどね。よく、toB向けのやつでフリーミアムモデルだと、どうしてもライセンス数での課金になるじゃないですか？
山口：うんうん。
hidek：そうすると、使っていただいている会社が成長しないと、なかなか課金もされていなかない、という。結構、一蓮托生というか、その辺が運営的には難しいのかな、というのが思ったりとかしてました。
山口：それはありますね。たぶん、それはいわゆるSMB領域に売っている場合に、だと思うんですよね。これが、先ほどgamiさんのところでもありましたけど、エンタープライズに、ってなると、「いかに全社導入に限りなく近いように導入してもらえるか」だと思うんですよね。ちょっとKARTEだと、全社導入的なラインはあんまないかもしれないけど。
hidek：うん。
山口：ベルフェイスの場合だと、セールス、全員に使ってもらう、みたいなのはあり得る話なので。だから、一発のボリュームがデカかったりとかはするんですよね、すごく。
hidek：うんうん。さっき、エンジニアリングの観点で言うと、toBで言うと、より品質みたいなところに敏感になるのかなぁ、という風に。僕は、オープンプラットフォームをやっていたときには、常にそれは言っていたつもりで。どうしてもひとつの障害、障害ゼロっていうのは難しい、ないとは思うんですけど、なるべく早く復旧する、っていうのをみんなにお願いしていたのは、止まってしまうことによって、その人たちの収入が断たれるわけですから、やっぱ、そこは意識しないといけない。だから、品質に対する意識っていうのは、すごく僕も意識してたんですけど。QAだとか品質担保で何か工夫していることとかってあったりとかします？
山口：今年度くらいからなんですよね、力入れ始めたのが。僕、入社が去年の12月なので。僕の入るちょっと前、というかもうちょっと前か、QA組織みたいなのが立ち上がったのが今年度の春くらいとかそんなタイミングなんですよね。
hidek：そうなんだ。
山口：それまでは、まだ全然「お手製」みたいな。要は、「関係者がやる」みたいな感じだったけど、やっと「組織として」って感じで。で、今月か先月から、とりあえず「セット組織を立ち上げるぞ」という風な感じにはなった、って感じですかね。
hidek：うんうん。
山口：今、もう、プロセス自体見直していて。今、シフトレフトっていう、いわゆる開発の計画が始まる段階からQAとかセキュリティとかが入っていく、みたいな方向性になっています。要は、上流から抑えにいこう、みたいな。っていう考え方になりつつありますね。
hidek：なるほどね。うんうん。メルペイだとね、どうしても、toCだけじゃなくてtoBも実はあって。いわゆる加盟店様って呼ばれる、メルペイを使ってもらうお店ですよね、も僕らにとってはお客様なので、そこに対してプロダクトを出していく、っていうところがあるので。あとは、お金っていう大切なものを扱うので、結構、QAはコストをかけてて。
山口：あー、そうね。お金扱うとすごく神経使いますよね。
hidek：そうなんですよ。ただ、今はリグレッションテストとかが、今まで人力で頑張ってたんですけど。やっぱりプロダクトが成長すると、人でやれることって限界があったりだとか、そこはボトルネックになりがちなので、今Q前Qかな、会社のOKRに、いわゆる「テストの自動化」っていうのを掲げてもらって、基本的にそこにリソースを割いていきましょう、みたいなトライをしたりだとか。結構、品質に関しては、toBという自負もあるので、その辺は工夫とかもしてますね。でも、テストの自動化は難しくないですか？
山口：いやー、難しい。これからですよ。E2Eテストの拡充みたいなのって、これから検討ですね。部分的にはあるんですけど、Autifyの導入とか、今、考えてたりとかしてて。
hidek：うんうん。
山口：しかもあれだとね、エンジニアじゃなくても一定作れる、っていうのがあったりとかするんですけど。我々、WebRTC使ったオンライン会議システムの部分があって、あれがね……。
hidek：テスト、結構大変ですね。
山口：そうそう（笑）。うん。難しいですね。
hidek：音質とかって難しいですよね。
山口：あー、音質とか、もう全然無理でしょ。
hidek：一応、定量化たぶんできるんでしょうけど。テスト音声流して、たぶん、その波形のなんかやったりとかするのかな。
山口：そこまでやるか、っていう問題はあるけどね。むしろ、もっと先に担保するべきことがある、という気はするけど。でも、そうですね。そういったところもあって、難しい領域もあるけど、一定、結構使えるのかねー、なんていう感じの話はしているところではありますね。
hidek：うんうん。
山口：で、それを最終的にはちゃんとCIとして回す、っていう風にはなってくるんだろうけど。品質問題とかSREの部分とか悩ましいですよね。
この記事が気に入ったらサポートをしてみませんか？