XIAOJUSURVEY を自前で運用する前に読む、構成と拡張の実際

XIAOJUSURVEY が埋めようとしている穴は何か

アンケートを取る手段自体はいくらでもある。問題は、設問の種類が増え、表示条件や分岐が絡み、回収したデータを設問単位や属性の掛け合わせで見たくなった時点で、汎用のフォームサービスでは表現しきれなくなることだ。README は内部システムで40種類以上の題型を蓄積し、精选テンプレートを100件以上持つと説明しており、対象として市場調査、顧客満足度調査、オンライン試験、投票、報道、測評といった場面を挙げている。狙っているのは単発のアンケート作成ではなく、調査という業務そのものを社内に一つの基盤として据えることだ。個人でも企業でも、特定領域の調査ソリューションを素早く組み立てられると README は書いている。つまり読者として想定されているのは、既製の SaaS に自社の設問ロジックを合わせる側ではなく、自社の調査フローに合わせて基盤側を曲げたい側である。

Vue3 と NestJS と MongoDB という分割の意味

技術構成は README に明快に書かれている。Web 側は Vue3 と ElementPlus、クロスプラットフォーム SDK は React Native、サーバー側は NestJS と MongoDB。能力拡張として AI による一言からのアンケート生成が挙げられている。ここで実務上効いてくるのは、ビルダーとレンダラーという2つの役割が同じ題型定義を共有する設計だ。README は「所见即所得、搭建渲染一致性高」として、題型を場面ごとに設計し、加工から配信までを高い一貫性で扱うと説明している。設問の表示条件、分岐、選択肢参照、設問参照といったロジックを組めるという記述も、この共有があって初めて成立する。データベースが MongoDB なのは、設問構造が固定スキーマに収まらないことの裏返しでもある。裏を返せば、回答データを SQL で直接集計する運用を既に持っている組織にとっては、ここが最初の摩擦になる。

題型を素材として足す、という拡張の考え方

このプロジェクトで最も特徴的なのは、題型をコードに埋め込まず素材として扱う点だ。README は題型物料化設計として、題型ごとに共通の基礎能力を持たせつつ、原子化された特性能力を持たせ、高度なカスタマイズを保証すると述べている。あわせて《问卷 Meta 协议》と題型物料協議という2種類の標準を定義し、前者を業務記述（问卷協議、題型協議）、後者を物料記述（題型と設定器）と位置づけている。設問の種類を増やす作業が、コアの改修ではなく協議に沿った素材の追加として整理されるわけだ。ただし README はこの拡張の手順そのものを本文には書いておらず、開発手册と工程配置化の文書に委ねている。したがって、独自題型を足すコストを見積もるには、リポジトリのコードではなく公式ドキュメント側の協議定義を先に読む必要がある。ここを読まずに着手すると、後から協議の粒度が足りないことに気づく。

ローカルで動かすまでの最短手順

README はローカル開発の手順を具体的に示している。サーバーは server ディレクトリで npm install のあと npm run local、画面は web ディレクトリで npm install のあと npm run serve を実行する。起動後の入口も明記されており、管理側は http://localhost:8080/management、回答側は http://localhost:8080/render/:surveyPath になる。Node のバージョンはバッジで 18 以上が示されているので、それより古い環境では動かす前に Node を上げる必要がある。デプロイは Docker 化された方案が用意され、イメージは2種類から選ぶ。slim 版は node:18-slim をベースに最小限の依存だけを入れ、本番向けとされる。完整版は node:18 ベースで curl、vim、git などを含み、開発や調査向けとされる。切り替えは docker-compose.yaml のイメージタグを書き換えるだけで、latest-slim と latest-full のどちらかを指定する。

回収データの扱いと分析機能の輪郭

分析側は README によれば、分題統計、交叉分析、多渠道分析といったオンライン帳票能力が、上億量級のデータで磨练されたとされる。データ導出と回収データ管理も機能として挙げられている。ここで注意したいのは、この記述が能力の存在を示すものであって、集計結果の正確さや処理速度を裏付ける数値ではないことだ。どの程度の件数でどの程度の応答時間になるかは資料からは分からない。実運用に載せるなら、分題統計と交叉分析を自社のデータ量で一度回し、遅延と集計結果の妥当性を自分の目で確かめる工程が要る。MongoDB 上での集計になるため、既存の DWH に回答を流して分析したい場合は、README が挙げるカスタム Hook 設定（データ推送集成、消息推送集成）を使って外部へ流す設計になる。分析をどこで行うかを先に決めておかないと、後から二重に集計基盤を持つことになる。

向かないケース、見落としやすい制約

第一に、設問が数問で選択式が中心、回答も数百件という用途には明らかに過剰だ。NestJS のサーバー、MongoDB、Vue3 のフロント、そして React Native の SDK という一式を維持するコストは、その規模では回収できない。第二に、フロントエンドを React で統一している組織にとって、ビルダーが Vue3 と ElementPlus である点は看過できない。埋め込み SDK は React Native とされているが、管理画面のカスタマイズは Vue の知識を要求する。第三に、README はリリースノートも変更履歴の本文も提示しておらず、CHANGELOG は GitHub の issue へのリンクとして示されているだけだ。バージョン間の破壊的変更を事前に把握する手段が薄いので、追従コストは実際に issue を追う前提で見積もるべきである。第四に、README が挙げる安全機能は伝送暗号化、敏感詞ライブラリ、公開審査、投票の刷り込み防止といった項目だが、いずれも機能の存在が示されているだけで、設定方法や既定値は本文には書かれていない。公開審査や敏感詞の設定を運用に組み込めるかは、ドキュメント側で確認するしかない。

SurveyJS や自前実装と何が違うのか

比較対象として分かりやすいのは SurveyJS のようなフォーム構築ライブラリだ。あちらは設問スキーマの JSON を定義し、レンダリングと編集 UI をライブラリとして提供する。アプリケーション側はその JSON を自分で保存し、回答の集計も自分で書く。XIAOJUSURVEY はそこから先、ユーザー管理、问卷権限、作成から配信、回収、分析までのライフサイクルを製品として同梱している。README が「产品级开源方案」と表現しているのはこの意味で、ライブラリではなく動くシステムが渡される。裏返すと、認証や権限の設計を自前で持ちたい組織にとっては、同梱されたユーザー管理と问卷権限のモデルをまず理解し、必要なら置き換える作業が発生する。ライブラリとして設問エンジンだけ欲しいなら SurveyJS 側が軽い。調査業務を丸ごと社内に立てたいなら、こちらを土台にする方が出発点は前にある。

Apache-2.0 と、維持していくコスト

ライセンスは Apache-2.0 で、OSI 承認の寛容型ライセンスに分類される。商用利用や改変、再配布が許容され、変更点の明示といった条件が課される。ここから先は法的助言ではないので、自社製品への組み込み方や表示義務の解釈は法務に確認してほしい。維持の観点では、既定ブランチが main で、最終 push が 2026-07-20 と記録されている。活発に見えるが、これは活動量の指標であって品質の保証ではない。むしろ判断材料にすべきは、公式ドキュメントがバージョン付きのパス（docs/next/...）で運用されている点と、CHANGELOG が issue ベースである点だ。アップグレード時に何が壊れるかを追う経路が issue に依存するなら、追従は自動化しにくい。Docker イメージのタグも latest-slim と latest-full という可変タグなので、再現性が必要なら digest を固定して自前レジストリに持つ運用を検討する価値がある。

編集部の結論

自社ドメインでアンケート基盤を持ち、題型を足したり外部システムへデータを流したりする拡張を前提にできるチームに向く。逆に、設問を数問置いて回答を集めたいだけの用途や、フロントエンドを Vue 以外で固めているチームには、NestJS と MongoDB と Vue3 の一式を抱える理由が薄い。着手前に確認すべきは、README が示す server と web の分離構成、docker-compose.yaml のイメージタグ、そして公式ドキュメントの《问卷 Meta 协议》と題型物料協議の2つが、自社で追加したい題型を表現できる粒度になっているかどうかである。

公式情報源

1. didi/xiaoju-survey on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README