クックパッドで技術部長を務めたのち、複数の企業で技術顧問やCTO/VPoEに就任。2022年にCTOとして入社した小川さんに、これまでの経歴や作りたい未来を伺いました。

大学院卒業後、最初に就職したのは大阪のWEB制作会社でした。当時はいわゆるWeb1.0の時代。それに関する開発を何でもしました。言語はPerlやPHP、Adobe Flashなど。社内向けのWebシステムの開発も担当していました。社長は大学の同級生で、初めての社員が僕。なし崩し的に僕がどんどんマネジメント業務を担うようになりました。

今でこそCTOですが、当時は体を動かして物を作るのがすごく好きで、新しい技術習得や調べるのも大好きで、もっと技術に触れていたいという思いが膨らんでいきました。GREEやDeNA、サイバーエージェントが盛り上がっていた頃で、東京に出たいという思いが膨らみ、東京の会社への転職を決意しました。

2社目の会社は、Ruby on Railsを使ったWebサービスのサービス開発とインフラ設計のようなものを網羅的に開発していました。インフラの構造やサービス設計にも積極的に意見を出していくうちに周囲からアイディアや考えを求められるようになり、やがてマネジメントレイヤーを期待されはじめました。当時の僕はマネジメントをしたいわけではなかったので、その会社も離れようと考えました。

クックパッドに誘われたのはちょうどその時。個人的に所属していたRubyのコミュニティで、声をかけられました。いろいろ悩んだのですが、当時Rubyを使っている大きなサービスは食べログとクックパッドぐらいで、Rubyを使って手を動かす仕事がしたくて入社を決めました。

技術者たちの組織をより強く、働く環境をもっと良くしたい

クックパッドに入社してからは、サービス開発やデータ分析のための開発をメインに取り組んでいました。やがて、プレミアム会員に関する事業部のまとめ役を担うようになった頃、社内ではエンジニア採用に課題が浮かび上がってきました。同時に、ちらほらと不満が聞こえだすように。みんなが楽しいと思える会社の実現はなかなか難しいものの、会社全体として取り組む必要があると考え始めました。

部長に現状の問題を起案したところ、採用を含めた会社全体のエンジニアに対する課題に取り組む業務を担うようになり、人事の兼務や技術部長への就任など、多くの役職を兼任することになりました。マネジメントにどっぷり浸かっていた期間は1年半ほど。コードを書くのはプライベート、趣味としての時間でしか取れませんでしたが、全然苦ではありませんでした。むしろ、開発組織を強化し、これから道を切り開いていくエンジニアたちのキャリア支援に面白みを感じたことを覚えています。3つもの部門を兼務したのは、多忙でしたが良い経験です。

今思うと、避けていたにも関わらずこのタイミングでマネジメントに取り組んだのは、自分自身の変化によるものが大きいです。

自分を変えたのは、同僚のおかげと言えるかもしれません。お互いに技術のスキルを認めあえる、好きだと思えるような専門領域に特化したエンジニアたちに、もっといい環境を整えたい、組織を強固なものにしたいという強い思いが膨らみ、自分は縁の下の力持ちとして取り組んでいくのも悪くないと感じたのです。

Webはまだまだ若い業界です。特に、僕がクックパッドにいたときはエンジニアの方のロールモデルがない時代、技術職の地位も今に比べると重要視されていなかった時代でした。そこでエンジニアの領域から一歩踏み込んで経営の基盤や組織開発に携わることで、これから来る人たちの上に何かを切り開く思いが強かったように思います。

採用もまた例外ではありません。エンジニアの採用にはやっぱりエンジニアが関わる方が良い。面接や面談も重要ですし、リファラルが自然発生するような状態を目指すことが重要です。多くのエンジニアはリファラルで入社しています。実際、クックパッドのエンジニアの入社経路もリファラルの比率が高めでした。

クックパッドを退社してからは業務委託で開発をしたり、技術顧問をしたり。技術だけではなく人事や役員と組織開発や採用について相談されるケースも多かったですね。ただ、組織に所属していない限りはあくまでもアドバイザー。自分が手を出すことは難しく、もどかしい思いもありました。

それならちゃんとCTOや技術責任者としてどこかの会社に入って、組織も採用もプロダクトも網羅的に携わりたいという気持ちが芽生え、タレンティオやロコガイドでCTOやVPoEを務めたのち、i-plugとご縁がありました。

もっと気軽に転職できる未来をつくる

i-plugへの入社を決めたのは、キャリア全般を扱う事業領域と自分の興味関心の親和性が高かったためです。

数年前から難しいと言われているエンジニア採用を例に挙げます。エンジニアの数が不足していることに起因する問題ですが、「ではエンジニアを増やしましょう」と簡単に増やせるものではありません。ただ、エンジニア適性のある人たちが違う仕事をしているケースが世の中にはたくさんありそうだと感じています。　

実際、20代半ばからプログラミングを始め、CTOになれるくらい優秀になった人もいます。大学で情報工学に行ってなければ駄目、子どもの頃からPCに触れていなきゃ駄目、という世界ではない。頭が良いとか悪いとか、そういう話でもありません。適性が大事かなと考えています。

キャリア領域はもっと関心が増えていいと考えています。キャリアにまつわる様々な課題を解決しないと、日本はおそらくダメになってしまう。今の日本では、入社半年で退職する新卒も珍しくなく、また、中途市場でも転職したくても出来ない人がいます。

もっとみんなが楽しく仕事をもっと楽しめるように、気軽に転職できたり、職種を変えてもなんとかなる仕組みを作れないかと考えています。現時点で未経験だとしても、経験すれば面白いと思える仕事はあるはずなので、個々の適性や志向性に合わせて、キャリア選択の可能性を示せる仕組みを作れたら面白いんじゃないかなと思います。

だから僕は、そういう未来を作る仕組みを技術で実現させたい。大変だと思うんですけど、その未来ができたら働くことに対しての負のイメージが少し払拭されるかもしれない。もしくは、働くのは楽しくてもいい。ただ、給与が待遇がいいとか。何かしら「働き続けられる」仕組みが作れたらと思います。

良いプロダクトなら売上も上がる。売れないなら、良い価値提供ができていない

僕が一番大切にしているのはプロダクトです。技術も当然大事ですが、プロダクトとして人々に何を提供するのか。何のために何を提供するかが肝であり、明確にすべきポイントだと考えています。

次に大切なのは、売上です。技術職や研究職の方で積極的に売上を口にする人は多くありませんが、私は重視しています。良いものを作れば、お金を払ってもらえるはず。逆に言うと、お金を払ってもらえないものは良い物といえないわけです。ですから、プロダクトを大切にしつつ、お金を払ってもらえるほど価値を提供できているかという点を重視しています。プロダクトの良さを測るために、売上は良い指標だと考えています。

続いて、技術とエンジニアたちが大切です。彼らが楽しみながら働ける環境づくりを重視したいと考えています。技術における言語の選定や投資対象も大事ですが、開発部門のみならず会社全体の風土や雰囲気、MVVなどを含めた組織開発が求められ、文化を醸成させることが大切かなと考えています。

文化の醸成は一筋縄ではいきません。リーダーが文化を体現しないと根付かないため、自らの行動としてどうあるべきかは常に意識をしていきます。加えて、対話も重視します。チャットで済ませたがるエンジニアも多いものの、その人らしさが伝わるのは、対面で会った時に感じる「非言語コミュニケーション」による醸成も多いものです。

体現とコミュニケーション。文化を作るまではいかずとも、根底にある人の大事な考え方の認識が揃い、楽しもうという気持ちが生まれるよう取り組んでいきたいです。

そういう文化ができあがると、もっと開発組織は良くなると信じています。例えば、エンジニア側から自発的に改善案が生まれたり、売上を高めるための戦略を考え出す。そこからスピードを持って開発ができる組織を目指したいと考えています。