行程管理システム開発の発注/外注/依頼/委託方法について

行程管理システムの発注・外注では、行程表作成だけでなく、見積、手配、顧客情報、当日の運行までを一つの業務データとしてつなげられる委託先を選ぶことが重要です。

Excelや紙、メール、電話に分散した情報をまとめたいものの、「パッケージを導入するのか、個別開発するのか」「RFPには何を書けばよいのか」「見積金額の妥当性をどう判断するのか」と迷う担当者は少なくありません。この記事では、旅行会社・バス会社・DMCなどが行程管理システムを発注・外注するときの考え方を、発注形態、要件整理、契約、費用相場、委託先選定、導入後の評価まで順番に解説します。

▼全体ガイドの記事
・行程管理システム開発の完全ガイド

行程管理システムの発注・外注で最初に決めること

行程管理システムは、旅行会社の案件管理、宿泊や交通の手配、貸切バスの運行、安全記録などを扱う業務システムです。発注前に「何を作るか」だけでなく「どの業務を標準化し、どの例外を残すか」を決めておくと、提案内容と見積を比較しやすくなります。

最初に、旅行会社の営業・手配・添乗、バス会社の配車・乗務員管理、DMCやランドオペレーターの仕入れ・多言語対応のどこまでを対象にするかを明確にします。同じ「行程管理」でも、旅行会社は見積から手配、顧客への案内までを重視し、バス会社は運賃計算、休憩、交替運転、運行指示書、点呼、日報などを重視します。利用者も、営業担当、手配担当、管理者、添乗員、乗務員、取引先などに分かれます。

この切り分けをしないまま「全部入り」のシステムを発注すると、使わない機能に費用をかけ、現場が入力を嫌がる結果になりやすいです。部署ごとに、現在使っている帳票、入力する項目、確認する相手、締切、手戻りが起きる場面を並べ、今回の対象範囲と将来の候補を分けてください。

導入目的は、「DX化したい」「情報を一元化したい」だけでは委託先に伝わりません。たとえば、行程表の初稿作成時間、見積作成時間、手配漏れ件数、行程変更が関係者へ伝わるまでの時間、当日の問い合わせ件数を測定対象にします。導入前の1か月間だけでも現状値を記録しておくと、提案段階で必要な機能を絞り込めます。

ナビタイムジャパンの「行程表クラウド」は、公式ページで行程表作成時間を従来の10分の1にする訴求や、140社以上の導入実績を示しています。ただし、これは同社サービスの紹介情報であり、自社でも同じ削減率になると断定する数字ではありません。見積比較では、実データを使ったデモで自社の平均案件を一件再現し、導入前後のKPIを計測できる設計か確認してください。

行程管理システムの発注形態はどれを選べばよいですか？

結論として、業務が標準化されていて早く使い始めたい場合はクラウドSaaSまたは業界パッケージ、既存システムを活かしながら不足部分を埋めたい場合は部分カスタム、独自の販売・収益・運行ルールが競争力に直結する場合はスクラッチ開発が候補です。最初から技術方式を決めるのではなく、業務の差別化要因と変更頻度を見て選びます。

クラウドSaaSや旅行業向けパッケージは、サーバー構築やアップデートを自社で抱えずに始めやすい形態です。行程表、地図、経路、見積、手配、顧客管理など、旅行業務で共通する機能があらかじめ用意されていれば、要件定義と導入教育を短くできます。複数拠点で同じ情報を見たい会社や、専任のIT担当者が少ない会社に向いています。

一方で、独自帳票、特殊な料金計算、例外的な承認経路を大量に追加すると、パッケージの利点が薄れます。標準機能で業務を変えられる部分、設定で対応する部分、追加開発が必要な部分を分け、追加開発の保守費用と将来のバージョンアップ影響まで聞いてください。月額料金だけでなく、初期設定、データ移行、アカウント追加、API利用、サポート、解約時のデータ返却に費用があるかも確認が必要です。

既存の予約、会計、CRM、GPS、デジタコを残し、行程データを連携の中心にする方法が部分カスタムです。最初のリリースを「行程登録・見積・手配状況・帳票出力」に絞り、会計連携や顧客向け通知を第二段階に回すと、投資と現場負担を抑えやすくなります。発注時には、API連携の方式、データの主システム、連携失敗時の再送方法、重複登録を防ぐルールを仕様に含めます。

スクラッチ開発は、複数法人の採算管理、独自の旅行商品、複雑な配車、安全監視、リアルタイム共有など、既製品では表現しにくい要件がある場合に選びます。費用と期間は大きくなりますが、要件定義書、画面・帳票仕様、テスト仕様書、ソースコード、データベース定義、API仕様、運用手順書を納品物に含めることで、将来の委託先変更に備えられます。

RFPと要件整理では何を伝えればよいですか？

RFPは、開発会社に希望を伝える資料であると同時に、自社の業務を整理するための道具です。細かな画面デザインを最初から固定するより、現状の流れ、解決したい問題、必要なデータ、業務上の制約、成功指標を共有したほうが、委託先から実現方法の違う提案を受け取れます。

現状説明には、案件受付から行程作成、見積、予約・手配、変更、顧客案内、当日運行、請求・精算までの業務フローを入れます。各工程で「誰が」「どのファイルや帳票に」「何を入力し」「誰が確認するか」を示し、転記回数、締切、差し戻し、手配漏れ、情報が古くなるタイミングも記録してください。

たとえば「行程変更に弱い」という課題は、「ホテル変更を営業がメールで連絡し、手配担当が別のExcelを修正し、添乗員には前日の電話で伝えている。最新情報の確認に平均30分かかり、月に数回は古い帳票が残る」のように書きます。具体的な業務シナリオがあれば、開発会社は通知、履歴、承認、帳票の必要性を判断しやすくなります。

機能要件は、必須、できれば必要、将来検討の3段階に分けます。必須機能には、日付・時刻・滞在時間・移動手段・休憩を含む行程作成、地図と経路、見積、手配先・予約番号・回答期限、変更履歴、顧客・参加者情報、PDFやWebでの行程表出力を挙げます。バス事業者であれば、配車、乗務員割当、運行指示書、点呼、日報、位置情報の連携も候補になります。

機能名だけでなく、利用シーンを書き添えることが大切です。「行程を編集できる」ではなく、「顧客から宿泊先変更を受けた担当者が、変更前後を確認し、見積と手配状況を更新し、権限を持つ添乗員へ最新の行程表を通知する」と書きます。これにより、履歴、権限、通知、承認、再出力が必要かどうかを提案段階で判断できます。

行程と参加者名簿をクラウドに置くなら、利用時間、障害時の復旧目標、バックアップ、アクセス権限、操作ログ、通信と保存データの暗号化、スマートフォン対応、データ出力、サポート窓口をRFPに入れます。個人情報保護委員会の通則ガイドラインは、取得、利用、保存、提供、削除・廃棄の段階ごとに取扱方法と責任者を定めることや、アクセス制御などの技術的安全管理措置を示しています。行程管理システムも、機能要件だけでなく運用ルールと委託先管理まで設計してください。

移行条件には、顧客、施設、交通、料金、過去案件、テンプレート、ユーザー権限のどこまで移すかを記します。移行元のExcelが複数あり、顧客名や施設名の表記が揺れている場合は、発注者側で名寄せするのか、委託先に依頼するのかで費用が変わります。移行件数、データの形式、欠損時の扱い、検証方法、移行リハーサルの回数を見積条件に含めると、後からの追加請求を抑えやすいです。

行程管理システムの契約形態はどう選びますか？

契約形態は、開発対象と責任範囲が明確か、要件が変わりやすいか、成果物をどう検収するかで選びます。契約書の名称だけで判断せず、要件定義、設計、開発、テスト、移行、保守の各工程をどの契約で委託するかを分けて確認してください。法的な適否は個別事情で変わるため、重要な案件では弁護士や契約実務に詳しい専門家への確認も必要です。

要件が固まり、完成させるシステムと検収条件を明確にできる工程では、成果物の完成を目的とする請負契約が候補になります。一方、要件定義や調査、アジャイル開発のように、専門家の作業や協議を積み上げる工程では、準委任契約が使われることがあります。重要なのは、準委任だから成果物が不要、請負だから変更が無料という意味ではない点です。

要件定義を準委任で行い、その結果をもとに開発を請負で発注する、または小さな機能単位で準委任の反復開発を行うなど、工程ごとに組み合わせる方法もあります。契約書では、作業内容、納品物、検収方法、期限、報告、再委託、知的財産権、秘密保持、個人情報の取扱い、障害対応、途中終了、データ返却を明記してください。

行程管理では、現場から「この帳票も欲しい」「この例外も自動化したい」と要望が増えやすいです。変更要求を受けたとき、影響範囲、追加工数、費用、納期、テスト範囲、既存機能への影響を双方で記録し、承認してから着手する変更管理の手順を作ります。発注時の見積に含まれる範囲と、別途請求になる範囲を機能一覧に紐付けてください。

また、データをCSVや標準形式で出力できるか、データベースの構造やAPI仕様を開示できるか、ソースコードや設定情報の権利をどう扱うかを確認します。クラウドサービスの場合も、解約時のデータ返却形式、返却期限、削除証明、移行支援の料金を契約前に聞いてください。安い初期費用だけで決めず、5年間の利用・保守・移行の総費用で比べることが大切です。

行程管理システムの費用相場と見積内訳

行程管理システムの専用製品は、利用人数、拠点数、機能、連携、データ移行、サポートで価格が変わり、公開定価がないサービスも多いです。以下は、NotebookLMのリサーチノート、2026年公開の業務システム相場、行程管理製品の機能範囲をもとにした目安です。専用製品の一律料金ではないため、実際の予算はRFPを渡して個別見積を取得してください。

既存クラウドSaaSの契約・初期設定は、機能が標準化されていれば初期費用0〜50万円程度が一つの目安です。小規模な個別開発や部分カスタムは150〜500万円程度、中規模の業務システム開発は500〜1,500万円程度が目安になります。行程、見積、顧客、手配、権限、帳票をまとめて作る場合は小規模側、請求・会計連携や複数部署、データ移行まで含める場合は中規模側に近づきます。

複数拠点の基幹連携、予約・会計・CRM・GPS・運行管理の統合、複雑な権限や監査を含む場合は、2,000〜5,000万円以上になる可能性があります。全社基幹刷新レベルでは5,000万円から数億円まで幅があります。これらは機能と期間を前提にした推定レンジであり、会社規模や技術者単価から特定の金額を断定したものではありません。出典は、NotebookLMリサーチノートおよび2026年公開の類似業務システム費用情報です。

見積書では、要件定義、基本設計、詳細設計、開発、結合・総合テスト、データ移行、教育、リリース後の支援を分けてください。ノートの整理では、要件定義10〜15%、基本設計15〜20%、詳細設計10〜15%、開発30〜40%、結合・総合テスト15〜20%、移行・導入5〜10%程度が工程配分の目安です。比率は案件によって変わりますが、要件定義やテストがほとんど計上されていない見積は、後で追加費用が発生しないか確認が必要です。

スクラッチ開発の運用保守は、初期開発費の年10〜20%程度を一つの検討目安にできます。たとえば初期開発費が3,000万円の場合、年間300〜600万円程度という計算になりますが、これは一般的な保守比率を当てはめた試算であり、障害対応、機能改善、クラウド費、ライセンス、サポート時間を含むかで変わります。SaaSなら月額利用料、ユーザー追加、ストレージ、API従量課金、個別サポートを5年間の総額に入れてください。

委託先の選び方と見積比較のポイント

委託先は、価格の安さや知名度だけでなく、旅行・観光業務への理解、行程変更や例外処理への対応、現場定着の支援力、連携とセキュリティの実装力で比較します。提案書の見栄えよりも、自社の実際の案件を題材にして、どこまで標準機能で対応し、どこから追加開発になるかを説明できる会社を選びます。

実績を聞くときは、「旅行会社向けの導入がありますか」だけで終わらせません。団体旅行、国内日帰り、宿泊、インバウンド、貸切バスなど、自社に近い業務の導入事例を尋ね、行程表、見積、手配、原価、請求、運行管理のどこまで使われたかを確認します。可能であれば、匿名化された画面や運用フロー、導入前後の作業時間、現場教育の期間も見せてもらいます。

比較候補には、ナビタイムジャパン、ブロードリーフ、クレスコ・ジェイキューブ、アゼスタ、アジェンダ、ティービーケー・システムズなど、旅行業務やバス運行管理に接点のある実在企業があります。たとえばブロードリーフの公開導入事例には、行程表・見積作成が1件2時間から20分程度になった事例があります。これは個別企業の事例であり、自社の効果を保証する数字ではないため、同じ条件で試算してもらうことが大切です。

相見積もりは、同じRFP、同じ利用人数、同じ拠点数、同じ移行件数、同じ連携範囲を渡して行います。見積比較表には、初期費用、月額費用、要件定義、追加開発、テスト、移行、教育、保守、クラウド・ライセンス、交通・地図API、消費税を分けて記載します。価格が安い会社に機能がないのか、高い会社に過剰な要件が含まれるのかを分解して確認できます。

特に注意したいのは、「別途相談」「実費」「要件確定後に提示」という項目です。曖昧な項目がある場合は、想定単価、上限、見積を出すタイミング、発注者が準備するデータ、追加になる条件を質問してください。評価は価格だけでなく、要件理解、提案の具体性、担当者の経験、体制、納期の現実性、保守、データ返却を点数化すると、社内説明もしやすくなります。

参加者名簿、連絡先、緊急連絡先、食事や配慮事項などを扱う場合、権限を役職・拠点・案件単位で設定できるかを確認します。誰がいつ何を変更したかの操作ログ、退職者のアカウント停止、CSV出力の制御、バックアップの世代数、障害時の連絡経路、復旧目標、脆弱性対応の責任分界も質問項目です。

貸切バスを扱う場合は、運送引受書、点呼記録、業務記録、運行指示書など、社内で保存・確認が必要な記録をどのように出力し、誰が承認するかを確認してください。国土交通省は貸切バスの安全確保に関する制度やデジタル式運行記録計の資料を公開しています。行程システムだけで法令対応が完了するわけではないため、現場の運行管理者と所管官庁の最新情報を確認しながら要件化します。

発注後の開発・導入を成功させる進め方

発注先を決めた後は、開発会社に任せきりにせず、発注者側の業務責任者と現場代表をプロジェクトに参加させます。行程管理は例外が多いため、実際の案件を使った確認と、現場での試行を早く繰り返すほど、リリース後の手戻りを減らせます。

最初から全社の全案件を移すのではなく、一つの支店、担当チーム、商品種別などを対象にパイロットを行います。国内日帰り、宿泊、団体、貸切バス、行程変更、キャンセル、悪天候による代替案など、通常と例外を含むシナリオを用意してください。画面が動くかだけでなく、旧帳票と新しい行程表の差分、見積・手配への反映、権限の違う人への見え方を確認します。

パイロット期間には、行程作成時間、見積作成時間、手配漏れ、変更の伝達時間、問い合わせ数、利用者が迷った箇所を記録します。数値が改善しない場合は、システムの問題だけでなく、入力項目が多すぎる、マスタが古い、業務ルールが決まっていない、教育が不足している可能性もあります。結果をもとに、機能追加より運用整理を優先する判断も必要です。

操作研修は、機能の説明会だけでは足りません。営業が案件を登録し、手配担当が予約を更新し、管理者が承認し、添乗員が当日の最新情報を見るという役割別の実習を行います。入力しないと次の工程に進めない項目、変更理由の書き方、キャンセル時の処理、緊急時の連絡方法を運用マニュアルにまとめてください。

リリース後は、問い合わせ窓口、障害と要望の分類、マスタ更新の担当、月次のKPI確認、権限棚卸し、バックアップ確認を定例化します。旅行業法について観光庁は、旅行業の登録制度や旅程管理主任者制度、関係法令・省令を公開しています。業務システムの設計では制度改正を追える担当者を決め、法令の個別判断は所管官庁や専門家に確認してください。

行程管理システムの発注・外注でよくある質問

ここでは、発注前に特に相談が多い疑問を整理します。費用や契約条件は個別案件で変わるため、FAQの目安をそのまま予算や法的判断にせず、自社の業務範囲とRFPに照らして確認してください。

標準SaaSの初期設定なら0〜50万円程度、小規模な部分開発なら150〜500万円程度、中規模の業務システムなら500〜1,500万円程度が機能範囲付きの目安です。複数拠点や会計・予約・GPS・運行管理を統合する場合は2,000〜5,000万円以上になる可能性があります。専用製品の公開定価を示す数字ではないため、利用者数、移行件数、連携数、保守範囲を揃えて個別見積を取得してください。

相談できます。現状の帳票、業務フロー、困っている場面、利用者、案件数、導入希望時期を準備すれば、要件定義から支援する会社に相談できます。ただし、複数社の提案と見積を公平に比べたい場合は、必須機能、対象範囲、成功KPI、移行データ、非機能要件だけでも先に整理してください。

標準的な行程表、見積、手配、顧客管理を早く始めたいならSaaSや業界パッケージが向いています。独自の料金計算、複雑な採算管理、複数法人の権限、既存基幹との固有連携が競争力に直結するなら部分カスタムやスクラッチ開発が候補です。まず標準製品で業務を試し、差別化に必要な部分だけを追加する段階導入も有効です。

比較可能な提案を得るには、業界パッケージに強い会社、個別開発に強い会社、連携やクラウド運用に強い会社など、得意領域の違う候補を3〜5社程度に絞る方法が現実的です。社数を増やしすぎると質問対応と評価に時間がかかるため、RFPを渡す前に実績、対象業務、予算感、支援範囲を確認し、自社に合う候補だけへ依頼してください。

まとめ：行程管理システムは業務と契約を整理してから発注します

行程管理システムの発注では、まず旅行会社、バス会社、DMCなどの対象業務と利用者を切り分け、行程表作成時間、手配漏れ、変更伝達時間、見積作成時間などのKPIを決めます。そのうえで、SaaS・パッケージ・部分カスタム・スクラッチ開発の違いを比べ、標準機能で済ませる部分と自社固有の開発部分を整理します。

RFPには現状業務、課題、必須機能、将来機能、利用者、データ移行、連携、セキュリティ、導入時期、成功指標を含めます。見積は初期費用だけでなく、要件定義、テスト、教育、保守、クラウド、API、データ返却まで同じ前提で比較してください。費用レンジは機能範囲付きの目安として扱い、特定の金額を先に決めつけないことが安全です。

委託先を決めた後は、実データに近い案件でパイロットを行い、現場の入力負担とKPIの変化を確認します。個人情報のアクセス権限、変更履歴、バックアップ、障害時の連絡、貸切バスの記録保存などを運用ルールに落とし込み、教育とマスタ整備を含めてリリース計画を作ります。機能数を増やすより、最新の行程情報が必要な人へ確実に届く状態を先に作ることが、外注成功への近道です。

行程管理システムは、単なる行程表作成ツールではなく、営業、手配、運行、顧客対応、請求をつなぐ業務基盤です。自社の業務を言語化し、契約と費用の前提をそろえたうえで、実績と伴走体制のある委託先へ相談してください。

▼全体ガイドの記事
・行程管理システム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。