事業部門から新しい業務システムの要望が上がり、情報システム部門が取りまとめ役に指名されたものの、予算の確保、稟議、ベンダーへの提案依頼、契約の判断まで何をどの順番で進めればよいか見えない。大企業のシステム開発の発注では、こうした状況が珍しくありません。

関係部門が多く、既存の基幹システムとの連携やセキュリティ審査も絡むため、発注の進め方そのものがプロジェクトの成否を左右します。この記事では、大企業がシステム開発を発注する際の社内プロセスを、予算化から発注後のガバナンスまで順を追って解説します。

この記事を読むと理解できること

• 大企業のシステム開発の発注が難しくなる構造的な理由

• 構想策定から発注後の運用までのプロセス全体像

• 予算化と稟議で経営層に示すべき論点

• RFIとRFPの役割と、要件が固まらない場合の進め方

• 発注先を公平に評価するための評価項目と手順

• 請負契約・準委任契約・多段階契約の使い分け

• 発注後に発注側が担うべき体制と変更管理のルール

システム開発の発注が大企業で難しくなる理由

中小規模の案件であれば、担当者が開発会社に相談し、見積もりを比較して決めるという流れでも進められます。しかし大企業のシステム開発の発注では、同じやり方では立ち行かない場面が多くあります。まずは、その背景となる構造を整理します。

関係部門が多く意思決定が分散する

大企業では、システムを使う事業部門、技術面と全社標準を管理する情報システム部門、投資判断を行う経営層、契約を管理する購買部門や法務部門など、発注に関わる部門が多岐にわたります。それぞれが異なる評価軸を持っているため、誰が何を決めるのかを最初に定めないと、議論が堂々巡りになりがちです。

特に、事業部門は業務の使いやすさを重視し、情報システム部門は保守性や既存環境との整合を重視するという構図はよく見られます。どちらも正しい観点であり、発注前の段階で両者の優先順位をすり合わせておくことが欠かせません。

既存システムとの連携とセキュリティ審査が前提になる

新しいシステムは単独で動くことは少なく、会計・人事・販売管理などの基幹システムや、全社の認証基盤、データ基盤と連携するのが一般的です。連携先の仕様やデータ移行の範囲を把握しないまま発注すると、開発が始まってから想定外の工数が発生します。

また、大企業では社内のセキュリティ基準に基づく審査や、委託先の情報管理体制の確認が求められます。これらの審査には一定の期間がかかるため、スケジュールに最初から組み込んでおく必要があります。基幹システムとの関係は業務システムと基幹システムの違いでも整理しています。

発注の失敗が全社に波及する

全社展開を前提とするシステムでは、利用者が数千人規模になることもあります。要件の取り違えや、現場に使われない画面設計は、そのまま業務の停滞や追加投資につながります。

さらに、特定ベンダーの独自技術や独自仕様に依存した状態で発注を重ねると、将来の改修や刷新の自由度が失われます。システム開発の発注は一度きりの調達ではなく、数年から十年単位でIT資産の形を決める判断だと捉えることが重要です。

システム開発の発注プロセスの全体像

大企業におけるシステム開発の発注は、大きく次の7つのフェーズで進みます。フェーズごとに主担当と成果物を明確にしておくと、社内の役割分担が整理しやすくなります。

この表のうち、発注前の4フェーズにどれだけ時間をかけられるかで、後工程の手戻りの量が大きく変わります。開発会社に依頼する一般的な流れや外注の判断基準はシステム開発の外注で解説しているため、ここでは大企業の発注側が社内で進めるべきプロセスに絞って説明します。

システム開発の発注前に行う構想策定と予算化

発注の出発点は、ベンダー探しではなく社内での構想策定です。何のためにシステムを作り、何が実現できれば成功なのかを言語化しない限り、適切な予算も提案依頼も作れません。

目的とKPIを経営課題に結びつける

構想策定では、まず現状の業務と課題を整理し、システム導入後のあるべき姿を描きます。いわゆるAs-IsとTo-Beの整理です。

そのうえで、処理時間の短縮、入力ミスの削減、意思決定の迅速化など、効果を測る指標を設定します。指標は経営計画や中期のDX方針と結びつけておくと、稟議の段階で投資の妥当性を説明しやすくなります。

予算は段階に分けて確保する

構想段階では要件が固まっていないため、開発全体の金額を正確に見積もることはできません。にもかかわらず、最初の稟議で総額を確定させようとすると、ベンダーは不確実性をリスク分として上乗せするか、範囲を狭く見積もるかのどちらかになりがちです。

そこで有効なのが、要件定義までと設計・開発以降で予算を分ける考え方です。まず要件定義の予算を確保し、その成果物をもとに開発予算を精緻化して再度決裁を得る流れにすれば、根拠のある金額で全体を判断できます。要件定義そのものの費用感は要件定義の費用も参考にしてください。

稟議書で示すべき論点

システム開発の発注に関する稟議書では、金額だけでなく判断の根拠を示すことが求められます。経営層や決裁者が確認したいのは、おおむね次のような論点です。

• 解決する経営課題と、実施しない場合のリスク

• 期待効果と、その測定方法

• 投資額の内訳と、段階的に決裁する場合の区切り

• 既存システムとの関係と、全社標準との整合

• 発注先の選定方法と、評価の公平性の担保

• 主なリスクと、その対応策

特に、選定方法の公平性は監査や内部統制の観点からも確認されやすい項目です。後から説明できるよう、評価のプロセスを発注前に設計しておくことが大切です。

システム開発の発注で使うRFIとRFP

予算の見通しが立ったら、ベンダーへの情報提供依頼と提案依頼に進みます。大企業の発注では、いきなり提案を依頼するのではなく、RFIで市場を把握してからRFPを出す二段階の進め方が一般的です。

RFIで市場と選択肢を把握する

RFI(情報提供依頼書)は、ベンダーの得意領域、類似案件の経験、採用できる技術やパッケージ、概算の費用感などを幅広く集めるための文書です。この段階では候補を絞り込みすぎず、スクラッチ開発、パッケージ、SaaSの組み合わせなど、複数の実現方式を比較できるようにしておきます。

RFIの回答を通じて、自社が想定していなかった選択肢や、要件の見直しにつながる示唆が得られることもあります。RFIとRFPの役割の違いはRFIとRFPの違いで詳しく解説しています。

RFPで提案条件をそろえる

RFP(提案依頼書)は、目的、対象業務、機能要件と非機能要件、連携先、スケジュール、予算の考え方、提案に求める内容と評価方法を示す文書です。すべての候補に同じ条件を渡すことで、提案内容を同じ土俵で比較できるようになります。

RFPで曖昧にされがちなのが、データ移行、受入テストの支援、運用保守、教育といった周辺作業の範囲です。これらが見積もりに含まれるかどうかで金額は大きく変わるため、範囲と前提を明記しておきます。具体的な書き方はRFPの書き方を参照してください。

要件が固まらない場合はプロトタイプで具体化する

新規業務のシステムやDX案件では、RFPを書こうとしても、現場が求める画面や操作の流れが言葉では定まらないことがあります。文章だけで要件を固めようとすると、関係部門ごとに解釈が分かれ、合意形成に時間がかかります。

このような場合は、画面のプロトタイプを作り、現場にヒアリングしながら要件を具体化する方法が有効です。実際の画面を見ながら議論すると、抽象的な要望が具体的な仕様に変わり、事業部門と情報システム部門の認識もそろいやすくなります。プロトタイプで固めた要件をRFPに反映すれば、提案の精度も高まります。

システム開発の発注先を選ぶ評価プロセス

提案を受け取ったら、事前に決めた基準で評価し、発注先を決定します。大企業では、評価の過程そのものが説明責任の対象になるため、手順を明確にしておくことが重要です。

評価項目と配点を事前に決める

評価項目と配点は、RFPを出す前に決めておきます。提案を見てから基準を決めると、特定のベンダーに寄せた評価だと受け取られるおそれがあるためです。

評価には事業部門、情報システム部門、購買部門などから複数の評価者を立て、個別に採点したうえで結果を突き合わせると、偏りを抑えられます。

提案の比較で見るべきポイント

提案の比較では、金額の大小だけで判断しないことが基本です。範囲を狭く見積もった提案は安く見えますが、後から追加費用が発生しやすくなります。

また、特定のパッケージや独自基盤を前提とした提案の場合、将来の改修や他社への切り替えが難しくなる可能性があります。保守の契約条件、ソースコードやドキュメントの扱い、データの取り出しやすさも確認しておくと、ベンダーロックインのリスクを判断しやすくなります。

最終選考で体制と担当者を確認する

書面審査で候補を2〜3社に絞ったら、プレゼンテーションや質疑の場を設けます。ここでは、実際にプロジェクトを担当するプロジェクトマネージャーや主要メンバーに参加してもらうことが大切です。

提案時の担当者と実際の担当者が異なると、提案内容の理解度に差が生じることがあります。再委託の有無と範囲、主要メンバーが交代する場合の取り扱いも、最終選考の段階で確認しておきます。発注先の候補をどう探し、どう比べるかは開発会社の選び方で詳しく紹介しています。

システム開発の発注で選ぶ契約形態

発注先が決まったら、契約形態と契約条件を確定させます。契約形態によって発注側と受注側の責任範囲が変わるため、工程の性質に合わせて選ぶ必要があります。

請負契約と準委任契約の使い分け

請負契約は、成果物の完成を約束する契約です。仕様が明確に定まっている工程に向いており、受注側は完成責任を負います。

準委任契約は、専門的な業務の遂行を約束する契約で、完成責任は負わず、善良な管理者の注意をもって業務を行う義務を負います。要件定義のように成果の形が事前に定まりにくい工程や、アジャイル型で仕様を固めながら進める開発に適しています。両者の違いは準委任と請負の違いで詳しく解説しています。

多段階契約で工程ごとに判断する

大企業のシステム開発では、要件定義、設計・開発、テスト・移行といった工程ごとに契約を分ける多段階契約がよく用いられます。経済産業省が公表している情報システム・モデル取引・契約書でも、工程ごとに契約形態を選ぶ考え方が示されています。

多段階契約にすると、前の工程の成果物を確認してから次の工程の金額と範囲を確定できます。前述した予算の段階的な確保とも相性がよく、稟議の区切りと契約の区切りをそろえておくと、社内の判断がスムーズになります。

契約書で取り決めておく事項

契約書では、次の事項を明確にしておくことが重要です。

• 業務範囲と成果物、範囲外とする作業

• 検収の方法、基準、期間

• 仕様変更の手続きと、費用・納期への影響の扱い

• 知的財産権の帰属と、ソースコードの利用範囲

• 再委託の可否と条件、情報管理の取り決め

• 契約不適合責任の範囲と期間

• 契約終了時の引き継ぎとドキュメントの提供

2020年施行の改正民法により、従来の瑕疵担保責任は契約不適合責任に整理されました。どの範囲までを責任の対象とするかは契約で調整できるため、法務部門と連携して条項を確認しておきます。

システム開発の発注後に必要な体制とガバナンス

契約を結んだ時点で、発注側の役割が終わるわけではありません。むしろ発注後こそ、発注側の体制とルールがプロジェクトの品質を左右します。

発注側のプロジェクト体制を組む

発注側では、最終的な意思決定を担うプロジェクトオーナー、日々の推進を担うプロジェクトマネージャー、業務要件を判断する事業部門の代表者、技術とセキュリティを確認する情報システム部門の担当者を置くのが基本です。規模が大きい場合は、PMOを設けて進捗、課題、リスクを横断的に管理します。

ベンダーとの窓口は一本化しておくことが重要です。複数の部門が個別に要望を伝えると、優先順位が曖昧になり、仕様の矛盾や追加費用の原因になります。

定例と変更管理のルール

発注後は、週次や隔週の定例会で進捗と課題を共有し、月次などの節目で経営層や運営委員会に報告する会議体を設計します。会議体ごとに、何を決める場なのかを明確にしておくと、意思決定が滞りにくくなります。

仕様変更は必ず発生するものとして、変更の申請、影響評価、承認のルールをあらかじめ決めておきます。変更管理台帳で経緯を記録しておけば、費用や納期の調整を根拠をもって行えます。

受入テストと検収の進め方

受入テストは、発注側が主体となって行う工程です。通常の業務だけでなく、月末や期末の繁忙処理、例外的な処理、連携先が停止した場合の動きなど、実際の業務に即したシナリオを用意します。

検収の基準は、要件定義の段階で合意しておくのが理想です。何をもって合格とするかが曖昧なままだと、検収の段階で認識の差が表面化し、トラブルにつながります。

運用保守と内製化を見据える

リリース後は、障害対応、問い合わせ窓口、改善要望の受付と優先順位づけの体制が必要です。保守契約の範囲と、追加開発の進め方を事前に決めておくと、運用開始後の混乱を防げます。

また、すべてを外部に依存し続けるのではなく、要件判断や軽微な改修を社内で担えるようにする選択肢もあります。中長期的な体制づくりについてはシステム内製化の記事も参考にしてください。

システム開発の発注でよくある失敗と回避策

最後に、大企業のシステム開発の発注で起こりやすい失敗と、その回避策を整理します。

これらの失敗の多くは、発注前の準備不足と、発注後の関与不足に起因します。システム開発全般の失敗パターンはシステム開発の失敗でも詳しく取り上げています。

株式会社FAKEでは、大企業DXの上流工程に入り、プロトタイプとヒアリングを反復して要件定義書の作成までを一つの流れで進めるFDE支援を提供しています。パッケージ前提ではない提案と、現場に使われるUXを起点にした業務の再設計で、発注前の合意形成を支援しています。

まとめ

大企業のシステム開発の発注は、開発会社を選ぶ作業ではなく、構想策定から運用保守までを含む社内プロセス全体の設計です。関係部門が多く、既存システムとの連携やセキュリティ審査も伴うため、各フェーズの主担当と成果物を明確にすることが出発点になります。

予算は要件定義と開発で段階的に確保し、RFIで選択肢を把握してからRFPで条件をそろえることで、根拠のある比較と判断ができます。評価項目と配点は事前に定め、契約形態は工程の性質に応じて請負と準委任を使い分けます。

発注後も、発注側の体制、変更管理、受入テストを主体的に運営することが成功の条件です。今回整理したプロセスを、自社の発注の進め方を見直す際のチェックリストとして活用してください。

システム開発の発注に関するよくある質問

要件定義書がない段階でもシステム開発の発注を相談できますか

相談は可能です。むしろ大企業の案件では、要件定義そのものを外部の専門家と一緒に進めるケースが多くあります。その場合は、要件定義までを準委任契約で発注し、成果物をもとに開発の範囲と予算を確定させる進め方が適しています。

RFIは必ず実施する必要がありますか

必須ではありませんが、実現方式の選択肢が複数考えられる案件や、市場の相場感がつかめていない案件では実施する価値があります。RFIで得た情報をもとにRFPの要件や予算を調整できるため、提案の質が高まり、発注後の手戻りも減らせます。

発注先の候補は何社程度に絞るべきですか

RFIの段階では幅広く情報を集め、RFPは3〜5社程度に送付し、最終選考では2〜3社に絞るのが一般的な目安です。候補が多すぎると評価の負担が大きくなり、少なすぎると比較の根拠が弱くなります。案件の規模と社内の評価体制に合わせて調整してください。

発注後に仕様変更が必要になった場合はどうすればよいですか

まず契約で定めた変更管理の手続きに沿って、変更内容を申請し、費用と納期への影響をベンダーに評価してもらいます。そのうえで、発注側の決定者が承認するかどうかを判断します。影響が大きい変更は、次のフェーズに回す、優先度の低い機能と入れ替えるといった調整も検討します。

複数のベンダーに分割して発注するのはよい方法ですか

領域ごとに得意なベンダーへ分割して発注すると、専門性を活かせる一方で、ベンダー間の調整や全体の品質管理を発注側が担う必要があります。分割する場合は、発注側にPMOを置き、インターフェースの仕様と責任分界点を明確にしておくことが前提になります。