BTMが浸透しない理由と乗り換えの判断

BTM（出張管理システム）を導入したのに、気づくと半分の出張が従来どおり各自の予約サイトで手配されている。請求書は相変わらず何通も届き、経理の作業は減っていない。契約更新の時期が近づき、「このシステムが悪いのではないか」と乗り換えを検討し始める——これは珍しい話ではありません。

ただ、乗り換えれば直る原因と、乗り換えても直らない原因があります。切り分けずに別のBTMへ移ると、移行コストだけ払って同じ場所に戻ります。本記事では、浸透度の測り方、原因の切り分け、乗り換えを決める基準、移行時に持ち出すべきものを順に整理します。

この記事の要点

• 浸透度を測る指標は利用率（BTM経由の手配件数 ÷ 全出張件数）の1つだけでよい。アカウント発行数やログイン数では実態が見えない。
• 9割はBTMの構造的な上限であって、目指すべき目標値ではない。業界最上位の公開実績でも、最もうまくいった顧客で9割。残りの1割は運用努力では埋まらない。
• 原因は5つに分けられ、そのうち乗り換えで直るのは3つだけ。残り2つはBTMを変えても再発する。
• 乗り換えを決める基準は4つ。利用率が6か月で5割を超えないことが最初の分岐点。
• 承認と手配が別々のシステムに分かれているという原因は、BTMの優劣ではなく順序の問題なので、乗り換えでは解決しない。

浸透度は「利用率」ひとつで測る

まず現状を数字にします。見るべきは1つだけです。

利用率 ＝ BTM経由の手配件数 ÷ 全出張件数

分母の「全出張件数」は、出張申請の承認件数から数えるのが正確です。BTMの管理画面だけを見ていると、そもそもBTMを通らなかった手配が分母から落ちるため、利用率は常に高く見えます。

アカウント発行数やログイン率は使えません。アカウントを持っていて月に一度ログインするが、実際の予約は個人のサイトで済ませている、という状態を拾えないからです。

なぜ高い利用率が要るのか

BTMの価値は集約にあります。請求の一本化も、出張データの分析も、危機管理での所在把握も、全件が通って初めて成立します。7割が通っていても、残り3割のために立替精算の仕組みと個別の請求処理を残さなければならず、管理部門の作業はほとんど減りません。

半端な利用率は、費用だけが二重になる状態です。BTMの利用料を払いながら、従来の立替精算と個別請求の処理も残っている。これが「導入したのに楽になっていない」の中身です。

利用率が5割を切っているなら、それは「使いにくい」ではなく「使われていない」状態です。

ただし、9割が上限になる

ここで注意すべきことがあります。利用率は100%にはなりません。

AI Travelは、活用が定着した導入企業では出張手配の9割以上が同サービス経由になると公開しています（提供元のトランスファーデータ社が自社実績として発表したもので、第三者の測定ではなく、母数の定義も公開されていません）。

この数字は、目標値としてではなく上限の目安として読むべきものです。「活用が定着した企業で」と母数を絞ったうえで、なお9割という表現になっているからです。業界で上位にあるサービスが、最もうまくいっている顧客について語って9割。残りの1割は、周知や教育では埋まらない領域だと考えたほうが実態に合います。

1割が残る理由

埋まらないのは、機能や使い勝手の問題ではありません。BTMが「手配のチャネル」でしかないことに起因します。

承認はBTMの外にあります。既存のワークフロー（kintone、Microsoft 365、Teams、Google Workspace）か、あるいは口頭やメールです。すると次の2つがどちらも可能なままになります。

• 承認を通さずに、自分で予約する
• 承認だけ通して、手配は各自でする

この2つが可能であるかぎり、利用率は運用努力で押し上げるしかない数字です。そして押し上げきれない具体的な残余が、必ず出てきます。

• 出張者が個人のマイルやポイントのために自分で予約する
• 取引先や主催者が手配した分（学会・展示会のパッケージ、招聘出張）
• BTMの在庫に無いもの（地方の小規模宿、高速バス、レンタカー）
• 直前・深夜の変更で、現地から電話対応になった分

つまり、利用率を9割から先に伸ばす取り組みは、費用対効果が急激に悪化します。5割から7割は運用改善で届きますが、9割から10割は届きません。ここに労力を使うくらいなら、次章の原因の切り分けに回すべきです。

浸透しない5つの原因

1. 自分で予約したほうが早い

多機能なほど画面は複雑になります。どこを押せば手配できるか分からない、候補を絞るのに手数がかかる。出張者から見れば、使い慣れた予約サイトで3分で終わることに10分かけている状態です。

この判断は合理的なので、精神論では覆りません。

2. 承認と手配が別々になっている

申請と承認は既存のワークフロー（kintone、Microsoft 365、Teams、Google Workspace など）で回し、承認が降りたらBTMを開いて予約する。この構成だと、同じ内容を2回入力することになります。

さらに、承認を待っている間に席や部屋が埋まれば取り直しです。出張申請の手動再予約はなぜ多発するのかで扱ったとおり、これは担当者の注意力ではなく順序の問題です。

現場から見ると「二度手間のうえ、結局取り直しになる仕組み」なので、使わない理由が積み上がります。

3. 個人のポイント・マイルが貯まらない

会社のBTMで手配すると法人決済になり、個人のクレジットカードのポイントは付きません。マイルも会員番号を入れなければ貯まりません。

これは出張者にとって実損です。規程で「マイルは会社帰属」と定めていない会社では、BTMを使わないことに金銭的な動機があります。

4. 規程が曖昧で、システムが弾く理由を説明できない

BTMに宿泊費の上限を設定すると、超える予約は止まります。ところが規程側が「原則◯◯円」程度の書き方だと、現場は「例外のはずだ」と考え、止められた理由に納得しません。

規程が曖昧なままシステムだけ厳格にすると、システムが悪者になります。

5. 変更・キャンセルのサポートが遅い

出張は直前に変わります。前日の便変更に当日まで返事が来ない経験を一度すると、次から自分で予約するようになります。

乗り換えで直るもの、直らないもの

ここが本題です。5つの原因を切り分けます。

原因	乗り換えで直るか
1. 自分で予約したほうが早い	直る — 操作性はサービスごとに大きく違う
5. サポートが遅い	直る — 有人サポートの範囲と対応時間は契約条件そのもの
手配できる在庫が足りない	直る — 提携先が違えば選択肢が変わる
2. 承認と手配が分かれている	直らない — どのBTMでも承認は自社のワークフローに残る
3. 個人のポイント・マイル	直らない — 規程の問題
4. 規程が曖昧	直らない — 規程の問題

2から4は、BTMを替えても同じ形で再発します。乗り換え先の営業資料には書かれていない部分なので、検討時に見落とされがちです。

とくに2は厄介です。BTM各社は「申請・承認から精算まで一気通貫」と説明しますが、実際には既存の承認ワークフローを捨てて、BTMの承認機能に寄せるという意味であることが多い。稟議のルートや金額分岐を作り込んでいる会社ほど、それはできません。結果として、承認は既存のまま、手配だけBTM、という構成に落ち着きます。

乗り換えを判断する4つの基準

基準1：利用率が6か月で5割を超えたか

導入から半年は立ち上がりの期間です。この間に5割を超えないなら、運用の工夫で覆る見込みは薄いと判断してよいでしょう。逆に7割まで来ているなら、残りは原因を潰す作業で届きます。

基準2：原因が「直る側」にあるか

上の表で、自社の主な原因が直る側に2つ以上あるなら乗り換えの効果が見込めます。直らない側だけなら、乗り換えても費用と手間が増えるだけです。

基準3：契約の残存期間と違約金

年間契約の途中解約で違約金が発生するかを確認します。残り3か月なら、待ってから動くほうが安く済みます。

基準4：移行にかかる作業量

見落とされやすい部分です。少なくとも次が必要になります。

• 利用者マスタと部署構成の再登録
• 規程（宿泊費上限、クラス制限、承認ルート）の再設定
• 会計・経費精算システムとの連携の作り直し
• 出張者への説明と再教育

再教育は最も重いところです。一度「使いにくい」と判断されたシステムを入れ替えると、現場は二度目の学習に消極的になります。乗り換えは一度きりのつもりで臨むべきです。

乗り換えるときに持ち出すもの

解約前に、次のデータを手元に落としておきます。解約後は取り出せなくなります。

• 手配履歴（日付・行き先・金額・利用者）— 次のサービスの見積もり条件になり、削減効果の比較基準にもなる
• 請求明細— 会計処理の照合に使う
• 規程の設定内容— 宿泊費上限や承認ルートの設定をそのまま移せる
• 利用者マスタ— 部署構成込みで出力しておく

手配履歴は特に重要です。これが無いと、次のサービスで「本当に安くなったのか」を検証できません。出張1件の工数は何分かで扱ったとおり、効果は工数と金額の両面で測る必要があります。

よくある質問（FAQ）

利用率は何で数えればいいですか？

BTM経由の手配件数を、出張申請の承認件数で割ります。BTMの管理画面の数字だけを見ると、BTMを通らなかった手配が分母から落ちるため、実際より高く出ます。

利用率が低いのは、周知不足が原因ではないですか？

周知は最初の1〜2か月の話です。半年経っても5割を切っているなら、周知ではなく構造に原因があります。本記事の5つの原因のどれかに当てはまるはずです。

乗り換えずに改善できる原因はありますか？

規程の明確化（原因3・4）は、システムを変えずに着手できます。マイルの帰属と宿泊費上限を規程に明記するだけで、現場の納得感は変わります。出張規程の作り方を参照してください。

利用率100%は目指すべきですか？

BTMの利用率としては現実的ではありません。承認がBTMの外にあるかぎり、承認を通さない手配と、手配を伴わない承認の両方が可能なままです。9割を超えたあとの伸びしろに労力を割くより、残る1割を立替精算で処理する運用を割り切って設計したほうが安く済みます。それが許容できない規模になっているなら、BTMの入れ替えではなく承認と手配の順序を見直す論点です。

参照している「9割」の数字は信頼できますか？

提供元が自社実績として公開した数値で、第三者の測定ではありません。母数（何社中の何社が「活用が定着した」に該当するか）も公開されていません。本記事では業界上位のサービスでも最良の顧客で9割という上限の目安として扱い、目標値としては使っていません。自社の目標水準は、残る1割を立替精算で処理するコストと見合うかで決めてください。

複数のBTMを併用するのは現実的ですか？

勧めません。集約が価値の中心なので、分けると請求もデータも分断され、導入前に戻ります。国内と海外で分けている会社はありますが、その場合も請求と精算の集約先は1つに寄せてください。

乗り換え先はどう選べばいいですか？

自社で起きた原因を、そのまま確認項目にします。操作性が原因なら実際の画面で手配してみる、サポートが原因なら深夜・休日の対応範囲を契約条件として確認する、という形です。BTM13社の比較で比較の6つの視点を整理しています。

乗り換える前に：承認側でつなぐという選択

原因が「2. 承認と手配が分かれている」だけなら、BTMを替える必要はありません。

1Approvalは、いま使っている承認ワークフロー（kintone、Microsoft 365、Teams、Google Workspace）の上で、承認が降りた時点で手配まで完了させる仕組みです。承認ルートの設計をやり直す必要がなく、二重入力も、承認待ちの間の取り直しも構造的に起きません。

この構成では、利用率を上げるという課題そのものが無くなります。承認を経ずに手配は発生せず、承認されたものは必ず手配されるため、分母を「承認された出張」に取れば全件が通ります。前述の「承認を通さず自分で予約する／承認だけ通して手配は各自」という2つの抜け道が、順序の上で成立しなくなるからです。

残る抜け道はそもそも申請せずに行く出張だけで、これはシステムではなく規程と統制の問題です。出張の不正10類型で扱っています。

費用は法人一括請求にまとまり、手配データは経費データとして生成されて会計・経費精算システムへ連携できます。立替と証憑回収が発生しないため、出張旅費の統制で扱った「手配を個人任せにしない」状態にそのまま近づきます。

利用率が上がらない理由が順序にあるなら、順序を直すほうが安く、早く、そして再発しません。

まとめ

BTMが浸透しないとき、最初にやるべきは利用率を数えることです。5割を切っているなら構造に原因があります。ただし9割はBTMの構造的な上限で、そこから先を運用努力で埋めようとしても割に合いません。

そのうえで原因を5つに切り分け、乗り換えで直る側にあるかを確認してください。操作性・サポート・在庫が原因なら乗り換える価値があります。承認との分断や規程の曖昧さが原因なら、乗り換えても同じ場所に戻ります。

そして乗り換えは一度きりのつもりで臨んでください。二度目の入れ替えには、現場はついてきません。

主な参照先

• 導入した出張管理システムが浸透しない！乗り換えの判断基準と具体策｜ピカパカ出張DX
• 出張管理サービス導入したけどうまくいかない！？正しい運用方法と事前対策｜ピカパカ出張DX
• 出張管理システムの失敗しない選び方 料金以外で比較すべき7つのポイント｜HIS
• Travel Intelligence Agent のリリース（株式会社トランスファーデータ）

※各サービスの条件は2026年9月時点で確認した公開情報です。最新の情報は公式サイトでご確認ください。