はじめまして。Contract One Engineering Unitで部長をしている大島です。2025年6月にチームにジョインしたので、もうじき1年になります。この1年でContract OneもContract One Engineering Unitも大きく成長しました。
今回はARR（Annual Recurring Revenue／年間経常収益）10億円達成し、さらに勢いを増すContract Oneを支えるべく、開発組織として日々向き合っている、生産性向上について書きたいと思います。
- 個人技の限界——「速い人」がいるだけでは組織は変わらない
- TPS——製造業が教えてくれた「仕組みで勝つ」構造
- 標準化——「何が正常で、何が異常か」を定義する
- 自働化——8フェーズのすべてで、異常を即検知し、止め、共有する
- カイゼン——標準化を更新し、ループを一段上げる
- おわりに——AIが活躍できる面積を広げ続ける
- Sansan技術本部ではカジュアル面談を実施しています
個人技の限界——「速い人」がいるだけでは組織は変わらない
私がジョインした2025年6月より前から、チームはAI活用と向き合ってきました。今となっては当たり前のことですが、2025年6月には生成AI縛りで開発を行う、LLM Weekを行いました。その取り組みは以下にまとめています。
その後も継続的にAI活用を進めてきました。プロンプトの工夫、コンテキストの渡し方、AIとの対話の流儀——それぞれが自分なりのやり方を模索しながら、確かな手応えを掴み始めていました。気がつけば2倍、3倍のスピードで仕事を回せる人が出てきました。
しかし組織全体を見渡すと、どうでしょう。生産性は思ったよりも上がっていないのです。これは私たちだけの課題ではありません。DORAレポートでも、AIは個人の有効性を大幅に向上させる一方で、組織・製品レベルのパフォーマンス向上は限定的であると報告されています。
さらにDORAは、AIは「魔法の杖」ではなく、組織の既存能力を反映し増幅する「鏡」であると指摘しています。つまり、プロセスや標準が整っていない組織でAIを導入しても、その混乱が加速するだけなのです。
チーム全体の生産性を変えたいなら、個人の習熟を組織の標準に変えることが大事なのです。
TPS——製造業が教えてくれた「仕組みで勝つ」構造
個人の習熟を組織の標準に変えるにはどうすればいいか——この問いに向き合ったとき、私が立ち返ったのは製造業の知見でした。私はもともと、自動車メーカーでソフトウェアエンジニアをやっていました。その時学んだ、大好きな概念の1つにトヨタ生産方式（TPS）があります。複数の部門と人が関わる生産ラインで、品質と速度を両立させてきたこのフレームワークは、「チーム全体でAI活用を標準化する」という私たちの課題にそのまま適用できると考えました。TPSの構造はシンプルです。
標準化が土台にあり、その基準のもとで自働化が機能します。自働化とは、単に作業を自動化するのではなく、異常が起きたら即座に検知して止まれる仕組みを組み込むことです。そして自働化の実践から得られた学びがカイゼンとして標準化にフィードバックされ、ループが一段上がります。当時は「制約が多いな」と感じることもありましたが、今になってその本質がよくわかります。なぜAI活用にTPSなのか。それには4つの理由があります。
- ソフトウェア開発との親和性が高い
- 自働化がハーネスエンジニアリングと驚くほど重なる
- 標準を常にアップデートし続ける仕組みがAI活用と相性が良い
- 組織全体での標準化に対する知見が豊富
順に説明します。
ソフトウェア開発との親和性が高い
TPSはアジャイル開発の源流です。スクラムの生みの親であるジェフ・サザーランドもTPSから強い影響を受けています。つまりTPSの考え方は、私たちが日常的に実践しているものの原型であり、未知の概念ではありません。
自働化がハーネスエンジニアリングと驚くほど重なる
2026年2月頃から爆発的に広がったハーネスエンジニアリングは、AIの不確実性をハーネスでコントロールし、誰でも同じ品質で再現できる“型”として活用するアプローチです。異常を検知して止める仕組みを組み込み、人間の判断を要所に残す——これはまさにTPSの自働化そのものです。別々の文脈から生まれた2つの考え方がここまで一致するのは、本質的に正しいアプローチだからだと感じています。
標準を常にアップデートし続ける仕組みがAI活用と相性が良い
AI活用の世界では、ツールもベストプラクティスも日々変化します。「一度決めたら終わり」の標準では、すぐに陳腐化してしまいます。TPSのカイゼンは、標準を固定するのではなく、例外が出るたびに更新し続けることを前提とした仕組みです。この「標準は生き物である」という発想が、変化の激しいAI活用の現場にぴったり合います。
組織全体での標準化に対する知見の豊富さ
ソフトウェア開発の生産性改善は、個人やチーム単位で語られることが多いです。しかし実際の開発は、企画・設計・実装・QA・運用と複数の役割が関わるラインです。TPSは複数の部門と人が関わる生産ラインを何十年もかけて最適化してきた知見の塊です。「個人の工夫を組織の仕組みに変える」という私たちの課題に対して、これほど実績のあるフレームワークは他にありません。
私たちはこれまで、チームの生産性を最大化するためにスクラムをベースとしたソフトウェア開発を行ってきました。しかしAI活用が進むにつれ、スクラムのプラクティスの一部は少しずつ不要になってきていると感じています。AIがコードを書き、レビューを補助し、テストを生成する世界では、従来のスプリント単位の進め方が最適とは限りません。
一方で、スクラムの源流であるTPSに立ち返ると、AI活用にそのまま使える構造が見えてきます。標準化、自働化、カイゼンのループは、AIツールが変わっても、チームの人数が変わっても、普遍的に機能する枠組みです。
だからこそ私たちは、スクラムの「先」にあるフレームワークとしてTPSを参考に、AIを組織で活用するための取り組みを始めました。
以下では、標準化・自働化・カイゼンがどのように私たちの開発プロセスに落とし込まれているかを紹介します。
標準化——「何が正常で、何が異常か」を定義する
TPSにおいて標準化は土台です。自働化は、「何が正常か」が定義されていなければ機能しません。ソフトウェア開発においてこの標準化を実現するために、私たちは3つのことを行いました。プロセスの分解、リスクベースでの標準の深さの決定、そして成熟度の可視化です。
開発プロセスを8フェーズに分解する
まず「どこを標準化するか」を明確にするために、ソフトウェア開発のプロセス全体を8つのフェーズに分解しました。
Phase 0 — コンテキストエンジン: AIが効果的に動くための土台です。仕様・設計・ドキュメントを機械可読な形で整備し、コンテキストとして配信できる状態にします。
Phase 1 — プロダクトディスカバリー: エピックの定義とストーリーへの分割を行うフェーズです。「何を作るか」をAIが理解できる形に落とし込みます。
Phase 2 — 設計とADR: 外部設計・内部設計・イベントストーミングなどを扱います。設計の意思決定をADR（アーキテクチャ決定記録）として残すことで、AIへのコンテキスト提供にもなります。
Phase 3 — プランニング: ストーリーをタスクに分解し、順序を決めます。AIが計画を補助し、漏れや依存関係を早期に顕在化させます。
Phase 4 — テスト＆仕様駆動開発: 先にテストを書き、そのテストを通すコードをAIに書かせます。テストが「AIへの仕様伝達手段」になるフェーズです。
Phase 5 — インナーループ（コーディング）: 実装の本体です。AIがテストをパスするコードを書き、人間はレビューと設計判断に集中します。
Phase 6 — 自動ガードレール（PRレビュー）: 静的解析・リンティング・AIレビューによる自動品質チェックを行います。
Phase 7 — オブザーバビリティ: リリース後の監視を担います。本番環境での異常検知と通知を行い、品質を守る最終防衛ラインです。各フェーズに「正常系」と「例外」を定義することが標準化の実態です。正常系が定義されたフェーズではAIに任せられる範囲が明確になり、例外が定義されたフェーズでは人間が介入すべきポイントが明確になります。
リスクベースで標準の深さを決める
8つのフェーズを定義した次の問いは、「全部を同じ厚さで標準化するのか」です。答えはNOです。現状のAIにすべてを任せることはできません。すべてを同じ基準で標準化した場合、AIは補助的な利用にとどまり、大きな生産性向上にはつながりません。そこで私たちが取り入れたのがリスクベースアプローチです。考え方はシンプルで、リスク = 影響度 × 発生確率でスコアリングし、Tierに応じてテストやレビューの基準を変えます。
Tier 1（スコア6〜9）: 契約管理や認証など、最高リスク領域。ユニットテスト80%以上のブランチカバレッジ、E2Eテストのハッピー＋ネガティブパスが必須。PRレビューはシニアアーキテクト必須。
Tier 2（スコア4〜5）: 通常のレビューとハッピーパスのE2Eテスト。
Tier 3（スコア2〜3）: 軽量なレビューと任意のテスト。
Tier 4（スコア1）: デスクチェックのみで、自動承認の候補。
AIレビューもTierによって深度を変えます。Tier 1にはコンテキストを考慮した深いレビューを、Tier 4には軽量な自動チェックを。高リスクに厚く投資し、低リスクは最小限にする。このメリハリがあるからこそ、品質と安全性を保ちながら、AIに任せられる領域を最大化できます。
成熟度モデルで「どこにいるか」を可視化する
8つのフェーズを定義したら、次の問いは「それぞれが今どのレベルにあるか」です。各フェーズで5段階の成熟度レベルを定義しました。判定の軸は「再現性」「監査可能性」「例外の扱いが仕組み化されているか」です。
L1: 手動作業が中心、品質にばらつきがある
L2: AIエージェントを使い始め、基本的な自動化を導入している
L3: AIが品質チェックや変換を支援し、人間が判断している
L4: AIが主導し、人間は最終承認のみ
L5: AIが自律的にディスカバリーから検証まで実行している
一気にL5を目指すのではなく、フェーズごとに効果とリスクを確認しながら段階的に進めます。この成熟度モデルにより、「標準化がどこまで進んでいるか」がチーム全体で共有できるようになりました。
自働化——8フェーズのすべてで、異常を即検知し、止め、共有する
標準化によって土台が整ったら、次はその基準のもとで自働化を機能させます。「自動化」ではなく「自働化」——単に作業を機械に任せるのではなく、異常が起きたら即座に検知して止まれる仕組みを組み込むことです。ソフトウェア開発に置き換えると、こうなります。
- 仕様が明確で迷わず進められるタスク（正常系）は、AIが流し切る
- 仕様の曖昧さやツールの不足といった例外は、すぐに顕在化させて人が対応する
- そして例外が出たら、次回は正常系になるよう標準を更新する
この自働化を、コーディング（Phase 5）だけでなく8フェーズすべてに組み込んでいるのが私たちのアプローチの特徴です。コンテキスト整備から設計、テスト、レビュー、監視まで——すべてのフェーズで「正常系をAIが流し、例外を検知して止まる」仕組みを構築しています。
各フェーズには評価と手戻りの仕組みも設けています。フェーズの完了時に成果物を評価し、問題が解消しない場合は1つ前のフェーズに戻ります。
たとえば、Phase 5（コーディング）でAIの出力品質が上がらない場合、Phase 5自体を改善するのではなく、Phase 4（テスト）やPhase 0（コンテキスト）の標準に問題がないかを遡って確認します。上流の標準が整っていなければ、下流の自働化は機能しない——この原則を仕組みとして組み込んでいます。
さらに、先述のリスクベースアプローチにより、フェーズごとのワークフローを柔軟に切り替えられるようにしています。Tier 1（高リスク）のタスクでは全フェーズを厳密に通しますが、Tier 4（低リスク）のタスクではフェーズを軽量化し、AIに大きく委ねます。同じ8フェーズでもリスクに応じて深さが変わる——この柔軟性が、品質を保ちながら速度を出すための鍵です。
当面の目標は全フェーズでL3以上——AIが品質チェックや変換を支援し、人間が判断する状態です。現状ではPhase 5への課題が集中していますが、それは上流フェーズの成熟度が上がった結果、ボトルネックが可視化されたとも言えます。
そして自働化を支える具体的な仕組みが、自工程完結とアンドンです。
自工程完結——各工程が品質に責任を持つ
自工程完結とは、各工程が自身の成果物のクオリティに責任を持ち、次の工程に不良を流さないという考え方です。「後工程で誰かが直してくれるだろう」ではなく、自分の工程の中で品質を検証し、基準を満たしていることを確認してから次に渡す。8フェーズそれぞれがこの自工程完結を果たすことで、初めて全体の自働化が成立します。中でも特に重要なのはPhase 0（コンテキストエンジン）・Phase 4（テスト＆仕様駆動開発）・Phase 6（自動ガードレール）です。
- Phase 0が整っていなければ、AIはコンテキストを正しく理解できず、何をやらせても的外れになります
- Phase 4が整っていなければ、AIが生成したコードの正しさを保証できません
- Phase 6が整っていなければ、速度を上げるほど品質リスクが増します
つまり、Phase 5（コーディング）の生産性は、Phase 0・4・6の整備度によって上限が決まります。各工程が品質を作り込んで初めて、AIが安心して正常系を流し切れるのです。
アンドン——「止まる勇気」がチームを速くする
アンドンとは、製造ラインで異常が起きたときにラインを止めるための仕組みです。問題が起きたとき、個人が抱え込まずに即座に共有し、チーム全体で解決する——この文化を開発プロセスに持ち込んだのがアンドンの仕組みです。
ここで言うアンドンは、単なる困りごと共有ではありません。「例外が起きた事実」と「次回から正常系として流すための更新点」をセットで残す仕組みと定義しています。アンドンが発火したら「火消し」で終わらせず、標準・ルール・判断基準の更新までが完了条件です。成功例もアンドンとして共有します。「このやり方にしたら詰まらなくなった」という知見を標準に組み込むことで、一人が得た改善がチーム全体の当たり前になります。
具体例を紹介します。以前、ADRレビューに時間がかかるという課題がありました。ADR用に最低限のフォーマットしかなく、人によって文章のクオリティに差がありました。記載に1日以上かかることもあり、レビュー時にもドキュメント構造が整っていないと理解に時間がかかるという問題がありました。
こうした課題は、アンドンがなければなかなか表面化しません。「ADRレビューが遅い」という事実は皆が薄々感じていても、それが個人のスキル差の問題なのか、フォーマットの問題なのか、プロセスの問題なのかは、声に出して共有しない限り見えてこないのです。
アンドンが上がったことで、チームとして「良いADRとはなにか？」という問いに向き合うきっかけが生まれました。良いADRを書く人の思考を言語化し、最終的にADR作成を行うSkillに落とし込みました。このSkillはチーム全員で共有し、現在はADRレビューがスムーズになっています。日常の中で「なんとなく非効率だな」と感じていることを、アンドンによって具体的な改善につなげられる。埋もれがちな課題を組織の学びに変える。これがアンドンの最大の価値です。
カイゼン——標準化を更新し、ループを一段上げる
自工程完結とアンドンによって発見された課題は、カイゼンとして標準化にフィードバックされます。
アンドンで上がった例外は、標準の更新によって次回から正常系に変わります。リスクTierも実績に基づいて再評価されます。成熟度レベルが上がれば、そのフェーズでAIに委ねられる範囲が広がります。このループが回るたびに、AIが正常系として流せる面積が広がっていく——これがカイゼンの本質です。
重要なのは、カイゼンが特定の誰かの仕事ではなく、チーム全員の日常になることです。
アンドンの取り組み開始1ヶ月で出たアクションアイテムは約40件。静的解析ツールの導入、リスクベースのPRレビュー設計、CI/CDのビルド時間短縮など、地に足のついた改善が並んでいます。提案だけでなく、チーム全体として改善までやり切る動きが活発化しています。上がった課題に対して即座にPRが作成され、チーム全員がアンドンの取り組みに主体的に参加するようになりました。
誰か一人が推し進めるのではなく、チームメンバー全員が同じ方向を向いてカイゼンを回す。この流れができ始めていることが、自働化の実現に向けて最も重要な変化だと考えています。
おわりに——AIが活躍できる面積を広げ続ける
冒頭で、スクラムのプラクティスの一部がAI活用によって不要になりつつあると書きました。しかしスクラムの源流であるTPSを改めて再解釈し、AI活用の基盤として取り入れたことで、私たちの開発組織は確かに前に進んでいます。
特に自働化の部分は、想像以上にうまく機能しています。アンドンによって例外が即座に共有され、自工程完結によって各フェーズが品質に責任を持つ——この2つの仕組みが、AIに任せられる正常系の面積を着実に広げてくれています。「生産性3倍」という目標に対して、手応えを感じ始めています。
この取り組みはまだ始まったばかりです。8フェーズの成熟度はフェーズごとにばらつきがあり、カイゼンのループもまだ数周しか回っていません。しかし、標準化→自働化→カイゼン→標準化更新という構造が回り始めた今、方向性は間違っていないと確信しています。
今後、取り組みが進んで新たな知見が得られたら、またお伝えしていきたいと思います。
Sansan技術本部ではカジュアル面談を実施しています
Sansan技術本部では中途の方向けにカジュアル面談を実施しています。Sansan技術本部での働き方、仕事の魅力について、現役エンジニアの視点からお話しします。「実際に働く人の話を直接聞きたい」「どんな人が働いているのかを事前に知っておきたい」とお考えの方は、ぜひエントリーをご検討ください。
