ヘキサゴナルアーキテクチャのシステム開発の発注/外注/依頼/委託方法について

ヘキサゴナルアーキテクチャのシステムを発注するなら、業務ルールを技術から分離する設計方針と、要件・契約・テスト・保守の責任範囲を先に決めることが重要です。

ヘキサゴナルアーキテクチャは、単に「モダンな技術で作ってください」と依頼すれば完成するものではありません。発注形態の選択、RFPの作成、契約方式、費用の見方、委託先の評価までを一つの流れとして整理する必要があります。この記事では、受発注・在庫・会計などの業務システムを外注するときに、何を決め、何を見積書で比較し、どの成果物を契約に含めるべきかを実務向けに解説します。

▼全体ガイドの記事
・ヘキサゴナルアーキテクチャのシステム開発の完全ガイド

ヘキサゴナルアーキテクチャのシステム発注の全体像

発注の出発点は、ヘキサゴナルという名称ではなく、将来も変更されにくくしたい業務ルールと、交換・追加の可能性がある外部接続を切り分けることです。中心にユースケースやドメインのルールを置き、画面、API、データベース、外部サービス、メッセージ基盤などをポートとアダプターで接続します。

「ヘキサゴナルアーキテクチャで開発してください」という一文だけでは、会社ごとに解釈が変わります。RFPでは、受注登録の業務ルールをDBなしでテストできること、REST APIと夜間バッチが同じユースケースを利用すること、RDBの交換時にドメイン層を変更しないことなど、確認できる状態に置き換えます。成果物としては、コンテキスト境界図、依存方向を示す構成図、ポート定義、アダプター一覧、テストコード、CI/CD設定、監視設計までを対象にします。

複数の入力経路から同じ業務ロジックを使う案件、ERP・決済・在庫など外部連携が多い案件、制度変更やサービス交換が想定される長期運用の案件は、分離の投資効果を出しやすいです。一方、利用期間が短い小規模なCRUDツールや、画面と単一DBだけで完結する試作では、ポートや変換コードが保守負担になる可能性があります。AWS Prescriptive Guidanceも、複数の入力元・出力先や将来の技術変更がある場合に適し、接続先が少ない場合は追加レイヤーの保守負担と遅延に注意する設計として説明しています（出典: AWS Prescriptive Guidance、2026年8月確認）としています。

発注形態はどれを選べばよいですか？

発注形態の結論は、要件の確定度と、発注側がどこまでプロジェクトを管理できるかで決まります。すべてを一社に委託する方法、設計や要件定義を自社で持って実装を外注する方法、複数社を組み合わせる方法には、それぞれ適した条件があります。

要件、対象業務、連携先、納期、受け入れ基準が比較的明確なら、要件定義から設計・開発・テストまでを主契約者にまとめる一括請負が候補になります。発注側の窓口を一本化しやすく、予算を計画しやすいことが利点です。ただし、アーキテクチャの判断やドメイン境界を受託会社に任せきりにすると、納品後に設計意図が分からなくなるリスクがあります。設計書、テストコード、リポジトリ、CI/CD、IaC、依存ライブラリ一覧を納品対象に明記してください。

要件を検証しながら進める新規事業や、既存システムの解析が必要な段階移行では、準委任契約でアーキテクトや開発チームを一定期間確保する方法が有効です。発注側が業務判断と優先順位を持ち、委託先が設計・実装を支援するため、変更に対応しやすくなります。自社のプロダクトオーナー、業務責任者、技術責任者を置き、意思決定の期限を決めることが前提です。丸投げに近い状態では、準委任にしても成果が安定しにくいです。

パッケージ導入会社、アプリ開発会社、クラウド運用会社を組み合わせる場合は、誰がポートを定義し、誰がアダプターを実装し、誰が障害を一次切り分けするかを決めます。特にデータ移行、認証、外部API、監視、バックアップは会社の境界で抜けやすい領域です。RACI表やシステム境界図を契約添付資料にし、インターフェース仕様と受け入れテストの責任者を明示すると、相互に「相手の範囲」と主張する事態を避けられます。

RFPと要件整理では何を決めますか？

RFPは機能一覧だけでなく、業務ルール、外部接続、品質基準、納品物、運用責任を同じ資料にまとめます。ヘキサゴナルアーキテクチャでは、業務の中心と技術の境界を正しく定義できるかが品質を左右するため、現行資料が不完全な場合は、開発前に診断・PoCフェーズを置くことも選択肢になります。

「受注を登録する」だけでは見積もれません。誰が、どの条件で、どのデータを入力し、在庫不足や与信超過のときに何を返し、二重送信をどう扱うかまで書きます。例えば受注登録では、販売担当者が商品・数量・納期を入力し、在庫引当が成功した場合だけ受注を確定する、という流れをユースケースにします。金額計算、権限、状態遷移、監査記録、再実行可否を業務ルールとして整理すると、中心のドメインに何を置くべきかが明確になります。

RFPには入力ポートとしてWeb画面、REST API、バッチ、キュー受信を記載し、出力ポートとして受注リポジトリ、在庫照会、決済、通知、ERP連携などを分けて書きます。各ポートについて、入力・出力データ、エラーコード、タイムアウト、リトライ、冪等性、認証方式、性能目標を指定します。アダプターは接続先ごとに実装し、業務ルールがAWS SDK、JDBC、HTTPクライアントなどを直接呼ばないことを受け入れ条件にします。AWSのガイダンスでも、ポートは技術に依存しないインターフェース、アダプターは外部とのデータ交換を変換する実装として整理されています（出典: AWS Prescriptive Guidance、2026年8月確認）とされています。

可用性、応答時間、同時利用者数、復旧時間、バックアップ保持期間、ログ保存期間、脆弱性対応期限を、可能な範囲で数値にします。さらに、ドメイン単体テストの実行方法、外部サービスを使わないテスト、契約テスト、性能試験、障害時の追跡方法をRFPに含めます。完成条件を「画面が動く」だけにせず、「テスト環境でアダプターを交換できる」「障害ログからポートと外部接続を追跡できる」まで定めることが大切です。

ヘキサゴナルアーキテクチャの開発はどう進めますか？

開発は、業務の境界を決める企画・要件定義、ポートとドメインを設計する方式設計、アダプターを含む実装、テスト・移行・運用設計の順で進めます。最初から全機能を作るのではなく、重要な一つのユースケースでアダプター交換とテスト容易性を確認すると、設計の勘違いを早い段階で発見できます。

設計初期には、受注、在庫、請求、配送などの業務境界を整理し、どのルールをドメイン層に置くかを合意します。アプリケーション層はユースケースの順序やトランザクションを調整し、入力アダプターはHTTPや画面の形式を変換し、出力アダプターはDBや外部APIの差異を吸収します。依存方向は外側から中心へ向かう形にし、中心のコードが具体的なフレームワークを参照していないことを、構成図とコードレビューの両方で確認します。

PoCでは、受注登録など業務上重要なユースケースを一つ選び、画面またはAPIから入力し、ドメインルールを通り、テスト用アダプターと実DBアダプターを切り替えて結果を確認します。PoCの合格条件は、ドメイン単体テストが外部環境なしで実行できること、外部APIのスタブで異常系を再現できること、同じポートに別アダプターを接続できることです。PoCを作らずに設計書だけで全体を確定すると、現場でアダプターの責務が曖昧になりやすいです。

単体テストではドメインの計算や状態遷移を確認し、契約テストではポートの入出力を確認し、統合テストでは実DB・外部API・メッセージ基盤を確認します。既存システムの刷新では、現行データの意味を解析し、アンチコラプション層や変換アダプターを設け、機能単位の並行稼働とデータ照合を行います。富士通のモダナイゼーション資料でも、既存業務システムの構造とデータを整理して移行計画につなげる考え方が示されており、全面再構築だけを前提にしないことが重要です（出典: 富士通「業務システムのモダナイゼーション」、2025〜2026年公開資料）とされています。

契約形態はどのように組み合わせますか？

契約は、要件の不確実性が高い工程と、完成物を確定しやすい工程を分けて考えます。ヘキサゴナルアーキテクチャでは、現行システムの解析やドメイン境界の決定に不確実性が残りやすいため、初期調査から本開発までを一つの固定価格にしないほうが、双方のリスクを管理しやすい場合があります。

請負契約を採用するなら、対象機能、対応ブラウザや端末、連携先、性能、セキュリティ、移行データ、検収方法を契約書や仕様書に結び付けます。「ヘキサゴナル対応」だけでは完成基準にならないため、中心層から外部SDKへの直接依存がないこと、指定したテストが通ること、設計書とソースコードを引き渡すことを受け入れ条件にします。追加変更の扱い、前提条件が崩れた場合の協議方法、遅延時の責任もあらかじめ定めます。

準委任契約では、一定期間のアーキテクト、テックリード、開発者、QAなどの体制と、担当する作業を明示します。成果物の完成を一方的に保証する契約ではないため、週次のレビュー、設計判断の記録、リスク一覧、品質指標、次週の予定を定例化します。人月や稼働時間だけを管理すると、ポートの定義やテスト設計が後回しになるため、ユースケース単位の進捗と未解決の設計課題も報告対象にしてください。

契約では、ソースコードだけでなく、テストコード、設計書、API仕様、IaC、CI/CD設定、コンテナ定義、依存ライブラリ一覧、運用手順書を誰が利用できるかを定めます。既存の汎用部品やOSSの権利と、今回開発する個別部分の権利を分け、二次利用や改修を妨げない条件を確認します。保守契約では、障害対応時間、脆弱性の修正期限、クラウド費用、追加アダプターの単価、担当者交代時の引き継ぎ方法を分離して記載すると、納品後の費用を比較しやすくなります。

費用相場とコストの内訳はどう見ますか？

ヘキサゴナルアーキテクチャだけの公的な価格統計はないため、金額は一般的な業務システムの規模、連携数、移行範囲、非機能要件から見積もります。以下のレンジは、リサーチノートにある2026年公開の費用情報と業務システムの見積もり観点をもとにした編集用の概算です。実際の金額は、要件定義後に各社から内訳付きで取得してください。

アーキテクチャ診断や設計だけなら50万〜150万円程度、小規模な新規業務システムなら500万〜1,000万円程度、部門横断で複数システムと連携する中規模案件なら1,000万〜3,000万円程度が一つの比較レンジです。既存システムの対象領域を切り出す段階移行は、対象範囲ごとに800万〜3,000万円程度、全社基幹や高可用性を含む大規模案件は3,000万円〜1億円以上になる場合があります。いずれも固定相場ではなく、利用者数、機能数、外部連携、データ移行、性能、24時間運用の有無で大きく変わります。

比較材料として、SIA株式会社が2026年版として公開する目安では、小規模業務ツール100万〜300万円、中規模の部門横断システム500万〜1,000万円、大規模基幹システム1,000万円〜数千万円以上、人月単価60万〜200万円程度とされています（出典: SIA株式会社「システム開発の費用・相場 2026年版」、2026年確認）。別の業務システム相場でも幅が示されているため、記事のレンジをそのまま発注額とせず、同じRFPで比較してください。

ヘキサゴナル採用では、ドメイン境界、ポート、アダプター、依存性注入、テストダブル、契約テスト、CI/CD、監視を初期から設計するため、単純なCRUD開発より工数が増えることがあります。編集上の試算として、通常の業務システム費用に10〜25%程度を設計・テスト重視の上乗せとして置くと、中規模500万〜1,000万円が550万〜1,250万円程度になる計算です。ただし、この10〜25%は公的な統計や固定料金ではなく、案件の複雑度から置いた仮定です。見積書では必ず、アーキテクチャ設計、ポート・アダプター実装、テスト、移行、運用設計を別行にして根拠を確認してください。

本番稼働後は、クラウド利用料、監視、バックアップ、ログ保管、脆弱性対応、障害対応、法改正対応、追加アダプターの開発費が発生します。保守費を初期開発費の年15〜25%程度として仮置きする見積もりもありますが、これも契約内容で変わる目安です。24時間365日の監視と平日日中の問い合わせ対応では費用が異なるため、SLA、対応時間、月次の改修枠、クラウドの従量課金を分けて提示してもらいます。

委託先選定と見積比較のポイントは何ですか？

委託先は「ヘキサゴナル対応」という営業資料の言葉ではなく、設計判断を成果物とデモで確認して選びます。候補会社には同じRFPを渡し、業務理解、ポートの切り方、既存連携、移行、テスト、セキュリティ、運用、引き渡し条件を同じ順番で回答してもらいます。価格だけでなく、将来の変更にどれだけ自社で対応できるかまで含めて比較することが大切です。

公開情報でヘキサゴナルアーキテクチャの導入を具体的に確認できる事例として、FintanのNTTデータ系事例があります。Nablarchへの依存をアダプター側に閉じ込め、ビジネスロジックとDBアクセスを分離し、モック用アダプターでテストやデモを行う考え方を確認できます（出典: Fintan「ヘキサゴナルアーキテクチャ導入事例」、2026年8月確認）。このような明示的な採用事例と、クラウド移行・モダナイゼーション・データ連携の関連実績は分けて評価し、関連実績だけを「ヘキサゴナル採用済み」と断定しないことが重要です。

大規模業務や金融・基幹連携ではNTTデータ、既存業務システムの段階移行では富士通やNEC、複数システムのデータ連携ではSCSK、クラウド移行やAPI運用ではTIS、社会インフラや高可用性を含む刷新では日立製作所などが候補になります。これは順位ではなく公開情報から見た相談先の例です。各社に、担当予定者が同じ設計を自社案件で実装したか、設計書・テストコード・IaCを引き渡せるか、追加アダプターの費用を確認してください。

見積比較では、要件定義、アーキテクチャ設計、画面・API、ドメインロジック、各アダプター、データ移行、テスト、リリース、運用設計を分けます。外部連携が5本なのか20本なのか、移行データが何年分なのか、並行稼働が何か月なのかが違えば、総額を比較しても意味がありません。人月単価だけでなく、工程別の人月、担当者の役割、再利用部品、ライセンス、クラウド、旅費、予備費を同じ項目で確認してください。

提案の技術評価では、受注登録の小さなサンプルを使い、REST入力アダプター、入力ポート、ユースケース、出力ポート、RDBアダプターの依存関係を説明してもらいます。さらに、RDBをインメモリー実装に交換するデモ、外部API失敗時のリトライとログ、単体テストの実行、認証・認可の境界を確認します。図がきれいでもコードやテストが伴わない提案は、発注後に追加費用が出やすいため注意が必要です。

個人情報、決済、監査ログ、権限、秘密情報を扱う場合は、入力アダプターと出力アダプターごとの認証・認可、暗号化、ログのマスキング、権限エラーの扱いを確認します。依存ライブラリやコンテナイメージの一覧をSBOMとして管理し、脆弱性が見つかったときの通知・評価・修正・再リリースの担当を決めます。経済産業省は2025年に、ソフトウェア部品表の活用と開発者・調達者・運用者間の共有を促す国際ガイダンスに共同署名しており、SBOMをRFPと保守契約の確認項目に含める根拠になります（出典: 経済産業省、2025年9月）とされています。

よくある質問

ここでは、ヘキサゴナルアーキテクチャのシステムを発注・外注するときに、相談前によく出る疑問へ回答します。設計パターンの採用可否だけでなく、費用、契約、既存システムとの関係も判断材料にしてください。

小規模なら500万〜1,000万円程度、中規模なら1,000万〜3,000万円程度などの概算レンジがありますが、固定相場ではありません。ポート数、外部連携、移行データ、テスト、可用性、運用要件をそろえ、アーキテクチャ設計とテストの費用を別項目で見積もると比較しやすくなります。

移行できますが、全体を一度に作り直すのではなく、業務領域や機能単位で現行解析、境界設計、変換アダプター、並行稼働、データ照合を進める方法が現実的です。現行仕様が不明な場合は、いきなり本開発を契約せず、診断とPoCを準委任または小規模な請負で発注し、結果をもとに本開発の範囲を確定する方法が安全です。

技術名を先に固定するより、業務ルールをフレームワークやDBから分離し、将来の変更に対応できることを要件にするほうが重要です。既存の社内スキル、運用体制、セキュリティ、ライセンス、採用市場を踏まえて候補技術を比較し、選定理由と長期保守の担当を提案書に書いてもらいます。

担当者の実案件、設計書のサンプル、ドメイン単体テスト、ポートとアダプターの構成、外部API障害時の処理、アダプター交換のデモを確認してください。さらに、ソースコード、テスト、IaC、SBOM、監視設定、運用手順を引き渡せるか、追加改修や保守を誰がいくらで担当するかまで確認すると、発注後の認識違いを減らせます。

まとめ

ヘキサゴナルアーキテクチャのシステムを発注するときは、設計パターンの採用を目的にせず、変更したい業務ルールと交換したい外部技術を先に整理します。発注形態は、要件が固まっていれば請負、変化が大きければ準委任、複数社を使うなら責任境界を明文化するという考え方で選びます。

まず業務ルールをユースケースと不変条件に整理し、変更が多い領域、外部連携が多い領域、長期運用する領域を特定します。そのうえで、RFPにポート、アダプター、テスト、移行、運用、SBOM、ソースコードの要件を書き、請負と準委任の境界を決めます。

見積もりは総額だけでなく、設計、実装、テスト、移行、運用の内訳と前提条件をそろえて比較します。担当者の実績、アダプター交換のデモ、テストコード、障害対応、保守単価、脆弱性対応を確認し、自社が納品後に理解・変更できる委託先を選ぶことが重要です。

RFPでは、ユースケース、不変条件、入力ポート、出力ポート、アダプター、非機能要件、テスト、移行、監視、SBOM、ソースコードなどを成果物と受け入れ条件に落とし込みます。費用は一般的な業務システムの規模別レンジを出発点にし、設計・テスト・移行の上乗せを仮定として分け、同じ前提で複数社の見積もりを比較してください。図と営業文句だけでなく、コード、テスト、運用、引き渡しまで確認できる委託先を選ぶことが、長期運用できるシステムにつながります。

▼全体ガイドの記事
・ヘキサゴナルアーキテクチャのシステム開発の完全ガイド

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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