ゴリゴリのSIerのSEが初めての個人開発で公開まで頑張ってみた過程

ゴリゴリのSIerのSEが個人開発でWebサービスを作ってみた
の続き、みたいな。

前回「Webサービスを作ってみた」話を書きました。
書いたやつを見て思ったんですが、ほとんどWebサービスの紹介でSIerの要素があんまり入ってない。
前回の意図としては、Webサービスそのものをアピールするというより「SIerはBPに投げるだけでプログラミングなんてしないよ」なんていう声をたまに聞くので、SIerの経験しかないSEがプログラミングやってWebサービスっぽいものを作るとこんな感じになりますよ、というひとつの実験結果をお見せしたかったのです。

それが成功か失敗かは置いといて。

ただ、「こんなの作りました」しか書いてない気がするので、大まかにどんな過程で開発を進めていったかを書きますので、何かの参考になれば…と思います。

ほんと大まかです。
モダンではありません。
読み物的な感じです。
「ポエム」タグです。

#1.動機づけ
今回は「作りたいもの」が自分の開発のきっかけになりました。
なぞるように一から体系的に学ぶのもいいですが、「作りたいもの」に必要な機能、その機能に必要な技術は何か？って考えながら進めていくと結構時間を忘れてどんどん形になっていきました。
とはいえ「作りたいもの」はそんな簡単に出てこない気もするので、いろんな人に「何か欲しいもの」をひたすら聞くのも良いと思ってます。
それを「作りたいもの」にすればもうあとは手が勝手に動くと思います。

#2.開発環境
そう思い立って、では何から始めるか…
本番環境をイメージしました。
私はモダンな経験はしていません。
「まぁ最初の個人開発だしサーバーは１台でいいか～、で、Web/APサーバーに Apache Tomcat、DBはMySQLでもいいけど今回は触ったことのないMariaDBの方で！」
みたいな。
あとは言語。
言語は前に書いた通り、未経験のVueと経験のあるJavaでバランスよく学んでいこうという思いでフロントはVue、バックエンドはJava（Spring Boot）にしました。
そしてエディタ。
私はC#とJavaの経験があり、業務で使った経験があるのはVisual StudioとEclipseです。
Visual Studioのライセンスは持ってません。
Eclipseは経験上、重くて起動時にたまにコケてたのが気になります。
よく目にするVS Codeが軽くてJavaにも使いやすそうなのでVS Codeにしました。
ソースのバージョン管理は特にしていません。
コンテナ的なものもありません。

#3.Javaで開発スタート
まず、ログイン画面から作り始めました。
最初にログイン画面って…あんまりおもしろくないですね。
Spring Bootの機能を利用して実装しました。

次にSIerの基本、マスタメンテナンス画面。
SIerが開発を学ぶためにまず最初に作らされるのがマスメン画面というイメージ。
経験があるのでとりえず実装完了。
このときはまだ見た目に何の装飾もしていません。
ヨメに「こんなのできたんだけど」とログイン画面とマスメン画面を見せてみました。
反応は「こんなのに何時間かけてんの？」みたいな反応でした。
機能がどうのこうのというより、見た目のしょぼさのインパクトが強かったみたいです。
これは私のモチベーションが下がったぁぁ
…ということでこの時点になってVueを導入しました、

私は、Vue未経験者です。（素のJavaScriptはそれなりに扱ってます）
何かライブラリになってて、ファイルをどこかに置いて参照する感じ？って思ってました。
学習用ならそんな感じでもいいかもしれませんが、Node.js、Vue CLIをインストールし、Vue CLIからプロジェクトを作成すると想像と違うものが出てきました。
単体で動かす感じ…
な私のVueレベル。
※あとで公式を見たら「初心者が vue-cliで始めることは推奨しません」って書いてある…
とりあえず見た目を何とかしたいので業務で扱ったことのあるBootstrapでも入れればいいのかなと思いましたが、調べるとElementというコンポーネントライブララリがVueとセットになってる記事をよくみかけたので、Elementを採用。
Vueの説明の最初らへんで「リアクティブ」って言葉をよく見かけましたが、その言葉に最初はピンときませんでした。
今は「動的に変わる」ってことだと思ってます。

#4.開発の流れ

業務では仕様書を書いてレビューしてもらって直してまたレビュー…の繰り返しですが、今回はそんな細かくやってません。
SIerとして「要件定義→外部設計→内部設計→実装→テスト色々→リリース」まで一通り経験してるので、頭の中では色々やってたかもしれません。
今回の流れとしては、機能ごとに
・画面イメージのメモ
・画面遷移図のメモ
・DBのテーブル設計のメモ
を作ったくらいです。
しかもそれらは今現在手元にありません。
紛失です。
業務の引継ぎ時は「仕様書はありません。ソース見てください」って伝える必要があります。
画面イメージや画面遷移が変わってもだいたい機能内で閉じてたので影響は少なかったのですが、テーブルの項目が変わると他の機能への影響が大きかったり色々面倒臭かったので、そっちはもう少しちゃんと考えてたほうがよかったな…と今は思ってます。

#5.いきなりAPI

さて、Node.jsとTomcatという二つの実行環境ができました。
今さらですがここらへんでバックエンドをREST API化するイメージが固まりました。
開発時はJavaのプロジェクトにVueのプロジェクトを突っ込んで、Node.jsとTomcat両方立ち上げてました。
本番環境ではビルドしたVueのファイルがwarファイルに含まれるようにして、全部Tomcatに乗せました。
※APIのURLの先頭を/api/…　にしないとVue側とURLがかぶってしまう問題が発生したのは後のこと…

#6.Vue + Java（Spring Boot）で開発スタート

ログイン画面とマスメン画面をVue + Spring Boot（REST API）で作り直し。
ここら辺は探すと色々やり方が出てくるのでそこまで詰まることはなかったです。

バリデーションには最初Elementを使ってましたが、サーバーサイドのエラーを扱おうとしたとき上手く使えなかったので、VeeValidateに切り替えました。
VeeValidateでなんとかやってます。

実装の流れはだいたいルーティーン化していました。
画面作成(Vue)→テーブル作成(DB)→リポジトリクラス作成(Java)→サービスクラス作成(Java)→コントローラークラス作成(Java)→REST APIアクセス部分作成(Vue)→画面調整(Vue)
これを機能ごとに繰り返す感じです。

ちなみに私のSIerとしての経験的に、ちょっとデザイナーと仕事をしたことがあるくらいで私にはデザインの知見がほとんどありません。なのでデザインに関しては何とも言えない仕上がりになっています。

#7.その他各機能の作成

各機能の作成は経験と世にあふれてるサービスを参考にしました。
排他制御は細かくやりました…
あと、世にあふれてるサービスを参考にしなくても、チャットなんかは実装方法を教えてくれてるサイトがたくさんありました。
ただシンプルなチャットが多いので、メンバーがオンラインかとか削除機能とかアイコンの表示とかは自力で考えました。

チャットのメッセージを削除する機能をあとから実装しようとしたら、テーブルの構造上消せないということが判明しました。
その時点でチャットに関するテーブルの構造を結構見直したので、影響範囲が大きかったです。
メッセージの削除はあとでいいかな～と思ってましたが、テーブルの構造はある程度そこも考慮に入れるべきだったな～と思ったりもしました。

ちょくちょくヨメに見せてましたが、けっこう辛辣なことを言ってくれました。
特にデザインと操作性ですね。
そこまで言う？くらい。
まあユーザーにとって大事なのはそこなんですよね。
ヨメの身も蓋もない指摘でダメージを受けつつ良くなった部分もあるので感謝です。

#8.迫りくるネガティブ

開発中、ときどきあいつはやってきます。
「こんなサービス誰が使うのか…？」という蠢き。
それは大きな影となり、視界を闇で包みます。
レビュー「クソサービスですね」
レビュー「使えない」
レビュー「バグ多すぎ」
頭の中をマイナスの評価が駆け巡ります。
そして手を止めて、すべてを捨て去りたくなります。
そうやって途中で止めて放置状態になった作りかけのアプリは至る所で眠っているでしょう。

こういうときは本来ユーザー目線でやりがいを取り戻すべきなのかもしれませんが、私はプログラミングの楽しさに逃げました。
で、気持ちが落ち着いてきたらまたユーザー目線に戻ります。
それの繰り返しでなんとかモチベーションを保っていました。

#9.ちょっと苦労したユーザー間で同期するタスク管理

チャットみたいにWebSocketでユーザー同士の画面を同期させる機能をタスク管理にもつけてみようかな～と思い、Vue.Draggable + WebSocket で実現しようと思ったのですが、一つ微妙に、いやかなり気になる現象が発生しました。

Vue.Draggable の奇妙な動きを対症療法でなんとかする

動きが微妙なのです。
結局丸2日くらい悩んで対症療法で何とかしました。

#10.公開準備

サーバーはAWS EC2 を利用しました。
最初は無料枠のインスタンスを利用していましたが、メモリが少なすぎてパフォーマンスに影響が出たので、有料でも少しスペックのいいものにしました。
勉強代、勉強代…
ここにDBとWeb/APサーバーをセットアップして、ビルドしたモジュールを乗せるだけ。

一通り機能を作り終えたら、公開に必要なドメイン取得、HTTPS化にとりかかりました。
何か大変なんだろうな～と思っていましたが、AWSでドメイン取得、HTTPS化はあっさり完結しました。
.comドメインは年1,000円くらいかかるみたいですが…
無料より手軽さを優先しました。

準備が整ったら、あとは告知するのみ。
今回は自分がアカウントを持ってるSNSで告知しました。
このボタンを押せば告知…って思うとなかなかの指プルプル状態でした。

#11.公開後

さほど変わりはありません。
辛辣なコメントをいただき沈むこともありますが…
利用してもらうのはなかなか難しいと思ってます。
今後、どうすべきかあまり決まっていません。
公開してからが一番大事な気がしますが。

#12.最後に

開発するぞ！と決めてから公開するまで大まかにこんな感じです。
技術的な要素はほとんどありませんが、ポエムということで。
やってて思ったのは、「あ～これ絶対に解決しなさそう！」って思っても長くても一週間以内にはなんとかなるということです。
意外に解決します。
ベタですがお風呂とかトイレの中で思いついたり。

やってて「こんなサービス誰か使うのか…？」という疑問は常に付きまといます。
実際誰も使わない気もします。
でもやっぱり一回公開まで経験することは大事だと思います。
ダメならまた作ればいいだけですし。
私は心臓が剛毛なメンタル強者ではないですが、へこみつつも何とか前に進む気はあります。
なのでこれまで一度も公開用のアプリを作ったことの無い方も、一度作ってみてはどうでしょうか。