収納代行サービス導入プロジェクトの進め方

収納代行サービスの導入は、「良さそうな会社を選んで契約すれば終わり」という単純なものではありません。
いざ導入を任された担当者が、何から着手すべきか分からず手探りで進めた結果、契約した後に「必要な機能が足りない」「社内の実務運用が全く決まっていない」「他部署の協力を得られない」といった深刻なトラブルに直面するケースは非常に多く見られます。

収納代行の導入は、会社の金流、基幹システム、そして顧客対応のあり方を大きく変更する「全社的な業務変革プロジェクト」です。
本ページでは、検討開始からサービス選定、稟議、契約、初期設定、テスト運用、そして本番開始後の効果測定にいたるまでの全工程を14のステップに分けて解説し、実務レベルでプロジェクトをスムーズに進めるためのガイドを提供します。

• 収納代行サービス導入を「プロジェクト」として進めるべき理由と全体像
• 検討・選定期（STEP1〜7）：課題整理から要件定義、稟議までの手順
• 準備・構築期（STEP8〜12）：審査契約からデータ準備、テスト、顧客案内
• 本番・運用期（STEP13〜14）：初回請求の注意点と稼働後の効果測定
• 進行時によくあるつまずき、成功のポイント、管理用チェックリスト

収納代行サービス導入はプロジェクトとして進めるべき理由

収納代行サービスは、経理・財務・営業・現場・システム・管理部門など、社内の非常に多くの部署に関わる仕組みです。
導入によって、顧客への支払い方法の提示、毎月の入金管理、自動消込、エラー時の未収対応、案内通知の送付など、これまでの日々の業務フローが根底から変わることになります。

これを特定の担当者任せで属進的に進めてしまうと、契約を結んだ後に「現場の営業から顧客対応の面で大反対された」「システム部門からデータ連携の仕様でNGが出た」といった問題が噴出し、プロジェクトが空中分解しかねません。
全社的なプロジェクトとして位置づけ、あらかじめ目的・役割・スケジュール・確認事項をクリアに整理しながら進めることで、部署間の連携ミスや手戻りを防ぎ、導入後の確実な運用定着を実現できるようになります。

導入プロジェクトの全体像

収納代行サービス導入プロジェクトは、主に以下の14ステップに沿って進行します。各フェーズのつながりを意識して全体像を把握しましょう。

• 検討・選定フェーズ：現状課題の整理（STEP1）⇒ 導入目的・ゴールの設定（STEP2）⇒ プロジェクトメンバー・関係部署の決定（STEP3）⇒ 導入要件の整理（STEP4）⇒ サービス比較・選定（STEP5）⇒ 見積もり取得・費用対効果試算（STEP6）⇒ 社内説明資料・稟議書の作成（STEP7）
• 契約・準備フェーズ：申込・審査・契約（STEP8）⇒ 初期設定・データ準備（STEP9）⇒ テスト運用（STEP10）⇒ 社内向けの運用ルール整備（STEP11）⇒ 顧客への案内（STEP12）
• 本番・改善フェーズ：本番運用開始（STEP13）⇒ 導入後の効果測定・改善（STEP14）

STEP1：現状課題を整理する

プロジェクトの第一歩は、社内の回収業務における「不の解消」のために、現在の実態を正確に洗い出すことです。

まず、現在の請求・入金管理フローを細かく書き出し、毎月の入金確認に合計何時間かかっているか、消込作業の具体的な件数や担当者の精神的・作業的な負担がどの程度あるかを正確に把握します。
あわせて、毎月の未収・延滞の発生件数、請求書や払込票の発行・郵送にかかる工数や実費、顧客からの支払い関連の問い合わせ内容を整理します。
このとき、経理担当者だけでなく、現場、財務、営業などそれぞれの部署の困りごと（「振込名義違いの追跡が辛い」「顧客からカードで払いたいと言われる」等）を漏れなく集めることが重要です。
現状の課題を数字と事実で整理しておくことで、この後のステップである導入目的や必要な要件をブレずに明確化できるようになります。

STEP2：導入目的とゴールを設定する

課題を整理したら、今回の導入プロジェクトによって「会社として何を変えるのか」という目的とゴールを定めます。

ゴールとして設定される主な項目には、「毎月の入金確認・消込作業の時間を〇%削減したい」「未収管理を強化し、滞納の検知スピードを上げたい」「口座振替やコンビニ収納など支払い方法を増やし、顧客利便性を向上させたい」「属人化していた請求・入金管理を標準化したい」「月末の月次締め作業を〇日早めたい」といったものが挙げられます。
ここで最も大切なのは、「収納代行サービスを導入すること」そのものを目的にしないことです。あくまで「回収業務全体のどの課題を、どれだけ改善するか」という具体的な着地点（KPI）をプロジェクトのゴールに据えてください。

STEP3：プロジェクトメンバーと関係部署を決める

全社最適な仕組みを構築するため、キックオフの早い段階で関係部署から担当者をアサインし、プロジェクトメンバーを確定させます。

• 経理部門：実際の入金データ確認、自動消込、仕訳処理などの実務要件を確認する
• 財務部門：代行会社からの入金サイクルが、社内の資金繰りやキャッシュフローに与える影響を確認する
• 営業・現場部門：新規顧客への支払い方法の説明手順や、既存顧客への案内方法、未収発生時の一次対応フローを確認する
• システム部門：顧客データ・請求データのCSV入出力、または自動同期のためのAPI連携、社内システムとの接続検証を行う
• 管理部門・経営層：委託契約書の法務チェック、個人情報管理ルールの整備、および投資対効果（費用）や導入方針の最終決裁を行う

このように、早い段階で各部署のキーマンを巻き込んでおくことで、「後から想定外の要望が出てきてプロジェクトがやり直しになる」という最大の後戻りリスクを防ぎやすくなります。

STEP4：導入要件を整理する

プロジェクトメンバーと共に、サービス会社へ見積もりを依頼したり選定を始めたりするための「要件定義（自社が求めるスペックの整理）」を行います。

具体的には、利用したい決済手段（口座振替、コンビニ収納、クレジットカード等）、月間の想定請求件数、現在の総顧客数・会員数、請求の発生頻度、請求金額のパターン（固定か従量か）、紙の請求書・払込票発行の要否を書き出します。
さらに、入金管理・自動消込・未収管理に求める具体的な機能レベル（例：決済失敗を即座にアラート抽出できるか等）や、CSV・API連携の必要性、社内の会計ソフト・基幹システムとの連携データの形式、顧客向けの案内・問い合わせ対応の範囲を整理します。
要件をまとめる際は、「絶対に譲れない必須要件」と「あれば好ましい希望要件」を明確に分けて整理することが、この後のベンダー比較をスムーズにするポイントです。

STEP5：サービスを比較・選定する

定義した要件をもとに、複数の収納代行サービスを横並びで比較し、自社に最適なベンダーをスクリーニングします。

比較表を作成し、対応している決済手段の網羅性、初期費用・月額費用・決済手数料などの料金体系、自社の資金繰りに合う入金サイクルの妥当性を精査します。
あわせて、管理画面の使いやすさ、自動消込や未収管理の機能の有無、請求書や払込票の発行・送付代行の有無、CSV・API連携の柔軟性を確認します。さらに、トラブル時に頼れるサポート体制や立ち上げ時の導入支援の有無、最低利用期間や解約条件などの契約縛りに問題がないかもチェックします。
すべての条件を同じ天秤に載せた比較表を作成し、社内でロジカルに判断・選定できる形に情報を整理します。

STEP6：見積もりを取得し、費用対効果を試算する

候補となるサービス会社複数社から、まったく同じ件数・金額の前提条件を指定して相見積もりを取得します。

見積書が届いたら、初期費用、月額費用、決済手数料、件数に応じた従量課金やオプション費用を項目ごとに細かく分解して整理し、月間トータルコストおよび年間トータルコストの試算を出します。
その上で、STEP1で算出した「現在の作業時間や間接人件費」と比較し、導入によって入金確認・消込・未収管理の工数がどの程度浮くのか、実質的な削減効果（ROI）を見積もります。
ここでは、金額換算できる定量効果だけでなく、未収金の減少、問い合わせの削減、ヒューマンミスの防止といった「定性効果」もあわせて整理し、「単なる費用の支出ではなく、コストを上回る業務改善効果がある投資であること」を社内説明できるように準備します。

STEP7：社内説明資料・稟議書を作成する

ここまでに集めたプロジェクトの成果を、決裁者が一目で承認できる稟議書および社内説明資料として一本のドキュメントにまとめます。

資料の構成は、検討に至った導入背景、数字で示す現状課題、達成すべき導入目的をストーリーとして最初に記載します。
その上で、複数社を比較したプロセスと今回のサービスを選んだ論理的な選定理由、発生する導入費用・ランニングコスト、試算した費用対効果（投資回収期間）を明記します。
さらに、導入後の新しい業務フロー、各部署ごとの具体的な役割分担（RACI）、本番稼働までのスケジュール、想定されるリスクとそれに対する具体的な解決策（バッファ）を漏れなく記述します。
社内承認に必要なすべての材料を過不足なく美しくまとめることが、一発で決裁を通すための実务的なポイントです。

STEP8：申込・審査・契約を進める

社内の承認（稟議の決済）が下りたら、選定した収納代行会社へ正式な申込手続きを行います。

申込書の提出とともに、会社概要、事業内容、取扱商材の資料やパンフレットのほか、料金表、利用規約、顧客との契約関係（返金ルール等）が分かるエビデンス資料、代表者情報、入金用の口座情報など、契約に必要な書類を不備なく準備して提出します。
ここから決済手段（特に口座振替やコンビニ収納、クレジットカード）ごとに金融機関やカードブランドによる厳格な「審査」が始まります。
審査を通過した後は、最終的な契約書面において、料金条件、入金サイクル、サポート範囲、および返金や誤入金、未収対応における両社の責任境界線を再確認します。
審査や金融機関の登録手続きには通常1〜2ヶ月以上の時間がかかるケースが多いため、プロジェクトのスケジュールはこれを見込んでタイトに引かないよう注意してください。

STEP9：初期設定・データ準備を行う

契約が完了し、システムの利用権限が付与されたら、本番稼働に向けた環境構築とデータのマスター準備に着手します。

まず、管理画面のマスターアカウントを設定し、プロジェクトメンバーや経理・現場の担当者ごとに「閲覧のみ」「編集可」といったセキュリティ権限を適切に割り当てます。
同時に、最も重要な作業として、既存の顧客データをシステムのインポート形式に合わせて綺麗にクレンジング（整備）します。顧客IDや請求番号の発行ルールを再定義し、システムエラーが起きない請求データの登録フォーマットを確定させます。
また、口座振替の用紙登録やWeb受付設定、コンビニ払いのバーコード帳票フォーマットの確認、CSV・API連携の接続設定を進め、会計ソフトや社内の基幹システムへデータをスムーズに取り込める（エクスポートできる）形式になっているかを、システム担当者とともに厳密に確認・設定します。

STEP10：テスト運用を行う

本番の顧客に請求を行う前に、ダミーの請求データを使用して、システムが設計通りに稼働するかを徹底的にテストします。

テスト用の請求データを実際にシステムへ登録し、お客様側の支払い画面や紙の払込票の表示が正しいか、コンビニ払いやカード決済を行った際に「支払いステータス」が管理画面へ即座に反映されるかを確認します。次に入金データの取得・出力を行い、自動消込の結果が経理ソフトへ正しくインポートされるかをチェックします。
特に重要なのは、口座引落不能やカード決済失敗といった「未入金・エラー時の表示」が正しく行われるか、また万が一の返金、金額の取消、誤入金が発生した際の修正対応フローが破綻なく動くかの検証です。
初回本番運用でパニックにならないよう、経理、現場、システムの全担当者が集まってテスト結果をトリプルチェックします。

STEP11：社内向けの運用ルールを整備する

テスト運用でシステムの動きを確認したら、日々の実務を迷わず回すための社内向けの業務マニュアルやルールを整備します。

「毎月の請求データは、誰が、いつまでにシステムへ登録するのか」「日々の入金状況やエラー画面は、誰が確認するのか」「決済に失敗した未入金者を誰が抽出し、どのタイミングで誰が顧客へ再請求・督促の連絡をするのか」という実務の流れを明確にします。
また、顧客からの支払いに関する問い合わせ窓口の定義（現場なのかCSなのか）、返金や請求取消時の社内承認フロー、最終的な会計ソフトへのデータ反映手順、データ連携エラー発生時のシステム部門へのエスカレーションルールをマニュアルやFAQとして落とし込みます。
誰が何を行うかの役割分担をこの段階で完全に明確にしておかないと、導入後に必ず業務の押し付け合いや放置トラブルが発生するため、細部まで文字化しておくことが不可欠です。

STEP12：顧客への案内を行う

社内の体制が整ったら、新しい支払い方法への変更について、顧客に対して丁寧かつ分かりやすい案内（アナウンス）を開始します。

案内文には、新しい支払い方法が開始される具体的な時期、口座振替依頼書の提出手順やWeb口座振替の登録方法、コンビニ払いの利用方法や支払い期限、クレジットカード情報の登録URLなどを明記します。当然、顧客側が負担する手数料の有無や、困ったときの問い合わせ先窓口も分かりやすく記載します。
既存の支払い方法（例：これまでの銀行振込など）から強制的に切り替える場合は、顧客側の混乱を避けるために「数ヶ月間の並行運用の移行期間」を設けるのが鉄則です。
現場がスムーズに対応できるよう、よくある顧客からの質問をまとめたFAQや、メール・架電対応用のテンプレートを事前に準備して営業やCSへ配布しておきます。

STEP13：本番運用を開始する

すべての準備と案内が完了したら、いよいよ実際の顧客請求データをシステムへ登録・送信し、本番運用を開始します。

初回の請求データが破綻なく送信されたかを確認し、期日に向けて顧客の支払い状況や代行会社からのリアルタイムな入金データを管理画面で注視します。
データの自動消込結果が仕訳データとして会计ソフトへ正しく連携されているか、口座振替不能やカード決済失敗の顧客がダッシュボードへ正しく抽出されているかを確認します。
初めての本番運用（初月）は、想定外の顧客の操作ミスやデータの不整合が最も起きやすいタイミングのため、通常よりも社内の確認体制を厚く配置しておくことがプロジェクト管理上のコツです。
初回運用で発生した顧客からの問い合わせ内容や運用のつまずきはすべて記録し、即座に社内ルールや案内文の改善へフィードバックします。

STEP14：導入後の効果測定と改善

本番運用が2〜3ヶ月ほど経過し、運用が軌道に乗った段階で、プロジェクトの当初の目的（STEP2のゴール）が達成できているかの効果測定を行います。

具体的には、現在の入金確認にかかった時間、消込作業にかかった時間、未収者の特定や実際の対応・督促にかかった実作業時間を計測し、導入前の数字と比較してどれだけ人件費・工数が削減されたかを可視化します。また、請求ミスや入金漏れの発生件数、顧客からの支払い関連の問い合わせ件数の推移をチェックします。
さらに、未収金額の総額や一次回収率の改善度合い、月末の月次締め処理にかかる日数の短縮変化を確認し、「実際に支払っているサービス利用料」に対して「削減された工数・財務メリット」がプラス（ROIがプラス）になっているかを経営層へ事後報告します。必要に応じて、決済手段のプラン見直しや、社内運用のさらなる効率化・改善へとつなげます。

プロジェクト進行でよくあるつまずき

多くの企業が収納代行導入プロジェクトの途中で陥りがちな、代表的な失敗・つまずきパターンを解説します。

• 目的の曖昧さとベンダー迷子：「経理をなんとなく楽にしたい」という曖昧な目的のまま手当たり次第にサービスを比較し始め、各社の部分的な機能や安さのノイズに惑わされて選定が長期化するつまずき。
• 他部署の置き去りと後半の大反対：経理部門だけでプロジェクトをクローズドに進めてしまい、契約直前になって現場から「顧客対応のフローが組めない」、あるいはシステム部門から「社内データベースとCSVの形式が合わず自動連携できない」と要件が後出しされ、プロジェクトがストップする失敗。
• 資金繰りの考慮漏れ：サービス会社の入金サイクル（締め日・支払日）の確認を後回しにしたため、自社口座へ現金が戻るタイミングがこれまでより遅くなり、会社のキャッシュフローに一時的な負担を与えてしまうつまずき。
• 顧客案内不足による初回パンク：顧客への移行案内やマニュアルの配布が不十分、または移行期間をタイトにしすぎたために、初回請求日に顧客からの「登録方法が分からない」「払込票が使えない」といった問い合わせが殺到し、現場の対応窓口がパンクしてしまう失敗。

プロジェクトをスムーズに進めるポイント

つまずきを回避し、予定通りのスケジュールでプロジェクトを成功へ導くための不可欠な成功法則です。

• 1. 課題とゴールの「文字化」：最初に現状の作業時間（数字）と導入目的を全社で明確に共有し、必須要件とあれば良い希望要件を冷徹に切り分けておくこと。
• 2. 早期の横串チーム結成：STEP3の段階で、経理だけでなく財務、現場、システム、管理の各部門から担当者を巻き込み、定期的なミーティングで進捗と変更点を共有すること。
• 3. 見積・契約条件の「統一」：相見積もり時は件数条件を完全に統一した比較表を作成し、契約前に入金サイクル・総費用・サポート境界線をシビアに確認すること。
• 4. 初期データ整備の先回り：アカウントが発行される前の審査期間（STEP8）を有効活用し、社内の既存顧客データのクレンジングやIDルールの整理を前もって終わらせておくこと。
• 5. 例外処理のテストと振り返り：テスト運用時は正常系だけでなく、残高不足やカードエラーなどの「異常系（例外処理）」まで意図的に発生させて挙動を確認し、本番開始後は必ず全社で振り返りミーティングを行うこと。

プロジェクト管理で使えるチェックリスト

各フェーズの進捗確認や、タスクの抜け漏れ防止としてプロジェクトミーティングでそのまま使えるチェックリストです。全てにチェックが入るよう進行を管理してください。

確認フェーズ	チェック項目（タスク内容）	確認状況
企画・立案	現在の各部署の作業時間や課題（数字）が具体的に棚卸しされ、導入目的・KPIが明確になっているか	[ ] 完了
体制構築	経理・財務・現場・営業・システム各部門の担当者がアサインされ、プロジェクトチームが発足しているか	[ ] 完了
要件定義	月間の想定請求件数、必要な決済手段、基幹システムや会計ソフトとのデータ連携形式が確定しているか	[ ] 完了
選定・稟議	見積条件を統一したサービス比較表および社内説明資料が完成し、決裁者の稟議承認（予算獲得）が得られているか	[ ] 完了
契約・審査	契約に必要な法人の証明書類や商材規約が用意され、決済手段ごとの審査スケジュールが確保されているか	[ ] 完了
データ準備	システムにインポートするための社内顧客データ・請求データのクレンジング、顧客IDルールの再定義が終わっているか	[ ] 完了
設定・テスト	管理画面の権限設定やデータ連携のテスト運用が完了し、エラー発生時や返金時の挙動まで全部署で確認済か	[ ] 完了
マニュアル	誰がデータを登録し、誰が未収を追うか等の社内役割分担（マニュアル）や、現場用の顧客対応FAQが完成しているか	[ ] 完了
顧客案内	移行期間を設けた顧客向けの支払い方法変更の案内文（マニュアル付）が用意され、適切なタイミングで発送されているか	[ ] 完了
本番・測定	初回運用時の厚いフォロー体制が組まれ、稼働数ヶ月後に検証するための効果測定項目（KPI）が決定しているか	[ ] 完了

まとめ｜確実なプロジェクト管理が、強固な回収インフラをつくる

収納代行サービスの導入は、単なるツールの契約手続きではなく、社内の業務フロー、関係部署の役割分担、顧客案内、システムデータ連携、そして導入後の運用定着までをトータルで設計・コントロールする「一大プロジェクト」として進めることが成功への必須条件です。

現状課題の徹底的な整理から始まり、要件定義、ベンダーのロジカルな比較、社内稟議の獲得、審査・契約、初期データクレンジング、徹底したテスト運用、そしてマニュアル整備というステップを順序正しく踏んでいくことで、抜け漏れや手戻りのない確実な立ち上げが可能になります。

プロジェクトを進める際は、経理部門だけの視点に閉じこもるのではなく、財務、現場、営業、システム、管理部門など、すべての関係者を早い段階から巻き込み、密な合意形成を図ることを心がけてください。
導入前には、トータル費用や資金繰りに直結する入金サイクル、トラブル時のサポート範囲、自社の対応責任範囲を明確に定義し、本番開始後は当初の目的である「作業時間の削減」や「未収・回収率の改善」を定期的に効果測定して、運用のブラッシュアップを継続しましょう。価格の安さだけに囚われず、自社の回収実務と組織の体制に100%フィットする強固な集金インフラをプロジェクトを通じて構築し、企業の持続的な成長基盤を整えてください。

よくある質問（Q＆A）

Q1. 収納代行の導入プロジェクトを立ち上げる際、全体の指揮を執る「プロジェクトマネージャー（責任者）」は、経理部門とシステム部門のどちらから選出するのが適切ですか？

A. 原則として、日々の集金運用の主幹となり、課題の当事者である「経理部門（あるいはバックオフィス責任者）」から選出するのが最も適切です。システム部門の担当者は、データ連携やセキュリティ基準の担保において非常に重要な役割を果たしますが、彼らは『システムが繋がるか』の視点で動くため、実務上の細かい例外処理や、現場の営業と連携した顧客への督促・返金フローといった「業務運用」の設計までを主導するのは困難です。経理側がプロジェクトの舵を握り、IT側は技術的な強力なサポーター（副責任者）として位置づける体制が最もスムーズに進行します。

Q2. 検討開始（STEP1）から、実際に本番運用（STEP13）を開始して初回の入金が自社口座に確認されるまで、一般的にどのくらいのプロジェクト期間を見ておくべきですか？

A. 企業の規模やシステム連携の有無によりますが、一般的には「最短でも3ヶ月〜4ヶ月程度」のプロジェクト期間を見ておく必要があります。社内選定や稟議承認に約1ヶ月、申込から各種金融機関やカードブランドによる「審査・登録手続き」の完了までに約1〜2ヶ月（特に口座振替の金融機関登録は時間がかかります）、その後の初期設定・データ準備・テスト運用と顧客への移行案内期間に約1ヶ月を要するためです。このリードタイムを無視して「来月から動かしたい」とタイトな計画を立てると、審査の遅れや顧客の口座登録が間に合わず、初回の集金が破綻するリスクが高まります。

Q3. テスト運用（STEP10）を行う際、マニュアル通りの正常な入金確認だけでなく、具体的にどのような「異常系の例外パターン」をテストしておくべきですか？

A. 実務で必ず発生する「顧客の口座残高不足（引落不能）」「クレジットカードの有効期限・限度額エラー」「コンビニ払込票の支払い期限切れ」、そして「二重払い（誤入金）や、請求金額と異なる金額の振込」の4パターンは必ずテスト環境で再現させてください。これらのエラーが起きた際、管理画面上でどのようなステータス（文言）で表示されるか、未入金者リストへ自動で抽出されるか、また社内で『誰がそのエラーを検知し、どうリカバリーするか』の動線を確認しておくことが、本番開始後の現場の混乱を予防する最大の防御策となります。

Q4. 既存顧客の支払い方法を新しい収納代行システムへ切り替えてもらう際、顧客側から「変更が面倒」「今のままでいい」と強い抵抗感を示されるリスクへの資料上の対策は？

A. 顧客への「移行期間（並行運用期間）」の長さと、現場の営業が説明しやすい「顧客側の直接的なメリット」をプロジェクト計画資料に明記してください。変更を急に強制するとクレームになりますが、例えば『3ヶ月間は従来の銀行振込も受け付けるが、以降は順次移行する』というバッファを設けます。また、顧客に対しては「コンビニやカードが使えて夜間でも払えるようになるため、銀行に行く手間や振込手数料の負担がなくなります」という『利便性の向上（サービス改善）』の文脈で案内文を設計することを、営業現場とあらかじめ約束・共有しておくことで、移行の摩擦を最小限に抑えられます。

Q5. 本番運用開始（STEP13）の最初の1ヶ月目において、プロジェクトチームが最も警戒し、リソースを割いて注視すべきポイントは何ですか？

A. 「顧客からの問い合わせ件数の推移」と「データ連携（CSVインポート・エクスポート）時のエラー発生の有無」です。どれだけ入念にテストを行っても、初回は『請求データのアップロード時に特定の文字コードでエラーが出る』『お客様がスマートフォンの操作方法を間違えて二重決済してしまう』といった想定外のヒューマンエラーやシステムトラブルが必ず発生します。初回請求日から約1〜2週間は、経理・現場・システム担当者のスケジュールに余裕を持たせ、トラブル発生時に即座に集まって個別対応・データ修正ができる「緊急対応体制」を維持しておくことが、プロジェクトを無事に着地させるための鉄則です。