自己紹介とカオナビという会社

宇谷：まず最初に自己紹介です。宇谷有史といいます。今はプロダクトデベロップメント本部 TalentHRグロース部という部署で、マネージャーや現場でコードを書いたりということをやっています。

今日はカオナビでClaude Codeを導入して、みんなに配って使ってもらって生産性を上げて、どんどんコードを書いてもらうということをやっているんですけれども、ただ配っただけだとうまく、そんなに使ってもらえなかったりという部分があったので、そういうような壁をどうやって乗り越えてきたのかというところを話そうと思っています。

カオナビという会社がどういうような会社で、どういう規模感で、どんなチームがあるのかという前提情報がないと、なかなか大変さとか、皆さんの今働いているような会社との違いがどういうところにあるのか分からないと思うので、最初に会社の紹介をさせてください。カオナビは「”はたらく”にテクノロジーを実装し、個の力から社会の仕様を変える」というパーパスを掲げております。提供しているサービスは、社名と同名のタレントマネジメントシステム「カオナビ」です。

ここに来ている方の多くはエンジニアの方が多いのかなと思っていて、じゃあ実際人事の仕事って何をやっているのというのが分からないと思うので、もうちょっとカオナビの紹介をさせてください。カオナビで解決できる人事課題というところで、人材情報の一元化、社内に誰がいてどんな人がいるのかを調べたりするようなものや、人事評価の仕組み、最近だと勤怠管理やスキル管理などのラーニングマネジメントシステムもあって、ちゃんと研修を受けてくださいねということができたりします。こういうような情報をカオナビに貯めて、経営層の意思決定の場で使ったり、社内にどれぐらいの年代の割合でいるのか、5年後どうなるのかということを考えたりするために、カオナビというものを導入いただいていたりします。そういうようなものを作っている会社で、AIを入れたらどうなったかというお話をしていきます。

カオナビの開発現場とAI活用の変遷

カオナビの開発現場の現状としましては、プロダクトデベロップメント本部というところの配下に開発の部署がいっぱいあって、今8つの部署があります。上の段にあるのが機能の開発をしているチームで、下の段にあるのが下回りの基盤だったり、最近は職能別の組織体制になったところでQA部だったりデザイン部があります。この外側にさらにCTO室だったりAI推進室というのがあったりして、会社全体的に技術やAIの支援を受けられるような体制があります。

組織の規模としては、今だいたい200から300人ぐらいが開発の部署の中にいます。ここでいう開発の部署というのは、デザイナーもQAもいるし、コードを書いている人もいるし、マネージャーというところも含めてです。チーム数としては約30チームぐらいで、自分が入社した4年前とかはもっと少なかったんですけれども、知らないうちにだんだん膨れていて、周りを見てもあのチームって何をやっているんだっけというのが認識しづらい状態になっています。コードベースはモノレポで、カオナビのソースコードでPHPできていて、パッケージバイフィーチャーとかモジュラモノリスみたいなもので機能単位でディレクトリを分けるということをやっています。開発スタイルとしてはスクラムとかカンバンとかチケット駆動とか、チームによって採用しているスタイルは別々だったりします。使用言語やツールはPHP、Laravelが一番メインで、Goが使われていたり、フロントエンドはReact、TypeScriptがあったりというところです。

AIのところを見るとClaude、DifyとGeminiがあって、基本的にはエンジニアはClaude Codeを使っています。

カオナビは今までGitHub Copilotを最初に導入したり、社内用のSlackボットを作ったりというのをやりながら、23年、24年、25年という風に変わってきて、25年はClaude Codeを入れていきましたよという感じです。どういう風に考えてどういう風に入れてきたかはスライドにまとまっているので、AI導入のところで気になっている人はこちらも見てもらえるといいかなと思います。

壁1：現場に浸透しない「不使用の壁」

じゃあカオナビが直面した3つの壁の話をここからしていこうと思います。現場に浸透しない「不使用の壁」というのは最初にやってきました。Claude Codeのアカウントを申請したら使えるようになりましたと言って、自分からしたらめちゃくちゃ便利になるからみんな使うんだろうなと思っていたら、思ったより使われないなというのがありました。

なんで使っていないのか聞いたら、「開発が忙しいので新しいものを使おうと思ってもキャッチアップする余裕がないんですよね」とか、「世の中ですごい騒がれているのは知っているんだけど使い方が全然分からない」とか、「従量課金のプランで使っているので使いすぎると怒られるんじゃないか」という不安の声があって、最初の1ヶ月わずか14人ぐらいしか使ってくれなくて困りました。

これがClaude Codeの利用者の推移で、青い棒が新規にアカウント発行してくれた人、折れ線グラフが累計で何パーセントぐらいの人が使っているかというところです。左側で山が大きくなっているのは検証で何チームかに配布してみたところで、実際全社に展開したのが12月です。

12月、1月あたりを見ると、自分の予想ではそこがいきなり跳ねて、その後だんだん落ち着いていくかなと思ったんですけれども、全然そんなことはありませんでした。

じゃあどうやって使ってもらおうかというところで、利用者を増やすための施策として3つのことをやってきました。1つ目はトップダウンのメッセージです。経営層や本部長からメッセージを発信してもらおうと思って、本部会で2月にはまず「コスト気にせずどんどん使ってください、全社的にAIへの投資フェーズだから使いすぎちゃったと思ってもいいから使ってください」ということを言ってもらいました。3月も本部会でアウトプットもアウトカムも10倍の世界に変わっていくことを目指しますというところを発信してもらい、この会社は本当にAIを使って生産性を上げるんだな、周りがやっているからではなく自分たちがやることに対して効果を出していくんだなということを発信してもらいました。

2つ目はAIの利用の情報発信です。AI週報というのを作って、毎週社内の新しく作られたスキルやClaude Codeのリリースノートをまとめて共有するようにしました。あとはすぐ使ってくれるような人はモデルを切り替えてプランモードにするなどのテクニックをしているんですけれども、後から使ってみたい人はまず何をやったらいいか分からないので、まずはプランを立ててから使いましょう、プランを立てるときはOpusを使ったほうがいい、実装はSonnetにさせたほうがいいというようなチップスを紹介して社内に広めました。あとはカタリバという、カオナビが2週間に1回やっている勉強会でも、AIの話をしてくださいと言わなくてもみんな当たり前のようにAIの話をしていて、社内でどうやら隣のチームはあんなふうに使っているらしいぞという情報が発信されて、使わないとまずいんじゃないかという雰囲気になっていきました。

3つ目はデータを用いたアプローチです。なんとなく使っているっぽいというだけだと、実際何人使っているのか、どれぐらい使っているのか分からないので、ちゃんと定期でモニタリングをするためにダッシュボードを作りました。アカウントの発行数だけでなく、毎日使っているのか、1週間に1回なのかというところも見て、あまり使っていない人がいたら困っていることはないかヒアリングしに行ったり、使っている人がいたら活用事例を周りに教えてくださいという話をしたりしました。そうした結果、90%以上の人がClaude Codeのアカウントを発行していて、実際に使ってくれているという状況まで持っていきました。

壁2：活用が一部の人にとどまる「属人化の壁」

次に属人化の壁というところを話していこうと思います。会社ですごく使っている人はめちゃくちゃ使っているんだけど、使っていない人は全然使っていないという差が激しいということが起きていました。

活用し始めた人はものすごくトークンを使用している一方で、アカウントを作成したけれども毎日使うほどではない人もいる。もっと使ってもらうためにどうしたらいいのかというところで、いろんな施策をやりました。

やっぱり周りがどうやって使っているかが分からないと、自分の使い方が合っているのかどうかも分からないんですよね。カオナビはリモートで働いている人がたくさんいるので、オフィスで隣の人がどうやって使っているのか覗き込んだりできないので、Slackがメインになりました。「#fun_claude_code」というチャンネルがあって、新しい情報をキャッチアップした人がどんどん情報を流してくれたり、こんなふうに使っていますというドキュメントを書いて流してくれたり、ハドルをしてClaude Codeにチケットを渡して実装させてレビュー出すところまで全部全自動でやりますというデモをやってくれる人がいて、こういう社内コミュニティが盛り上がると、とりあえず使っておけばいいんだなというのが分かって利用が増えてきました。

多分これが一番大きかったんじゃないかなと思っているのが、Claude Codeがプラグインのマーケットプレイスで機能を提供していて、あれは自分で作ることもできるというところです。社内のGitリポジトリにスキルを配布できる場所を用意して、いろんな人にスキルを作ってもらって共有できる状態にしました。その結果、自分が作ったスキルを他人と共有すると、今まで自分が苦労していることはこんな簡単にできるんだと分かったり、周りの人がどうやって作っているのか分かって自分でも作ってみようと思える人が増えました。

うちはGitHubじゃなくてGitLabなので、GitLab workflowといって、チケットを渡すと実装してレビュー依頼まで出してくれる、CIが回ってチェックして落ちていなかったらちゃんとレビューを出すというものが作られたり、RedmineやConfluenceなど普段使うツールのスキルも用意されたので、みんながわざわざ各々手元で作らなくてよくなりました。

3つ目がこの勉強会の差分解というのがすごく良くて、若手のエンジニアが中心になって勉強会を立ち上げてくれました。若手だとみんなAIをどうやって使っているのか分からないから聞きたいと言って、先輩社員を連れてきて30分の勉強会でデモをやってもらったり、世の中でハーネスエンジニアリングが流行っているんだけど何なんですか教えてくださいとか、使いすぎないようにステータスラインで今どれくらい使っているか見たいのでハンズオンをやってみようというようなことをやって、社内で若手からシニアまでAIを使うところの情報を流通させるということが起きました。これが2週間に1回のカタリバと交互に毎週あって、社内にいるとAIの勉強会が毎週あって新しい情報が手に入るという状態になり、使う人が増えていきました。

利用状況の改善というところで、P75で見てもP50で見てもだいたい上がっていて、新しくアカウント発行した人はいきなり最初からバンバン使えるわけではないことを考えると、P50が維持されているだけでも結構すごいんじゃないかと思っていて、結構使われるような状況になりました。

壁3：全体の停滞を招く「レビューの壁」

3つ目のレビューのところは、皆さんかなり気になっているんじゃないかなと思います。このカンファレンスのためにトークの内容を提出してくださいと言われたのが3月末の時点だったので、こういう兆候があるんじゃないかなというところも含めて先のことを考えながらプロポーザルを出しました。

AIの利用が進んだ結果マージリクエストが増加してレビューされず、生産性が頭打ちになるんじゃないかなとぼんやり思いながら、カオナビはそのために何をやらなきゃいけないんだろうかということを考えながら出していました。

じゃあ実際マージリクエストの本数は上がったのかというところから見ていくんですけれども、時期をプロットすると12月が正式採用で、そこから1月2月3月4月、5月で1回落ちるんですけれども、これはゴールデンウィークの影響で日数が単純に少ないためです。

6月末時点でもやっぱり増加していて、AIをアカウント配布して使ってくれる人が増えるにつれてどんどん上がっているということが言えそうです。まだ頭打ちになっていない感じもあります。

じゃあレビューのところはどうなんだろうと思って、コーディングからマージされるまでのライフサイクルのデータを見ると、正式採用されたその後を見てもマージまでの時間は変わっていない、これはP50なので中央値です。棒グラフの内訳を見ても、全体の傾向としては大きくは変わっていません。

P75で見ても全体の傾向としては変わっておらず、むしろレビューからマージまでの時間は短くなっているみたいなことになっていて、カオナビではレビューがボトルネックにならなかったんですよね。

じゃあなんでレビューがボトルネックになっていないんだろうというところを話せればいいかなと思います。仮説となんで違ったのかと考えると、カオナビはマージリクエストがレビューされてマージされるまでを短くしましょうというアクションをずっとやってきていて、そこにすごく取り組んでいました。その施策をいくつか紹介できればと思います。

まずガイドラインが整備されていて、これは自分が入社した4年前からもうすでにあって、レビューを出すときはちゃんと概要文を書きましょう、コミットメッセージを書きましょうとか、1回のマージリクエストは200から300行までが理想で、これ以上大きくなるとレビューが大変ですよというガイドラインが整備されていて、行数というところで把握できる単位に区切りましょうということをやっていました。ガイドラインは作っても運用されないと意味がないんですけれども、カオナビではこれが結構ちゃんと守られて機能しているガイドラインで、最終的にちょっと大きかったなとなったら、こういうふうに分割するといいんじゃないですかとレビューがコメントしてくれたりして、ちゃんと分割されています。

あとは設計レビューという仕組みがあって、これは事前に作るもののアイデアをドキュメントにまとめてみんなにレビューしてもらう仕組みです。これがあるだけで、その後マージリクエストをパッと見たときにいきなり全然知らない機能がやってきてレビューしてくださいと言われると、これで合っているのかなとなってとても辛いんですけれども、設計レビューがあってこれから作られるものがどんなものか分かっていると、コードレビューをするときに助けになります。マージリクエストがすぐマージされないのは、結局そこで議論が始まってしまっているんですよね。こっちのほうがいいんじゃないか、あっちのほうがいいんじゃないかという議論がコメント欄で始まると、マージまでの時間がどんどん長くなって手戻りになってしまうので、それを事前に検知するためにこういう仕組みを用意しています。

あとはレビュー体制の改善というところで、フロントエンドのチームがどうやったらもっと早くマージリクエストをマージまで持っていけるかを毎週議論して、いろんな施策をやってみたそうです。フロントエンドのレビューできる人が少なかったので増やそうと、でもいきなり若手にレビューしてもらうのは難しいので、先輩社員と一緒に見てペアでレビューして、どういうところを見ているのか、どういう観点で見ないといけないのかを体験しながらやっていきました。

あとはエリアレビューといって、それまでは自分が作っている機能じゃない機能をレビューしましょうとやっていたんですけれども、カオナビはたくさん機能があってたくさんチームがいるので、知らないチームの知らないものがどんどん飛んでくると分からないし、通知が多いと見逃してしまうので、2つにエリアを分けてあなたはこっち、あなたはこっちという形でレビューをするようにしました。そうすると通知が減って見逃しが減ったり、フォーカスするところが決まってレビューがしやすくなりました。

あとはフロントエンドのエキスパートがClaude Codeにレビューさせるためのスキルを整備していったので、AIの助けを借りて書いたコードをAIの助けを借りてレビューしていくところがあって、本当にAIが言っていることが間違ってなさそうかを見ていくという感じに変えられて、レビューの負荷が下がりました。

結果、カオナビではレビューはボトルネックになっていなかったというのが結論なんですけれども、もしかしたら皆さんが期待していた結果と違うのかなというのはあります。なんでボトルネックになっていないのかというと、そもそも人が手でコードを書いていた時代においても、やっぱりレビューは大変だったし、その大変だったレビューに対してどうやって改善していきますかという取り組みをずっとやってきたから、AIがやってきても同じように問題にはならなかったという部分がありました。

なぜ乗り越えられたのか―データ文化と成長支援の仕組み

じゃあカオナビが今AIを導入して90%ぐらいの人が使ってくれて、レビュータイムも変わらなくてということが、なんでうまくいったのかなと、最初このトークを出したタイミングでは考えていなかったんですけれども、まとめていくとなんでこうなったんだろう、自分が特に何かをしたわけでもないのにどんどん勝手にこうなっていったというところがあるので、どうやったらそういうような組織や文化が根付くのかというところを紹介できたらいいかなと思います。乗り越えることができた一番大きい要因は2つあって、データを見て改善するという文化が当たり前のようにあることと、エンジニアに対する成長支援の仕組みがすごく充実していることです。

カオナビでデータを見て改善する文化は突然生まれたわけではなくて、2023年ぐらいにSnowflakeを導入してどんどんデータを貯めて分析できる基盤を作りましょうというのを始めました。これは開発のためではなく、カオナビという組織全体がいろんなデータを分析しながらもっとお客さんに導入してもらう、開発の生産性を上げるにはどうしたらいいんだろうというところを分析したいというところで始まりました。2023年にSnowflakeのPoCが始まって、2024年、25年とだんだん基盤を整備していって、その基盤を使って皆さんの活動を改善してくださいねという風になっています。

今回Claude Codeの利用料金やトークンの使用量も全部その中に入っていて、一般の社員がそこを集計して、あのチームはすごく使っているぞ、うまくやっているんじゃないかというところが見えるようになっていて、気になった人がその場ですぐ調べてAIがSQLを書いてくれて分析するということができています。

Claude Codeの前からデータを見て改善するというのはやっていて、CIの実行時間で一番遅いテストはどれなんだろう、本番デプロイまでの時間が長いんだけどどこを改善したら早くなるだろうかということや、チームのアクティビティを取っていて、月にマージリクエストが何本くらい出ていて上昇傾向にあるのか下がっているのかというところも見れる状態になっていました。そのためチームが自分たちをヘルスチェックして改善していくという基盤がすでに整っていて、今回Claude CodeというAIが出てきても、すごい新しいものという感じというより、今までやっていることを当たり前のようにやるだけだよねという感じで、データを見て改善するということをやってきました。

もう一つのエンジニアに対する成長支援の仕組みの充実というところで、カオナビの会社のバリューの中に「会社を使って成長する」というものがあって、エンジニアに対してだけでなく全社員に向けて会社を使って成長してくださいということが発信されています。スキルアップや学習機会を積極的に支援していますというのを打ち出すぐらいにはいろんなことをやっていて、砂場という毎週2時間自由に使える時間や、業務に必要な本を月1冊買える本棚という制度、さっきの社内勉強会のカタリバは年間で25回、2週に1回やっていく計算です。

今日のようなカンファレンスに行きたいと思ったら、実際に行けるという支援も充実していて、カオナビの名前をカンファレンスでよく見ますと言われるくらい、本当にいろんなところをスポンサーしているので、それで実際にカンファレンスに足を運んでもらうことがいっぱいあります。

これはいきなり制度が入ってきたわけではなく、CTOの松下がCTOになってからカオナビのエンジニア組織を作るぞといったときに、色んな施策を用意してくれていて、2022年ぐらいにこういう制度がだんだん出来上がってきました。それよりも前からカオナビの文化を作るために、成長支援のためにいろんな施策をやってきたということがあります。

こういう成長支援の仕組みを充実させた結果、勉強会やカンファレンスに参加する人がめちゃくちゃ増えました。自分が入社したときには4人ぐらいしかカンファレンスに行くメンツがいなかったのが、今20人ぐらいカンファレンスに行くという一大勢力みたいな感じで人がどんどん行くようになりました。登壇することを強く後押ししているので、社外でアウトプットする人も増えましたし、社内の勉強会で喋ってみようかなという人もどんどん増えて、勉強会の枠があっという間に埋まるような感じになっています。そうすると社内に情報が流通するようになって、成長するということが当たり前なんだという環境になったおかげで、学習する人や向上心が高い人が増えたというのもあって、Claude Codeを配っても、これでどうやって自分の仕事のやり方を変えられるかなということを考えてくれる人がたくさん増えました。

まとめ：生産性向上に必要な3つのこと

AIを導入しただけでは、使ってくださいと言ってアカウントを配っただけでは使われないし、どうやって使っていいんだろうと分からない人もたくさんいるので、それだけでは生産性は上がりません。改善するには本当に丁寧なオンボーディングが必要です。ちゃんとドキュメントを整備して、最初にまずこれを読んでねというところからやっていくのが必要です。

ちゃんとそれが効いているのかなというところを数値を見ながら改善して、悪いんだったら何かしら手を打たないといけないし、良いんだったら次どこに向かっていくんだっけということを考えながら、数値を見てどんどん改善していくところが必要です。みんなに使ってもらう、一人に使ってもらうんじゃなくてみんなに使ってもらおうと思うと、社内で知識を広めるような文化みたいな基盤があると情報が流通するようになって、新しくClaude Codeなどを使ってくれる人を増やすためには、そういうところが大事だったりします。

アーカイブ動画・発表資料

イベント本編は、アーカイブ動画を公開しています。また、当日の発表資料も掲載しています。あわせてご覧ください。

▼動画はこちら

※動画の視聴にはFindyへのログインが必要です。