クリーンアーキテクチャのシステム開発の発注/外注/依頼/委託方法について

クリーンアーキテクチャのシステムを発注・外注するときは、設計手法の名称だけで会社を選ばず、業務ルール、変更頻度、テスト、運用までをRFPと契約に落とし込むことが重要です。

「クリーンアーキテクチャに対応できます」と提案されたものの、何を依頼書に書けばよいのか、通常のスクラッチ開発と比べて費用がどれくらい増えるのか、見積書のどこを比較すべきか分からない方も多いのではないでしょうか。この記事では、発注形態の選び方からRFP・要件整理、契約形態、費用相場、委託先の見極め、見積比較までを、発注者の実務に沿って解説します。

▼全体ガイドの記事
・クリーンアーキテクチャのシステム開発の完全ガイド

クリーンアーキテクチャのシステムを発注する前に知るべき全体像

クリーンアーキテクチャは、特定の製品やクラウドサービスの名前ではなく、業務上の重要なルールを画面、データベース、クラウド、外部APIなどの技術詳細から分離する設計方針です。発注時には「クリーンアーキテクチャで作る」とだけ伝えるのではなく、どの業務を守り、どの変更に強くしたいのかを明確にする必要があります。

中心に置くのは、受注を確定する、与信を判定する、承認を完了する、といったユースケースとドメインのルールです。画面からデータベースを直接呼び出すのではなく、アプリケーションのユースケースを介して処理し、外部システムとの接続はポートとアダプターに閉じ込めます。そのため、たとえばデータベースを変更したり、REST APIを別の連携方式に置き換えたりしても、業務ルールへの影響を限定しやすくなります。

ただし、クリーンアーキテクチャを採用すれば、自動的に低コスト、高性能、マイクロサービスになるわけではありません。単純なCRUDだけで変更も少ない小規模システムでは、層やインターフェース、テストコードが増えることで初期工数が過剰になる場合があります。受発注、在庫、請求、権限、外部連携のように業務ルールが複雑で、長期運用や仕様変更が想定される案件ほど、採用理由を説明しやすくなります。

向いているのは、部門をまたぐ業務システム、将来の制度変更が多い基幹システム、複数のSaaSや会計・決済・物流サービスと連携するシステム、既存システムを段階的に刷新したい案件です。業務ルールをコードの中心に置くことで、機能追加の影響調査や回帰テストを行いやすくする狙いがあります。

一方、数画面の社内申請フォームや短期間だけ使うキャンペーンサイトでは、すべての層を厳密に分ける必要はありません。発注書には「全機能を同じ厳密さで設計する」と固定せず、重要な業務ルールにはドメイン層と自動テストを適用し、単純な参照画面は実装を簡素化する、といった適用範囲を書き分けると、品質と予算のバランスを取りやすくなります。

発注形態はスクラッチ・パッケージ・SaaSのどれを選ぶべきですか？

結論として、業務の独自性と変更頻度が高いならスクラッチ開発、標準化できる部分が多いならSaaSやパッケージを優先します。クリーンアーキテクチャはスクラッチ開発だけのものではなく、パッケージやSaaSの外側に独自の業務連携・拡張部分を作る場合にも活用できます。先に設計手法を決めるのではなく、業務のどこを標準機能に合わせ、どこを自社固有の資産として作るかを決めることが出発点です。

スクラッチ開発は、業務ルールが自社の競争力に直結し、既存製品では承認・料金計算・在庫引当などを表現できない場合に適しています。開発会社には、ドメインモデル、ユースケース、外部連携、データ移行、監査ログまで含めて設計してもらいます。反対に、勤怠や経費、一般的なワークフローのように業務を標準化できる場合は、SaaSを導入し、差別化が必要な部分だけAPI連携やアドオンで補う方が、導入期間と保守負担を抑えやすいです。

パッケージは、標準機能を使いつつ自社向けの設定や追加開発を行いたい場合の中間案です。ただし、SaaS本体の内部構造を自由にクリーンアーキテクチャへ変更できるとは限りません。RFPでは「製品内部を変更できるか」ではなく、「自社の拡張サービスをどの境界に置くか」「API停止時にどう復旧するか」「製品変更時に何をテストするか」を確認すると、期待違いを防げます。

クリーンアーキテクチャとマイクロサービスは別の概念です。新規発注では、まず一つのデプロイ単位に複数の業務モジュールを分けるモジュラーモノリスから始め、負荷、組織体制、障害分離の必要性が明確になった領域だけを分離する方が、運用を複雑にしにくいです。サービスを増やすと、ネットワーク、認証、監視、データ整合性、リリース管理の費用も増えるためです。

既存システムを刷新する場合は、すべてを一度に作り直すのではなく、Strangler Figと呼ばれる段階的置換の考え方をRFPに盛り込みます。たとえば受注照会を新システムへ移し、旧システムとデータ連携しながら、次に在庫引当、請求へ進みます。並行稼働、移行リハーサル、切り戻し条件を先に決めておけば、全面刷新による業務停止のリスクを下げられます。

段階的な刷新の実例として、IBMが公開するAPIS ITの事例では、10年前のSOAPサービスを.NET 8のREST APIへリファクタリングし、クリーンアーキテクチャ化したと説明されています。IBM公式の事例紹介では、コードと依存関係が30%少なくなり、レイヤーが50%簡素化されたとされていますが、これは特定案件の導入結果であり、すべての発注案件に同じ効果が出るという意味ではありません。提案を比較するときは、このような成果指標を自社の変更時間や障害対応時間に置き換えて確認します。

RFPと要件整理では何を開発会社へ伝えますか？

RFPは、会社に丸投げするための書類ではなく、提案条件をそろえて比較するための共通資料です。IPAの「ストーリーで学ぶ要件定義実践入門」では、RFPに背景や目的、求めるシステム、提案・契約の手続きなどを記載し、業務フロー、要件一覧、課題一覧、現行システム構成図などを補足する考え方が示されています。クリーンアーキテクチャを指定する場合も、設計用語だけではなく、業務と受入基準を中心に書きます。

最初に、現状の課題と事業目的を記載します。「受注処理を速くする」だけでなく、入力から出荷指示までのリードタイムを何日から何日にするのか、手作業をどの程度減らすのか、誰が効果を測るのかまで整理します。続いて対象部門、利用者数、権限ロール、業務フロー、例外処理、マスタ、データ量、保存期間、既存システムとの連携を記載します。

非機能要件も後回しにしません。稼働時間、目標応答時間、同時利用者数、バックアップと復旧目標、監視、障害通知、個人情報、アクセス制御、脆弱性診断、ログ保存期間を明記します。成果物には要件定義書、ドメインモデル、画面・API仕様、テスト仕様と結果、ソースコード、CI/CD設定、IaC、運用手順、教育資料を含めるかを指定します。納品物の一覧が曖昧な「開発一式」は、後から追加費用や引き継ぎ問題につながりやすいです。

業務担当者と開発会社が同じ理解に立つには、代表的なユースケースを縦に一周させることが有効です。受注確定を例にするなら、入力値の検証、在庫や与信の判定、承認権限、外部APIの失敗、二重登録、監査ログ、通知までを一つの流れとして記述します。そのうえで、正常系だけでなく、権限がない場合、外部サービスがタイムアウトした場合、同じ依頼を再送した場合の結果を受入基準にします。

設計方針の受入基準には、ドメイン層がWebフレームワークやデータベースへ直接依存しないこと、外部接続をインターフェースの外側へ置くこと、ユースケース単位でテストを実行できること、依存方向をレビューで確認することなどを含めます。コードカバレッジの数値だけを合格条件にすると、意味のないテストが増えることがあります。重要な業務ルールがどのテストで守られているかを、テストケースと業務シナリオで説明できる状態を目指します。

クリーンアーキテクチャのシステム開発を外注する進め方

発注後は、企画・要件定義、設計・開発、テスト・移行・リリースを一続きの計画にします。クリーンアーキテクチャでは、業務用語や境界を早い段階でそろえないと、後工程で層だけが増えて業務ルールが曖昧になります。発注者側の業務責任者を決め、毎週のレビューで仕様、優先順位、未決事項、変更の影響を確認する体制が必要です。

要件定義では、画面一覧を先に増やすのではなく、業務イベントと業務ルールを整理します。たとえば「注文」と「受注」を同じ意味で使うのか、受注確定後に価格変更できるのか、返品時に在庫と請求をどう戻すのかを、現場の言葉で決めます。顧客、商品、取引、請求のような概念を境界づけられたコンテキストとして整理すると、どの機能を一つのモジュールで管理するか判断しやすくなります。

この段階で、将来変更されそうなルールと、ほとんど変わらない処理を分けます。税率や承認経路、料金計算のような変更頻度が高いルールはユースケースやドメインに寄せ、メール送信やDBアクセスは外側のアダプターに置く設計を提案してもらいます。すべてを抽象化するのではなく、変更理由が異なるものを分離する、という観点でレビューします。

提案書だけでは、開発会社がクリーンアーキテクチャを実践できるか分かりません。契約前または要件定義の初期に、最重要の受注・承認・在庫引当などを一つ選び、画面、API、業務ルール、DB、外部連携、監査ログ、ユニットテストまでを縦切りで動かすPoCや小さなMVPを依頼します。ここで、業務担当者が理解できるデモになっているか、外部APIの障害や権限エラーをテストできるかを確認します。

PoCは本番システム全体を作るものではありません。目的、対象範囲、期間、成果物、製品版へ再利用できるコードの範囲を合意してください。PoCのコードを捨てる前提なのか、品質を上げて本開発へ引き継ぐのかで、必要なテストや文書化の費用が変わります。特に生成AIや自動化ツールを使う提案では、人によるレビュー、機密情報の入力制限、生成物の著作権・脆弱性確認も評価項目にします。

テストは、ドメインの単体テスト、ユースケースのアプリケーションテスト、DBや外部APIを含む統合テスト、画面のE2Eテストを分けます。発注者は「テストを実施する」とだけ書かず、誰がどの環境で何を確認し、結果をどの形式で提出するかをRFPと契約書に定義します。性能、セキュリティ、障害復旧、データ移行、権限のテストは、納品直前に初めて行うと修正余地が少なくなるため、計画時点から見積もりへ入れます。

リリース前には、移行リハーサル、並行稼働、利用部門の教育、問い合わせ窓口、切り戻し手順を確認します。リリース後は、エラー率、処理時間、利用率、手作業の削減量などのKPIを設定し、保守契約の定例会で振り返ります。クリーンアーキテクチャの価値は納品時の見た目ではなく、数年後の変更や障害対応で現れるため、運用設計と引き継ぎを開発の外に置かないことが大切です。

契約形態は請負と準委任のどちらが適していますか？

要件が固まり成果物と完成条件を定義しやすい工程は請負、業務理解や設計を一緒に深める工程は準委任が基本的な選択肢です。実際には、要件定義を準委任で行い、設計・開発の一部を請負、リリース後を保守の準委任にするなど、工程ごとに使い分けます。IPAの「ユーザのための要件定義ガイド」でも、要件定義はユーザー企業が主体となり、準委任契約を基本形とする考え方が示されています。

請負契約では、納品対象、検収条件、瑕疵や契約不適合への対応、納期、変更管理を具体化します。「クリーンアーキテクチャ準拠」という抽象的な表現だけでは検収できないため、依存方向の設計ルール、代表ユースケースのテスト、成果物一覧、性能・セキュリティの合格基準へ分解します。要件が未確定のまま固定価格の請負にすると、変更のたびに追加費用や納期延長が起きやすいです。

準委任契約では、稼働時間だけでなく、担当する役割と会議体、レビュー成果、設計・テストの記録、進捗報告を定義します。発注者側が意思決定を遅らせると、受託会社の作業時間だけが増えることがあります。プロダクトオーナー、業務責任者、技術責任者を発注者側に置き、未決事項の期限と決裁者を明らかにしてください。

契約時には、ソースコードだけでなく、設計書、API仕様、テストコード、CI/CD設定、Infrastructure as Code、監視設定、バックアップ手順、データ出力方法まで引き渡し対象に含めるか確認します。著作権の帰属、第三者ライブラリのライセンス、再利用部品の扱い、著作権法第27条・第28条の権利、秘密情報の管理も、法務担当と整理します。納品後に別会社へ保守を移せるかどうかは、発注前に聞くべき重要な質問です。

障害時の一次対応、脆弱性の修正期限、クラウド費用、監視費、バックアップ、SLA、追加開発の単価、再委託先、契約終了時の移行支援も分けて記載します。特にクラウドでは、基盤を提供会社が管理していても、認証・認可、アプリケーション、ログ、監視、第三者ライブラリの更新は開発側や利用企業の責任として残る場合があります。OWASPの「Secure Cloud Architecture」でも、共有責任を踏まえた認証、ログ・監視、コードセキュリティ、ライブラリ更新の確認が示されています。

クリーンアーキテクチャのシステム発注費用相場

クリーンアーキテクチャ単体の公的な価格表はありません。費用は、機能数、業務の複雑さ、外部連携、データ移行、利用者数、非機能要件、開発チームの体制、納期で変わります。SIA株式会社の2026年7月更新記事（出典: SIA株式会社「システム開発の費用・相場【2026年版】」）では、一般的なシステム開発の目安を小規模100万〜300万円、中規模500万〜1,000万円、大規模1,000万円〜数千万円以上、人月単価60万〜200万円程度としています。

上記の一般相場に、ドメイン設計、依存ルール、テスト自動化、CI/CD、監視、設計文書の工数を含めて考えると、発注予算の初期検討では次のレンジが目安になります。小規模で単一業務を扱う社内システムは350万〜850万円、部門横断で複数ロールや外部APIを扱う中規模システムは800万〜1,800万円、基幹連携や大量データ、段階移行を含む大規模システムは2,000万〜1億円以上です。期間は順に3〜5か月、5〜9か月、8〜18か月以上を想定します。

この金額と期間は、クリーンアーキテクチャ分だけを切り出した市場統計ではありません。一般的なシステム開発相場と業務システムの規模別データをもとに、ドメイン設計・テスト・運用設計を削らない場合の発注検討用に推定したレンジです。単純なCRUDだけの案件と同じ金額を期待せず、要件定義や設計が深くなる分、初期工数がおおむね10〜25%増える可能性を仮置きして、提案会社に内訳を確認してください。

「開発一式」ではなく、要件定義、ドメインモデリング、アーキテクチャ設計、画面・API設計、実装、単体テスト、結合・E2Eテスト、性能・セキュリティテスト、データ移行、教育、リリース、保守に分けた見積を依頼します。リサーチノート内の業務システムQ&A整理（出典: 同ノートのローカル一次Q&A）では、開発費の大部分は人件費で構成され、工程別にも要件定義、設計・環境構築、実装、テストで比率が異なるとされています。会社や案件により計上方法は変わります。

保守運用は初期開発費の年15〜25%程度という目安が紹介されることがありますが、月額の監視、クラウド利用料、脆弱性対応、法改正対応、問い合わせ、追加開発、SLAを含むかで数字は変わります。したがって「保守は開発費の何％」だけで決めず、5年間の総保有コストを比較します。初期費用が安くても、変更のたびに影響調査と手作業テストが必要なら、長期的な費用や納期が膨らむ可能性があります。

委託先選定と見積比較で確認すべきポイント

委託先は「クリーンアーキテクチャ」という言葉の使用実績だけで決めません。業務理解、ドメインモデリング、テスト自動化、クラウド運用、既存システム移行、セキュリティ、契約終了時の引き継ぎを一緒に評価します。提案時には、実際の担当アーキテクトが誰か、要件定義から保守まで同じチームが関わるか、再委託の範囲、ソースコードとIaCの引き渡し条件を確認します。

面談では、「どのフレームワークを使いますか」よりも、「受注確定の業務ルールをどの層に置きますか」「DBを変更するとき、どのテストを再実行しますか」「外部APIがタイムアウトしたとき、利用者へ何を表示しますか」と聞きます。回答が技術用語だけで終わらず、業務ルール、依存方向、リトライ、冪等性、ログ、監査証跡まで説明できるかを見ます。

可能なら、匿名化された設計書、テスト計画、コードの一部、障害対応の振り返りを見せてもらいます。秘密保持のため実物が難しい場合は、仮想の受注シナリオを使った設計レビューを行います。提案デモでは、権限のない操作、同一注文の二重送信、連携先の障害、データ移行後の照合を試し、正常系だけを見て評価しないことが大切です。

複数社の見積を比較する際は、同じRFP、同じユースケース、同じ利用者数、同じデータ量、同じ納期条件を渡します。そのうえで、要件定義の時間、アーキテクトの関与、レビュー回数、テスト環境、移行リハーサル、監視、教育、保証、保守の範囲を横並びにします。安い見積にドメイン設計やテストが含まれていなければ、価格差ではなく作業範囲の差です。

比較表には、初期費用、追加変更の単価、クラウドやライセンスの実費、保守費、障害時の対応時間、SLA、納品物、再委託費、契約終了時の移行費を記載します。見積の前提に「業務ルールは発注者が提示」「外部API仕様は確定済み」「データ品質は保証しない」などの条件があれば、発注者側の作業とリスクとして別に整理します。数字の根拠を質問できる会社ほど、契約後の変更管理も透明になりやすいです。

よくある質問

ここでは、クリーンアーキテクチャのシステムを発注・外注するときに、特に相談の多い疑問へ回答します。費用や技術だけでなく、適用範囲と契約条件まで確認してください。

初期費用は、単純なCRUD開発より高くなる可能性があります。ドメイン設計、依存関係の整理、テスト自動化、文書化に工数がかかるため、発注検討では10〜25%程度の上振れを仮置きし、提案会社の内訳で検証してください。ただし、この比率は市場統計ではなく案件条件からの推定です。変更頻度が高いシステムでは、長期の影響調査や回帰テストの負担を下げられる可能性があるため、5年TCOで判断します。

すべての小規模システムに必要なわけではありません。将来の変更が少なく、業務ルールも単純なら、適用範囲を限定したシンプルな構成が適しています。一方、利用者は少なくても、料金計算、承認、在庫、権限、法改正、外部連携が複雑なら、重要なユースケースだけにドメイン層と自動テストを適用する価値があります。

用語の使用実績だけでなく、業務理解、代表ユースケースの設計、テストコード、障害対応、設計レビュー、運用引き継ぎを確認します。担当アーキテクトが提案から本番まで関わるか、依存方向やテストの合格条件を説明できるか、ソースコード・IaC・設計書を引き渡せるかを質問してください。可能であれば、匿名化された実績や仮想シナリオの設計レビューを見て判断します。

まとめ

クリーンアーキテクチャのシステムを発注・外注するときは、設計手法の指定を目的にせず、業務ルールを守り、将来の変更と運用を安全にするための条件として扱います。まず、独自業務と標準化できる業務を分け、スクラッチ、パッケージ、SaaS、段階移行の選択肢を比較します。

RFPでは、業務の目的、代表ユースケース、非機能要件、成果物、移行条件、セキュリティ、保守範囲を具体化します。設計手法の名称だけでは見積も検収もできないため、依存方向、テスト、障害対応、引き継ぎを受入基準に落とし込みます。

見積書は、要件定義、設計、実装、テスト、移行、教育、保守を分け、前提条件と除外項目まで比較します。初期費用だけでなく、変更、障害、クラウド、脆弱性対応、契約終了時の移行まで含めた5年TCOで、委託先の提案を判断します。

次に、RFPへ目的、業務フロー、ユースケース、非機能要件、成果物、受入基準、データ移行、セキュリティ、運用体制を書きます。契約は工程ごとに請負と準委任を使い分け、見積は開発一式ではなく、要件定義、ドメイン設計、実装、テスト、移行、保守を分けて比較します。価格だけでなく、5年TCO、変更リードタイム、障害復旧、契約終了時の引き継ぎまで確認することが、発注後の後悔を減らします。

▼全体ガイドの記事
・クリーンアーキテクチャのシステム開発の完全ガイド

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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