開発中のシステムがリリースされた
ブログの更新が滞って早くも半年が経過していた。 実はこの記事を書き始めたのは、4ヶ月前で、ようやく投稿することができた。
更新しなかった理由は、忙しかったからに他ならない。残しておきたい話のネタはいくらでもあるのだが、肝心の書く時間がない。しかし、現在ぶつかっている壁を解決するために、時系列として記録を残すべく、開発中のシステムをリリースするまでの流れを書いておく。
開発中のシステムとは
以前、知人からWebサイトの開発（HP＋システム）を請け負った。このうち、１月の段階でホームページは完成していたのだが、システム開発については、当時まだ未着手の状態だった。
詳しい話は、以前投稿した「フリーランスとして初めてのお仕事」を参照されたい。
具体的なシステムとは、事業で行う予約システムだ。つまりReservaやStoresなどのようなサービス。普通であれば、そういったサービスに（規模によるが）月額料金を支払い、運用するわけだが、今回はそのシステムの開発も任せていただいた。
この２ヶ月何をしていたか
結論から言えば、次の３行に集約できる。
・新年～年度末で仕事がとても忙しかった ・予約システムの開発が難航した ・新型コロナウィルスを患った
３つ目のウィルス感染については、別の機会に振り返ろうと思うが、ここで敢えてそれを取り上げた理由としては、このウィルス感染で自宅療養をしたから、予約システムの完成に大きな進捗を与えたと言える。
開発を振り返る
スタート地点は０から
今思えば、当時Webの開発スキルがほとんどない状態で、よくもこんな見切り発車ができたなと、自分に言いたい。依頼を請け負った直後は、これから開発に利用するサービスの名前を知っている程度で、「これらのサービスを駆使して使い方を覚えれば完成するよねー」ぐらいの軽い気持ちでいた。こんな見切り発車ができた理由として、依頼人である知人がとても寛容で、私にとって学習を含めた開発になることや、仕事をしながら開発するから期間がある程度長くなることについて理解が得られていたことであろう。本当に感謝したい。
ホームページの開設は容易だった
まずはデザインとコンテンツのヒアリング、事業についてのインタビューなどを行い、HPのモックアップを作る。この段階で９割ぐらいの決めが必要になり、ここから先の作業は変更した場合に大きなコストが発生することについて了承を得ることが必要だ。 例えば、Yahooのトップページのようなデザインのページ案で作り込んでいき、終盤で要件が転向し、Bingのようなデザインにしたいと言われた場合、レイアウトを作成が１からになってしまうため、それまでの作業が全て水の泡になってしまう。モックアップから仕上げに入っていくに対しては、デザインの微調整やテキスト・素材の変更などにとどめておく必要がある。このあたりの進め方に関しては、幸いなことに本業で嫌というほど経験したので難なく完成まで進められた。 ホームページは１月末で完成し、調整を２月末まで行った。
予約システム開発は学習から始まった
Web開発はあまり自信がなかった。前職でRailsを用いたBackofficeの開発を担当した経験がある他は、ASP.Netを用いたWebアプリケーション開発を少しした程度。最近話題になっているサーバーレスアーキテクチャやNoSQL思考など、言葉自体は知っていたが触ったことがないという「エンジニアとしてどうなの？」的な人間だった。
サーバーレスアーキテクチャに苦戦
最初、チュートリアルを見た時に「コマンドを打つ」から始まっており「そのコマンドはどこに打ち込むの？」という疑問から始まったのだ。
調べていくうちに、まずは開発環境を作る必要があることがわかった。幸いなことにLinuxもWindowsもサーバーの立て方はわかっており、数年間運用していたので問題なくできる。
しかし思うのだ。今更ローカル環境にサーバーアプリケーションや仮想マシンをいれるのか？と。 現代ならば、開発環境ですら仮想化されているのではないだろうかと調べてみた。
あった。Cloud9。
とにかく一つずつ紐解いていき、なんとか開発環境を手に入れ、最初の「npm install -g @aws-amplify/cli」を実行できた。 ここまでおよそ３時間。 自分でも思う。これは先が思いやられる。
チュートリアルを進めて関係図を見たりしても、どうもしっくりこない。クラサバ構造でフルスクラッチ開発していた人間からすると、なんで動くの？と思うことが多々あるのだ。他にも「Qiita」や「はてブロ」で公開してくれている有志の方々のチュートリアルメモを片っ端から試した結果、何度も何度も挫折した。
挫折の大きな理由としては、（公式チュートリアルですら）「記事の鮮度」が古かったりして、期待どおりに動作せずエラーの内容を調べても解決できなかったり、チュートリアルで説明されている機能の名称やサービス自体が終了していたりなど、様々な壁にぶち当たった。
もちろん、時間をかければ解決できる問題もあるだろう。やり方がいずれわかっていくと思う。しかし、とにかく解決するための情報収集に困難を極めるため、このまま続けていくとせっかくスマートに（楽に）開発しようとしているのに、スムーズに開発できないのでは本末転倒になってしまう。
幸いなことに、チュートリアルを繰り返していくうち、サーバーレスアーキテクチャというものがどういう構造で、AWSとそうでない部分がどういった成り立ちなのかがわかってきた。 ここまでおよそ１日かかった。
まずは簡単なサーバーレスアプリケーションを作ること
チュートリアルで大苦戦して得られたのは、知識だけではない。完成には程遠いという現実もわかったのだ。しかし、請け負った限りは最後まで完成させたい。相方の励ましやエールをもらい、くじけずに頑張っていこうと決心した。
そこで、まずはリリースまでの最低限必要なものを洗い出してみた。
・開発環境 ・バージョン管理システム ・バックエンドフレームワークの選定 ・UIフレームワークの選定 ・UIライブラリの選定 ・データベースの選定 ・ユーザー認証 ・アクセス制限 ・公開
まず、開発環境はCloud9でやっていくことにした。どの環境からでも作業を再開できるので、会社やカフェ・自宅のどこからでもアクセス可能なのは非常にアドバンテージとなる。バージョン管理システムは、本業でも散々使っているGit一択。GithubのPrivateリポジトリで十分使える。バックエンドフレームワークについては、サーバーレスアプリケーションを運用したいのでLaravelやRoR、Node.jsなどが選択肢となる。Ruby on Railsは開発経験があるので選択肢の一つだったが、ここでは、敢えてNode.jsを選定した。せっかくなので新しいものを覚えたいのと、Web上の情報がかなり多く、開発しやすそうだったから。
UIフレームワークについて、最初はReact.jsやAngularを使おうとしていたが、断念した。今となっては、基本がわかっているので、React.jsでもAngularでもいいのだが、当時良いチュートリアルに恵まれず、最もシンプルさと汎用性を感じたのがVue.jsだった。Vue以外のフレームワークについては、機会があれば使ってみたい。
Vuetify導入～日本語公式マニュアルに感動
Node.jsが動いている環境なら（Cloud9なら最初からセットアップ済みの環境が手に入る）、npm install vueなどと打てば環境構築は完了する。そして、スタンドアローンでWebアプリケーションが動くまで、何もつまづかず、１０分程度でHello worldが表示できた。私は英語ができないドメスティックWebエンジニアなので、日本語の公式マニュアルが充実していると嬉しく感じる。しかも、Vuetifyは非常にシンプルなので、とっつきやすく、違和感なくシームレスにコードが書けることがすごいと思う。
Router周りは少し苦労した。チュートリアルがあまりないので手探りだったが、一旦コードが動いてしまえば調べるのは容易である。
本業の仕事があるため、１日あたり１時間～２時間程度しか時間が割けないのがもどかしく感じる。 また、できれば２月中にシステムを開始できないかという相談を受けた。 現在の進捗からすると２月中のシステムアップはかなり難しそうだが、機能を制限すればなんとかできるかもしれない。
DynamoDBは断念、直感的なFirestoreに
AWSのNoSQLといえば、DynamoDB。業界でも有名だが、RDBMSにどっぷり使った自分としては、DynamoDBは少し使い勝手が良くない。クエリ条件式に使うAttributeはいちいちインデックスを指定する必要があったり（他の同じだがFirestoreは便利（後述））、スキーマの修正ができない（作り直しになる）このあたりは、開発のやり方次第では有るのだが、自分にはあっていない。 いろいろ調べているうちに、Firebaseというサービスにたどり着いた。どうやらGoogleが提供しているモバイル向けのプラットフォームで、NoSQLだけでなく、StorageやAuthまわりなどのサービスも提供してくれるらしい。しかも永年無料枠があるのが素晴らしい。
私がFirebaseのNoSQL（Firestore）を使うようになったのは、呼び出し方や使い方がRDBMSっぽいのと、まともな日本語公式マニュアルがちゃんと用意されている点である。もちろん、コントロールパネルも全て日本語表示で直感的。 DBとのデータの入出力ができるようになり、開発速度は加速度的に上昇した。 この段階で開発開始から５日程度だったが、仕事が忙しくなりあまり開発が進まなくなったのもこの頃である。
新型コロナに感染、自宅療養開始
２月中旬ごろ、喉が痛くなり微熱が出て、味覚が鈍くなった。これはもしかして…と思って病院に行ったら、案の定、感染していた。保健所から自宅療養を命じられたが、今勤めている会社はリモートワーク環境が整っている（なお、これはFortigateを使って私が整備し、緊急対応などで活用できている） しかし、実際にリモートワークが認められているわけではなく、会社に来られないなら休みとして扱われるという旧態依然とした考え方であったが、逆にこれが今回の大きなポイントとなるのである。
自宅療養期間でシステム開発ができる
自覚症状があり、体調は芳しくなかったものの、全く動けないわけではなかった。そのため、滞っていたシステム開発を大きく進める絶好のチャンスであった。 自宅療養期間は１０日間、１日８時間作業ができれば８０時間分の工数が消化できるわけである。ただし、療養が最優先なので調子が悪くなれば、適度に休憩をとったり仮眠したりすることも必要である。 開発においては、Firestoreでデータが入出力できるようになり、ようやくシステムの作り方のピースが揃ってきたところであった。ここからが本番である。
まずは管理者画面から
管理者画面は、ざっくり言えばそのシステムのあらゆるデータを見たり変更したり、システム設定などを変更できる画面である。管理者にも権限レベルが有るわけだが、ブログで言えば、ブログを書くことのできる人は管理者にあたる。 今回のシステムでは、管理者は一人なので、システム上の管理者権限は特別な区分けをすることなく、あとは一般のユーザーという２種類のユーザー種別を用意することとした。 管理者画面を先に作るメリットは、あらゆる必要な機能のモジュールを先に作ることができること。例えば、今回は予約システムだが、管理者はユーザーの予約を作成・変更・取り消し（削除）ができる。これを先に作っておけば、一般ユーザー側のシステムを作るときに、すでにある機能を制限的に呼び出すだけで良いということになる。UIにも依るが、まとめて機能を作るメリットは、作業が効率的になるだけでなく、構想が頭の中にあるうちに機能を形にできることで、変な不具合を生みにくいというのもある。 まずは、ユーザー情報として最低限必要な要素（ユーザーIDや名前など）と予約に必要な要素（予約IDや予約日時など）をDBに仮登録し、それらを読み出して表示するところから取り組んだ
実質５０時間
最初の２日間と最後の１日は療養・調整期間として費やしたので作業ができたのは７日間である。１日８時間弱、作業をすることとした。 その７日間のうちで、管理者画面の殆どが出来上がった。プログラマーとは言え、知識０から初めて短期間で形になるというのは、最近の開発手法やフレームワークがいかに優れているかというのがわかる。 １～４日目で、ユーザー登録・ログイン/ログアウト・予約管理が出来上がった。 ５～７日目で、ユーザー管理・予約メニュー設定・システム設定などが出来上がった。 残すところは、エンドユーザー側のシステムと画面の作成である。
残り２日
３月スタートにむけて進めていたが、残り2日となってしまった。 本来であれば、リスケジュールの相談を行いたいところだが、ここまでいろんなことに協力してもらっているため、なんとか最低限運用できる状態に仕上げて、後々要望に合わせたアップデートをするという体制を取りたい。 それについて、念のため相談したところ、問題ないとのことだったので、エンドユーザー側の画面を取り急ぎ作成し、Githubにコミット、そこから新しいプロジェクトをクローンしてfirebaseにパブリッシュした。
無事に3月からサービス開始
最後の仕上げでかなりバタバタはしたが、Firebaseの優れたサービスで問題なくサービスを開始することができた。実際にサービスを開始するにあたって、DBの初期値を入れるためのバッチを作ることを省いたりするなど、ある程度手作業になってしまったことが課題として残るが、ひとまず運用段階に入り、運用権限を譲渡することができた。足りない機能などは随時対応を進めている。
振り返ってみて
従来ではWebアプリケーションを作るとなると、サバクラ方式が殆どでアプリケーション側とサーバー側のソースを書かなければならなかった。そしてそれにあったデザインを制作し、作り込んでいくというのが定番だったが、最近ではサーバーレスという考え方が増えてきて、さらにUIフレームワークも充実しているので、アプリケーションの開発に専念できる。たとえるならば、WPF（C#）とSQLServerでアプリケーションを作っているような感覚である。 自分の計画性のなさと見通しの甘さが露呈し、まるで夏休み終盤の学生が宿題に追われているような状態だった。エンジニアをやっているとあるあるなのかもしれないが、実際に尻に火がつかないと本来のパフォーマンスが発揮できないのは不便に思う。コツコツと計画的にできる人が羨ましい。
これから
まずは引き続き要望に答え続けていこうと思う。その後、そのサービスから汎用的に使えそうな部分をブラッシュアップし、いつかは一般開放ができるようになりたい。こういった一つ一つの積み重ねが自分のスキルになっていくのだと改めて実感できた。
