CTOの魅力は「自分で意思決定をして、フィードバックを得ながら前に進むこと」
加川申祐氏（以下、加川）：それではパネルディスカッションを始められたらと思うので、よろしくお願いします。
一同：よろしくお願いします。
加川：（スライドを示して）1つ目のトピックはこちらです。「CTO、VPoE、テックリードのそれぞれの魅力とは」について語ってもらえたらと思います。
都筑友昭氏（以下、都筑）：ありがとうございます。では自分からいきますね。自分の思うCTOの魅力を話せればと思います。これは責任と裏返しというか難しさと裏返しではあると思いますが、責任の重さは魅力なんじゃないかなと考えています。
意思決定を自分がしていかないといけないというところと、その意思決定が数年後とかに跳ね返ってくる。そこで初めて答え合わせができるわけなんですが、それを見据えて自分で意思決定をして、フィードバックを得て前に進んでいくところがすごく魅力なんじゃないかなと思っています。もう1つは、CTOとなると、最終的には誰にも何も言われないので、自分でセルフモチベートをしていかないといけないんですよね。それが僕はすごくおもしろいなと思っています。
文句を言う相手がいなくなっていく中で、「なんで自分はこれをやっているんだろう」とかを考えていくうちに、自分のモチベーションの本質にどんどん近づいていって。結果として「純粋に自分がやりたい」とか、「会社のために」みたいな（感じで）、自分の本質に向き合えるかたちになっていくのが非常に役得というか、そういったところでは魅力のあるポジションだなと思っています。
都筑氏がCTOになった経緯
武藤悠輔氏（以下、武藤）：質問をしても大丈夫ですか？ 時間も気にしたほうがいいですか？
加川：（時間は）ぜんぜん大丈夫です。ぜひぜひ。
三上悟氏（以下、三上）：ワイワイやったほうが良い感じですよね？
加川：ワイワイやってください。（時間が）延びそうだったらちょっと……。
（一同笑）
武藤：事業に関わっている中で、（都筑さんが）CTOになった瞬間みたいなものってあるんですか？ 役割として、エンジニアからCTOに役割が明確に変わった瞬間があるのか、今もあまり変わらないでやっているかみたいなところって、どんな感じですか？
都筑：肩書きという意味では、法人化した瞬間がCTOになった瞬間ですね。「法人化しました」と言ったタイミングでやっている内容がその日から180度変わるかというと別にそんなことはなくて、やはりまだまだ0→1の立ち上げをしている中だったので、基本的にはコードをどんどん書いていく責務を担っていました。
気持ち的なところでいくと、我々はシリーズAでMBO（Management Buyout）をしているんですが、そのタイミングが気持ちとしてはやはりすごく変わったなと思います。
武藤：MBO以降のほうがより責任が伴うというか、意思決定に対して重みが付いてくるみたいな感じですか？
都筑：そうですね。あとはやはりサービスをただ作ればいいというものでもないというか、アウトプットの最大化はもちろんありつつ、アウトカムに対しても責任が生まれてくるなという思いが、気持ちの変遷としてはあります。
武藤：ありがとうございます。ちなみに今VPoEはいるんですか？
都筑：今VPoEはいないですね。なので私がCTOで加川がEMという体制になっています。
武藤：わかりました。
武藤氏がVPoEになった経緯
都筑：同じような流れで、武藤さんは最初からVPoEとして業務をやっていたんでしたっけ？
武藤：そうですね。私がVPoEになったのは、会社がスピンオフしたタイミングで実は取締役にはなっていて、そのあと改めてVPoEになったというかたちです。VPoEになったのには2つの意思表示があって、1つは「CTOではない」という気持ちも実はちょっと気持ちとして持っている面があります。
なんて言うんですかね。この会社を最大限スケールさせる時に、最初の3年間は少なくとも今の僕でもかなり成長させられるという気持ちがありました。得意分野を全部作るに近いことなので、その領域（について）は最初の2、3年は問題なくいくかなと思っていて。それ以降については、やはりCTOとしての仕事が明確にあるんじゃないかなと思っています。
そこに向けて自分もしっかりとCTO職を担えるように自己研鑽を積むというか、しっかりとインプットをしつつ視座を上げていくんですが、より適切な人がいた時にはその人をCTOに置いて、事業としての成長を最大限優先できるようにしたいという気持ちも込めているというのが、CTOではなくVPoEと付けている理由です。
もう1個は、「ちゃんとエンジニア組織を作るぞ」という（ことに）責任を持つことを明確にするためにVPoEをしています。これはいろいろな解釈があると思うんですが、どちらかというとCTOは指針を決めるほうで、VPoEは実行に責任を持つと私は認識しています。
そういう意味で、（自分が）やっているのはVPoEの仕事に近い部分かなというところでその名称を付けています。（この役職についた過程の）最初をたどると「1人目のエンジニアとして手伝い始めて」みたいな。都筑さんとまったく同じ経緯です（笑）。
最初はソフトウェアエンジニアが0人みたいな状態で困っているところを手伝い始めて、そこからガッツリ入り始めて、気づいたらのめり込んで今に至るみたいなところなんですね。（都筑さんと）けっこう似ている流れかもしれないなと思っています（笑）。
都筑：そうですね。すごくシンパシーがあるなと思いながらお伺いしました。最初の時点で数年後を見越して自分の役割を定義してVPoEを名乗るというのはけっこう凄みがあるなと思って聞いていました。
武藤：1つ気をつけたいなと思ったのが、自分より優秀な人を採用したいと思い続けないといけないということです（笑）。例えば自分がCTOであるために自分より強い人をちょっと避けようとなってしまうことは絶対に避けたいなというのも、自分を律するためでもあります。
三上：なるほど。そうですね。
三上氏がテックリードになった経緯
三上：ちなみに、弊社にはCTOがいなくて、VPoEの肩書きを持った人もいないんですよ。だからそういう意味でいうと、創業者である1人目のエンジニア社員の方が当時はCTOだったんですが、今はCTOの役割をやっていなくて。ほぼフルスタックエンジニア、何でもできる人みたいな感じの役割でゴリゴリとコードを書いていて。僕と同じテックリードという役割をやっていたりします。
先ほどの紹介でもありましたが、弊社は、全員が「開発部門リーダー」という「リーダー」の名前になって、C職（C-level）やVPoEがいない感じです。CTOとかは（今）募集しているところだったりしますが。
そういう意味でいうと、僕はCTOもVPoE的な開発部門長も経験済みな上で、今はテックリードをやっているというちょっと変わった経歴です。なので、先ほど見せてもらった図に関していうと、あれを2、3巡しているみたいな感じです（笑）。
テックリードの魅力は「技術的な意思決定が1年後に返ってくる」こと
三上：（コメントを見て）あ、そうですね。魅力の話（をしないといけない）ですもんね。テックリードの魅力は自分の技術的な意思決定が1年後に返ってくるというところです。どんな仕事をしているかというと、テックリードは会社の中でマネジメントをしないといけないことがいくつかあります。
CTOがやることはピープルマネジメントの評価の部分と、（その他に）テクノロジーについてのマネジメントも複雑に考えていかないといけないところも当然あります。事業がどんどん拡大していくと、人の採用が比率としてかなり大事になってきて、テクノロジーをマネジメントする時間が取れなくなってくる。なので、そういったところを専門に見ることのできる人が必要になってくるので、（そこを補うために）こういったテックリードというポジションがあるんですね。
三上氏がテックリードとして最近取り組んだこと
僕がこのポジションで最近やっているのは標準化です。初手に何をしたかというと、ライブラリのアップデートです。（弊社に）入った時はGo言語を使っていて、ORM（Object-Relational Mapping）のライブラリが3種類あったんですよ。「みんな好き勝手に作っていたのかな？」というものがあって、それをまず1つにまとめました。
ログのライブラリがたぶん（その時は）3種類ぐらいあって、みんながそれぞれ（ログを）覚えていたら学習コストが高いので、それを1つにしました。「似たようなことができるこれを使ってください」みたいな感じで1つ決めて、それをすべてのエンジニアが使えるようにリードしていく仕事でした。
あとは非機能要件にあたる部分ですね。機能要件の部分はプロダクトマネージャーが考えてくれて、エンジニアはその要求仕様書どおりに実装するんですが、非機能要件で言っているのは、例えばセキュリティの部分で。
特にtoB向けだったりするとISMSを取らなきゃいけなくて（取得のためのことは）CTOがやったりするんですが、僕は情報セキュリティ管理者でもあるし、経験があるのでやります。
あとはパフォーマンスチューニングですね。システム全体が不安定になるところがあるので、監視システムを導入したり、エラーログを全部見て統計を取って、それに対していつのタイミングでエラーを解決するのかという優先順位を（決めることを）品質基準に合わせてやっています。
エラーは小さいものからユーザー域のメチャクチャ大きいものまで幅広くあるんだけど、1つのことだけを考えてデータのアラートにすぐ反応していたらいつまでたっても時間が足りないので、その優先度がクリティカルなのか、ハイなのか、ノーマルなのか、ローなのかを見極めた上で、一次対応、二次対応をする。そういうところの仕組みを作っています。
そんなことをしているので、魅力は点ではなく、会社全体の組織の動きというか仕組みというか、そういった全体像が見ることができるところは魅力かなという感じ。
また、自分がやった修正が1年後に何の不具合も起きないとか、土日に叩き起こされ（ることが）ないとか。そういうことがない平和な状態、ある意味幸せな状態に（自分の力を使うことによって）なれるところが魅力的かなと思います。
加川：ありがとうございます。
（次回につづく）
