侍とコードとKLと

どうも、Yasです。

侍……。みなさんは、この言葉から何を連想しますか？
僕にとってはクアラルンプール（KL)。マレーシアきっての大都市で首都。シンガポールから飛行機で１時間ちょっと。東京に出張で新幹線乗るよりも実は近い距離。シンガポールから出国するのも、KLでの手続きも簡素なもので（その当時はね）、すぐ行ける距離ではあったんです。

KLになった理由はとてもシンプルで、そこに侍がいたからです。そこに山があるから登るんだ……。みたいな言い草ですけど、Yasは人ドリブンなのでどこでも会いたいと思ったらとんでいくそんな一途な代表なのです。

侍との出会いも山中の時と似たような奇跡的な出会いがありました。当時、駐在員だった僕がシンガポールに行く前にこんな会話を交わしていました。

Yas: 「僕、シンガポールに赴任になったんだよね。」
侍:   「あ、そうなんですか！？実はマレーシアで働くことになったんです」
Yas: 「そうなのね！、じゃあお隣さんやし遊びに行くわなー。」

……

一見、社交辞令的に見える会話ですが。社交辞令とか高度なコミュニケーションを取ることができないので。ここでの「遊びに行く」は確約事項でした。KLに赴くと決めた時の開発状況はMagnet4Joyのドラフトが出来上がったぐらいで、誰かに手伝ってもらうにしてもシンガポールに信頼できるエンジニアのツテはなかったというのもあって、お隣だし行ってみるか！というだいぶんと軽いノリでした。

無事、KLについて市内のホテルのロビーで超久しぶりの再会。最後に会話の続きをするかのごとく自然に仕事の話をしはじめました。

Yas:「かくかく、しかじか。こんなことをやっているのよねー。手伝ってくれない？」
侍: 「あ、良いっすよ。製品作ってみたかったんですよねー！あ、じゃあPCとってきますねー。」

と、尋常じゃないフットワークの軽さをみせて、自分の家にPCを取りに帰り１時間後に開発が始まりました。この日は侍と適度に楽しい会話をして、楽しく飲みに行って羽伸ばすつもりだったんですが、盛り上がったし。楽しそうだし、すぐやろうぜ！ってことになりました。

プログラマやってて良かったなと思うのはとりあえずPCとインターネットさえあればそれだけで事足りるってところです。お手軽にどこでも開発できるのは本当にステキやなとしみじみ思ったりします。

さて、侍はPCを持って鼻息荒くやってきたわけですが、PCが活躍するのはもうちょっと先です。机に頭を突き合わせ真っ白なメモに必要な機能と画面の構成をペンで書き殴っていきます。フロントはなんとなくできているけど、管理画面全然ないよね。とか、そんな感じのやりとりをしながらゴリゴリとワイヤーを作っていきます。とりあえず、マスタは持っとかないとね。フロントのUI/UXは複雑なことはせずに必ず、画面上でできることは１つ。エンドユーザは業界人じゃないので難しいことは抜きにしたいよね……うんぬん。

そんなこんなで２０枚弱の落書きが部屋に散乱したところで。開発スタートです。GitのURLを教えて。ビルドの仕方を教えて。よーいドン！

いわゆるマイクロサービス的なクライアント・サーバスタイルの開発が早そうだったので。MVPを目指してゴリゴリ作ります。Firebaseのプロジェクトは３つ。フロント、管理画面、APIです。技術的にはVue.jsでフロントも管理画面を作って、APIはnode.jsでゴリゴリ書くことにします。そこにFirebase Functions, Firestore, Firebase Storageにデプロイするという極力簡素化した構成にしてみました。FirebaseはEmulatorが素晴らしいんだけどまさかのそれを知らない状態で始めたので、今思い返すと失敗したなと思いますが実は便利だなぁと思い出したの最近なのでそこまで実は後悔していません。

あーでもない、こーでもないと言いながら、文字通り寝る間も惜しんで書いて、書いてかきまくります。２泊３日の開発合宿はあっというまで、ほぼMVPといえるものはなんとかできました。こうして、侍との邂逅は見事にとても濃ゆい形で果たされました。YasはまたKLに訪れることになったり、侍がシンガポールに来ることになったりするなんてことはこの時はまだ全く思わなかったけどね……。

さて、開発裏話なので。今、思い返してこうしとけば良かったなぁと思うことを書いておきます。自分の備忘録的なところもあるのですが……。

後悔は３つ。今後のリファクタリングで片付けようと思いながらも棚上げになっている仕方ない子たちです。

１つめ、APIが多くなりすぎて訳がわからない……。機能が増えていく中で薄々感じていたんですが、作りながらフィードバックをもらってというスタイルでリアルタイムで開発していたので、出来上がりの速度を優先した結果です。到着点がわかりそうでわからないこのフェーズだとあるあるだと思います。

２つめ、Functionsに全てのDBアクセスを寄せることでフロントから直接DB操作をさせるということを避けています。これはフロントの方が軽微な修正が圧倒的に多いだろう（Typo魔人だし僕）という目論みによるものです。そこは何にも後悔していないんだけど、DBへのテストが結構めんどくさい。っモックデータを投入するスクリプトをXUnitとセットで用意しとけば良かったなぁとJSONでその場で作って投入するでサクッと動かせちゃうのでこういう一工夫をしとくと楽だったなぁとリファクタリングする気持ちになった今、思っています。後悔先にたたず。

３つめ、Firebase Remote Configは積極的に活用すべきだった。Feature Flag / Switchを実現するためのものだけど。とりあえず一直線にMVPを作ろうと思っていたのでこういうところは見落としがちです。後から、追加したくなるんだよね……。こういう設定系。

で、最大の後悔は（３つじゃないの！？）管理画面は必要悪だと思っていること……。必要ないなら要らないんですよね（あたりまえだ）。設定をしなきゃいけないぐらい複雑なものを作ってしまったことが１番の後悔。それこそ、Firebase Remote Configを元に設計すればよかったねーってことです。どうせ、機能が追加されていく、そしてその機能はいつかリタイアするときが来る。理想的なのはソースコードから丸ごと落としちゃうことだけど、そんなにキレイにいかないのがこの世の中ですよね……。

これから何か作るぜ！SaaSで作るぜ！みたいな人にFirebaseはステキにおすすめなんですが。設定やABテストをベースに設計していくのが今時なのかなぁと思った次第です。元々、設定の化け物みたいなソフトウェアの番人やってたので敬遠してたんだけど最低限はどうしても必要だよね。そうしないとミイラ取りがミイラになっちゃうよ！なんで、次こそは本気出すってことで次回はこの経験を活かして設計してみようと思った次第です。

今回は侍との出会いとSaaS作っていく上でのちょっとした後悔でした。次回はTSUMUGUの産みの苦しみ、精算ってどうすんだ？でお会いしましょう。

----

株式会社Gifted Pocketでは「親育て・業務効率化」の2側面を同時にケアする統合ソリューションTSUMUGUの販売をおこなっております。登園・降園・精算といった基本的な業務のバックアップだけではなく。自由度の高いおたより作成・集計機能を搭載。ロボットを使った様々なギミックでおどろきと会話を生み出します！是非、ご検討くださいませ。資料のご請求はこちらからどうぞ。