システム開発会社の引継ぎ相談フォームを作る｜初回に聞く情報と調査後の確認を分ける

他社が開発したシステムについて相談を受けたいのに、自社サイトには通常の問い合わせ欄しかない。詳しく書いてもらおうと項目を増やすと、今度は相談者が資料や技術情報をそろえられず、入力が止まってしまうことがあります。反対に、自由記述だけでは、対応する営業や開発担当が現状をつかめません。

引継ぎ相談の入口では、初回に聞く概要、後から受け取る資料、調査して初めて回答できることを分けましょう。初回フォームの目的は、次の確認を進めるために現状を把握することです。入力された内容だけで引継ぎや改修を約束する仕組みにしないことが重要です。

この記事は、システム開発会社の経営者と広報・Web担当者に向けたページ・フォームの設計案です。システム資産の権利、契約の解釈、移行の技術的な可否は、それぞれの担当者が個別に確認します。Web上では何を聞き、何を送らないよう案内するかを具体化します。

「相談を受け付ける」と「引き継げる」を分けて案内する

フォームの前には、相談できる対象と、回答までの進み方を置きます。業務システム、Webサービスなどの対象、既存改修や保守の相談に対応する範囲を、実際の事業内容に合わせて示します。「どのようなシステムでも引継ぎ可能」と広く書くより、概要を確認してから調査の進め方を相談する説明が必要です。

相談者が知りたいのは、技術用語の一覧だけではありません。前の開発会社へ連絡できない、担当者が退職した、資料が残っているか分からないなど、今の状態でも話を始められるかです。自社が受け付ける状態を確かめた上で、資料不足の相談も受けるなら、その旨を入口に書きます。

同時に、受付後すぐに作業が始まるような表現を避けます。概要確認、必要な資料と共有方法の相談、調査条件の合意、調査結果に基づく範囲の検討というように、何が次の判断になるかを伝えます。実際の順序や契約の時点は会社ごとに異なるため、自社の担当者と照合して掲載します。

既存顧客の障害連絡と、新規の引継ぎ相談は入口を分けます。今まさに業務が止まっている人が新規営業フォームへ送信し、緊急対応が始まると思ってしまうと、期待と実際の受付がずれます。契約者向けの連絡先がある場合はそちらを案内し、新規相談で受け付ける範囲も明示します。

「相談は無料」と表示する場合は、対象が初回の概要確認なのか、技術調査まで含むのかを確認します。後の工程で費用が発生する可能性があるなら、条件を案内して合意してから進めることを説明します。費用の境界が未確定のまま、入力完了を調査の依頼として扱わない設計にします。

初回は、システムの用途・困りごと・資料の有無を聞く

項目を選ぶときは、回答する営業担当が最初に何を判断するかから考えます。誰が使うシステムか、何に困っているか、今後どこまで任せたいかが分かれば、次に参加する担当者や確認事項を選びやすくなります。最初から構成の詳細やすべての資料を求める必要はありません。

W3Cのフォームに関する資料は、手続きに必要な情報を求め、過剰な入力を避ける考え方を示しています。入力欄のラベル、説明、検証、完了やエラーの通知も別々の要素として扱っています。この考え方を、引継ぎ相談の初回に必要な情報へ絞り込む際の基準にできます。W3Cのフォーム設計資料

以下は架空の受付設計例です。自社の営業・開発担当が実際に使う項目へ調整し、すべてを必須にするための表として使わないでください。氏名や連絡先など返信に必要な基本項目とは別に、引継ぎ特有の情報を整理しています。

例えば、仕様書の欄には「ある・ない・不明・確認中」といった状態を用意します。「ある」を選んだ人に、その場でファイルの添付を必須にする必要はありません。資料があることと、第三者へ渡せる状態であることは別なので、保有状況を確認してから受領の相談へ進めます。

開発言語やクラウドの名称は、相談者が把握している場合に書ける項目とします。分からない人が適当に選ばなくて済むよう、「不明」を選べる形にします。公開サイトのURLを聞く場合も、管理画面のURLや接続先を求める欄と誤解されない説明を添えます。

希望時期は、日付だけでなく理由を任意で聞くと、事情を理解しやすくなります。契約の終了、担当者の退職予定など、決まっている期限と、できれば早く進めたいという希望を分けます。ただし、入力された希望日を自動的に対応可能日として表示しないようにします。

相談者が利用企業の担当者なのか、支援会社として問い合わせているのかも、必要に応じて確認します。返信の窓口と、資料共有や作業範囲を承認する人が異なる場合があるためです。初回は立場が分かる選択肢にとどめ、委任の証明や契約書の提出まで一律に要求せず、後の確認へつなぎます。

認証情報や実データを、最初のフォームへ入れさせない

自由記述欄の直前には、書いてよい範囲を短く示します。「困っている業務と希望を概要でお知らせください。パスワード、APIキー、顧客データ、ソースコードは入力しないでください」といった案内です。ページ末尾だけに注意書きを置くより、入力する場所で確認できる配置を考えます。

ここで重要なのは、禁止事項を長く並べることより、代わりに何を書けばよいかを伝えることです。「ログインできる管理者が社内にいるか」「ソースコードを保有しているか」のように、権限や資料の状態を選べれば、相談者は秘密そのものを送らずに現状を説明できます。

エラー画面の画像を受け取りたい場合にも、表示された氏名、メールアドレス、契約情報などが含まれる可能性を考えます。初回は現象を文章で聞き、画像が必要になった段階で、伏せる箇所や共有方法を案内する設計を検討します。画像の添付を選ぶなら、受領する側で確認と管理ができる条件を整えます。

入力内容をそのまま自動返信メールへ全文掲載するかも確認します。注意書きがあっても、相談者が秘密情報を誤って記入する可能性は残ります。受付番号と受信の案内を中心にするなど、何を返信へ転記するかを決め、担当者への通知と管理画面に残る情報も把握します。

フォームの説明を工夫することと、受信後の情報管理は両方必要です。Web担当者だけで保存や閲覧の条件を決めず、問い合わせを受ける担当、情報管理の担当、制作・保守担当の間で確認します。自社のプライバシー表示と実際の保存先が食い違わないかも点検します。

資料の受け渡しは、必要な範囲と受領先を決めてから案内する

初回に資料を受け取らない設計なら、フォーム近くに「内容を確認後、必要な資料と共有方法をご案内します」と書きます。添付欄がない理由と次の行動が分かれば、相談者が独自の共有リンクや大きなファイルを無理に送ろうとする状況を減らせます。

その後の案内には、対象の資料、受領先、閲覧する担当、共有期限、受領の確認方法を含めます。秘密保持や調査契約の確認が必要な場合は、その手続きを済ませる時点も自社の手順に合わせます。契約書があるだけで、すべての資料を無条件に受領できると見せないことが大切です。

OWASPのファイルアップロードに関する資料は、許可するファイル形式や容量だけでなく、保存場所、利用者の権限など複数の対策を扱っています。添付ボタンを設置して拡張子を制限しただけでは、受領方法を十分に設計したとはいえません。Web担当者は、こうした条件を誰が実装・確認するかまで相談します。OWASPのファイルアップロードに関する資料

資料の共有と、システムへ入るための権限付与も分けます。仕様書を受領したことは、実環境へ接続して調査する許可を得たことと同じではありません。公開フォームでは権限を渡さず、対象の環境、操作範囲、利用期間、担当者を確認する別の手順へ案内します。具体的な方法はシステムの責任者が判断します。

受領を断る資料や、不要になった資料の扱いも案内を準備します。「送れるものはすべて送ってください」という依頼では、必要性が分からないデータまで集まります。まず資料の種類と対象を確認し、不足があれば追加で依頼する進め方にすると、相談者と受領者の双方が共有範囲を把握しやすくなります。

送信完了後は、次の連絡と調査後に決まることを示す

送信完了画面には、受け付けたこと、次に誰が連絡するか、追加資料は案内まで待つことを示します。返信の目安を載せる場合は、自社が守れる営業時間や休業日との関係を明記します。自動メールの到着を、担当者が内容を確認した通知と混同させないようにします。

その場で概算費用を表示する機能を置く場合も、何を前提にした目安なのかが必要です。引継ぎでは資料や権限の状況によって調査範囲が変わるため、情報が足りない段階の数字を確定見積もりとして見せない設計にします。金額を出すことが初回相談の目的に合わなければ、概要確認後の案内を先に整えます。

調査後に確認する事項としては、引き受ける範囲、見積もりの前提、着手時期、追加で確認が必要な点などが考えられます。これらを初回フォームの説明で区別しておくと、「送信したので来月から保守が切り替わる」といった期待のずれを避けやすくなります。

受付対象外だった場合の案内も決めます。対応できないと分かった後に資料を集め続けたり、別の会社へ無断で情報を転送したりしないよう、社内の確認手順とWebの説明をそろえます。紹介を行う運用があるなら、相談者への説明と必要な確認をしてから進める設計にします。

公開前に、資料が分からない人でも相談できるかを試す

画面の点検では、詳しい技術担当者だけでなく、システムを日々使う業務担当者を想定します。用途と困りごとは説明できるが、言語も資料の場所も分からないという架空の相談で、最後まで入力できるかを試します。「不明」を選んだ後に詳細欄が必須になっていないかが確認点です。

次に、資料がある人のケースで試します。「仕様書あり」を選んでも、初回に資料本体やパスワードを求められないかを見ます。自由記述の説明、確認画面、完了画面、自動返信で、送らない情報と次の案内が一貫しているかを確かめます。

入力エラーでは、どの項目をどう直せばよいかが分かること、入力した他の内容が不用意に消えないことを確認します。PCとスマートフォン、キーボード操作でラベルや選択肢が使えるか、問い合わせが担当者へ届き、想定した場所に保存されるかまで検証します。

改修の相談には、現在の問い合わせ画面、よくある引継ぎ相談の概要、初回に必要な情報、後から受け取る資料の種類を用意すると進めやすくなります。実案件の秘密を資料に含める必要はありません。まず一つの架空相談を通して、概要の受付から必要な確認へ進める案内を整えましょう。