農業システムのRFP（提案依頼書）と要件定義書は、現場の作業把握、要件の合意、連携・移行条件の明記の順に進めると、定着と手戻り防止につながります。
農業経営体向けに、RFP・要件定義書・提案依頼書の作り方を、その順に見ていきます。全体像は農業のシステムの完全ガイドもご覧ください。
▼全体ガイドの記事
・農業のシステムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
現状の作業フローを整理するヒアリング
要件定義では、現場の作業がどう回っているかを正確に把握する必要があります。農業は経験や勘、地域・経営体ごとの慣行で成り立っているため、言語化しないままシステム化すると、現場と仕様がずれてしまいます。だからこそ、まずヒアリングで現状の作業フローを徹底的に整理します。
現場・経営・販売の各層からの作業実態の聞き取り
農業システムの導入では、現場の声を聞かずにトップダウンで決めて失敗しがちです。リサーチでも、ヒアリングが不足したまま高機能化すると反発を招くと指摘されています。そのため、ヒアリングは経営者だけでなく、作業する生産者や出荷・販売の担当者にも行います。
作業の実態を集めるときは、現場の言葉で次の観点を確かめます。
- 担当者：誰が作業するか
- 場所と時期：どのほ場で、いつ行うか
- 作業上の負担：どの作業で手間取るか
立場によって評価軸も異なり、現場は使いやすさを、経営者はROI（投資対効果）や面積生産性を重視します。
各層の声は一枚の「現状の作業フロー図」にまとめます。誰がどの作業に時間を取られるかを共有でき、要件定義の出発点が明確になります。
評価軸の違いを把握しておくと、要件の優先順位付けや社内稟議も進めやすくなります。
あるべき姿の設計と業務の標準化
現状を把握したら、あるべき作業の姿を描きます。現状をそのままシステムに写すと、非効率な作業まで固定化してしまうからです。
属人化した作業や、人によって異なる工程は、見直してシステム化に適した形に整えます。この業務変革はAXと呼ばれ、導入効果を高める中核の考え方です。
標準化を進める際は、次の点を満たすようにします。
- 現場の納得：一方的に新しいやり方を押し付けない
- 課題を起点にする：作業を変える利点が伝わる形にする
- 要件の根拠：標準化した業務フローを機能要件に反映する
一方的な変更は、現場が従来のやり方に戻る原因になります。また、標準化を飛ばして機能だけを並べると、根拠のない要件になり、開発後の手戻りを招きます。
発注側の協力義務と要件凍結の作法
要件定義はベンダー任せにできず、発注側にも開発を円滑に進めるための協力義務が法的に求められます。要件が曖昧なまま進めたり、合意内容を後から覆したりすると、開発が頓挫し、発注側が法的責任を問われることもあります。そのため、要件凍結の作法を知ることも、自社を守る備えになります。
ユーザーの協力義務が問われた判例の教訓
裁判例では、ベンダーのプロジェクトマネジメント義務に加えて、発注側にも協力義務があると示されています。その例が、旭川医科大学病院とNTT東日本の事件です。
札幌高裁の控訴審（平成29年8月31日）では、ユーザー側の協力義務違反が認定されました。この判決では、169項目の追加要望のうち124項目が開発対象外と判断され、ユーザー側のみに約14億1,500万円の支払いが命じられました。
旭川医科大学病院とNTT東日本の判例は、要件定義で発注側の協力が欠かせないことを示しています。
- 追加要望：際限なく重ねると、発注側が責任を負う場合がある
- 要件定義：必要な機能を出し切り、合意範囲を明確にすることが最大の防御になる
- 記載範囲：合意した範囲と対象外の範囲を両方示す
仕様凍結後に大量の追加要望が出されたことが原因で、ユーザー側が敗訴した事例もあります。
要件凍結のタイミングと変更管理のルール化
要件凍結が曖昧なままでは、追加要望と費用が膨らむおそれがあります。そこで、RFPと契約には、要件凍結の時期や変更管理の手続きを具体的に記載します。
- 要件凍結：要件を確定する時期
- 変更時の扱い：追加要望の影響を整理し、追加開発費と納期への反映方法を定める
- 着手前の合意：変更内容・理由・影響範囲・追加費用を書面で合意し、トラブルを防ぐ
変更管理のルールは、発注側とベンダーの双方を守る仕組みになります。riplaはフルスクラッチ受託の立場から、要件定義で範囲を明確にし、変更管理を仕組み化することを重視しています。
RFPに盛り込む外部連携・データ移行
農業システムでは、外部関係者との連携と既存データの移行が見落とされがちです。本体機能ほど目立たなくても、抜けると手戻りやトラブルにつながります。そのため、RFPには連携先・移行対象・前提条件を明記します。
農協系統・出荷先との連携と事前協議
農業では、農協（JA）系統の物流・出荷システムと、市場や直販などの商系チャネルが分かれているケースが多くあります。そのため、連携には相手側の仕様に合わせた調整が必要です。
連携の準備では、次の事項をRFPと事前協議で明確にします。
- 事前協議：EDIの仕様変更は最低でも数ヶ月前から関係者と協議する
- 連携内容：外部システム、データの方向、連携内容をRFPに書く
- 未確定の前提：連携先が未定なら不確実性を前提条件にし、見積もりの幅を求める
外部システムとのデータ連携では、仕様変更前の協議が必要です。リサーチでも、物流系のEDI（電子データ交換）については、早期に関係者と調整することが指摘されています。
連携を後回しにすると、開発後半の調整が難航し、納期遅延やコスト増につながります。連携の有無と相手は、早い段階で固めておきます。
データ移行・マスター整備（クレンジング）の要件化
既存データの移行とマスター整備も、要件定義で抜けやすい作業です。紙、エクセル、別システムで管理していたほ場情報・取引先・資材などを移すには、想像以上に時間がかかります。
重複や表記揺れ、古い情報を残すと、リサーチが指摘する「ゴミデータを高速処理するだけ」のシステムになりかねません。そのため、既存データを新システムで活用するには、移行作業とクレンジングの範囲をRFPで具体化します。
- 移行対象：データの種類・件数・現在の保管形式
- 整備の分担：重複削除・表記統一・古いデータの整理を誰が担うか
- 稼働前確認：在庫・記録と実物を突き合わせ、整合を取る
移行はベンダー任せにできない部分が多く、発注側が現場の協力を得て主体的に進めます。また、移行と整備の工数を要件と費用に含めないと、予算超過につながります。
SLA・サポート体制と提案比較の軸
要件定義書とRFPでは、稼働後の品質保証（SLA）とサポート体制、提案を比べる軸も定めます。運用条件を先に決めておくのは、繁忙期にシステムが止まると収穫や出荷に直結するためです。発注前に条件を要件として示しておけば、各社の提案を同じ前提で比べられます。
SLAと保守費の要件明記
SLAは、繁閑に応じて水準を変えると現実的です。保守費の前提も要件に書いておきます。RFPには、次の条件を定めます。
- SLA：障害対応時間、受付時間・手段、稼働率
- 保守費：開発費の15〜20%が目安。見落とすと運用予算が破綻し、3,000万円規模なら年間数百万円規模
- サポート：ヘルプデスク、伴走体制、応答時間
- 繁閑別の水準：繁忙期は迅速な復旧を重視し、閑散期は即応性を調整する
農業現場は高齢化が進んでいるため、操作に困ったときに相談できる窓口や、現場感のある伴走型支援が定着を左右します。実際に、サポートの遅さが原因で別システムに乗り換え、二重コストを払う事例も報告されています。
RFPで応答時間や体制を問えば、各社の提案を比べられます。
田植えや収穫のピークに停止すると経営に響くため、迅速な復旧が欠かせません。一方で、閑散期には同じ即応性が不要な場合もあります。
一律に高いSLAを求めると保守費も高くなるため、業務の繁閑に合わせて水準を分けます。過剰なコストを避けつつ、必要な安心を確保できます。繁閑の前提も、要件に記載しておきます。
提案を同じ軸で比較するためのRFP項目
農業システムの提案を公平に比べるには、開発範囲から運用後の支援までを、各社に同じ条件で示します。条件をそろえておけば、提案を横並びで比べられます。
- 目的と範囲：解決したい課題、対象業務、機能要件
- 品質と前提：非機能要件、外部連携、データ移行
- 提案条件：希望納期、予算感、SLA、サポート要件
- 見積資料：体制図と見積もりの内訳
見積金額の安さだけで選ぶことは避けます。連携費・保守費・データ移行費を除いた提案は、後で追加費用になることがあるためです。
リサーチでは、安さを優先した結果、現場で使えず再導入となり、大きな損失が出た事例も報告されています。
体制図と見積内訳を求めたうえで、各社のPM（プロジェクト責任者）と面談します。面談で現場理解を確かめることが、ベンダー選定の判断材料になります。要件定義書とRFPの精度は、農業システム導入の成否を左右します。
現場感を理解したベンダーの見極め
農業システムの提案を比べるときは、次の観点から現場理解を見極めます。
- 農業の業務理解：作業サイクル、天候への依存、農協系統との関係
- 現場への適合：高齢化した現場のITリテラシーへの配慮
- PMとの面談：自社の課題や、同種案件の失敗を防ぐ方法を尋ねる
- 導入後の支援：伴走体制と、現場が困ったときの相談窓口
技術力が高くても、農業特有の文脈を理解していなければ、現場に合わない提案になり得ます。
RFPへの回答や面談で、理解の深さを確認します。また、PMが紋切り型の回答しかできない場合は、慎重に判断します。
リサーチでも、業界の現場感を理解した伴走支援が定着を左右するとされています。価格や機能に加えて、現場理解という定性的な軸も、要件定義と選定に含めます。
機能要件・非機能要件の分類とRFP項目
洗い出した要求は、機能要件と非機能要件に分けて、優先順位を付けます。要求を同列に並べると、ベンダーが優先事項を判断しにくく、見積もりも膨らみがちです。そのため、分類と優先順位付けによって、現実的な開発範囲を定めます。
機能要件の必須・優先・将来による分類
機能要件は、システムが何をするかを定めるものです。ほ場の水管理、作業記録、出荷管理など、具体的な機能を洗い出して、次のように分類します。
- 必須：導入目的の達成に欠かせない機能
- 優先：効果は大きいが、初期導入では見送れる機能
- 将来：次のフェーズで追加を検討する機能
この分類は、過剰なカスタマイズや高機能化を防ぎます。リサーチでも、業務をシステムに合わせ、本当に必要な機能に絞る重要性が指摘されています。
最初からすべてを盛り込むと、費用が膨らみ、現場が使いこなせないことがあります。そのため、必須機能から導入し、効果を確かめてから優先・将来の機能を追加します。
段階的に進める方針をRFPに書けば、初期投資を抑えながら現場に定着させる道筋を示せます。
非機能要件（性能・可用性・操作性）の要件化
非機能要件は、システムがどのように動くかを定めるものです。性能・可用性・セキュリティ・操作性などを、次のように具体化します。
- 可用性：農業システムが繁忙期に止まらないこと
- 操作性：高齢の生産者にも直感的なスマホ・タブレットUI
- 具体的な操作条件：主要記録は3タップ以内、文字サイズを変更可能
- 通信条件：ほ場でオフライン記録し、後で同期できること
リサーチでは、建設・農業の現場は高齢化が進んでおり、多機能すぎると混乱を招くと指摘されています。操作性は数値化しにくいものの、具体的な条件にして要件に記載します。
たとえば、ほ場の通信環境が不安定な場合に対応できないと、機能が揃っていても現場で使えないおそれがあります。そのうえで、機能要件とともに非機能要件もRFPへ記載し、各社の提案を比べられるようにします。
まとめ
農業システムのRFP・要件定義書では、現場・経営・販売の作業を一覧にして標準化してから、要件に落とし込みます。発注側にも協力義務があるため、要件凍結と変更管理のルールを定めて、自社を守ります。
旭川医科大学病院の判例（札幌高裁・平成29年）では、ユーザー側に約14億1,500万円の支払いが命じられました。合意範囲と対象外を明確にすることが重要です。
農協系統などとの外部連携は早めに協議し、データ移行・クレンジングの工数と費用を織り込みます。SLA・保守費（開発費の15〜20%が目安）とサポート体制も要件に書き込みます。
提案は同じ軸で比べ、見積もりの安さだけで選ばず、体制図とPM面談で現場理解を確かめます。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を創業。