宮川元々、Cloudbaseはリファラルを中心にメンバーを採用していたので、代表の岩佐との繫がりがある同級生や仲の良い友人同士でスタートしたんです。始めからお互いを理解できているからこそ、スピーディに事業を進めていけると思っていました。

しかし、リファラル以外で入社するメンバーが増えてくると、今までは当たり前に共有できていると思っていた仕事の進め方や認識にズレが生じ始め、メンバー同士でコミュニケーションの齟齬が多発するようになってしまったんです。

本来であれば、もっと早い段階からこの課題に向き合うべきでしたが、マネジメント経験がほんの1年程度の私にはそれができていませんでした。

宮川その頃、プロダクトチーム（Cloudbaseにおける開発組織の呼称）内では、「一体、自分は誰に何を預けて、何を任されているのか」という点が曖昧になっていたんです。

そのため、「あの人はこれをしてくれたから、この人も同じことをしてくれるはず」といった勝手な期待を持ってしまい、実際の成果物との間にギャップが生まれることがしばしばありました。

さらに、その問題は経営のレイヤーにおいても起きていました。

経営側の意向がメンバーにうまく伝わっておらず、会社の目指すべき方向性とメンバーの認識にズレが生じ、組織として統制が図れない状態に陥ってしまったんです。

私たちはこの問題を急いで立て直すべく、一度全員で仕事の手を止め、これから組織としてどうあるべきかをディスカッションすることに決めました。結果、以降はプロダクトチーム内にEM（Engineering Manager）を1名置き、各自の期待役割を明確にした上で日々の業務に取り組んでもらうようにしました。（一人目のEMを担う成瀬氏がこの件を解説している記事はコチラ）

そこからですね。組織間で多発していたコミュニケーションのズレが徐々になくなっていったのは──。

大峠EMというと、例えばメルカリやタイミーのように、エンジニアが多数在籍する大規模な組織で採用しているポジションだと思われるかもしれません。

しかし、エンジニアの数が10名にも満たない私たちのような組織でも、コミュニケーションを調整するEMを配置することで事業の成果が向上するとわかったんです。これは私たちにとって大きな発見でした。

宮川結局、やらなければならないタスクが膨大にある中で、「誰かが対応してくれるだろう」と考えてしまうと、誰も手を付けられないんですね。これは当事者意識があるか、ないかという話ではなく、対処しきれないタスクの「量」の問題です。

そのため、タスクを整理して優先順位を決め、「ここはもうやらない」と判断する役割が必要になります。

本来、この役割をCTOが担うこともできますが、私自身、「歴戦のCTO」というキャリアパスを歩んできたわけではないので、「得意な人に役割を委ねる」と判断することも重要だと学びました。

岩井確かに、クラウドセキュリティに課題を抱えている大企業にとって、パブリッククラウド環境内のリスクを検出する『Cloudbase』は一定のニーズを得ています。しかし、プロダクトが完成しているかと言えば、断じてそんなことはありません。

『Cloudbase』はマルチクラウドに対応していますが、現時点ではAWSへの対応が比較的進んでいる一方で、AzureやGoogle Cloud、またはOracle Cloud Infrastructure（以下、OCI）などに関してはこれから対応を強化していく必要があるんです。

今後、パブリッククラウドの対応範囲を広げていくためには、「その数だけやるべきことが倍々に増えていく」と捉えていただければと思います。

大峠そうですね。加えると、複数クラウドに“領域"を広げるだけではなく、セキュリティの“種類"も増やしていく必要があります。現在、私たちのプロダクトはクラウドセキュリティの「設定ミス」という問題に対するソリューションに力を入れていますが、他にも「脆弱性」や「異常検知」などのセキュリティ対策も強化していく必要があります。

つまり、パブリッククラウド領域×セキュリティ領域をカバーしていこうとすると、二次元のマトリクス上にやらなければならないことが増えていくわけです。これらをカバーしていくとなると、とても今のプロダクトチームだけでは成し得ない。急ピッチで組織体制を整えていくことが急務となっています。

大峠例えば、既に世界では話題となり対処されている脆弱性に関する問題が、日本では未だに放置されているといった実態があります。

世界では最先端のテクノロジーに対して付随するセキュリティの課題にも敏感ですが、日本の現状としては、「最低限これはやらないと危険だよね」というリスクを検出して対処するといったレベルにとどまっているわけです。

なので、外資系企業が最新のコンピューターウイルスの検出に注力してプロダクトを磨き上げている一方で、私たちは日本企業の実態に合わせる必要があります。つまり、社内にセキュリティエンジニアがいなくても、自分たちでセキュリティ問題を改善していけるようなプロダクトづくりこそが日本企業には必要なんですね。

大峠実は、岩井は学生時代に競技プログラミングをしていた人間なんですよ。

競技プログラミングというのは、課題に対していかに効率的で速い回答を出すプログラムを書けるかに挑戦し、スコアで競うというものです。そんな中でも、一般の高校生だと太刀打ちできないようなレベルになっている情報オリンピックに出ていましたよね。これまでに出した過去一番の記録は何でしたっけ？

岩井アジア太平洋情報オリンピックで銀賞を受賞したことですね。他にも日本の情報オリンピックで2回ほど銀賞を受賞しています。

これは数学オリンピックのプログラミング版のようなものをイメージしていただければと思います。愚直にやると一生かかっても計算が終わらないような問題に対し、一瞬で計算するアルゴリズムを考えるという競技ですね。

大峠すごいですよね。例えば、Googleに行くようなエンジニアは競技プログラミングで上位の成績を収める程の技術力が必要だとも言われています。私も情報オリンピックに出場して予選敗退しているので、まさかその後に一緒に働けるとは夢にも思いませんでした（笑）。

宮川大峠のように、エンジニアのバックグラウンドがありながらプロダクトマネジメントができる人材って、スタートアップの中では稀有な存在ではないでしょうか。

『Cloudbase』はSaaS型のプロダクトであり、さらにエンタープライズ向けに特化したサービスのため、技術的に難しいポイントが多いんです。そこに対し、彼はエンジニアの知見も持っているからこそ、プロダクト側との連携を適切に取りながら推進できているのだと思います。

岩井まさにですね。エンジニアからの視点でいうと、大峠は自分でコードを書いてきた経験があるので、プロダクトの話をするときも技術ベースで会話ができる。プロダクト側が開発側に無茶ぶりしてきて、よくある「技術的に大変でしょ、これ…」という事態になることはないので、安心して任せられます。

余談ですが、大峠は議論の際はすごくロジカルに話すんですが、普段はたまに抜けているところがあって。競合のサービス名や外資の社名で、大体1個ぐらいスペルを間違えているんですよね。しかも読み方も自己流で、何回言っても直らない（笑）。そうしたお茶目なところが、社内でも愛される存在かなと思いますね。

宮川実はCloudbaseに入社する1年前から岩佐の事業を手伝っていたんです。Cloudbaseは現在のプロダクトに辿りつくまでに6回ピボットがあり、そのうち5個目、6個目のプロダクトは主に私がベースをつくりました。

その後、岩佐から現在の『Cloudbase』の構想を聞いたときに、「今までの2つよりも圧倒的に優れている、これならいけるぞ」と確信し、前職を辞めて一緒に事業を始めたんです。

最初はエンジニアとしてひたすらコードを書いてましたが、徐々にメンバーが増えていくにつれて、開発リーダーから、開発組織全体を見る立場になり、現在はCTOとして全体を統括しています。当然、すべてを一人で担える範囲ではないので、大峠や岩井と一緒に進めていますね。

大峠迷いはなかったですね。もちろん、転職前に別の企業も検討したんですが、私は「ここの会社で得られる知識が将来どれくらい役立つだろうか」という視点で考えてCloudbaseを選びました。

まず、エンジニアリングにとってクラウドは欠かせないものであり、CloudbaseならAWS、Azure、Google Cloud、OCIといった複数のクラウド技術を深く学ぶことができます。

大峠そして、私たちはこれら全てのパブリッククラウドに対してスキャンを実施しているため、セキュリティ知識も同時に習得できる。今後、どのようなキャリアパスを歩むにしても強力なスキルセットになると感じました。

働きながら自身の資産として技術を身につけられる環境に「お得だな」と（笑）。もちろん、簡単に身につくものではないからこそ、やりがいもあるのですが。二人はどうですか？

宮川そう、まさにエンジニアにとってクラウド技術やセキュリティ知識の習得は、アスリートが体幹を鍛えるようなもの。ここでの経験は必ず今後のキャリアの基盤になると感じています。

また、エンジニアキャリアに生きる点は他にもあります。エンジニアって、将来的にプロダクトにおいて企画段階から関わりたいと考えるケースも多いと思うんです。そういった時にも、パブリッククラウドのようにエンジニアと親和性が高い領域であればより主体的に関わりやすく、PMやPdMにも染み出していきやすいですよね。

すでにお客様にSaaSを提供しているチーム（アプリケーションチーム）では、エンジニアが「どんな機能をつくるのか、どんな課題を解決したいのか？」という部分からオーナーシップを持って取り組んでいます。実装はあくまで手段に過ぎず、「お客様に価値を提供したい」という想いを持ったエンジニアにとってはハマる環境だと思います。

また、技術営業として商談に同席しているエンジニアも多く、キャリアの幅を広げながら、多くのチャレンジができるのもCloudbaseの魅力です。

岩井私は今、社内の開発者たちの生産性を向上させるための仕組みづくりに取り組んでいます。チームが拡大するにつれて、どうやって生産性を維持し、どのように目線を合わせて開発を進めていくか、そこに深い関心を持っているんです。

私はもともとエンジニアとして活動してきたため、どうしてもエンジニアリングの側面ばかりに意識が向いていました。しかし、事業、プロダクトの成長のために適切な組織の拡大を行うには、技術だけではなく、チームや組織の観点も持ちながら考えていかなければ駄目なんだと気づくことができた。

前職と比べて視座が上がり、見える範囲が一気に広がったという感覚で、これはCloudbaseに入ったからこそ得られた成長ですね。

岩井おっしゃる通り、スタートアップはユーザー数が増えない限り、扱えるデータ量も制限されるため、エンジニアの中には「技術力を試す機会が少ない」などの理由でスタートアップを敬遠されることもあるかと思います。

しかし、そういう意味ではCloudbaseのプロダクトは一味違います。私たちが向き合う顧客は日本を代表する大企業ばかりですので、クラウドの利用規模が大きく、膨大なデータを扱えるんです。

また、多くのスタートアップでは事業のスピードを優先し、セキュリティやパフォーマンスへの取り組みが後回しにされがちです。ところが、Cloudbaseはクラウドセキュリティを事業ドメインとするため、同じスタートアップでも事業の立ち上げ段階からパフォーマンスの問題やスケーラビリティの課題にも直面しながら、セキュリティの最前線で開発を進めています。

このように、スタートアップでありながらエンジニアとして存分に力を発揮できる“全部盛り"の経験がここでは得られる。なので、Cloudbaseはエンジニアが市場価値を大きく高めることができる環境だと私は思っています。

岩井まず、開発者の視点からお答えすると、お客様に対し、最速で最大の価値を届けることがエンジニアとしてのミッションになります。

その上で、もしお客様がセキュリティがネックとなり社内のクラウドを活用できず、結果として開発やイノベーションのスピードが遅れてしまうのならば、その状況を何としても解決したい。それがモチベーションになっています。

セキュリティと聞くと「守り」に思われがちですが、私たちはセキュリティでシステムやネットワークをがちがちに強化することだけが目的ではありません。その強固な土台があることで、より多くのチャレンジを後押しすることこそが真の狙いです。日本企業が世界に向けて良いプロダクトを送り出すことに大きなやりがいを感じています。

宮川岩井が言ってくれた通りで、私たちが達成したいミッションは、「日本企業が世界を変える時代をつくる。」です。

宮川現在、多くの日本企業ではセキュリティがボトルネックであると認識しており、その課題を解消することでイノベーションが加速できると考えています。

実際『Cloudbase』を利用している企業様からは、プロダクト開発からリリースまでのサイクルが最大で3.5ヵ月も短縮できたというお声を頂いております。これってとんでもなく大きな価値を生み出せていると思うんです。

宮川開発の遅延がくり返されることは、1年やそれ以上の大幅な遅れにつながる可能性があります。例えば、ChatGPTを振り返るだけでも、1年前はまだまだこれからというフェーズであり、2年前には世の中に公開すらされていませんでした。

世の中の変化は非常に速く、日本企業がイノベーションを追い求めるためには、いかに開発のスピードを上げるかが極めて重要です。

今後、より多くの企業が私たちのプロダクトを導入することで開発スピードを上げることができれば、日本企業が世界を変える大きな一歩になると信じています。

大峠「国外」「海外」において、私たちと同様のプロダクト自体はあります。しかし、それらの競合他社は主にプロフェッショナルなITエンジニアが活用するサービスを提供している一方で、私たちはそうではない方々、上記に該当しない方々でも使えるプロダクトになっています。そこが大きな差別化ポイントですね。

岩井あとは技術力でしょうか。自分たちで言うのも恐縮ですが、Cloudbaseは「技術力で勝負できる」ところが強みです。

先ほどもお話した通り、複数クラウド×多様な機能で、品質を維持しつつ開発スピードを上げていくことは、エンジニアリング組織にとって大きなチャレンジであり、難しい部分でもあります。他の企業が後から参入してきたとしても、私たちのスピードと品質には追いつけないと思います。

宮川まず前提として、私たちは「Unlock」と「With」という2つのバリューを大切にしています。

これは自らオーナーシップを持ち、積極的に活動の幅を広げていこうとする姿勢にも通じています。まだ誰も手を付けていない浮いたボール（=課題）を見つけた時、「やります」と進んで取りにいく人が多く、そうしたアクションを全社的に推奨しているんです。

宮川例えば、Cloudbaseのエンジニアは開発依頼があったものだけをつくるのではなく、一般的な企業であればPMが担当する領域にまで、積極的に染み出していくことができます。

事実、お客様にSaaSを提供しているチーム（アプリケーションチーム）では、エンジニアが「どんな機能をつくるのか、どんな課題を解決したいのか？」という部分からオーナーシップを持って取り組んでいます。実装はあくまで手段に過ぎません。何より「お客様に価値を提供したい」という想いを持ったエンジニアにとってはハマる環境だと思います。

先ほどもお伝えしたように、私はCTOとして立派な経歴を持っているわけではありません。なので、ぜひ自らプロダクトづくりや組織づくりをリードしていける方に参画いただき、一緒に事業を拡大していけたらと願っています。

もちろん、今いるメンバーにもたくさん協力をお願いしており、大きな裁量を持ってチャレンジしてもらっています。ぜひ、こうした機会をポジティブに捉えて挑戦してもらえたらと思います。

大峠そうですね。もちろんPMだけでなく、PdMにも染み出していきたいといったプロダクト志向が強いエンジニアの方にもおすすめです。

『Cloudbase』はエンジニアにとって親和性の高いプロダクトですので、キャッチアップコストやユーザーインタビューの観点でみてもチャレンジしやすいと思いますね。

宮川課題が多い状況でもわくわくできる方、勝ち馬に乗るのではなく、自ら勝ち馬をつくり出していくぞ、という意気込みのある方と共に仕事を進めていきたいです。

組織が拡大している今、Cloudbaseには足りないピースが数多く存在しています。具体的に言えば、今後2年ほどでプロダクトチームを30〜40人規模へと成長させていきたいと考えています。

今のプロダクトチームはまだまだ少数精鋭であり、かつシリーズAという今の急成長フェーズも相まって、メンバーの数よりもチャレンジの数が圧倒的に多い状況です。その過程で多くの失敗と成功体験を積むことができる、希少な環境が揃っています。

組織をつくるということは本当に難しいと感じていて、前職時代に感じていた「自分ならこうするのに」という想いをいざ形にしようとすると、何から手をつけていいのかわからない。なので、事業や組織の状況をみながらトライ&エラーを繰り返していくのみなんだなと思っています。

こうした機会に立ち会えるのは、長いキャリアの中でも限られた回数しかありません。ぜひ、こうした取り組みに興味がある人はこのチャンスに挑戦してほしいと思います。

そして、Cloudbaseで成長したメンバーが、仮にいつか卒業する際は、次の企業でCTOや組織を引っ張っていくリーダーになっていてほしい。いわば、“Cloudbaseマフィア”のような存在を目指しています。

大峠二次元、三次元、四次元…解くべき課題は無限に広がっています。この無限に広がる伸びしろに挑戦していける仲間を求めています。

これからのCloudbaseは、プロダクトを通じてより大きなインパクトを生み出すべく、強固な開発組織の構築に挑戦していきます。例えるなら、スイミーのように個々の魚たちの結束によって一つの巨大な魚（集合体）となり、全員で同じ方向に力強く進んでいくような、そんな開発組織をイメージしています。

個のプレイヤーとして見れば、我々も一定の価値を生み出せる開発スキルは備えていると自負していますが、それを組織として再現性高く打ち出していけるかというと、大きな挑戦となります。

こうした組織としての挑戦こそが我々の目下の課題であり、新しく入ってくる仲間にも力を貸して欲しいと願っているポイントです。

岩井これまでリファラル採用で入社するメンバーが多く、特にエンジニアは26、27歳の若手メンバーがほとんどであったため、正直入りにくい雰囲気があったかもしれません。しかし、組織の拡大において「同質化」は課題と捉えているので、今では経験豊富なシニアメンバーの採用も進み、組織としての多様性が広がってきています。

また、私たちは技術力には自信あるとはいえ、品質を維持しながら開発スピードを上げていくという課題は依然として存在しています。

特に今後、プロダクト側からのニーズが増えるにつれて、どのように並列して開発を進め、開発スピードを維持できるかが焦点になってくる。まだ解決できていない難しい課題がたくさんありますが、諦めずに常に考え続け、チャレンジ精神を持ったメンバーと共に働ければと思っています。