エンジニア組織のロール再定義、横断で動くためのCTO室設立…　組織改善にはボトムアップとトップダウンのどちらも大切

CTOに就任して行った3つの組織的な取り組み

松下雅和氏：ここからはCTOとして組織全体の話をしようと思います。当時「ニューノーマル時代のカオナビへ」ということで、オフィスの移転を行っています。カオナビでは、働き方を選択するのは企業ではなく、社員がするべきだと考えています。

出社は義務ではなく、自由に出社しても自宅でもいい。出社するなら居心地のいい環境を提供するのが企業の義務だと考えているので、すごくいい環境のオフィスを提供してもらった記憶があります。

働き方では、ハイブリッド勤務とスーパーフレックスが新しく増えました。ハイブリッド勤務は自宅でも会社でも構わない。スーパーフレックスは1日に4時間以上働けばいい、自分の裁量で月の所定労働時間になるように働けばいいので、午前中4時間働いたら午後は休むことも可能になりました。

バリューも新しく変わり、（これまでは）「仮説思考」と「仕組み化」と「シンプル」がありましたが、「シンプル」がなくなって、「コラボレーション」と「誠実さ」と「オーナーシップ」になりました。会社として、より全体最適や主体性を求め始めました。

それに対する組織的な取り組み。実際に変えていかなきゃいけないなと思って動いたのは、スライドの3つです。エンジニア組織のロールの再定義・技術力向上の促進・採用広報活動です。

エンジニア組織のロールの再定義

まずはエンジニア組織のロール再定義。当時、テックリードはそれぞれの技術領域であるフロントエンドやバックエンドに1人しかいないという状態でした。人数が増えていくのに、テックリードは領域に1人になってしまってスケールしない。テックリードになりたいと言ってもなれないイメージがありました。また、テックリード自体はチームの外にいて支援する立ち位置なので、チームの中でリーダーシップを発揮する人がいない状態でした。

テックリード自体も決定プロセスが不明瞭だったので、いつ・誰がなるのかよくわからないと思われていたようです。そのあたりをちゃんと見直そうということで、チームに1人設置して、技術的にチームをリードする。リーダーシップをすごく求めるような立ち位置に変えました。リリース・運用・保守に責任を持つということです。

（スライドを指して）チームのイメージはこんな感じです。チームを技術領域、人・チーム領域、プロダクト領域に分ける。すると、テックリードは技術領域を見つつ、プロダクトと人・チームに対しても少し関わっていくような立ち位置で、リーダーシップを発揮する。EMはチームの中にはいないので、外から支援をする立ち位置です。カオナビには特定領域に特化した人を認定する“Expert”という人がいるので、そちらから技術的なサポートも得られるようなチーム体制を作っています。

（スライドを指して）グレードは公開できませんが、実際のグレードとロールの関係性はこんなかたちです。最近では“IC（インディビジュアルコントリビューター）”と言われますが、部下を持たないでエンジニアとしてのキャリアを上げていくことも、カオナビとしてちゃんとやるべきだと。

エンジニアはシニアエンジニア、プリンシパルエンジニア、チーフエンジニアというかたちで、しっかりと開発に注力してグレードを上げられるように意識したラダーを用意しています。他に、テックリードやEMにもそれぞれラダーを用意しています。これらの運用は2022年7月から始まるので、これからどうなるかと思っていますが、どんどん変わっている状況です。

技術力向上の促進

続いて、技術力向上の促進について。『ELASTIC LEADERSHIP』という本で見た方も多いかと思いますが、一般的にチームの状態として、サバイバルモード、学習モード、自己組織化モードという一連の流れがあります。

サバイバルモードになっていると、常に火消し状態というか、遅れと残業が多くて次の一手が打てないような状態になってしまっている。カオナビはそこまで仕事が忙しいわけではないですが、ふだんの業務の中にゆとり時間がまったくなくて、自分のスキルを上げたり、次の一歩で新しいことをやったりできない状態だったので、学習モードでもありませんでした。

そこで、カオナビでは「スナバ」という制度を作りました。こちらは業務時間を週に2時間まで自由に使っていいという制度です。将来的に事業貢献やプロダクト改善につながるようなものであれば何をしてもかまわない時間を用意しています。未来の自分や誰かのためにゆとり時間を用意することで、それを活用してどんどんよりよい環境を整えていくことを目的にしています。

最初はなかなか使ってもらえなかったのですが、自ら楽しんで実践している姿を見せると、こういう使い方ができるんだと楽しんでもらえます。

私の場合は、Slackのスレッドに返信をすると画面上に「ニコニコ動画」みたいにメッセージが横に流れる「Message Screen」というアプリを作りました。これが割と好評で、今でも使ってもらっています。

他にも、お酒を飲みながらカジュアルにいろいろな話をしていきましょうと、「イドバタ」という業務時間外の学びの場も用意しています。

過去には、「あなたのターニングポイントは？」という話や、開発と品質の話、RSGT（Regional Scrum Gathering Tokyo）の動画の上映会など、いろいろやっています。

「カタリバ」は社内勉強会に名前をつけただけですが、こちらもすごく盛り上がっています。Message Screenを使って返信を書いてもらうので、勉強会ではみんなのワイワイガヤガヤしたメッセージが500件以上流れていきます。

採用広報活動

採用広報活動では、エンジニア採用が年々困難になっているので、トップダウンで何かやるのは難しいだろうと思っていました。みんなにも協力してもらって、主体的に関わってほしいと思ったので、Slackでみんなに伝えて、「協力してもらえる方はぜひお願いします」とアナウンスしました。今は10名以上集まって、採用チームのメンバーと一緒に、どういう施策をすればより人が集まるのか、カオナビの名前を外に出していけるのかといった施策を練っています。

実績として、第1弾はAdvent Calendarでしたが、こちらも社内のメンバーに声をかけたら25人集まって、なんとか枠を埋められました。他にも、ここ1年くらいは各所で協賛して登壇も経験しています。

また、kaonavi Tech Talkという社外勉強会をやっています。来週第6回があるので、興味があればぜひ見てください。

技術的な取り組み

技術的な取り組みの「技術的負債解消へ」は、マイクロサービス化に向けて、タスクフォース化してメンバーを集めて動き始めています。まずは共通基盤となり得る箇所から手を出そうということで、今はCTOとしてオーナーシップを持ちつつ、Big Rewriteを避けながら着実に進めています。

他に、フロントエンド支援チームがフロントエンドをどんどん新しく変えようとしています。

QA（Quality Assurance）体制の見直しもやっています。QAは本来、本部外から品質を保証する役割だと思いますが、実際は本部の中にいて、それぞれのチームに対して品質担保をするような動きになっていました。（つまり）QAではなくQC（Quality Control）だと。そこで、QA組織自体を解体して各チームにQCとして動いてもらおうということになりました。今はQCが各チームに配属されて、QCの横組織でお互いの知見を深めていく体制に切り替えました。

そして、品質の改善。スライドの例もそうですが、エンジニアには当たり前の品質である「これ、当たり前にできるよね」という考え方があると思うんです。しかし、経験の浅い人など、いろいろなバックグラウンドの人がいるので、なかなか共通認識として持てない。それらを当たり前の品質としてしっかりとドキュメント化して、みんなで共有したうえで開発してもらうように取り組んでいます。

他に、ポストモーテム運用もやっています。何かインシデントが起こった時にはしっかりとそこから学びを得る。振り返りながら、組織的に根本的・恒久的な改善につなげていく取り組みもやっています。

ここまでを振り返ると、もともとカオナビには組織的な課題がありましたが、それに対して、採用広報活動のほか、それぞれの課題に対して取り組むアプローチをしてきました。組織的な課題は、比較的トップダウンで関わるものが多い印象です。やはり組織として取り組むのに、ボトムアップで少しずつ変えるのは難しいので、そこはエイヤッと変えることが多かったです。

逆に技術的な課題に対しては、それぞれ対応するものがあると思います。これらは、かなりボトムアップで取り組むことが多いです。トップダウンで方針を決めますが、実際に動くのはメンバーなので、ボトムアップでしっかりと管理したり、把握しながら進めてもらうのが一番いい。トップダウンとボトムアップを使い分けています。

技術的な課題を横断に解消するためにCTO室を立ち上げ

これですごく順調かというと、実は機能開発が優先されることで人の奪い合いが起こって、なかなか進まない。

横断的に動いて、技術的な課題を解消する組織が必要だということで立ち上げたのがCTO室です。

現在は4つのチームがあります。先ほどのフロントエンド支援チームがFEST。マイクロサービス化のタスクフォースのチームはBERTという名前で、現在はマイクロサービスではなくモジュラモノリスを目指すべく動いています。+SREは、よりインフラやSREという観点で全社的な課題を解決するチームです。このように、かなり横断的にいろいろなところに関わっていくチームがCTO室の中にいます。

CTO室メンバーに対して求めるマインドは、基本的に全社に対するものとそんなに変わりませんが、主体性に加え横断的に動くからには巻き込み力や飛び込み力が大事です。コラボレーションとして、全体最適をしっかり理解したうえでやらないといけない。また、失敗を恐れない。大きく変えなきゃいけない場面も多いので、そこは恐れずにしっかりとやっていこうという方針を打ち出しています。