今年一年のアウトプットを振り返る

Posted at 2019-12-15

この記事は『ラクス Advent Calendar 2019』の15日目の記事です。

はじめに

年末が近くなってふと今年一年を思い返すと社外でも割とエンジニアっぽいことやってきたなと思ったのでこの一年でやってきたことのご紹介をしようと思います。

ちなみに普段の仕事は最近『データアーキテクト』と呼ばれているようなことをしています。
が、まだ浸透していない言葉なので『データエンジニア』を自称しています。

ただ、この記事の内容は仕事とは直接関係ない『個人開発』に関する内容が多めです。
個人開発の進め方、技術書典で本を出した振り返りなどに興味がある方は楽しんでいただけるかもしれません。
技術書典の振り返りまでがこの記事の本編です。

やってきたこと

この一年で社外向けに個人開発としてやってきたことを適度に分割してご紹介します。
思い返せば今年はずっと何かの〆切に追われる一年でした……。
来年は心穏やかにすごしたいです。

【1～5月】ボードゲームデザインのアシストツールを作ってリリースした

何をやったか

私は趣味でボードゲームを自費出版しています。
ゲームのルールを作るという活動はルールの組み合わせを何パターンも試行錯誤する必要がありとても大変です。
ルールを考える際にインスピレーションを与えてくれるようなツールが欲しいと常々思っていました。
海外のボードゲームデータベースサイト『BoardGameGeek』ではゲームのジャンルやルールを細かく分類して各ゲームに対してタグ付けをしたり、ゲームの面白さを評価したりといったことがされています。
（あるゲームは『経済』『農業』といったジャンルに属し、『ハンド・マネージメント』『ワーカー・プレースメント』といったルールを持ち、10 段階評価は 8.1 である。とか）
ただし、このサイトは基本的にゲームを遊ぶ人向けのサイトのためジャンル・ルールそれ自体の平均評価などは見られません。
なので、データを集めて全体を俯瞰できるようなツールを作ろうと思いつき実際に作ってみました。
この思いつきでこの一年の活動の方向性がほぼ決まりました。今年一年のプライベートでの開発ほぼこのツール関連のことしかしていません。

実際にはできたブツは Superset という BI ツールで BoardGameGeek の色々なデータを可視化できる仕組みを作りました。
https://joururi-soft.com/ へアクセスし、以下の ID・パスワードで閲覧オンリーユーザーでのログインが可能です。

ID：DilemmaHoldem
Password：texasholdem

実際にサイト内で見られる可視化の例を挙げると、上の図はゲームのルールと評価の相関関係を示した図です。
横軸がルール名で縦軸が評価レートになっています。そして、各マスの色の濃さがそのルール・評価レートに該当するゲームの数になります。
この図を見たときに色の濃いマスが上に出ているほどそのルールを含むゲームは面白いということが示唆されます。
上の図の中の濃いマスが上に出ているルールで特に目立っているものををいくつかピックアップすると『アクションポイント割り当てシステム』『バリアブル・プレイヤー・パワー』『協力プレイ』というルールがいずれも評価レート "8" 付近が一番濃く出ており面白いと評価されているであろうことがわかります。
『ダイスロール』や『ハンド・マネジメント』も色は濃いのですが、単純に登録されているゲーム数が多いだけで評価も "6" 付近の色が濃いのでひとまずここでは除外。

この図で面白いと評価されているルールをゲームに組み込めば面白いゲームを作れるのではないか？　という仮説を立てられるためルール作りに一役かってくれそうです。

このツールを作る際に1～5月にやったことは概ね以下の通り

1月：作ろうと思い立ち自社の開発サークルの LT 会で『作ります宣言』をする
- 手始めに逃げ道を塞ぎます。言ったからにはこのツールを作らないとダメな空気を自分の中に植え付けます
- ちなみに当時はデータ集めて、問い合わせ用の API を作って、フロントも自分で実装しようとか考えてました
2月①：とりあえず独自ドメインを購入
- 独自ドメインを買って逃げ道を塞ぎます。ツール作らないと無駄にドメインの使用量を払うことになります
2月②：データ収集バッチを作る
- どんなツール作るにしてもデータは絶対に必要なのでとりあえず集める
- BoardGameGeek は XML API が公開されておりサイト内の情報を XML で取得可能
- Scala + PhantomJS で API を叩きまくって MySQL にデータを溜めるバッチ処理を作成
  PhantomJS が開発終了していることはバッチを作り終わってから知った
- データベース作ったからには最後までやらないと無駄になるという気持ちになる
- ただし、この時点で API とフロントの実装は無理だと察して BI ツールの利用を検討しはじめる
3月：BI ツールを選定する
- Redash、Metabase、Superset をネットで調べて比較してみる
- Redash ほど SQL 依存ではなく可視化の種類の多い Superset を使うことに決める
  今思えば Metabase の方がより使いやすかった気がする
- システムの全体図は以下の通りに決定
  1. バッチ処理で XML API 叩きまくって MySQL にデータ集めます
  2. Docker 上で動いている Superset と MySQL を接続します
  3. 利用者の PC から Superset にアクセスしてデータを可視化したり可視化結果を閲覧したりします
  4. 以上
4月：GCP の使い方を学んで GCE でサーバ構築を行う
- アクセス数全然ない予定だったので一つのインスタンスに色々なミドルウェア全部乗ってます
  （Nginx、Docker（Superset）、MySQL 全部乗せ）
5月：SSL 対応とか実際のデータ可視化とか細かい色々な調整をやって『ゲームマーケット』で制作者向けサービスとして発表した

身についた・使ったスキル

独自ドメインの購入のしかた
Scala を使った XML のパース処理の実装
基本的な Docker コマンド
Superset を使ったデータ可視化
GCP の使い方（GCE インスタンス作成、ファイアウォールの設定、独自ドメインの振り方など）
Superset、MySQL などのサーバ構築
Nginx を使った SSL オフロード
スケジュール的に無理な部分を切り捨てて代替手段を考える

感じたこと

率直な感想としては一人でサービス作るのめちゃくちゃ大変だなと感じました。
サービス本体は Superset に頼りましたが、食わせるデータや動かすためのサーバの準備は自力でやらないといけなかったので結構な労力でした。
加えて独自ドメイン振ったり、通信を SSL 化したりといった細々としたタスクも全部自分持ちだったのでそれらも対応していると意外と時間持っていかれると感じました。

今回作ったツールは作ることそれ自体は全く目的ではなく、『ゲームデザインを少し楽にする』ことが目的で、そのマイルストーンとしてゲームマーケットでのリリースを目指していたのでスケジュール的に無理な部分は積極的に切り捨てて代替手段を取りました。
当初自力で実装する予定だったデータ分析用の API 開発やフロント周りは全部 Superset で代替しました。サーバも本来であればミドルウェアごとに立てた方が良いのだと思いますが時間とお金の関係でひとつのサーバに全部乗せしました。
しかし、そのお陰で目指していたゲームマーケットでのリリースは無事達成できました。

一通り終わってみて感じるのは「個人開発ではどこを目指すかがブレると絶対に空中分解するだろうな」ということです。
今回の目的はあくまでも『ゲームデザインを少し楽にする』ことでした。API 作り、フロント周りの実装、ミドルウェアごとのサーバ構築辺りは自分のスキルアップとしてはすごく良いと思うのですが、これらも妥協せずやっていたとしたら私のスペックでは完全に手に余ってしまいリリースには漕ぎつけられなかったと思います。
なので、個人開発では目標地点は一点集中でそこに至るための道はある程度柔軟に妥協していく必要があると感じました。
一点集中したとしても全部自分でやるとなると嫌でも色々学ぶのでちゃんとスキルは身につきますｗ

次回への改善点

さんざん『ゲームデザインを少し楽にする』ことが目的と言っておきながら実はまだこのツールを積極的に使って作ったゲームは世に出ていません。
ツールを作ることと後述の技術書典で本出すことに力を注ぎすぎました。
加えて可視化の種類もまだほんの少ししかありません。

来年以降は

データ可視化をもっと学び、ゲーム作りの際に仮説を立てるのに役立つデータを作る
作った可視化データをもとにゲームをデザインして世に出す

辺りが目標となります。