快手电商、AI パイプラインで開発パラダイムを再構築

快手技術 2026年9月3日 17時35分 北京

参加して抽選で「クイックシャープの牛仔小快フィギュア」をプレゼント！

序章：AI による効率化の「氷と火」

2026 年、「AI による効率化」は産業界・研究開発（R&D）領域において最も切実なキーワードとなりました。それはほぼすべての四半期報告書の冒頭に貼られるように定着しましたが、実際のビジネス成果として現れることは稀です。

AI ツールは個人の能力を飛躍的に向上させていますが、個人と組織の効率化の間には「氷と火」ほどの格差が生じています。個人の生産性は 10 倍に拡大することも容易ですが、企業規模での効率化効果は依然として不明確なままです。その背景にある構造的な問題は、多くのチームが AI を単なる「ツール」として利用している段階にとどまり、業務プロセス自体の再構築には至っていない点にあります。

ツールを置き換えるだけでは局所的な加速は生まれても、組織全体の効率化を飛躍させることはできません。

個人レベルでの効率は向上し続けている一方で、組織としての効率化効果はまだ見えないのが実情です。では、どのようなツールを組み合わせ、どのようなプロセスや組織体制を整備すれば、チームの生産性を本格的に引き上げることができるのでしょうか？

この記事では、快手（クァイショウ）电商のマーチャントチームが、「ツールの活用による効率化」と「組織構造の刷新」を両輪として、いかに組織全体の効率を向上させたかについて共有します。

2026 年初頭より、快手电商のマーチャントおよびオペレーション支援センターは、ツールと組織の両面における効率化の深化に向けた取り組みを開始しました。本稿は、同チームが快手ドメイン内の AI 活用事例を整理・総括したものです。

一、私たちの現場と直面する課題

1.1 システムの規模と複雑さ

私たちが担当するのは、快手电商の B&M（Business & Merchant）向けシステムです。その最大の特徴は、処理フローが長く、扱うビジネス領域が多岐にわたり、かつ相互に密接に絡み合っている点にあります。

現在のシステムでは 6 種類以上のユーザー役割、20 以上のビジネスドメイン、そして数百規模のマイクロサービスを提供しています。各ドメインは完全に独立しているわけではなく、互いに連携して製品ラインを形成し、多様なユーザー層をサポートしています。こうした複雑なシステム環境において、一つの機能要件を実現するには複数のチームによる連携が不可欠です。「一言の指示」だけで AI に実装を任せるのは非現実的であり、AI がより効率的に要件を満たすためには、明確な規範と制約の下で導く必要があります。

1.2 データが語る真実：コーディングは速くなったが、納期は劇的に短縮されていない

2026 年 1 月から 4 月にかけて、チームの主要な施策は AI ツールの浸透促進でした。その結果、チーム全体の週次トークン消費量は数千万に達し、一人あたりのコード生成量は 170% 増加しました。

しかし、平均的な要件の納期短縮効果は極めて限定的なものにとどまりました。

自社の実践経験や業界全体の知見を踏まえても、コーディング工程のみを対象とした AI 導入では、全体としての効率化効果は限定的です。要件の交付スピードを高めるためには、AI を要件定義からリリースまでの全ライフサイクルにわたって組み込むことが不可欠です。

以下に、当チームが 2025 年に要した要件ごとの時間分布と、業界全体の平均的な納期データを比較したグラフを示します。

1.3 現在の納品効率を阻む構造的な課題

a. 「需要側」の理解分析にコストがかかる

EC の B&M（ビジネス＆マーケティング）領域は業務要件が極めて複雑です。要件を出すのは製品マネージャーですが、その段階で「要件予備審査」「要件本審査」「技術方案審査」「TC 審査」など、数多くのレビューをこなさなければなりません。

従来のプロセスでは、要件の漏れや不足といったミスが発生しやすいだけでなく、これらのレビューに膨大な時間を費やすことになっていました。

b. 「納品側」の協働コストが高い

一つの要件には、出店審査、店舗管理、取引履行、資金管理、カスタマーサポート、決済・清算など、多岐にわたる工程が含まれます。また、製品担当者、フロントエンド開発者、バックエンド開発者、テスターなど、多くの役割が関与します。

例えば、フロントエンドで 3PD（Person-Days：人日）が必要で、バックエンドでも 3PD、テストでも 2PD かかる場合、単純に足して 5PD で済むわけではありません。実際には 10PD に達することさえあります。

従来の納品環境では、人間同士のコミュニケーションの複雑さが指数関数的に増大し、要件の多くが「他者との調整」や「待ち時間」によって消費されてしまいます。

c. 「新入社員」の業務学習曲線が急峻である

EC の B&M 領域システムは 5 年以上にわたって継続的に改善され、膨大なドメイン知識を蓄積しています。また、ビジネスルールや事業形態が頻繁に変化する性質を持つため、新規メンバーが開発を開始するには、一定の学習期間と文脈理解が必要です。

従来の開発モデルでは、新成員はシステム全体の文脈に乏しく、高コストな知識伝承プロセスを必要としていました。

2. 私たちの目標と設計原則

#### 2.1 目標

上記の課題を解決するため、私たちは一連の「要件納品自動化パイプライン」を構築しました。この実践を通じて、私たちが問いかけたのは以下の点です。

「複雑な業務があり、過去の負債（レガシー）を抱えるエンタープライズシステムにおいて、要件を 7x24 時間自動で稼働させるためのインテリジェントな納品パイプラインとは何か？」

現状と目標をいくつかの観点から比較します。

• 主要効率指標: 現在の要件処理能力（スループット）は低く、平均納品期間も長いです。目標は、要件スループットの 30% 向上と、平均納品時間の 40% 短縮です。
• チームの役割: 現状ではフロントエンド開発、バックエンド開発、テストが分業されていますが、これを「ビジネス全栈（フルスタック）開発」へと転換します。

• 納品モード:
• 現状: 要件分析段階は PRD の人手による理解と製品要件の議論に依存。コード開発段階では L3（高度な自動化レベル）の比率がわずか 5%。テスト・連携調整段階では手動でのユニットテスト作成と、人手によるエラーログ分析。機能リリース段階では手動でのデプロイパイプライントリガーと、オンラインでの再検証。
• 目標: これらを AI パイプラインによって自動化し、人的ミスを減らし、スピードを劇的に向上させること。

目標とする状態では、需要段階で自動的に PRD（製品要件定義書）と構造化された需要を生成し、技術方案を作成して TC（テストケース）も自動生成します。開発段階では L3 自動化の割合が 15% を超え、タスク分解やテスト駆動開発（TDD）を実施。ユニットテストは AI が 100% 生成し、AI がビジネスエラーログを分析して自動連携テストを行います。テスト段階ではテストケースを AI が自動生成・調整し、精度は 100% に達し、実行率は 80% を超えます。これにより需要からテストまでの交付効率が平均 45% 向上します。リリース段階では自動デプロイパイプラインが稼働し、AI が PRD に基づいて製品验收を行います。

工程ツールの現状は、チーム単位でのプロジェクト管理と kdev による CI/CD プロセスに依存しており、需要のライフサイクルにおける監視機能が不足しています。

目標は、インテリジェントなデリバリーパイプラインを基盤として需要の全ライフサイクルを完結させ、埋め込みポイント（イベント）を通じて需要全体の自動化率と交付効率を可視化することです。

以下の 2 つの図は、従来の開発モデルと AI パイプラインモデルの違いを示しています。

従来のモデル：

複数の役割が関与し、協業コストが最大の問題となります。互いの待ち時間が需要交付時間を最も大きく圧迫します。

AI パイプラインモデル：

「スーパー・インディビジュアル（超個人）」が主導し、アジャイルな対応で需要交付の自動化を実現します。

開発パラダイムに変革が訪れます。ドメイン責任者がその領域の初期化を担当し、パイプラインの自動化を担保します。需要実行者とプロダクトマネージャーは現場で需要について議論し AI と対話した上で、「自動デリバリー」を実行します。

2.2 核心原則

全ライフサイクル： 単点ツールの改善に留まらず、知識構築から需要生産、開発実行、テスト・リリースに至るまで、エンドツーエンドの AI による効率化体系を構築します。

エンジニアリングワークフロー： AI にコードを書かせるだけでなく、AI を「制御可能」「監査可能」「再利用可能」な工程ワークフローに組み込みます。これにより、大多数の需要は要件を明確にするだけで、Harness Engineering（ハーン・エンジニアリング）と呼ばれる自動化された開発パイプラインが実行されます。

クラウドとエッジの連携： 単一役割の効率化ではなく、「クラウド＋エッジ」による多角色協働システムを構築します。クラウドが司令塔となり、構造化された需要の管理、タスク配分、ワークフローのオーケストレーション、およびマルチエージェントの協調を担当します。エッジは実行装置として具体的な実装を行います。この模式を「Agent Swarm（エージェント群）」と呼びます。

エンドツーエンドの接続： 交付側の効率化だけでなく、EC プロダクトとの深層連携を通じて需要側でも自動化を実現します。「対話式 PRD 生成」と「構造化需要生成」により需要側を自動化し、フロントエンド、バックエンド、テストの全リンクを繋ぎます。これにより需要の自動フローと追跡可能性を確保します。またドメイン別ナレッジベースを構築することで、PRD 生成、技術方案作成、TC 生成の精度を高め、AI による交付をよりスマートにします。

2.3 対抗的デザイン：open-door と close-door

「open-door」と「close-door」の対抗的な設計により、真に需要（要件）の自動化された納品を実現します。

パイプラインの各ノードは、いわば「部屋」のようなものです。pandoraFlow-delivery の役割は可能な限り「open-door（扉を開ける）」ことで、要件が次の部屋へスムーズに到達できるようにすることです。一方、pandoraFlow-review の役割は可能な限り「close-door（扉を閉める）」ことで、前の段階の成果物が完全に承認されるまで、現在のノードには進入させないことです。

この 2 つのスキルによって、すべてのスキルが連携してつながります。しかし、パイプライン内の中間生成物を保存・管理し、パイプラインの状態を継続的に監視する必要があります。これらについては、設計はシンプルに保ち、ファイルシステムと Git を活用することで解決しています。

AI コードチェーンにおいては、「生産よりも検証が重要」という判断に基づいています。ただし、機能開発が完了した時点でのみ検証を行うのではなく、各ステップの中間生成物に対して検証を行います。要件の全ライフサイクルを通じて、各段階で「plan（計画）→ execute（実行）→ verify（検証）」を遵循します。この設計の核心は、現在の段階の成果物を直ちに承認することにあります。承認に失敗すれば修正のために戻り、成功すれば次のステップへ進むというプッシュ・プル型のデザインにより、要件納品の自動化を確立しようとしています。

三、全工程の分解

3.1 需要側：生産・運営・研究の連携体制の高度化

以前：

製品マネージャーは、ドメインを跨ぐ相互作用ロジックや境界条件を手作業で整理する必要がありました。PRD（製品要件定義書）の完全性は個人の経験に大きく依存しており、作成後には MRD 審査、PRD 審査、デザイン審査など複数のラウンドを経て調整を行う必要がありました。問題が発見されると、最初からやり直しとなることも珍しくありませんでした。また、過去の要件ドキュメントやビジネスルールが各所に散在していたため、製品担当者が新要件を作成する際に過去の資産を再利用できず、開発担当者が PRD を元に技術方案を策定する際にも、情報不足により頻繁に製品担当者に確認しに戻るという非効率な状況が生じていました。

現在：

私たちは、既存のドメイン知識ベース（過去の PRD、業界資料、ビジネスルール、ドメイン概念など）を支えとした「需要自動生成ワークベンチ」を構築しました。これにより、製品マネージャーはエージェントとの対話を通じて要件を明確化し、プラットフォームが自動的に PRD と構造化された要件（EARS/BDD 形式）を生成します。さらに、開発チームへワンクリックで転送することも可能です。この結果、需要側のプロセスは「多回の審査と手動調整」から、「知識ベースによる自動生成＋プロトタイプ確認＋所属チームへのワンクリック転送」へと進化しました。

3.2 Spec 段階：要件納品モデルの高度化

以前、PRD（製品要件定義）から技術仕様書への移行は完全に人手に頼っていました。開発者は手作業で上流・下流のサービスインターフェースドキュメントを検索し、どのサービスが影響を受けるかを一つずつ判断する必要がありました。現在のビジネスプロセスは複雑に絡み合っており、影響範囲を整理するだけで膨大な時間を要します。

設計案は個人の経験に大きく依存しており、担当者によって提案される案の深さや網羅性に大きな差が生じます。また、作成後は技術仕様レビューを経る必要があり、その過程で発見された見落としや誤りは手戻りを招き、一連のプロセスには非常に長い時間がかかります。さらに厄介なのは、過去のニーズから蓄積されたインターフェースに関する理解やアーキテクチャ上の判断が、個人の頭の中や適当に作成したドキュメントに散在している点です。そのため、類似の新しいニーズが発生しても、毎回ゼロから始めなければなりません。

現在では、システムのドメイン知識（ドメイン知識はドメイン責任者によって一度だけ初期化され、既存コードからシステム API、データ構造、ビジネス呼び出しチェーンを抽出し、過去の PRD や技術仕様書からビジネスルール、機能の境界線、過去のアーキテクチャ判断を抽出し、各業務ドメインの機能エントリと主要ロジックを統合する）に基づき、AI が自動的に上流・下流のインターフェース解析を行います。コード呼び出しグラフを組み合わせることで、関連サービス内で今回の変更点を正確に特定し、インターフェース依存関係と影響範囲を自動導出します。さらに、proposal.md、design.md、tasks.md という構造化された要件三件套をワンクリックで生成できます。

これにより、仕様（Spec）段階は「知識ベース駆動・自動生成・レビューゲートフロー」という形へと変貌しました。

3.3 Dev 段階：開発フェーズ

以前、実際にコードを書く前に、開発者は高いハードルに直面していました。B&M 端末システムは 5 年以上の期間で反復進化を遂げ、膨大な技術負債が蓄積されています。また、異なる開発者のコーディングスタイルが混在し、各ビジネス領域には独自のルールと歴史的な負荷が存在します。開発者は既存コードを手動で読み込み、現在の業務ロジックを理解した上で、「どこを」「何を」「どれだけ」変更すべきか、そしてどの箇所に連鎖的な影響が生じるかを判断する必要がありました。

複雑なビジネスシナリオ——プロセスオーケストレーションノードの設定や、ドメイン横断の業務ルール調整など——においては、この整理コストは極めて高く、システムへの深い理解を個人に依存せざるを得ませんでした。経験豊富な開発者であっても、テスト提出後に「漏れ」「誤り」「重複設定」などの問題が発生しやすく、手戻りが頻発していました。

現在では、開発パイプラインにおいて tasks.md には、Spec 段階から自動導出された変更点と影響範囲が明記されています。開発者はこの task.md のタスクリストを順次実行することで、Spec から直接コード生成を行います。ドメイン知識ベースには、既存システムの API 定義、データ構造、業務呼び出しチェーン、そして過去のアーキテクチャ判断が蓄積されており、AI は常にこれらの文脈制約の中で動作します。これにより、変更対象となるビジネスルールの境界を自動で特定し、どのロジックの追加・修正が必要か、どこに設定の競合や漏れリスクがあるかを正確に判断できます。

テスト駆動開発（TDD）を採用しているため、すべての機能に検証が組み込まれています。新人開発者でも知識ベースを活用して即座に業務に参画でき、「正確に変更し」「確実に実装する」ことが可能になりました。

3.4 Test 段階：テストフェーズ

以前、テストフェーズに入ると、テスターは手動でテストケースを作成し、テストデータを準備する必要がありました。一つの機能要件には多くのビジネスパスが含まれるため、テストケースのカバレッジはテスターの要件理解度に依存します。その結果、カバー漏れや境界条件の取りこぼしが頻発しました。

また、テストデータの準備も多大な時間を要します。異なる業務ドメイン間でデータに依存関係が存在するため、完全なテスト可能なチェーンを構築するだけでも重労働でした。

バグが発見されると、開発者は再び介入して原因調査と修正を行い、次のテストサイクルを待つ必要があります。このループが繰り返されることでテスト期間が長期化し、各工程間の待ち時間が全体の所要時間の大部分を占めるようになりました。

現在：テスト工程は「手動でテストケースを作成し、データを準備して修正を待ち、再検証を行う」という従来型のプロセスから、「スキルを用いて自動生成・実行し、問題を自動的に解決する」高効率なフローへと進化しました。構造化された要件（BDD/EARS）と変更の影響範囲に基づき、主要フロー、例外パス、境界条件を網羅したテストケースが自動生成されます。また、ドメイン知識ベースを活用してテストデータを自動構築することで、各業務領域間のデータ依存関係を理解し、完全で利用可能なテストチェーンを自動的に準備します。

変更された機能ポイントの分析に基づき、マルチエンドでの精密な回帰テストが可能となり、高カバレッジの境界条件ケースも生成されます。さらに AI による全パス探索と遷移ルートの検証により、「検出漏れなし」「網羅性あり」「実行速度が速い」ことを保証します。バグは自動的に記録・特定され、テスターが報告書を提出すると即座に修正フローが起動し、バグがなくなるまで循環的に改善を繰り返します。

3.5 オンコールフェーズ：日常のオンライン運用

以前：オンコール中は、オンラインアラートやユーザーからのフィードバックに対し、担当者はログプラットフォームで一つずつログを検索し、キーワードをフィルタリングして traceId でログチェーンを分析。コードと照合しながら行ごとに調査を行い、複雑なリンクの中で根本原因を特定するには多大な時間を要しました。複数のサービスが連携する問題の場合、さらに困難を極め、複数ドメインの担当者を招集して共同で確認する必要があり、協働待ちによるコストが非常に高かったのです。

現在：現在のパイプラインでは、オンコール対応はスキルによってログソースに統一してアクセスし、実行時のログとリンクコンテキストが大規模モデルに自動的に注入されます。これにより、マルチサービスのログ関連分析と根本原因の特定をランタイムで完結させ、複数のプラットフォーム間を行き来する必要がなくなりました。

根本原因を特定した後、エージェントはコード呼び出しグラフとドメイン知識ベースを活用して最小の影響範囲を自動で絞り込み、「問題ログ→根本原因分析→影響範囲→最小変更提案」という根拠のあるチェーンに支えられた修正方針を提示します。これは経験則に基づく推測ではなく、確実なエビデンスに基づいたアプローチです。

修正完了後は自動的にテスト環境へデプロイされ、ログを再収集して問題が解消されたか検証されます。「アラート→特定→最小範囲での修正→検証」という一連のクローズドループは、単一のコンテキスト内で完結します。

四、組織の変容

AI ツールの導入と自動化された開発パイプラインの構築だけで、組織全体の開発効率が向上するのでしょうか？答えはノーです。組織の効率化は極めて複雑な協働の問題だからです。

この話題については『人月神話』から議論を始めましょう。同書には有名な命題があります。「あるプロジェクトが元々 10 人で 1 年かかる場合、人員を倍増して 20 人にすれば半年で完了できるか？」という問いに対する答えは「不可能」です。この命題が示す核心的なパラドックスは、人員を増やしてもプロジェクト期間が線形的に短縮できない点にあります。その理由は、人間同士のコミュニケーション複雑度が幾何級数的に増大し、新メンバーがシステム全体の文脈を欠き、高コストな知識伝達が必要となるからです。

同書のもう一つの頻出キーワードは「左移（レフトシフト）」です。以前からエンジニアリングの分野では「問題が発生する前に解決する」という左移の考え方が叫ばれてきました。しかし、なぜ以前ほど浸透しなかったのでしょうか？長年の工程経験から得た見解として、左移そのものは正しい考え方ですが、投資対効果（ROI）が不十分だったためです。

左移の本質は、部門間での責任の移譲にあります。つまり、本来右側で責任を負っていた部分を左側に移すわけですが、左側の担当者がそれを受け入れるか、認めるか、あるいは能力があるかどうかという問題があります。これには膨大なソフトウェアエンジニアリングエネルギーと組織的な摩擦コストが必要です。システムに十分な自動化機能が備わっていない場合、左移は単なる作業量の移動でしかありません。

しかし、AI 時代の到来により、この二つの古典的な難問が書き換えられました。

組織に人を増やすと非効率的なコミュニケーション問題が生じますが、AI エージェントを追加する場合は異なります。エージェントは文脈を損なうことなく取得でき、既存のコードから大規模かつ体系的に文脈を解析できます。人間同士の幾何級数的なコミュニケーションコストを必要としません。

現在、エージェントを追加することは以前とは全く異なり、昔のパラドックスは新しい時代の基盤ロジックにおいてもはや成立しません。

左移についてはどうでしょうか？AI 時代においては、従来文脈や知識資産として存在していたものを AI が既存コードから抽出し、さらに増分される PRD や Spec などのコンテキストを付加することで、複雑なビジネスシステムを誰もが理解できる文脈フレームワークへと簡素化できます。新メンバーにとっても異なる役割の担当者の間でも、一つの業務フロー内でより低コストかつ効率的に合意形成が可能になります。

したがって組織の変容においては、チームは機能別に分かれた組織から「スーパーインディビジュアル（超個人）」型のチームへ移行を試みています。この変革に伴い、チームの役割分担と協働方法にもいくつかの変化が生じています。

組織の進化がもたらす具体的な変化を、以下の 5 つの視点から見てみましょう。

開発プロセスの変化

以前は、運営、製品、開発、テストなど多様な役割が関与し、協働コストが最大の問題でした。相互に待ち合う時間が、納期遅延の主要な原因となっていました。

要件定義から実装に至るまで、MRD（市場要件定義）レビュー、PRD（製品要件定義）レビュー、技術設計レビュー、TC（テストケース）レビュー、コードレビューなど、多くの審査段階を通過する必要がありました。

実装フェーズでは、通常、フロントエンドとバックエンドの開発者が複数おり、複数のドメインにまたがる連携が必要でした。これには、完全なサイクルでのフロント・バックエンド連携や、上流・下流との調整が不可欠でした。

現在は、製品マネージャーとデリバリー責任者（フルスタック）の 2 名だけで、要件の全ライフサイクルを完結できます。

二人で会議を行い、AI と対話しながら構造化された要件を定義します。

デリバリー責任者は、その後の AI との対話を通じて技術設計、TC、および計画（plan）を生成し、全体の成果物が正しいかレビューします。

AI が自動的にコードを書き、連携テストと自動テストを実行します。現在は中間成果物の手動検証が必要ですが、将来的には完全自動化され、深夜に AI だけで完結できるようになります。

最後に製品マネージャーが最終验收を行います。

ドメイン責任者の役割変化

以前は、既存システムの業務複雑度が極めて高く、歴史的な技術負債や多様なコーディングスタイルが蓄積されていました。生産環境の安定性を保つため、パフォーマンスや保守性にも細心の注意を払う必要がありました。

ドメイン責任者はアーキテクチャ文書を整備し、技術設計レビューとコードレビューを通じて、ドメイン内のエンジニアリングコードに対して包括的な制約と検証を行いました。

現在では、AI コーディングの導入前に、ドメイン責任者がその領域の初期化を担当します。

既存コードや PRD からコンテキストとナレッジ資産を抽出し、システムの API、データ構造、ビジネスフローを掘り起こします。その後、規約テンプレートに従って AI に構造化された Spec（仕様）知識ベースの生成を促します。

さらに、現在の開発負荷、制約条件、検証ルールを設定します。

要件定義の左移（早期化）

以前は、製品マネージャーが会議を調整し、MRD レビュー、PRD レビュー、そしてビジュアルレビューを行いました。レビューで問題が見つかったり、実装中に新機能の変更が必要になった場合、全体のプロセスを最初からやり直す必要がありました。

現在では、デリバリー責任者は単に要件の詳細を議論するだけでなく、ユーザーフロー、製品価値、顧客体験に本質的な注力を向けられます。

Zeta PM ワークステーションを用いてプロトタイプを迅速に生成し、このプロトタイプを直感的な媒体として活用しながら自動的に PRD を生成します。これにより「見たままが仕様」という確認が可能になり、本来リリース後にしか行えなかった验收を、要件定義の最も初期段階（左側）へ前倒ししました。

ドメイン知識の蓄積により、要件側では過去の詳細や変更の影響を包括的に把握できます。この状態であれば、製品マネージャーとデリバリー責任者は煩雑な要件の詳細議論から解放され、顧客価値とユーザー体験に集中できるようになります。

品質保証の左移（早期化）

以前は、テスト工程の左移が長年十分に浸透しなかったのは、方向性が間違っていたからではなく、コストが高すぎ、プロセスが重すぎたことが本質的な原因でした。

現在では、AI によってカバレッジの整理が軽量化され、テストケースの作成が高速化されました。これにより、「正しくはあるが高価すぎる」状態から、実際に実行可能なエンジニアリングプラクティスへと進化しました。デリバリー責任者は AI ツールを用いて自動テストを実行し、テスト工程を左移させることで開発全体の効率を大幅に向上させます。

テスト業務の中心は、テストケースの生成、テストデータの準備、そしてテストの実行です。AI による用例生成、自動データ準備、および AI による自動実行の恩恵を受け、テスト段階を開発フェーズへ前倒しできます。さらに、AI による問題特定と自動修復を連携させ、バグがなくなるまで循環的に改善を行うことで、要件の完全な自動交付を実現します。

役割の統合

以前は、

現在のスキル深度が職務を分ける主要な基準となっています——フロントエンドはフロントエンド、バックエンドはバックエンド、デザインはデザインと守り、各人は自らの専門分野で極限まで追求します。

現在では：

プロダクトマネージャー、インタラクションデザイナー、DA（データアナリスト）が三合一となり、業務コミュニケーションからデモ確認、業務意図からユーザーインターフェースまでを一手に引き受けます。

フロントエンド、バックエンド、テスト担当者が三合一となり、フロント開発、データ構造、状態管理、API 設計、高可用性と高信頼性の課題を網羅し、ビジネスモデルからシステム安定性までをカバーします。

五、私たちが踏んだ二つの失敗

1. 失敗その一：大規模なプラットフォーム構築にコストをかけるのではなく、標準とプロセスの確立に注力すべきです

チームが実践を始めた当初は、開発者が利用するプラットフォームの開発に多くの時間を費やし議論しました。しかし、そこにはいくつかの大きな問題がありました。

まず、開発者の習慣を変えるのは難しく、受け入れられにくい点です。

業界のソリューションやツール、スキルの進化スピードは非常に速く、もし深くカスタマイズして開発した場合、業界の迅速なイテレーションに追いつけず、かつ使いやすさでも劣ってしまうからです。

この問題が起きた根本的な原因は二つあります。一つ目は、開発者が「自前の輪を造る」ことに執着しており、現在ではそのコストが低下している点です。二つ目は、多くの場合、横断的なチームが推進するには、ツールとプラットフォームが組織の存立基盤となる必要があるという点です。

私たちのチームはこの課題に対し、プラットフォームを構築するのではなく標準を確立し、最小限のツールで監視を行うことで対応しました。そして、ツールとスキルには開放性を保つことにしています。私たちが核心として取り組んだのは以下の二点です。

第一に、開発パイプラインの各段階における順方向の推進と逆方向の検証プロセスを導入しました。さらに、すべてのプロセスノードを「delivery（納品）」と「review（レビュー）」という二つのスキルで強制的に連結し、その間で使用される openSpace や superPower などのツール群は、初期設定時に各ドメイン責任者が自由に選択・定義できるようにしています。

第二に、開発プロセスのすべてのデータを収集しました。要件定義、技術設計、フロントエンド開発、バックエンド開発、結合テスト、テスト待機、開発待機など、各段階の所要時間と自動化能力を可視化し、管理手法を通じて各段階で高い自動化率を実現することを目指しています。

1. 失敗その二：Harness は構築しやすいが、ドメインでの実践は困難である

業界のスキルを導入してそのまま使うか、それをベースに「魔改造」する程度であれば難しくはありません。しかし、ツールを導入しプロセスを定めたからといって、ドメインで本当に業務効率が上がるでしょうか？結果としてそうならないケースも少なくありません。

もしツールとプロセスを動かす主体が人間である限り、人間同士の協業コストや摩擦は決して消えません。この点について、私たちのチームには二つの経験があります。

第一に、ドメインの自動化要件納品における監視体系を構築することです。交付チェーンにおいて人が介入する回数を指標とし、これを評価基準として設定しました。

第二に、実際に業務を理解しているドメイン責任者が現場に入り込み、ナレッジベースや標準作業手順書（SOP）の詳細を確認し、独自のワークフローを構築・カスタマイズできるようにすることです。

六、同業者向けの注意点リスト

プラットフォーム構築に莫大なコストをかけるのではなく、標準を確立した上でオープンソース界の力を借りてツール問題を解決すべきです。

ドメイン知識の蓄積は極めて重要です。開発効率化の三大核心要素は「基盤モデル + Harness + ドメイン知識」です。基盤モデルは世界トップ 3 のプレイヤーが持つものであり、Harness はオープンソース界のものであり、ドメイン知識だけが自社のものです。ナレッジベースについては、過去のすべてのコード、PRD（製品要件定義）、技術設計を統合し、プロセス・ルール・エンティティを中核としたドメイン知識層を構築しました。これらはすべて知識グラフの形式で表現されています。

組織の効率化を実現するため、最も重要な指標は「AI 自動化率」です。これは AI が人間の業務を引き継ぎ、人間が介入する必要がある回数を指します。私たちの判断では、複雑な作業はすべて AI が要件納品の開始前に完了させるべきであり、コード記述、単体テスト、システムテスト、リリース・デプロイの各段階で極めて高い自動化率を達成する必要があります。この目標を達成するためには、一定の管理手法が不可欠です。

七、結び：ツールによる効率化と組織による効率化という二輪駆動

ツールによる効率化においては、要件の全ライフサイクルにおける自動化交付能力の構築を通じて、組織が真に効率化する点に注力します。

組織構造においては、フルスタック型のスーパーインディビジュアル（超個人）の育成と実践を重視し、横断的な組織次元で機能部門を減らし、ビジネス戦術ユニットが自律完結できる能力を持たせることに注力します。

指数級な効率化の恩恵は、往々にして第一段階の技術革命による生産性向上が原動力となり、組織構造そのものの見直しを促すことで初めて実現されます。逆に、組織構造の変革を伴わないまま技術導入を進めれば、組織全体の効率化には限界が生じます。したがって、組織の生産性向上という観点からは、「ツールによる効率化」と「組織構造の再設計」の両軸を同時に捉える必要があります。

以下に、他社でも応用可能な成功事例を二つの主要な視点から整理します。

【交付プロセス（ツールによる効率化）】

需要対応の加速：一部のツールを置き換えるだけでは局所的な速度向上にとどまり、システム全体の生産性飛躍にはつながりません。重要なのは、需要から研究開発、そして納品に至るまでの全ライフサイクルにおける自動化です。真の自動化が実現できなければ、「指数級な組織効率化」も夢のまた夢となります。

検証を優先する：コード生成による一時的な興奮に惑わされず、ドメイン責任者の立場に立って課題を分解し、段階的な成果物を厳格に検証することが求められます。

対抗型 AI エージェント（一方が前進し、他方が後退して競い合う仕組み）の設計により、自動化プロセスを実際に稼働させることが可能です。

【組織構造】

縦方向の視点：需要とテストの工程を前倒し（左シフト）し、従来の工程別分業型から、全機能を担う「スーパー・インディビジュアル」による交付モデルへ転換します。これにより、優れたドメイン責任者を育成します。ドムイン責任者の役割は、「技術専門家の視点」から「ドメインの専門家としての視点」へと進化し、細部の実装からユーザーフロー、製品価値、顧客体験への注力へとシフトする必要があります。

横方向の視点：企業内での情報伝達の非効率や、部門間での無駄な競争（インナーゲーム）が常態化している根本原因は、組織設計の欠陥と、部署間の権限・責任範囲の不明確さにあります。さらに、各部門が業務チェーン上で占める位置づけや、その時点での事業発展段階にも深く制約されています。AI ツールは個人の能力を拡大するものですが、この課題に対処するには二つの現実的なアプローチが可能です。一つは、横断的な機能部署（アルゴリズム、中台、効率化チーム、テスト、フロントエンドなど）の縮小・再編です。これらを資金調達、流通、運営プラットフォームといった事業単位へと再構成し、「阿米巴経営」を推進します。AI 時代においては、この組織変革は以前よりも容易に実現可能となるでしょう。

八、チーム紹介

快手（クイショウ）電商の商家・運営支援センター技術チームは、商家、インフルエンサー、そしてプラットフォーム運営者を対象に、全工程を経営シーンに対応しています。同チームは「経営目標とシステム能力を結びつける」ことを使命とする経営技術チームとして位置づけられ、商家の経営とプラットフォーム運営の知能化アップグレードに注力。これにより経営コストの削減と運用効率の向上を図り、事業成長を牽引します。

技術体系は「インテリジェントな経営のクローズドループ」を経営の中心軸とし、経営領域における洞察、意思決定、実行、そして振り返りと原因分析をシームレスに結びつけます。また、「デジタル・エンプロイ（数字の従業員）」とは、プラットフォーム運営向けの AI 運用エージェントであり、大規模な運用を実現する担い手です。AI、データインテリジェンス、B 端プラットフォームが技術基盤を支え、AI ネイティブな開発手法によって、事業判断から製品検証に至るまでの反復プロセスを強力にサポートします。

「参加して豪華賞品を獲得しよう」

あなたの仕事において、AI が実際に一人で完遂できる部分はどのくらいありますか？もし AI がコード作成、テスト、リリースという一連の工程をすべて引き受けた場合、あなたが最も手放したくないのはどのステップでしょうか。コメント欄でぜひ教えてください！当社はコメントの中から抽選で 3 名の幸運な方を選び、「馬の年生肖キーホルダー（デニム風の『小快』）」をプレゼントいたします。

【おすすめイベント】

WeChat で開くにはこちらへ