LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

BPRを伴うシステム開発委託とは

BPR（Business Process Re-engineering：ビジネスプロセスリエンジニアリング）を伴うシステム開発委託とは、業務プロセスの根本的な再設計（BPR）とそれを実現するシステムの設計・開発を、同一の委託先が一体で担う形態を指します。単にITシステムを外注するのではなく、「業務のあり方を変える」ことと「その変化をシステムで支える」ことを切り離さずに推進するアプローチです。

BPR（業務プロセスリエンジニアリング）の定義と業務改善との違い

BPRとは、業務のやり方を部分的に修正する「業務改善」とは異なり、業務プロセスの目的・手順・役割・使用するシステムをゼロベースで再設計する取り組みです。1990年代にマイケル・ハマーとジェームズ・チャンピーが提唱した概念で、コスト・品質・スピード・サービスを抜本的に向上させることを目指します。

業務改善が「現状のプロセスをより効率よく動かす」のに対し、BPRは「そのプロセス自体が本当に必要か、より良い方法がないか」を問い直す点が根本的に異なります。そのため、BPRではシステムの入れ替えだけでなく、組織体制・業務分担・承認フロー・データ管理方針まで変更の対象になることが珍しくありません。

IPA（独立行政法人情報処理推進機構）が2025年6月に公表した「DX動向2025」（日本企業1,535社・米国509社・ドイツ537社対象、2025年2〜3月調査）によれば、日本企業の業務プロセス改革について「部分最適」を志向する割合は46.0%と、米国の22.4%、ドイツの32.2%を大きく上回っています^*1。業務改革を局所的な効率化に留めている日本企業の実態が浮かびあがります。

業務再設計とシステム開発を「一体で進める」必要性

BPRを進める企業が直面しやすい課題のひとつが、「業務改革の設計」と「それを実現するシステム開発」を別々に発注することで生じる情報の断絶です。業務要件の背景にある「なぜそのプロセスに変えるのか」という意図が、コンサルタントからシステム開発会社への引き渡し時に失われると、設計通りに機能しないシステムができあがるリスクがあります。

同調査では、成果指標を「設定している」と回答した日本企業は27.4%にとどまり、米国の89.8%、ドイツの82.7%と大きな差があります^*1。業務改革の目標が明文化されないまま開発に進むことが、完成後に「業務が変わっていない」という問題につながる要因のひとつと考えられます。

分断型委託が失敗する3つのパターン

BPRとシステム開発を切り離して別々に委託する「分断型」には、実務上3つの失敗パターンが見られます。事前にこれらを理解しておくことが、委託先選定の判断軸になります。

業務知識のないベンダーへの要件定義の丸投げ — 現場との乖離が起きるケース

BPR後の業務設計書をそのまま渡してシステム開発を依頼したところ、開発側が業務の背景を理解できず、「機能は実装されているが実際の業務では使えない」システムが完成するケースがあります。

要件定義の段階で誤りが生じた場合、設計段階での修正は開発段階の2倍、テスト段階では4倍のコストがかかるとされます（IPA「情報システム・モデル取引・契約書（第二版）」2020年12月、関連解説より）^*2。業務知識を持つ担当者が要件定義に同席できる体制を、委託先に求めることが大切です。

BPR完了後にシステム化を別会社へ引き渡す — 意図の断絶が起きるケース

業務コンサルタントがBPRを完了し、成果物として業務設計書を作成した後、その文書だけを別のITベンダーへ渡してシステム化を依頼する形態です。この場合、「なぜそのプロセスに変えるのか」という背景の文脈が伝わらず、開発会社が文書に書かれた内容を表面的に解釈してしまう問題が生じやすくなります。

特に、業務設計書に記載された「例外処理のルール」や「承認の判断基準」などは、文書だけでは伝わりにくい暗黙知を含んでいます。コンサルタントが開発フェーズにも参加できる体制があるか、または同一組織でBPRと開発を担えるかを確認することが重要です。

システム先行で業務再設計が後追いになる — 逆順起動のリスク

ERPパッケージやクラウドサービスの導入が先に決まり、「そのシステムに合わせて業務を変える」という逆の順序で進むケースも少なくありません。この場合、システムの制約に業務が引きずられ、本来解決したかった課題が解消されないまま運用が始まることがあります。

BPRを本来の意味で推進するには、「業務のあるべき姿を先に設計し、それを実現するシステムを選ぶ（または作る）」という順序を守ることが原則です。既成パッケージの導入検討段階から業務再設計の視点を持つ担当者を関わらせることが、後工程での手戻りを防ぐことにつながります。

BPR一体型委託の4フェーズ

業務再設計とシステム開発を一体で進める委託では、一般的に以下の4フェーズで進行します。各フェーズで「業務側」と「技術側」の両方の視点が必要になる点が、通常のシステム開発委託との大きな違いです。

フェーズ1：業務現状分析と課題の可視化

最初のフェーズでは、現状の業務プロセスを可視化し、どこに非効率・重複・属人化・情報の断絶があるかを特定します。この段階では、現場へのインタビュー・業務フロー図の作成・ボトルネック分析が中心となります。

委託先に求めるのは、業務を理解して整理できる「業務コンサルタント」の役割です。単にヒアリングを行うだけでなく、業種特有の業務慣行や法令上の制約を理解した上で課題を構造化できる力が求められます。この段階でシステム開発担当者も同席させることで、後工程での要件定義に必要な前提知識を共有することが大切です。

フェーズ2：業務再設計（To-Be設計）と要件への落とし込み

現状分析の結果をもとに、あるべき業務プロセス（To-Be）を設計します。このフェーズが、BPRの核心となります。どのプロセスを廃止・統合・自動化・移譲するかを決定し、新しい業務フローと役割分担を確定させます。

同時に、その業務変化を実現するために必要なシステム機能を「業務要件」として整理します。業務担当者・コンサルタント・システム設計者が三者で要件を確認する場を設けることで、「業務としてやりたいこと」と「システムで実現できること」のギャップを早期に解消できます。IPA「情報システム・モデル取引・契約書（第二版）」（2020年）では、この段階のユーザー・ベンダー間の「共通理解」の醸成がシステム開発の成否を左右すると整理されています^*2。

フェーズ3：システム開発と業務変更の並走

システムの開発を進めながら、並行して現場への業務変更の周知・手順書の整備・試行テストを行います。この「開発と業務変更の並走」が一体型委託の特徴であり、開発が完了してから現場に周知する従来の方式と大きく異なる点です。

アジャイル開発（短いサイクルで機能を順次リリースし、フィードバックを取り込む開発手法）との親和性が高いフェーズです。デジタル庁が2024年に公表した「デジタル社会の実現に向けた重点計画」でも、アジャイルガバナンス原則として業務改革と技術実装の一体的な推進が示されています^*3。

フェーズ4：導入・定着支援と業務定着確認

システムリリース後も、業務が新しいプロセスに定着しているかを確認する期間が必要です。このフェーズを委託範囲に含めるかどうかで、プロジェクト全体の成否が変わります。「システムは動いているが、現場は以前のやり方に戻った」という状況は、定着支援なしの委託でよく見られます。

定着支援では、利用状況のモニタリング・操作に不慣れな担当者へのフォロー・予期しない業務パターンへの対応などが含まれます。委託先にこのフェーズまでの対応能力があるかを、事前に確認することが大切です。

委託先選定で確認すべき5つの要件

BPRを伴うシステム開発委託では、通常のシステム開発案件と異なる視点で委託先を評価する必要があります。以下の5点を軸に確認してください。

業務コンサルとシステム開発を一貫して担える体制があるか

最も基本的な確認事項です。業務設計・要件定義・開発・テスト・定着支援を同一チーム（または連携済みの組織）が担えるかを確認します。特に「業務コンサルタント」と「システムエンジニア」が別会社の場合、フェーズをまたいだ意思疎通の責任者が不在になるリスクがあります。

提案依頼の段階で「業務再設計フェーズを誰が担うか」「要件定義段階から参画するメンバーのプロフィール」を具体的に確認することで、体制の実態を見極められます。

RFP（提案依頼書）作成支援から参画できるか

RFP（Request for Proposal：提案依頼書）とは、発注者が委託先に提示する要件定義書のもとになる文書です。BPRを伴うシステム開発では、発注者側が「何を作るか」を最初から明確にできないケースが多いため、RFP作成前の業務整理から委託先に参画してもらえるかどうかが重要になります。

RFP作成段階から関与できる委託先は、業務理解力と上流工程の経験の両方を持っている証左になります。「RFPを渡してから提案を受け付ける」という通常の発注フローだけでなく、「前工程から一緒に整理する」ことができるかを確認してください。

アジャイル開発とBPRを組み合わせた経験があるか

BPR一体型委託では、業務変更とシステム開発が並走するため、要件が途中で変わること自体を前提に進める必要があります。この点でアジャイル開発（反復・漸進型の開発手法）との親和性が高く、ウォーターフォール型のみの経験しかない委託先では対応が難しいことがあります。

「業務変更に伴う仕様変更への対応方針」「スプリントレビューへの業務担当者の参加方法」などを具体的に確認することで、柔軟な開発進行への対応力を見極められます。

業種・業務領域の知見があるか

BPRは業種・業務領域ごとに再設計のアプローチが異なります。製造業の生産管理BPRと、サービス業の顧客対応フローBPRでは、可視化・再設計に必要な専門知識が大きく異なります。委託先が自社の業種に近いプロジェクトの経験を持っているかを、実績紹介や担当者の経歴から確認することが大切です。

元請（プライムベンダー）として責任を持てるか

プロジェクト全体のマネジメント責任を持つ元請（プライムベンダー）として機能できるかは、複数の協力会社を組み合わせる大型案件では特に重要です。業務コンサルと開発会社が別組織の場合、どちらがプロジェクト全体の品質・進捗・コストを管理するかが不明確になりやすいため、元請としての責任範囲を事前に確認してください。

上表は市場参考として整理したものであり、一次資料に基づく数値調査ではありません。自社の案件規模・業種・予算に応じて複数社への提案依頼（RFP）を行い、個別に比較することをお勧めします。

LASSICが対応するBPR一体型委託の形

LASSICは元請（プライムベンダー）として、要件定義から開発・保守・運用まで一貫した体制でシステム開発を受託しています。

業務再設計フェーズから参画し、業務担当者と開発チームを橋渡しする役割を担える点が、BPRを伴う委託案件との親和性が高い理由のひとつです。

IT人材の確保が難しくなっている中、外部の専門家と一体でBPRを進める選択肢は、今後さらに現実的な判断になっていきます。経産省の委託調査「IT人材需給に関する調査」（2019年3月、みずほ情報総研実施）では、2030年に高位シナリオで約79万人のIT人材不足が試算されており、業務改革とシステム整備を内製で賄うことの難しさは一層高まると見られます^*4。

まとめ：BPR一体型委託を成功させる3つの判断軸

本稿では、BPR（業務プロセスリエンジニアリング）を伴うシステム開発を外部委託する際の失敗パターン・進め方・委託先選定の要件を整理しました。要点を3点に集約すると次の通りです。

第一に、業務再設計（BPR）とシステム開発を別々に委託する「分断型」は、業務知識の断絶・意図の消失・逆順起動という3つの失敗パターンを生みやすいため、一体で担える委託先を選ぶことが出発点になります。第二に、一体型委託では現状分析・業務再設計・開発並走・定着支援の4フェーズを通じて業務側と技術側が密連携する体制が不可欠であり、この体制を持つ委託先かどうかが選定の核心です。第三に、委託先評価では「業務コンサルと開発の一貫性」「RFP前からの参画」「元請（プライムベンダー）としての責任体制」の3軸を確認することで、発注後の手戻りリスクを低減できます。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：IPA（独立行政法人情報処理推進機構）「DX動向2025」（2025年6月公表）。日本企業1,535社・米国509社・ドイツ537社対象（2025年2〜3月調査）
2. *2　出典：IPA（独立行政法人情報処理推進機構）「情報システム・モデル取引・契約書（第二版）」（2020年12月）
3. *3　出典：デジタル庁「デジタル社会の実現に向けた重点計画」（2024年6月21日閣議決定）
4. *4　出典：経済産業省委託「IT人材需給に関する調査」（2019年3月、みずほ情報総研実施）。高位シナリオにおける試算値。出典URL：meti.go.jp/policy/it_policy/jinzai/houkokusyo.pdf

Tweet