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