スタートアップにおける「CTO」の役割は各社それぞれだ。経営や組織づくりに長けた人もいれば、「天才エンジニア」として技術的に大きな貢献をする人もいる。

とはいえ、スピーディな成長を求められるスタートアップにおいて、その存在が非常に重要であることは言うまでもない。

「ノンデスクワーカーの才能を解き放つ」というミッションのもと、「現場から紙をなくす」現場DXプラットフォーム「カミナシ」を展開する株式会社カミナシ。

2016年に創業し、2020年に現在のプロダクトをローンチ後、その翌年にはシリーズAで総額約11億円の資金調達を実施するなど、順調に成長を続けてきた同社。しかし一方で、組織の技術的トップであるCTOは、創業以来ずっと不在だったのだという。

CEOの諸岡 裕人さんは「CxOは僕の代わりに社長ができる人、という考えがあり、CTOに関しては探し続けているうちに5年が経っていた」と話す。しかしその弊害として、不具合対応がうまく回らなかったり、技術的負債が蓄積したりといった「成長痛」を感じるシーンも増えていったそうだ。

2021年6月に入社したエンジニアリングマネージャーの宮本 大嗣さんを中心に、なんとか開発組織を立て直したものの、中長期を見据えた開発には取り組む余裕のない状態が続いていたという。

そんな中、2022年4月に入社し、2022年7月1日に同社のCTOに就任したのが原 トリ（通称：トリ）さんだ。トリさんの入社により、スタートアップに求められる「短距離走とマラソン」のうち、「マラソン」ができる組織がCTOを中心に構築されつつある。

今回は、「事業計画をリスペクトして動ける強いエンジニアリング組織を作っていくこと」がCTOの役割だと話すトリさんと、諸岡さん、宮本さんの3名に、カミナシのエンジニア組織が向き合ってきた・今向き合っている課題から、それをどう解決しようとしているかについて、詳しいお話を伺った。

組織が順調に成長し、権限移譲も進む中で念願のCTOが入社

諸岡　2016年12月にカミナシを創業し、現在は組織全体で60名弱の規模感になりました。皆さん優秀なので、さまざまなフロント業務も僕から順調に権限移譲…というかどんどん剥奪していただいています（笑）。

CEOとしては、採用や広報などに注力しつつ、直近はミッション・ビジョン・バリュー（MVV）のアップデートという大きなテーマがあったので、半年ほどはそれに最もリソースを割いて取り組んでいます。

宮本　私は2021年6月にエンジニアリングマネージャーとしてカミナシに入社し、開発周りの整備や、採用、技術的なPRなど、色々なことに取り組んできました。

入社の背景としては、もともと諸岡さんとは過去に接点があり、ご縁を感じていたんですね。加えてエンジニアとしても、お客様の現場に訪問して一次情報を得ながら、お客様のためになるものを開発したいと思っていました。

実は以前に在籍していた企業で、20年ほど現場のオペレーションが変わらず、紙ベースで非効率な状態にあった…という経験もしていて。そういった現状を変えることに、大きな意義を感じていました。

トリ　僕は2022年3月に前職のAmazon Web Service（AWS）を退社し、4月にCTO候補として入社しました。そして2022年7月1日付けで、CTOに就任しました。

入社の決め手はいくつかあるのですが、最終的には、諸岡・河内（COO）という二人の経営陣と一緒に働いたら楽しそうだなと（笑）。

そしてカミナシが解決しようとしている課題も、面白そうだったんです。ある意味、これまでソフトウェア業界が挑戦をためらっていた領域にチャレンジしているということが、すごく面白くて。

CTO候補としての入社でもあったので、経営とエンジニアリングをつなぐ動き方をするという役割にも、これまでにやったことがない面白さがありそうだなと。要はまとめると、全体的に面白そうだったということです（笑）。

▼左から諸岡さん、トリさん、宮本さん

諸岡　トリさんを口説くにあたっては、登壇されている過去のイベント動画などもしっかり見て、COOの河内と一緒にめちゃくちゃ作戦を立てました。

当時、カミナシの10年後についてSF小説を書く、という取り組みをしていたので、それを送って読んでもらったり。最初は全く転職の意向をお持ちではなかったので、まずは一旦話してみませんか？　というところからスタートしたんですよね。

創業から探し続けて5年、「CTOは自分の代わりに社長ができる人」

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

諸岡　カミナシはずっとCTO不在だったのですが、起業した時点からCTOは常に欲しかったんです。「いつになったらCTO入るんですか？」と聞かれ続けて、探し続けて約5年が経ったという。

実は創業して以来、「CTOになってほしい」と思った方が二人いたのですが、その一人には今、技術顧問をしてもらっています。そしてもう一人がトリさんです。5年間で二人にオファーを出して、一人決まったので、打率は高いですよね。5割打者です（笑）。

ここまでCTOがいなかった理由としては、自分の心の中に「CxOは僕の代わりに社長ができる人」という基準がずっとあったことです。とにかく技術に強い、すごいプロダクトを作れる、界隈で有名だ…といったことだけではなく、僕に何かあったときに明日から社長ができる人を見つけたいと思っていました。

となると、カルチャーフィットはもちろんですが、何よりも「人に何かを伝える力」を持っていることが大事だと考えていて。

これまでのカミナシは、基本的に僕と河内というビジネスサイドの人間がツートップで引っ張ってきました。そうすると、事業が伸びていけば、基本的には会社は順調だと思っちゃうんですよ。

ですが一方で、技術的には負債が溜まっていって、不具合が増えたり、新機能開発がままならなくなってきたり…といった成長痛を実感していたところもありました。CTOが不在だったことで、そこに対して技術的に未来を見通したアラートが出ることがなかったんですね。

ビジネスサイドって、基本的にブレーキがないじゃないですか。ですので、アクセルしかない車でずっとドライブしてきたような感覚で。今になって、その分の苦労をしている部分はありますね。

▼カミナシ社のオフィスの様子

「臭いものにはフタをするしかなかった」時期を経て今がある

宮本　トリさんが入社する前から、技術的な負債が溜まってきていることは認識していました。

ただ、自分が入社した1年前の当時は、カミナシをゼロから作った開発メンバーが全員新規プロダクト開発に移ってしまった時期で。

入社年次が新しい人が中心だったので、ドキュメント整備も不十分、それでいて自動テストも不足していたのでリリースする度に障害が起きて切り戻す、といった状況が頻発しており、 組織が通常のサービス開発自体もままならないくらいの状態になってしまっていたんですよね。

この状態で技術負債の解消に着手してしまうと、私目線では会社全体のバランスがおかしくなりそうな印象もありました。

ですので当時は、開発チームでうまく回っていない部分を立て直したり、QA体制を組成したり、不具合対応のために他部署との調整を行ったり…。また並行して、CTO候補の方をリストアップしたり、採用周り全般を見たり、と色々とやっていました。

諸岡　当時は大変な時期でしたので、宮本さんには本当に感謝しています。実はトリさんも、宮本さんがピックアップしてくださった方の一人ですね。

宮本　技術的負債に関しては、もっと早く手を打てることも多かったかもしれません。でも、当時はまず開発のリズムを取り戻すことにフォーカスする必要もあったので…私の方で臭いものにはフタをしまくっていたという（笑）。

とはいえ、組織の課題解決に取り組みつつも、一方ではこのフタをどこで開けようか、正直すごく迷っていました。

ただ、CTOを迎え入れるための種まきだけは、並行してやっていましたね。CTOの在り方は各社バラバラだと思うのですが、カミナシとしては実務者のトップではなく、経営者としてのトップであるCTOを採用しようという結論になったので、それを踏まえて準備してきました。

▼「経営者としてのCTO」に求めるものをまとめた資料

宮本　例えば、技術的負債への取り組みでいうと、Notionにプロダクトリスク管理シートを準備し、ビジネス側とプロダクト側で負債に伴うリスクについて管理・コミュニケーションが取れるようにしていきました。

※当時、宮本さんが取り組まれた各種の施策については、こちらのnoteもぜひご覧ください。

何か種をまいておけば、水やりから始められるかなと。なので、全般的に満遍なく、小さいながらも組織の改善をしていましたね。

そして、やっと開発もある程度うまく回り出したタイミングでトリさんが入ってきてくれて。技術組織のトップとして、うまくバトンタッチできたかなと思っています。トリさんの目線だとどうですかね？

トリ　そうですね。実際に5月下旬からは、12月末までに「中長期的な価値を犠牲にしなくとも、スプリントの6割を純粋な機能開発に充てられるチームになること」をゴールに、技術的な負債の返済をプロジェクト化して取り組み始め、その第1弾も非常に順調に完了しています。

ただ、これは正論ですが、技術的負債は、機能開発と並行して常に返し続けていかなきゃいけないものなんです。「負債を返済するぞ」とプロジェクト化してしまってる時点で、エンジニアリング組織としては完全に間違っていて。カミナシでは今回プロジェクト化してしまいましたが（笑）。

ただ、我々も含めてスタートアップは、正論だけでは会社としてのゴールを達成できないこともあり得ます。

難易度の高い課題を解くことで、社会的に大きなインパクトを生み出そうとしている。そのためには、まずビジネス上の実績を出して、大きなお金を調達して、それを使ってまた優秀な人を雇って…というサイクルを回さなければいけないことも事実です。

ですので、特にPMFするまでは、継続的に負債を返済するのは難しいことだっただろうと思います。

諸岡　僕から見ると、以前は宮本さんが最前線に立って、突貫でどうにかサービスを動かしてくれていた。そこにトリさんが入ってくれたことで、初めてプロジェクトとして技術負債の返済をやろうという話ができたんだと思っています。

トリ　目の前にいっぱい仕事があってそれに追われている状況だと、プロジェクト化しましょうと経営に上申すること自体が難しいですよね。宮本さんの立場だったら「そんな暇ねえよ！」みたいな（笑）。

宮本　まさにそうでしたね（笑）。

事業計画に基づいたエンジニアリングのためのカルチャーを作る

トリ　入社してすぐは、ふわーっと様子を見ていたといいますか、チームやシステムを観察するところから始めました。エンジニアリングと他のチームのSlack上でのやり取りなどは、状況を理解する上ではとても学びが多かったですね。

また、僕自身がAWSが得意、あるいは好きなこともあって、インフラまわりがどうなってるかはやはり気になりまして。そこで主にセキュリティまわりで即座に対応すべき事柄がいくつかあったので、入社当初は社内を観察しながらもその部分については手を動かして改善していきました。

次に、採用のプロセスに入るようにして、最初は選考というより候補者の方と仲良くなるみたいな（笑）。アトラクト的に、「カミナシのエンジニアリングを将来的にはこういうふうにしていきたいんだよね」といった話をしたり。

そこから採用にもっと深く入っていって、どういう人が今のカミナシには必要なのか、という観点からジョブディスクリプションを更新するようなタイミングで、徐々に経営側の仕事が増えていった感じです。

入社した当時に僕が感じていたことを改めて言語化するなら、「エンジニアリングだけ事業計画に基づいていないな」だと思います。

他の部門はみんな事業計画に基づいて、クォーター、半年、1年と動きをデザインしていたのですが、エンジニアリングはそうではなかった。他のチームから流れてくるタスクを捌くことで精いっぱいになっていたんですね。

エンジニアリング単体で、事業計画に基づいてできるプランニングは何かというと、例えば「年末までに契約者数がこれぐらいのサイズになる」という計画があるとしますよね。

その際に想定されるデータ量や、トラフィックのボリュームなどがその計画から逆算できるはずなので、それに基づいて、現状のシステムでそれが捌けるか勘案する…といったことです。事業計画に基づいた逆算と準備ですね。

そこで現在は、1〜3年ぐらいの視点で「今どこに着手すべきか、何をすべきか」という観点で、優先順位を考えながら採用を含めた組織のプランニングをしたり、技術的な検討をしたりという動き方をしています。

短期で成果が出ることは、組織にいる一人ひとりにやってもらったほうがその人の評価にもつながるので、自分はすぐには成果が出にくい中長期視点で組織とサービスをスケールさせるために必要なことを進めている形ですね。

直近では、短期的な視点でプライオリティが高い物事をこなしつつも、中長期視点での価値を犠牲にしない組織に生まれ変わっていくための足場作りを僕の方でいろいろと進めていますが、これを成功させることが今は何よりも重要だと考えています。

スタートアップは短距離走＋マラソン。後者を担うのがCTOの役割

トリ　ちなみに…これまで偉そうに色々とお話しましたけど、僕、CTOやったことないんで。未経験です（笑）。

一同 （笑）

トリ　まだ、思ったことを何となく言語にしてみている…というレベルなんですよ。偉そうにしゃべってるんで、そうは見えないとよく言ってもらえるのですが。

諸岡　でも僕たちからすると、未経験だろうが何だろうが関係ないと。荒野を歩いていたら、世界一高い宝石を発見した、みたいな気持ちなので。

トリさんはテック系の大きなカンファレンスに登壇して、ベストスピーカー賞を受賞するようなレベルなので、人に何かを伝える力はもうめっちゃ強い、間違いないんです。

トリ　ただ、スタートアップのCTOに求められることって何かというと…まだわからない部分も多いですね。

とはいえ、少しずつ解像度は高まってきていて。まず、先ほどもお話しした事業計画を実現可能にする動き方ができて、かつ、ビジネスをドライブし得る強いエンジニアリング組織を作っていくこと。これはカミナシのCTOとして、やらなければいけないことですね。

宮本　私、トリさんが入る前は色々なロールを持ちまくっていて、にっちもさっちもいかない状態でカレンダーも埋まりまくっていたので、トリさんに巻き取ってもらったことでラクになりましたよ。

今トリさんがおっしゃった、経営周りの話や、未来に向けた計画は、まさにやりたかったけれど自分だけではできなかったところで。それをトリさんに引き継げたので良かったです（笑）。

トリ　短距離走をしながらマラソンしなきゃいけない、というのがスタートアップだと思うのですが、少なくともそのマラソン部分を僕が担えるようになったということかなと思います。

諸岡　経営視点から見ても、今まで自分と河内が2人で話してたところに、トリさんが必ずいるようになったので、圧倒的に変わりました。ビジネスサイドの決定もそうですが、MVVのような組織づくり観点の話にも全部トリさんに入ってもらっているので、以前とは全然違いますね。

例えば我々のバリューの中に、高い目標を恐れずやっちゃおうぜ、ということを意味する「β版マインド」というものがあります。でもトリさんが入ってきて、いの一番に「β版マインドちょっとよくないですね」みたいな話があって。

「カミナシはβ版マインドを乱用しすぎるきらいがある」と言われて、なるほどなと。すでに利用しているお客さんがいるようなサービスだと、エンジニアリングが簡単に「やっちゃったけど戻そう」といった動きが取りにくいこともたくさんある。

リスクをちゃんと計算した上で挑むのは良いけれど、エンジニアリングの観点からこのバリューを正しく使うためにはこういう視点が必要です、といったアドバイスをもらいましたね。

トリ　経営チームのロングタームな意思決定に、技術の視点から情報や意見を持ち込むことは、スタートアップに限らず必要なことだと思っています。

…ただ、スタートアップって不確実性が高くて、「本当に私、大丈夫かしら」みたいな気持ちになって、夜な夜な枕を濡らしたりはしているんですけど。

一同 　（笑）

トリ　でも、そこで「β版マインド」が効いてくるんですね。最大限考えた上でチャレンジしてみる、リスクを見ながらチャレンジしてみる、ということは、速いスピードで進化をしていくためには大事だと僕自身も信じているので。

チームのメンバーにもとても素敵な人がいっぱいいるので、皆さんに支えてもらいながら頑張ろうと思っています。（了）