相談して言われた「じゃあCTOでよくない？」　松下雅和氏がカオナビでCTOに就任するまで

松下氏の自己紹介と「カオナビ」の紹介

松下雅和氏：「働きやすく、成長し続けられるエンジニア組織を目指して」という内容で、株式会社カオナビのCTO松下が発表します。

まず簡単に自己紹介をします。（スライドを示して）好きな技術や趣味はこんなところです。私はSIerを2社経由して、3社目で株式会社サイバーエージェントにエンジニアとして入社しています。サイバーエージェントでは、ゲームやコミュニティサービスを経験しました。

当時一緒に働いていた後輩が起業したのが、4社目の株式会社トランスリミットです。トランスリミットでは、海外向けのゲームアプリを開発しており、私は途中からジョインして、CTOという立ち位置で動いていました。その後、縁があって2020年2月に株式会社カオナビに入社し、現在CTOとして活躍しています。

ここで簡単に「カオナビ」の紹介をさせてください。カオナビは、社名と同じ「カオナビ」という（名前の）タレントマネジメントシステムを提供しています。

「カオナビ」は、 社員の個性・才能を発掘し、戦略人事を加速させるタレントマネジメントシステムです。人材データの情報を入力してもらうことで、人材情報の一元化や見える化、人事業務の効率化、人材配置・要員シミュレーションなど、人事や経営層のふだんの業務の課題になるようなことを解決できる、さまざまな機能を提供しています。

タレントマネジメントシステムとしては業界ナンバーワンで、利用企業数も2,500社を超えていて、シェアもナンバーワン（2022年3月末時点※ ）です。

※出典　ITR「ITR Market View︓⼈事管理市場2022」⼈材管理市場：ベンダー別 売上⾦額シェア（2015〜2021年度予測）

カオナビの歴史

（スライドを示して）本日のテーマはこちらです。まずは簡単にカオナビの歴史をお伝えします。「カオナビ」のサービスは2012年に事業が始まり、2019年に東証マザーズに上場しています。

歴史上をざっくり分けると、黎明期とサービスリプレースした後、そして急速に組織化・拡大していった3つの時期になると思います。

最初の黎明期では（サービスを）オンプレ型で提供していて、お客さまの会社に行って実際に「カオナビ」iをインストールするような導入方法を採っていたそうです。当時はSESが中心の開発で、社員はほとんどいませんでした。

そこからサービスをリプレースして、SaaSとして提供するようになりました。この頃からだんだん社員のエンジニアが増えてきましたが、当時は職能別の組織体制でした。2019年からエンジニアがどんどん増えてチーム開発が進んでいき、その後は一気にエンジニアの人数が増えたという状況でした。

私がカオナビに入社したのが2020年2月で、同年9月にCTOに就任しています。本日は、私が入社してからCTOに就任して今に至るまでの流れをお話ししようと思っています。

アジェンダとしては、まず2020年2月から8月まで、1人のエンジニアとして動いていたこと。その後CTOとして、また組織全体の取り組みとして、2020年9月から何をやってきたのか。その後、CTO室を立ち上げているので、そちらの内容にも触れて、最後にまとめます。

松下氏入社当時のカオナビの状況

まずは「エンジニアとしての取り組み」です。入社当時のカオナビを振り返ってみると、バリューとして、仮説思考、仕組み化、シンプルという3つを掲げていました。エンジニアなら当たり前の内容という気もしますが、これらに全社的に取り組んでいるのもカオナビの特徴だと思います。ビジネスサイドや営業、バックオフィスも、当たり前に仕組み化に取り組んでいます。それを意識している会社はなかなかないと思っています。

働く環境は原則出社勤務で、リモートはまったくやっていませんでした。「ぎゅっと働いて、ぱっと帰る。」という行動指針を掲げていて、いかに時間を使わずに効率よく成果を出すかを強く求められる働き方です。実際に残業時間もほとんどなく、±20時間のフレックスになっています。

残業してもかまいませんが、しっかり生産性高く働けていればマイナスでもかまわないという会社です。短い時間で成果を求められるように、自由がある分、逆に責任もある、責任も求められるような環境だと思います。

私が入社したタイミングからは、新型コロナウイルスの感染対策としてコアタイムが10時から11時に変わったり、在宅勤務が次第に推奨されて、出社禁止にまでなりました。実際、私は最初の1ヵ月くらいしか出社していなくて、今もほとんどリモートで働いています。

当時はスイッチワークという制度も導入されて、例えば子どもの送り迎えなど、自宅で自由に休憩を挟んでかまわない制度も生まれました。リモートをまったくやってない会社にしては、すごいスピード感だったのではないかと思います。

エンジニア文化としては、ボトムアップや変化を歓迎するような傾向があります。もともとjQueryやJavaScriptで作られていたものが、最近はReactやTypeScriptへの置き換えが始まっています。Goの採用が進んでいるシステムがあったり、スクラムの導入にもいち早く取り組んでいたり、2019年の5月から隔週で開催しているエンジニア勉強会は、今もずっと続いています。

特徴的なのが、ビジネスサイドとの連携もしっかりやっているところです。1週間に1回全社スプリントレビューという場が用意されていて、各チームが今開発しているものを持ち込んで、設計段階のものを営業やバックオフィスの方にも見てもらう。実際に「カオナビ」を使う人事の方や営業の戦略的な目で見てもらうことで、早い段階で仕様を確認したり、フィックスしたりできるようなやり方を取っています。これらもボトムアップとして生まれた仕組みです。

カオナビの組織的な課題

逆に、組織的な課題もかなりありました。当時の私が見たところでは、業務委託に依存している、キャリアパスが整っていない、チーム間の連携が不十分、そもそも技術責任者が不在という点です。これらについて簡単に触れます。

「業務委託に依存」は、もともと社員が少ない環境下だったので業務委託に依存してしまう。知識や技術が会社に残らなかったり、オーナーシップをもって行動できる人が少ない環境でした。

「チーム間の連携が不十分」は、社員の割合が少ないので、当然チーム間で積極的に連携することが少なくなっていました。業務委託の方は、クローズされた自分のチームの中で依頼されたことをふだんやっているので、それができない体制だったと思います。また、チームごとに担当したり個別対応する場面も多かったので、機能によって実装方式が変わったり、共通化すればいいのに個別に実装してしまうような場面もけっこうありました。

「キャリアパスが整っていない」は、会社として給与に比例するようなグレード制度はもちろんありますが、実際にエンジニアとして先にどんなキャリアがあるのかは定義されていなかったので、目標設定や評価がやりづらかったと思います。モチベーションにも関わる部分なので、今後社員が増えてきたら、カオナビにいることでどんなキャリアが歩めるのかをきちんと提示できないと難しいと感じていました。

「技術責任者が不在」は、プロダクトとして意思決定はしっかりとできていましたが、どういう技術を使うか、どういう場面でどういう判断をするべきかがなかなか決められない状況下だったと思います。だからこそボトムアップという文化が生まれたのかもしれませんが、全体最適や大きな方針を打ち出すことは難しかったのではないでしょうか。

「カオナビ」の技術的な課題

次は、技術的な課題です。今の「カオナビ」はモノリシックなシステムになっていて、技術的負債の蓄積や品質管理自体が難しいという課題を抱えていました。

まず「モノリシックなシステム」。こういったシステムを扱っている方は理解できると思いますが、影響範囲が大きいため簡単には変更できず、開発スピードが上がらない。

他の機能に依存する部分や相互に影響し合うような場面も出てくるので、同時に複数のラインで開発が走るようになると、生産性がスケールできなくて、チームもそれ以上増やせないという状況もありました。リリースにかかる工数も多くて、全体の影響範囲を見てテストをして大丈夫だと判断してからでないとリリースできない。このあたりも時間がかかります。

当時、マイクロサービスというキーワードも出ていましたが、すごく過度な期待をしていたと思います。マイクロサービス化すれば全てが解決されるように思えてしまって、手段と目的が逆転している状態になっていたので、まずいなと思った記憶があります。

「技術的負債の蓄積」についても、機能開発が優先されてしまうので、なかなか取り組めない状況です。技術品質改善活動が推奨されて、週に2時間はその時間を取ってもいいと言われていましたが、個人に任されていたので、取り組めたのは一握りの人でした。時間も短いので、大きな改善はできない状況です。

「品質管理の難しさ」は、開発者によって品質のバラつきがあったり、機能面ではQA組織が品質を保証してくれてはいますが、逆にQAに任せてしまって、自分たちの品質管理が弱くなっている。QAでどんどんバグが出てきて、手戻りも多く発生していた気がします。ドキュメントも不十分で、実装から理解しようとしても、なかなか全体を把握できないという状況でした

入社してまず着手したシステム改善

そこで私が入って、まずどうしようかと。前職でCTOを経験していましたが、入社時の立ち位置としては“なんでもやる玉拾い”のスタンスで動いていました。それ自体はスキルの向上にもつながったのでよかったのですが、とはいえ少人数のスタートアップで、経営のこともぜんぜんわからない状態でした。カオナビに入った時はCTOをまったく意識していなくて、本当に会社組織を知りたい、経営層の方と近い立ち位置で働きたいと思っていました。

その結果、「執行役員兼プロダクト本部長のもと、横断的に自由に動いていい」というかたちで入り、ここからは思うように動いています。

着実な成果を出さないと、当然ながら「この人、本当に信用できるの？」と思われてしまうので、システム改善の細かいところからやりました。

開発支援として数ヶ月単位の規模のプロジェクトに入り、設計開発をどんどん支援していくなど、みんなの信頼を獲得することを意識してやっていたと思います。

ほかに、新卒研修をやったり、経営層のPoC開発について「こんなことやってみたいんだが」と言われた時に3週間くらいでパパッと作ったり。そういう技術的なところやバックグラウンドをしっかりと発揮できたんじゃないかと思っています。

ここまでで技術スタックもだいたい理解したし、システムとドメインの知識もだいぶ身についてきました。

開発全般の流れも見えてきましたが、頼れる仲間（が見つかったこと）が一番大きかったと思います。

当時、カオナビにはいろいろな課題がある中でも、主体的に取り組んでいる人は多かったし、私もオンボーディングでいろいろな人に手伝ってもらって、Slackでも世話焼きというか、支援してくれる人が多かった。

周りをどんどん巻き込んでよくしていこうと考えている人たちもいて、変化に対して許容できる人が多い印象でした。それも最近入った人や、入社してまだ社歴の浅い人たちが中心だったので、そもそも（企業の中に）“当たり前”がなくて、自分たちでどんどん変えていけばいいという考え方だったのかなと思います。

ボトムアップで変えていけるようにするための組織課題やシステムの改善

ここからはボトムアップでいろいろ変えていけるといいということで、組織課題やシステムの改善に着手しました。まずはチーム間の連携を変えていきたいと思い、当時のEMと議論して、エンジニア分科会を設置しました。

テックリードやEMに集まってもらって、課題の検討や対応方針など、今まで各チームがバラバラで考えていたこと、チームの情報や課題感を共有して、どうすべきかをみんなで議論して対応したり方針を決めたり、「こうやっていこう」という動きをしています。

やはりいいエンジニアを採らないと、その先の育成込みで考えると長い時間がかかってしまうので、対外活動は大事だろう。なるべくどこかで登壇できないかと探っていたところ、アジャテク（Agile Tech EXPO）から登壇の話があったので、「ぜひお願いします」と言って登壇させてもらいました。

XP祭り（XP祭り2020）は、スクラムをカオナビ社内に定着させた2人のメンバーも誘って、45分枠で登壇しました。今までカオナビでの登壇は少なかったので、こういったところも少しずつ変わってきたかなと思います。

モノリシックなシステムに対しては、マイクロサービス化がひとり歩きするのがすごく怖かったので、「そもそもマイクロサービス化をするんだったらこういうやり方がいい」と、こちらである程度方針を出していきました。

具体的な対象機能やフェーズ、マイルストーンをどんどん定義していく。マイクロサービスに寄せる過度な期待をコントロールする。「現実的にはこういうラインまでしかできない」ということを、しっかりと明確化していきました。ただし、この時点でのマイクロサービス化はゴールとは考えていなくて、手段として（であり）、他の選択肢があれば変えてもいいと考えていました。

「もうCTOでよくない？」からCTOに就任

ではボトムアップでこのままどんどんいけるかというと、やっぱりどこかに限界があるんです。組織全体に働きかけるのは難しかったり、即戦力のエンジニアの採用が急務でしたが、採用に深く関わることができないので、いい人を採ることにも関われない。大きな施策を進める時も、方針は示せても体制を作って一緒にやっていくことはできませんでした。

どうしたものかと執行役員兼本部長に相談したら、「じゃあもうCTOでよくない？」という話になりました。ちょうどその時、本部長も経営層と話していたようで、すぐに決まってしまいました。そんな流れでCTO就任。

話が出てから1週間で経営会議の承認が下り、2週間後くらいにはプレスが出たという早い流れで、スピード感がすごいと思った記憶があります。

（次回に続く）