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

乗務員管理システムを発注・外注（依頼・委託）する流れは、現行業務と発注範囲の整理、RFPによる要件の提示、提案と検証、段階的な導入の順に進みます。

各段階で決めた内容を次の段階に引き継げば、現場で使える仕組みに近づきます。

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

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

乗務員管理システムの発注・外注の始め方

最初に決めるのは、製品名や開発言語ではなく、対象となる業務範囲と守るべき制約です。

乗務員管理システムは、乗務員台帳、資格・教育、勤務計画を中心に、勤怠や乗務実績を一つの業務プロセスとして扱います。点呼、安全記録、給与や運行管理との連携も、同じ流れの中で扱うことになります。そのため、業務範囲をどこで区切るかの見極めが欠かせません。

乗務員管理システムの役割

乗務員管理システムは、安全かつ適法な乗務割当を支える業務システムです。

• 割当判断：便・路線・車両・勤務への配置を、資格や休息、勤務時間、健康状態、社内規程と照らして決めます。
• 勤怠との違い：出退勤や休暇の記録にとどまらず、安全に乗務できるかの判断まで含みます。
• 発注範囲：台帳、交番表、点呼・アルコール検査、デジタコ、運行管理、給与のうち、どこまでを委託に含めるかです。
• MVP：1営業所や1路線で、台帳、資格期限、勤務計画、本人確認を試す範囲を指します。

全機能を一度に任せるより、範囲を絞って始める方が要件の手戻りを抑えやすくなります。現場で効果を測りながら、範囲を少しずつ広げていきます。

航空・バス・トラック・鉄道の要件の違い

乗務員管理の要件は、業態ごとに扱う予定情報や勤務制約が異なります。

• 航空：フライト、機種資格、訓練・審査、休暇、宿泊・旅費との連携が中心になります。
• バス・タクシー・トラック：便の種類ごとに異なる拘束・休息の決まりへの対応が中心になります。
• 鉄道：循環勤務、駅係員の勤務、列車・担当区所との割当を管理する形です。

たとえば、JTAインフォコムのC3はフライト情報と連携し、約420名の1か月分の予定を管理します。iPadから休暇申請できる事例です（出典: JTAインフォコム「開発実績」、2026年確認）。

バス、タクシー、トラックでは、路線便・貸切便・隔日勤務・宿泊勤務・車庫待ちなどを勤務パターンとして登録します。そのうえで、拘束時間・休息期間・運転時間を判定できるかも確かめます。

改善基準告示の改正内容は、バス、トラック、ハイヤー・タクシーなどで2024年4月1日から適用されています。そのため、発注先には、自社の業態に対応したルール更新の実績を確認します（出典: 厚生労働省「自動車運転者の長時間労働改善に向けたポータルサイト」、2026年確認）。

既製SaaS・パッケージ・スクラッチの選び方

標準機能を使うか、既存システムに合わせるか、独自機能を開発するかによって、発注形態を選びます。

• 既製SaaS：標準的な台帳、申請、シフト、勤怠を短期間で導入したい場合の候補です。
• パッケージ：既存の運行管理や給与を使いつつ、勤務ルールや帳票の差分だけを変えたい場合の候補になります。
• スクラッチ：独自の制約が開発費と保守費に見合うなら、検討の対象になります。

SaaSは、業務を製品の標準に合わせるほど初期費用と期間を抑えられます。一方で、スクラッチは複数法人、独自規程、特殊な資格判定、AI・数理最適化が競争力に直結する場合に選択肢になります。

スクラッチは自由度が高い分、法令や現場ルールの継続的な保守が欠かせません。既製機能で満たせない制約が、その費用に見合うかを比べます。

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

発注は、業務の整理から段階的なリリースまでを順に進めます。自社が業務ルールと受入基準を決め、開発会社が設計と実装を担う体制にすると、役割がはっきりします。

1. 現行業務と発注範囲の整理

発注範囲を決めるために、現行業務、担当者、機能の優先度を洗い出します。

• 基本情報：業態、拠点・乗務員・管理者の数、端末、締め時刻、現行のExcel・紙・システムを一覧にします。
• 業務ルール：営業所ごとの違いを確かめ、共通ルールと拠点固有ルールを分けます。
• 担当者：入力・承認・現場判断を、業務フローの中で誰が担うかを示します。
• 機能の区分：必須・便利・将来拡張に分け、第1段階には台帳、資格期限、勤務計画、休暇申請、勤怠実績を例として挙げます。

第2段階では点呼・アルコール検査やデジタコ連携、第3段階ではAI交番やBI分析を加える案もあります。段階に分けておくと、発注時の費用と将来の予算を社内で説明しやすくなります。

2. 制約条件の要件化とRFPへの記載

RFPには、どの条件を、いつ、どの強さで判定するかを書きます。判定は警告、登録不可、承認必須の3段階に分けます。例外が起きたときの対応も、あらかじめ明記しておきます。

• 判定ルール：資格切れは登録不可、休息不足は警告とし、承認の例外は理由と承認者を監査ログに残します。
• 例外対応：欠勤、臨時便、車両・ダイヤ変更、勤務交換、通信断のそれぞれで、修正する人を決めておきます。
• システム連携：対象名、方向、頻度、方式、データの正本のほか、再送と訂正履歴の扱いも定めます。
• 個人情報：所有権、保存場所、バックアップ、返却・削除、再委託の条件を明示します。

連携の対象は、運行・運航管理、車両、点呼機器、デジタコです。さらに、給与、人事、ID管理、通知、BIとの連携も含みます。APIが使えない場合は、CSVやバッチによる受け渡しも書き込みます。

3. 提案・デモ・小規模検証による実現性の確認

候補会社には同じRFPを渡し、勤務パターンなど共通の例で提案内容を比べます。

• デモ：資格失効、休息不足、欠勤、臨時便を、登録から警告・承認・再割当まで通して試します。
• 変更対応：管理者の設定で対応できるか、個別の改修が要るかを見分けます。
• 小規模検証：1営業所の匿名データを使い、PoCやパイロットで確かめます。
• 効果測定：交番確定時間、手修正、法令エラー、残業の偏り、問い合わせを、導入前後で測ります。

実際の事例では、名鉄バスが既存の乗務員勤怠システムとAI交番を連携させ、交番確定を従来の8〜10時間から最短1.5時間程度に短縮しました（出典: メイテツコム「名鉄バス株式会社様」、2025年）。

4. 開発・テスト・教育と段階リリース

要件定義の後は、画面、データモデル、権限、連携方式、例外処理を設計します。その際、開発会社と自社のどちらが何を担うかも、この段階で確かめておきます。

• テスト：資格失効、休息不足、急な欠勤、臨時便、勤務交換、通信や連携の停止を試します。
• 停止時の運用：安全に関わる業務では、紙や既存Excelでの手動の対応も受入条件に含めます。
• 利用者教育：予定確認、休暇申請、勤務変更の承認、点呼入力、訂正申請を、実機で練習しておきます。
• 段階導入：代表的な1拠点から始め、問い合わせや手修正を改善してから他拠点へ広げます。

全拠点を一斉に切り替えると、移行の誤りと現場の混乱を同時に検証することになります。

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

要件が固まる前に開発を始めると、追加費用や納期遅延が起きやすくなります。そのため、フェーズごとに契約と納品物を分ける設計が有効です。

要件定義で合意する範囲、開発で作る範囲、運用保守で続ける範囲を分けておきます。検収の基準は、機能名ではなく業務シナリオで書きます。

請負契約・準委任契約・時間精算の使い分け

作業内容がどこまで確定しているかに応じて、契約形態と成果の条件を決めます。

• 請負：受入条件を明確にできる機能が対象です。台帳、資格期限一覧、休暇申請、勤務実績の出力などが例です。
• 準委任・時間精算：複数拠点の調査や要件定義、現場ヒアリングを重ねながら進める改善で使われることがあります。
• 契約書：納品物、作業範囲、納期、検収期間、瑕疵対応を盛り込みます。変更管理や追加改修の単価、支払条件も記します。
• AI交番：最適な結果そのものを保証するか、制約違反を防いで管理者が確認・修正できる状態を成果とするかを決めます。
• 条件追加：見積方法を決めて、追加の依頼がすべて無償の改修だと誤解されないようにします。

データ・ソースコード・設定情報の権利の確認

契約の段階で、業務データ、技術資産、設定を変える権限の扱いを決めておきます。

• 業務データ：氏名、連絡先、健康・面談記録、資格、勤務実績は、自社にとって重要な情報です。所有権の扱いも確かめます。
• 保管・移行：利用目的、保存場所、バックアップ、終了時の返却・削除、データの形式を決めておきます。
• クラウド：サービスの標準機能で扱うデータと、自社が登録したデータを区別しておきます。
• 専用開発：ソースコード、インフラ構成、DB定義、API仕様を含め、引き渡す範囲を決めます。運用手順、テスト仕様、管理者設定も、その対象です。
• 保守・設定：著作権をすべて取得しなくても、別の会社が引き継げる利用許諾と技術資料、管理権限を確保します。

設定変更を委託先だけに頼ると、法令改定や拠点追加のたびに依存が続きます。

SLA・セキュリティ・再委託の契約条項

24時間運行や早朝の交番確定がある会社では、業務への影響を踏まえてSLAを定めます。

• 障害基準：勤務計画の確定、資格判定、点呼データ連携ができない状態を、重大な不具合として扱います。
• 業務対応：障害の受付から一次回答、復旧目標、停止通知、データ復旧、代替手段まで、事前に合意しておきます。

2026年のIPA「情報セキュリティ10大脅威」では、組織向け2位に「サプライチェーンや委託先を狙った攻撃」が挙がっています（出典: IPA「情報セキュリティ10大脅威 2026［組織編］」、2026年）。

乗務員の連絡先や健康情報を外部サービスで扱うなら、その対策をRFPと契約に反映します。

• 安全対策：MFA、最小権限、アクセスログ、暗号化を定めます。脆弱性対応、バックアップ、復旧訓練も含めます。
• 事故対応：報告期限、再委託先の社名と作業範囲、国外保管の有無を確認します。
• 監査：再委託先を調べる権利と、報告を受ける権利を確かめます。

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

乗務員管理システム専用の公的な価格統計は少ないため、以下の金額は2026年公開の相場や類似案件を使った推定です。金額だけでなく、前提条件と3年総額をあわせて比べます。

費用は、乗務員数や営業所数、法令ルールの複雑さによって変わります。さらに、連携の本数、移行データ、24時間運用の有無が効いてきます。端末や保守の範囲も、金額を左右します。

発注形態ごとの初期費用と月額費用の目安

既製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、DBなどの設計と、勤務・資格判定、交番・最適化ロジックの開発を分けます。
• 導入：API連携、データ移行、端末、テスト、教育、プロジェクト管理を、別々に確かめます。
• 移行・連携：データ入力、重複や欠損の補正、履歴の変換、リハーサルを明記します。API・CSV、監視と再送、仕様変更の扱いも書き込みます。
• AI交番：制約、最適化モデル、確認画面、手修正の記録、再計算について、費用を分けて示します。

APIを新規開発するか、既存のAPIを使うか、CSV出力にするかも、分けて確かめます。

人月単価の公開目安は、プログラマが40万〜60万円、SEが60万〜100万円、PM・上流担当が80万〜130万円程度です。単価だけでなく、人月と納品物の対応も見ます。

初期費用ではなく3年TCOでの比較

クラウドやSaaSでは、利用人数や拠点、端末、通信の費用が続いていきます。さらに、APIや保守、法令改定対応の費用もかかります。

一方で、スクラッチは初期費用が大きくても、自社の運用に合わせて費用の構造を組み立てられます。

• 3年TCO：初期開発費に、月額36か月分を足したもの。
• 追加費用：端末・通信、データ移行、教育、保守、改修、障害対応も含めて見ます。
• 効果測定：交番確定時間、残業、手修正、法令チェックを比べます。資格期限、問い合わせ、欠勤時の再割当時間も、導入前後で見ます。

削減できる時間と、事故や行政指導、給与計算ミスのリスク低減は、分けて示すと経営層に説明しやすくなります。

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

委託先は、知名度や見積総額だけでなく、対応できる業態と得意な機能を比べて選びます。

既存システムとの連携方法も、あわせて確かめます。業界理解に強い会社と特定機能に強い会社を組み合わせる場合は、障害対応を誰が受け持つかを先に決めておきます。

責任の分け方は、一社に任せるか共同体制にするかで変わります。そのため、どこまでを誰が受け持つかを明確にしておきます。

業界・業務実績の確認方法

導入事例は、業態と対象業務が自社に近いかを見ながら、複数の候補を比べます。

• 航空：JTAインフォコムのC3などで、フライト、資格、訓練、休暇、乗務時間を統合した実績を見ます。
• バス・鉄道：メイテツコム、株式会社工房、アイテック阪急阪神などの勤怠・勤務・点呼事例を比べます。
• 最適化：ALGO ARTISなどの実績と、既存の勤怠・運行管理との連携を確認します。

三菱電機デジタルイノベーションの東京空港交通の例では、乗務員以外に、宿泊隔勤、車両整備、バス管制も管理します。人数、拠点、期間のほか、連携や開発の境界も確かめます。保守と支援担当者の体制も見ます。

相見積もりで条件をそろえて比較

候補会社を選ぶときは、共通の前提と判断基準を持って比べます。

• 共通条件：各社に同じRFP、サンプルデータ、デモの課題を渡します。
• 見積比較：項目を横に並べ、含むもの、含まないもの、前提、別途費用を整理します。
• 総額の前提：A社は連携や移行が別途、B社は保守や法令改定対応を含むといった違いが出ることがあります。
• 評価表：業務適合性、法令・資格判定、連携、使いやすさ、拡張性を観点に分けて評価します。セキュリティ、支援、保守、3年TCOも含めます。
• 提案内容：標準、設定、カスタマイズ、将来対応に分けて、値引きよりも要件の抜けと変更単価を確かめます。

見積総額だけでは判断しきれないため、各社の前提を並べて読むと、予算超過を防ぎやすくなります。

デモで見る例外処理と運用

画面の見栄えだけでなく、例外処理や導入後の支援、運用手順も評価します。

• 例外処理：欠勤、資格更新の遅れ、臨時便、交替者不在のときに、候補を検索できるかを確かめます。
• 判断・通知：法令違反を避けつつ、管理者が承認し、本人へ通知できるかを確認します。
• 警告・監査：理由が現場に伝わり、誤検知を直して、その履歴をたどれるかを見ます。
• 導入後支援：規程変更、営業所追加、担当者異動への対応を見ておきます。
• 運用手順：問い合わせ、障害連絡、データ訂正の手順が、契約やマニュアルに書かれているかを確かめます。

運行・運航、安全、労務、現場代表が加わると、見落としによる手戻りを減らせます。

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

乗務員管理システムの失敗は、開発技術そのものより、業務ルールの曖昧さや現場の入力負担から起きます。既存システムとの担当の境目、移行データの品質、運用変更の準備不足も、同じように原因になります。

発注の時点で、リスクを洗い出し、誰が、いつまでに、どの判断をするかを決めておきます。そうすると、開発会社任せのプロジェクトになりにくくなります。

法令チェックを警告だけで終わらせない設計

法令チェックは、警告を出すだけで終わらせず、登録不可、例外承認、理由入力、監査記録に分けて設計します。

航空や鉄道では、運航規程や乗務資格、教育・審査も要件に含めます。安全管理や勤務協定も、要件として扱います。そのうえで、運行・運航、安全、労務、情報システム、現場代表を会議体に加え、最終承認者を決めます。

健康・資格・勤務データを守る担当の分け方

乗務員管理では、連絡先や健康状態、面談記録に加えて、資格や勤務・乗務の履歴も扱います。閲覧、登録、承認の権限は、所属、営業所、職種、役割ごとに分けます。

安全管理を外部に任せても、個人情報を扱う事業者の確認責任は残ります。そのため、監査ログや事故報告、再委託先、終了時の削除などの取り決めを、RFP・契約・運用手順で揃えます。

1営業所のパイロットによる現場定着の測定

パイロットでは機能だけでなく、現場で使えるか、業務にどれだけ効果があるかを測ります。

• 利用確認：点呼前の入力、スマートフォンでの予定確認、欠勤者の再割当にかかる時間を測ります。
• 基準値：導入前の数値を2〜4週間記録し、交番の作成・確定時間、修正・訂正の数、警告と解消時間、問い合わせ、利用率、残業の偏りを導入後と比べます。
• 次拠点への展開：要望を、全社共通の機能、営業所ごとの設定、運用で吸収する項目に分けて、RFPや追加開発のバックログに反映します。
• 定着支援：リリース後3か月、6か月、1年の時点での対応を、委託先に提案してもらいます。

次の拠点でも要望の分け方をそろえておけば、手戻りを減らせます。また、節目ごとの定着支援があれば、開発が終わったあとに社内だけで運用を抱え込むリスクを抑えられます。

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

発注前によく挙がる疑問を、費用、進め方、委託先選びの観点から答えます。

答えは、自社の業態や拠点数、乗務員数、既存システムによって変わります。それでも、判断の起点をはっきりさせておくと、候補会社との打ち合わせが具体的になります。

乗務員管理システムの開発費用はいくらかかりますか？

標準的なSaaSやクラウドの設定導入は、初期10万〜100万円、月額2万〜20万円程度が目安です。パッケージのカスタマイズは、初期100万〜500万円程度が目安です。

連携の多い中規模開発は800万〜2,000万円です。複数法人や複雑な最適化を含む場合は、1,500万〜5,000万円以上になる可能性があります。

これは専用の統計ではなく、類似の業務システムからの推定です。そのため、対象人数、拠点、連携、移行、保守に分けた見積もりで確かめます。

RFPがなくても開発会社へ相談できますか？

相談はできます。まず、対象業態、乗務員数、拠点数、現在の業務方法を整理します。そのうえで、困っている作業、連携したいシステム、導入の希望時期を伝えると、話が進みやすくなります。

RFPが未完成でも、要件定義の支援を含む提案を依頼できます。その場合は、作る成果物の所有権や期間、費用、次の開発に進む条件を確かめます。

複数社で比べられるよう、同じ課題とサンプルのケースを渡すことが大切です。

乗務員管理システムはSaaSとスクラッチのどちらがよいですか？

標準的な台帳、申請、シフト、勤怠が中心で、業務を製品に合わせられるなら、SaaSが適しています。既存システムを活かして差分だけを変えたい場合は、パッケージをカスタマイズします。

独自規程や複数法人の統合が競争力に直結する場合は、スクラッチを検討します。その際は、標準機能で80％を満たせるか、独自の制約を設定で変えられるか、既存の連携を保てるかを比べます。

外注すると乗務員の個人情報は安全に管理できますか？

リスクになるのは外注そのものより、確認しないまま委託することです。

• 委託先確認：権限、再委託、保管場所、ログ、バックアップ、障害対応を、事前に確かめます。
• 体制・実績：委託先のセキュリティ体制と運用実績を見ます。
• 安全対策：MFA、最小権限、暗号化、ログ、脆弱性対応、事故報告を、RFPと契約に定めます。
• 終了時の扱い：返却・削除と復旧テストを定めます。健康・資格情報は、必要な担当者だけが閲覧できるようにします。

まとめ

乗務員管理システムの発注・外注では、まず業態や拠点、乗務員数を押さえます。次に、現行業務、既存の連携、法令や社内規程を洗い出します。

発注担当者は、資格期限や休息、拘束時間などの制約をRFPに具体的に書き込みます。欠勤や臨時便、点呼、給与連携についても、同じように書き込みます。そのうえで、候補会社に同じ条件で提案と見積もりを依頼します。

最初に作る資料：業務一覧と制約条件

業務一覧には、現行業務、担当者、機能の優先度を洗い出した結果をまとめます。制約条件は、資格切れは登録不可、休息不足は警告とするように、条件ごとに判定の強さまで書いておきます。

既製SaaS、パッケージのカスタマイズ、スクラッチのどれを選ぶ場合でも、1営業所のパイロットとKPIを設定して、現場の定着と業務効果を確かめることが大切です。

委託先に求める運用まで含めた仕組み

機能を納品して終わりにせず、安全な判断と継続した利用を支えるところまでを成果と考えます。

管理者が安全に判断でき、乗務員が迷わず使い続けられる仕組みを、委託先に求めます。

見積比較では、初期費用の安さだけでなく、3年TCOやデータ移行、連携まで確認します。特に、法令改定への対応や教育、保守を見ます。さらに、セキュリティや再委託、契約終了時のデータ引渡しも確かめます。

• 選定基準：業界経験、要件を整理する力、連携とセキュリティの体制を見極めます。
• 契約条件：導入後の伴走と、自社と委託先のあいだでどこまでを受け持つかを定めます。

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

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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