社内アンケート集計システムの費用｜匿名回答と少人数集計をどう分けるか

れむ3号： 「匿名だから率直に答えてください」。でも、部署と役職を選んだら自分だと分かりそう。今回はそんな架空の社内アンケートを出発点に、社内アンケート集計システムの費用を左右する条件を考えるよ。僕の暫定結論は、設問数だけでなく「誰に、どの単位で結果を見せるか」を先に決めること。

時任ミライ： 回答を増やしたいという気持ちと、詳しく分析したいという気持ちは、同じ方向を向いているようで少し違いますね。私も、細かく分けられるほどよいと考えかけました。でも、答える側から見れば、その細かさがためらいにつながるかもしれません。

名前を消すだけで、説明は足りるだろうか

れむ3号： 例えば、ある部署に特定の役職の人が一人しかいない、という仮想ケース。名前欄がなくても、部署と役職と自由記述を組み合わせると推測できることがある。「匿名」という言葉だけで設計を終わらせないほうがいいね。

時任ミライ： 一方で、誰も回答者を識別できない仕組みにすると、未回答の人だけへ案内する機能や、本人が回答を修正する方法も考え直す必要があります。安心して答えられることと、運営の便利さ。その境界を、画面を作る前に言葉にしておきたいです。

れむ3号： まずは、識別情報を何のために持つかを分けよう。回答内容と名簿を結び付けるのか、回答済みかだけを管理するのか。管理者が見られる情報、保管期間、削除の対象も同時に決める。ここで方式が変わると、データの持ち方やテストも変わるんだ。

費用が変わるのは、集計の裏側

社内アンケート集計システムの費用を比較するため、ここでは製品価格や確定金額ではなく、見積もり条件を整理する。実際の費用は利用規模、選ぶ製品、連携、運用条件をそろえて確認する必要がある。

決める条件	小さく始める案	個別設計が増える案
回答受付	共通の回答フォーム	部署別配信、分岐、回答修正
利用者管理	管理者が対象を登録	社員情報や社内ログインと連携
結果表示	全体集計を限定共有	部署階層、役職、期間の組合せ
少人数の扱い	定めた人数未満を非表示	差分や絞込みからの推測も検証
自由記述	担当者が確認して共有	伏せ字、分類、確認履歴を管理
継続運用	単発調査	定期配信、過去比較、設問の版管理

時任ミライ： 表を見ると、集計画面よりも、その前後の取り扱いを決める仕事が多いですね。結果を見たい人を増やすだけでも、部署異動後に何を見られるのか、過去の結果も見せるのか、問いが増えていきます。

れむ3号： うむん。例えば「少人数なら非表示」にしても、全体と一部の結果を引き算して残りが分かる場合がある。人数の基準は万能な数字として置かず、公開範囲や絞込み機能とセットで検討したい。画面一枚でも、試す組合せが多ければ確認工数は増えるよ。

既存フォームで試すと、何が分かるか

時任ミライ： 個別開発に進む前に、既存のフォームと手作業の集計で一度試す案もあります。ただし、使うサービスがどの情報を収集し、誰が閲覧できるかは確認が必要です。導入が簡単であることと、運用条件に合うことを分けて見たいですね。

れむ3号： 試行では、回答数だけでなく、質問を読み違えた箇所、自由記述の確認時間、結果を共有するまでの作業を記録する。回答が少なかったとしても、設問が長いのか、目的が伝わっていないのか、取り扱いへの不安なのかは、まだわからないよ。数字だけで意欲の問題にしない。

時任ミライ： その試行があると、開発する理由も変わりそうです。「グラフを自動にしたい」から、「毎回の閲覧範囲の設定を間違えないようにしたい」へ。便利さを求めていたはずが、継続して説明できる運用を求めていたと気づくこともありそうです。

初期費用と、続ける費用を分けて聞く

社内アンケート集計システムの費用は、設計と画面開発だけでは比較しにくい。見積もりには、設問・集計条件の整理、権限設計、連携、データ移行、テスト、利用説明の範囲を分けて記載してもらう。既存データを取り込むなら、古い部署名や設問の変更をどこまでそろえるかも条件になる。

運用側では、サービス利用料や保守に加えて、配信設定、問い合わせ、自由記述の確認、集計条件の変更を誰が担当するかを決める。開発会社の月額費用に、これらの作業がすべて含まれるとは限らない。

れむ3号： 見積もり比較では、同じ仮想データを渡して「何を表示しないか」まで説明してもらうと差を見やすい。通常の回答だけでなく、回答ゼロ、少人数、部署異動、途中取消、自由記述に氏名が入った場合も受入確認の候補になるね。

時任ミライ： 削除も、画面から消えれば終わりとは限りません。出力ファイルや保存済みの集計、バックアップをどう扱うか。運用上の取り決めとシステムでできることを分けて確認すると、あとからの思い違いを減らせそうです。

受け入れ確認を、画面の完成と分けておく

れむ3号： テストの条件も見積もりに入れておきたい。例えば、部署の管理者としてログインした人が別部署の結果をURLの変更で見られないか。画面上で隠れていても、出力ファイルには残っていないか。見せる画面だけを確認すると、出口を見落とすことがあるよ。

時任ミライ： 利用する人の立場で確認すると、完成の意味も具体的になりますね。回答者が途中で保存した場合、再開できるのか。締切を過ぎたら修正できないのか。困ったとき、内容を見せずに問い合わせられるのか。機能の有無だけでは分からない体験があります。

れむ3号： あと、過去比較。設問の文言や選択肢が変わった結果を、そのまま同じグラフにつなぐと意味が変わる。設問ごとの版と実施期間を残し、比較可能なものだけ並べる運用を決めよう。自動で比較する範囲が広いほど、定義と検証の仕事も必要になる。

時任ミライ： 試験用データは架空のものを用意し、期待する表示を事前に合意しておくとよさそうです。完成後に初めて「ここは表示しないつもりだった」と気づくより、見積もり段階で境界を見つけられます。

初回導入の範囲は、ひとつの調査、限られた管理者、決めた集計軸に絞る案も考えられる。ただし、必要な閲覧制御やデータの取り扱いを後回しにする意味ではない。運用に不可欠な条件を満たしたうえで、便利な追加機能を次段階へ分ける。初期費用だけでなく、次に変更する場合の費用と担当も比較に含めたい。

最初の相談では、見たい結果を一枚にする

ドリーミへ開発費用の見積もりを相談する際は、想定人数、実施頻度、設問例、見たい集計、見せたくない集計、利用者の役割、必要な連携を用意すると範囲を整理しやすい。記事下の見積もり案内から、既存フォームを使う案と個別開発する案の比較を含めて相談できる。

れむ3号： 僕なら、最初に欲しいグラフを一枚描いて、その下に「誰が見られるか」「どんなとき非表示か」を書く。全機能を決める前でも、設計の肝が見えてくる。

時任ミライ： 答えを集める仕組みを考えていたのに、最後は、答えてくれる人へ何を約束できるかに戻ってきました。その約束を小さく、具体的にするところから始めたいですね。