初めまして、プレイライフ株式会社で昨年５月に入社したばかりで
唯一の正社員プロダクト開発エンジニアの合原ですw

当社では、現在「ホテコ」という新しいサービスを立ち上げ、サービスの検証を日々繰り返しています。
本サービスでは現在、middlemanを用いて、静的ページで、サイト開発・運用をしています。

Qiita初投稿となる本記事では、エンジニアとして、「ホテコ」のサービスローンチに当たって技術選定等どういう思考で、middlemanを採用したのか、主にその点について順にまとめます。

前提

例に漏れず、当社では、これまでのスピード感のある開発に伴い、いわゆる技術的負債も多分が蓄積しています。
そんな中、さらなる事業展開するため「ホテコ」という新サービス立ち上げることとなりました。

当社エンジニアとしての大前提

そんな中、弊社のようなスタートアップでは、いかに速くサービス展開、マネタイズするかのかが非常に重要になってきます。これは「汚いコードでもいいから速く作ればいい」、ということでは、決してありません。むしろ、そういったコードは許されません。
上記の前提からして、当社でのスピーディな開発のためには、以下の点が肝要になります。

• 1秒でも速く実現できること
• お金にならないコードは無駄
• 技術的負債を産まない

リーン開発とは

リーン開発は、トヨタ生産方式をソフトウェアの開発工程に応用させた、
プロセスから無駄を取り除くことを目的とした開発手法。
特にスクラムのようなプロジェクトマネジメントフレームワークではなく、
実践手段を提供するための手助けの役割を担う。

具体的には、ビジネスアイデア（多くの場合それは思い込み）をまずは仮説と捉えるという事。
そして最小限のコストで実装しスピーディーにリリースしてユーザーの反応を見る（計測する）。
得られたデータを精査し、反響があればさらに一歩進めて実装をしていく。
これを繰り返す事で開発コストを抑えながら仮説を実証していく方法。

前提となる必要要件

• 既存サービスへの影響はZEROにしたい
• 速くスタートできること
• 速く試し改善できるようにしたい
• サービススタート時必要なページは２ページのみ
• 将来的には、契約に応じて掲載ホテル（ページ）数が増やしたい
• 流入経路は、（ほぼ）リスティング広告のみ

上記を踏まえると、
自ずと、リーンな開発手法が想像できます。なぜなら、ビジネスアイデア自体まだ仮説であり、極論、それ自体が間違っているケースさえありえます。

そういう場合、webサーバ用意して、DB用意して、、、と作り込んでから、成果出ませんでしたでは、話になりません。
そこで、まず

既存サービスへの影響はZERO

この点についは、ドメインを分け、別環境で行うこととしました。
※ビジネス観点での考慮含む

速く改善できるようにする

上記の要件からしても、動的処理は必要ない＆webサーバすら必要ない

また、
* ページ数が少ない
* デザイン・UI・UXを手軽に変更できるようにする

ということからも、静的ページでの運用が最適と考えました。
掲載ホテル（ページ）数の増減については、営業次第で、月に何百件もあるといったことではないので、
最初から動的に量産できる状態にする必要もありません。

また、目的とするCV（コンバージョン）に最適なUI・UXも未確定な状態では、多ページに渡り共通化されたCSS等を利用するよりも、ページ毎に改変しやすい静的ページを利用する方が最適だと考えられます。

速くスタート（ローンチ）するために

上記を踏まえ
* 実装コスト低

私自身、普段Railsでの開発が主、つまりrubyに慣れていることからも、
手軽にできる方法として、middlemanを採用しました。
実際デザインカンプ上がってから、１w強で、サービスのスタートができました。

技術スタック

• middleman
• S3
• ACM
• cloudfront
• EC2（DNSレコード追加のみ）

middlemanで、主にページ作成(html,js,css等)を行い、circleciで、middlemanでbuildされたファイルS3への配置しています。

また、AWS Certificate Managerを設定したオリジン（cloudfront）経由とすることでhttps化された静的サイトを構築しています。
結果的に、ローコストでスピーディに本サービスのスモールスタートができました。

まとめ

現状は、新サービスの検証フェーズですが、特に大きなトラブルも起きていません。約1週間単位で、現状はデザインテストを繰り返しコンバージョン率のもっとも良いデザイン、UI・UXの検証を続けています。今後、リダイレクトする、量産化に向け、本運用するとなった場合などは、nuxtjsの利用や、当社のメインサービスサイトplay-life.jsと同様のRails環境下への移行なども検討しています。

手前味噌ですが、このように当社では、やりたいと思ったことができるのはもちろん、時間や労力といった観点でのコストなど、そういった点も含め自身で技術選定ができるので非常にやりがいがあります。今後も技術視点であったり、ビジネス視点であったり、当社の多岐に渡るエンジニアリングについて情報共有していくので、ぜひよろしくお願いいたします。