既存システム改修の相談ページ｜仕様書がなくても現状を伝えられる質問票へ

既存システム改修の初回相談で、仕様書がなくても現状を伝えられるWeb質問票の設計。画面・操作・困りごと・希望・保有資料を分け、ページとフォーム、受付通知の内容をそろえる方法を解説します。

「既存システムを改修したい方は、仕様書を添えてお問い合わせください」。開発会社のサイトにこの案内だけがあると、日々の仕事では困っていても、資料が手元にない担当者は相談を始めにくくなります。画面を操作することはできても、システムの構造や正式な機能名まで説明できるとは限りません。

仕様書がない段階から相談を受ける開発会社なら、今の画面、困っている操作、残っている資料を、分かる範囲で伝えられる入口を作りましょう。この記事では、開発会社の経営者やWeb担当者に向けて、一つの作業場面を説明する質問票と、その内容をページやフォームへ反映する方法を紹介します。改修方法や受託可否を判定するための技術資料ではありません。

「仕様書不要」の次に、何を話せばよいかを示す

相談ページに「仕様書がなくても大丈夫」と書くだけでは、代わりに何を準備すればよいかが分かりません。まず、自社がどの段階から話を聞くかを確認し、現状の困りごとを整理する相談と、仕様が決まった改修の依頼を読み分けられる説明にします。資料がない相談も受ける方針なら、添付を必須とするフォームが残っていないかを見直します。

ミルプラトーの公開サービスページでは、仕様書がない場合の相談に対して、実現したいこと、困っている作業、現在のシステムを聞く案内があります。また、既存システムの改修は、仕様や利用環境などを確認して対応範囲を伝える説明になっています。相談を始める情報と、改修判断に必要な確認を分ける構成が参考になります。ミルプラトーのシステム開発案内

自社のページでも、最初から調査用の情報をすべて集めようとせず、次の打合せで何を確かめるか分かる質問を選びます。「困りごとを詳しく書いてください」という大きな欄より、どの作業の、どの画面で、何をしている時かを順に聞く方が、業務担当者は説明を組み立てやすくなります。

ただし、相談を受け付けることを、資料がなくても必ず改修できるという約束へ広げません。自社が得意とする対象、現状確認の範囲、追加の調査が必要な場合の進み方を、営業と開発の双方で確認します。サイト上の短い見出しと、担当者が実際に答える内容をそろえることが出発点です。

一つの画面で起きていることから聞く

質問票の中心には、相談者が普段使う画面や帳票を置きます。正式な機能名が分からなければ、「注文を一覧で見る画面」「月末に出す集計表」といった業務上の呼び方で説明できるようにします。入力欄の例も、開発言語やデータベース名ではなく、作業の場面を示すものにします。

次に、その画面で何をしたか、今はどんな結果になるかを分けて聞きます。「集計が使いにくい」だけでは、操作の手間なのか、結果が違うのか、必要な項目がないのかが分かりません。「条件を選んで一覧を出す」「別の表へ転記して集計している」というように、現在の作業を説明してもらいます。

希望する状態は、現状とは別の欄にします。「一回で出せるようにしたい」という希望が書かれていても、現在何回の操作や転記があるかを推測して埋めないようにします。相談者が見た事実、困っている理由、こうなってほしいという希望を分けると、担当者が追加で聞く内容も整理できます。

原因の推測を回答させる必要はありません。「サーバーが古いから遅いと思う」と書かれていたら、推測として受け取り、どの操作で待つのかを別に確認します。Webの質問で技術的な原因まで決めさせると、分からない人が相談を諦めたり、仮の説明が事実として引き継がれたりするためです。

現状画面・困りごと・保有資料の質問票

次の表は、受注一覧の改修を相談する架空の例です。目的は完成した仕様を集めることではなく、相談者が今の仕事を説明できる項目に分けることです。自社の最初の返答に必要な項目を選び、すべてを必須にする表として使わないでください。

聞く項目	架空の回答例	フォームで添える説明	次に確認すること
使っている画面・帳票	受注一覧の画面	普段の呼び名で構いません	対象となる画面や出力
今している操作	月を選んで一覧を出す	操作の順を短く記入	条件と表示結果の関係
困っていること	部門別の合計を別の表で作っている	実際の作業を書いてください	転記する項目と利用場面
変えたい状態	部門別の合計を確認したい	決まった仕様でなく希望で構いません	表示か出力か、使う目的
発生する場面	月末の集計時。ほかの担当者は未確認	頻度や対象は分かる範囲で記入	共通する条件と例外
残っている資料	古い操作手順書あり。仕様書の有無は不明	資料名と分かる状態だけで構いません	現行画面との対応と資料の版

この例では、部門別の合計欄を追加すると決めたわけではありません。集計を画面で見たいのか、別の作業へ渡したいのかによって、確認する内容は変わります。質問票に希望が書かれたことを、そのまま開発する機能の決定として扱わないことが大切です。

「いつから起きているか」も、現象に合う聞き方にします。以前できていた操作ができなくなった相談と、以前から手作業で補っている作業の改善相談では、答えが違います。発生日がない改善相談に日付を必須とすると、相談者が適当な日を入れることになります。「以前から」「時期は不明」など、自社の受付に必要な状態を用意します。

受注一覧画面について操作・困りごと・希望・保有資料の状態を別々に聞く質問票 — 画面と質問項目を対応させた架空例。実在システムの画面、改修仕様、対応実績ではありません。

画面が複数ある場合も、最初から全画面の説明を求めず、代表となる一つの作業を選べる案内にします。その画面から別の画面や帳票へ進む場合は、関係があることだけ記入してもらいます。一つの画面で分かったことを、システム全体の仕様として受け取らないためにも、質問票に対象の範囲を残します。

画面の説明と、画像の提出を分ける

「今の画面を教えてください」という案内は、画面画像の添付を求める意味にも読めます。初回は画面の呼び名や操作内容を文章で聞くのか、画像も受け付けるのかを明確にします。画像がなくても相談できる運用なら、そのことを添付欄の近くに示し、文章だけで説明できる例を置きます。

実画面には顧客情報や社内情報が含まれる場合があります。画像を受け取る場合の共有範囲や方法は、自社の担当者と決めて案内します。ログイン情報を送ってもらえば説明の代わりになる、という作りにはしません。初回の質問票で聞く対象は、相談の概要を理解するための画面と作業です。

公開する入力例には、実案件の画面をそのまま使わず、説明用の架空画面を用意できます。例えば、受注一覧という見出し、月の選択、一覧の領域だけを描き、どの箇所について質問しているかを番号で示します。利用者名や売上の実数を入れなくても、操作と困りごとの関係は説明できます。

相談者が画像を添えた場合でも、画像一枚だけで操作の順番や結果を確定したことにはなりません。「画像のどの箇所が気になるか」「その前に何をしたか」を文章で説明できる欄を設けます。エラーの画像と、追加したい項目のイメージ画像は役割が異なるので、添付の目的も分かる名称にします。

仕様書がなくても、残っている資料の状態は聞ける

保有資料の欄を仕様書だけにすると、操作手順書や帳票の見本、過去の改修メモなどが残っていても、資料なしと回答されることがあります。自社の確認で役立つ資料の種類を候補として示し、持っているか分からない場合も選べるようにします。資料の一覧を作ることと、その場で資料本体を提出することは分けます。

資料には、ある・ないのほかに、古いかもしれない、所在を確認中、社外共有の可否を確認中といった状態があります。「古い操作手順書がある」という回答なら、現行の画面と一致するとは扱いません。作成時期や対象が分かる範囲で記入できる補足欄を用意し、不明な版を最新資料として通知しないようにします。

For fの既存システム改善・連携の案内では、要件が決まっていない段階の相談と、既存環境や資料・利用権限などを確認して対応範囲を案内する説明が分けられています。相談の段階で分かることを聞き、必要な確認を次へつなぐ構成です。他社の対応条件を、そのまま自社の受付条件にしないことが前提になります。For fの既存システム改善・連携の案内

資料の有無で表示を切り替える場合は、「不明」を選んだのに添付が必須になるといった矛盾を点検します。「手順書あり」を選んだ後、確認画面で「仕様書あり」とまとめられていないかも確認します。項目を短くするために、違う資料や状態を同じ意味へ置き換えないことが重要です。

質問票の正本を決め、ページと通知をそろえる

相談項目を見直す時は、Web担当だけで質問を増やさず、営業と開発担当が最初の打合せで何を確認するかを持ち寄ります。そのうえで、現状画面、操作、困りごと、希望、資料の状態という項目ごとに、掲載する質問文と回答例を一つの資料へまとめます。これをWeb上の説明を更新する際の確認元にします。

確認元には、項目名、説明文、必須か任意か、未回答・不明をどう扱うか、確認する担当を記載します。内部で使う専門用語と、相談者へ見せる言葉が異なる場合も対応を残します。担当者が替わっても、「現状の操作」を「追加したい機能」へ勝手に変えないための資料です。

その質問が表示される場所も整理します。既存改修のサービスページ、よくある質問、相談フォーム、入力確認画面、担当者への通知が主な確認先です。「仕様書がなくても相談可」という説明を残しながら、フォームだけが詳細設計書必須になっていないかを横断して見ます。電話相談の案内でも、同じ項目名を使えるか確認します。

通知では、現在の状態と希望を別の見出しにし、資料の名称と状態を組にして渡します。未回答を「資料なし」に変えたり、原因の推測を「原因」に短縮したりすると、画面で分けた意味が失われます。受付担当が追加の質問を考えられる形で情報を渡すことまで、改修の依頼範囲に含めます。

仕様が分からない人のケースで、案内を確認する

公開前には、業務の説明はできるが仕様書の所在が分からない人を想定し、質問票を読んでみます。正式な画面名を知らなくても答えられるか、希望する結果だけ書いて現状が抜けないか、不明な項目のために入力が止まらないかを確認します。技術に詳しい担当者だけでなく、日常の作業を説明する立場から点検することが大切です。

次に、古い手順書がある相談と、画像を添付しない相談で確認します。資料の状態が確認画面にも残るか、文章だけの説明でも次の連絡へ進める案内かを見ます。スマートフォンでは、回答例が入力欄から離れすぎていないか、記入後も質問の見出しを読めるかを確かめます。

送信完了後は、現状の相談を受け付けたことと、担当者が次に確認する内容を案内します。質問票の回答だけで改修内容、費用、着手時期が確定するように見せないことが必要です。通知の到着や内容を確認する際は、許可されたテスト環境で架空の回答を使い、入力した区別が受信側にも残るかを点検します。

既存システム改修の相談ページは、仕様書を持つ人だけの入口にする必要はありません。自社が受け付ける相談の範囲を確認したうえで、一つの画面で起きていることから話せる質問を用意します。現状、希望、資料の状態を混ぜずに引き継ぐ設計が、次の確認を始めるための手掛かりになります。