プロダクトづくりが、画面の実装だけでは終わらない理由

この記事は2026年10月23日時点の問い合わせフォームと流れを記録しています。現在の委託範囲はグラフィックデザイン、UI/UX、フロントエンド開発で、確認した範囲に応じて見積もります。詳しくはサービスページをご覧ください。

協業相談フォームには、名前、Email、いくつかのテキスト入力欄と送信ボタンがあります。それだけを見ると、単なる画面実装の仕事として説明できそうです。けれども、届けるべきものは部品を並べた画面ではありません。相談する人が現状を伝え、受け取る人が次の一歩を判断できるだけの情報を得られることです。

入力項目で尋ねる内容や、まだ答えがわからなくてもよいこと、送信後のメッセージが何を意味するかによって、必要なやり取りが成立するかどうかが変わります。こうした判断は、画面を実装すれば自動的に決まるものではありません。

ここでは、2026年10月23日時点でこのサイトが使用していた協業相談フォームを例にします。一件の問い合わせがたどる流れに沿って、ページがすでに担っていた部分と、別途確認が必要な受信やその後の対応を分けて見ていきます。

フォームで何をできるようにするのかを先に決める

当時の繁体字中国語版の協業相談ページは、相談前に提案をすべて固める必要はない、という呼びかけを出発点にしていました。それに合わせて、フォームも最初から完全な仕様を求めるのではなく、現在行き詰まっていること、先に進めたいこと、すでにあるリソースや制約を尋ねていました。

単にラベルを親しみやすい表現に変える話ではありません。初回のやり取りでどのような情報を得たいのかを決める話です。まず課題と使えるリソースを知ることで、どの範囲に取り組む価値があるかを話し合えます。

ページでは未整理の要望でも相談できると案内しているのに、入力項目では全員に正確な予算、固定した日程、完全な機能一覧を求めていたら、案内と要求が食い違います。相談する人は無理に何かを選び、受け取る側は、その回答がどこまで確かなのかを推測することになるかもしれません。

そこで、まずはこのやり取りでどの判断を支えたいのかを明らかにし、そのうえで入力項目を見直します。画面に余白があるからといって、集められそうな質問を増やすわけではありません。

必須と任意の区別が、相談を始められる条件を決める

当時のフォームでは、呼び名、Email、行き詰まっていること、先に進めたいこと、すでにあるリソースが必須でした。協業の方向性、参考リンク、時期、予算は任意で、方向性・時期・予算には未定やまず相談したいという選択肢もありました。

各項目は、その後どの仕事に使うのかという観点で整理できます。

情報	支えたい作業	そこから勝手に判断してはいけないこと
呼び名とEmail	相手をどう呼び、どう連絡するかを知る	本人確認済みであることや、メールが必ず届くこと
現状・優先事項・リソース	課題、着手できる範囲、制約を判断する	要件仕様がすべて確定していること
協業の方向性・時期・予算	話し合いの前提を共有する	見積もり、納期、協業がすでに合意されていること

この表は入力項目の役割を整理したもので、ユーザー調査や効果測定の結果ではありません。この必須項目の組み合わせがどの訪問者にもちょうどよいかどうかは、実際の利用とフィードバックで確かめる必要があります。コードに required を付けても、そのプロダクト上の判断の代わりにはなりません。

「未定」も意味のある状態として扱う必要があります。まだ話し合いが必要だという情報なので、後で整理する際に、確定したように見える日付や金額へ黙って置き換えるべきではありません。

画面の入力項目を、実際に送信されるデータにつなげる

このサイトのフォームは、ネイティブの form を使い、POSTで外部のフォーム受付エンドポイントに送信する実装でした。表示上のラベルと入力コントロールは対応付けられ、各項目には name も残されていました。たとえば、stuckPoint、firstPriority、availableResources です。そのため、画面上の質問は単に配置された文言ではなく、送信データの項目名と対応していました。

変更するときも、この関係を一緒に守る必要があります。たとえば質問の文言を「先に何を完成させたいですか」に変えても、受信側が回答をプロジェクト全体の仕様だと解釈し続ければ、画面が崩れていなくても引き継ぎはずれてしまいます。

ブラウザー標準の required と type="email" は、必須項目の入力や形式をブラウザーが先に確認するために役立ちます。ただし、送信者の本人確認や、そのメールアドレスに届くことの検証ではありません。MDNも、ブラウザー側の検証はサーバー側のデータ検証やセキュリティ確認の代わりにはならないと明記しています。[4]

受信を外部サービスに任せることは、実装上の境界を設けることです。検証、通知、その後のデータ利用の責任まで消えるわけではありません。サービス側を確認していないなら、その結果は未確認のまま扱うべきで、HTML属性から推測して埋めるべきではありません。

成功メッセージが示せるのは、ページが実際に把握していることだけ

当時のフォームは送信後に協業相談ページへ戻り、form=success または form=error で表示する状態を選ぶ設定でした。ページのスクリプトはsuccessを読むとフォームを隠して成功メッセージを表示し、errorを読むと失敗メッセージを表示していました。

ただし、この画面上の判断はURLパラメーターを読んでいるだけでした。form=success を付けた協業相談ページを直接開いても同じ状態になる仕組みであり、それによってページ自体が検証済みの受信証明を得ていたわけではありません。

「成功メッセージが表示された」「外部サービスが受信した」「通知メールが届いた」「担当者が内容を読み、返信の準備をしている」は、それぞれ分けて確認しなければなりません。読み取りだけの確認でわかるのは、ページが成功や失敗をどう表示するかです。それだけでサービス側や受信者の状態まで証明することはできません。

この記録のためにテスト用の問い合わせを実際に送信したわけではなく、サービス側の受信データやEmailも確認していません。ここで説明できるのは、当時のページが何を根拠に状態を判断していたかです。送信経路全体を確かめるには、許可を得たテストで、識別できる一組のテストデータが実際に届いたかどうかを照合する必要があります。

JavaScriptが無効でも、ネイティブのフォームには送信のためのHTML構造が残っていました。ただし、URLパラメーターに応じたこの結果表示の切り替えはスクリプトが担っていました。「client-onlyのフォームではない」ことを、JavaScriptなしのフィードバックまですべて実装済みだという意味に広げてはいけません。

初版では一部の作業を成立させ、全工程が自動化されたとは扱わない

このサイトの例は、プロジェクト管理システムではありませんでした。フォームは協業相談を集めるためのもので、ページの文言では、内容を読み、Emailで返信することが案内されていました。それは、システムが自動で見積もりを出し、日程を組み、協業を約束できるという意味ではありませんでした。

初版の目的が双方の話し合いを始められるようにすることなら、完成して見せるためだけに、根拠のない即時見積もりや納品状況の自動表示を先に加える必要はありません。ただし、受信後に誰が対応するのか、返信前に何を確認するのかという責任は明確であるべきです。管理画面として描かれていないからといって、省いてよい仕事ではありません。

初版は、一件の問い合わせがこの範囲の作業を最後までたどれるかで見ます。相手が何を書けばよいかを理解し、データが識別できる項目名で送信され、結果表示が証拠の範囲を超えず、受け取った人が次にどう進めるかを把握できるかを見ます。人の手が必要な箇所や未検証の箇所は、それぞれの場所で明らかにしておきます。

これも、画面の外にあるプロダクトの仕事です。すべての役割をフロントエンド開発者一人で引き受けるという意味ではありません。作業が依存する判断を洗い出し、責任と情報を持つ人に確認を求めるということです。そうしなければ、完成したように見えるフォームが、本来扱うべき問題を一段階先へ送っただけになりかねません。

出典

[4] https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Forms/Form_validation — MDN — Client-side form validation