読者です 読者をやめる 読者になる 読者になる

kamiのサービス制作ログ

ひとりでサービスを制作している人の作業ログ的なブログ

2日間でサービスをリリースしたかったけど1週間かかったときにやったこと

めちゃくちゃなタイトルですが、表題のとおりです。 本日、SHOMEI DESIGNというメールの署名のビジネス向けテンプレート集サービスをリリースしました。

リリースの作業ログ的な記事を書いてみようと思います。 完全に自己満足記事なのであしからず……。

f:id:kami30k:20140514190134p:plain

なぜつくった?

新卒のころ、メールの署名をつくるために、ひたすらググったり、先輩社員からくるメールの署名をみたり……と、だいぶ時間を浪費した記憶があったからです。 私と同じような人がいるかどうかは分かりませんが、そんな人たちのためになればと思いつくりました。

たとえば、「署名」でググって上にくるこのまとめですら、1,600,000view以上もの閲覧数です。 需要はあるだろうという判断でした。

正直私はチャットワーク万歳な人で、コミュニケーションはすべてチャットワークに集約されればいいと思っています。 ただ、世の中からすぐにメールがなくなる訳ではありません。 であればせめて、署名という瑣末なものに時間を費やすことだけは避けよう、というのがサービスのコンセプトです。

どうやってつくった?

こんなにへっぽこなサービスですが、以下のような煩わしいプロセスのもとにつくっています。 これは、どんな規模のサービスでもつくれるよう、プロセスに沿っての反復練習をしたいと思っているからです。

以前リリースしたKPT LOGというオンラインでKPTを行なうサービスがあるのですが、これはもうすこし規模が大きかったです。 そのときの知見も含め、以下のプロセスを立てました。

このプロセスも完全にオリジナルで、サービスをつくりながらプロセスを検証、よりよいものにしていきたいと思っています。

0) 制作コンセプト

以前リリースしたKPT LOGは、細部にこだわりすぎて、1ヶ月ほど時間がかかってしまいました。 そのため、最後の方はモチベーションがほぼ0でした。

今回は、ザッカーバーグ氏の「Done is better than perfect.(完璧を目指すよりまず終わらせろ)」という言葉をコンセプトに制作しました。

1) 制作プロセス編

各項目の右にある数値は、およそかかった時間(分)です。 基本的にホワイトボードに走り書きしたものをEvernoteにドキュメントカメラで送ってます。

この記事はあくまで作業ログなので、具体的な方法論についてはまた別の機会に書ければと思います。

  • 企画段階

    • リーンキャンバス作成 60

      課題やソリューションといった項目からなるリーンキャンバスを作成します。 RUNNING LEANという本の内容を実践しています。

    • 企画書作成 5

      企画書といってもサイト名やドメイン名、提供プラットフォーム、CSF(主要成功要因)など、リーンキャンバス以外に必要な情報を簡単にまとめます。

    • 関連サービスのデザイン調査 30

      最近のサービスがどんなデザインなのか調査します。 Siiimpleというサイトが参考になりました。

    • デザイン制作方針決定 15

      調査結果をもとに、どんなトンマナでつくるかを決めます。 署名を手っ取り早く見つけることができればいいので、至極シンプルにつくろうと決めました。

    • ストラクチャ作成 5

      どんなページ構成にするかを決めます。 マインドマップなどを使うと便利です。 今回はトップと利用規約だけでした。

    • ワイヤーフレーム作成 30

      ストラクチャをもとにワイヤーフレームをつくります。 ホワイトボードで適当に書きます。

    • プロジェクト管理ツールの設定 5

      以前はPivotalTrackerを使っていたのですが、ちょっと機能過多すぎるかなと思っていたので、今回はTrelloを使いました。 結論かなりよかったです!

    • ストーリーリスト洗い出し&登録 30

      ストーリーを洗い出し、Trelloに登録します。 Inbox/ToDo/ToDo:Today/Doing/Doneといったボードをつくって管理しました。

    • リリーススケジュール作成 15

      リリースまでのスケジュールをつくります。 表題のとおり今回「2日でつくるぞ」というスケジュールを引き、あえなく散りました。

    • 採用技術選定 15

      あとで詳しく書きますが、どのような技術を使うかを決めます。

    • ネットワーク構成図作成 5

      開発端末、CIサーバ、ステージング(あれば)、本番環境などの構成図を書きます。

    • AARRRシート作成 15

      今回は小規模なサービスなのであまり詳しくかけませんでしたが、ユーザをどのように獲得するか、どのように拡散させるかといった内容をまとめます。

  • 開発段階

    • サーバ契約 5

      さくらのVPSが大好きなのでこちらにしました。 個人でつくっており、お金がないので……。

    • 独自ドメイン取得 0

      実は半年前にこのサービスを思いついたときに先走ってドメインだけ取っていました。

    • デザイン制作 60

      デザインはFireWorksで作成しました。 そこまで詳細には作らず、コーディングでpx単位で調整していきます。

    • コーディング 180

      KPT LOGをつくったとき、さすがにスマホで見れないのはつらいと思ったので、今回はリキッドデザインでつくりました。 GuardでHaml/SCSS/CoffeeScriptをヲチしながらサクッとつくりました。

    • データベース設計 5

      データベースはほぼないに等しい仕様でした。 これもマインドマップなどでつくります。

    • アプリケーション設計 120

      後述しますが、今回はじめてSinatraを使ったので、ディレクトリ構成をどうすれば効率がよいかを考えて設計しました。 なので、すこし時間がかかってしまいました。

    • テストケース作成 15

      今回ページ数がすくなく、またユーザ登録/認証などがないため、テストケースは少なく済みました。

    • 開発環境構築 5

      ローカルにGemfileをつくってbundle installするだけなのですぐ終わりました。 KPT LOGのときはVagrant+Chefで構築したので、勉強しながらで3日ほどかかりました……。

    • バージョン管理設定 15

      プライベートリポジトリにしたいけどお金がないので個人的にBitbucket一択でした。

    • CI/本番環境構築 60

      これもKPT LOGのときに書いたChefレシピをほぼ流用したのですぐ終わりました。

    • 独自ドメイン設定 5

      これはドメイン管理会社のコンパネをいじるだけなのですぐ終わります。

    • デプロイツール設定 60

      Capistranoでデプロイしていますが、これもKPT LOGの流用でした。 ただ、Unicornの起動関連タスクがうまくいってなかったようで、書き直しに少し時間がかかりました。

    • ビルドパイプライン設計 5

      CIツールのビルドパイプラインを設計しました。 といっても今回はテスト→トリガによる本番デプロイのみにしました。 KPT LOGのときはserverspecによるテストやステージング環境へのデプロイなどもありました。

    • CIツール設定 60

      Jenkinsの設定をしました。 CIサーバ自体はKPT LOGのときに構築していました。

    • 実装 240

      設計したアプリケーションやデータベースをもとにコードを書いていきます。

  • リリース前段階

    • セキュリティチェック 15

      これは以前徳丸先生の本を参考に、自分なりのセキュリティチェックリストをつくりました。 それをもとにチェックを行ないました。

    • 動作確認 15

      MacSafari/Firefox/ChromeIEWin7+IE8〜IE11で動作確認しました。 Windows環境はModern.IEを使いました。 IE8は切り捨てました。

    • アクセス解析ツールの導入 5

      Google Analyticsを本番環境時のみに適用するようコードをコピペしました。

    • バックアップの設定 0

      今回ユーザが登録する類のものではなく、またSQLiteを使ったためバックアップは取っていません。 KPT LOGのときはBackup+Wheneverで1日ごとにバックアップを取っていました。

    • リリース時プロモーション施策案作成 5

      この記事もそうですが、どうやってリリース直後の初動を増やすかを考えました。 ただ、SHOMEI DESIGNに関してはほぼほぼSEOなので、あまり初動の数字にはこだわらないようにしました。

    • 署名整理 180

      今回使用した署名は、実は半年ほど前クラウドワークスのタスク型案件で依頼したものです。 なので、署名の在庫自体は数多くありました。 ただ、このクオリティを担保するために整理する作業にかなり時間を取られてしまいました。

  • リリース段階

    • 本番環境の公開設定 5

      公開までは簡易的に認証をかけておき、公開時にとるよう設定します。

    • プロモーション施策実施 5

      今回はTwitterで告知しただけでした。

2) 採用技術編

今回は以下の技術を用いて開発を行ないました。 いままでRailsしか使ったことがなかったのですが、今回は規模も小さいということでSinatraを採用しました。

いま公開している仕様なら単なる静的ファイルでいいかもしれませんが、のちのち実装したい機能を考えてフレームワークを使いました。

リリース後の所感

  • Twitterで告知した程度じゃ人は全然来ない、でも他にプロモーション方法が思いつかない……
  • Sinatra+SQLiteの快適さがやみつきになりそうなくらい楽しい
  • リキッドデザインが思いのほか簡単だった
  • 一番やりたかった「コードを書く」ということが、仕様が簡単すぎたため全然できなかった

おわりに

実は「4月〜9月の間に20個のサービスをつくる」という個人的な目標を立てているのですが、初めて使う技術が多く、勉強にかなり時間が取られています。 もっと早いサイクルでサービスをリリースできるよう、努力していきます。