技術的負債解消における「8割の合理と2割の非合理」の考え方　強い組織を作るために必要な、ゴールと手段の明確化

CTOとしてチャレンジしている2つのこと

山元亮典氏（以下、山元）：キャリアの話でどんどん盛り上がっているところではありますが、せっかくなので今CTOとしてチャレンジしていることなどの話をぜひ聞いていけるとうれしいなと思います。

今まで挑戦してきたことやこれから挑戦したいことなどをインタビューできたらなと思うのですが。

赤澤剛氏（以下、赤澤）：ありがとうございます。そうですね。2つあって。

まずやってきたことで言うと、私が入社してからアルファドライブという会社で組織、エンジニアチームを立ち上げたんですが、僕が1人目、2人目の状態で、ちょうど2人で始めたんです。今ようやく20を超えてというタイミングになってきて、最初は5人、10人の文化でかなり強く作れたなと思うので、これを文化としてどんどん浸透させて、組織を拡大していくことは1つ（チャレンジしていきたいこととして）あるかなとは思います。

もう1つ、ユーザベースとしては大きなエンジニアチームがあるんですが、グループの中で新しいチームを会社の中で作った時に、やはりエンジニア、エンジニアリングが経営とどういうふうに結び付くかを、最初は相当意識して経営メンバーと話してやることができた。

それでけっこう強い文化（を作ることができた）というか。エンジニアチームだけじゃなくて、企業としてエンジニアやプロダクトをどう考えるかという文化が、少し対話的に作れていったんじゃないかなと思ったので、そこは改善や反省もいっぱいある中で、自分の中では1つけっこう良かった（こと）かなと思います。

CTOは技術課題を経営課題にできる人

赤澤：やはり僕自身が「CTOの役割って何だろう？」と考えた時に、“一番優れたエンジニア”という表現よりは、経営の中で一番技術に詳しくて、もう1歩踏み込んで言うと、技術課題を経営課題にできる人がCTOだと思っていて。

技術負債の解消なんかはそうですよね。だからプロダクトは事業とセットで作る。例えば「技術的負債はエンジニアが悪いから、エンジニアがどこか自助努力でがんばって工数を作って直す」というのは、一番良くないパターンだと思います。

山元：そうですね（笑）。

赤澤：これは「どっちにする？」という択一で見るんですが、ゴールは一緒のはずです。良い機能をたくさん早く作りたいというゴールは、みんな共通じゃないですか。技術負債の解消も機能を作るのも実は同じゴールで、ただ、いつの時点でその機能の総量を最大化するか。いつピン留めするかだと思うんです。

3ヶ月後、半年後だったら技術負債を置いてやるべきだし、2年後にマックスにしたいんだったら「今、技術負債の解消でフロントのリアーキテクチャをしましょう」っていう判断（になるだけ）で、ゴールは一緒じゃないですか。あとはタイミングだけの話で。

どちらがエンジニア（の問題）でどちらが事業（の問題）で（ということ）じゃなくて、同じ経営ミッションとして、お客さまにいいものをたくさん作って、数値的には売上やトップラインやMRR（​Monthly Recurring Revenue​）を上げるってなった時に、「どういう手段で何年後にプロダクトを最大化しますか？」「じゃあ、今、技術的負債の解消をしましょう」と。

これは、誰かが悪くて変なエンジニアが変なものを作ったんじゃなくて、お客さまが増えて時代が経ってアーキテクチャの技術も変わってきて、必然的に負債化したものだから、「しっかり経営課題として理解して、プロダクトを解消しましょう」とする。

これは自分の中で最初にCTOとしてやるべきだと思いました。よくいろいろなところで言うのですが、カミナシ社のCTOのトリ君（原トリ氏）とこの話をして、僕はすごく感銘を受けて納得できたところです。

これを組織や経営メンバー全員と合意してやれるようになってきたことは、組織を作りながら自分の中でできたことの成果かなと思っています。

マルチプロダクトをどう1スイート1プロダクトにしていくかが今後のミッション

赤澤：今後のミッションでいうと、今SaaSが先ほど言ったエンタープライズクラスも含めて3つぐらいあって、周辺の小さなサービスも2つ、3つぐらいあって。

山元：けっこう多いですね。

赤澤：これらをどう1スイート1プロダクトにしていくのかは、1つのミッションです。やはり事業の独立性が高いので、アーキテクチャもけっこう独立していて。それこそアカウントも独立していて。今ちょうど、いろいろなサービスがNewsPicksのIDでログインできるようになって、IDプロバイダーとして成立させていっているんです。ちょっと細かい話ですが、例えばプロダクトによってテナントの構造とか考え方が違ったりするんですよね。

山元：そうですよね。

赤澤：何がややこしいかというと、これって宗教なので。間違っていたら正しいほうにそろえればいいんですが、テナントの考え方は「あっ、そっちのパターンね」という（感じで）、「良い悪い」じゃなくて「それもある」。例えば「テナントをこういうふうに捉えて、サブドメインをこうしているプロダクトもある」。これも1つのポリシー。良い悪いじゃなくて、それぞれの考え方を整合させて、「テナントをどうする」「契約をどうする」「シート管理、席数管理をどうする」ということも考え出すと、「あぁ、1プロダクトってどうするかな」というのは1つすごくありますね。

山元：難しいですね。けっこうおもしろいですね。

赤澤：そうなんですよ。もちろんお客さまにとって便利な機能の連携として、そのフロントの機能との連携として「NewsPicksで読んだ記事がこっちにこう見えて」とか、「誰がどう読んでいるかわかって」とか、「それを新規事業でやる時に活かせて」とか。そういう機能間の連携と裏側の基盤の統合との両面があるので、そのあたりをどう整合させてやっていくかは、次のポイントかなというのはあります。

山元：それはやりがいがありますね。Voicyもけっこう同じところがぶつかっている部分ではあるので。

赤澤：わかります。マルチプロダクトは（そうなりますよ）ね。でも、毎回自分に言い聞かせるんですけど、製品が成長してお客さまがついてそういうことを考えられるようになったからこそ（そういう問題が出てきているということ）なので。

技術的負債という呼び方をされますが、資産がしっかり人に使われて売れてきたからこそ「どうする？」となるんだから、ある意味「幸せな状況だね」という感じではありますよね。

山元：そのとおりですね。どう（いうふうに）IDプロバイダーを作って、データをどうするか。我々もtoBとtoCなどいろいろな事業があって、それぞれのニーズが違ったりするので。

赤澤：そうなんですよ。

山元：その中で、統合をどうするかみたいなことを、まさに今話していたりするんです。

赤澤：いいですね。おもしろいですね。テナントとかプロダクト統合飲み会をやりましょう（笑）。

山元：その際はぜひ知見もいただければ。

赤澤：いやいや、私も一緒なので。こういうのがやはり自分の中でけっこうおもしろいトピックではありますね。

もちろん単体のSaaSとしてどんどんお客さまについてもらってというところはあるので、SaaSとしての拡大もあるんですけど、1スイートというか、事業としてクロスセルで買ってもらった時に、お客さまにどう追加のメリットを提供できるか。そこがやはり1つ今考えているところです。

山元：そうですよね。いや、そこはめちゃめちゃ話したいところではあるので、深い話はまたということで。

赤澤：そうですね。それこそ鍋でね（笑）。

技術的負債解消における「合理」と「非合理」

山元：技術的負債はけっこう関心の高い人が多いトピックなのかなと思います。

経営課題として大きくリソースを割いて取り組むパターンと、技術的負債を継続で解決していくパターンもあると思うんですよ。そういったところは何かコントロールされているんですか？

赤澤：そうですね。やはり継続的にそういった工数は確保していますね。例えば一番短い単位でいうと、アジャイルの原則として、バグを後から直すんじゃなくて、最初にバグを直してその状態を維持していく。維持という概念がアジャイルの1つのポリシーだと理解していて。

なので極端な話、いつどこでリリースすると言われても、その断面で切ってリリースできる状態を維持していくという考え方がある。だから、「後から直そう」じゃなくて、比較的早期の段階で負債を解消したり、不具合の修正もということで、前のフェーズでやって、それを維持する。例えばユニットテスト。E2Eで維持するとか、リアーキテクチャも比較的早いタイミングでかけたりというところはあります。

技術的チャレンジのところもけっこう工数を取ったり、マインド的に例えば技術選定とかアーキテクチャ設計も2割非合理を取るということを強いチームポリシーにしていて。

山元：おもしろいですね。

赤澤：どういうことかというと、合理性を積み上げていくと、中長期で非合理が生まれるんですよ。極端に言うと、例えば誰かから「えっ、それ今Railsでやって……」。あっ、Railsが悪いわけじゃないですよ。例えばの話で出しただけですが、「Railsでダメですか？」って言われ（たとし）て。

思いません？　「今どきのアプリケーション、Railsで作れないものなんかないし」って。よくできているフレームワークだから、たぶんこれ、PHPでも（もちろん）できるし。ただ、それをずっと続けると施策が1つ（に限られること）で、エンジニアとしてのキャリア的にもおもしろさに欠けて（しまいます）。

例えば、（社内の）強いエンジニアが違う言語やスタックが使えて伸びているサービスのところに行くこともチーム的には起きちゃったり。例えばフロントの技術も成長しなかったりするので。

僕自身は過去に合理性を追求しすぎたという反省があって。（今は）非合理を適切に取り込むことが最終的に全体としては合理的だという考えになったので、8割は「なぜこの言語なのか」「なぜこのアーキテクチャなのか」を当然説明できなきゃいけなくて、それを自分たちがお客さまにサービスとして提供して、しっかり責任を持って保守していけることが大前提なんですが、2割ぐらいはやはり「やってみたい」とか「なんかカッコイイ」とか、そういう。ワード的には極端な非合理なんですけど。

山元：（笑）。

赤澤：でも、そういったものを無視することが、やはり最終的に非合理を生むので。8割、2割（で考えています）。何割非合理を取れるかがある意味、組織のキャパの強さだと思っていて。感覚値ですが、僕らだと今2割から3割ぐらいの非合理性を取れるというところはあって。それがお客さまにしっかりいいものを提供して、自分たちがストレッチして技術的にも広げていったりというところ（につながっているという思い）はあります。

山元：おもしろいですね。非合理、合理。確かに。

赤澤：そうなんですよ。「今やってるこれでいいじゃん」と言いだして、それを積み重ねると、最後には強い組織じゃなくなっていく。

昔でいうと例えば「jQueryじゃダメですか？」みたいな。（jQueryは）よくできているからできないものがないという話をしだしたら、「（それは）できるに決まってんじゃん」みたいな。そういうのはけっこうありますね。極端な例ですけれど。

山元：そうですよね。正論ばかり言い合っても決まらないというか、永遠にスコープも広げてしまうし（笑）。

赤澤：そうなんですよ。正論ばかり積み重ねると、最後はなぜか非合理的という。

山元：確かにそのとおりですね。短期的な決断につながってしまうというところは、やはりけっこう大きいのかもしれないですね。

赤澤：そのとおりですね。だから、いつの時点のゴールで話しているか。エンジニア同士もそうだし、事業とエンジニアでも一緒に話す時には、どのタイミングで何を実現するための話かを意識しないといけなくて。

ゴールの抽象度を上げるとそもそも絶対そろうわけですよ。具体（的）にすればするほどずれていくので。極端に言うと「私とあなたは世の中をハッピーにしたいですか」というところまで抽象度を上げたら、それはそろうわけです。

だから「お客さんにいい機能をたくさん早く提供したいですよね」「もちろん」「いつの時点で最大化させますか」と。事情があって3ヶ月後がピークだったら、「このアーキテクチャのリアーキテクチャをかけずに、現行のアーキテクチャで機能を作り続けることがベストです」となる。

「いや、2年後こういうのを達成したいから」ということで、2年後をマックスにしたいのなら「この半年間は新規機能開発を止めてリアーキかけるのが最善じゃないですか」というふうになるので。どこでゴールがすり合って、どこから手段としての議論になるのかはけっこう明確に意識しています。

特にプロダクトと事業系の話だったら、やはり意識しなきゃいけないポイントだなと思って。

山元：そのとおりですね。2年先なんて不確実性が高すぎて、カオスすぎてというところはあるので。僕はよく、アートという言葉を使っています。アーティスティックにという感じで、決断で迷っている人がいた時は、「最後はアートだよ」みたいな感じで言っているところがあります。

赤澤：わかります。

山元：やはりみんな「けっこうちゃんとロジックを作る」とか、「データ分析をちゃんとしないと」みたいな感じでやっていたりするので、そこの感覚と近いのかなと。

赤澤：一緒ですね。一番もったいないなと思うのは、迷っている間に両方できるケースがあって。

山元：ああ、はい！

赤澤：左か右か迷っている間に、左に行って正解だったらOKで、左に行ってダメだったら右へ行って戻ってくる時間もあるぐらい迷っていることがあるじゃないですか。最初は考えれば考えるほど、その思考の結果の確度がどんどん上がっていくんですが、ある時、「ここまで行ったら絶対にやらないと結果はわからない」というフェーズが来るじゃないですか。

僕はこの見極め精度の優れた人が、比較的優秀と言われるリーダーの1つのポイントかなと思っていて。

考えなくてやるのも違うと思っていますが、考えて、精度が上がっていくけれど、これ以上はアクションしないといけないというタイミングの見極めが早い人がリーダーになると僕は思ったりするんです。

なので、今まさにお話しされたことがそうで、「ここまで行ったらもう左に行こう。ダメだったら右に行こう」みたいな。

自分の中で甲乙丙というか、松竹梅みたいな案ができて、優先度が高い案で「ここまでやって、ここまでやって、ここまで行けるんだったらここまでやろう」というアクションで、パターンを出して選択するという状態で動くしかない時があるので。「じゃあ、ここからはアクションね」と（決めると）いうのは本当にそうだと思います。

山元：「ここまでが合理的で、ここから非合理的で」という感覚ですよね。

赤澤：そうです。

山元：そこのセンス。あれはセンスなのかよくわからないですが、うまい人は本当にうまいですね。抽象的に全部理解をして、ガッと大きい決断をできるみたいな人とか。

赤澤：そうですね。今自分でしゃべっていて、その例を出して思い出したんですけど、昔の上司と一緒にご飯を食べに行って、左に行って間違って、右に行って、「赤澤君、これがアジャイルだよ！」と言われた時は、「違うだろ、マップ見ろよ」とは思いました。

山元：（笑）。

赤澤：今その例を出して、実際にやられたら「いやいやいやいや、マップ見ろよ」と思って。左に行って「違う、右だ！」とか言って、「これがアジャイルだ！」と言われた時に、「いや、違うだろ」って。

山元：ちゃんと仕様を確認しましょうよと（笑）。

赤澤：それはグーグルマップを、みたいなことをさっき思ったので。でも確かに、比喩表現としてはそういうのがアジリティ、アジャイルかなとも思ったりしますね。

山元：おもしろいですね。なるほど。ありがとうございます。

（次回に続く）