海運業界のシステム開発の発注/外注/依頼/委託方法について

海運業界のシステム開発を発注・外注するなら、洋上の通信断、多国籍の現場、港湾・税関とのデータ連携を前提に、要件定義から段階的に進めることが重要です。

海運業界では、船舶の運航管理、用船契約、貨物・運賃管理、港湾荷役、航海採算、船員管理などが一つの業務につながっています。そのため、単に紙やExcelをWeb画面に置き換えるだけでは、現場の負担が増えたり、システム間の二重入力が残ったりします。本記事では、海運業界のシステムを発注・外注・委託する際の発注形態、RFPと要件整理、契約、費用相場、委託先選定、見積比較のポイントを、2026年時点の動向を踏まえて解説します。

海運業界のシステム開発が難しい理由

海運業界のシステム開発では、陸上のオフィス業務だけでなく、船上、港湾、倉庫、運送会社、荷主、船舶代理店、税関などを一つの業務プロセスとして捉える必要があります。特に、通信品質と利用者の環境が場所ごとに大きく違う点が、一般的な業務システムとの大きな違いです。

船上では、航行する海域や契約している衛星通信によって、通信速度、遅延、利用可能な時間、通信費が変わります。常時オンラインのクラウドシステムを前提にすると、通信が不安定なときに入力が失われたり、画面が開かずに紙へ戻ったりするリスクがあります。発注前に、どの機能をオフラインで使えるようにするか、船内に一時保存するデータは何か、通信回復後にどの順番で差分同期するかを要件に明記することが大切です。

海運の一つの案件には、船員、船長、運航担当、荷主、フォワーダー、港湾作業員、倉庫、トラック会社、船舶代理店、税関などが関わります。入力項目の意味や締め切りが部署ごとに違うため、画面を作る前に業務用語と責任分界を揃えなければなりません。また、外国人船員が使う画面では、英語などの多言語対応だけでなく、乗下船のたびに短時間で覚えられるUIと教育方法も必要です。

港湾や税関とのEDI、船舶代理店との情報交換、社内ERP、運航管理、会計、燃料管理をつなぐときは、インターフェースごとにデータ形式と更新タイミングを定義します。IMOによると、海事シングルウィンドウは2024年1月1日から加盟国の港で義務化され、入港・滞在・出港に関する情報を一つの窓口で電子交換する考え方が求められています（出典: International Maritime Organization、2024年）。この流れを踏まえ、自社だけで完結する画面ではなく、外部システムと再利用できるデータモデルを先に考えます。

海運業界のシステムはどの発注形態が適していますか？

結論として、海運業界のシステムでは、要件が固まっている範囲は請負、変化が多い上流工程や運用改善は準委任、既存サービスで代替できる範囲はSaaS導入を組み合わせる方式が現実的です。一社に丸ごと外注する方法もありますが、発注者が業務知識と意思決定を手放すと、過剰なカスタマイズや責任の曖昧さにつながります。

運航予定、船員管理、請求、ワークフローなど、業務が標準化されている領域はSaaSや業界パッケージを優先します。初期費用を抑えやすく、アップデートやセキュリティ対策を自社だけで抱え込まずに済む点がメリットです。一方、用船契約の条件、航海単位の採算、特殊貨物の安全確認など、競争力に直結する業務を無理に標準仕様へ合わせると、現場がExcelへ戻る可能性があります。API、データ出力、オフライン対応、海外利用、解約時のデータ返却を確認します。

自社独自の運賃計算、船舶ごとの制約、港湾荷役の安全手順、複数通貨の採算管理などを標準サービスで表現できない場合は、SI会社や開発会社へ委託します。自由度は高い一方で、発注者側に要件を決める責任が生まれます。特に「海運業務を理解している会社」という曖昧な条件だけで選ばず、実際に船・港・代理店・荷主を含む業務フローを説明できるか、類似のEDI連携と移行実績があるかを確かめます。

おすすめしやすいのは、最初に業務整理・現状調査を委託し、次に小さな実証、最後に本開発と展開へ進む方式です。例えば、最初の対象を一航路または一港の入港予定・荷役計画・トラック手配に限定し、通信断時の入力と復旧後の同期を検証します。実証で得た業務ルールをRFPへ反映すると、初期段階から全社基幹を作り込むより、手戻りと過剰カスタマイズを抑えやすくなります。

海運業界のシステム開発を進める手順

発注前に「何を作るか」だけでなく、「どの業務をどの順に変えるか」を決めます。海運ではシステム障害が配船、荷役、通関、請求へ連鎖するため、移行計画と業務継続計画を開発計画と同じ重さで扱います。

電話やFAXが残っているからといって、最初からすべてを高機能なシステムへ置き換える必要はありません。船の入港タイミング、サイロや倉庫の空き、トラックの手配、安全確認など、関係者が毎回判断している項目を洗い出し、定時連絡の時刻、入力担当、異常時の連絡先、確認済みの定義を決めます。港湾荷役のように火災や異物混入が安全に直結する現場では、チェックリストと連絡プロトコルを揃えるだけでも、システム要件の質が大きく上がります。

業務フローを船上、運航部門、港湾、倉庫、経理などの単位で描き、誰が、いつ、何を入力し、どのデータを次の工程が使うかを整理します。航路、港、船舶、貨物、荷主、運賃、燃料油、為替、取引先、船員などのマスタは、項目名、コード、更新権限、履歴、廃止ルールまで決めます。発注者がマスタをベンダー任せにすると、現場の呼び方とシステムの値がずれ、請求や採算が合わなくなるためです。

全船・全港を一斉に切り替えると、問題の原因が仕様、データ、教育、通信のどこにあるか分かりにくくなります。まず代表性のある一航路で、入港前の情報収集、荷役計画、船陸同期、実績登録、採算集計までを通して検証します。パイロットでは機能の完成度よりも、通信が切れた状態、外国人船員が初めて使う状態、港湾側が別システムを使う状態で業務が止まらないかを確認します。

納品日に操作説明を一度行うだけでは定着しません。短い動画、英語などの多言語マニュアル、船員交代時の引き継ぎ、問い合わせ窓口、障害時の紙運用、毎月の利用状況確認まで設計します。導入後は、入力漏れ、同期失敗、二重登録、処理時間、問い合わせ件数をKPIにして、現場の声を次の改善へつなげます。システムの完成をリリース日ではなく、二重管理が減り、安全と採算の判断が早くなった時点と定義します。

RFPと要件整理で何を決めればよいですか？

RFPは、ベンダーへ希望を伝える資料ではなく、同じ前提で提案と見積を比較するための発注条件です。機能一覧だけでは海運特有のリスクを表現できないため、業務の背景、利用者、データ、制約、品質、移行、体制、見積条件を一体で記載します。

「海運業務を効率化する」ではなく、「入港予定の変更を船・港・倉庫・トラック会社が同じ情報で確認できる」「Voyageごとの収入、燃料、港費、為替を締め後何日以内に把握する」のように、対象業務と達成指標を書きます。対象外も重要であり、会計は既存ERPを使う、船員給与は別システムのままにするなど、今回作らない範囲を明示します。対象範囲が曖昧なRFPは、提案段階の安い見積が後から膨らみやすくなります。

RFPには、通信断が何時間続いても入力可能にするか、端末に何件までデータを保持するか、同期の競合をどう解決するかを書きます。さらに、対応言語、文字サイズ、教育時間、権限、監査ログ、バックアップ、復旧目標、暗号化、脆弱性検査、外部API、EDIの標準、時差、通貨、単位、タイムゾーンも確認します。IMOは2025年5月に海事シングルウィンドウの設定ガイドラインを公開しており、発注者は単独の画面ではなく、船・港・公的機関の情報交換と相互運用性を要件に含める必要があります（出典: International Maritime Organization、2025年）。

既存のExcel、古い運航システム、会計、EDI、紙帳票から何年分を移行するか、重複や欠損を誰が直すかを決めます。受入基準は「動くこと」ではなく、通信を切っても入力できること、同じデータを二重送信しないこと、航海採算の集計結果が既存帳票と一致すること、外国語表示でも主要操作を完了できることなど、業務で検証できる表現にします。IPAも要件定義では利害関係者と合意した要求を要件定義書に文書化することを示しており、口頭合意を残さない運用が重要です（出典: 独立行政法人情報処理推進機構、2023年）。

海運業界のシステム外注で契約形態をどう選びますか？

契約は、作業の不確実性と成果物の明確さに合わせて分けます。契約書の名称だけで判断せず、成果物、検収、変更、責任分界、知的財産、データ返却、障害対応、再委託、終了条件を確認します。

請負契約は、合意した仕様に基づく設計、実装、試験、納品など、成果物と検収条件を定義しやすい工程に適しています。例えば、確定した入港予定管理画面、API仕様、帳票、テスト結果を納品対象にします。ただし、海運の要件は港や契約条件の確認で変わりやすいため、変更要求の受付方法、追加見積の単価、納期への影響、優先順位の決め方を契約と別紙に記載します。変更を無制限に含める契約は、双方の負担と品質低下を招きます。

現状調査、業務整理、RFP作成支援、プロトタイプ、アジャイルな改善など、作業を通じて要件を具体化する工程は準委任契約と相性がよいです。発注者とベンダーが同じプロジェクトチームとして動き、月ごとの作業時間や体制に対して支払います。その代わり、何を作るかをベンダーへ丸投げせず、発注者側のプロダクト責任者、現場代表、データ責任者を置きます。IPAは、ユーザー企業とベンダーがリスクやセキュリティ対応コスト、責任分界を共通理解にする重要性を示しています（出典: 独立行政法人情報処理推進機構、2024年）。

洋上で通信が切れた場合、システムが停止したのか、通信会社の障害なのか、船内端末の問題なのかを切り分けられるよう、監視対象と連絡先を決めます。復旧目標時間、バックアップ頻度、脆弱性対応、休日の連絡、データの保管地域、個人情報や船舶情報の扱い、第三者サービスの障害時対応を確認します。サイバーポートでは自社システムとのAPI連携による二重入力解消の事例が公開されているため、港湾側のサービスを使う場合もAPI仕様、料金、可用性、将来の仕様変更を契約前に確認します。

海運業界のシステム開発費用相場と内訳

海運業界のシステム開発費用は、利用者数よりも、対象業務、外部連携、データ移行、オフライン要件、海外展開、セキュリティ、運用体制で大きく変わります。公的に一つの平均相場が定められているわけではないため、以下は予算を組む際の実務的な目安として扱い、必ず同じ前提の見積で比較します。

一港・一航路の業務を対象にしたPoCや入力画面、簡易ダッシュボードなら、調査・設計を含めて数百万円から1,000万円前後が一つの検討レンジになります。複数部署で使う運航・荷役・請求の業務システムに、認証、権限、帳票、既存システム連携、移行を含める場合は、1,000万円台から数千万円規模になりやすいです。船陸同期、EDI、航海採算、複数国・複数言語、全社基幹刷新まで含めると、数千万円から1億円超も想定し、段階発注で投資効果を確認します。これは相場の断定ではなく、機能数とリスクを分解するための予算仮説です。

初期費用には、現状調査、要件定義、UI設計、アプリ開発、API・EDI連携、インフラ構築、テスト、データ移行、教育が含まれます。別枠で、クラウド利用料、衛星通信や回線、端末、ライセンス、監視、保守、問い合わせ、脆弱性対応、バックアップ、追加開発を見積もります。保守費を開発費の一定割合だけで決めず、毎月何人が何時間対応するか、障害対応と改善をどこまで含むか、船舶数やデータ量が増えた場合にどう変わるかを確認します。

パッケージの標準機能を調べずに、現場ごとの例外をすべて開発すると、費用だけでなくテストと保守の負担も増えます。例外を「法令や安全上必須」「採算や顧客価値に直結」「一時的な慣習」に分類し、最後のものは業務ルールを標準化できないか検討します。船陸同期や外国語UIなど、海運特有の要件は削らず、汎用的な承認画面やマスタ管理は標準機能へ寄せると、投資配分が明確になります。

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

価格が低い会社を選ぶのではなく、同じ業務成果を、同じ品質と範囲で実現できる会社を選びます。提案書の見栄えより、質問の深さ、リスクの指摘、標準化と個別開発の切り分け、現場への定着計画を評価します。

候補会社には、船舶や港湾、物流、貿易、基幹システムの実績だけでなく、通信断を含むエッジ・クラウド構成、APIやEDI、複数通貨、監査ログ、データ移行の事例を確認します。実績は会社名や業界名だけでなく、担当範囲、利用者数、連携先、稼働後の保守体制、失敗と改善策まで聞きます。提案会では、候補会社に同じ業務シナリオを示し、入港予定が通信断の間に変更された場合や、同じ貨物データが二重送信された場合の設計を説明してもらいます。

見積比較では、要件定義、設計、開発、テスト、移行、教育、PM、インフラ、ライセンス、保守を分け、作業量、単価、期間、前提、除外事項を並べます。「一式」の項目は、成果物と工数の説明を求めます。特に安い見積は、データクレンジング、外部連携、オフライン試験、現場教育、リリース後の改善が含まれていない場合があります。逆に高い見積は、不要な個別機能や過剰な会議体が含まれていないか確認します。

サプライチェーンを止めないため、切り戻し条件、旧システムとの並行期間、障害時の紙・電話運用、データの復旧手順を決めます。要件追加を誰が承認するか、予算超過を何％で経営会議へ上げるか、パイロットを継続しない条件は何かも明文化します。大規模なERP刷新を一度に進める場合は、過去の他業界事例でも移行遅延や調達停止が事業に影響したため、段階移行、データ照合、業務継続テストを必須の見積項目にします。

よくある質問

ここでは、海運業界のシステムを発注・外注する際に、特に相談の多い疑問へ回答します。

一港・一航路の小規模な実証なら数百万円から1,000万円前後、複数部門の業務システムなら1,000万円台から数千万円、EDI・船陸同期・航海採算・多国展開まで含めると数千万円から1億円超を検討するケースがあります。機能、連携数、移行件数、オフライン要件、教育範囲で変わるため、金額だけでなく見積の前提と除外事項を比較してください。

業務の目的、現状フロー、対象範囲、データ、利用者、制約は自社が中心になって作る必要があります。書式や技術要件、現行システム調査、概算、候補会社との質疑は外部の支援会社へ委託できます。発注者が業務の判断を持ち、外部支援会社は整理と可視化を担う役割分担が適切です。

できますが、すべての機能をオフライン対応にするのではなく、船上で必要な入力・参照・確認を選びます。端末や船内サーバーへ一時保存し、通信回復後に差分同期する方式を検討します。競合データの解決ルール、同期失敗時の再送、時刻の扱い、暗号化、端末紛失時の消去、テスト海域をRFPへ明記してください。

標準業務が多く、海運特有の運航・用船・採算機能が必要なら、海運特化型ERPを候補にします。会計、人事、購買など共通業務は汎用ERPを使い、運航や港湾との連携を周辺システムで補う構成も有効です。製品名だけで決めず、実際の航海シナリオ、運賃・燃料・為替、港湾EDI、通信断、多言語画面をデモで確認し、カスタマイズ費と将来のアップデート影響を比べます。

要件を整理したうえで、3社程度から同じRFPに対する提案を取ると比較しやすくなります。会社数を増やしすぎると質疑と評価が浅くなるため、海運・物流の業務理解、通信やEDIの技術力、保守体制、予算規模、担当者との相性で候補を絞ります。最終的には見積金額だけでなく、リスクを先に指摘し、段階導入と定着まで説明できる会社を選びます。

まとめ

発注者は、現場ルール、マスタ、要件の優先順位を決める責任者を置きます。委託先に専門的な設計と開発を任せても、業務上の判断まで外注しないことが成功の前提です。

一航路・一港のパイロットで通信断、EDI、教育、移行を確認し、受入基準を満たしてから対象を広げます。段階的な発注にすると、見積の前提を現実のデータで更新しながら投資を管理できます。

海運業界のシステムを発注・外注する際は、まず船上・港湾・陸上の業務をつなぐ目的を定め、現場ルールとマスタを整理します。そのうえで、SaaSやパッケージで標準化できる範囲、個別開発が必要な範囲、準委任で要件を固める範囲、請負で成果物を作る範囲を切り分けます。

とくに重要なのは、通信断から復旧した後の差分同期、多国籍船員が迷わないUI、港湾・税関とのEDI、Voyage単位の採算管理、データ移行と業務継続です。2026年の港湾DXでは、国土交通省がサイバーポートを共通インフラとして民間サービスや自社システムとの連携を進めています（出典: 国土交通省、2026年）。自社内だけのシステムを作るのではなく、外部標準と将来の連携を見据えたRFPにします。

最後に、安い見積を選ぶのではなく、同じ前提で費用・範囲・品質・体制を比較し、一航路や一港のパイロットで検証してから段階的に展開します。発注者が業務とデータの責任を持ち、委託先の専門性を活かす体制を作れば、過剰カスタマイズや現場の二重管理を抑えながら、海運業界のシステムを事業に定着させやすくなります。

参考・出典: International Maritime Organization「Maritime Single Window」、International Maritime Organization「FAL related guidance」、国土交通省「港湾ロジスティクスの強化に向け港湾手続のデジタル標準化を推進」、独立行政法人情報処理推進機構「情報システム・モデル取引・契約書」、独立行政法人情報処理推進機構「要件定義とは」、Cyber Port・CONPASポータル（いずれも2026年8月確認）です。

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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