【カミナシ原トリ×AlphaDrive赤澤】フェアなエンジニアリング組織をつくるために「短期的な非合理を取っていく」CTOの度量

それまでひとりエンジニアとして開発を担当し、あるいは、テックリードとして小規模なチームを任されていた──ある日CTOを打診されたものの、エンジニアリング組織をつくるために何から手を付けていいのか迷子になった人もいるのでは。

そこで今回、多様な経験を積み、30代にしてスタートアップのCTOに就任した株式会社アルファドライブ CTOの赤澤 剛氏と、株式会社カミナシ CTOの原トリ氏にインタビュー。2人がCTOとして、どんなエンジニアリング組織を目指しているのか伺いました。2人が理想とするエンジニアリング組織とは、そしてその組織をどうやってつくろうとしているのでしょうか。

※こちらの対談は前後編に分けてお届けしております。前編では、「CTOになる」という選択がお2方のキャリアにもたらしたもの、そしてCTOとしてやり遂げたいことについて伺いました。

• keyboard_arrow_down 中長期の合理性のために、短期的な非合理を選べるか
• keyboard_arrow_down 目を見て「フェアである」と説明できるか
• keyboard_arrow_down 自分がボトルネックにならないために
• keyboard_arrow_down 自分と真逆の人に、CTOのバトンを渡せる状況をつくりたい

──お二人が現在見ているエンジニアリング組織の規模を教えてください。

赤澤：AlphaDriveのエンジニア組織は現在主にユーザーグループの中で、法人向けのSaaS開発に携わっています。メンバーはNewsPicks所属のエンジニアが7人、AlphaDrive所属のエンジニアが約20名ですね。

トリ：カミナシのエンジニアリング組織は、現在ソフトウェア開発の正社員エンジニアが9名、加えて業務委託や副業・兼業メンバーなどが複数名参画しています。チーム全体の人数は、約15名ほどです。

──CTOとして、どのような方針でエンジニアリング組織をマネジメントしているのでしょうか。

赤澤：僕たちは「全員プロダクト開発エンジニア」という方針を掲げています。サーバーサイドやフロントエンドなど、それぞれ役割や強みを持つ領域はあるけど、そこを厳密に分けるのではなく、全員オーバーラップしてやっていくほうが強い組織になると思っています。

「お客さまにより良いプロダクトを提供する」というゴールがあるなら、領域などこだわらずに、あらゆる手段を尽くして課題を解決していくべきだと思いますね。

トリ：カミナシも同じですね。サービスを構成する要素はたくさんあって、サービスの課題を解く際に技術スタックの中の「どこで解くべきか」は毎回違うはずです。自分がフロントエンドが得意だからといって、フロント側で無理やりコードを書くことが、根本的な解決策にならないこともある。サーバーサイドやインフラ、運用を改善することが、本質的な可能性もありますよね。

だから課題を解くHowを考える際に、「それはどこで解くべき課題なのか」を考えられるソフトウェアエンジニアがたくさんいる組織でありたいですね。良いサービスをつくり出すために必要なのは、本質的な解き方を考えられるソフトウェアエンジニアですから。

赤澤：あと、「全員プロダクト開発エンジニアである」ことは、組織として楽しいカルチャーをつくる大前提になる気がします。

例えば、フロントエンドでも、インフラのスタック構築までやってみたいのであれば、全然やってみればいいじゃんと。メンバーのスキルの幅が広くなることは、中長期的に組織の成長に絶対つながる。短期的なリリースの速度が落ちたとしても、最終的には必ずプロダクトにとっても、お客さまにとっても、もちろん組織にとってもプラスになります。

だから、自分のやりたいことにキャップをしないでほしいですね。

トリ：技術的な挑戦をすることに関しても、同じことが言えると思いますね。たとえ誰も知らない技術でも、それがワークするビジョンが見えていて、かつチームに浸透させる努力ができるのであればチャレンジすればいい。

赤澤：そうそう、うまくいかないことも含めて成果だし、自分も一緒にフォローするよって感じですよね。

トリ：「新しい技術を取り入れて、その技術がスケールしなかったらどうしよう」などと、懸念することってあると思うんですけど、どこまで先を見通せるかは、その時点の組織の技術力にかかっていて、見えなくてもしょうがないことです。重要なのは、後で見えてきたときに、それを正す力を持つほど、組織を成長させられるかどうかです。

ぶっちゃけ、僕らは受託開発ではなく自社のSaaSを開発しているのだから、「仮に失敗して、それが数年後に発覚しても、最終的に自分たちでケツを拭けばいい」という覚悟で取り組むなら、チャレンジはどんどんすればいいと思いますね。

赤澤：僕らは「中長期の合理性のために、短期的な非合理をいかに取れるか」を合言葉にしていて。「短期的な非合理」とは、例えば新しい技術を学ぶ期間も含まれます。もちろん、技術的負債の解消も。その間は一時的に新機能などのアウトプットが落ちてしまうけど、短期的な合理性のみを追求すると、中長期的な非合理を生んで組織は死んでいきます。

技術選定も、8割は「なぜその技術を使うのか」という合理性が必要だけど、お客さまに対価を提供できる前提で、エンジニアとして成長し、開発を楽しめる組織になると思えるなら、最後の2割は「やってみたい」だけで決めてもいい。この2割の非合理をいかに選び取るか、そして現時点では2割の余力を今後どこまで大きくできるかは、CTOの器量が試されるところですね。

──CTOとしてエンジニアリング組織でやり遂げたいことはなんですか。

赤澤：わかりやすい1つを挙げると、みんなの環境や待遇、給料を上げたい。技術に対する適切な報酬ラインまでに、いかにして給料水準を引き上げられるかは自分の課題ですね。

お金が全てではないけど、「事業で誰を幸せにするのか」と同じぐらい、働いているメンバーが「うちの会社っていいよね」と素直に思える状況を、気持ちだけでなく待遇面でもつくりたいと思います。

トリ：メンバーに対してフェアでありたいよね。CTOという立場的に、僕らのほうが圧倒的に事業に関する情報を多く持っている。事業の利益が出ているのであれば、それをお互いがフェアだと納得する金額でメンバーに還元したいというか。

給料が安い会社が全てダメなわけじゃないけど、少なくとも利益が出ていて、それを使って社員の給料を上げられるのにも関わらず、優先順位がなぜか役員報酬に向かうような会社は意思決定を誤っているのではと思います。

個人的には、エンジニアの皆さんには社員に面と向かって、給与の額がフェアであることを説明できる会社に行ってほしいです。

赤澤：すごくわかります。相手の目を見てちゃんと説明できるかは、定性的な指標ですけど、僕もあらゆる決定の指針にしています。特にマイナスの判断を相手の目を見て説明するには、その背景の説明責任が求められますから。

トリ：実は4月にカミナシに入社してすぐ、ソフトウェアエンジニアの給与テーブルを他職種と切り離して、条件を引き上げたんですよ。それはフェアネスの意味もあるし、市場のソフトウェアエンジニアの給与レンジとマッチしていなかったから調整しました。経営メンバーも社内外のデータに基づいてすぐに決断してくれて、会社規模が大きくなってもこういうフェアさは維持したいですね。

一方、給料を上げるには、もちろんその対価に値するスキルセットや成果が求められます。カミナシのエンジニアリングチームはすごく頑張っているけれど、まだまだスキルセットもマインドセットも高めていくフェーズにあるので、自分は今そこにも取り組んでいる感じです。

赤澤：あと、話は変わっちゃうんだけど僕はいつも「Keep Lazy!（怠惰であれ）」って言っているんですけど、とにかくエンジニアが怠惰でいられる組織にしたいんですよね。「みんながやりたくないことをやらずに済んで、やりたいことに集中できる世界」をつくりたい。そのために、技術的負債を解消するとか、自動化できることはさっさと自動化するとか、仕組み化するとか。そういうことを進めていって、とにかく「Keep Lazy!」を達成したいですね。

──CTOとして組織から求められていることについてもお聞きしたいです。1エンジニアとして求められているものとの決定的な違いは何だと思いますか?

トリ：まだCTOになって間もないので仮説ですけど、「僕がHowの部分で手を動かしてしまうと、僕の限界値が組織の限界になる」ということでしょうか。

プロダクトをつくる際の「Why」「What」「How」の中で、エンジニアはまずHow、つまりプロダクトをどうつくるかについてプロフェッショナルであるべきだと思っています。それができたら、WhyやWhatにも貢献していくのが僕のポリシーです。

要は、CTOの僕がプレイヤーとしてHowに寄った動きをすると、僕自身はすごく楽しいんですけど、そのほかの部分が見えなくなってしまう。今はいかにHowの部分に直接的な手出しをせずにエンジニアリング組織が理想的な方向に進んでいけるようになるか、そのための俯瞰的かつ大きな枠組みを用意することが求められていると思っています。

赤澤：めちゃくちゃいい話。トリくんの「Howの大きな枠をつくる」というのは、僕自身も意識していることです。僕が製品開発に入り込みすぎちゃうと、僕の存在が逆に組織のボトルネックにもなり得ますから。

いかに枠を広げて、チームメンバーが自由に駆け回れるフィールドを一緒に作っていけるかかが重要だと思います。その際、自分の中で戒めにしているのは、僕が相談相手ではなく、承認者や報告相手になった瞬間に終わりだということ。

「メンバーが相談しにきてくれない」っていうことが起きる組織もありますけど、言葉を選ばずにいえば、そんなの「相談されないリーダー側の問題じゃないかな、メンバーのせいにしちゃダメだよ」って思うんですよね。話す価値がないと思われているのかもしれないわけだから。

僕は、「赤澤に話せば自分のアイデアがより良くなるかもしれない」と、相手に自分と話すことにメリットを感じてもらえる状態を維持したい。CTOという立場に関係なく、壁打ち相手として見てもらえる存在でありたいですね。

トリ：相談してもらえるっていいですよね。困ったときに壁打ちをしたい相手として、頭の片隅に置いておいてほしい気持ちはすごくあります。

赤澤：そのためにも、技術レベルは相談相手に足り得る水準を維持し続けなきゃいけないな、と思います。

トリ：プレイヤーだった頃は、自分の目の前の仕事をいかに片付けるかに時間を使うけど、CTOになってからは組織が自走できるようになるために時間をかけるように意識していますね。そういう意味では、仕事のプライオリティがすごく変わりました。

自分一人ではなく、組織が成果を出すことが重要だから、相談を受けたときの気合の入り方も全然違う。プレイヤーのときは「ググった？」って軽い気持ちで言っていたけど、今は「一緒にググってみようぜ」と言っています（笑）。

──トリさんは7月にCTOになったばかりですが、今の時点で不安なことはありますか？

トリ：シンプルに、ひたすら考えて信じて意思決定したことが失敗して、会社を潰したらどうしよう、という不安はすごくあります。

僕は割とラディカルに意思決定するタイプなんですよ。ただ、カミナシはいまダイナミックに成長しているなかで、プロダクトや組織に歪みが出始めている部分も見えてきていて、だからこそ意図的に保守的な意思決定に倒している部分も一定程度あります。その結果、会社をいい方向性に導かなければと常に考えていますね。

ちなみに剛は3年後とか、組織を考えたときに不安に思うことはある？

赤澤：「次のCTOにいつ、どうやってバトンを渡すのか」は時々考えますね。どういう状態だったら、その人に自分がCTOになってよかったと思ってもらえるんだろうって。

まだCTOとして、やらなければならないことはいっぱいあります。ただ僕は、交代を常に意識しておくことで、メンバーや組織の状況を感度高く見れていると思うんです。今からシビアに考えておかないと、いつの間にか僕が目の上のたんこぶになってしまう気がして。

──どういう状態でのバトンタッチが理想なのでしょうか？

赤澤：お客様により良いプロダクトを届けるというゴールがあるから、売上などの数値的な達成が軸になると思っています。もちろん達成できたら、それを一つの指標にバトンタッチするし、達成できなかったとしても、「自分ができる最善はここまでだ」と区切りをつけるタイミングは来る。達成の場合も、未達成の場合も、僕の中には引き際としての数値的な基準がありますね。

──前後編とお話を伺ってきましたが、最後に改めて、CTOとはどのような役割だと思いますか?

赤澤：僕はキャリア篇でもお話した通り、「技術の課題を会社の重要な課題として組み込む人」だと思っています。

たとえエンジニアとして一番技術に詳しい状態が実現できなくても、経営の意思決定の中で技術を重要視して動き、会社の決定を技術でより良くしていくべきですね。

トリ：一方で、メンバーの視点から考えると、優先順位がどこにあるかを、会社全体の話としてチームに説明するのがCTOの役割なんでしょうね。経営と現場の翻訳者として、技術の視点を経営に持ち込み、経営の視点を現場に持ち込むことが求められていると思います。

CTOとしていろんな経験を積んだ再来年ぐらいにまた聞いてもらえたら、もっとかっこいいことが言えるんじゃないかな。

赤澤：会社によってCTOのタイプは違って、僕みたいな「雑草系CTO」が役に立たない会社もあると思うし、AlphaDriveにも、より技術やアカデミックな視点が強いCTOを迎えるべき日が来るかもしれません。多様なエンジニアが伸び伸びと活躍できる組織をつくることが僕の役割だと思いますね。

トリ：僕もそうですね。例えば会社のフェーズが変わってきたら「基礎技術の観点からこの会社を買収すべき」みたいな、今の僕ではまだできなさそうな意思決定ができる人物が次のCTOになるみたいなのもいいと思う。なので、自分がCTOでいる間に、そういう人を受け入れられる会社にしたいですね。

対談前編（キャリア篇）はこちら＞＞＞

取材・執筆：天野夏海
撮影：若子jet