中国クライアントから范围外の依頼を受けて、追加費用を伝えたいが关系を壊したくない、そんな悩みはないでしょうか。
Change Request対応は「即接受・有条件接受・拒绝」の3パターンで処理します。影响评估(Impact Assessment)を先に示すと中国クライアントも納得しやすくなります。
本記事では変更依頼への3択対応と、中国特有の決裁フロー・范围蔓延防止策までを整理します。
- 変更依頼が起きるタイミング
- 变更对应の3択
- 变更依頼受信時の初期対応テンプレ
- 影响评估(Impact Assessment)
- 变更订单(Change Order)の案内
- クライアントの社内承認フロー
- 拒绝・延期の表現
- 頻発する変更依頼への対応
- 社内向けエスカレーション
- Change Request 例文8
- Change Request対応力を評価する指標
- CRで絶対書かないNG表現
- Change Request Post-mortem
- Change Request関連記事
- 中国B2B特有のCR論点
- CR管理のベストプラクティス
- 中国B2B CR交渉テクニック
- CR対応の地域別差
- CR対応者のスキル育成
- CR見積もり公式と実例
- Change Order書式テンプレ
- CR頻発時のプロセス見直し
変更依頼が起きるタイミング
Change Requestは主に3つのタイミングで発生します。
需求确定後の追加依頼
当初合意された要件定義確定後に追加依頼が来るパターンです。最も頻出します。
中国B2Bでは需求确定書を作成しても、その後の追加依頼は避けられません。変更管理プロセスを事前に合意します。
途中での规格変更
プロジェクト中盤で仕様変更が発生するパターンです。技術課題や市場変化が原因です。
交付前の修正
納品直前に「もう少しこうしたい」と修正依頼が来るパターンです。納期・コストに影響大です。
变更对应の3択
Change Requestへの対応は3択です。
即接受
軽微な変更で影響が少ない場合、即接受します。関係維持に効果的です。
(1)「即接受」(2)「jí jiē shòu」(3)「即時受入」は1時間以内の作業で対応可能な変更に限定します。
有条件接受
追加費用・工期延長を伴う場合、条件付きで受け入れます。変更见积(Change Order)を提示します。
拒绝・延期
プロジェクト目標と矛盾する変更や、致命的に影響する変更は拒否または延期提案します。Phase 2として別契約にするのが実務解です。
变更依頼受信時の初期対応テンプレ
変更依頼受信直後の24時間の動きが重要です。
24小時以内の确认收到
(1)「已收悉您的变更需求」(2)「yǐ shōu xī nín de biàn gèng xū qiú」(3)「変更依頼を受領」と24時間以内に確認返信します。
即時判断は避けます。評価時間を確保します。
影响评估期間の提示
(1)「我方需要3个工作日进行影响评估」(2)「wǒ fāng xū yào 3 gè gōng zuò rì jìn xíng yǐng xiǎng píng gū」(3)「影響評価に3営業日必要」と期間を提示します。
評価期間中は関連作業を一時停止することを明示します。
並行作業の一時停止判断
変更影響範囲を考慮し、関連作業を一時停止するか判断します。損失を最小化する判断です。
影响评估(Impact Assessment)
影響評価は4軸で行います。
工时(Hours・Days)
追加必要な工数を時間・日数で定量化します。「需要追加10人日」のように。
交付日期
納期延長が必要か、必要なら何日かを明示します。
其他功能への波及
変更が他機能・他タスクに波及するかを評価します。連鎖的影響は特に注意します。
成本(预算)
追加コストを見積もります。人件費・外部委託費・ツール費用を含めます。
变更订单(Change Order)の案内
条件付き受入の場合、正式なChange Orderを発行します。
既存合同とのリンク
既存合同との関連を明示します。「基于5月1日签订的合同附件1,提出以下变更订单」のように。
追加金额の提示
追加金額を明示します。根拠(工数・時間単価)も示します。
签字流程
変更注文の署名フローを明示します。既存合同と同じく盖章が必要です。
クライアントの社内承認フロー
中国B2B変更注文の承認フローを理解します。
决策者の特定
変更承認の決裁者を特定します。通常、元の合同署名者と同じ人が決裁します。
複数承認の並行
大型変更は複数部門(采购・业务・法务)の並行承認が必要です。各部門の連絡先を把握します。
期限設定の交渉
承認期限を交渉で設定します。曖昧な期限では中国B2Bでは動きません。
拒绝・延期の表現
変更を断る場合の表現です。
当前阶段不可の理由
(1)「当前阶段不可实施」(2)「dāng qián jiē duàn bù kě shí shī」(3)「現段階では実施不可」と明示します。
理由として「影响当前交付日期」「与项目目标冲突」を挙げます。
Phase 2提案
Phase 2として別プロジェクトに切り出す提案をします。「建议作为Phase 2处理」と書きます。
代替案提示
完全拒否ではなく、縮小版の代替案を提示します。「我们可以实施XX,但YY需要推迟」のように。
頻発する変更依頼への対応
頻繁に変更依頼が来る場合、管理プロセスを強化します。
范围蔓延の早期検知
(1)「范围蔓延」(2)「fàn wéi màn yán」(3)「スコープクリープ」を早期検知します。月次で範囲変更量を測定します。
变更日志の蓄積
変更ログを蓄積すると、パターンが見えます。次回プロジェクトの参考になります。
定期レビュー設置
変更依頼のレビュー会を定例化します。週次または隔週です。
社内向けエスカレーション
変更依頼が重大な場合、社内エスカレーションします。
PM→客户经理→业务负责人
影響が大きい順に、PM・客户经理・業務責任者へエスカレーションします。
法务审核判断
契約条項に影響する変更は法务レビュー必須です。
チームへの影響共有
変更決定後、実行チームへ明確に共有します。情報不足でミスが発生します。
Change Request 例文8
シーン別のChange Requestメール例です。
即接受テンプレ
「李经理,收到您的变更需求(UI文案调整),此变更影响较小,我方可以在本周内免费实施,不影响整体交付日期,已安排设计团队处理,完成后会另行通知」が即接受テンプレです。
有条件接受テンプレ
「王总,收到贵司关于XX模块的变更需求,经过3日评估,此变更涉及:(1)追加开发工时10人日(2)测试工时5人日(3)交付日期延长2周(4)追加费用30万元,详细Change Order见附件,请审阅签字」が有条件接受テンプレです。
拒绝テンプレ
「张总,关于贵司提出的架构变更需求,经评估,此变更与当前项目目标冲突,且影响已完成的70%功能,建议作为Phase 2独立项目处理,我方可以提供Phase 2的详细方案」が拒绝テンプレです。
软件开发サンプル
「陈经理,关于新增支付接口集成的变更需求,评估如下:工时:15人日追加、交付:延期2周、费用:35万元、影响:需要重新进行安全测试,请确认是否接受」が软件开发サンプルです。
创意制作サンプル
「李总,关于海报设计风格变更的需求,评估如下:设计工时:5人日追加、费用:8万元、交付延期:1周、建议:如时间紧迫,可以保留原方案作为备选」が创意制作サンプルです。
管理咨询サンプル
「王总,关于研究范围扩大的需求,评估如下:调研工时:20人日追加、差旅费:15万元、报告复杂度:增加3个章节、交付延期:3周,请确认」が管理咨询サンプルです。
跨境电商サンプル
「陈经理,关于新增亚马逊日本站运营的需求,评估如下:月度运营费:20万元追加、首月启动费:30万元、预计3个月见效,建议6个月合同期」が跨境电商サンプルです。
物流供应链サンプル
「王总,关于运输路线调整的需求,评估如下:每单成本:增加15%、运输时间:延长1天、整体影响:需要调整库存策略,建议先做3个月试点」が物流サンプルです。
Change Request対応力を評価する指標
CR対応力の定量化指標です。
Turnaround Time
変更依頼受信から対応方針返信までの時間です。24時間以内が理想です。
承認率
提出したChange Orderの承認率です。高すぎると過小見積もり、低すぎると過大見積もりのサインです。
范围蔓延金额
当初契約金額からの変更追加総額です。10%以内が健全な範囲です。
CRで絶対書かないNG表現
Change Requestメールで避けるべき表現です。
感情的な拒否
「这个要求太过分」のような感情表現はNGです。常に論理的・定量的に説明します。
責任転嫁
「都是贵司需求变更导致」は責任転嫁に見えます。「需求变更带来影响」と客観的に書きます。
曖昧な見積もり
「大概需要几周时间」のような曖昧な見積もりは信頼を失います。具体的な日数・金額を示します。
Change Request Post-mortem
プロジェクト終了後のCR振り返りです。
项目結束後の振り返り
CR発生件数・原因分類・影響度・対応品質を振り返ります。
CR頻発原因分析
頻発した場合、要件定義の甘さか、クライアント側の戦略変更か、原因を特定します。
次项目への学び
分析結果を次プロジェクトに活かします。要件定義プロセスの改善が効きます。
Change Request関連記事
Change Requestと連動するクライアント対応トピックを確認します。
クライアント対応フロー
chinese-biz-email-clientではクライアント対応全体、chinese-biz-email-status-updateでは進捗報告を扱います。
chinese-biz-email-delivery-reportでは納品報告を解説しています。
トラブル対応・契約
chinese-biz-email-delay-escalationでは延期エスカレ、chinese-biz-email-nda-contract-reviewではNDA・合同审查を扱います。
chinese-business-emailはハブ記事です。
中国B2B特有のCR論点
中国B2Bには欧米・日本にないCR論点があります。
关系重視による口頭追加
中国B2Bでは关系重視で、正式なCR手続きを経ず口頭で「ちょっと追加して」と言われることがあります。
すべて書面化する原則を最初に合意しておきます。
春节前の駆け込み変更
春节前は「新年前に終わらせたい」心理で駆け込みCRが頻発します。事前に覚悟しておきます。
面子配慮での対応
小さいCRは面子配慮で即接受すると関係が強化されます。ただし頻発すると范围蔓延になります。
盖章必要なCRの管理
金額を伴うCRは盖章必須です。簡易な変更でも金額が付くなら正式手続きを踏みます。
CR管理のベストプラクティス
中国B2B Change Request管理のベストプラクティスを整理します。
CR管理表の作成
全CRを表で管理します。番号・依頼日・内容・影響・状態・決定日・担当者の7列で構成します。
飞书多维表格・钉钉项目管理・Notionで管理すると検索・フィルタが効きます。
CR番号の付与
(1)「CR-001」のように連番で管理します。後から参照しやすくなります。
影響度分類(Impact Level)
Level 1(軽微)・Level 2(中)・Level 3(重大)の3段階で分類します。
Level 1は即接受、Level 2は3日評価、Level 3は1週間評価のルールを決めておきます。
CR専用メールスレッド
各CRは専用メールスレッドで管理します。他の議論と混ざらないようにします。
週次CRレビュー会
週次でCRレビュー会を開催し、全CRの進捗と影響を確認します。
中国B2B CR交渉テクニック
Change Request交渉に使えるテクニックを整理します。
バンドル提案
複数の小さなCRをまとめて提案すると、単価が下がります。クライアント側も単位コストが下がって納得しやすくなります。
機能トレードオフ
「Aを追加する代わりにBを削減」のトレードオフ提案です。ゼロサムではない創造的解決になります。
段階的実装
大きなCRを小さなフェーズに分割します。Phase 1・Phase 2・Phase 3と段階的に実装します。
試行プロジェクト化
大規模CRを試行プロジェクトとして切り出します。リスクを限定しながら顧客のニーズを検証できます。
将来オプション化
現時点では実装しないが、将来実装する前提で設計します。顧客の将来性を保証します。
CR対応の地域別差
中華圏でCR対応の文化が違います。
大陸:速度重視・数字先行
大陸は数字先行で、定量的評価を先に示します。工数・費用・期限を先に示すのが効率的です。
台湾:婉曲・関係重視
台湾は関係重視で、CRも柔らかく処理します。「實屬不便」「另作安排」などの婉曲表現を使います。
香港:英中混在・契約重視
香港は契約条項を厳格に守ります。契約外の依頼は基本的に別契約として処理します。
シンガポール:書面化徹底
シンガポールは書面化を徹底します。口頭合意より書面のChange Orderが重視されます。
CR対応者のスキル育成
CR対応は専門スキルです。育成ポイントを整理します。
見積もりスキル
工数見積もりの精度がCR対応の鍵です。過去データと経験で精度を上げます。
交渉スキル
顧客との価格・期限交渉スキルが重要です。BATNA・ZOPA・Win-Winを意識します。
法務知識
契約条項の基本理解が必要です。变更条款・违约金・不可抗力を理解します。
中国ビジネス文化理解
关系・面子・盖章の中国特有文化を理解しないと、適切なCR対応ができません。
CR見積もり公式と実例
CR見積もりを定量化するための公式を整理します。
工数見積もり公式
基本工数 × 複雑度係数 × リスク係数 = 追加工数の公式です。
複雑度係数は1.0-2.0、リスク係数は1.1-1.5が標準です。新技術使用時は係数を上げます。
費用計算公式
追加工数 × 時間単価 + 外部委託費 + ツール費用 = 追加費用の公式です。
中国IT系の時間単価は300-2000元/時間が相場です。Senior・Principalは更に高くなります。
期限延長計算
追加工数 ÷ チームキャパシティ = 期限延長日数の公式です。
クリティカルパスに影響する場合は全体延長、並行できる場合は影響なしとなります。
リスク評価公式
発生確率 × 影響度 = リスクスコアです。High・Medium・Lowで分類します。
Change Order書式テンプレ
正式Change Orderに必要な項目を整理します。
基本情報セクション
CR番号・契約番号・プロジェクト名・日付を明示します。
変更内容セクション
変更前・変更後を対比して示します。差分が一目で分かるようにします。
影響評価セクション
工数・費用・期限・品質・他機能への影響を定量化します。
承認フローセクション
両社の署名権者・盖章欄を設けます。効力発生日を明示します。
添付資料セクション
詳細見積書・技術仕様書・テスト計画を添付リスト化します。
CR頻発時のプロセス見直し
Change Requestが頻発する場合、プロセス全体を見直します。
要件定義プロセスの強化
当初要件定義フェーズに十分な時間を投入します。中国B2Bでは2-4週間が標準です。
プロトタイプ・モックアップ・ユーザーテストを組み込みます。
ステークホルダーマッピング
意思決定者・影響者を事前に特定します。後から「上司がNG」と言われないためです。
アジャイル開発への移行
変更が多い場合、ウォーターフォールからアジャイルへの移行を提案します。
スプリント単位での変更吸収が可能になります。
固定価格から時間精算への切替
範囲が流動的な場合、固定価格契約から時間精算契約への切替を提案します。
Change Control Boardの設置
大型プロジェクトではChange Control Board(変更管理委員会)を設置します。両社のキーパーソンで構成します。


