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

乗務員管理システムの発注・外注は、Excelの交番表をそのままWeb化するのではなく、法令・社内規程・資格・便や車両の制約を要件に落とし込める委託先を選ぶことが成功の近道です。発注形態、RFP、契約、費用、見積比較を順番に整理すれば、導入後に「現場で使えない」「連携費用が膨らんだ」という失敗を抑えられます。

本記事では、航空会社、バス、タクシー、トラック、鉄道などの事業者が、乗務員管理システムを発注・外注・委託するときの進め方を解説します。既製SaaS、パッケージのカスタマイズ、スクラッチ開発の選び方から、RFPに書く項目、契約形態、2026年時点の費用目安、候補会社の比較ポイント、段階導入とセキュリティ対策まで、実際の社内稟議と相見積もりに使える形でまとめます。

▼全体ガイドの記事
・乗務員管理システム開発の完全ガイド

乗務員管理システムの発注・外注は何から始めますか？

結論から言うと、最初に決めるべきことは製品名や開発言語ではなく、対象となる業務範囲と守るべき制約です。乗務員管理システムは、乗務員台帳、資格・教育、勤務計画、勤怠、乗務実績、点呼、安全記録、給与や運行管理との連携を一つの業務プロセスとして扱うためです。

乗務員管理システムとは、誰を、どの便・路線・車両・勤務に割り当てられるかを、資格、休息、勤務時間、健康状態、社内規程などの条件と照合して管理する業務システムです。一般的な勤怠システムが出退勤や休暇を中心に扱うのに対して、乗務員管理では「その人を安全かつ適法に乗務させられるか」という割当判断が中心になります。

発注時は、台帳だけを作るのか、交番表の作成まで自動化するのか、点呼・アルコール検査・デジタコ・運行管理・給与システムと連携するのかを分けて考えます。最初から全機能を一括で外注するより、1営業所や1路線を対象に、台帳、資格期限、勤務計画、本人確認などのMVPを作り、現場で効果を測ってから範囲を広げる方が、要件の手戻りを抑えやすいです。

航空向けでは、フライト情報、機種資格、訓練・審査、休暇、宿泊や旅費などを乗務スケジュールと結び付けます。JTAインフォコムのC3は、フライト情報と連携し、約420名の1か月分のスケジュールを管理しながら、iPadから休暇申請を行える事例が公開されています（出典: JTAインフォコム「開発実績」、2026年確認）。このような業態では、便の変更や資格の組み合わせを扱えるかが重要です。

バス、タクシー、トラックでは、路線便・貸切便・隔日勤務・宿泊勤務・車庫待ちなどを勤務パターンとして登録し、拘束時間、休息期間、運転時間を判定します。鉄道では、乗務員の循環勤務や駅係員のパターン勤務、列車や担当区所との割当が焦点になります。厚生労働省の改善基準告示はバス、トラック、ハイヤー・タクシーなどで2024年4月1日から改正内容が適用されているため、発注先には自社の業態に対応したルール更新の実績を確認します（出典: 厚生労働省「自動車運転者の長時間労働改善に向けたポータルサイト」、2026年確認）。

標準的な台帳、申請、シフト、勤怠が中心で、短期間に導入したい場合は既製SaaSが候補です。自社の業務を製品に合わせられる範囲が広いほど初期費用と導入期間を抑えられます。すでに運行管理や給与の仕組みがあり、差分の勤務ルールや帳票だけを変えたい場合は、パッケージにカスタマイズを加える方法が現実的です。

複数法人の統合、独自の勤務規程、特殊な資格判定、AIや数理最適化を競争力の源泉にしたい場合はスクラッチ開発も検討します。ただし、自由度が高いほど法令改定や現場ルール変更を自社と開発会社が継続的に保守しなければなりません。比較の基準は「スクラッチの方が高機能か」ではなく、「既製機能で満たせない独自制約が、開発費と保守費に見合うか」です。

乗務員管理システムを発注・外注する進め方

発注プロジェクトは、現行業務の棚卸し、RFP作成、候補会社への説明、提案・見積比較、契約、要件定義、開発、テスト、教育、段階リリースの順で進めます。外注先に丸投げするのではなく、自社が業務ルールと受入基準を決め、開発会社が設計と実装を担う役割分担を明確にします。

最初に、対象業態、拠点数、乗務員数、管理者数、対象端末、勤務表の締め時刻、現在使っているExcel・紙・既存システムを一覧にします。営業所ごとに勤務パターンの呼び方や承認者が違う場合は、共通ルールと拠点固有ルールを分けて記録します。入力担当、承認担当、現場で最終判断する担当を業務フローに書き出すと、画面や権限の漏れが減ります。

次に、絶対に必要な機能、あると便利な機能、将来拡張する機能を分けます。たとえば第1段階は乗務員台帳、資格期限、勤務計画、休暇申請、勤怠実績に絞り、第2段階で点呼・アルコール検査やデジタコ連携、第3段階でAI交番やBI分析を追加します。段階を切ることで、発注時に必要な費用と、将来予算として残す費用を説明しやすくなります。

RFPには「交番を作成したい」とだけ書かず、どの条件を、どのタイミングで、どの強さで判定するかを記載します。たとえば、資格期限切れは登録不可、休息不足は警告、管理者が承認した例外は理由と承認者を監査ログに残す、というように、警告・登録不可・承認必須の3段階へ分けます。欠勤、臨時便、車両変更、ダイヤ変更、勤務交換、通信断のときに、誰が何を修正できるかも要件にします。

連携要件では、運行・運航管理、車両、点呼機器、デジタコ、給与、人事、ID管理、通知、BIなどのシステム名と、連携方向、頻度、方式、データの正本を整理します。APIが使えない場合にCSVやバッチを選べるか、連携失敗時に再送できるか、訂正データの履歴を追えるかまでRFPに書くことが大切です。個人情報を扱うため、データの所有権、保存場所、バックアップ、返却・削除、再委託の条件も発注前に明示します。

候補会社には、RFPを渡して同じ前提で提案してもらいます。その際、画面の見栄えだけを比較するのではなく、自社の勤務パターン、資格失効、休息不足、欠勤、臨時便を例に、登録から警告、承認、再割当までを実演してもらいます。制約条件を変更したときに、管理者が設定画面で対応できるのか、都度開発会社へ改修を依頼するのかで、長期の保守性と費用が変わります。

可能であれば1営業所のデータを匿名化し、短期間のPoCまたはパイロットを行います。名鉄バスでは、既存の乗務員向け勤怠管理システムとAI交番ソリューションを連携し、交番の確定作業を従来の8〜10時間から最短1.5時間程度に短縮した事例が公開されています（出典: メイテツコム「名鉄バス株式会社様」、2025年）。自社でも交番確定時間、手修正件数、法令エラー、残業の偏り、現場の問い合わせ件数を導入前後で測ると、投資判断がしやすくなります。

要件定義後は、画面やデータモデル、権限、連携方式、例外処理を設計し、開発会社と自社の担当範囲を確認します。テストでは通常勤務だけでなく、資格が失効した場合、休息時間が不足する場合、乗務員が急に欠勤した場合、臨時便が入った場合、勤務を交換した場合、通信や連携が止まった場合をシナリオ化します。安全に関わる業務では、システムが止まったときの紙や既存Excelによる手動運用も受入条件に含めます。

リリース前には、営業所の管理者と乗務員を対象に、予定確認、休暇申請、勤務変更の承認、点呼結果の入力、訂正申請を実際の端末で練習します。全拠点で一斉に切り替えると、データ移行の誤りと現場の混乱を同時に検証することになります。まず代表的な1拠点で運用し、問い合わせと手修正の傾向を改善してから、他拠点へ展開する方法が安全です。

乗務員管理システムの契約形態と発注条件

乗務員管理システムでは、要件が固まる前に開発を始めると追加費用や納期遅延が起きやすいため、フェーズごとに契約と成果物を分ける設計が有効です。要件定義で合意する範囲、開発で作る範囲、運用保守で継続する範囲を明確にし、検収の基準を機能名ではなく業務シナリオで記載します。

完成する機能と受入条件を明確にできる部分は、請負契約が適しています。たとえば、乗務員台帳、資格期限一覧、休暇申請、勤務実績の出力など、画面、入力、判定、帳票が合意できる機能です。一方、複数拠点の業務を調査しながら要件を詰める要件定義や、現場ヒアリングを繰り返す改善フェーズは、準委任契約や時間精算を組み合わせることがあります。

契約書には、成果物、作業範囲、納期、検収期間、瑕疵対応、変更管理、追加改修の単価、支払条件を記載します。AI交番や最適化ロジックを含む場合は、算出結果が必ず最適になることを約束するのか、制約違反を出さず管理者が確認・修正できることを成果とするのかを分けます。最適化の条件追加をすべて無償改修と誤解しないよう、変更要求の見積方法も先に決めます。

乗務員の氏名、連絡先、健康・面談記録、資格、勤務実績は自社の重要な業務データです。契約時に、データの所有権、利用目的、保管場所、バックアップ、契約終了時の返却・削除、移行用データの形式を確認します。クラウドサービスでは、サービス提供会社が持つ標準機能のデータと、自社が登録したデータを区別しておくと、将来の乗り換えや再委託の判断がしやすくなります。

専用開発では、ソースコード、インフラ構成、データベース定義、API仕様、運用手順、テスト仕様、管理者向け設定の引渡し範囲を定めます。すべての著作権を取得する必要がない場合でも、契約終了後に自社や別会社が保守できる利用許諾、技術資料、アカウント管理権限を確保します。設定値が開発会社の担当者しか変更できない状態は、法令改定や営業所追加のたびに依存が発生するため注意が必要です。

24時間の運行や早朝の交番確定がある会社では、稼働率だけでなく、障害受付時間、一次回答までの時間、復旧目標、計画停止の通知、データ復旧、代替手段をSLAにします。重大障害の定義を「ログインできない」だけにせず、勤務計画が確定できない、資格判定ができない、点呼データが連携されない、といった業務影響で定義すると実態に合います。

2026年のIPA「情報セキュリティ10大脅威」では、組織向けの2位に「サプライチェーンや委託先を狙った攻撃」が挙げられています。乗務員の連絡先や健康情報を外部サービスで扱う場合は、MFA、最小権限、アクセスログ、暗号化、脆弱性対応、バックアップ、復旧訓練、インシデント時の報告期限をRFPと契約へ反映します（出典: IPA「情報セキュリティ10大脅威 2026［組織編］」、2026年）。再委託先の社名、作業範囲、国外保管の有無、監査や報告を受ける権利も確認します。

乗務員管理システムの費用相場と3年TCO

乗務員管理システム専用の公的な価格統計は少ないため、以下の金額は2026年公開の業務システム相場、輸送業向けサービスの公開料金、類似案件の目安を組み合わせた推定です。乗務員数、営業所数、法令ルール、連携本数、移行データ、24時間運用、端末、保守の範囲で変わるため、金額だけでなく前提条件と3年総額を比較します。

既製SaaSやクラウドを設定して導入する場合、初期費用は10万〜100万円、月額は2万〜20万円程度が一つの目安です。輸送業向けサービスの公開料金には、75名・1拠点で初期設定11万円、月額5万7,750円という例があります（出典: 東京海上日動「TUMIXコンプラ 料金表」、2026年確認）。ただし、これは個別開発の価格ではなく、標準機能と利用人数を前提にした参考例です。

パッケージへ業務適合カスタマイズを加える場合は初期100万〜500万円、月額5万〜30万円程度、期間は2〜6か月程度が目安です。1営業所向けの小規模スクラッチやMVPは300万〜800万円、複数拠点と外部連携を含む中規模開発は800万〜2,000万円、複数法人・24時間運用・複雑な最適化を含む大規模開発は1,500万〜5,000万円以上になる可能性があります。これらは乗務員管理専用の確定相場ではなく、業務システム開発の公開レンジからの推定です（出典: 株式会社Fuji of Innovation「業務システム開発の費用相場 2026年版」、2026年）。

見積書は、要件定義・業務設計、画面とUX、データベース、勤務・資格判定、交番や最適化ロジック、API連携、データ移行、端末設定、テスト、教育、プロジェクト管理、クラウド、保守に分けてもらいます。「開発一式」だけでは、連携先が増えたときや帳票が追加されたときの追加費用を判断できません。人月単価の公開目安には、プログラマ40万〜60万円、SE60万〜100万円、PM・上流担当80万〜130万円程度がありますが、単価よりも何人月をどの成果物に使うかを確認します。

データ移行費は、Excelや紙からの入力、重複・欠損の補正、資格期限や勤務履歴の変換、移行リハーサルを含むかで大きく変わります。連携費も、APIの新規開発、既存APIの利用、CSV出力、連携監視、エラー再送、仕様変更への対応を分けます。AI交番を追加する場合は、制約条件の整理、学習・最適化モデル、管理者による確認画面、手修正結果の記録、再計算のルールを別項目にすると、機能の過不足を評価しやすいです。

クラウドやSaaSは初期費用が低く見えても、利用人数、拠点、端末、通信、追加ユーザー、API、保守、法令改定対応が毎月発生します。スクラッチは初期開発費が大きくなりやすい一方、利用者数の増加や自社固有の運用に対する費用構造を設計できます。初期開発費に月額36か月分、端末・通信、データ移行、教育、保守、追加改修、障害対応の費用を足して、3年TCOを算出します。

導入効果は、交番確定にかかる時間、担当者の残業、手修正数、法令チェックの見落とし、資格期限切れの防止、問い合わせ数、欠勤時の再割当時間で測ります。売上や利益に直結しにくいシステムでも、月間の削減時間と事故・行政指導・給与計算ミスのリスク低減を分けて評価すると、経営層へ説明しやすくなります。

委託先の選定と乗務員管理システムの見積比較ポイント

委託先は知名度や見積総額だけで決めず、航空、道路運送、鉄道のどの業態に対応できるか、台帳・勤怠・交番・点呼・最適化のどこを得意とするか、既存システムとどう連携するかで比較します。自社の業界を理解する会社と、特定機能に強い会社を組み合わせる場合は、障害対応と責任分界を一社に任せるのか、共同体制にするのかを明確にします。

航空向けではJTAインフォコムのC3のように、フライト情報、資格、訓練、休暇、乗務時間を統合した経験を確認します。バスや鉄道では、メイテツコム、株式会社工房、アイテック阪急阪神などが公開する、乗務員勤怠、乗合勤務、運輸勤怠、循環勤務、点呼や日報の事例が比較材料になります。AIや数理最適化を重視する場合は、ALGO ARTISのような最適化領域の会社を候補にし、既存の勤怠・運行管理との連携実績も確認します。

三菱電機デジタルイノベーションの東京空港交通向け事例のように、乗務員だけでなく、宿泊を伴う隔勤、車両整備、バス管制など周辺部門まで勤務状況を把握する案件もあります。事例を聞くときは、導入社名だけでなく、対象人数、拠点数、期間、連携先、標準機能と個別開発の境界、導入後の保守体制を質問します。自社と同じ課題を経験した担当者が提案・導入後支援にも参加するかを確認すると、営業資料とのずれを抑えられます。

相見積もりでは、各社へ同じRFP、同じサンプルデータ、同じデモ課題を渡します。見積書は、要件定義、開発、連携、移行、教育、クラウド、保守、追加変更を横並びにし、含む・含まない・前提条件・別途費用を記号や注記で整理します。A社は初期費用が安くても連携と移行が別途、B社は高くても保守と法令改定対応を含む場合があるため、総額だけでは判断できません。

評価表は、業務適合性、法令・資格判定、連携性、使いやすさ、拡張性、セキュリティ、導入支援、保守体制、3年TCOのように分けます。さらに、提案内容のうち「標準」「設定」「カスタマイズ」「将来対応」を明示してもらいます。値引き交渉を先にするより、抜けている要件と将来の変更単価を確認した方が、契約後の予算超過を防ぎやすいです。

提案比較で差が出るのは、通常勤務の登録画面より例外処理です。乗務員が当日欠勤したとき、資格の更新が間に合わないとき、臨時便が発生したとき、交替者が見つからないときに、候補を検索し、法令違反を避け、管理者が承認し、本人へ通知できるかを確認します。システムが出した警告の理由を現場が理解できるか、誤検知を訂正できるか、訂正履歴を監査できるかも重要です。

導入後の伴走も評価します。法令や社内規程が変わったときの設定変更、営業所追加、担当者の異動、問い合わせの受付、障害時の連絡、データ訂正の手順が契約と運用マニュアルに落ちているかを確認します。システム部門だけでなく、運行・運航、安全、労務、現場の代表者をデモに参加させると、発注後に「必要な人が見ていなかった」という手戻りを減らせます。

発注後に起きやすいリスクと導入成功のポイント

乗務員管理システムの失敗は、開発技術よりも業務ルールの曖昧さ、現場の入力負担、既存システムとの責任分界、移行データの品質、運用変更の準備不足から起きます。発注時点でリスクを洗い出し、誰が、いつまでに、どの判断をするかを決めておくと、開発会社任せのプロジェクトになりにくいです。

法令や規程のチェックは、画面に赤い警告を出すだけでは不十分です。違反の可能性がある割当を登録不可にする条件、例外として承認できる条件、管理者が理由を入力する条件、後日監査できる記録を分けます。ルールの施行日、適用対象の車種や勤務区分、改定者、テスト結果を管理できるようにすると、法令改定時にどの画面と計算を見直すべきか追跡できます。

航空や鉄道では、改善基準告示だけで判断せず、運航規程、乗務資格、教育・審査、安全管理、社内の勤務協定などを要件化します。労務担当だけで仕様を決めると、運行現場で必要な便・車両・乗務区分の制約が抜ける可能性があります。発注前から運行・運航、安全、労務、情報システム、現場代表を会議体に入れ、ルールの最終承認者を決めます。

乗務員管理では、連絡先、緊急連絡先、健康状態、面談記録、資格、勤務・乗務履歴など、アクセスを誤ると本人に影響する情報を扱います。所属、営業所、職種、役割によって閲覧・登録・承認の権限を分け、退職や異動のときに権限を自動停止できる設計を検討します。管理者がCSVで全件を出力できる場合は、出力権限、利用目的、保存場所、削除期限も管理します。

クラウドの責任分界では、サービス提供会社が担うOS・ネットワーク・バックアップと、自社が担うアカウント、権限、マスタ、端末、入力内容を分けます。委託先へ安全管理を任せても、個人情報を扱う事業者としての確認が不要になるわけではありません。監査ログの保管期間、脆弱性の通知、インシデント報告、再委託先の管理、契約終了時のデータ削除を、RFP、契約、運用手順の3か所で整合させます。

パイロットでは、機能が動くかだけでなく、朝の点呼前に入力できるか、乗務員がスマートフォンから予定を確認できるか、管理者が欠勤者を何分で再割当できるかを測ります。KPIは、交番作成・確定時間、手動修正数、資格・休息の警告数と解消時間、問い合わせ数、利用率、データ訂正数、残業の偏りなどにします。導入前の基準値を2〜4週間記録しておくと、改善効果を説明しやすいです。

パイロット後は、現場の要望をすべて個別カスタマイズにせず、全社共通にすべき機能、営業所固有の設定、運用で吸収する項目に分類します。そこで得た判断をRFPや追加開発のバックログへ戻し、次の拠点へ展開します。発注先を選ぶときに、リリース後3か月、6か月、1年の定着支援を提案してもらうと、開発完了後に社内だけで運用を抱えるリスクを減らせます。

乗務員管理システムの発注・外注に関するよくある質問

発注前に多い疑問へ、費用・進め方・委託先選びの観点から回答します。自社の業態、拠点数、乗務員数、既存システムによって最適な答えは変わりますが、判断の起点を明確にしておくと、候補会社との打ち合わせが具体的になります。

標準的なSaaSやクラウドの設定導入は初期10万〜100万円、月額2万〜20万円程度、パッケージのカスタマイズは初期100万〜500万円程度が目安です。連携が多い中規模開発は800万〜2,000万円、複数法人や複雑な最適化を含む場合は1,500万〜5,000万円以上になる可能性があります。専用統計ではなく類似業務システムからの推定なので、対象人数、拠点、連携、移行、保守を分解した見積もりで確認します。

相談できますが、最低限、対象業態、乗務員数、拠点数、現在の業務方法、困っている作業、連携したいシステム、導入希望時期を整理してから相談することをおすすめします。RFPが未完成でも、要件定義支援を含む提案を依頼し、作成した成果物の所有権、期間、費用、次の開発フェーズへ進む条件を確認します。複数社から比較できる情報量をそろえるため、同じ課題とサンプルケースを渡すことが大切です。

標準的な台帳、申請、シフト、勤怠が中心で、業務を製品に合わせられるならSaaSが適しています。既存の運行・給与・点呼システムを活かして差分だけ変えたい場合はパッケージのカスタマイズ、独自の勤務規程や複数法人の統合が競争力に直結する場合はスクラッチを検討します。判断に迷うときは、80％を標準機能で満たせるか、独自制約を設定で変更できるか、既存連携を維持できるかの3点で比較します。

外注そのものが危険なのではなく、委託先の権限、再委託、保管場所、ログ、バックアップ、障害対応を確認せずに任せることがリスクになります。MFA、最小権限、暗号化、アクセスログ、脆弱性対応、インシデント報告、契約終了時の返却・削除、復旧テストをRFPと契約に含め、委託先のセキュリティ体制と運用実績を確認します。健康情報や資格情報は、業務上必要な担当者だけが見られる権限設計にします。

まとめ

乗務員管理システムの発注・外注では、まず対象業態、拠点、乗務員数、現行業務、既存連携、法令・社内規程を棚卸しします。そのうえで、資格期限、休息、拘束時間、欠勤、臨時便、点呼、給与連携などの制約をRFPへ具体化し、候補会社に同じ条件で提案と見積もりを依頼します。

見積比較では、初期費用の安さだけでなく、3年TCO、データ移行、連携、法令改定、教育、保守、セキュリティ、再委託、契約終了時のデータ引渡しまで確認します。既製SaaS、パッケージのカスタマイズ、スクラッチのどれを選ぶ場合も、1営業所のパイロットと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を創業。