【振り返り】業務で0からシステム構築をしてWebサービスをリリースした話

はじめに

つい最近の話になりますが、小さいWebサービスをリリースしました。
ほんとに小さなもので「これ、作ったんだぜ!」と大きな声で言えないため
細々と嬉しさを噛み締めつつ、1人振り返りしてツラツラ書きます。

これから何かしらリリースする人、リリースしたい人にとって
少しでも有益な情報となり、参考になってもらえればと思います。

チーム

若手が多かったので、それぞれアドバイザーがいましたが、
ディレクター、デザイナー、プログラマ、インフラ含めて
メインは7人ほどで対応していました。

自分はプログラマ側のリーダー的な立場でした。

インフラ

小さいサイトであり、かつ複雑なサイトではないため
「こんな感じでいいよね」という感じでスムーズに進みました。

サーバのランニングコストにもよりますが、最低限、冗長化をして
予期せぬアクセス増加を見据えた方が良いと思います。
なにより運用した際の安心感が違います。

また、同時にSTG環境の用意をしました。
テスト環境なので、そんなに高スペックでなくても良いですが
本番環境でいきなり試すこともできないので、なるべく本番環境と
同等のシステムを構築した方が良いです。

ミドルウェア

新卒から数年間、Javaをやっていましたが、恥ずかしながら
Apacheのメンテ経験は0に近く、実戦経験もなかったので
WebサーバはNginxとしてました。

DBはMySQLにしてレプリケーションを行い 障害に対しての対策を行いました。

アプリ

「小さいサイトなので、効率よく開発できるものを選ぼう」という
考えはあったものの「使いたい言語で開発をしよう!」という
考えもあったので、Ruby (Ruby on Rails)を選択しました。

インフラ(ミドルウェア)構築

過去の案件でAnsibleを使った、構築手順があったので
それを流用させてもらい、今回のシステムにあった形に
書き直しました。

過去に自分で勉強して内容を理解できるところまで
やっておいてよかったと実感した瞬間でした。

コーディング

フロントエンド

デザインが上がってくるまで時間があったため
機能的なところ(バリデーション、テーブル登録)を先に実装していきました。

Railsと便利なGemの数々を使い、レールから外れないようにして
実装をしてもらい、問題なく実装することができました。

後にデザインが上がってきて、デザインの取り込みをしていましたが
やはりリッチな動きとなるとJavascriptやちょっとしたデザイン崩れが発生します。 予期していたことなので、慌てずデザイナーの人に自分の席にきてもらい
対面で一緒に考えてもらいながら対応をしました。 そのおかげで、意思疎通もスムーズに行なえ対応できました。

バックエンド

フロントエンドで登録がある場合、必ずバックエンド(管理画面)が必要となります。
ただし、フルスクラッチで作っている余裕はなく、どうすれば良いか?と
考えていたのですが、2年ぐらい前から勉強がてら作っていたものを流用することにしました。

すでにVPSのサーバで動いているので、自分の中で実績は十分あったので
バックエンドの要件定義の話になった際、サンプルとして画面を見せて
すぐに合意を得ることができました。

ただ、バックエンドもやりたいことはたくさんありますが
期間が期間のた「め本当に必要な機能のみ実装する」ということを
ちゃんと合意を取った上で開発しました。

テスト

残念ながら、Rspecの経験がなく逆にコストが
かかりそうだったため、自動テストはなしとしました。

手で動かしても問題ない規模であったため、どうにかなりました。

リリース

新規サービスということもあり、本番環境は事前に構築しておき
IP制限を行い、社内からしか見れないようにしていました。

そのため、事前に構築→IP制限外して公開ということができたので
安心してリリースを行うことができました。

リリース後

リリースしてみて、気づくこともあり、またバグもあったので
リリース後対応として対応をしています。

ただ、致命的なバグというのはない(と思っている)はずなので
ホッとしています。

反省点

リリース延期ということがなくリリースできましたが
なんやかんやで残業が多かったのが残念なところでした。
ただ、自分が使ってみたい技術をすべて使えたので
100%悪い意味での残業ではなかったです。

次に「限られた期間内でこの規模なら大丈夫だろう」という
思いがあり、軽く見積りしただけで開始してしまいました。
間に合わなければ意味がなく、残業なんてしない方が良いはずで
「定業時間内でできる範囲を考える」というのを意識すれば
良かったと思いました。
上記の弊害として、当初、他の案件も見なければならなかったため
自分がこの案件に100%コミットする感じではありませんでした。

ただ、インフラ構築、バックエンドのコーディングもやらないと
いけなかったため、他のメンバーに迷惑をかけてしまいましたが
この案件に100%コミットすることになりました。
両立できるかな?と考えましたが、甘かったです。

良かった点

自分で勉強してきたことをフルに発揮できる内容であり ある程度、実装イメージがついた状態で実装することが出来ました。
日々の勉強の賜物だなぁとつくづく思いました。

なお、勉強する内容も小難しいものではなく、単純に Railsの基本的な開発方法、サーバへのデプロイをやってみたり
機能として、ユーザー登録、管理画面の作成をやっておいた方が良いです。

チームに関しては「チーム一丸となってやる!」ということを信念を持ち
ディレクター、デザイナー、インフラの方たちと接しました。
ベストなコミュニケーションだったかと言われると難しいところですが
結果的には予定通りリリースできたので、問題なかったと思います。

まとめ

今回初めて、自分1人でインフラ、ミドルウェア、アプリを構築したので
業務を通じて、とてもためになった内容でした。

また、短期間でここまでできたのは、日々の勉強の成果もあり
少しずつですが絶えず続けてきたことが実った業務でした。

まだ、大きなシステム構築する力がありませんが
小さいことを1つずつやっていき、かつ勉強も絶えず続けて
大きなことを成し遂げていければと考えています。