3社から提案が届いた場面を、説明のための仮の例で作ります。以下の金額はすべて架空で、特定の案件のものではありません。1社目は「AI 業務改善一式 980 万円」の1行見積。2社目は月額 240 万円の準委任で、期間は6か月、体制は 3.5 FTE と書いてある。3社目は初期費用 180 万円と月額 45 万円のサービス利用料で、開発の作業は「別途お見積り」。この3枚をそのまま並べて、どれが安いかを言える人はいません。単位が違い、含まれる作業が違い、終わったときに手元に何が残るかも違うからです。提案が横に並ばない理由は1つではありません。各社の提供方式（人を出すのか、自社サービスを使わせるのか）や、見積から外している作業の違いも重なります。ただし、依頼する側が対象範囲と期間を指定していないことは、発注側の側で減らせる原因です。
FDE（Forward Deployed Engineer）型の支援は、要件が固まる前に人が入って動くものを作るという性質上、この問題が特に出やすい。何を作るかが最初に確定していないので、提案の書き方が会社ごとに割れます。FDE そのものの定義は今さら聞けない「FDE」とは？に書きました。この記事で扱うのは、その前段にある発注先の選び方のうち、提案依頼書（RFP）に何を書くかと、返ってきた提案を並べたときの比較軸の2つに絞ります。費用の構造と見積書の読み方はFDE に頼むといくらかかるのか、契約前に相手へ投げる質問はFDE の失敗パターン10、選定後の契約条項の書き方はPoC で止まる会社と FDE で動いた会社にあります。ここは重複させません。
提案依頼書に書くのは、作るものの仕様ではなく、判断できる状態の定義。対象業務の範囲、成功の測り方、出せるデータと権限、体制と会議体、期間と変更の手続き、契約類型と支払いの単位、終わり方の7項目を書けば、提案は横に並ぶ。並べたときは7つの軸で見て、そのうち金額より先に確認するのは、完成の定義・来る人と稼働・進め方と区切り・引き継ぎ物と権利・非機能条件の5点。金額は対象範囲と期間を全社そろえた総額で比べ、見積に入っていない作業は「未見積」と書き残す。IPA のモデル契約は、アジャイル開発版の別紙と契約前チェックリストを提案依頼書の目次に使い、第二版は工程ごとに契約類型を割り当てるときに使う。
この記事の要約
提案依頼書を書く前に、発注側が決める3つ
提案依頼書の質は、書き始める前に社内で決まっているかどうかで決まります。決まっていない状態で書くと、依頼文は「AI を活用した業務効率化のご提案をお願いします」という一文になり、提案は各社の得意分野の紹介になって返ってきます。先に決めるのは3つです。
1つ目は、対象業務の範囲を業務の名前で切ること。「経理の効率化」ではなく「請求書の受領から仕訳の登録まで。月あたり 400 件、担当2名、締めの5営業日で処理している」と書ける粒度まで落とす。件数と所要時間が書けないなら、提案依頼書を出す前に1か月測ってください。この数字は後で見積を比較するときの共通の分母になります。
2つ目は、成功の測り方。何をもって本番と呼ぶかを、発注側の言葉で決めます。「精度が高いこと」ではなく「担当者の修正なしに通った仕訳の割合が、直近1か月の実データに対して何%」のように、測る対象・母数・時期の3つを書く。決め方は生成AIの「評価設計」に整理しました。この項目を空欄のまま出すと、各社が自社の測りやすい指標を提案書に書いてきて、比較のときに単位が揃わなくなります。測り方は1つに絞らないほうがよい。修正なしで通った割合だけを見ると、誤った出力を人が見逃した場合を拾えないからです。依頼書には、全社に渡す同じ検証データ、絶対に出してはいけない誤りの種類と許容できる件数、人が確認に使う時間、モデルやサービスが更新されたときに測り直す時期の4つを、記入例として添えてください。
3つ目は、出せるデータと出せない情報、そして渡せる権限。本番データを社外に出せるのか、匿名化が要るのか、どのシステムに読み取り権限を出せるのか。ここが未定のまま契約すると、着任した人の作業が権限申請の待ち時間で止まります。判断の観点は顧客データを外に出さずに AI を本番で使うに書いたとおりで、提案依頼書には結論だけを1段落で書けば足ります。
この3つが決まっていれば、依頼書の本体は数枚で足ります。当社が下書きを手伝うときは A4 で3〜5枚に収まることが多く、これは目安であって決まった分量ではありません。逆に、3つが決まっていないまま枚数だけ増やしても、埋まるのは会社概要と提出要領です。
提案依頼書に書く7項目——IPA のモデル契約の目次を借りる
何を書くかを一から考える必要はありません。IPA（情報処理推進機構）が公開している情報システム・モデル取引・契約書は、契約書のひな型と各開発段階の責務の解説を無償で公開したもので、そのうちアジャイル開発版の別紙が、案件ごとに決める項目の一覧になっています。別紙の項目は、本プロジェクト、開発対象プロダクト、スケジュール、体制（スクラムチーム構成）、会議体、本件業務の内容及び役割分担、本契約の有効期間、委託料及び支払方法の8つ。これは契約書の別紙ですが、中身は「発注側が先に決めておかないと契約が書けないこと」の一覧なので、提案依頼書の目次にそのまま使えます。
ウォーターフォール型を対象にした第二版にも同じ発想の条文があります。IPA の講演資料に載っている個別契約の条文は、個別業務に着手する前に、発注側から示した提案依頼書（RFP）と受注側の提案書・見積書を基礎として、具体的作業内容（範囲、仕様等）、契約類型（請負・準委任）、作業期間又は納期、作業スケジュール、役割分担、連絡協議会の運営、発注側が提供する資料等、作業環境、納入物の明細及び納入場所、委託料及びその支払方法、検査又は確認に関する事項の各号を定める、という構成になっています。提案依頼書に何を書くべきかは、契約書に何を書くことになるかから逆算できる、ということです。
この2つを、FDE 型の発注に合わせて7項目に畳んだのが次の表です。右端の列は、その項目を空欄にしたときに提案がどう割れるかを書いています。
| # | 項目 | 書く中身（発注側が埋める） | 空欄にすると起きること |
|---|---|---|---|
| 1 | 対象業務と現状の数字 | 業務名、開始と終了の工程、月あたりの件数、担当者数、現在の所要時間。使っている既存システム名 | 各社が対象範囲を独自に解釈し、安い提案は範囲が狭いだけになる |
| 2 | 成功の測り方 | 本番と呼ぶ状態、測る指標と母数、測る時期。誰が合格を判定するか | 提案書の指標が各社バラバラになり、金額しか比較できなくなる |
| 3 | 出せるデータと権限 | 実データを渡せるか、匿名化の要否、読み取り権限を出せるシステム、作業場所と持ち出しの可否 | 着任後に権限待ちが発生し、期間の前半が消える |
| 4 | 体制と会議体 | 発注側の出席者と役割（決裁・業務・情シス）、社内で引き継ぐ担当者の有無、週次の時間帯 | 受注側だけの体制が提案され、判断待ちで止まる |
| 5 | 期間と区切り | 希望する開始日、区切りの長さ（1〜2週）、見せてほしい頻度、延長の可否 | 6か月一括の提案と2週間ごとの提案が並び、進み方を比べられない |
| 6 | 契約類型と支払いの単位 | 準委任か請負か、単価と稼働時間で払うか成果物単位か、月次報告に求める内容 | 一式見積と単価見積が混在し、金額の換算ができない |
| 7 | 終わり方 | 引き継ぎで受け取りたい物、成果物の権利の帰属、再委託の可否、途中で止めるときの手続き | 契約終了時に社内に何も残らない提案が最安値で採用される |
項目4の体制は、受注側の人数と同じくらい、発注側の出席者が効きます。誰が決裁を出し、誰が業務の実態を答え、誰がデータと権限を握っているか。当社の見立てでは、この3者の名前と週の時間を提案依頼書に書いてある案件のほうが、返ってくる提案の中身が具体的になります。体制の作り方はFDE を受け入れる社内体制に書きました。項目7の引き継ぎ物は、FDEが抜けた後も回る引き継ぎで挙げた手順書・権限表・変更手順を、そのまま「提案書に含めてください」と書けば足ります。
提案依頼書に書かないほうがよいこと
書く項目より、書かない項目のほうが判断を分けます。FDE 型の発注で提案依頼書に入れると事故になりやすいのは、次の3つです。
1つ目は、画面と機能の仕様を確定させて書くこと。ただしこれは、作るものが決まっていない案件の話です。画面と項目まで書ける状態なら、仕様を確定させて相見積を取るほうが手数も費用も少なくて済みます。決まっていないのに仕様を書くと、提案は仕様どおりの見積になり、着手後の変更のたびに追加見積が出る。なお、仕様を固めて発注した場合でも、稼働後に現場が使い続けられるようにする作業（運用手順の整備、担当者の教育、例外処理の追加）は残ります。ここまでを誰がやるかは、仕様の確定とは別に決めてください。IPA のアジャイル開発版モデル契約が準委任契約を前提にしている理由もここにあり、解説は、あらかじめ内容が特定された成果物を予定どおり完成させることに対価を払う請負契約では、対価を固定した場合に受注側へ追加・変更を抑制する動機が生じ、両当事者の利害対立を招くリスクがあると書いています。
2つ目は、使う技術や製品を細かく指定すること。指定した時点で、その製品を扱う会社しか提案できません。指定する理由があるのは、すでに社内で使っていて動かせない既存システム、情シスが決めた社内標準、保守の体制がすでにある製品の3つ。新しい製品でもこの3つに当たれば指定してかまいません。当てはまらない道具は、提案の比較材料として各社に書かせたほうが情報が増えます。AI 会社の支援部隊が自社製品を前提にする構図はFDE の失敗パターン10で扱いました。
3つ目は、提案書の枚数と体裁を細かく指定すること。様式が重くなるほど、提案書を作る部署を持つ会社が有利になります。FDE 型で効くのは、来る人の経験と進め方であって、提案書の作り込みではない。当社は、様式は A4 で 10 枚程度、必ず書いてほしいことを箇条書きで指定する形が、比較しやすさと参加のしやすさの折り合いが付くと考えています。
並べたときの比較軸——7つの軸と、金額より先に見る5点
提案が返ってきたら、比較表を作る前に軸を決めます。軸を決めずに表を作ると、各社の提案書の目次がそのまま列になり、書いてある項目が多い会社が良く見える。当社が使っている軸は7つです。そのうち、金額より先に確認するのは①から⑤の5点。金額（⑥）と止めるときの条件（⑦）は、この5点で内容が揃ってから見ます。
| 軸 | 何を見るか | 良い提案の形 | 危ない提案の形 |
|---|---|---|---|
| ① 完成の定義 | 提案書の中で、本番と呼ぶ状態が発注側の定義と一致しているか | 依頼書に書いた指標と母数をそのまま引用し、測る時期と判定者まで書いている | 「業務効率化の実現」で終わり、測り方が書かれていない |
| ② 来る人と稼働 | 役割ごとの人数を稼働換算（FTE）と経験で書いているか。交代時の扱い | 役割・求められる経験・想定 FTE・単価が行ごとに分かれている | 「専任チームで対応」とだけ書き、人数も稼働も書いていない |
| ③ 進め方と区切り | 何日ごとに動くものを見せるか。範囲を変えるときの手続き | 1〜2週の区切りと、見せる会議・変更の合意方法が書いてある | 月次報告のみ。変更は「別途協議」 |
| ④ 引き継ぎ物と権利 | 終わったときに社内へ何が残るか。成果物の権利は誰のものか | 手順書・権限表・変更手順を成果物として列挙し、権利の帰属案を明示 | 成果物が報告書と議事録。権利の記載なし |
| ⑤ 非機能条件 | 止まったときの復旧、応答時間、運用の担当、移行、セキュリティ | 今回効く項目だけを選んで数値で書いている | 非機能に触れず、稼働後の運用が誰の担当か書かれていない |
| ⑥ 金額の換算 | 月あたりの費用に換算できるか。含まれない作業が特定できるか | 単価と想定稼働、含まれない作業（データ移行・運用）が分かれて書いてある | 一式。内訳が「システム構築費」の1行 |
| ⑦ 止めるときの条件 | 途中で止める場合の手続きと、そのときの支払い・引き渡し | 解約の申し入れ方法と、途中までの成果物の扱いが書いてある | 記載なし。契約書のひな型を後出しにする |
⑤の非機能条件は、独自に軸を作らずに IPA の非機能要求グレードを使うのが早い。システム基盤に関する非機能要求を、可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの6つの大項目に分類したもので、2010 年 4 月に初版が公開され、2018 年 4 月に改訂されています。全体で 236 のメトリクスがありますが、比較で全部を使う必要はありません。今回の業務で止まったら困る項目だけを、依頼書の段階で 10 個ほど選んで書く。目的は、発注側と受注側の認識の行き違いを防ぐことだと IPA 自身が書いています。
採点で気をつけることが3つあります。第一に、必須条件と加点項目を分けること。満たしていなければ選考から外す条件（対応できる業務領域、着任できる時期、機密情報の扱い、財務の健全性）は、点数ではなく可否で判定します。会社の規模、過去の導入社数、資格の保有数を、この必須条件に置くか、加点項目として小さい重みで見るかは、発注側が自分の業務リスクから決めてください。止まると業務が回らない基幹の作業なら、事業を続けられる見込みや同種の実績を必須条件に置くほうが筋が通ります。第二に、加点項目の重みを業務リスクから決めること。7軸を同じ点数で足すと、書きやすい項目を厚く書いた会社が有利になります。第三に、平均ではなく最低点を見ること。6軸が満点で1軸が空欄という提案は、その空欄の中身が着手後の交渉に回ります。
提案書に書いてあることと、実際に来る人ができることは別です。最終候補には、着任予定者との面談を設定し、こちらの業務データの一部を渡して、その場で扱い方を説明してもらう。同じ課題を各社に出し、返ってきた進め方を比べる方法もあります。人が入って動く前提の発注では、書類の点数より、この確認のほうが結果に効きます。
金額の形が違う提案を、横に並べる
比較のいちばん面倒な作業がここです。提案の金額は、一式、月額、単価×稼働、初期費用＋利用料の4つの形で返ってきます。形が違うまま並べても意味がないので、先に比較の土台を1つ決めます。対象業務の範囲（依頼書の項目1）と、比べる期間。期間は提案の期間ではなく、発注側が使い続ける想定の年数から決めてください。この2つを固定したうえで、各社の提案をその範囲・その期間の総額に直します。月あたりの費用は、総額を期間で割った参考値として横に置きます。
| 提案の書かれ方 | 換算のしかた | 先に確認すること |
|---|---|---|
| 一式（総額のみ） | 総額 ÷ 提案期間の月数で月あたりに直す | 期間が延びたときに追加が出るのか、総額のままか |
| 月額（体制の記載あり） | そのまま。総額は月額 × 提案期間 | 稼働の下限があるか、月内で稼働が減ったときに減額されるか |
| 単価 × 稼働時間 | 単価 × 想定稼働時間 で月あたりを出す | 想定稼働が上振れしたときの上限、月次の稼働報告の様式 |
| 初期費用 ＋ 月額利用料 | 初期費用 ÷ 想定利用月数 ＋ 月額利用料 | 利用料に含まれる作業、追加開発の単価、解約時の残債 |
| どの形にも共通 | 見積に入っていない作業は 0 円にせず「未見積」と書いて行に残す | データ移行、既存システムとの接続、運用開始後の対応、教育 |
冒頭の3社を、この土台に載せ直します。対象範囲は「請求書の受領から仕訳の登録まで」、期間は 24 か月に固定し、各社に追加で確認したのは、提案期間を過ぎた後の費用、データ移行と既存システムとの接続が見積に入っているか、運用開始後の対応は誰の担当か、の3点です。金額は冒頭と同じく説明のための架空の数字です。
| A社（一式 980 万円） | B社（月額 240 万円） | C社（初期 180 万円＋月額 45 万円） | |
|---|---|---|---|
| 提案の対象期間 | 記載なし。確認して6か月と判明 | 6か月 | 構築3か月＋利用期間の定めなし |
| 24 か月に直した総額 | 980 万円＋延長 18 か月分（延長は月 120 万円との回答）＝ 3,140 万円 | 240 万円 × 24 ＝ 5,760 万円（7か月目以降も同額との回答） | 180 万円＋45 万円 × 21 ＝ 1,125 万円 |
| データ移行・既存システムとの接続 | 見積に含む | 見積に含む | 未見積（別途お見積り） |
| 運用開始後の対応 | 未見積 | 月額に含む（月 20 時間まで） | 利用料に含む（障害対応のみ） |
| 終了時に社内へ残る物 | 納品物一式。権利の記載なし | 手順書・権限表・変更手順 | サービス上の設定。解約すると使えない |
同じ範囲と期間に直すと、1行見積で最も安く見えた1社目は延長分で膨らみ、総額が最も低い3社目は接続の作業が丸ごと未見積であることが分かります。終了時に社内へ何が残るかを書いているのは2社目だけ。ここまで並べて初めて、金額の欄が意味を持ちます。未見積の行を 0 円で埋めてしまうと、この差が消えます。
換算の根拠は、IPA のアジャイル開発版モデル契約の別紙が参考になります。別紙の体制の欄は、役割、求められる経験・スキル、想定 FTE（フルタイム当量）、1 FTE あたりの基準単価（月額）の4列で書く形になっており、委託料は受注側人員の単価と稼働時間により算定する、というサンプルが載っています。提案の段階でこの4列を書いてもらえば、換算の作業はほとんど不要になる。依頼書の様式にこの表を貼り付けて、これに記入してくださいと書くのがいちばん早い方法です。
同じ別紙には、月ごとの実施業務の確認の条文もあります。受注側が当月に実施した業務の概要や稼働時間数を翌月の指定日までに報告し、発注側が定めた点検期間内に内容を確認して異議がなければ確認の通知を行い、期間内に書面で具体的な理由を明示して異議を述べなければ確認したものとみなす、という流れ。単価と稼働時間で払う契約は、この報告と点検の仕組みがあって初めて機能します。提案書に月次の稼働報告の様式が載っているかどうかは、⑥の金額の軸で見るべき点の一つです。見積書そのものの読み方はFDE に頼むといくらかかるのかに譲ります。
IPA のモデル契約と厚労省の Q&A を、どこで使うか
モデル契約は契約段階の道具だと思われがちですが、提案依頼書と選定の段階のほうが使い道があります。使いどころを整理します。
| 資料 | 何が載っているか | 選定のどこで使うか |
|---|---|---|
| モデル取引・契約書（アジャイル開発版）の別紙 | 案件ごとに決める8項目（プロジェクト、開発対象、スケジュール、体制、会議体、業務内容と役割分担、有効期間、委託料と支払方法） | 提案依頼書の目次と、提案書に記入してもらう様式 |
| 同・契約前チェックリスト | 目的とゴール、プロダクトのビジョン、アジャイル開発の理解、開発対象、初期計画、契約の理解、体制（共通・発注側・受注側）の9項目 | 依頼書を出す前の自己点検と、最終候補と締結前に一緒に確認する |
| 同・モデル契約の条文と解説 | 準委任を前提とする理由、変更管理、再委託、著作権の帰属の3案（発注側帰属を原則、受注側帰属、共有）、損害賠償の累計総額の上限（実際に支払った委託料の合計額） | 提案書の契約条件の欄を読むときの基準。差分だけを質問する |
| モデル取引・契約書（第二版） | ウォーターフォール型を対象にした契約書と解説。工程ごとの契約類型の割り当て方 | 既存システムの移行や保守が絡み、工程を分けて発注するとき |
| 非機能要求グレード | 6つの大項目と 236 のメトリクス | 依頼書の非機能条件の欄と、比較軸⑤の採点表 |
| 厚労省の疑義応答集（第3集） | アジャイル型開発と偽装請負の判断の考え方 | 常駐や協働の進め方を提案書で確認するとき |
契約前チェックリストは、受注側に投げる前に発注側が自分で埋めるものです。IPA の解説は、契約締結に先立って、目的とゴール、開発対象のビジョン、双方の開発手法の理解、初期計画、必要な体制がそろっているかを確認し、不足があれば補う対策をしておくべきだと書いています。項目には、完了基準・品質基準が明確になっているか、発注側が適切な責任者を選任して権限委譲ができるか、受注側が開発チームを固定できるか、といったチェックポイントが並ぶ。埋まらない欄があったときは、3つに仕分けます。社内で決めるもの（目的とゴール、責任者と権限、完了基準）。仮に置いて提案を求めるもの（初期計画のスケジュール、区切りの長さ、想定 FTE）。候補企業と一緒に確認するもの（開発チームを固定できるか、常駐や協働の進め方、技術的に実現できるか）。仮置きするときは「当社の希望は6か月・週次。実現できる計画を提案書に書いてください」のように、希望と、変えてよい範囲の両方を書く。依頼書の末尾には、質問の受付期限、回答を全社へ同じ内容で共有するかどうか、提案の提出期限、選定結果の連絡時期を書いておくと、問い合わせのやり取りが減ります。
④の引き継ぎ物と権利を採点するときは、モデル契約の条文を基準にすると読みやすくなります。IPA のアジャイル開発版モデル契約は、受注側が本件業務の過程で新たに作成した著作物の著作権について、発注側に帰属させる A 案を原則としつつ、受注側に帰属させる B 案と、共有とする C 案も選べる形にしています。どの案でも、受注側が以前から持っていた著作物の著作権は移りません。損害賠償は、累計総額を、発注側が受注側に実際に支払った委託料の合計金額を限度とする条文が置かれ、故意または重大な過失による損害には適用しないとされています。提案書の契約条件がこれと違うときは、違う理由を聞けば足ります。個別の契約でどう書くかは事案ごとに変わるため、締結前に弁護士に確認してください。
もう1つ、FDE 型で必ず論点になるのが、発注側と受注側が同じ場所で密に連携する進め方と、労働者派遣・請負の区分の関係です。厚生労働省が公表している疑義応答集（第3集）は、アジャイル型開発を題材にこの点を扱っています。契約が請負か準委任かという形式ではなく実態で判断されること、発注側と受注側の開発関係者が対等な関係の下で協働し、受注側の開発担当者が自律的に判断して開発業務を行っていると認められる場合であれば偽装請負と判断されるものではないこと、他方で発注側の責任者や担当者が受注側の担当者に対して直接、業務の遂行方法や労働時間等に関する指示を行うなど指揮命令があると認められる場合には偽装請負と判断されること、が書かれています。同じ資料は、こうした事態が生じないよう、双方の開発関係者の役割や権限、チーム内での業務の進め方をあらかじめ明確にして合意しておくことや、事前研修などで開発手法の特徴について認識を共有しておくことが重要だとしています。
選定の場面での使い方は単純です。提案書に、役割と権限の切り分けが書かれているか、日々のやり取りを誰と誰がどう行う想定かが書かれているかを見る。書かれていない提案が悪いのではなく、着任後にこの線引きを発注側が独りで考えることになるので、最終候補との打ち合わせで必ず確認する項目に入れておきます。個別の判断は事案ごとに変わるため、線引きが微妙な進め方を採る場合は、社会保険労務士や弁護士に確認してください。
まとめ
提案が比較できない原因のうち、発注側が減らせるのは依頼書の中身です。IPA のモデル契約の別紙と個別契約の条文を、発注側の作業に合わせて当社が7項目に整理し直しました。対象業務と現状の数字、成功の測り方、出せるデータと権限、体制と会議体、期間と区切り、契約類型と支払いの単位、終わり方。白紙から考える必要はありません。逆に、画面と機能の仕様、使う製品の細かい指定、提案書の様式の作り込みは書かないほうが、比較に必要な情報が集まります。
並べるときは7つの軸で見て、そのうち完成の定義、来る人と稼働、進め方と区切り、引き継ぎ物と権利、非機能条件の5点を金額より先に確認する。金額は、対象範囲と期間を全社そろえた総額に直してから表に入れ、見積に入っていない作業は「未見積」と書き残す。非機能条件は非機能要求グレードの6項目から今回効くものだけを選び、常駐と協働の線引きは厚労省の疑義応答集の考え方を提案書で確認する。この手順で、最安値を選んで着手後に追加見積が積み上がるという結果は減らせます。従業員 30〜300 名の会社が、そもそも FDE 型で頼むべきかどうかの判断は従業員30〜300名の会社は FDE を頼むべきかに書きました。
FDE を募集しています（会計FDE／FDE・業務システム）
経理の月次をAIで本番まで持っていく「会計FDE」（会計士・経理責任者・管理部門経験者）と、要件が固まる前に動くものを出して本番まで運ぶ「FDE（業務システム）」（ITコンサル・PM/PL・情シス出身者）を正社員で募集しています。応募でなくても構いません。まず30分の「キャリア相談」から。採用のお問い合わせフォームに「キャリア相談希望」と書いて送ってください。
提案依頼書の下書きと、届いた提案の比較表づくりをお手伝いします
対象業務の切り方と現状の数字の取り方、成功の測り方の決め方、提案依頼書の7項目の下書き、届いた提案を同じ単位に換算する比較表まで、貴社の業務と既存システムに合わせて整理します。当社が候補に入らない前提のご相談でも構いません。経理 AX・kintone・案件管理システム刷新・Claude 導入で本番稼働まで伴走した経験をもとに、発注側の立場で必要な項目を洗い出すところから始められます。