印刷業界のシステム発注では、現場業務の可視化、要件の優先付け、変更管理の合意を順に進めると、手戻りや紛争を抑えやすくなります。
この記事は、印刷会社の発注側に向けて、RFP・要件定義書・提案依頼書の作り方を実務から解説する要件定義の記事です。業務・要件・連携・契約を整理します。全体像は完全ガイドもご覧ください。
▼全体ガイドの記事
・印刷業界のシステムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
現状業務の可視化と標準化から始める要件定義
印刷業では長年の慣行やベテランの暗黙知が残り、担当者も手順の理由を説明できないことがあります。そのため、RFPを書く前に現状業務（AsIs）を可視化します。受注から請求までを聞き取って業務フローに起こすことが、要件定義の出発点です。
この工程を飛ばして「とにかくDXしたい」と曖昧に発注すると、現場に合わない高機能なシステムができてしまい、誰も使わなくなります。
現場ヒアリングによるAsIsの把握
聞き取りでは、現場の負荷や工程間の滞りを把握し、システム化の前提をそろえます。
- 作業の順序：誰が、どの順番で何をしているか
- 滞りの発生箇所：手戻りや待ちがどこで起きるか
- 作業時間：どの作業に時間がかかるか
聞き取りの対象には、営業・製版・機長・製本・経理など、全工程の担当者を含めます。経営層だけで決めた要件は現場とずれやすく、製造・建設の現場でも反発を招いた失敗が報告されています。
そのため、要件定義は現場を起点に進めるのが基本です。ヒアリングで見えた業務を、そのままシステム化することも避けます。非効率な手作業や属人的な手順を自動化すると、無駄を高速化するだけになるからです。
AsIsを見える化したあとは、業務をシステムに合わせて標準化した「あるべき姿（ToBe）」を描き、不要な工程を削ります。これはAX（業務改革を伴うデジタル化）の考え方で、システム導入を業務改善の機会と捉える姿勢が、要件定義の質を左右します。
RFP冒頭での目的とスコープの明文化
RFPの冒頭では、システムを導入する目的を明文化し、解決したい課題を書きます。目的が違えば、作るシステムも変わるからです。
- 進行管理：進行状況を見える化する
- 見積：見積精度を高める
- 原価：原価を把握する
目的は「DXが流行りだから」で済ませず、具体的に示します。可能なら数値目標も添えます。目的が定まれば、作る範囲と作らない範囲も明確になります。
スコープは、後の費用とトラブルを左右します。製造業の基幹開発の目安は、小規模で500万〜2,000万円、中規模で2,000万〜8,000万円とされます。
カスタマイズの追加は1件100万〜1,000万円にもなり、範囲が曖昧なまま機能を足すと費用が膨らみます。そのため、今回作る範囲と将来の拡張範囲は分けておきます。
機能要件と非機能要件の書き分け
RFPでは、機能要件と非機能要件を分けて整理します。機能要件はシステムにできること、非機能要件は性能・可用性・セキュリティなどの動作条件を指します。
印刷業では、見積・受注・進行・原価・在庫・請求の機能に目が向きがちです。一方で、面付けや図版を扱う性能や、納期管理を支える可用性も欠かせません。非機能要件を軽視すると、導入後の不満につながります。そのため、両者を分けて漏れなく書き出すことが大切です。
優先度付きの機能要件の整理
予算を超えたときに調整できるよう、印刷業の機能に実装上の重みを付けておきます。
- 必須：ジョブチケットによる進行管理、用紙仕様に基づく見積計算
- 推奨：設備とのJDF連携
- 任意：予算に応じて段階的に実装する機能
優先度があれば、見積が予算を超えたときに、どの機能を削るかを判断できます。反対に、全機能を必須にすると調整の余地がなくなり、交渉も硬直します。
機能要件は、「誰が・いつ・何のために使うか」という業務シナリオで書きます。「機能名」を並べるだけより、具体的な利用場面を示したほうが、認識のずれを防ぎ、提案の精度も高まります。
たとえば、機長が印刷開始時に完了予定を入力し、経理が月末に締めて請求書を発行する場面を記します。そうすると、ベンダーも現場での使われ方を想像しやすくなります。
性能・可用性・操作性の非機能要件の定義
面付けなどの処理や停止時の影響、現場での定着まで、稼働後に必要な条件を仕様として共有します。
- 性能：面付けや図版など、重いデータの処理速度
- 可用性：稼働率と復旧時間の目標
- セキュリティ：必要な安全性
- 操作性：現場担当者が研修なしで主要操作を行える目標
印刷業では重いデータを扱うため、処理速度が重要になります。製造業では、重い図面や部品表の通信速度の面から、クラウドよりオンプレが有利とされています。
印刷業でも、データの特性を踏まえてクラウドかオンプレかを判断します。納期管理のシステムが止まると業務が滞るため、稼働率や復旧時間も定めておきます。
印刷現場では操作性も軽視できません。担当者の年齢やITリテラシーには幅があり、多機能すぎる画面は混乱を招くため、直感的なスマホ・タブレットUIへの配慮が必要です。
建設・農業の現場システムでも、高齢化に配慮したUIが定着の決め手とされています。そのため、提案の段階で操作性を評価軸に加え、画面の分かりやすさを確かめます。
要件と併せたベンダー評価基準の設定
RFPでは複数のベンダーから提案を集めて比較検討するため、要件と同時に評価基準を決めておきます。価格だけで選ぶと、安くても現場に合わないシステムを選ぶリスクがあります。
- 機能：要件をどれだけ満たすか
- 業務理解：印刷業界の業務を理解しているか
- 操作性：現場で使いやすいか
- 支援体制：サポート体制と開発実績
各項目に重みを付けて、総合的に判断します。評価基準を先に決めておけば、提案を受けたあとの意思決定がぶれにくく、社内の合意も得られます。
印刷業では、工程や商習慣への理解が成否を左右します。面付け・校正・用紙の取り都合を要件に反映するには、業界の業務を知るベンダーであることが欠かせません。
印刷業の開発実績と、現場を踏まえた提案力を確認します。他業種では、低価格のシステムでサポートが追いつかず、1年未満で乗り換えて二重コストになった例もあります。
価格と業務理解、サポート体制のバランスを見て選ぶことが、RFPの成功につながります。
外部連携とデータ移行の要件化
外部連携とデータ移行は見落とされやすく、あとで大きなトラブルにつながります。印刷業のシステムでは、設備や会計、受注先のシステムとの連携が発生します。
連携先には、面付けソフト・CTP・印刷機、会計システム、Web受注（Web-to-Print）、得意先や協力会社のシステムがあります。既存システムや手作業で扱ってきたデータも、移行の対象になります。RFPで具体化しておかないと、連携や移行が見積に含まれず、後から多額の追加費用が発生します。
外部連携における相手側との事前協議の要件化
連携要件には、相手側の仕様と調整に必要な期間も含めます。設備や得意先のシステムとの連携は相手の都合に左右されるため、自社だけでは完結しません。
- 対象：どの外部システムと連携するか
- データ：どのデータを連携するか
- 方式：どの方式で連携するか
- 協議日程：相手側との調整時期
物流のEDI連携では、仕様変更を最低3ヶ月前に協議すべきとされています。外部連携は、早めの折衝が前提になります。
連携先が多いほど、開発の難度と費用は上がります。そのため、効果の大きい連携から優先し、段階的に設計する方法が現実的です。
設備連携を増やしすぎると、特定の設備に依存し、将来の設備更新を難しくします。そこで、今回と将来の連携を切り分け、機能要件と同様に優先度を付けてRFPに記します。
これらをRFPに明記しておけば、プロジェクト終盤の連携トラブルを防げます。
データ移行・マスタクレンジングの要件化
データ移行は、軽く見られがちな領域です。得意先・用紙・資材・単価の各マスタや、過去の案件履歴を新しいシステムに移します。
古いデータをそのまま移すと、重複や表記揺れも引き継がれてしまいます。物流のWMS導入でも、重複・表記揺れ・古い情報を放置すると、ゴミデータを高速で処理するだけになると警告されています。
- 担当：誰がクレンジングするか
- 時期と範囲：いつ、どこまで整理するか
- 移行後の確認：検証方法とテスト工程
マスタクレンジングとは、データの整理や名寄せのことです。マスタの整備はベンダーに丸投げできません。どれを正とし、何を残すかは、業務を知る発注側が判断します。
RFPには、移行対象の範囲、クレンジングの分担、移行後の検証方法を記載します。また、工数とスケジュールも見積に含めてもらいます。
要件から漏れると、稼働直前になってデータが汚れていて使えないという事態になり、本来の効果を得られないおそれがあります。
データ移行には、本番稼働前のテストとリハーサルも含めます。実データで試験稼働し、現場の担当者が操作して問題を確かめる期間を設けます。
物流のWMS導入では、本番前に基幹・現場・実物の在庫を一致させる調整が欠かせません。印刷業でも、用紙在庫や品目マスタの検証が必要です。
RFPで移行とテストの工程を明らかにし、誰がいつ何を確認するかまで決めておくと、稼働直後の混乱を防ぐ備えになります。
発注側の協力義務と契約上の論点
発注側が見落としやすい法的な論点に「協力義務」があります。システム開発では、発注側も要件を適切に示し、開発に協力する義務を負います。
要件定義の段階でこの義務を理解しておくかどうかが、失敗時の法的リスクを左右します。RFPと要件定義は、発注のための文書にとどまらず、紛争を防ぐ合意形成の記録でもあります。
協力義務違反が問われた判例
旭川医大病院とNTT東日本の開発訴訟は、発注側が負う協力義務の重さを示す例です。札幌高裁の控訴審判決は、平成29年8月31日に出されました。
- 追加要望：169項目のうち124項目が当初対象外
- 判決：ユーザー側の協力義務違反を認定
- 支払い：ユーザー側のみに約14億1500万円
この追加要望の内容と支払い額は、要件を後から膨らませ続けると、発注側が法的責任を負いうることを示しています。
この件の教訓は、要件定義で内容を固め、安易な追加要望を抑えることです。仕様凍結後に大量の追加要望を出し、ユーザーが敗訴した例は、ほかにもあります。
印刷業でも、開発中に機能を次々と追加すると、納期遅延や費用膨張を招き、発注側の責任を問われることがあります。
現場の要望はRFPと要件定義の段階で出し切り、合意後は凍結します。この規律が、発注側を守ります。
契約に明記するSLAと保守範囲
開発後の運用・保守の条件も、RFPと要件定義で定めます。契約後の認識違いを防ぐため、障害対応と保守支援の条件を分けて明記します。
- SLA（サービス品質保証）：障害対応時間・復旧目標・サポート窓口の体制
- 保守支援：応答時間と、業務を理解した担当者による支援体制
保守費用は一般に、開発費の15〜20%が目安とされます。たとえば開発費3,000万円の場合、保守費用は年450万〜600万円です。この継続費を要件定義で見込み、TCO（総保有コスト）として予算化しておくと、導入後の資金計画が安定します。
保守は、要件として含めておく必要があります。他業種では、低価格のシステムで返信が遅く、1年未満で他社へ乗り換えて二重コストになった例があります。
保守の内容は、RFPで定めるべき重要事項です。印刷業では、工程を理解したベンダーによる伴走型のサポートが、定着を左右します。
選ぶ際は、価格だけでなく必要な支援を評価することが、長期的な成功につながります。
要件凍結と変更管理のルール
協力義務を果たすために、RFPと要件定義の段階で、要件凍結の時期と変更管理のルールを定めます。要件定義で仕様を確定し、それ以降の変更は所定の手続きを経たうえで、契約や要件定義書に記します。
この合意があれば、開発中に現場の思いつきで要望が膨らむ事態を防げます。仕様凍結後に大量の追加要望が出て、納期遅延や費用膨張から紛争に発展した例は数多くあります。
開発途中で必要な機能が見つかることもあります。その場合、変更をなくすのではなく、影響と費用を双方が合意してから進めます。
- 起票と承認：誰が変更を起票し、誰が承認するか
- 影響評価：費用と納期への影響をどう評価するか
変更管理の手順を定めておくと、変更を秩序立てて扱えます。後から「言った・言わない」の紛争に発展するリスクも減らせます。
要件定義では、作るものだけでなく、変更とどう付き合うかまで決めることが大切です。
まとめ
印刷業界のシステムのRFPと要件定義は、現状業務の可視化と標準化から始まります。機能要件と非機能要件を分けたうえで、外部連携とデータ移行も具体化します。
現場ヒアリングを起点にAXの発想で業務を見直し、要件に優先度を付けておくと、現場で使われ予算内に収まるシステムに近づきます。
連携や移行は見積から漏れやすく、マスタクレンジングは発注側の責任です。
要件を後から膨らませると、納期遅延や費用膨張に加えて法的責任も問われます。旭川医大の判例では、約14億円の支払いが命じられました。
riplaはフルスクラッチ受託と国内開発の立場から、印刷業の要件整理と協力義務を踏まえた進め方を支援しています。全体像は完全ガイドをご覧ください。
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。