仕様変更依頼は、相手のスケジュールと予算を揺らす行為です。
インドネシアでは「条件付受諾文化」が根強く、全面拒否は関係悪化に直結します。
このページでは衝突を避けながら変更を通すための3段構造を、ジャカルタの実務に基づいて整理します。
Astra系列やTokopediaのプロジェクト管理現場で実際に流通している型を基準にしています。
変更要請3段構造
変更依頼メールは3つのブロックで構成します。
順序を変えると、相手のapproval lineで質問が増え、合意までの時間が伸びます。
第1段：変更事由の明示
「なぜ変更が必要か」を最初に書きます。
事由が曖昧だと「ベンダー側の都合」と誤解され、追加費用の交渉が不利になります。
クライアント事由、ベンダー事由、外部要因の3区分を意識して書き分けます。
第2段：影響評価
日程、費用、品質、スコープの4軸で影響を定量化します。
「軽微な影響です」では合意が出ません。
%や日数で示すことで、approval lineが意思決定しやすくなります。
第3段：承認要請と代替案提示
「どうしますか」ではなく「A案推奨、B案/C案も可能」と選択肢を出します。
選択権を相手に渡すことが、インドネシア式の礼儀です。
選択肢を3つ提示すると、Direkturが意思決定しやすくなります。
件名の様式
件名で変更要請であることを明示します。
「[Permintaan Perubahan] Fitur 〜 – Proyek 〜」型
Permintaanは「依頼」、Perubahanは「変更」の意です。
例として「[Permintaan Perubahan] Fitur Login – Proyek Mobile App」と書きます。
角括弧があると、クライアント側のフィルタールールで優先処理されやすくなります。
緊急度表示（[URGENT][PRIORITAS]）
緊急時は件名先頭に「[URGENT]」を追加します。
「[PRIORITAS]」は「優先」の意で、URGENTより一段下の緊急度を示します。
多用すると効力が薄れるため、本当に必要な時だけ使います。
第1段：変更事由
事由は具体的に、かつ責任の所在を明確にします。
「Karena perubahan kebutuhan klien」
クライアント側の事情で変更が発生した場合の表現です。
意味は「クライアントの要件変更により」です。
この事由なら追加費用の交渉が成立しやすくなります。
「Karena ditemukan kendala teknis」
技術的な障害が発見された場合に使います。
「技術的な問題が見つかったため」の意です。
ベンダー側に責任がある場合と、設計段階の見落としで双方責任の場合に分かれます。
「Karena perubahan situasi pasar」
市場環境の変化を理由にする表現です。
競合の動きや法規制の変化など、双方が制御できない要因を示します。
UU PDP施行のような法改正は、この事由に該当します。
「Berdasarkan hasil review internal」
「社内レビューの結果に基づき」の意です。
ベンダー側の自発的な改善提案として変更を持ち込むときに使います。
この事由は信頼を高めますが、追加費用の交渉は不利になります。
第2段：影響評価
影響は4軸で定量化します。
日程影響（遅延日数）
「Akan ada keterlambatan sekitar 5 hari kerja」のように営業日数で示します。
カレンダー日数と営業日数を混同すると、Lebaran連休やHari Kemerdekaan（独立記念日、8/17）を跨いで認識がずれます。
必ず「hari kerja（営業日）」と明記します。
費用影響（追加工数）
「Biaya tambahan sekitar IDR 50.000.000 untuk 10 man-days」と書きます。
man-daysを使うのは、テック系で標準化されています。
BUMNやBank Mandiriでは「人月（orang-bulan）」表記が好まれます。
品質影響（リスク）
機能省略、テスト期間短縮、保証期間短縮の3カテゴリで示します。
「Risiko: pengurangan cakupan testing dari 100% menjadi 80%」のように具体数字を入れます。
品質リスクを隠すと、納品後のクレームに直結します。
スコープ影響（拡大・縮小）
機能数や対象範囲の増減を明示します。
「Penambahan 3 fitur, pengurangan 1 fitur」のように増減両方を書きます。
純増だけでなく純減も含めることで、価格交渉の根拠になります。
第3段：承認要請
承認要請はapproval lineを意識して書きます。
Approval line明示（Manager → Direktur → VP）
「Mohon persetujuan dari Bapak/Ibu Manager terlebih dahulu, kemudian akan kami eskalasi ke Bapak/Ibu Direktur」と段階を示します。
段階を飛ばすと、面子（muka）の問題が発生します。
BUMNでは6〜8階層のapproval lineが普通です。
承認期限の提示
「Mohon arahan paling lambat hari Jumat, 25 April 2026, pukul 17.00 WIB」のように日時を明示します。
WIBはWaktu Indonesia Barat（西部標準時）の略で、ジャカルタ時間です。
WITA（中部、バリ・スラウェシ）、WIT（東部、パプア）と区別します。
緊急承認要請時のクッション
急ぎの場合は「Mohon maaf atas urgensi ini」と冒頭に置きます。
「急いでください」を直訳すると無礼に響きます。
「ご理解いただけますと幸いです」の意で「Mohon pengertiannya」を末尾に添えます。
代替案提示の重要性
代替案がない変更要請は、インドネシアでは半ば失礼です。
「Opsi A／B／C」で選択権付与
3案を並べることで、相手に意思決定の余地を与えます。
1案だけ提示すると「強要された」と受け取られます。
2案だと「選ばされた」と感じる人もいるため、3案が安全圏です。
各代替案の影響比較
表形式で比較するのが標準です。
日程、費用、品質の3軸で各案を並べます。
Excel添付でもメール本文の表でも、いずれの場合も比較軸を統一します。
推奨代替案の明示
「Kami merekomendasikan Opsi A」と推奨を明示します。
推奨理由を1〜2行で添えます。
推奨を出さないと「ベンダーが責任から逃げている」と誤解されます。
変更発生原因の責任区分
責任を曖昧にすると、追加費用の交渉が成立しません。
クライアント事由時の要請
「Sesuai permintaan tim Bapak/Ibu pada rapat 20 April」と日付と会議名を明示します。
誰が何を言ったかを記録に残すことが、後の費用交渉の根拠になります。
議事録（Notulen Rapat）を別途添付するとさらに確実です。
ベンダー事由時の謝罪（Mohon maaf）
ベンダー側のミスは「Mohon maaf yang sebesar-besarnya」で謝罪します。
謝罪後すぐに対応案を提示することが、信頼回復の鍵です。
謝罪文だけで終わると「対応する気がない」と受け取られます。
外部要因時の共同対応
UU PDPやUU Tipikorのような法改正、為替変動、輸入規制などは双方の責任ではありません。
「Karena faktor eksternal, mohon kerja sama untuk mencari solusi bersama」と書きます。
共同対応の姿勢を見せることが、長期関係に響きます。
費用増減の交渉
費用交渉は別メールで切り出すこともあります。
追加工数の算定方法
man-days、orang-bulan、人月のいずれか1つに統一します。
1 man-day = 8時間労働が標準です。
残業を含める場合は「1 man-day inklusif lembur」と明記します。
見積書更新（e-Faktur影響）
e-Faktur Pajak（電子インボイス）の再発行が必要になります。
PPN 11%（付加価値税）の計算もやり直します。
NPWP（納税者番号）の確認も忘れずに行います。
精算方法の提案
追加分を月次精算するか、最終納品時にまとめて精算するかを提案します。
「Pembayaran tambahan dapat diproses sekaligus pada milestone berikutnya」のように具体策を示します。
BCAやBank Mandiriの送金では送金手数料も発生するため、誰が負担するかを明記します。
変更後のフォロー管理
変更が承認されてからが本番です。
変更後最初の週の進捗報告
変更承認の翌週は、通常の週次報告に「Update Pasca Perubahan」セクションを追加します。
変更が想定通り進んでいるかを定量化して示します。
2〜3週間継続すれば、信頼が再構築されます。
再発見された影響の即時共有
変更後に新たな影響が発見されたら、その日のうちにメール+WhatsAppで知らせます。
翌週まで待つと「隠していた」と取られます。
WhatsApp Businessでの即時連絡が、インドネシアでは標準動作です。
学習事項の整理
プロジェクト終了時に「Pelajaran (Lessons Learned)」として変更履歴を整理します。
次回プロジェクトでの再発防止に活用します。
Astra系列ではこの文書化が標準プロセスです。
顧客主導変更要請への対応
クライアントから変更要請が来た場合の応答もパターン化します。
要請受付確認メール
「Terima kasih atas permintaan perubahan. Kami akan melakukan evaluasi dampak dan kembali dalam 3 hari kerja」と即時返信します。
3 hari kerjaは「3営業日」の意です。
受付確認は24時間以内が標準です。
影響評価期間の案内
評価に何日かかるかを明示します。
「Evaluasi membutuhkan waktu 5 hari kerja karena perlu konsultasi dengan tim teknis」のように理由も添えます。
評価期間中は週次報告で進捗を伝えます。
受諾、調整、拒否の判断
受諾なら「Setuju」、調整なら「Setuju dengan kondisi 〜」、拒否なら「Mohon maaf, tidak dapat dilaksanakan karena 〜」と返信します。
全面拒否は最後の手段です。
条件付受諾を最大限模索するのがインドネシア式です。
インドネシア特有の「条件付受諾」文化
「No」と言わず、条件をつけて「Yes」に変えるのが現地流です。
全面拒否は関係悪化
「Tidak bisa」と直接拒否すると、その案件だけでなく今後の関係にも影響します。
面子（muka）を潰す行為と受け取られます。
長期関係を重視するインドネシアでは致命的です。
「Jika ditambahkan 〜, kami bisa lakukan」
「〜が追加されれば、対応可能です」の意です。
条件を提示することで、相手に再交渉の余地を与えます。
「Jika diberikan tambahan waktu 1 minggu」「Jika ditambahkan biaya」など条件のバリエーションを持ちます。
譲歩構造の設計
こちらが何を譲り、何を得るかを設計してから交渉に入ります。
「日程は譲るが、費用は確保」のような優先順位を内部で決めておきます。
その場で考えると、相手の押しに負けやすくなります。
日本人の変更要請NG3選
失敗のパターンは決まっています。
影響評価なしの変更提案
「変更したい」だけのメールは、approval lineで止まります。
必ず影響を4軸で定量化してから送ります。
定量化なしの変更提案は「準備不足」と評価されます。
Approval line CC漏れ
担当者だけに送って上司に伝わっていないと、後で「聞いていない」と差し戻されます。
段階的にCCを広げるのが安全です。
BUMNでは特にこの失敗が多いです。
「若干の変更」の曖昧さ
「sedikit」「kecil」など曖昧な形容詞は使いません。
必ず数字で示します。
「3% delay」「IDR 5 juta tambahan」のように具体化します。
具体的な変更要請メールの完成例
ここまでの要素を組み合わせた完成例を示します。
件名: [Permintaan Perubahan] Fitur Login Multi-Factor – Proyek Mobile App E-Wallet
本文冒頭: Yth. Bapak Andi Pratama, Salam hormat,
第1段（事由）: Berdasarkan hasil review internal pada 22 April 2026, kami menemukan bahwa fitur login multi-factor authentication memerlukan revisi karena perubahan regulasi OJK terkait keamanan transaksi e-wallet.
第2段（影響）: Dampak yang diperkirakan adalah keterlambatan 7 hari kerja, biaya tambahan IDR 75.000.000 untuk 15 man-days, serta pengurangan testing scope dari 100% menjadi 90%.
第3段（代替案）: Opsi A (rekomendasi): Tambah 7 hari, biaya IDR 75jt, scope penuh. Opsi B: Tambah 3 hari, biaya IDR 30jt, scope 80%. Opsi C: Tunda fitur ke fase 2, biaya IDR 0, scope sekarang.
結語: Mohon arahan paling lambat hari Jumat, 25 April 2026, pukul 17.00 WIB. Hormat saya, [署名]
署名にはWhatsApp Businessの番号、e-mailアドレス、会社住所（Jakarta CBD周辺なら詳細番地まで）を含めます。
業界別の変更要請の特徴
業界によって変更要請の難易度が大きく違います。
テックスタートアップ（Gojek、Tokopedia、Traveloka）
変更を歓迎する文化があり、「Pivotする勇気」を評価します。
Slack や Notion 上での即時議論が標準で、メールは記録用です。
「Hi Andi, can we change the scope?」のような英語混じりも自然です。
製造業（Astra、Indofood、Unilever Indonesia）
承認プロセスが厳格で、変更には2週間以上かかります。
SOP（Standard Operating Procedure）の改訂を伴う場合は1ヶ月見ます。
承認書類は紙ベースで、Cap Perusahaan（法人印章）が必要なこともあります。
金融（Bank Mandiri、BCA、BNI、BRI）
OJK（金融庁）の規制対応で変更が頻発します。
コンプライアンスチームのレビューを必ず通します。
変更要請メールには、規制根拠（POJK番号など）を明記すると話が早くなります。
BUMN（Pertamina、PLN、Telkomsel、Garuda Indonesia）
変更プロセスはもっとも厳格で、approval lineは8階層です。
承認に1〜2ヶ月かかることも珍しくありません。
e-Procurement（LPSE）に再登録が必要なケースもあります。
関連記事
インドネシアビジネスメール完全ガイドでは基本作法を扱います。
進捗報告のリズムは週次報告メールを参照してください。
納品時の連絡は納品完了報告メールでまとめています。
謝罪表現の使い分けは謝罪メールを確認してください。
依頼の基本表現は依頼メールに整理しています。
