見積管理システムのモダナイゼーションのアセスメント/要件定義/RFPについて

上流工程は、現状分析(アセスメント)、要件定義、RFP(提案依頼書)の作成、ベンダー選定の順に進みます。

支援費用は、資産棚卸しや要件定義の支援範囲によって、一般に200万円から500万円程度になることもあります。全体像は見積管理システムのモダナイゼーションの完全ガイドもご覧ください。

▼全体ガイドの記事
・見積管理システムのモダナイゼーションの完全ガイド

見積管理刷新のアセスメント(現状分析AS-IS)の進め方

見積業務の現状把握で確認するExcel見積、積算・単価、承認フロー、過去データを4枚のカードで示した図。
様式や計算ルール、承認、保管先を順に見渡せます。

刷新の初めに取り組むのは、現状の見積業務を正確に把握するアセスメント(現状分析AS-IS)です。この分析は、刷新全体の土台となる最初の関門です。

現状を把握しないまま要件定義に進むと、現場の運用や例外処理が抜け落ちやすくなります。その結果、稼働後に業務が回らなくなるおそれがあります。

見積業務の現状把握の対象

AS-IS分析では、散らばっている資産と業務の流れを一覧にします。見積管理に特有の対象は漏れなく洗い出し、実際のファイルや帳票も確かめます。そうすると、ヒアリングだけでは見えにくい実態も分かります。

  • Excel見積:部門や担当者ごとの様式と散在状況
  • 積算・単価:計算式や更新ルールの属人化
  • 承認フロー:承認者、段階、差し戻しの実態
  • 過去データ:フォルダ、メール、個人PCへの分散
  • 外部連携:CRM/SFAや基幹システムとの接続状況

積算ロジックと単価マスタは見積の精度に直結します。計算の流れを人に頼ったままにすると、新システムで同じ結果を再現できず、現場の信頼を損なうおそれがあります。

アプリ資産の複雑度と依存関係

改修を重ねたシステムでは、プログラムやデータの依存関係が複雑になっていることがあります。機能が参照するデータや外部連携を確かめないまま刷新すると、後から影響範囲が判明するおそれがあります。

  • 資産の可視化:複雑度や依存関係を地図のように示します。富士通の「ソフトウェア地図」は構造を俯瞰する取り組みです(出典:富士通)。
  • 刷新順の判断:影響範囲と優先度を見て、見積業務のどの部分から段階的に刷新するかを決めます。

資産棚卸しや要件定義を専門家に支援してもらう場合、その費用は一般に200万円から500万円程度になることもあります。

上流工程の精度が足りないと、後工程で手戻りが生じやすくなります。一方で、費用は小さくありません。その費用は、刷新全体のリスクを下げる先行投資として見れば、合理的です。

ポイント

アセスメントでは、見積の計算方法や承認の流れ、他システムとの依存関係が、実際のファイルや資産で確かめられているかが判断の目安です。

要件定義の機能要件と非機能要件

見積管理システムの要件を機能要件と非機能要件に分け、積算ロジックと応答性能を左右に配置した図。
操作で実現することと、システム品質の基準を分けて考えられます。

現状を把握したあとは、新システムが満たすべき要件をまとめます。要件定義は、ベンダーが見積や設計を行うときの基準となる文書です。

要件に曖昧さが残ると、提案を比べにくくなり、開発中の仕様変更や追加費用につながります。そこで、刷新では機能要件と非機能要件を切り分けて整理するのが定石です。

見積管理の機能要件

機能要件は、新しい見積管理システムで何ができるべきかを定めるものです。積算ロジックや承認ワークフローは、現状を再現する面と改善する面の両方から慎重に設計します。

  • 積算ロジック:計算方法を標準化し、同じ結果を再現する
  • 承認ワークフロー:承認段階、差し戻し、代理承認を定める
  • マスタ運用:原価マスタ・単価マスタの更新担当と履歴管理を決める
  • テンプレート:顧客や案件ごとの見積様式を1か所で管理する
  • システム連携:CRM/SFAや会計との二重入力をなくす

閲覧と編集の権限の制御、操作履歴の記録も要件に含めます。各機能は、現状の姿をそのまま再現せず、To-Beの業務プロセスに合わせて設計します。

非効率な運用までそのまま移すと、刷新の効果が損なわれます。このため、現場の業務フローをあるべき姿に再設計し、それを支える機能として要件を組み立てます。

見落としやすい非機能要件

非機能要件は、システムの品質や運用に関する要件です。性能やセキュリティは業務の信頼性を左右するため、機能要件と同じように定めておきます。

  • 応答性能:想定データ件数と同時利用者数を前提に、目標値を定めます。一覧表示や再計算が遅れると、商談の速度に直接響きます。
  • KPI・可用性:見積作成のリードタイムや承認にかかる時間を測り、停止してもよい時間帯と復旧の目標を決めます。
  • セキュリティ:単価や原価などの機密情報について、アクセス制御、暗号化、ログ管理を明記します。

非機能要件の精度は、刷新の成否を左右します。要件定義の段階で言葉にしておけば、提案を比べる軸になり、稼働後の評価基準にもなります。

ポイント

要件定義は、機能と非機能の両方が、ベンダーごとに同じ意味で読める言葉になっているかを見て判断します。

RFP(提案依頼書)の盛り込み項目

要件定義で固めた内容は、RFP(提案依頼書)にまとめてベンダーに提示します。各社から比べられる提案を得るための文書です。

記載が不十分だと、ベンダーごとに提案の前提がずれてしまい、比べられません。見積管理の刷新では、現状の情報と要件、移行の方針までを一貫して盛り込むことが大切です。

RFPの具体的な記載項目

ベンダーが提案を組み立てるには、現状の前提と刷新後の要件の両方が必要です。過不足のないRFPにするため、最低限次の項目を押さえておきます。

  • 現状情報:構成図(ハードウェア・ソフトウェア・連携先の全体像)と現行業務フロー(見積作成から承認・受注までの流れ)、刷新対象と対象外の範囲
  • 要件と目標:機能・非機能要件、刷新後に達成したいKPI
  • データ移行:過去見積データ、原価マスタ・単価マスタの移行方法
  • 進行体制:稼働希望時期と主要日程、自社側の推進体制と役割分担
  • 運用と見積条件:稼働後の運用・保守の範囲と水準、見積の前提と記載粒度

データ移行では、移す範囲だけでなく、移行後にどう検証するかも記しておきます。移行の精度は業務の継続性を左右するため、検証の方法まで決めておく必要があります。

比較しやすい提案を引き出す書き方

提案の様式や見積の記載粒度を指定すると、各社の提案を同じ前提で比べられます。あわせて、初期費用と運用費用を分けて書いてもらい、機能ごとの工数内訳も求めます。

評価の観点とスケジュールも、RFPに記します。また、重視する点を依頼の段階で共有しておけば、質の高い提案を引き出せます。

RFPは依頼文書であるだけでなく、ベンダーとの対話の起点にもなります。そのため、評価基準は提案を受け取ったあとではなく、依頼の時点で共有しておきます。

ポイント

RFPは、現状の情報や要件、データ移行の方法、体制、見積条件がそろい、各社が同じ前提で提案できる状態かが目安になります。

失敗しないベンダー選定の評価基準

刷新ベンダーの評価基準として、同業界・同規模の実績、段階移行の設計力、停止時間の見積り、24時間365日の保守を4つのパネルに示した図。
実績の近さから稼働後の支援まで、評価の視点が並びます。

提案を評価する基準は、刷新プロジェクトの成否を左右します。金額の安さだけで選ぶと、業務特有の要件に対応できず、稼働後にトラブルが頻発することがあります。

客観的な基準を設けて、ベンダーの対応力を多面的に確かめます。そのうえで、移行や運用の経験も評価の対象に含めます。

客観的に見る5つのチェックポイント

刷新ベンダーには、新規開発とは異なる移行や運用の力も問われます。次の5つを基準に、感覚に頼らず各社を比べます。

  • 同業界・同規模の実績:自社と近い業務・規模での経験があるかを確認する
  • 段階移行の設計力:稼働中のシステムを止めずに移行する力
  • 停止時間の見積り:切り替え時に業務が止まる時間を、現実的に算出できる力
  • 24時間365日の保守:稼働後の障害対応を担う体制
  • 品質・セキュリティ認証:ISO9001やISO27001などの取得状況

提案書の記載だけで判断せず、過去の事例や担当者へのヒアリングでも確かめます。とくに段階移行は、提案書の文面だけでは力量が分かりにくい分野です。

一括での切り替えはリスクが高いため、既存システムを少しずつ置き換える設計を提案できるかを、慎重に見極めます。

見積業務特有の評価観点

普遍的なチェック項目に加えて、見積管理に固有の評価軸を持つと、選定の精度が高まります。具体的には、積算ロジックや帳票、連携への理解を確かめます。

複雑な積算ロジックを正確に移せるか、既存の帳票や様式を再現できるかを見ます。さらに、CRMや会計との連携実績も確認し、業務の継続性を評価します。

提案の段階で具体策を示せるかも、信頼性を判断する材料になります。価格や一般的な実績だけでなく、業務固有の軸で評価すると、業務を支える相手を選びやすくなります。

ポイント

ベンダーは、金額の安さだけでなく、段階移行の設計力や見積業務への理解で比べ、提案書の記載を過去事例で裏づけられるかを見て選びます。

まとめ

上流工程は、アセスメント(現状分析AS-IS)、要件定義、RFP作成、ベンダー選定の順で進みます。各工程で認識のずれを抑えておけば、必要な機能を過不足なく実装できます。こうした積み重ねが、刷新の成功確率を高めます。

アセスメントでは、Excel見積が散らばっていることや、積算ロジックが中身の見えない状態になっていることを明らかにします。また、要件は機能と非機能の両面を、To-Be業務に合わせて定めます。

RFPには現行の構成や移行の方針を記し、選定では段階移行と業務固有の対応力を確かめます。既存システムの刷新では、資産把握の正確さと移行設計が成否を左右します。

刷新は、システムを置き換えるだけでなく、見積・積算・原価の業務を再設計する機会でもあります。上流工程に時間をかけると、稼働後の手戻りや混乱を防ぎやすくなります。

自社だけで進めることに不安があれば、専門家の支援も選択肢になります。支援を受ければ、現状分析からRFP作成、ベンダー選定までを体系立てて進められます。

まずは、見積業務の現状を一覧にするところから始めましょう。

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。