要件定義は、必要な情報や機能、使う条件、作る範囲、完成の確かめ方を決める作業です。最初から難しい技術仕様を書く必要はありません。会社が「何を実現したいか」を説明し、制作担当と「どう作り、どう確かめるか」を詰めます。

架空の設備点検会社では、初めて依頼する施設担当者が、自分の設備を点検できるか、見積もり前に何を準備するかを知り、相談を送る場面を考えます。会社側は、設備の種類と希望内容がわかる相談を受け取り、受付担当が対応することを目指します。問い合わせ数の増加を保証する例ではありません。

「問い合わせを増やす」は会社の目標になり得ますが、そのまま完成条件にはなりません。訪問者の目的、必要な情報、行う操作へ分けると、サービス説明、準備物、相談の入口が必要だと説明できます。アクセスを集める施策と、サイトの制作完了を分けてください。

訪問者の用事は、実際の問い合わせ、担当者が聞かれる質問、既存資料などから確認します。まだ証拠がない場合は仮説と書きます。GOV.UKの資料は利用者の目的から考える方法を説明しますが、ここでの会社サイトの依頼表は本稿の提案です。

この章の根拠：出典1出典5

サイト構成は、どのページをどの順で辿れるようにするかの設計です。点検会社なら、トップ、サービス、準備案内、会社情報、問い合わせが候補になります。一つのページへまとめるか分けるかは、情報量と訪問者の探し方で相談します。

機能要件は「相談を送れる」「担当者が原稿を変えられる」のような仕事です。非機能要件は、使う環境、表示や応答、情報管理、復旧など、仕事が成立する条件です。用語を覚えるだけでなく、「スマートフォンで対象を読める」「エラー後に入力を直せる」と具体化します。

CMSは文章や画像を管理画面から更新する仕組みです。自社が受付時間を変更したいなら、どの欄を誰が編集できるかを条件へ入れます。会員登録、決済、サイト内検索は、その利用場面がなければ今回の範囲から外せます。追加したいものは後の候補として分けてください。

リニューアルでは既存のページとURLを一覧にし、残す、直す、統合するなどの扱いを確認します。見た目の変更だけでURLを変える必要はありません。変更が必要な場合の転送や内部リンクも制作範囲へ含め、無関係な場所へまとめて移す案を避けます。

この章の根拠：出典1出典2出典7

フォームの欄には、何を書くかを示すラベル、必須かどうか、書式や補足を用意します。「設備名」の意味が訪問者にわからない場合は、例や不明な場合の書き方を示します。入力欄の中の薄い文字だけに説明を任せず、入力後も読める表示を検討します。

必須欄が空なら、不足している欄と直し方を知らせる必要があります。送れた場合は、送信を受け付けたことと次の案内を示します。「送信完了」という画面が出るだけで、会社側の通知や保存が正しいとは限りません。制作担当と会社の受付担当が別に確認します。

通知先、保存先、参照する人、保存期間や削除の手順、返信窓口は、使う製品と会社の管理方針へ合わせて決めます。法律や契約上の対応が関係する場合は担当者が現行の条件を確認します。本稿の例を、そのまま法的な十分条件として使わないでください。

完成条件は「テスト用の相談を送ると、完了案内を読み、合意した通知先で内容を確認できる」「必須欄が空なら該当欄と直し方がわかる」と書けます。実顧客への連絡ではなく、許可されたテスト入力と確認先を使います。受付担当が休みの場合の扱いも運営条件へ含めます。

この章の根拠：出典3出典4

会社は、サービスの事実、対象外、公開できる実績、連絡先を確認します。制作担当は、構成と画面案、実装と確認方法を提案します。写真撮影や原稿作成を頼む場合は、その仕事も見積もりに含めるかを決めます。素材がない状態を「会社が用意」とだけ書かないでください。

費用の比較では、設計、デザイン、実装、フォーム、原稿・素材、移行、試験、操作説明がどこまで入るかをそろえます。公開後はサーバーやドメインの更新、追加製品、訂正、保守、障害時の対応が別に発生する場合があります。金額は個別の見積もりと現行契約で確かめます。

日程は公開希望日だけでなく、原稿と写真を出す日、画面案を確認する期間、修正、試験、公開後の確認を含めます。架空の「今月末希望」は見積もりの条件で、制作可能という回答ではありません。素材が遅れた場合や機能が追加された場合の扱いも相談します。

保守の担当には、更新できる範囲、ソフトウェアの更新、バックアップ、復旧を尋ねます。データベースは記事や設定などのデータを保存する場所です。WordPressの復旧ではファイルとデータベースが関係するため、画像だけを保管した状態をサイト全体のバックアップと思わないでください。

引き継ぐものは、原稿、素材、ファイル、必要な操作説明、契約の管理情報、確認記録です。認証情報そのものを一般の依頼表へ記載せず、権限のある管理者間で扱います。契約終了時の移行条件も、発注前に確認できます。

この章の根拠：出典5出典6

「使いやすい」「速い」「スマホ対応」は、そのままでは担当者が同じ結果を判定しにくい言葉です。対象のページと端末、操作、期待する結果をそろえます。数値の性能条件が必要な場合は、計測方法と環境を制作担当と合意します。根拠のない秒数を一律に書きません。

点検会社の例では、スマートフォンで対象設備を探し、準備案内から問い合わせへ進みます。文字を拡大しても重要条件を読めるか、キーボードで必要な操作に到達できるかも試します。簡単な点検だけで、すべてのアクセシビリティを証明するわけではありません。

結果の欄は、未実施、確認できた、不具合ありと区別します。たとえば「テスト送信は画面の完了まで確認。担当者への通知は未確認」なら、フォーム全体を完成としません。誰がどこを調べるかを添え、修正後に同じ手順で再確認します。

追加の希望が出た場合は、元の目的に必要か、今回の範囲を変えるかを話し合います。変更した条件、費用と日程への影響、確認する担当を依頼表へ反映します。発注した時の表を固定して、途中の合意だけを口頭に残さないでください。

画面の完成例だけを採用記録にしません。受け入れる条件と、実際の確認結果を別の欄にし、未確認の通知や復旧はそのまま残します。試験で新しい不足が出たら、範囲・費用・日程のどれを変えるかを制作担当と照合してください。

この章の根拠：出典2出典4

点検会社の完成する依頼表は「設備の対象と準備を読んで相談できる。ページと受付を作る。素材は会社が確認。完成はスマホの移動、入力修正、担当者への通知で試す。更新・復旧の範囲は見積もりで確認」という内容です。

不明な技術を無理に確定せず、質問として残せます。会社が目的と業務条件を出し、制作担当が実現方法を提案すると、費用と日程を同じ範囲で比較しやすくなります。公開後の成果と制作完了の確認を分けて、運営へ引き継いでください。

この章の根拠：出典1出典2出典5