役割のベースは「成功のためなら手段は問わずになんでもやる」　CTOが絶対的に“オープンマインドでいる”べき理由

「レバレッジを効かせられているか？」を常に意識している

藤倉成太氏（以下、藤倉）：みなさんは、ボードとの関係性はどうですか？

横塚出氏（以下、横塚）：僕もどちらかというとそっちのタイプかもしれないですね。アイデアをどう実現していくかみたいなエグゼキューション寄りのタイプではありました。

今雄一氏（以下、今）：小橋さんは、かなりやりたいことが多そう。

横塚：ありそうなイメージはあります。

小橋昭文氏（以下、小橋）：自我が出てきます。

（一同笑）

小橋：なんでしょうね。ある意味やりたいことというか、やはりスタートアップというのはアイデアがあったり、当然やりたい世の中・作りたい世の中があって、それに対して自分の中に仮説があるわけですね。仮説がないけど挑むというよりは、たぶん仮説を作りながら挑んでいくんだと思っていて、自分の中の仮説が崩れることも含めて繰り返しやってきています。

「手段を問わず」という言葉が先ほどありましたが、その会社の方針を決定していく中で、ITやテクノロジーが適切なのかどうかを常に考えながらやっていくというのがたぶんすごく重要で、私も意識はしています。

ビルドトラップみたいな、作りたいから作っちゃうというのもすごく重要なんですが、特に「レバレッジを効かせられているんだっけ？」というところを含めて、ある意味、自分を自分で否定できるところは、注意していますかね。もちろん私は自我が出てきやすいんですけど（笑）。

（一同笑）

小橋：そこが注意しているところですね。

デリバーのしやすさも大事な変数

藤倉：私は創業者でもなければ創業期からジョインしたCTOでもなくて、わりと1エンジニアとして最初は会社にジョインした経歴があるんです。

でも会社の規模が小さい頃からずっといて、自分が開発のマネージをするようになってからはもう常に「あの案件どうなってる？」「あれはいつ出るんだっけ？」と期待をしてくださっているいろいろな人たちに矢継ぎ早に聞かれるんですよね。やはり我々が機能をデリバーしないことには何も始まらないので、そういう経験が多かったなと思うんですが、そういうのはどうですか？

横塚：でも、日々追われますよね。

（一同笑）

今：完全にそのあたりは昔と変わらない。

横塚：そうですね、ずっと。

今：だからそれで言うと、デリバーのしやすさも大事な変数だと思っています。最初の技術的な方針を妥当に決めることもCTOの大事なミッションだと思うんですけど。これもまた変数で、開発者やエンジニアがいないとか、CEOがぜんぜんテックに詳しくないとか、いろいろな変数がある中でデリバーしやすい方式を選ぶ必要があります。

ビルドトラップの話もありましたが、極論それは別に「Shopifyでいくね」みたいなこともあると思っていて。「それ、0→1でプログラミングする必要あるの？」みたいなところまでを踏まえて考えるのがCTOの仕事なのかなと思います。

藤倉：そうですよね。アーキテクチャも別に正しい・間違っているというのはないと思います。それぞれの仮説があって、時には「いや、モノリシックでいくんだ」というのが正しいかもしれないし、本当の初期の初期、エンジニアは自分1人しかいないけど「マイクロサービスでいきます」。これも1つの仮説かもしれません。

それも含めて、自分たちの会社にとって良い未来に早く近づくにはどうすればいいかも考える。やはりテクノロジー系のことが多いし、経営チームの中でたぶん一番自分が詳しくなきゃいけないという自覚もあるので、主にそこに対していろいろな発言をしたり、考えたり、時には説得したりするのがCTOの役割という感じなんですかね。

“新しいオフィスのネットワーク設計”は創業期CTOのあるある

小橋：そうです。付け加えるとすると、スタートアップはいろいろありますが、ITというのはすべての組織にとって欠かせない存在になってきていると思うんです。ITと言うと、例えばGoogle Workspaceをどうやって運用するか、社内の権限をどうするか、社内の情報流通、権限まわりをどうやって構築するか。ある意味、自社のデータモデリングをしないといけないとかもあると思っています。

こういうものは、CIOと言われる場合も多いと思うんですけど。特に人手不足という状況下のスタートアップでは、そういうデータ、組織、リアル世界の人を含めて、このITの道具をどう合わせにいくかというところで、結果的にテクノロジーの専門性があったり、適正な人としてCTOがやる場面が多いかなと思いますし、私もずっとやってきたところはあります。みなさんはどうですか？

今：創業期CTOのあるあるだと思いますね。だいたい兼任して社内データモデリングをしますね。

藤倉：スタートアップだと人が急激に増えて、オフィス移転するじゃないですか。新しいオフィスのネットワーク設計をするとか、あるあるですかね。

今：ありますね。Wi-Fiの機器をどうしようかとか。

（一同笑）

藤倉：そうですね。

横塚：その流れで、コーポレート本部の担当役員をやっていた時期もありました。

（一同笑）

横塚：社内DXの課題は、コーポレートITの領域から、請求まわりだったりいろいろあるじゃないですか。なので、兼任はありますよね。

藤倉：そうですよね。社内の業務をいかに効率化するか。そのために今使える外部のテクノロジーを調達してくることですら、求められたりもするし。

今：なので、「なんでもやります」じゃないですけど、コンピテンシーとして絶対的にオープンマインドである必要はあると思っています。

藤倉：「これしかできません・やりません」ではなく。

今：そうですね。

藤倉：それは、グルっと回って最初にみなさんがお話しされていた、「とにかく成功するためだったら手段は問わずになんでもやる」というのがやはりベースにある、というところに戻ってくるんですかね。わかりました。ありがとうございます。

技術スタックの最終的な意思決定の責任を持っている

藤倉：では、ちょっと次のトピックにいきたいなと思います。お話の中でいくつか例が出ましたが「Cクラスの人、CxOの人は、テクノロジーバックグラウンドを持ちながら、とにかくなんでもやる」ということまでわかった。

じゃあ実際に、日々何をしているのか、もうちょっと解像度をググっと上げた話も聞いてみたいなと。そんなことを知りたいと思っているオーディエンスの方もいるんじゃないかなと思います。

お話できる範囲・できない範囲があると思いますが、例えば最近CTOとしてちょっとやっている・やっていたプロジェクトでお話できる範囲で……我々の仕事はいろいろな帽子を被り分けながらやっているので、何をどういう役割でやっているというのはちょっと難しいとは思いますが、「これはCTOとしての自分がやっているな」と思うような仕事をなにか紹介していただけますか？

小橋：一瞬考えてしまいましたが、いわゆる典型的なCTOっぽい仕事をまずお話しします。

本当につい最近なんですけど、私の場合は組織のエンジニアが今90人から100人ぐらいになってきているので、ある意味いろいろなプロジェクトが並行で走り始めているというところで、典型的な例だと技術スタックはどうするかとか。

今回のテーマにもありますが、開発者の生産性をどうやって上げるのか。あるいは上げるフェーズなのかどうか、ということを考えることが増えてきて、「言語もいろいろ試したいけど、統一しないと運用できないね」みたいな、そういうところの最終意思決定をするという責任は持っていると思います。

決めないという意思決定もできると思うんですが、そういう意思決定は、もう少し強くしていこうかなというところで社内の事情をあらためて把握したり。その意思決定の重要性を発信していったりというのを徐々に始めているのが、本当に私の直近数週間でやっていることです。みなさんはどうですか？　もしかしたらもうみなさんだと、できあがっているんですかね？

今でもコードを書くことはあるか？

横塚：どういう時間の使い方をしていますかね。今は、例えば新規サービスの立ち上げには週2ぐらい使ったりしていますけれども。開発のソフトウェアのチームができてきている段階なので、当然ボードメンバーで経営の方向性の摺り合わせをしたり、開発の生産性のモニタリングのチェック等々は週1、リーダーと1on1というかたちではやっていますけれども。直近は私は、新規サービスの立ち上げに従事しています。

今：個人でプログラムも書いたりしているんですか？

横塚：今年はちょこっと書いていました。

藤倉：おぉ！

今：そうなんですね。

横塚：はい。あと、週1はお客様を訪問したりとか。けっこういろいろフィードバックをいただいたりとか。最近（プログラムを）書いていますか？

今：書いていますね。

（一同笑）

横塚：今さんはゴリゴリ書いているイメージ。

今：あまり良くないと思いつつ、書くことは多いですね。

藤倉：でもそれもけっこう人によりますよね。

横塚：そうですね。

藤倉：こだわりであったり、ポリシーみたいなものを持ってコードを書き続けているCTOの方もぜんぜんいらっしゃるし。一方で、私なんかはSansanでCTOを始めた時ぐらいから、別に明確に決めたわけじゃないですけど、他のやるべきことが多かったり。もしかしたら自分のキャラクター的にそっちのほうが……まさに小橋さんがおっしゃっていた「レバレッジが効く」と思っていたのか、わりとコードを書かない仕事に自分を寄せたかもしれない。

なので、もう本番のコードは、この10年……は、言い過ぎかな。でも7、8年は書いていない。お2人はどうですか？　

小橋：本番で動いている……。ええとね、負債化したものを運用しているという意味ではたぶん少しありますね。

（一同笑）

小橋：よくある「とりあえずなんとかしないといけなかった」みたいな。瞬発力でなんとかしちゃったものが負債化して、自分でそれをいかになくすか、委譲していくかみたいなところは部分的にはもちろん残っているんですけど、ある意味意図的に本番のところは避けるようにしている。自分1人では運用ができないし、かつスクラムやチームで開発するというのは、ミーティングが多い人としてはすごくやりづらいんですよね（笑）。

週末にコードを書いてポンッと出していくみたいな、あまり健全じゃない部分もあるので。避けようとはしている部分はありますね。

今：私の動き方で言うと、けっこう最初のトライやプロトタイプを作るのを任されがち。CTOあるあるだと思っていて、例えば「機械学習が流行ってきたからちょっとやってよ」とか「検索システムが遅いからちょっと新しいスタックを試してよ」とか。最初にちょっと実験をしてフィジビリティが取れたら現場メンバーに渡すとか。

横塚：リスクの探索的なところとか。

今：そうですね。最近も現場のメンバーに任せられるようになって、私が書いた機械学習のコードがプロダクションから全部消えて、メチャクチャうれしかった。

小橋：いいですね。

（一同笑）

横塚：多少はありますよね。私は逆に明確に人員工数や、どれぐらい投資できるかが読めない時は（コードを書いています）。

今：そうですね。触ってみないとわからないというのはありますね。

横塚：やらないとわからないですよね。

初期の頃は採用にも関わっていた

藤倉：開発という行為自体もある種、先行的に投資をする行為に近いなと思いますね。出してみないとわからないということもあるので。ただ、技術的なフィジビリティスタディとなっちゃうと、投資に足り得るかすらわからないみたいなところの判断もどうしてもすごく曖昧というか……。なので、ちょっと現場のメンバーに任せにくかったりもしますよね。オーダーが複雑すぎたり、判断基準を明確にしてあげられないので渡しにくい。

今：現場のメンバーに抽象度の高いお題は振りにくいというか。「ちょっとこの技術がいい感じか試してみて」みたいな。

（一同笑）

藤倉：いい感じ（笑）。

今：「いい感じって何だろう」みたいな。

（一同笑）

藤倉：そうですね。そういう時はちょっと自分が率先して手を動かすこともあるということですかね。CTOとしてテクノロジーをどうするかもそうですが、やはりその開発チームを強くしていく・大きくしていく・素早くしていくみたいなこともあって、初期の頃は本当に守備範囲が広いと思います。採用でもけっこうご自身が先頭に立ってやってきた感じですか？

小橋：そうですね。本当にすてきな採用人事の方々に助けられているというところは、もう大前提としてあると思うんですけど、ある意味、テクノロジー組織として何をやっていくかを言う責任があるというか。やはり興味を持ってもらう上では、言葉の重みも必要で、そこはすごく重要だと思うのですが、そこの仕組み化だったり、何を見極めたいのか、という点で関わっていましたね。

面接も「いい感じに面接して」というのを創業期にやっていたんですけど（笑）。「いい感じに面接してって何だろう」みたいな（笑）。当然現場の面接官から疑問が出てくるので、そういうところをきちんと整理していくことには関わっていましたね。最初は本当に恐縮ながらすごく雑に「いい仲間かどうかを確認してください」と、そんな感じでしたね。

（一同笑）

今：そうですよね。「一緒に働けそうかを確認してください」みたいな。

横塚：一番大事だったりしますよね。

小橋：そうですね。

藤倉：わかりました。ありがとうございます。

（次回へつづく）