後半のこの記事では、システムの具体的な中身について、管理画面、Webフロントエンド、ランキングシステムのセクションに分けて紹介します。

前編では開発したシステムの概要や開発手法などについて紹介をしているので、そちらを先にご覧いただくことをお勧めします。

管理画面

役割としては、エンジニアだけしかできない作業を減らすこと、行える操作を限定し、視覚化することでバグの原因を排除することです。主に実装した機能としては、

問題の追加・編集・削除
会場の進行管理
参加者の全回答テーブル
（未使用）問題ごとの回答率グラフ

の4つです。

運営しか使わない1~3の管理画面のデザインは全ての作業においてもっとも優先度が低く、最低限の機能と使い勝手を満たしたバランスで実装しました。

それでは、実際に操作している動画と合わせてご紹介します。

問題の追加・編集（・削除）

このように問題を作成し、解答の差し替えをしていました。

出題順もあるので順序を入れ替えることもでき、当然削除もできます。

会場の進行管理

運営側では、会場の進行状況に合わせて、参加者の画面の遷移や回答の締め切りなどの状態操作を行っていました。

参加者の全回答テーブル

問題ごとに正解率を予想し、報酬設計を行っていたので、期待通りに回答が分散しているかを確認しながら進行していました。

正答数降順でソートをかけて、得点が高い人ほど上にくるようにしています。

回答率グラフ

本番に時間があれば各問題の集計が終わった後にスクリーンで回答率グラフを表示する予定でしたが、こちらは未使用に終わりました。

スクリーンに表示する想定だったため、画面内に余分な表示を（ブラウザのメニューだったり、マウスポインターでさえ）したくなかったので、全画面にした時に適切なサイズになるようにし、円グラフの表示/非表示はs / h(show / hidden)キーで行えるように実装しました。

円グラフは使いまわせる形で作成したので、最終的な各問題の回答率のビジュアライゼーションも簡単にできました。

Webフロントエンド

当初Unityでネイティブアプリにする予定でしたが、配布や修正が簡単という理由から、Webアプリになりました。

今回、各画面の担当者が好きなライブラリで自由に開発できるようにSPA（シングルページアプリケーション）ではなく画面毎にHTMLを作って開発しました。なので通常のプロダクトではありえないような、ログイン画面はReactで、それ以外はVue.jsという２つのJavaScriptのフレームワークが使われています。

スタイルの記述にはSass(SCSS)を使っています。ネストして書くことでわかりやすく変数やmixin、extendなどが使えるので便利です。また、ブラウザ毎のベンダープレフィックスを書くのが大変なのでautoprefixierを使って自動的に付くようにしました。

Vue.js

Vue.jsは.vue拡張子の単一ファイルコンポーネントにできることと、導入が簡単なので今回使うことにしました。コンポーネント単位でJavaScriptとCSSのスコープが切られるため他のコンポーネントに影響が出ません。

今回のアプリでは使いまわせるコンポーネントがヘッダーくらいだったのと表示自体が単純だったので１つのコンポーネントに全て記述しました。大規模な開発では、コンポーネントをもっと細かい粒度で分けるかファイルを分けるなどの工夫が必要です。

Vue.jsは簡単に始められ、規模が小さい時はイベントバスを使ってコンポーネント間の通信を行い、規模が大きくなったらVuexを使うなど柔軟性があります。

単一ファイルコンポーネント

一つのファイルにHTML、JavaScript、CSSを記述できます。

<template>
        <p>{{ hoge }}</p>
</template>
<script>
export default {
        data() {
                return {
                        hoge: 'Hello, World'
                }
        }
}
</script>
<style lang="scss" scoped>
p {
        font-size: 2rem;
        text-align: center;
}
</style>

ファイルを分けることもできます。

<template src="./hoge-component.html"></template>
<script src="./hoge-component.js"></script>
<style scoped src="./hoge-component.css"></style>

CLI

公式が用意するCLIを使ってWebpackのビルド設定を知らなくても簡単にVue.jsのプロジェクトを作成できます。ターミナルでnpm install -g vue-cliを実行するだけでインストールできます。

$ vue init webpack hoge
$ cd hoge
$ npm install
$ npm run dev

アニメーション

今回のアプリでは主に画面遷移時にフェードイン・フェードアウトアニメーションを実行しています。

Vue.jsでは標準でtransitionコンポーネントを提供しているので簡単にトランジションを追加することができます。transitionコンポーネントでラップされた要素はトランジションの状態毎にクラスが追加されます。

トランジションの例

<template>
        <button @click="show = !show">CLICK</button>
        <transition name="hoge">
                <p>Hello, World</p>
        </transition>
</template>
<script>
export default {
        data() {
                return {
                        show: true
                }
        }
}
</script>
<style lang="scss" scoped>
.hoge-enter-active, .hoge-leave-active {
        transition: opacity .3s;
}
.hoge-enter, .hoge-leave-to {
        opacity: 0;
}
</style>

開発の振り返り

開発にはGitHubを用いました。ISSUEベースのタスク管理 + GitHubフローというごく標準的な開発形式で進めました。特別にチームとして意識的に行ったことはありませんが、チーム開発の基本的なところについて自然にコンセンサスを取れていたことが、スムーズな開発に繋がったと思います。

また、他にも下記の要因が挙げられます。

コンセプトを固めてから実装に移ることができた
短期間でフィードバック期間を設けた
開発の優先順位を間違えることがなかった
開発事項をもれなくISSUE化するようにした
進行の管理者と実装者が分かれていた
コミュニケーションのコストが低かった

1. コンセプトを固めてから実装に移ることができた

『人月の神話』のフレデリック・ブルックス曰く

“Conceptual integrity is the most important consideration in system design.”

とあるようにシステムのコンセプトが定まった上で開発を行うことは、チームにおいて強力な開発手法となります。そして今回は、ベンチマークとするコンテンツがしっかり定まっていたことと、PM（プロジェクトマネージャー）に相当する者が、開発側で迷うことのないレベルまでページ単位で仕様を定めてくれたため、結果としてスムーズに開発を行うことができました。

2. 短期間でフィードバック期間を設けた

開発中に1週間単位程度で開発中のものをそれ以外のメンバーで触ってフィードバックを返すようにしていました。そのため、次に何を優先的に実装するべきか、何が仕様と異なっているかを常に把握しながら実装を進められました。

3. 開発の優先順位を間違えることがなかった

開発順序としては下記の通りになりました。

APIサーバー
UIデザイン
Webフロント
全体フィードバック
API、フロント修正
アニメーション調整

全体からディテールへというように、理想的な開発ステップを踏めたと思います。

成り行きではありますが、全体フィードバックまではあまり大きなデバッグ作業を行なっていませんでした。しかし全体フィードバックを精度高く行うことができたため、結果としてフィードバック（デバッグ）フェーズで修正項目を一気にリストアップすることが出来、逐次に開発側でデバッグ作業を行うよりも大幅に工数の削減を行うことができました。

開発の粒度としても、大きなプロジェクトですとデータ構造について議論するというステップがあったりしますが、今回のような小規模短期間の開発においては担当に一任できたことは大幅に工数の削減に寄与したように思います。

4. 開発事項をもれなくISSUE化するようにした

これは常にISSUEを見れば実装すべきことが何か、というのをわかるようにメンバーで心がけたことにより、今何を実装すべきかということを見失わないですみました。

ありがちなミスとして、ISSUEをメモ書き代わりに使うのは良いのですが、後から見たときになにをすれば良いかわからないということがあります。それが起こらないよう何をどう実装すれば良いかということがわかるレベルでISSUEを記述することをこころがけることにより、有効にISSUEを活用することができます。

5. 進行の管理者と実装者が分かれていた

今回はチームメンバー数が潤沢だったこともあり、進行管理と実装を別々の者が担当しました。第三者の目線で進捗を管理する方が、適切に問題を指摘でき、スケジュール管理の精度を上げることができました。

6. コミュニケーションのコストが低かった

全員が同期というのもありますが、互いに尊重しあえるメンバーであったため、対話ベースでもチャットベースでもスムーズにコミュニケーションを行うことができました。また開発上必要なことは、最低限READMEに書くことで全員が行う面倒な作業を再現性を保ったまま減らし、開発に集中できる環境が整っていたと思います。

以下は、実際に作成したREADMEの一部です。