開発組織全体に横断的な技術支援を行うチームとして、2022年に設立されたカオナビのCTO室。技術課題の解消やメンバーの育成など、幅広く開発現場をサポートする役割を担っています。
支援を通じて、バックエンドやフロントエンド、さらには開発組織全体にどのような変化が生まれているのか。そして、「CTO室がリードせずとも、現場主導で改善を進められる」組織を目指すプロセスとは──。
CTOを務める松下さんと、エキスパートの富所さん、鈴木さんに具体的な取り組みを聞きました。
俯瞰的な視点で技術課題に向き合うCTO室の役割と立ち上げの背景
まず、CTO室の立ち上げ背景と現在の役割について教えてください。
CTO室は、開発組織全体に横たわる技術課題を中長期的な視点で解決することを目的に、2022年4月に発足した組織です。
当時は、各チームがカオナビの機能開発に集中するあまり、機能をまたがる課題や長期的に取り組まなければならない技術課題に目を向けづらい状態でした。そこで、プロダクト開発の現場から少し離れた俯瞰的な視点で課題を捉え、支援を行うために、CTO室を立ち上げたのです。
現在は、そうした技術課題の解消に加えて、技術広報をはじめとした社外への情報発信や、プロダクト開発組織における育成やマネジメントもサポートしています。
CTO
松下 雅和SIer企業を経て、サイバーエージェントでゲームやコミュニティサービスを開発後、アプリゲームのスタートアップでCTOを経験。現職では、主にCTOとしてプロダクトとエンジニア組織の成長に取り組む。
立ち上げ当初に向き合っていた横断的な技術課題には、どのように取り組んできたのでしょうか？
当初は、フロントエンド・バックエンド・インフラ、3つの領域それぞれに課題を抱えていました。そのため、CTO室に所属する各領域に精通したエキスパートがリードしながら対応できる体制を構築しました。
まず着手したのは、課題の「見える化」です。社内でどのような問題が存在していて、どのような順番で解消していくべきか。改善への道筋を立てるために、「カオナビ」のテックリードたちにヒアリングを重ね、整理を進めていきました。
その後、技術課題の管理・改善の仕組みが整備されるにつれて、各領域の体制も徐々に変化していきました。例えば現在では、課題管理の役割は「技術基盤部」に引き継がれ、CTO室は支援する立場として関わっています。またインフラ領域についても、保守運用の横断的な管理を担う「プラットフォーム本部」が新設され、そちらに業務が移管されました。
組織の拡大や新たな課題の発生にあわせて、CTO室の役割や支援の仕方は、都度アップデートし続けています。
課題解決の実行フェーズでは、どのように進めているのでしょうか？
技術課題は非常に多岐にわたるため、CTO室だけですべてを解消するのは現実的ではありません。私たちが課題解決のためのプロセスを描き、実際の作業は開発チームと協力して進める形をとっています。
だからこそ、何よりも重要なのは他部門との関係構築です。課題を共有し、解決への方向性を提示しながら、合意形成を積み重ねていく。そうした丁寧なコミュニケーションを心がけています。
一つひとつの取り組みはスパンが長いため、まだまだ解消し切れていない課題もありますが、発足以来、確実に改善を進められていると感じます。
信頼構築から始め、新たな知見を常に取り入れるバックエンド組織に
開発現場での課題解決について、詳しく伺いたいです。バックエンド領域では、どのように取り組まれてきたのでしょうか？
私が入社して最初に取り組んだのは、開発環境の改善でした。当時はマシンスペックの問題もあり、動作がかなり遅く感じられました。お客様に直接提供している画面ではないものの、この状態では開発効率にも支障が出てしまうと考え「この開発環境を改善していったほうがいいのでは」と伝えることから始めました。
他にも、リリース時の混乱を防ぐために、機能を小さく分けて段階的にリリースできるフィーチャートグルを取り入れました。また、機能追加や修正の負荷を下げるために、コードを機能単位で管理するパッケージバイフィーチャーの仕組みも導入しています。
加えて、アーキテクチャーディシジョンレコード（ADR）の整備も進めました。アーキテクチャに関する重要な意思決定を記録に残し、後から組織全体で見返せるようにするための文書です。いずれも、バックエンド開発部門のメンバーとともに取り組んできました。
CTO室
エキスパート（バックエンド）
富所 亮
SIer企業にて、自社・受託を問わずWebアプリケーションの開発に従事。2020年に当社に入社し、バックエンドのエキスパートとしての業務の傍ら、PHP界隈の勉強会やカンファレンスに多数登壇。
入社直後からさまざまなアクションを起こされていたんですね。
とはいえ、途中から会社に入ってきた人間が、いきなり「こうした方がいい」「ここを変えるべき」と言っても、なかなか受け入れてもらえません。
耳を傾けてもらうには、まず周りに対してきちんと貢献し、自分という存在を信頼してもらうことが肝心だと考えていました。そのため、最初は「顔を覚えてもらうこと」「コミュニケーションの機会をつくること」から始めたんです。
リモート勤務のメンバーが多い中でも、出社のチャンスがあればできるだけ対面で話すようにしていましたし、普段のやりとりに使っているSlackでも、積極的にやりとりに加わるよう心がけていました。
関係性が築かれていく中で、どのような変化を感じていますか？
社内での改善活動と並行して、社外のカンファレンスや勉強会に参加し、新しい技術や知見に触れることの重要性についても伝えてきました。そうした働きかけの中で、バックエンドのメンバーたちが自発的に外部との関わりを持ち、積極的に情報を取りにいってくれるようになったのは、大きな変化だと感じています。
世の中のトレンドや他社の取り組みに触れることで、自社とのギャップに気づけるようになったのも、ひとつの成果です。結果としてチーム全体の視座も上がり、今では非常に頼もしい存在になってくれたと感じます。技術的な観点でも、同じ目線や共通認識のもと、よりフラットに建設的な議論ができるようになりました。
気づきを促すアプローチが生んだ、フロントエンドチームの変化
続いて、フロントエンドでの取り組みについて教えてください。
入社後、まずはプロジェクトの状況や基盤の構造、開発の進め方などを一通り把握していきました。その中で、バックエンドと同様に「もっと改善できる」と感じるポイントがいくつも見えてきたんです。
最初に出したプルリクエストは、機能追加やバグ修正ではなく、コードの記述ルールを自動でチェックするリンターの設定を見直すものでした。すぐに着手できる改善活動だと感じたので提案したのですが、社内のメンバーからは「いきなりそこを直すの？」と驚かれましたね。
日々の開発業務に追われていると、足元の課題に目を向けづらくなります。だからこそ「自分たちで気づき、改善していける組織」をつくりたいと考えました。
組織を、マインドや行動の面から変えていくのですね。
その通りです。常に意識しているのは「まず自分がやってみせる」ことです。例えば、私が最初に手を動かして、コードを一部だけ改善してみる。そうすると、メンバーに「こんなやり方もあるんだ」と気づいてもらえるきっかけになります。
すべてを自分で修正するのではなく、再現しやすい環境を整える。また、メンバーが良い動きやアウトプットをしたら、オープンな場で賞賛し、他のメンバーにも波及させる。こうした働きかけが、まさにCTO室のテーマである“支援する”という役割につながっていると感じています。
フロントエンド組織の中で感じる変化についても教えてください。
自分やチームにとっての最適を追求するだけでなく、“会社全体”の視点から考え、行動してくれるメンバーが増えたと感じます。
カオナビでは各チームが裁量を持って業務を進めている分、どうしても自分たちの視点に閉じがちな部分もあります。
しかし最近では「このコードは他チームの機能にも活用できるのでは？」と、チームの取り組みを積極的に共有する動きが出てきました。チームを横断して知見を共有することで、全社的な開発スピードや品質の向上にもつながると考えています。そうした前向きな変化を日々目にできることが、とても嬉しいですね。
CTO室
エキスパート（フロントエンド）
鈴木 僚太LINEにて金融領域を経験後、AIオートメーションを専門とするバベルを経て現職。開発環境や設計改善を通じて、開発効率の向上に取り組む。著書に『プロを目指す人のためのTypeScript入門』。
CTOの松下さんから見て、2人の取り組みはいかがですか？
長く社内に在籍していると、自分たちの業務の進め方や開発環境が“当たり前”になってしまい、本来であれば改善できるはずの課題に気づけなくなることがあります。だからこそ、こうして2人が外からの知見を持ち込み、違和感や問題点を率直に発信してくれるのは本当にありがたいですね。
現在は私も入社して時間が経ちました。それゆえ、引き続き外部の知見を積極的に取り入れることを意識しています。
また、新しく入社したエンジニアのメンバーには、カオナビの開発環境や課題についての意見を聞くようにもしています。こうした継続的な取り組みが、CTO室としての現場支援に活きていると感じています。
チーム間のさらなる連携と学び合い、生産性向上を目指して
CTO室では現在、技術広報や開発組織内の人材育成にも力を入れていると伺いました。具体的な取り組みを教えてください。
技術広報の観点でここ数年注力してきたのは、バックエンド領域の採用です。PHPというプログラミング言語に特化したカンファレンスへの協賛や登壇を続けてきたことで、エンジニアコミュニティ内でのカオナビの認知は着実に高まってきたと感じます。そうした場をきっかけにつながりが生まれ、リファラルで入社いただくケースも増えました。
今年度からは、フロントエンドやインフラ領域、さらにはPHPだけでなくGoなど他のプログラミング言語の分野でも採用を強化していこうと、取り組みをスタートさせたところです。
一口に「エンジニア採用」といっても、担当領域や職種によって最適なアプローチの方法も異なります。どういった方にリーチしたいかを戦略的に設計しながら、それぞれに合った発信や接点づくりを続けていきたいですね。
開発組織内の人材育成についてはいかがでしょうか？
チームを超えて学び合う機会として、「オアシス」と呼んでいるイベントを毎月開催しています。オフラインで集まり、軽食やドリンクを囲みながらディスカッションや交流を行う場です。
最初はプロダクト開発組織を中心に呼びかけていたのですが、最近ではエンジニアだけでなく、セールスやマーケティング、デザイナーなどさまざまな職種のメンバーが参加しています。「AI」をテーマにした回では、予想を超える人数が集まり、大きな反響がありました。
チームや職種を越えて、接点を持てる機会となっているのですね。
鈴木さんから「知見がチーム内に閉じがちだった」という話もありましたが、そもそも職種や部門を越えて話す機会は、日常的にはあまり多くありません。オアシスのような場を通じて「顔と名前が一致する関係」を築けることが、コミュニケーションを円滑にするうえで非常に重要だと考えています。
そうすれば、いざ困ったことが起きた際にも「あの人に相談してみよう」と、問題解決がしやすくなるかもしれません。
組織が大きくなるほど、横断的な取り組みや対話の難しさは増していきます。だからこそ、立場や役割を越えて率直に意見を交わせるような関係性を、これからも丁寧に育てていきたいですね。
また、そうした関係構築と並行して、より広い視点での「組織の見える化」にも取り組んでいます。
「組織の見える化」とは？
開発の効率や生産性、そして私たちが生み出しているプロダクトが本当に価値あるものかどうか。そういった点を数値で可視化しながら、より効率的かつ効果的にお客様に届けられるよう改善を進めています。
その一環として、モデルケースとなる生産性の高いチームをいくつか選定し、業務プロセスの改善や進め方の磨き込みを進めています。社内にとどまらず、アジャイルコーチなど外部の協力も得ながら、試行と改善を続けているところです。最終的には、再現性のある成功モデルを確立し、開発組織全体への展開を目指しています。
現場支援を通じて、個人と組織の可能性を広げたい
技術支援から組織づくりまで、CTO室での取り組みがどんどん広がっている様子がうかがえます。
CTO室が設立された背景には、技術課題に対する強い危機感がありました。数々の課題をそのままにしていては、組織として立ちいかなくなってしまう。まさにやらざるを得ない状況だったんです。
しかし、本来はそうした技術課題の解消は、CTO室が起点となるのではなく、現場のチームが自律的に取り組んでいける状態が望ましいと考えています。最近は、現場でも積極的な改善の動きが見られるようになり、私たちCTO室は、もっと広い意味での「組織づくり」にフォーカスできるフェーズに入ってきたと感じています。
フロントエンド領域でも、最初は自分が手を動かして課題を解決する場面が多く、CTO室が理想とする「支援者として現場を後押しする立場」とのギャップを感じていました。
しかし今では、自律的に改善に向けて動く文化の醸成や、その仕組みづくりに取り組んできたことで、現場のメンバーに安心して任せられることが徐々に増えてきました。目指していた姿に着実に近づいている実感があります。
技術課題に向き合うのは、非常に骨の折れる、いわば泥臭い作業です。過去から積み重ねてきた負債を解消したり、慣れたやり方を根本から見直したりするのは簡単ではないですからね。今後は、メンバーたちに「課題を発見する」最初のフェーズもどんどん経験してほしいと考えています。
本当にそう思います。課題の発見や土台の改善といった取り組みは、新機能の開発やプロダクトの立ち上げのように目立つ仕事ではありません。ですが、こうした見えにくい仕事が、組織にとっては非常に重要だと感じています。
そしてそのプロセスに関わることは、エンジニアにとっても大きな学びの機会になります。 課題を捉え、改善を形にする経験を通じて、より多くのスキルや知見を身につけ、周囲から信頼される存在へと成長できるはずです。
そうしたメンバーのキャリアの幅を広げるような支援にも、今後は一層力を入れていきたいですね。