AIネイティブな開発プロセスへの移行、はじめました — SmartHR勤怠管理の開発チームの取り組み

SmartHR 勤怠管理の開発チームでプレイングマネージャーをしているtkkrです。

2026年の4月から、開発プロセスそのものをAI前提で再設計する「AIネイティブ開発化」というプロジェクトを進めています。AIツールを導入して業務を効率化するという話ではなく、既存の開発プロセスを一度壊して、AIがいる前提で作り直すという取り組みです。

今回の記事では、なぜそんなことを始めたのか、どうやってプロジェクトを設計したのか、そしてプロジェクトで大切にしている考え方を共有します。具体的な実験の詳細や学びについては、後続の記事で共有していく予定です。

AIを使っているのに、なぜ速くならないのか

勤怠管理チームでは、以前からAI活用を積極的に進めていました。Skill の整備もされ、個人レベルでの活用はかなり浸透している状況でした。私自身も、ここ半年は自分の手でコードを書くことはほとんどなくなっていました。

しかし正直なところ、チーム全体の生産性が目に見えて上がった実感はありませんでした。

AIがコードを速く書いてくれても、その前後の開発プロセス（開発アイテムの分割・整理、コードレビュー、動作確認）は従来のままです。ボトルネックが開発プロセス自体にある限り、部分的に速くしても全体のスループットは変わりません。

「AIで既存の業務をどう効率化するか」ではなく、「AIがいる前提で、開発プロセスはどうあるべきか」に問いを変え、既存プロセスの改善ではなく、ゼロベースでの再設計に取り組むことにしました。

プロセスの再設計の専任チームを設ける

「AIがいる前提で、開発プロセスはどうあるべきか」という問いに向き合うために、1つのチームを「実験専用」にして、開発プロセスの再設計に集中的に取り組むプロジェクトを立ち上げました。

実験に集中できる環境がないと、既存業務との板挟みで攻めの改善が難しくなると思ったので、チーム体制とメッセージングの両面で環境を整備しました。

複数の開発チームのうち、1チームを実験専用のパイロットチームとして扱う

SmartHR勤怠管理は4つの開発チームで運営しています。全チームで一斉にプロセスを変えるのはリスクが大きいので、1チームをパイロットチームとして2026年4月から3か月にわたって集中的な実験を行い、下期にチーム全体へ展開する計画としています。

チームのミッションは「開発生産性を2倍にすること(1チームで開発出来る開発アイテムの量を2倍にすること)」に設定しました。本来は、開発生産性の評価としては、ユーザー価値の最大化をターゲットとして置くべきですが、まずは明らかに伸びしろのある開発量を設定することにしました。

なお、内部品質（コード・設計の品質）も外部品質（ユーザーから見た振る舞いの品質）も、これまで人間が担保してきたものと同等の品質を前提としており、速度のために犠牲にすることなく進めることとしています。

2026年7月までに最速の状態に到達できるのであれば、機能開発が1つも終わらなくてもよい

勤怠管理チームでは、これまでも機能開発と並列しながら一部のメンバーがAI活用についてのサイドミッションを持つことで、活用を推進してきました。しかし、これまでの活動では思うような抜本的な改善を産むことが出来ていませんでした。

これを受けて、「実験しながらも通常通りの成果を求められること」というプレッシャーを取り除き、リスクを取った実験がしやすい状況を作ることにしました。

ビジネスサイドとも調整し、「このクォーターではパイロットチームの機能開発が1つも完了しなくても構わないので実験を優先して良い」と明言し、クォーターが終了した段階で勤怠管理チーム全体でAIネイティブな開発プロセス・開発体制に移行できるかどうかでプロジェクトを評価するという扱いにしました。この前提を関係者全員で共有できたことで、大胆な実験を可能にする土台を作ることが出来ました。

密度の高い実験ループを回す

大胆な実験ができる環境を整えたうえで、探索の質を上げる仕組みを設計しました。

環境が整っても、「何をやるか」「どう進めるか」が曖昧だと探索の質は上がりません。そこで、判断の軸となるポリシーと、進め方の型となる実験サイクルの2つを用意しました。

ポリシーを明文化し、チームの意思決定の軸を揃える

探索的なプロジェクトは方向が散りやすく、世の中にはすぐ飛びつきたくなるアイデアが沢山あります。チーム全員で同じ方向を向いて意思決定できるように、判断基準となるポリシーを策定しました。

ポリシー	一言でいうと
既存のプロセスにとらわれず逆算する	「これまでこうだった」ではなく「本当に必要なものは何か」から考える
インパクトとレバレッジにこだわる	効果が高いものから着手し、薄いと感じたら実施中でも中断する
仮説を立て、検証し続ける	やりっぱなしにしない。学びの質を重要視する
わかりやすいレポートを出し続ける	実験チームが閉じない。AIが書いたレポートをそのまま渡さない

4つ目のレポートに関するポリシーは、実験チームが社内で孤立しないための仕掛けでもあります。「AIが書いたレポートをそのまま渡す」をNGとしているのは、AIネイティブ開発を推進するプロジェクトだからこそ、人間の言葉で説明責任を果たすことを大事にしたかったためです。

仮説→実験→評価→レポートのサイクルで、「なんとなく良さそう」だけでだらだらと施策を進めない

限られた時間で成果を出していくために、序盤はあえて固めに仮説ドリブンの実験サイクルを設計しました。

まず仮説の定義を決めました。「ある要因に介入すると、ある結果が起こるはずだという予測」です。

例: 「現在の開発アイテムは実装都合で分割されており必要以上に小さい。より大きな単位で開発すれば、リードタイムを短縮できるかもしれない」

蓄積した仮説からインパクトが大きそうなものを選び、実験テンプレート（背景・実施内容・確かめたい仮説・リスク仮説・評価観点）に沿って設計し、実験→評価→レポートのサイクルを回します。

また、この仕組みを運用するにあたって、評価や向き直りを高速に行うために、「プロジェクト初期はペアやモブでの実験を積極的に行うこと」や「毎朝の朝会を長くとり、細かい単位で振り返りを行うこと」を意識しました。

実験の評価をするにあたって、定量的な評価指標も重要ですが、短期的なプロジェクトにおいては評価指標を整えることに時間を割き過ぎるわけにもいかないため、定性的な評価を元にプロジェクトを推進していける状態を保ちました。

実験を重ねて見えてきた3つの方向性

わずか一年前と比べても、コードの調査・設計・実装におけるAIの精度は遥かに進化しており、この進化はこれからも続くと見ています。だからこそ、「AIが情報にたどり着く」「手元の情報から良いアウトプットを出す」といったモデルの進化で解決されていく領域にはあえて手をかけすぎず、モデルがどんなに進化しても残り続ける課題にリソースを集中することを意識しています。

その考え方のもとで、現時点で重要だと見ているのが以下の3つです。

人と人のコミュニケーションのオーバーヘッドを解消する

仮説を立てて複数の実験を重ねるうちに見えてきたメインテーマは、人間同士のコミュニケーションのオーバーヘッドをいかに削減・効率化するかでした。開発アイテムの分割・整理、コードレビューでのラリー。これらは本質的に「人間が人間にタスクを受け渡すための仕組み」です。AIが実装や検証の多くを担えるようになり、実装が速くなるほど、レビューや仕様確認などの人間同士のコミュニケーションがボトルネックとして浮き彫りになりました。

現在は以下の3つの実験を中心として、コミュニケーションコストの削減に取り組んでいます。

実装都合の単位での Issue 分割の廃止
クラウド上で動くAIエージェントを用いた実装業務の脱個人化
暗黙知の形式知化

各実験の詳細は後続の記事でお伝えします。

これらに加えて、AIの活用に限らない開発チームのコミュニケーションの改善にも取り組んでいます。細かなUIや仕様の意思決定のたびに専門職能を呼ぶコストは高く、同期コミュニケーションに頼り切るとスケールしないため、開発チームの自律性がより重要になることを痛感しています。開発チームへの専門職能のイネイブリングや、品質面でのポリシー策定など、チームが自律的に判断できる範囲を広げる取り組みも進めています。

まず小さい機能開発で仕組みを固める

実験を重ねる中で、機能の複雑度や専門度によって、AIに任せられる範囲が大きく変わることを実感しました。特に深いドメイン知識が必要な開発アイテムでは、AIへのインプットを正しく作る仕組みやアウトプットを評価する仕組みを整えるコストが大きくなり、仕組みづくりのコストパフォーマンスが合わないケースも出てきます。

SmartHR勤怠管理の開発アイテムのサイズ分布を見ると、過半数（55%）が2週間程度で開発が完了する小規模なアイテムです。一方、2か月以上かかる大規模な機能も約6%存在します。いきなり全てに適用するのではなく、まずは過半数を占める小規模な開発アイテムを安定して消化できる仕組みを作ることに集中し、そこで精度を上げてから大きな開発アイテムに展開していく戦略です。

改善を正しく評価する仕組みを整える

プロセスの再設計を進めるうえで、「改善を正しく評価する仕組み」の重要性が増しています。これはAIの出力の評価と、プロセス改善そのものの評価の2つの側面があります。

AIの出力を評価する基盤を作る

AIエージェントに業務を任せるようになると、「その出力はどの程度信頼できるか」や「正しい出力が出せるまでにどれくらいのコストが掛かったか」が避けて通れない問題になります。実験の中でも、品質に関するフィードバックが複数のツールに分散し、評価を人手で回すのではスケールしないことを痛感しました。現在はAIエージェントやSkillの出力を体系的に評価する基盤づくりに取り組んでいます。

また、現段階ではあえてSkillの乱立を許容し、まずSkillが作られること自体を推進しています。評価の仕組みが整ったら、AI自身に自己改善のループを回してもらうというスタンスです。

プロセス改善の方向性を可視化する

プロジェクト当初は明らかにインパクトが大きそうな課題が目に見えていたため、「何をやるか」の判断に困ることはありませんでした。しかしプロジェクトが進むにつれ、またAIネイティブ化に関わる関係者が増えるにつれ、「今何に改善の余地があり、どこから手をつけるべきか」を関係者全員で認知できることが重要になってきました。現在はVSM（バリューストリームマッピング）を用いて開発プロセス全体を可視化し、改善の方向性の合意や改善対象の選択に活用し始めています。

おわりに

プロジェクトはまだ道半ばで、「開発生産性2倍」にはまだ到達できていませんし、本来追うべき顧客価値の最大化にまではまだ向き合いきれていません。ただ、実験を重ねる中で、最初に目指すべき方向性は見えてきたと思っています。モデルの進化に任せられる領域とそうでない領域を見極め、人間同士のコミュニケーションの再設計・規模別のアプローチの使い分け・改善を正しく評価する仕組みという、3つのテーマに焦点が定まってきました。

既存のプロセスを壊すのは勇気がいります。それなりにうまく回っているプロセスであればなおさらです。それでも踏み切れたのは、「機能開発ゼロでもOK」というメッセージングと、仮説→実験→評価のサイクルによって「失敗しても学びが残る」構造を作れたからだと思います。

このプロジェクトの具体的な実験や学びについては、引き続きこちらで発信していくので、後続のブログ記事もご確認いただけますと幸いです！