印刷業界のシステムのRFP/要件定義書/提案依頼書について

印刷業界のシステム開発を外部に発注するとき、成否の8割を決めると言っても過言ではないのが、RFP（提案依頼書）と要件定義の作り込みです。印刷業は、見積・受注・面付け・刷版・印刷・製本・在庫・請求が密接に絡み合い、案件ごとに仕様が異なる複雑な業務を抱えています。この複雑さを曖昧なまま発注すると、ベンダーは現場に合わないシステムを作り、リリース後に「これでは使えない」という手戻りが発生します。逆に、要件を丁寧に定義したRFPを用意できれば、見積の精度も提案の質も上がり、開発が始まってからのトラブルを大幅に減らせます。

本記事は、印刷業界のシステムのRFP・要件定義書・提案依頼書の作り方を、発注企業（印刷会社）の視点から実務的に解説する「要件定義特化」の解説です。現状業務の可視化と標準化（AX）、機能要件・非機能要件の書き分け、外部連携とデータ移行の要件化、そして発注側に求められる「協力義務」という法的な論点まで、実際の判例や一次データを交えて掘り下げます。なお、印刷業界のシステムの全体像をまだ把握していない方は、まず印刷業界のシステムの完全ガイドから読むことをおすすめします。

▼全体ガイドの記事
・印刷業界のシステムの完全ガイド

現状業務の可視化と標準化から始める要件定義

RFPを書く前に、まず取り組むべきは現状業務（AsIs）の可視化です。印刷業の業務は、長年の慣行とベテランの暗黙知の上に成り立っており、当事者ですら「なぜこの手順なのか」を言葉にできないことがあります。受注から請求までの業務フローを、関係者へのヒアリングを通じて棚卸しし、図に起こすことが要件定義の出発点です。この工程を飛ばして「とにかくDXしたい」という曖昧な目的で発注すると、現場の実態に合わない高機能システムが出来上がり、誰も使わなくなります。

現場ヒアリングでは、営業・製版・機長・製本・経理といった全工程の担当者に、実際の作業手順と困りごとを聞き取ります。「どんな順番で何をしているか」「どこで手戻りや待ちが発生するか」「どの作業に時間がかかっているか」を具体的に洗い出すことが重要です。トップダウンで経営層だけが決めた要件は、現場の実態とずれていることが多く、製造・建設の現場でも「現場の反発を招いた」失敗が繰り返し報告されています。要件定義は現場起点で進めるのが鉄則です。

ヒアリングで見えた現状を、そのままシステム化してはいけません。非効率な手作業や属人的な手順をそのまま自動化すると、無駄を高速化するだけになります。AsIsを可視化したうえで、業務をシステムに合わせて標準化する「あるべき姿（ToBe）」を描き、ムダな工程を削ぎ落とすことが大切です。これはAX（業務改革を伴うデジタル化）の発想であり、システム導入を業務改善の機会と捉える姿勢が、要件定義の質を左右します。

RFPの冒頭では、「何のためにシステムを導入するのか」という目的を明文化します。進行管理の見える化なのか、見積精度の向上なのか、原価の把握なのか、目的によって作るべきシステムは変わります。「DXが流行りだから」という漠然とした動機ではなく、解決したい具体的な課題を、可能なら数値目標とともに示すことで、ベンダーは的を射た提案ができます。目的が定まると、何を作り、何を作らないかというスコープの線引きも明確になります。

スコープの明確化は、後の費用とトラブルを左右します。製造業の基幹開発は、小規模で500万〜2,000万円、中規模で2,000万〜8,000万円が目安とされ、カスタマイズ追加は1件100万〜1,000万円にもなります。スコープが曖昧なまま開発を始め、後から「あれも、これも」と機能を追加すると、費用が青天井になります。RFPの段階で「今回作る範囲」と「将来の拡張に回す範囲」を切り分けておくことが、予算管理の土台になります。

機能要件と非機能要件の書き分け

RFPの中身で核になるのが、機能要件と非機能要件の整理です。機能要件は「システムが何をできるか」、非機能要件は「どれだけの性能・可用性・セキュリティで動くか」を指します。印刷業のシステムでは、見積・受注・進行・原価・在庫・請求といった機能要件に目が行きがちですが、データ量の多い面付けや図版を扱う性能要件、納期管理を支える可用性要件など、非機能要件の軽視が後の不満を生みます。両者を分けて、漏れなく書き出すことが大切です。

機能要件は、ただ列挙するのではなく「必須・推奨・任意」といった優先度を付けて整理します。印刷業なら、ジョブチケットによる進行管理や用紙仕様に基づく見積計算は必須、設備とのJDF連携は推奨、といった具合に重み付けすることで、予算に応じた段階的な実装が可能になります。優先度を付けておくと、見積が予算を超えたときに、どの機能を削れば成立するかの判断もしやすくなります。全機能を「必須」にすると、調整の余地がなくなり交渉が硬直します。

機能要件を書くときに有効なのが、「誰が・いつ・何のために使うか」という業務シナリオで記述することです。「機長が印刷開始時に完了予定を入力する」「経理が月末に締めて請求書を発行する」といった具体的な利用場面で書くと、ベンダーは現場の使われ方をイメージしやすくなります。抽象的な機能名の羅列より、シナリオベースの記述のほうが、認識のズレを防ぎ、提案の精度を高めます。

非機能要件では、性能・可用性・セキュリティ・操作性を具体的に定めます。印刷業の場合、面付けや図版といった重いデータを扱うため、処理速度の要件は重要です。製造業でも、重い図面・部品表データは通信速度の問題からクラウドよりオンプレが有利とされており、印刷業もデータ特性を踏まえてクラウドかオンプレかを判断する必要があります。納期管理を担うシステムは止まると即座に業務が滞るため、稼働率や復旧時間の目標も非機能要件に含めます。

とりわけ印刷現場で軽視できないのが、操作性の要件です。現場には年齢構成やITリテラシーに幅があり、多機能すぎる画面は混乱を招きます。建設・農業の現場システムでも、高齢化に配慮した直感的なスマホ・タブレットUIが定着の決め手とされており、印刷現場でも同じ配慮が要ります。「現場担当者が研修なしで主要操作を行える」といった操作性の目標を非機能要件に明記し、提案時にUIの分かりやすさを評価軸にすることが、定着するシステムの条件です。

RFPを出す目的は、複数のベンダーから提案を集め、比較検討することにあります。そのため、要件を書くのと同時に、提案をどう評価するかの基準を定めておくことが大切です。価格だけで選ぶと、安いが現場に合わないシステムをつかむリスクがあります。機能の充足度、印刷業界の業務理解、操作性、サポート体制、開発実績といった評価項目を設定し、それぞれに重み付けをして総合的に判断する仕組みを用意します。評価基準を事前に決めておくと、提案を受けたあとの意思決定がぶれず、社内の合意も得やすくなります。

とりわけ印刷業では、業界特有の工程や商習慣をベンダーが理解しているかが、成否を大きく左右します。汎用の業務システムに詳しいだけでは、面付けや校正、用紙の取り都合といった印刷固有の事情を要件に落とし込めません。評価の段階で、印刷業の開発実績や、現場感を踏まえた提案ができるかを確認することが重要です。低価格を売りにしたシステムでサポートが追いつかず、1年未満で乗り換えて二重コストになった他業種の失敗例を踏まえれば、価格と業務理解・サポートのバランスで選ぶ姿勢が、RFPを成功に導きます。

外部連携とデータ移行の要件化

要件定義で見落とされがちなのに、後で大きなトラブルになるのが、外部連携とデータ移行の要件です。印刷業のシステムは、面付けソフト・CTP・印刷機といった設備、会計システム、Web受注（Web-to-Print）、得意先や協力会社のシステムと連携します。また、既存システムや手作業のデータを新システムに移す移行作業も発生します。これらをRFPで具体的に要件化しておかないと、見積に含まれず、後から多額の追加費用が発生します。

外部連携の要件化では、連携相手のシステム仕様と、調整に必要なリードタイムまで含めて記述します。設備や得意先システムとの連携は、相手側の都合に左右されるため、自社だけで完結しません。物流のEDI連携では、仕様変更は最低3ヶ月前に協議すべきとされるように、外部連携は早めの折衝が前提です。RFPに「どの外部システムと、どのデータを、どの方式で連携するか」を明記し、相手側との協議スケジュールも要件に織り込むことで、プロジェクト終盤の連携トラブルを防げます。

外部連携は、連携先が多いほど開発の難度と費用が上がります。すべてを一度に連携しようとせず、効果の大きい連携から優先する段階設計が現実的です。設備連携を欲張りすぎると、特定設備に依存したシステムになり、将来の設備更新時に足かせになります。連携の範囲も、機能要件と同じく優先度を付けて整理し、今回の連携と将来の連携を切り分けてRFPに記載することが、賢い要件化です。

データ移行は、要件定義で最も泥臭く、最も軽視されがちな領域です。得意先マスタ、用紙・資材マスタ、単価マスタ、過去の案件履歴などを新システムに移す際、古いデータをそのまま移すと、重複や表記揺れが新システムに引き継がれます。物流のWMS導入でも、重複・表記揺れ・古い情報を放置すると「ゴミデータを高速処理するだけ」になると警告されています。移行前のマスタクレンジング（データの整理・名寄せ）を、誰が・いつ・どこまでやるかをRFPに明記することが欠かせません。

マスタ整備は、ベンダーに丸投げできない発注側の責任領域です。どのマスタが正で、どの情報を残すかは、業務を知る発注側でなければ判断できません。RFPには、移行対象のデータ範囲、クレンジングの分担、移行後の検証方法を盛り込み、移行作業の工数とスケジュールを見積に含めてもらいます。データ移行を軽く見て要件から漏らすと、稼働直前に「データが汚くて使えない」という事態に陥り、本来の効果が得られません。

移行作業は、本番稼働前のテストとリハーサルまで含めて要件化することが理想です。実データを移して試験稼働させ、現場の担当者が実際に操作して問題がないかを確認する期間を、スケジュールに組み込みます。物流のWMS導入では、本番前に基幹・現場・実物の在庫を一致させる調整が欠かせないとされており、印刷業の用紙在庫や品目マスタでも同じ検証が必要です。移行とテストの工程をRFPで明確にし、誰がいつ何を確認するかまで決めておくことが、稼働直後の混乱を防ぐ備えになります。

発注側の協力義務と契約上の論点

要件定義とRFPの議論で、発注側が見落としやすいのが「協力義務」という法的な論点です。システム開発は、ベンダーだけの責任で進むものではなく、発注側（ユーザー）にも要件を適切に提示し、開発に協力する法的な義務があります。要件定義の段階でこの協力義務を理解しておくことが、開発が失敗した際の法的リスクを大きく左右します。RFPと要件定義は、単なる発注書ではなく、後の紛争を防ぐための合意形成の記録でもあります。

発注側の協力義務がいかに重いかを示すのが、旭川医大病院とNTT東日本のシステム開発をめぐる訴訟です。札幌高裁の控訴審判決（平成29年8月31日）では、ユーザー側の協力義務違反が認定されました。169項目あった追加要望のうち124項目が当初の開発対象外と判断され、最終的にユーザー側のみに約14億1500万円の支払いが命じられています。これは、発注側が要件を後出しで膨らませ続けると、法的責任を負いうることを示す重い事例です。

この判例の教訓は、要件定義の段階で要件を固め、安易な追加要望を抑えることの重要性です。仕様凍結後に大量の追加要望を出した結果、ユーザーが敗訴した例は他にもあります。印刷業のシステムでも、開発が進んでから「あの機能も欲しい」と次々に要望を追加すると、納期遅延や費用膨張を招くだけでなく、トラブル時に発注側の責任が問われます。RFPと要件定義の段階で、現場の要望を出し切り、合意したうえで凍結する規律が、発注側を守ります。

要件定義とRFPでは、開発後の運用・保守の条件も忘れずに定めます。SLA（サービス品質保証）として、障害時の対応時間、復旧目標、サポート窓口の体制を明確にしておくことで、稼働後の「言った・言わない」を防げます。保守費用は、一般に開発費の15〜20%が目安とされ、開発費3,000万円なら年450万〜600万円になります。この継続コストを要件定義の段階で見込み、TCO（総保有コスト）として予算化しておくことが、導入後の資金計画を安定させます。

保守の中身も、要件化しておくべき重要な論点です。低価格を売りにしたシステムでサポートの返信が遅く、結局1年未満で他社に乗り換えて二重コストになった、という他業種の失敗例があります。印刷業でも、業界特有の工程を理解したベンダーが、伴走型でサポートしてくれるかどうかが定着を左右します。RFPには、保守の応答時間や、業務理解のある担当者による支援体制を要件として盛り込み、価格だけでベンダーを選ばないことが、長期的な成功につながります。

協力義務を果たすうえで、RFPと要件定義に必ず盛り込みたいのが、要件凍結のタイミングと、その後の変更管理のルールです。要件定義のフェーズでいったん仕様を確定（凍結）し、それ以降の変更は所定の手続きを経るという合意を、契約や要件定義書に明記します。これにより、開発が始まってから現場の思いつきで要望が際限なく膨らむ事態を防げます。仕様凍結後に大量の追加要望を出した結果、納期遅延や費用膨張を招き、トラブルに発展した例は枚挙にいとまがありません。

もちろん、開発の途中で「やはりこの機能も必要だった」という変更が生じることはあります。重要なのは、変更をゼロにすることではなく、変更の影響と費用を双方で合意してから進める仕組みを持つことです。変更管理のルールには、誰が変更を起票し、誰が承認し、費用と納期への影響をどう評価するかを定めておきます。このルールがあれば、変更が秩序立って管理され、後から「言った・言わない」の紛争に発展するリスクを減らせます。要件定義は、作るものを決めるだけでなく、変更との付き合い方まで設計する作業だと捉えることが大切です。

まとめ

印刷業界のシステムのRFP・要件定義は、現状業務の可視化と標準化から始まり、機能要件と非機能要件の書き分け、外部連携とデータ移行の要件化、そして発注側の協力義務とSLAの明記という四つの柱で構成されます。現場ヒアリングでAsIsを棚卸しし、業務をシステムに合わせて標準化するAXの発想で要件を定め、優先度を付けて記述することが、現場に使われ、予算内に収まるシステムへの近道です。外部連携とデータ移行は見積から漏れやすく、マスタクレンジングは発注側の責任であることを忘れてはいけません。

とりわけ重要なのが、旭川医大の判例が示す発注側の協力義務です。要件を後出しで膨らませると、納期遅延や費用膨張だけでなく、約14億円の支払いを命じられた判例のように法的責任も問われます。要件定義の段階で要望を出し切り、合意して凍結する規律が、発注側を守ります。riplaはフルスクラッチ受託と国内開発の立場から、印刷業の業務に踏み込んだ要件整理と、協力義務を踏まえた進め方を一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

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

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

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

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

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。