BASEとnoteのCTOがあえて触れずにメンバーに任せる理由

パーソナライズと多様なユースケースへの対応に取り組みたい

司会者：ありがとうございます。今お話ししてもらった内容にも紐づくと思うんですが、次のテーマに移ろうかなと思っています。「2021年に強化して取り組むこと」。課題と直結するところもあるかなと思うんですが、こちらもぜひお聞きしたいです。今度は今さんからお話しいただけますか？

今雄一氏（以下、今）：まず安定性とパフォーマンス改善。これがベースになっています。ありがたいことに2021年もさらにトレンドが上がって、ユーザー数も投稿数もPVも増加傾向にあります。また負荷対策をすることになっているんですが。

川口将貴氏（以下、川口）：はい、うちもです。

今：まだやるべきことというか、やるネタは豊富にあるので、1個1個を試していっているという感じです。ほかには、技術的にアーキテクチャの改修ですね。特にサーバーサイドです。

ストレージレイヤー、データベースにちょっと不安やリスクがあるので、基本的な作戦はこれらの分割ですね。これを方針として考えていて、いろいろ試しています。可用性を高めていきたいと思っています。これが最低限で、プラスでnoteの読みたい記事にすぐに到達できるなど、パーソナライズですね。僕らって昼飯を食べているときに無意識にブラウザのウィンドウで「Twitter」や「YouTube」など打っちゃうじゃないですか。

川口：はい、打ちますね。

今：動画を見ながら飯を食べるじゃないですか。これってなんでなんだろうなと思っていて、読んでもらいたい人にどう到達させるかが大事だと思っています。

昔はパーソナライズをされていると嫌がるユーザーが多かったと思うんですが、ここ1、2年でトレンドが変わったなぁと思っています。機械学習でリコメンドしないと逆に怒られるというか、当然の品質になっていると思っています。お問い合わせでもそういう感想が増えています。

川口：そうですね。シークレットモードでYouTubeを見ると、ぜんぜん見たいサイトじゃないですからね（笑）。

今：そうそう、そうなんですよ（笑）。toCの場合、ユーザーさんが完全にリコメンドされることに慣れたなって思います。もっと言うと、僕も同じ感想です。もっとリコメンドしてくれよと思うので。そういう部分を強化していきたいなと思って、いろいろやっています。

川口：コンテンツがすごく増えたので、自分でフィルターするのが限界な人がけっこう多いんですよね。

今：そうですよね。BASEさんはECで、そもそも提供すべき機能がとても多くて、ドメインもメチャクチャ複雑だからそれに対応するだけでもかなり骨が折れるなという印象なんですが、どうですか？

川口：実際そうです。「初めてショップを開設してみました」などインターネットにもまだそんなに詳しくなくてフリマアプリくらいの感覚で使ってくれている人から、配送を自動化していたり問い合わせをbotで対応していたりする大規模なショップまでいて、いろいろなユースケースがあります。

求められている機能をひたすら実装していても、一生やることがあるなみたいな感じです。BASE APIというものを提供していて、それを利用した開発会社もいるので、APIエコノミーみたいな感じで、エコシステムはこれからけっこう重要になってくるだろうなと薄々感じています。

BASE APIはベータ版ですってずっと言っているので（笑）。そこをどうベータ版じゃなくするかも課題ではあります。

今：確かに相性がよさそうですね。

川口：機能開発、プラス、サードパーティ向けのAPI開発ってなるとけっこう大変で。そこのリソースの部分の確保が開発時に難しいなと思います。

今：そうですよね。Tシャツを売るにしても、魚を売るにしても、本を売るにしても、例えば、Tシャツだったらサイズ数を、S、M、Lで選べたほうがいいとか、まとめ買いすると割引きになるとか、ドメインごとに文化が違ったりもしますよね。

川口：ぜんぜん違いますね。この時期だと、テイクアウトの需要などもあって。それで、5月や6月に今までの開発計画を変えて、「テイクアウトApp」を実装しているので、ニーズが本当にすごく多様だなっていう部分はありますね。

今：noteと似ているなと思っているところが、ビジネス向けやイラスト向けや小説など、ドメインをまったく絞っていなくて、全ジャンル対応するぞっていうところです。メディアもそうですね。画像も音声も動画も提供するぞっていう感じでやっていますよね。

言うのは簡単なんですが、UIや体験を破綻なく設計するのってメチャクチャ難しいと思っているんですが、BASEさんもそういう感じなんですか？　

川口：簡単に使えるという軸は、絶対にブレないで設計はしているんですが、多様性という意味では難しいし、そんな感じですね。とはいえ、最初は小さなショップだったけども、どんどん成長されて規模が大きくなっていくショップさんから要望があるようなユースケースにも対応していかないと。

リファクタリングやリアーキテクトには読み解くスキルが必要

今：技術的にはリアーキテクトの話がありましたが、どういう方針で、向こう何年くらいやられるんですか？

川口：これが非常に難しくて、うちのテックリードがいろいろ考えてくれている部分もあるのであれなんですが、結局、機能開発の部分を止められるのかっていうのはあります。1年や2年止めて、フレームワークを全入れ替えしてっていうのが、ハッピーなのかって言われると実際その1年間、開発が止まっていることによる、ショップさんに対して新しい価値を提供できない状態っていうのはフレームワークを乗せ替える以上に損なのでは？　と思う部分もあります。

じゃあビジネス的な開発の部分や、プロダクト的な開発と並行しながらどうリアーキテクトするかを考えるたびにけっこう難しいかなと思ってはいます。一部機能を絞って、リアーキテクトしていくのは進めています。

既存機能をほぼそのまま踏襲して、コードの奥底に眠る謎の仕様を読み解くみたいな。なんでこうなっているかはわからないけど、これは必要なんだろうか!? って思いながら（笑）。

今：ありがちですよね。それ。

川口：本当にありがちですねぇ。剥がしやすいコードだったら、こんなことには当然なっていないはずなので、むろん剥がしづらい。ビッグバンリリースにしすぎると、たぶんみんなの身も保たないので、どう緩やかに移行できるかがけっこう鍵ですね。

今：はいはい。

川口：CakePHP2はリリースしてもう10年のフレームワークなので、4系になっているとはいえ、2系の頃なんて、チュートリアルが「ブログを作ってみよう」なので、ブログを作る以上のことをさせちゃうとなかなか大変そうだなっていう印象です。

コードがドキュメントになることを考えて、うちではDDDの選択肢として取りはじめてはいますね。

今：うんうん。ちなみに、例えばRailsだったら、アップデートガイドみたいなものがメチャクチャ手厚くて事例も多いので、エイヤっでやることもあると思うんですが、CakePHPだと、2系 3系 4系って断絶がかなりあるんですか？

川口：3系と4系は案外そうでもなくて、2系と3系が致命的にないんですよね（笑）。モデルDBからフェッチしてきたのが、3系まではただの連想配列みたいな感じなんですが、3系からはきちんとエンティティみたいなクラスになるので、この時点ですべてが終わっています。

今：なるほど（笑）。その時点でメチャクチャでかいですね。

川口：だから、エイヤでやろうとすると全部ダメになる感じです（笑）。最初に見たときに、あ、終わってるって思いました。

今：はいはい。

川口：ランサーズさんは2系と3系を同居させる移行プランをやっていて、パワーがあるなと思います。

今：ビッグバンでいくのか、エンドポイントごとに少しずつやっていくのかの2択だとは思いつつ。

川口：コードの考古学みたいなことがけっこう必要になってきました。それができるエンジニアはすごく貴重ですね。

今：基本的にリファクタリングやリアーキテクトなどの既存実装を読み解くのはスキルがけっこういりますよね。

川口：そうですね。どちらかというと、エンジニアって理系が多めな印象ですが、作者の気持ちを考えなきゃいけないので、文系的な国語の能力がすごく必要です。「そのときの作者の気持ちは？」と考えると、だいたいコメントはないんですが、コードだけでなんとか類推して、そのときのプロダクトオーナーに思い出してもらえるようなコミュニケーションをしたり、Slackをひたすら漁ったり、ドキュメントツールを漁ったりするのはすごく必要な能力です。

もちろんアーキテクトを作るという意味では、高い技術力は必要だとは思うんですが、それを実際にかたちにしようと思って、泥臭いことをすごくがんばるのが大変ですね。

1年で倍に増えたエンジニア　体系的に知識を伝えていくのが課題

司会者：そろそろ次のテーマに移ろうかなと思います。次のテーマなんですが、今の課題に紐づくかもしれないんですが、エンジニア組織の課題と今後というところで、こちらをお話いただきたいです。いかがでしょうか？

川口：エンジニア組織で言うと、メンバーがありがたいことに……2020年でエンジニアは何人増えたんでしたっけ？　覚えています？

司会者：何人増えたかはすぐ出てこないんですが、今業務委託の方も含めて70人くらいなので、20人、30人は言い過ぎかもしれないですが、けっこう増えたんじゃないですか？

川口：増えていくと、やっぱりオンボーディングはすごく課題です。うちはそろそろ始めて7年になるサービスで、リポジトリが大きくて、マイクロサービスになっているわけでもないので、覚えなきゃいけないベースの知識がすごくたくさんあります。まして、今はリモートワークが重なっているので。

知識のインストールや、ほかのチームとのコミュニケーションはけっこう課題になっています。テキストチャットが得意なメンバーであればコミュニケーションも容易なんですが、みんながみんなそうではなかったりしますし。

コードを読み解く能力も人それぞれなので。ドキュメントがすごく書いてあればオンボーディングってうまくいくんだっけっていうと、たぶんそうでもなくて。どうステップアップしてベースの知識を獲得するかは課題かなと思います。

本当に全部覚えなきゃいけないんだっけ、知らなきゃいけないんだっけというと、そうでもないので。よしなにサービスを切り出してあげることはしていかなきゃなとは思っています。

人数が増えて、1回もリアルで会わずに面接、入社を済ませ、早1ヶ月経つ人もいます。こういうこと（コロナ禍）が起きるまではまったく想定していなかったので、準備もそんなになくて、どうするものなんだろうなって思っています。

司会者：noteさんも2020年はかなり人数が増えたというお話がありましたが、実際どんなことが課題ですか？

今：当社のエンジニアは40人弱くらいの人数なんですが、2020年で倍に増えました。BASEさんと似たような感じなのかなと思っています。うちも7年選手のコードで、私はイチからやっているのでだいたいわかっているんですが、仕様的にけっこう複雑だったり、明らかに負債の香りのする部分があったり、もちろん濃淡はいろいろあるんですが、こういうのを伝えていく必要があるなと思っています。

過去の障害事例をスライドにまとめていて、だいたいパターンは似ています。ダメなクエリ打っているとか、ワーカーにキューを積みすぎとか、ロックを取っていないとか、サーバーエンジニアなら踏みそうなやつですよね。

川口：よくありがちな。

今：やっぱり結局そうなるので。事例があるとけっこうわかりやすいというか。

川口：設計のレビューに出ているんですが、指摘するところは「過去にこういうことあったよな」って思い出すこともけっこうあります。それこそ「メンテナンス時の挙動は大丈夫？」とか。

開発しているときはあんまり気づかないんですが、「メンテナンスが入ったときにここをフィックスできなくなったらどうするの？」とか。実際過去に障害になったりした部分を当てはめてみるとけっこうありましたね。

今：そうですね。大規模サービスにあまり触れてこなかった方もいるので、ゼロイチとイチヒャクってやっぱり扱う技術テーマというか、気をつけるポイントがぜんぜん違うなという肌感があります。とはいえ、当社で経験を積んで、成長してほしいので、レビューなどを通じてなんとか伝えようとしている感じですね。

川口：BASEやnoteさんなど、それこそソーシャルゲームを経験しているとデータのオーダーの数がぜんぜん違くて。

今：うん！

川口：1万件だったら耐えられるけど、100万件だったら耐えられないからどうしようかなぁと事前に考えられる人たちはやっぱり強いです。その考えは一子相伝みたいに口頭で伝達しないと無理なのかっていうと、そうでもないと思います。もっと体系的に知識を伝えていかないとなとは思いますね。

今：ちょっと話が大きくなっちゃいますが、やっぱり運用ってやってみないと知識が得られないのが難しいポイントかなぁとも思っています。特にtoCの大規模サービスはそんなに数が多いわけではないので、インストラクションが難しいなとは思っていますね。

川口：どううまく経験させられるかっていうのがすごく課題です。実際に障害対応などをすると一番身につきやすいじゃないですか。

今：そうですね。

自分でやっているうちは2流　心を鬼にしてメンバーに任せる

川口：問題は目の前で起きているし、ユーザーに迷惑をかけているので、だいたい僕らが率先して対応しちゃうわけじゃないですか。

今：メチャクチャわかりますね。

川口：それをやっちゃうと、ほかの人たちは一生学べないしなぁみたいな。

今：それをやっているうちは二流だと、自分に言い聞かせているけど。

川口：本当にそうなんですよ。任せきれないって思っているのと一緒なので、自分は二流だなぁと思いながら、あーあと思いながら自分で対応することはあって。心を鬼にしてあえて触れないようにするのを意識していかないといけないですよね。

今：それもあるんですが、フロントエンドやインフラの深い部分などは、当然僕以外で、メチャクチャ知識もスキルもある人がいるので、そういう人に気持ちよく働いてもらえるようにしたいというのはもちろんあります。

組織をなるべくフラットにしているというのも、基本的には大方針だけは伝えるんですが、どう解くかは各々考えてもらうためです。私もぜんぜん口出ししないので、突然マイクロフロントエンド的な分割路線になっていたりもしましたけど。

川口：それはすごいですね。

今：任せているので、ぜんぜんオッケー（笑）。

川口：誰かの独善的じゃなくて、チーム間がきちんとコミュニケーションできていれば、ぜんぜんいいかなという感じはします

今：そうですね。急にマイナーな言語やフレームワークに変わっているわけではなくて、基本的には需要に添っているのでいいかな。

川口：そこらへんの意思決定って、ふだんテックリードなどに任せちゃっている感じですか？　

今：下回りの安定性とかは私が見るんですが、意識的に任せようとはしています。組織が大きくなってくると、基本的にはマイクロマネジメントはしないほうがいいなと思っていて、メンバーの成功体験を積み上げていく方向でやっていきたいというのが前提です。

川口：僕も過去自由にやらせてもらった結果が今なので、自分が任せられる立場になってから、そういうのはいまいちって言い続けるのはダサイなって思っているんですが、つい指摘してしまって、まだ成長ができていないなと思っています……。

自分がシングルポイントになっちゃうというところは……組織よりは個人の課題な気はしてきましたけど（笑）。

今：そうなんですよね。100人、200人くらいの規模だとそうなっちゃいがちだと思うんですが、そうは言ってもいられないのはもちろん承知していますと

川口：100人、200人くらいだとなんとかできちゃうから良くないんですよね。なんとかできちゃうわと思っているうちにさらに組織がスケールして、いかんともしがたくなって、それこそ人的な障害になるというのがシステムと一緒かなとは思っています。

（次回へつづく）