LASSIC Media らしくメディア
アンケートシステム・Webフォーム開発を外注
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- アンケート・Webフォームシステムは、既製フォームSaaSと違いデザイン統一や基幹連携など自社仕様の要件次第で構築方式の判断が分かれます。
- Webフォームで氏名や連絡先といった個人情報を取得する場合、原則として利用目的の明示が必要だと個人情報保護委員会は説明しています。
- 回答者認証やスパム対策、条件分岐、多言語対応といった運用機能をどこまで組み込めるかが、外注先選定の分かれ目になります。
目次
アンケートシステム・Webフォームとは——顧客満足度調査から社内調査まで対応する仕組み
アンケートシステム・Webフォームシステムとは、質問項目の作成から配信、回答の収集、集計までを一つの仕組みで行うツールを指します。顧客満足度調査(CSAT)や申込受付、問い合わせ窓口、社内アンケートなど、法人における利用場面の幅広さが特徴です。既製のフォームサービスでも簡易なアンケートは作成できますが、条件分岐や大量配信、基幹システムとの連携が絡むと、自社仕様での構築が検討対象になってきます。
この一連の流れのうち、既製サービスが得意とするのは作成から回収までの部分です。一方で回収後のクロス集計や、基幹システムへのデータ連携まで一気通貫で設計しようとすると、パッケージ選定やスクラッチ開発による作り込みが必要になる場面が出てきます。総務省が公開する電子アンケートシステムの手引きでも、システム導入時にはセキュリティ対策や個人情報保護の手続きをあわせて検討する必要があると説明されています*3。
用途の広さも自社構築を検討する理由の一つです。顧客満足度調査やNPS(ネット・プロモーター・スコア)のような定量指標の収集、申込・問い合わせフォーム、社内向けの意識調査など、目的によって必要な質問形式や集計の粒度は異なってきます。
既製フォームSaaSと自社構築の違い——デザイン統一・データ管理・基幹連携で分かれる判断
既製のフォームSaaSは、アカウントを作成すればすぐに質問項目を並べられる手軽さが特長です。ただしテンプレートの範囲内でしかデザインを調整できなかったり、回答データの保存先がサービス提供元のサーバーに限られたりする制約が伴う場合があります。多数の拠点や顧客層に向けて統一されたブランドイメージで配信したい企業にとっては、この制約が課題になることがあります。
自社構築を選ぶ理由として挙がりやすいのは、次の4点です。第一に、企業サイトと同じデザイントーンでフォームを表示できる点が挙げられます。第二に、回答データを自社のデータベースで保有し、アクセス権限やログを自社の基準で管理できます。第三に、CRMやSFAなど既存の基幹システムとAPI連携させ、回答をそのまま顧客管理に反映できる点です。第四に、大量配信やキャンペーン時の同時アクセスといった負荷条件に合わせて、インフラを設計しやすくなります。
自社構築には、パッケージ製品を導入する方法と、要件に合わせてスクラッチで開発する方法の二通りがあります。パッケージは導入期間を短縮しやすい一方、独自の条件分岐や特殊な集計ロジックには対応しきれないケースもあります。スクラッチは要件への適合度が高くなる分、設計から運用まで踏まえた計画が必要です。
| 項目 | 既製フォームSaaS | 自社構築（パッケージ／スクラッチ） |
|---|---|---|
| デザインの自由度 | テンプレート範囲内での調整が中心 | 自社サイトのトーンに合わせて設計できる |
| データの保有先 | サービス提供元のサーバーに保存 | 自社基盤で保有し管理権限を持てる |
| 基幹システム連携 | 連携アドオンの範囲に依存する | CRM・SFA等とAPIで柔軟に連携できる |
| 条件分岐・集計の自由度 | 標準機能の範囲に限られる | 要件に合わせたロジックを組み込める |
| 導入までの期間 | 短期間で利用を開始できる | 要件定義から開発までの計画が要る |
フォームビルダーと条件分岐（ロジック）——回答内容に応じて質問を出し分ける仕組み
フォームビルダー——質問項目をドラッグ操作で組み立てる機能
フォームビルダーとは、単一選択・複数選択・自由記述・マトリクス形式といった質問タイプを画面上で組み合わせ、コードを書かずにフォームを組み立てる機能です。担当者が入れ替わっても運用を引き継ぎやすくなるよう、管理画面の使いやすさも設計時の検討項目になります。
条件分岐（スキップロジック）——回答に応じて次の質問を変える仕組み
条件分岐は、ある質問への回答結果に応じて次に表示する質問を変える仕組みです。たとえば顧客満足度調査で「不満」を選んだ回答者にだけ理由を尋ねる自由記述欄を表示したり、申込フォームで法人と個人とで必要な入力項目を出し分けたりする用途に使われます。既製サービスでも簡易な分岐は用意されていますが、複数条件を組み合わせた分岐や、他システムの情報を参照した分岐までは対応範囲外になっている場合があります。
入力のしやすさも回収率に直結します。W3Cのアクセシビリティ推進部門であるWAIは、フォーム項目にlabel要素を関連付けることや、関連する項目をfieldsetでグループ化すること、入力の指示をあらかじめ示すことを推奨しています*2。スクリーンリーダーを使う利用者だけでなく、あらゆる回答者にとって迷いにくい画面設計につながる考え方です*2。
回答収集後の集計・クロス集計とBI連携——データを活用できる形に変換する
回答を集めるだけでは、施策への反映にはつながりにくいものです。単純な件数や比率の集計に加え、回答者の属性(部署・拠点・利用サービスなど)ごとに傾向を比較するクロス集計まで見据えて、質問設計と回答データの持ち方を検討しておく必要があります。
顧客満足度調査でよく使われる指標にNPSがあります。NPSは「この製品・サービスを友人や同僚に薦める可能性はどのくらいか」を0〜10点で尋ね、9〜10点を付けた推奨者の割合から0〜6点を付けた批判者の割合を差し引いて算出する指標です*5。2003年にベイン・アンド・カンパニーのフレッド・ライクヘルドらが提唱した手法とされています*5。CSAT(顧客満足度)とあわせて経年で追いかけたい場合、集計ロジックをシステム側に組み込んでおくと、都度の手作業を減らせます。
集めたデータの活用先も設計段階で押さえておきたいポイントです。CSV出力やAPI連携でBIツールに回答データを流し込めるようにしておけば、他の指標と突き合わせた分析がしやすくなります。未回答者への自動リマインド配信や、回答完了時の担当部署への通知といった機能も、回収率と対応スピードを左右します。
個人情報の取扱いとスパム・bot対策——アンケート・Webフォーム特有の留意点
アンケート・Webフォームでは、氏名や連絡先といった個人情報を入力してもらう場面が少なくありません。個人情報保護委員会のFAQでは、申込書やホームページ上の入力画面で連絡先を記入させる場合、原則として利用目的の明示が必要だと説明されています*1。一方で、取得の状況から利用目的が明らかな場合(申込内容の確認や結果通知のみに使う場合など)は、例外的に明示が不要になるとも述べられています*1。
総務省が公開する電子アンケートシステムの手引きでも、個人情報を取得する際は利用目的や利用範囲を明確にし、その範囲内で利用することが求められると整理されています*3。回答者から得た情報を社内でどこまで共有するのか、保管期間をどう定めるのかといった運用ルールは、システム構築と並行して詰めておく事項です*3。
もう一つの留意点が、不正な回答やスパムの混入を防ぐ仕組みです。GoogleのreCAPTCHAは、利用者に追加操作を求めずに0.0〜1.0のスコアで不正の疑わしさを判定し、そのスコアをもとに通過の基準を決めたり追加の確認を挟んだりできる仕組みとして提供されています*6。フォームの目的や想定される不正のパターンに応じて、どの程度の判定基準を設けるかを検討することになります。
回答者認証・多言語対応・通知/リマインド——回収率を左右する運用機能
回答者認証も、アンケート・Webフォームシステム特有の検討事項です。総務省の手引きでは、なりすましや重複回答を防ぐ対策として、ワンタイムパスワードや本人確認用の仕組みを組み合わせる例が挙げられています*4。SSLなどの暗号化技術を用いた通信の保護についても言及されています*4。会員向けの継続調査なのか、不特定多数に向けた単発アンケートなのかによって、必要な認証の強さは変わってきます。
海外拠点や外国籍の従業員・顧客を対象にする場合は、多言語対応も設計事項に加わります。質問文や選択肢の翻訳だけでなく、入力欄のラベルやエラーメッセージまで含めて言語を切り替えられる構成にしておくと、回答のしやすさが変わってきます*2。
通知・リマインド機能は、回収率を底上げする実務的な仕組みです。回答期限が近い対象者への自動リマインドメール、回答完了時の担当部署への通知、異常な回答パターンを検知した際のアラートなど、運用フェーズで必要になる機能をあらかじめ洗い出しておくと、稼働後の手戻りを減らせます。
まとめ：アンケート・Webフォームシステム開発で押さえる3つの判断軸
本稿ではアンケート・Webフォームシステムの機能と、開発を検討する際の観点を整理しました。要点は3つに集約できます。第一に、既製フォームSaaSと自社構築の違いは、デザイン統一・データ管理・基幹連携をどこまで求めるかで判断が分かれるということです。第二に、フォームビルダーや条件分岐、クロス集計、BI連携といった機能をどこまで組み込むかで、パッケージとスクラッチのどちらが適するかが変わってきます。第三に、個人情報の取扱いやスパム・bot対策、回答者認証は、アンケート・Webフォームに特有の留意点であり、企画段階からの織り込みが欠かせません。
よくある質問
既製のフォームサービスではなく自社構築を検討したほうがよいのはどのような場合ですか。
デザインを自社サイトと統一したい場合、回答データを自社基盤で保有・管理したい場合、CRMなど基幹システムとAPI連携させたい場合、複雑な条件分岐や独自の集計ロジックが必要な場合などが検討のきっかけになります。既製サービスの標準機能で要件を満たせるかどうかを、まず棚卸ししておくことが実務的です。
Webフォームで個人情報を取得する際に確認しておきたい点は何ですか。
個人情報保護委員会のFAQによれば、申込書やホームページ上の入力画面で連絡先を記入させる場合、原則として利用目的の明示が必要です*1。取得の状況から利用目的が明らかな場合は例外的に明示が不要になるケースもありますが、社内での共有範囲や保管期間についても、あわせて運用ルールを定めておくことが望まれます*3。
スパムや不正な回答を防ぐには、どのような対策がありますか。
Googleが提供するreCAPTCHAのように、利用者の操作を増やさずにスコアで不正の疑わしさを判定する仕組みが挙げられます*6。あわせてワンタイムパスワードなどによる回答者認証や、重複回答を検知する仕組みを組み合わせる方法も、総務省の手引きで紹介されています*4。
NPSやCSATのアンケートは、システム側でどのような設計が必要ですか。
NPSは「薦める可能性」を0〜10点で尋ね、推奨者の割合から批判者の割合を引いて算出する指標です*5。継続的に測定して経年で比較する場合は、質問文の表記を変えずに固定し、集計ロジックをシステム側にあらかじめ組み込んでおくと、都度の手作業を減らせます。
アンケート・Webフォームシステムの開発を外注する場合、何を確認すればよいですか。
要件定義から関わってもらえるか、条件分岐やクロス集計といった機能の実装実績があるか、個人情報の取扱いを踏まえた設計に対応できるかを確認します。あわせて基幹システムとの連携方式や、公開後の保守・改修をどこまで依頼できるかも、契約前にすり合わせておきたい点です。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：個人情報保護委員会「申込書やホームページ上のユーザー入力画面で連絡先を記入させる場合、当該連絡先の利用目的を明示する必要がありますか」（よくある質問）（https://www.ppc.go.jp/all_faq_index/faq1-q4-17/）
- *2 出典：W3C Web Accessibility Initiative「Forms Tutorial」（https://www.w3.org/WAI/tutorials/forms/）
- *3 出典：総務省「電子アンケートシステム 3-4 個人情報保護に関する留意点」（https://www.soumu.go.jp/denshijiti/ict/questionnaire/3-4.html）
- *4 出典：総務省「電子アンケートシステム 3-3 電子アンケートシステム活用の際の留意点」（https://www.soumu.go.jp/denshijiti/ict/questionnaire/3-3.html）
- *5 出典：ベイン・アンド・カンパニー「NPS（ネット・プロモーター・スコア）とは？」（https://www.bain.com/ja/consulting-services/customer-strategy-marketing/about-nps/）
- *6 出典：Google Cloud「reCAPTCHA Overview」（Fraud Defense ドキュメント）（https://docs.cloud.google.com/recaptcha/docs/overview）
