IT・システム開発会社のWebサイトで見積範囲を伝える｜調査・要件定義・開発・保守を分ける

「新しい業務システムを作りたい。全部込みでいくらですか」。問い合わせを受けた時点では、現行業務の例外、既存システムとの接続、移行するデータ、誰が画面を確認するかも分からないことがあります。それでもサイトに「ご相談から開発・保守まで一括対応」とだけ書いてあると、発注側は最初の相談で全工程の確定見積が得られると受け取りかねません。開発会社側も、説明が足りないまま「概算」を返し、後から対象の違いを説明することになります。

IT・システム開発会社の経営者、営業責任者、Web担当者に向け、調査・要件定義・開発・保守の成果物と確認事項をWeb上で分けて見せる方法を考えます。ここで示す表と相談例は架空です。契約類型や見積条件を一律に定めるものではありません。各社の提供範囲と実際の進め方を営業・開発・保守の担当者で確かめ、掲載文に置き換えてください。

最初に「何の見積か」を選べるようにする

みやあじよのIT・システム開発会社向けページは、業務整理、要件定義、設計、開発、テスト、移行、保守のどこを担うかと、発注側が何を用意・確認するかを分けて示す構成です。相談入口も、新規開発、既存システム、まだ依頼内容が決まらない段階を分けています。この考え方を個別のサービスページへ落とし込む際、工程名の羅列だけでは足りません。各段階で何を明らかにし、何が残るのかを示すと、相談者は今の状態に近い入口を選べます。

例えば「販売管理システムの刷新」を想定しても、現在の業務とデータ構造が整理済みの企業と、古いシステムの資料がなく実態から調べる企業では、最初に必要な仕事が異なります。後者へいきなり「開発費の確定見積」を約束する表現は避け、まず調査で確かめる範囲、調査後に見積対象を定める範囲を説明します。一方、仕様と対象範囲が固まっている相談なら、受け取った資料を基に見積条件を確認する、と書けます。同じフォームへ誘導するとしても、入口の説明を分けることが大切です。

見積の呼び方も社内で揃えます。「初回の参考価格」「前提を置いた概算」「対象と成果物を明示した見積」は、読み手が期待する精度が違います。数値を掲載しない場合でも、どの時点の情報を基に算出するか、含めていないものは何か、次に何を調べると範囲を更新できるかを示せます。「無料相談で正式見積を即日回答」といった実態に合わない約束を加える必要はありません。

成果物表で、工程と発注側の確認を対にする

以下は、サイトの「開発の進め方」または「見積について」に載せるための架空の編集例です。成果物の名称や順序は会社・案件ごとに変わります。表の目的は契約書を代替することではなく、相談時に何が分かっており、何がまだ未確定かを見えるようにすることです。

段階	Webに示す成果物の例	発注側に確認してもらうこと	見積の説明で分けること
現状調査	業務・既存環境の確認結果、未確認事項一覧	現行資料、利用者、困っている場面、調査できる環境	調査自体の範囲と、調査後に決める開発対象
要件定義	対象業務、必要機能、連携・制約、優先順位の整理	業務上の判断、対象外にする作業、関係部門の合意	要件をまとめる作業と、その後の開発見積
設計・開発・検証	画面・処理の設計資料、動作する成果物、確認結果	仕様確認、テスト用情報、受入時の確認方法	開発・テスト・移行をどこまで含むか
運用開始後	引継ぎ資料、問合せ先、保守対象の一覧	管理者、連絡経路、変更依頼の窓口	保守、運用作業、追加開発を同じ費用と見なさないこと

架空の開発相談で現状調査、要件定義、開発と検証、運用開始後の成果物と見積範囲を分ける図 — 架空の開発相談を段階で分けた図です。実案件の契約内容や費用を示すものではありません。

表を作る時は、「当社が実施する作業」の列だけを埋めないでください。発注側の担当者が業務上の優先順位を決める場面、確認に必要な資料を渡す場面、利用部門が画面を試す場面が抜けると、工程表はあっても進め方が伝わりません。逆に、すべてを発注側の責任として列挙する表も相談の妨げになります。どの判断を誰と一緒に行い、会社が何を支援できるかを平易に書きます。自社で担わない調査や移行があれば、表から消すのでなく「対象外」「別途確認」と示します。

成果物を細かく書きすぎる必要もありません。サービスページでは、相談者が「この段階まで依頼できるか」「次に何を渡せばよいか」を判断できる粒度に抑えます。具体的な納品物や確認方法は、案件ごとの提案書や見積書で確定します。汎用の工程図を公開し、実際にはチームや開発方式によって成果物が異なるなら、図に「一例」と入れて誤認を防ぎます。

調査を開発費の中へ黙って埋め込まない

既存システムの刷新では、画面だけを見ても内部処理やデータの状態は分かりません。IPAのモデル取引・契約書の見直し資料は、再構築で要件定義に入る前の現行システム調査に時間と費用がかかる点を挙げています。サイトでこの資料を根拠に使うなら、「刷新なら必ずこの順で契約する」という決め付けではなく、現行調査が見積の前提を明らかにする場合がある、という説明に限ります。

Webページには、調査前に分かることと、調査しなければ答えられないことを並べると有用です。例えば相談者が現在の利用人数、主な業務、画面一覧を持っていれば、相談の入口で共有できます。しかし、実際のデータ量、外部連携の仕様、変更されていない旧機能、移行時の停止可能時間などは別に確認が必要かもしれません。資料がない状態で「旧システムと同じものを新環境に移す」と言われた時には、同じの意味を調べる作業がある、と説明します。

調査の結果、当初想定より対象が広いことも、逆に使わない機能を外せることもあります。Web上で強調すべきなのは値上がりの可能性だけではなく、調査によって何が判断できるようになるかです。「調査結果と未確認事項を共有し、対象と優先順位を協議した後、開発範囲の見積を提示します」のように、成果物と次の判断をつなげます。調査の有償・無償、期間、報告形式は会社の実際の運用を確認してから掲載します。

新規開発でも、相談時に業務の目的がまだ抽象的なら、要件を整理する支援と、決まった要件を実装する仕事を分けて見せます。例えば「紙の申請をなくしたい」という相談では、申請者、承認者、例外、記録の保存期間などを聞いて初めて必要な機能を絞れます。Webの説明は機能一覧を先回りして約束するのでなく、何を聞き、何を整理し、誰と判断するかを示します。

要件定義の成果物を、開発開始の判断につなげる

「要件定義を行います」と書いても、発注側には何を受け取り、いつ開発の話へ進むか見えません。ページでは、対象業務、利用者、必要機能、外部連携、制約、優先順位、未決事項など、会社が実際に整理する項目を例示します。書類の名称よりも「何を決めるための資料か」を添えます。例えば業務の流れを描く資料は、部門ごとの例外を見つけ、対象外の作業を決めるために使う、と説明できます。

確定していないものも残せます。公開ページに「すべての要件を初回打合せで確定」と書くと、難しい相談ほど期待とのずれが生まれます。優先順位が決まらない機能、他社サービスの仕様確認待ち、移行データの品質確認待ちなどは、提案時に前提や保留事項として記録する運用を紹介します。後に変更が生じた場合、何を再確認するかまで触れれば、「見積後の変更は一切できない」という誤解も避けられます。ただし、変更手続や費用の扱いを一般論で断定せず、自社の提案・契約内容で定めます。

IPAは情報システム・モデル取引・契約書を公開し、開発における役割分担や段階ごとの検討に使える資料を示しています。この記事の表はその契約条項の要約ではありません。Web担当が掲載する項目を決めるための例であり、法的な義務の解説ではありません。契約文面に関わる表現は、担当部署・専門家と照合します。

開発・テスト・移行を「一式」で隠さない

要件が見えてきた後も、開発と検証と移行では作業の性質が違います。画面と機能を作る範囲、既存データを新環境へ入れる範囲、発注側の受入確認を支援する範囲を、サイトの例示で分けます。すべての会社が同じ作業を提供するわけではありません。「開発一式」という表記だけでは、データ移行や利用者向け説明まで含むのか、相談者には判断できません。

たとえば既存データに同じ顧客が複数の表記で登録されている場合、移行用の変換作業と、どの情報を正しいと扱うかという業務判断は別です。開発会社が技術的な移行を行える場合でも、内容の意味を一方的に決められません。サイトには「移行対象と現行データの確認方法は個別に相談」と置き、確かめる資料の例を添えられます。実際に引き受けない作業を、説明を充実させるためだけに追加しないことが前提です。

検証についても「テスト実施」だけでは対象が曖昧です。会社側の動作確認、発注側の業務確認、外部サービスとの接続確認は目的と参加者が異なります。サービスページでは詳細なテスト仕様を書くのではなく、「誰が何を確認した段階で次へ進むか」を一文で示します。公開前の説明と、提案書に落とす個別条件を分けておくと、営業資料とも整合します。

成人開発担当者二人が無記名の工程カードと空白のノートを見ながら相談範囲を確認する場面

保守は見積の末尾に一語だけ添えない

運用開始後を説明する欄では、「保守対応可」の一語と月額の有無だけで終わらせないようにします。問い合わせの受付、障害時の調査、定期作業、機能追加の相談では、担当者も作業量も変わります。どの窓口へ連絡し、最初に何を確認し、追加の開発相談はどこへ進むかを、現行の提供内容に沿って短く示します。保守契約の詳細をコラムで決める必要はありません。

既存の保守範囲の記事は運用開始後にどの作業を扱うかに焦点を当てています。本稿では、初回の見積相談で「保守まで一括」と誤認されないために、開発後の別段階として表に置きます。保守費、クラウド利用料、ライセンス料、追加改修費が別の主体・別の時期に生じるなら、その関係を各社の説明に合わせて確認します。具体的な費用を持たないまま架空の金額を掲載しないでください。

相談フォームは「未定」を受け止める

見積範囲を丁寧に説明しても、問い合わせフォームで詳細な仕様書の添付を必須にすると、まだ課題しか分からない相談者は止まります。入口では「新規開発を検討中」「既存システムの刷新・改修」「依頼範囲が未定」など、状態を選べるようにします。現時点で答えられる内容として、目的、困っている業務、希望する時期、既存システムの有無程度から始め、図面や機密資料が必要になるタイミングは個別に案内します。

既存の引継ぎ相談フォームの記事は、初回の概要と、その後に安全に受け取る資料を分けることが中心です。本稿はフォームの入力項目や受渡し方法そのものではなく、相談者の状態と見積対象をページ上で対応させます。フォームへ入る直前に「現時点で仕様が未確定でも相談できます」「調査が必要な場合は、確認する対象を相談時に整理します」といった自社の実態に合う文を置くと、何を送れば話を始められるか伝わります。

送信後の案内も、いきなり見積提示を約束しない文面にします。誰が確認し、最初の返答で何を聞くか、資料の受渡しが必要ならどの段階で案内するかを実務と合わせます。個人情報や機密情報の扱いは、フォーム運用と自社の方針に従って確認します。公開ページに内部の詳細な調査手順や顧客の固有情報を書かずとも、相談の順序は説明できます。

公開前に、営業・開発・保守の言葉を照合する

ページ案ができたら、架空の問い合わせを一件通して読みます。「古い販売管理システムを刷新したいが資料が少ない」という相談者が、どこから始められ、調査で何を受け取り、いつ開発見積の範囲が分かるかを追います。営業担当には初回返答の内容、開発担当には工程と成果物、保守担当には運用開始後の窓口を確認してもらいます。ページの文言だけが先行し、実際の提案書や相談対応とずれないようにします。

スマートフォンでは、工程表が横へ動かせるか、列見出しが読めるか、表の前後の説明で要点をつかめるかを確かめます。表だけが画像で載っていると文字を拡大しにくく、更新も難しくなります。本文の表で見積対象を説明し、図解は段階の関係を補う役にします。相談CTAは各段階の説明から突然別のサービスへ飛ばず、対象のIT・システム開発会社向けページへつなぎます。

公開後に実際の問い合わせで「調査も開発費に含むと思っていた」「保守の範囲が分からない」といった質問が出れば、説明不足の箇所を見直せます。質問を記録しても、改善率や受注数を測っていないうちは成果を断定しません。まず一つの提供サービスについて、成果物と発注側の確認、見積が更新される段階を現行資料と突き合わせることから始めてください。