kaonavi Tech Night＃1

2026年7月1日に開催したkaonavi Tech Night＃1で投影した資料です。

Transcript

1. とは ? カオナビのエンジニアが「現場のリアル」をオープンに語る、 ミートアップイベントです！ 選考や面接では伝えきれない、技術的な挑戦・組織の課題・泥臭いリアルまで、 飾らずに共有します。
2. カオナビ‧エンジニア組織の紹介 by CTO松下
3. Speaker Profile @matsukaz / 松下 雅和 （CTO） 業務内容 マルチプロダクトの技術戦略推進 , 技術広報 経歴 SIer → SES → サイバーエージェント → アプリゲーム Startup → 現職 趣味 漫画, アニメ, ゲーム, カメラ, 自転車, 犬, 2児(姉妹)の父
4. タレントマネジメントシステムのパイオニアであり、 国内シェアNo.1※の会社 会社概要 会社名 株式会社カオナビ(英⽂ kaonavi, inc.) 会社設⽴⽇ 2008年5⽉27⽇ 所在地 本社：東京都渋⾕区渋⾕2-24-12 事業開始⽇ 2012年4⽉16⽇ 渋⾕スクランブルスクエア 38F （※⼤阪、名古屋、福岡にオフィスあり） 代表取締役社⻑ CEO 取締役 CFO 佐藤 寛之 橋本 公隆 さとう ひろゆき はしもと きみたか 2003年3⽉ 上智⼤学卒業 2003年4⽉ 株式会社リンクアンドモチベーション ⼊社 2008年5⽉ シンプレクス株式会社 ⼊社 2011年10⽉ 株式会社カオナビ 取締役就任 2012年4⽉ カオナビ事業開始 2022年6⽉ 株式会社カオナビ 代表取締役社⻑ Co-CEO就任 2025年7⽉ 代表取締役社⻑ CEO就任 2004年10⽉ 名古屋⼤学卒業 2004年11⽉ 三洋電機株式会社 ⼊社 2006年4⽉ 三菱UFJモルガン‧スタンレー証券 株式会社 ⼊社 2018年8⽉ 株式会社カオナビ ⼊社 2019年6⽉ 同社 取締役就任 ※出典 ITR「ITR Market View：⼈材管理市場2024」⼈材管理市場：ベンダー別売上⾦額シェア（2015〜2022年度）、SaaS型⼈材管理市場：ベンダー別売上⾦額シェア（2015〜2022年度）
5. Purpose 私たちが社会に対してすべきこと “はたらく ”にテクノロジーを実装し 個の力から社会の仕様を変える 私たちが思い描くのは、性別や学歴といったラベルにとらわれず、 誰もが社会で活躍できる未来。 テクノロジーによって、一人ひとりの個性や才能を深く理解することで、 個人の自由なキャリア形成や多様な働き方が共存する社会に向けて 事業を行っています。
6. タレントマネジメントシステム ⼈事業務の効率化から戦略⼈事の実現まで、 幅広い⽬的で利⽤できるタレントマネジメントシステムです。 https://www.kaonavi.jp/
7. タレントマネジメントの重要性 持続的な企業の成⻑のため、⽣産性向上が求められており、「⼈的資本経営」の重要性が⾼まっています。 最新の⼈材情報を活⽤し、個⼈‧組織の潜在能⼒を最⼤化する「タレントマネジメント」が ⼈的資本経営の中核として重要です。 労働⼈⼝の減少 ⼈材の流動性の増加 技術⾰新 採⽤難‧⼈的資本経営への関⼼ 1⼈ひとりの⽣産性を⾼めることが必要不可⽋に ⼈的資本経営の中核として、個⼈‧組織の潜在能⼒を最⼤化する タレントマネジメントが重要
8. ユーザーとの接点 顧客‧ユーザーとの共創で成⻑する コミュニティづくり 正解がないタレントマネジメントだからこそ、お客様と共に、サービスを 創りあげていくためのコミュニティやイベントを運営しています。
9. Vision パーパス実現のための手段 人材データと AIで個の可能性を拓くデータプラットフォーマーになる 私たちがリードしてきたタレントマネジメントが日本の働き方を革新してきたように、 データとAIの力で人的資本（Talent）に知性（intelligence）をもたらし、 「個」の力を最大限に引き出すプラットフォーマーとして、組織、そして社会を革新し続けます。
10. 開発組織について
11. 数字でわかるカオナビ 事業成⻑に伴い⼈員は年々増加。年代‧性別問わず活躍しています。 最年少管理職 年齢別内訳 50代 社員数 マネージャー 29 歳 1.0% 40代 20.8% 本部⻑ 25.1% 執⾏役員 カスタマーサクセス &サポート 394 32 歳 35 歳 36 歳 部⻑ 20代 職種別内訳 16.8% 名 36.0% コーポレート （正社員） 30代 13.7% セールス＆ マーケティング 53.1% 社員数推移 394 400 350 283 300 リモート ワーク率 管理職 ⼥性⽐率 78.8 26.3 % エンジニア 304 229 250 154 150 111 50 25 33.5% 名 184 200 100 % 本部間の 異動者数 81 34 0 兼業率 20.3 % ʻ17/3 ʻ18/3 ʻ19/3 ʻ20/3 ʻ21/3 ʻ22/3 ʻ23/3 ʻ24/3 ʻ25/3 ⼈的資本の 情報はこちら！ ※2025年3⽉末時点のデータです。 https://universe.kaonavi.jp/
12. 組織体制 プロダクト開発チームの組織体制（全体像） プロダクト プランニング本部 カオナビサービスの企画⽴案や 連携 プロダクト デベロップメント本部 戦略策定及び実⾏‧管理 カオナビサービスの 企画‧開発及び運⽤‧保守 CTO室 ‧横断的な技術施策 ‧新技術の調査、研究 ‧技術広報 ヨジツティクス事業部 各種サポート ヨジツティクスの 企画‧開発、 運⽤‧保守及び営業 AI推進室 基盤提供 ‧⽣成AIをプロダクトに実装 プラットフォーム本部 ‧⽣成AIで業務効率化を推進 ‧AIに関する広報 当社サービスにおける 保守領域の横断的な管理
13. 組織体制 プロダクトデベロップメント本部の組織体制 TalentHRカイゼン部 TalentHRベース部 TalentHRグロース部 CoreHR部 ユーザーの体験向上に つながる開発を通じて、 最短で全社浸透を実現する ⼈事データベース強化に向けた 「お⽫」の機能開発を担う 「お団⼦」の機能群のうち、 市場的に関⼼度の⾼い グロース領域の開発を担う 労務‧勤怠に関する企画、 開発、運⽤を⼀貫して担う 研究開発部 技術基盤部 プロダクトQA部 プロダクトデザイン部 組織戦略推進部 AIやシステム間連携など 新規性の⾼い技術を⽤い、 新たな価値創造をリードする プロダクト全体の開発 及び運⽤を技術⾯でリードし、 ユーザーが安⼼して利⽤できる 基盤を提供する 組織としてナレッジと 専⾨性を蓄積‧進化させ、 品質保証活動を通じて プロダクトの価値を⾼める 再現性のある個のチカラを 結集し、事業‧開発‧顧客を 繋ぐデザインでプロダクトの 価値を⾼める 本部内の 組織開発の推進と 組織運営の改善を実⾏する
14. 使用ツール 開発組織の使⽤⾔語‧ツール バックエンド フロントエンド モバイルアプリ インフラ AI関連 その他
15. 組織体制 スキルアップや学習機会を積極的に⽀援 スナバ ホンダナ 兼業推奨 週2時間、⾃由に使える 未来のための⾃⼰研鑽タイム ⽉に1冊、開発に関わる書籍を ⾃由に購⼊できる⽀援制度 カオナビの仕事以外での経験を通じた⾃⼰研鑽を応援 イベント登壇‧協賛‧参加⽀援 プロダクト組織の兼業率 23.2 % ( 2025年3⽉末⽇時点） 社内勉強会 イベントへの登壇‧スポンサー実績 年間開催回数 kaonavi Tech Talk 社内/社外向けプロダクト組織の勉強会＠YouTube Live Check！ check ! イベント申し込み 過去イベントアーカイブ note カオナビ技術広報 https://note.com/kaonavi_devs/ （2025年度実績） 25 回 ▪技術記事を書いたらLaravelにコントリビュートできた話 ▪Github Copilot に レビュー基準を詰め込んでレビューさせてみた ▪QAエンジニアへPlaywrightを布教して⾃動化 ▪GoとPHPのインターフェイスの違い 株式会社カオナビの技術や、開発、エンジニアにまつわることを発信していきます。
16. 働き方に関する制度 My Work Style ⾃分に合った働き⽅を⾃由に選ぶことができ、働く場所と時間に縛られることはありません。 ハイブリッド勤務 スイッチワーク 一人ひとりがベストな環境でパフォーマンスを 私用で2時間抜けるなど勤務時間とプライベート 発揮できるよう、勤務場所は自分で選択可能。 の時間を柔軟に切り替え可能です。 場所に縛られない働き方ができます。 5:00 フ レッ クス タイ ム スーパーフレックス 自律した働き方の確立や、仕事とプライベートの 4h 両立に向け、出退社時刻と勤務時間（ 1日4時間 以上）を自分で設定可能。自由度の高い働き方 22:00 ができます。 ON/OFF 20 フレックス ±20時間 月内で労働時間に ±20時間の幅を設け、各自で 労働時間を調整することが可能です。
17. ショートセッション
18. ショートセッション① 「noUncheckedIndexedAccess、 3時間、1万円。」 by uhyo(鈴⽊ 僚太)
19. Speaker Profile @uhyo / 鈴木 僚太 （フロントエンドエンジニア） 業務内容 エキスパート（フロントエンド） 開発環境の整備、開発効率改善、 設計改善など 経歴 LINE → バベル → カオナビ 趣味 アニメ、ゲーム、プログラミング ゲームは任天堂派
20. noUncheckedIndexedAccess、 3時間、1万円。 2026.06.10 © kaonavi, inc.
21. 今日の発表内容 noUncheckedIndexedAccessは、TypeScriptコードの 型安全性に寄与する重要なコンパイラオプションです。 しかし、特に昔からやっているプロジェクトでは、この オプションをオンにしていない ことが多くあります。 © kaonavi, inc.
22. 今日の発表内容 noUncheckedIndexedAccessを、プロジェクトの途中から オンにすることはとても大変なことでした。 しかし、今は違います。 弊社では、AIに1万円課金することで3時間で有効化を完了するこ とができました。 （ただし、とりあえず型エラーを抑制しただけで、根本解決は引き続き） © kaonavi, inc.
23. noUncheckedIndexedAccessとは インデックスシグネチャ による要素アクセスについて、 結果に自動的にundefined型を含める機能。 // arr: number[]; obj: Record<string, string> // noUncheckedIndexedAccess なしの場合 const num = arr[100]; // number const str = obj.foo; // string © kaonavi, inc.
24. noUncheckedIndexedAccessとは インデックスシグネチャ による要素アクセスについて、 結果に自動的にundefined型を含める機能。 // arr: number[]; obj: Record<string, string> // noUncheckedIndexedAccess ありの場合 const num = arr[100]; // number | undefined const str = obj.foo; // string | undefined © kaonavi, inc.
25. 有効化はとても大変 従来undefinedの可能性を考慮していなかった箇所で、 undefinedの可能性が出現する。 undefinedの可能性を考慮した型に直さないと型エラーが 発生。 弊社アプリでは数千件の型エラー が！ © kaonavi, inc.
26. 有効化はとても大変 型エラーの例: © kaonavi, inc.
27. 対応方針① 根本対応はランタイムも含めた直しが伴うが、 それだと永遠に終わらない。 そこで、!を使った暫定対応 で型エラーを消すことを目標と する。 © kaonavi, inc.
28. 対応方針① 暫定対応で型エラーを消した↓ © kaonavi, inc.
29. 対応方針② 数千件のエラー箇所に手で!を付けて回るのは厳しい。 エラー発生箇所 ＝ ! 付与箇所ではない ため、 スクリプトでの自動修正も困難。 © kaonavi, inc.
30. 対応方針② それならAIに修正してもらおう ！！！ （弊社はClaude Codeを主に使用しています） © kaonavi, inc.
31. 対応方針② しかし、単純にAIに「数千件のエラー全部直して！ 😁👊」 と頼むだけだと、時間と金がとてもかかる ことが予想される。 そこで、ファイル単位でサブエージェントにアサインする 方法を考えた。 （当時はAgent Teamsもworkflowもまだ無かったよ！） © kaonavi, inc.
32. 具体的な方法 大量に出力された型エラーを、ファイル単位で分解 し、 別々のファイルに書き込む。 （foo.tsの型エラーを記録したファイル、bar.tsの型エラーを 記録したファイル……が生成される） （もちろんAIがそのためのスクリプトを書きました） © kaonavi, inc.
33. 具体的な方法 ファイルごとにサブエージェントを起動し、 「このファイルの型エラーを!を使用して修正して！」と 依頼する。 数百件のサブエージェント が起動することになる。 © kaonavi, inc.
34. ポイント : コスト削減 ファイル単位でサブエージェントに分解することで、 各エージェントのコンテキストの最小化 を図る。 さらに、ファイル単位のタスクは十分に単純なので、 モデルとしてHaikuを使用。 © kaonavi, inc.
35. ポイント : 終了判定 各サブエージェントに、「エラーの修正が完了したら担当の エラーメッセージファイルを消去 する」と指示した。 これにより、サブエージェントの作業が終わったかどうかを 「ファイルが消えているかどうか 」で判定できる。 リトライ性も高い。 © kaonavi, inc.
36. 結果 大量のサブエージェントが起動し、数十分程度 で全エラーの 修正が自動的に行われた！ このあと検証なども含め、作業時間の合計が3時間くらい。 AI代はHaikuの利用が功を奏したのか、1万円以内 になった。 © kaonavi, inc.
37. うまくいかなかった点 Haikuに「!を使用してエラーを修正して」と指示したら、 !!obj[key] のような修正をしてきた。とんちか？ また、数カ所指示に反してランタイムの修正をしてきた 箇所もあった。（その後の検証作業で検出） Haikuの使用はケチりすぎたかも？ © kaonavi, inc.
38. まとめ noUncheckedIndexdedAccessの有効化は、 昔はすごく困難な仕事でしたが、 AIを活用すれば3時間で終了するタスクになりました。 まだ有効化していない人は明日有効化しよう！ © kaonavi, inc.
39. ショートセッション② 「インフラエンジニア、プロダクトチームへ留学中」 by ⽔⾕ 圭佑
40. Speaker Profile 水谷 圭佑 （インフラエンジニア） 業務内容 「カオナビ採用」の開発・運用 経歴 SIer → カオナビ 趣味 美術館に行く おもしろクラフトビール探し 飼い猫に構っていただく
41. 「留学」 この発表においては、以下のことを指します インフラエンジニア（私）がプロダクトチーム（機能開発チーム）に所属 フロントエンド‧バックエンドの実装をはじめとした開発業務に携わること
42. 話すこと インフラエンジニアとしてのこれまでの活動 「留学」の動機とやったこと 「留学」で得たこと 話さないこと Claude Code を含めた Coding Agent の活⽤事例
43. 2023年: インフラエンジニアとしてのお仕事 当時活動していた組織では、職能でチームが分かれていた 機能開発チーム / インフラチーム 私の仕事（のひとつ）は、機能開発チームからのインフラ実装や変更の依頼に対 応すること 機能開発チームとのコラボレーションは基本的に依頼ベース 具体的な実現⽅式を考えて提案し、実装に落とすことが求められる 機能開発チーム側で、具体的なAWSサービスの選定などが済んでいることも この場合、やることはほぼ Terraform 書くだけ
44. 2023年: 考えていたこと クラウドがインフラの抽象化を推し進め、開発者がインフラを扱う障壁は低下 ⽣成 AI がさらにその勢いを加速させる予感がしていた インフラエンジニアとしての⾃分の存在意義ってなんだろう
45. 2023年: 考えていたこと インフラエンジニアとしてご飯を⾷べていくには インフラエンジニアとしてさらにレベルアップする？ 他分野のスキルを獲得してクラスチェンジする？ 例えば SRE 本で紹介されている Google の SRE のスキルセットは、ソフ トウェアエンジニアのそれを前提としている バックエンドもできれば強みになりそう
46. 2024年: 新規プロダクトチームに参画 「カオナビ労務」のリリース後にインフラエンジニアとして加⼊ いくつかあったインフラ領域の課題を少しずつ解決していくことができた ⼩規模なチームだったからこそ、インフラに限らずより広い領域を⾒ることがで きた バックエンドの⼩さな改善タスクにも少し挑戦することができた ⼀⽅で、インフラだけでは解けない信頼性にかかわる課題が多く残った データベース設計の根本的な⾒直し アプリケーションのスケーラビリティ改善 時間ベースの処理や待ち合わせ → ⾮同期処理への置き換え
47. インフラだけでは解けない課題 インフラ観点の問題解決しかできないと 局所最適になりやすい 信頼性を向上するためには ユーザに近い機能仕様‧アプリ観点 での 問題も解決できる必要がある ⾃分だけでできる必要はないが 基本が 出来るだけで コミュニケーションの質は 格段に上がる https://speakerdeck.com/sansantech/20250711
48. 2025年: プロダクトチームへ「留学」 「カオナビ採⽤」の開発チームに加⼊ ソフトウェアエンジニアのメンバに混ざって実装タスクを担当 個⼈としてはアプリケーション開発のバックグラウンドはほぼなし 当たり前だが分からないことだらけ Claude Code も活⽤して、なんとかついていった 気付いたらバックエンド/フロントエンドの実装を何とかやれている API を実装して画⾯を実装して、1ストーリーを⼀⼈でDone 実際にチームに⼊って体験することで、機能開発の全体像が⾒えるようになった
49. 2025年: プロダクトチームへ「留学」 兼務のインフラエンジニアとして、他機能開発チームの⽀援も引き続き担当 新機能の開発にあたってインフラに関する相談を受けた 開発チームで検討している内容を先回りしてインプットしたうえで会話がで きた PRD や Figma を⾒て要件や画⾯遷移を把握 実現したい価値に対して、アプリケーション設計も含めた複数の選択肢 を提案することができた 様々な場⾯で、インフラ観点に閉じない思考やコミュニケーションが取れるよう になってきている実感がある
50. 2026年: プロダクトチームへ「留学」中 「カオナビ採⽤」のファーストリリース 新規機能の開発中、引き続きバックエンドを中⼼に実装も担当 インフラ基盤や監視運⽤の整備を⾃⾝が中⼼となって進めている これからチームで運⽤が進められる体制を整えていく 今後の私がどうなっていくかは、またどこかの機会で
51. ショートセッション③ 「迅速な機能提供をするためのスクラム改善」 by 平⼭ 涼也
52. Speaker Profile 平山 涼也 （フロントエンドエンジニア） 業務内容 ポジションマッチングの機能開発 カオナビのFE Tech Lead 経歴 ヤフー→グロービス→コドモン→ estie→東急→カオナビ （フリーランスの経験もあります。） 趣味 一人飲み、旅行、 ポッドキャスト配信、読書
53. Contents • 当時のプロジェクト状況 • 実施した改善 • 改善した結果 • 現在の状況・今後の展望
54. 当時のプロジェクト状況
55. 当時のプロジェクト状況 その前に…当時の私の近況について • 昨年の10⽉に中途として⼊社 • 昨年の12⽉に、今回紹介するチームにアサインされる • アサインされる前までは、別チームでオンボーディングを受ける
56. 当時のプロジェクト状況 1つの機能の追加‧改修の平均リードタイム
57. 当時のプロジェクト状況 178⽇
58. 当時のプロジェクト状況 チームの10⽉、11⽉の機能リリース数
59. 当時のプロジェクト状況 0件
60. 当時のプロジェクト状況 タスクの優先度の状況
61. 当時のプロジェクト状況 不明瞭
62. 当時のプロジェクト状況 リリースまでのリードタイム 10⽉、11⽉のリリース数 タスクの優先度状況 ⼀つの機能追加‧改修の企画が チーム全体で開発⾃体は⾏って KPI に沿ったユーザーストーリー ⽴ち上がってからリリースする いるにも関わらず、機能リリー よりも、リリース数を上げるた までのリードタイムの平均が178 スの数が0件だった。 めのチケット作成に注⼒してい ⽇だった。 て、優先度が頻繁に変わってい た。
63. 実施した改善
64. 実践した改善 スモールリリースの実践
65. 実践した改善 追加‧編集‧削除まででリリース
66. 実践した改善 その後、CSVの機能をリリースする形へ
67. 実践した改善 リリースを分割することによって…
68. 実践した改善 AI機能を並⾏開発して追加リリース！
69. 実践した改善 リファインメントの⼆段構え化
70. 実践した改善 リファインメントの正常化 エンジニアだけの リファインメントを設置 リリース数増加のためにエンジニアがリファ バグ修正やリファクタリングなど、技術的負 インメントを主導していた状態をPdM主導に 債や保守に関するタスクの優先度をエンジニ 変えて、ストーリーの背景‧受⼊条件‧優先 アが判断する場を設け、エンジニアメンバー 度を共有してチーム全体で認識を揃えられる 全体でタスクの優先度の認識が擦り合うよう 形へ変更 に変更
71. 実践した改善 バックログ運⽤の整理
72. 実践した改善 バックログのオーナーをPdMへ 開発タスクの優先度調整の改善 エンジニアが⾃由に優先度を⼊れ替えていた ユーザーストーリーの優先度をバックログで 状況から、PdMがKPIを考慮した上で優先度 表現できるようになったため、その優先度を を決めて表現できるように、PdMが優先度の ベースにしつつリファクタリングやバグ修正 ⾼いユーザーストーリーをバックログの上部 の優先度調整をバックログやスプリント上に に移動させ、チーム全体で優先度をいつでも 可視化しやすくなったため、開発タスクが取 把握できるように変更。 り組みやすい形になった。
73. 実践した改善 デイリースクラムのスクリプト変更
74. 実践した改善 チケットベース報告 スイムレーンの導⼊ タイムラインの活⽤ チームメンバーが1⼈ずつ報告す サブタスクがある場合、タスク Jiraのタイムラインを活⽤し、⾃ る形から、タスクごとに報告す の実施漏れがあったり、連携の 分たちが決めているリリース⽇ る形に変更。 漏れが発⽣することが多い。 に間に合うかを確認できるよう 「⼈」から「事」に関⼼事が移 そのため、サブタスクも進捗確 に変更。 ⾏することで、⼈を管理してい 認がしやすいスイムレーンを導 間に合わなさそうであれば他の る印象が和らいで報告者の⼼理 ⼊してその時点でのタスク状況 タスクをスプリントから落とす 的ハードルが下がり、報告しや が把握しやすい形に変更するこ など、優先度をベースにした調 すい形へ。 とで、他のメンバーがヘルプに 整をチーム内で⾏いやすい形 ⼊りやすい形へ。 へ。
75. 実践した改善 スクラムボードの スイムレーン タイムライン
76. 改善した結果
77. 改善した結果 通常案件リリースリードタイム
78. 改善した結果 137⽇ →69⽇ 🎉
79. 改善した結果 約50%短縮 🎉
80. 改善した結果 通常案件リリース数
81. 改善した結果 改善前は、10⽉‧11⽉で「0件」
82. 改善した結果 1⽉〜3⽉ 8件リリース🎉
83. 改善した結果 さらに、1⽉末からこのチームが分裂して そのもう⼀⽅のチーム側で…
84. 改善した結果 10件リリース🎉
85. 改善した結果 両チーム合計で 18件リリース🎉
86. 現在の状況‧今後の展望
87. 現在の状況・今後の展望 現在は、今紹介した2チームのリリース数が 部の中で1,2位の状態をキープ💪
88. 現在の状況・今後の展望 ただし、リリースが増えただけでは 事業は伸びない
89. 現在の状況・今後の展望 ユーザーフレンドリーで 売上に繋がるプロダクトづくりが求められる
90. 現在の状況・今後の展望 お客さまと会う‧話す 数値⽬標への関⼼ リファクタリングの余⽩作り 実際にご利⽤いただいているお 事業成⻑に繋がるKPIを意識しな 機能リリースに関⼼が⾏き過ぎ 客さまとの定例会に赴き、実際 がら機能開発ができる⽂化の醸 てしまうと、保守の観点が抜け の課題感をお聞きして、プロト 成を検討。 やすくなり、将来の⾃分たちの タイプをベースにしながら機能 まずはリリース速度をKPIに置い ⼯数を奪っていくことになる。 要件を決めていく形へシフト。 ているが、簡単な案件を量産し 機能リリースを意識しながら、 現在1チームが実際にその動きを て数字を稼げてしまって本質的 どこまでリファクタリングに時 実践中。 ではないため、ビジネスを意識 間を割けるようにしていくかが したチームを増やすことが今後 現状抱えている課題の⼀つ。 の課題。