溜まりがちな技術的負債にどう向き合えばいいのか　4社のCTO・VPoEが語る、それぞれの「攻めと守り」

4社のCTO/VPoEが「攻めと守り」を議論

白石久彦氏（以下、白石）：ここからはパネルディスカッションということで、私はakippaの技術顧問を担当している白石と申します。僕が司会進行、雑談の回し役みたいな感じですが、やらせていただきます。このパネルディスカッションは、「急成長ベンチャーのCTO/VPoEが語る攻めと守りのバランス」というイベントタイトルのままで、いくつかの質問・トピックで話していきたいなと思っています。

パネラーのみなさんは、先ほど登壇いただいた下司さん（下司宜治氏）、川口さん（川口将貴氏）、森住さん（森住卓矢氏）と、あとはakippaの井上さん（井上直登氏）と、akippaのテックリードをやっている村上さん（村上健一郎氏）にもここからジョインしてもらいます。村上さん、一言よろしくお願いします。

村上健一郎氏（以下、村上）：私はakippa株式会社でバックエンドのテックリードをやっています、村上と申します。本日はよろしくお願いします。

（会場拍手）

白石：この6人でやっていきたいと思います。パネラーのみなさんに言っておきますが、パネルディスカッションはチームプレイなので、僕が滑ったらみんなの責任、僕がウケたら僕の手柄でやっていきたいと思います。

（一同笑）

白石：チームプレイでよろしくお願いします。

お客さんを知らないと進めにくいところもあるので、みなさんに軽く挙手のアンケートをお願いしたいなと思うのですが、エンジニアはどのくらいいますか？

（会場挙手）

やはりエンジニアが多いですね。ありがとうございます。エンジニア以外のプロダクト開発に携わっている職種の方はどのくらいいますか？　PdM、デザイナーとかですね。

（会場挙手）

ありがとうございます。それ以外の方は？

（会場挙手）

まぁまぁいますね。けっこうプロダクト開発に携わっている方が多いということで、お客さんの分布はなんとなく把握したので、そんな感じでやっていけたらなと思っています。今回は、一応akippaプレゼンツということで、各社のCTOやVPoEにお集まりいただいていますが、ここは公開コンサルティングのようなかたちで進めていけたらなと思っています。akippaのエンジニアリングの現場は、（スライドを示して）今こういう課題を抱えています。溜まりがちな技術的負債、よくあることですが技術的負債を抱えています。「フレームワークがばらけています」とか「EOLが過ぎたテックスタック」がある状況になっています。

技術的負債のコントロールは誰がしているのか？

白石：ここから少しずつお話をうかがっていければなと思います。「溜まりがちな技術的負債とどのように向き合えばいいのか」。先ほど各社の事例をみなさんに話してもらったのですが、そこから聞いていければなと思っています。例えば技術的負債は、スピードと技術的にやらないといけないことの排反によって起こるところがよくあると思います。そのあたりを聞いていければなと思います。

例えば、そういうスピード重視と、ある程度きちんと見越してやっていくことを誰がどのようにコントロールしているか、事例をちょっとずつうかがっていければなと思います。どうしよう。アンドパッドの下司さんから、誰がコントロールしているんですか？　ルールはありますか？

下司宜治氏（以下、下司）：アンドパッドだとけっこうチームが分かれていて、10チームぐらいになっています。それぞれにプロダクトのテックリードがいて、管理範囲がそのチームごとに分かれているので、技術的負債の基本的な向き合い方はそのプロダクトのテックリードに任せている部分がけっこうあります。

一方で、任せているので、テックリードが放置してしまう場合もありはするんですね。そういったところは、全社的な横断組織もあるので「ちょっとそこは放置しすぎじゃないですか？」と、アラートを上げたりはしますね。そのように向き合っています。

白石：ありがとうございます。放置しちゃうテックリードは全社で横串を刺すチームが「ダメだよ」みたいな話をしていくんですね。

下司：そうですね。横串のチームが「ダメだよ」「ここはいつまでにやろうね」と話をします。そういうテックリードは基本的にプロダクトマネージャーの方々から「新しいものを作ってほしい」と言われていて、どうしてもそっちに寄りがちなので、僕らはテックリードだけではなくプロダクトマネージャーにも「ちょっとこういうことがあるので協力してくださいよ」みたいなことは言っています。

白石：ありがとうございます。BASEの川口さんはいかがですか？

川口将貴氏（以下、川口）：うちはそこのテックリードがいないので、どうしたいかを順番に聞いたり、そこの負債を返す作業をしたいのか、それともリリースをしたいのかを聞きます。最終的なジャッジは僕がしている部分がまだあります。そのあたりをもう少し委譲していかなきゃいけないのが課題かもしれないです。

白石：でも、SREのマネージャーも兼ねているので、そのへんの安全性も守備範囲はCTOということですか？

川口：そうですね。ちょっと兼務が多いので「ここが負債なのでは？」みたいな気持ちはありますね。

白石：（笑）。絶賛募集中という話も先ほどあったので、興味がある方がいたらこのあと捕まえて話を聞いてみてください。森住さんはどうですか？　SmartHRさんの事例を。

森住卓矢氏（以下、森住）：そうですね。テックリードという役割はないのですが、各チームにプレイングマネージャーが常にいます。社内では「チーフ」と呼んでいる方です。基本的にはその人が全体的にプロダクトのテック面の面倒を見ている感じです。

どうやって外から検証しているの？　という話ですが、そこはスキップレベル1on1を通して定性的に把握しています。チーフをスキップしてメンバーと直接話す中で「開発しにくいところはありますか？」とか「技術的負債として感じているところはありますか？」みたいに話を聞いて、それをチーフにフィードバックして判断してもらう感じですね。

白石：チーフを飛ばして1度、1on1をして、そこで情報を集めて客観的に見てフィードバックするという話で合っていますか？

森住：そうですね。だいたいの頻度としては1Qに1回ぐらいかな？　チーフをスキップして「メンバーはこう言っていましたよ」というのを伝えて「じゃあどうしましょうか」という感じですね。

白石：ありがとうございます。「横串を刺す組織はけっこう最近までなかった」という話があったと思いますが、そのスキップ1on1は誰がやるんですか？

森住：SmartHRの階層構造が今はVPoE、マネージャー、チーフ、メンバーになっているので、マネージャーがチーフをスキップしてメンバーと1on1をしています。

白石：なるほど。初めて聞いたおもしろい取り組みです。メンバーの声を拾うということですかね。ありがとうございます。

「これだけは絶対にやっちゃダメ」というルールは存在する？

白石：そのあたりで、例えば全社で決まっている「これだけは絶対にやっちゃダメ」みたいなルールがあれば聞いていきたいなと思います（笑）。下司さんはありますか？

下司：やっちゃダメなルールですか？

白石：なければ「ない」って言ってもらって大丈夫ですよ。

下司：「やっちゃダメ」って言ったことはたぶんあまりないですし、あまり言いたくないです。先ほど言ったように、Design Docを書いていて、Design Docでレビューしているので「Design Doc書かずに進めないでね」と言っているぐらいですかね。

白石：なるほど。では何をやってもいいけど、Design Docに書かれたものに対してきちんとチェックやレビューが入るという感じなんですか？

下司：そうですね。勝手にやることはほぼないので「やっちゃダメ」と言ったことはあまりないですね。

白石：ありがとうございます。BASEの川口さんはどうですか？

川口：「やっちゃダメ」って、どうなんですかね。まぁ、誰も幸せにならないことはやらないでほしいなとは思っています。もともとルールを決められるのが好きじゃないので、決め過ぎないようにはしているつもりです。強いて挙げると……。難しいですね。「やっちゃいけない」か。そんなにルールは作っていないですね。それこそ採用で「これだけはダメだよ」とマネジメントが必要な方は事前に確認するようにしているかもです。

白石：採用で。

川口：採用の時点からポジティブではなくなってしまっていると思うので、これまで業務で制約する人はいなかったなと。

白石：（笑）。

川口：逆にやっちゃいけないものってどういうものがあるんですかね？

白石：なんでしょうね。それこそ先ほどの下司さんの話じゃないですけど、レビューできちんとチェックできていれば、提案は自由だと思うんですよね。だから提案できちんと会話ができればいいと思うんですけど、自分で決めたものを自分で進めちゃう。レビューの機構もない組織だったりすると、どんどんそういうものがプロダクションに入っていっちゃうみたいな。

川口：それでいうと、うちはそうなんですよね。内部統制でレビューが通っていないコードは僕にも回ってきていないので、絶対に入らない構造にはなっていますね。ガードレール的なものも作っているというのはあるかな。

白石：森住さんはいかがですか？

森住：そうですね。SmartHRもそんなに「これはやっちゃダメだよ」と、言語化しているルールはないですかね。GitHubの仕組みとして「何人かがApproveしないとマージできませんよ」みたいな機械的なものは存在していたりしますが、意思決定をする時に「ここのガイドラインに沿わなきゃダメ」みたいなのは特にない感じです。

白石：例えばSmartHRさんだとRailsでやっている印象がすごく強いんですけど、Rails以外のものを使う提案もぜんぜんありなんですか？

森住：ありはありですね。SmartHRはすべてのプロダクトがバックエンドがRailsで、フロントエンドがReactとTypeScriptなんです。共通のGemやReactのUIコンポーネントライブラリを用意しているので、けっこうその資産があって「その資産を捨ててでも突き進むならいいよ」という感じで、そこまでのものは今のところなかなかないです。

白石：提案は一応受け付けるけど、それを突破できるの？　みたいな話になっちゃう感じなんですね。

森住：そうですね。技術スタックも、もともとRailsをやっていなかった人が入ってきて、徐々にRailsの経験者が増えている状況なので、そういう社内のテックスタックも考慮した上で「それでもやる必要があるならば」という感じです。

白石：「チャレンジはぜんぜんウェルカムですけどね」という感じですかね。

森住：そうですね。小さいところでそこはそんなに気にしなくてもいいかなというところでRustで遊ぶとかはぜんぜんやれるかなと思いつつ、現状は本当にでかめのプロダクトでそういう冒険をしているのは特にない感じですかね。

（次回へつづく）