よりよい開発者体験のために何をしてきたか？
藤倉成太氏（以下、藤倉）：では、次の話題にいきたいなと思います。今回のカンファレンス全体を通じては、開発者体験、Developer eXperienceというのが1つのテーマになっています。そこで、特に創業期やスタートアップの頃の開発者体験はどんなものだったか、ご自身でどんなことを思いながらそこに対して手を打つ、もしくは打たないと決めていたのかについて、ちょっと聞いてみたいなと思います。
例えばソフトウェアの開発環境、CI/CDとかでもいいですし、開発ツールの話もあれば、学習支援などはわりとベストプラクティスが出揃っているので、「ディスプレイは大きいほうがいいよね」みたいな環境の話とか。
あとは会社のフェーズの中で「今はそれは入れるべきだ」とか「それはまだちょっと自分たちにはtoo muchかな」と考えながらやるのは1つあるなと思います。創業期の頃にどんなことを考えながら開発者体験を捉えていたか。なにかありますか？
小橋昭文氏（以下、小橋）：創業期……。
藤倉：ちょっとフワッとした質問をしちゃったので私から話をすると、エンジニアにとって働きやすいというか、良い環境を提供したいなと思ったんですよね。とはいえ、すべてにおいてお金がかかることはほぼ間違いない。なので、それが会社にどんな便益を与えるかをどう説明するか。どの切り口からストーリーにしていくかはわりと意識していたなと思っています。
例えば、採用をがんばっている関係で、どんどん人が入ってくる。もう毎月、毎週のように入ってくる。ボタン一発で開発環境を作れれば、プチプチとインストールするよりもその人たちが仕事を始めるまでのタイムラグは少ない。
コストのオーバーヘッドを小さくできるから、経営にとってこの投資は意味があるじゃんと説明をするほうが、その良さを取りやすかったりするんですよ。そういうストーリーをどう作るかというのがわりと、自分がコツをつかめるまではけっこうがんばってやっていたなという記憶があります。
ルールメイキングを考えていくことが、開発生産性にヒットする
横塚出氏（以下、横塚）：ぜんぜん忖度ではないのですが、藤倉さんの話の中でもあったいわゆるCI/CDとか、やらなきゃいけないことを淡々とやっていくという意味だと、ちょうどその時期にCTO協会からDXクライテリアみたいなのが出たので、このタイミングでやっていこうかと、エンジニアリングマネージャーと摺り合わせつつ徐々にやっていました。
ソフトウェアエンジニアは、アーキテクチャを考えてコードを書くというところに100パーセントの時間を使うべきだという前提は摺り合わせつつ、お客さまとセッションすることも大事だと思うのですが、その中でいかに時間を確保していくかというところは、会社のフェーズが上がっていくにつれて数字を取り始めました。「実は1日の半分しかコードを書いていなかった」みたいなところは、エンジニアリングマネージャーと「どうしたら良くなるかな？」と、定量的に測ったりしていました。
小橋：すごいですね。そういうことは何もしていなかったです。
（一同笑）
藤倉：何もしていない？ 例えば、CI/CDの環境も整備できていたほうがもちろんいいですけど、エンジニアの数が少なくて、みんながマニュアルでデプロイをできちゃう時は「その環境っているんだっけ？」とやはり思うわけですよね。
ただ人数が増えてくる中で特定の人しか手動でデプロイができないのは、やはり環境として厳しいし、他の人にそれを覚えてもらうかといったら事故にもつながるし。
それであれば環境を整備して、誰でもできるようにしたほうがスケールするんじゃないか？ みたいな。なので、最初はなくてもいいという判断を私はわりとしがちで、何をやらないというのも1つの判断ではあるとは思うんですよね。
今雄一氏（以下、今）：自分もそうでしたね。noteもリリース前まではHerokuで開発していたので、CI/CDはまったく考えていなかったんですけど。やはり開発者が増えると、開発の生産性にけっこうヒットするようになってきて、なんらかの秩序というかルールを敷かないと（開発者）体験が良くなくなる。みなさんは肌感でわかると思うんですが、そういうのがあるので、そこにどういうルールを敷くかにけっこうセンスが必要かなと思っています。
例えばこれはベタですが、「APIは全部OpenAPIで定義して、レビューを通して認識がブレないようにしよう。自動的にドキュメント生成をしよう」ということをやりました。けっこう最初は大変だったんですけど。あとは最近だと、モジュラモノリスという、モジュールごとにモノリスを分解していくということも企画してやっています。こういったルールメイキングを考えていくことが、開発生産性にヒットするのかなと。今はそういうフェーズかなと思っています。
ただ、開発者がこれから100人や200人に増えてきて組織が分かれますとか、たぶんもっとフェーズが上がっていくとまた別の課題が出てくるのかなとは思っています。
小橋：そうですね。最初は3人しかいなかったし、誰か1人しかできない業務がそもそもなかったというかたちでやっていたんですけど。まさに人が増えてきたり、本番運用が始まったり、運用が始まるまでは劣後してしまうというか。特に時間プレッシャーがあると、動くものができてからどうしても考えがちで、ここは私もすごく悩んだ。
もともとWeb界隈出身じゃなかったというのもあって、そもそも創業期によくわからないというのがあったんですよね。正しい意思決定ができないので、とりあえず探索しながら、みんなで学びながらやっていました。良くも悪くも、今になって後から是正しにいっているというか。統制というか標準化に向かって動いているところなので、まさに組織の規模が大きくなるとそこの標準化のインパクトが大きくなってくるな、というのは自分も感じているところですね。
間違いのない確かな情報だけで意思決定をすることはあり得ない
藤倉：エンジニアに限らず、学び続けることって我々プロフェッショナルにはやはり必要じゃないですか。会社から多少なりとも経済的なものだったり支援だったりができたほうがいいんだろうなと思うんですけど、先ほど私が言った説明の仕方・切り取り方では、なかなか正当化させるのが難しいなと思っています。もちろんみんなが成長してくれて、知識を豊富にしてくれればその分開発が良いものになったり、巡り巡って絶対良いことになるのは間違いないんですが、なかなか証明しにくい種類だなと思っているので、そこは私はもう「採用競争力です」と言うみたいな。
（一同笑）
藤倉：伝家の宝刀ですよね。とりあえず「採用競争力がないとエンジニアが採れないので」と言うと、とりあえずなんでもOKしてもらえるみたいな。
（一同笑）
今：間違っていないですけどね。
小橋：間違ってはいない。
藤倉：正当化するというか、理由をしっかりと付けて意味のあるものに肉付けしていくかで悩むことはけっこう多いですよね。
小橋：そうですよね。
横塚：やはりカルチャーが大事ですよね。CTOはそこをしっかり合理的に説明する責任が一定ありつつも、最後の説明しきるというところだと、どうしても難しいところはやはりあると思っています。やはりカルチャーとして最初からそういうものに投資していくんだよみたいなものは、もしかしたら僕自身振り返ってみても創業の初期からもっともっと根付かせていくべきだったかな、というところがありますね。
小橋：そうですね。不完全な情報がある中で最後は意思決定するのが経営だと思うので、データドリブンと言いながらも、データが3割ぐらいしかないみたいな（笑）。最後は「エイ、ヤー！」で決める責任を持っているので、権限も持っているべきだというところ。採用のブランディングみたいなところは、我々はこうありたいという自我を出すべきところだとは思いますね。出し過ぎると怒られるかもしれないですけど。
（一同笑）
藤倉：小橋さんが最初のほうにおっしゃっていた、仮説とか、なりたい姿とか、理想とかを持って、こういう世界に近づけるんじゃないかと思ってやって、結果そうならなかったら「間違っていました。すみません」と言って勇気を持って引っ込めたり、自己を否定する。
それでまたさらに先に進むとか、そういうのは確かにありますね。間違いのない確かな情報だけで意思決定をするなんてことは、まずあり得ないですよね。それはたぶん意思決定とは呼ばないんだと思っていて、確かに難しいところですね。他に開発者体験みたいなところで、なにかありますか？
横塚：私の会社事ではあるんですけど、保険領域でビジネスをやっている身として、例えばエンジニアに特化した人生のリスクに対する保険を共済みたいなかたちで提供をしてエンジニアがより働きやすくできないかなと考えています。
今：目や腰をかなり悪くしますもんね。
小橋：そうですね。
藤倉：そうですね。
小橋：いい姿勢にしましょう（笑）。
（一同笑）
藤倉：確かに保険業界ならではの開発者体験ですね。
横塚：CTO協会さんに協力していただければありがたいです。
藤倉：それは非常におもしろい取り組みだと本当に思います。業界全体でしっかりやっていかなきゃいけないことなんじゃないかなと思いますね。
全体最適のためには「全部自分でやろう」と思わないほうがいい
藤倉：ということで、このパネルディスカッションも残り数分になってしまったので、みなさまから一言ずついただいてこのセッションを閉めていこうかなと思います。今さんからお願いできますか？
今：創業期CTOは個人的にはすごくおすすめですが、基本的に全部自分でやろうと思わないほうがいいとは思っています。自分はテックが強いのか、組織運営が強いのか、プロダクトが強いのか。絶対に得意不得意あると思うので、2人目、3人目のトイメン（対面）となるマネージャー、経営メンバーのあてを考えて、2、3年後に委譲することを常に考えながらお仕事することをすごく勧めたいと思います。
これは自分が苦しんできたからというのもあるんですが、絶対にそっちのほうが全体最適になると思うので、チームでプロダクトなりスタートアップを作っていくことをすごくおすすめしたいと思います。
藤倉：ありがとうございます。
自分の強み・弱みと見つめ合っていくのが仕事
藤倉：横塚さんはいかがですか。
横塚：僕も1エンジニアメンバーとして開発していた時に、やはりCTOという肩書きに漠然とした憧れがありました。実際になってみると、まさに今日のテーマですが、CTOの役割は？ とか、CTOとは何なのか？ みたいなところでやはり深く悩む時期もありました。
その中で、CTOの先輩方にいろいろ話を聞いてもらう中で、今さんがおっしゃるように、自分の強みとしてどこを伸ばして、弱い部分をどういうかたちで埋めていくのか。それと見つめ合っていくのが仕事かなと思っています。なので、なにか僕の経験の面で貢献できるところがあれば創業期のCTOの方に還元したいし、まだ僕もここから精進していきたいなと思っています。
創業期はなんでもやる覚悟を持ってコミットしていくことがすごく重要
藤倉：小橋さん、お願いします。
小橋：会社を成功させていく、事業を成功させていくという中で創業期を振り返ってみると、自分と同じ類の人じゃなくて違うスキルがある方がいることによって、本当に助けられた場面は多いなと今になって思っています。
それは経営という観点もそうだし、技術という観点も含めてですね。なので、最初はそういう仲間を揃えてカバレッジを広げていくというところはすごく大切だったなと振り返ってみて感じました。
究極的に、特に創業期はなんでもやる覚悟を持って、やはりその会社を作りたい、世界を作っていくということにコミットしていくことがすごく重要だったなと思いました。
なので、これから創業される方々はぜひ応援したいなと思っています。本日はありがとうございます。
藤倉：ありがとうございました。スタートアップのCTOの役割ということで、このセッションを終了したいと思います。みなさん、ありがとうございました。
一同：ありがとうございました。
