■ 1. 問題提起: AIを使っても生産性が上がらない理由
- SmartHR勤怠管理チームでは以前からAI活用を推進し、個人レベルでの活用は浸透していた
- しかしチーム全体の生産性向上は実感できなかった
- AIによるコード生成が速くなっても、前後の開発プロセス（アイテム分割・整理、コードレビュー、動作確認）は従来のままであり、ボトルネックは解消されなかった
- 問いを「AIで既存業務をどう効率化するか」から「AIがいる前提で開発プロセスはどうあるべきか」に転換し、ゼロベースでの再設計に取り組んだ
■ 2. プロジェクト体制の設計
- 4つの開発チームのうち1チームを2026年4月から3か月間の実験専用パイロットチームとした
- 下期に全チームへ展開する計画
- チームのミッション:
- 「開発生産性を2倍にすること（1チームで開発できる開発アイテムの量を2倍にすること）」と設定
- 内部品質（コード・設計の品質）・外部品質（ユーザーから見た振る舞いの品質）は従来と同等水準を維持する前提
- 実験環境の整備:
- ビジネスサイドと調整し、「パイロットチームの機能開発が1つも完了しなくてもよい」と明言した
- クォーター終了時点でAIネイティブな開発プロセス・体制に移行できるかどうかでプロジェクトを評価する扱いとした
- この前提を関係者全員で共有したことで大胆な実験が可能な土台が整った
■ 3. 実験ループの設計
- 判断基準となるポリシーを明文化し、チームの意思決定の軸を統一した
- 既存のプロセスにとらわれず逆算する（「本当に必要なものは何か」から考える）
- インパクトとレバレッジにこだわる（効果が薄いと感じたら実施中でも中断する）
- 仮説を立て、検証し続ける（やりっぱなしにしない、学びの質を重視する）
- わかりやすいレポートを出し続ける（AIが書いたレポートをそのまま渡さず、人間の言葉で説明責任を果たす）
- 仮説→実験→評価→レポートのサイクルを設計した
- 蓄積した仮説からインパクトが大きいものを選び、実験テンプレートに沿って設計する
- プロジェクト初期はペアやモブでの実験を積極的に行う
- 毎朝の朝会を長めに設け、細かい単位で振り返りを行う
- 短期プロジェクトのため評価指標整備に時間をかけすぎず、定性的な評価でプロジェクトを推進した
■ 4. 実験から見えてきた3つの方向性
- AIの進化で解決される領域には注力しすぎず、モデルがどれだけ進化しても残り続ける課題にリソースを集中する方針
- 人と人のコミュニケーションのオーバーヘッドを解消する:
- AIが実装・検証を担えるようになるほど、レビューや仕様確認などの人間同士のコミュニケーションがボトルネックになった
- 取り組んでいる実験として「実装都合の単位でのIssue分割の廃止」「クラウド上で動くAIエージェントを用いた実装業務の脱個人化」「暗黙知の形式知化」の3つがある
- 開発チームの自律性を高めるため、専門職能のイネイブリングや品質面でのポリシー策定も進めている
- まず小さい機能開発で仕組みを固める:
- 機能の複雑度や専門度によってAIに任せられる範囲が大きく変わることが判明した
- SmartHR勤怠管理の開発アイテムの55%は2週間程度で完了する小規模なアイテム
- まず小規模アイテムを安定して消化できる仕組みを構築し、精度を上げてから大規模アイテムに展開する戦略をとる
- 改善を正しく評価する仕組みを整える:
- AIの出力を評価する基盤の構築:
- AIエージェントの出力の信頼性・コストが問題となり、品質フィードバックが複数ツールに分散することでスケールしないことを実感した
- 現在はAIエージェントやSkillの出力を体系的に評価する基盤づくりに取り組んでいる
- 当面はSkillの乱立を許容し、評価の仕組みが整い次第AIに自己改善ループを回させる方針
- プロセス改善の方向性の可視化:
- VSM（バリューストリームマッピング）を用いて開発プロセス全体を可視化し、改善の方向性の合意や改善対象の選択に活用し始めている
■ 5. まとめ
- 「開発生産性2倍」にはまだ到達できておらず、顧客価値の最大化にも十分向き合いきれていない状況
- 実験を重ねる中で「人間同士のコミュニケーションの再設計」「規模別アプローチの使い分け」「改善を正しく評価する仕組み」の3つのテーマに焦点が定まった
- 「機能開発ゼロでもOK」というメッセージングと、仮説→実験→評価のサイクルにより「失敗しても学びが残る」構造が大胆な実験を可能にした
- 具体的な実験・学びの詳細は後続のブログ記事で発信予定