新しいアンケートシステムをつくった（Goとシステム概要編）

f:id:juntaki1:20190924172635j:plain エムスリーエンジニアリンググループの滝安（@juntaki）です。私のチームでは製薬会社のマーケティング支援事業として、会員向けのアンケートを行っています。つい先日、新しいアンケートシステムのIbisをリリースしました。この記事ではシステムをつくった背景とその概要を説明します。続きの記事でチームメンバーが技術的な詳細についても説明します！

アンケートのむずかしさと、Ibisをつくったわけ

アンケートシステムは、かんたんに言ってしまえばフォームジェネレーターです。ざっくりの要件としては、設定に従いアンケートの画面が動作すること、回答が適切なフォーマットで利用できること、の2点です。 ……そして、細かくは、バリデーション、回答による条件分岐などについて考慮する必要があります。また、当然それらをWebから管理できるわけです。難しく言うと、メタWebシステムといえる複雑さがあります。

すでにエムスリーにはTigerというアンケートシステムがあります。リンク先の記事にもある通り、Tigerが目指していることは「作れないものがない」という点です。つまり、主にアンケートの画面を組み立てることにフォーカスしています。一方で回答については、1アンケートごとに1セット、という形式で管理されています。（それで十分なケースもあるのですが）少し設問を変えてしまうと、別アンケート扱いになり、回答の突き合わせがしにくい、という問題がありました。

f:id:juntaki1:20190925112723p:plain — Tigerのアンケート、設問、回答の関係。設問2は共通だが、別のアンケートの回答

アンケートには大きく2種類あり、1つ1つクライアントのニーズに合わせて調査を作っていくタイプと、自主調査としてデータを蓄積していくタイプがあります。前者はTigerで100%カバーできているのですが、後者については、今まではアンケートごとにシステムを作っている状況でした。

自主調査は比較的長期間行うため、たとえば、日々の改善で少々アンケートの構成や選択肢を変えたとしても、同じ回答データとして比較可能な状態で蓄積し続ける仕組みが必要です。アンケートごとに乱立したシステムを統合しつつ、あらたな自主調査を実施しやすくなるシステムとして、Ibisを作りました。

Ibisの仕様

f:id:juntaki1:20190925112043p:plain — Ibisのデータの流れ、設問2は2つのアンケートから回答が入る

IbisではTigerとは異なり回答のフォーマットにフォーカスし、アンケートの画面はシステム側でよしなに組み立てる方針です。格納される回答データはシステムのデータベースからBigQueryのデータウェアハウスに同期され、そのままTableauのダッシュボードで確認できるようになっています。

具体的には、Ibisの管理画面では「アンケート作成」ではなく、「設問の作成」から操作がスタートします。アンケートは作成された設問を集めて作っていきます。つまり、同じ設問がさまざまなアンケートに含まれていても、きちんと、それが同じ設問に答えていることがわかるわけです。他にも、アンケートが長くなると途中で離脱する人が増えてきます。Ibisであればアンケートを細切れにしても、まとめて聞いても、結果は同じことになります。

このように、格納されるデータ（＝設問1つ1つ）からボトムアップで作っていくことで、データの連続性を担保しながらアンケートの改善を行っていけるシステムになっています。*1

システム構成

構成はこのスライドに書いてあるのとほとんど同じものになっていて、wire, xo, protobufなどのコードジェネレーターを活用しています。それによって、Clean Architecture的な依存関係の整理をしながらも、手で書くコードを最小限に、読みやすくとどめています。

Go/App Engineの構成は以前作ったアンケートの集計システムで採用したのですが、このときは社内システムで、エムスリーとしては初のプロダクションへのGo導入でした。今回は社外のユーザーが利用するシステムでは初のGoプロダクトです。そのため、会員向けの認証システムなどと接続する必要があり、Go向けのライブラリの整理もまとめて実施しています。これで会員向けのシステムについても、Goが選択肢に入りやすくなるはずです。