Help us understand the problem. What is going on with this article?

[個人開発]大喜利サービスを5日でつくってわかったこと

サービスイメージ

サービスイメージ
ひとこと大喜利「ザブトン」
https://zabuton.co/
誰でもすぐ簡単に大喜利が投稿でき、
SNS主体で大喜利を楽しむことができる
そんな大喜利サービスを開発しました。

はじめに

個人開発でサービスはいくつも作ってきましたが
こういった記事を書くのは初めてです。

後半の方でコードもGithubにて公開していますが、
文章、コード共に拙い部分がありますが、何卒お目溢し頂ければと思います。

筆者について

僕は元々はゲーム会社出身ですが、
メンタルやられて退職してからフリーランスとなり
サービス乱立したりしながら生計を立てている20代エンジニアです。

ただ、エンジニアという職業は手段であって、
僕の目的はものづくり(サービスつくり)です。

今までは外界との接触が苦手で
TwitterやGithub、QiitaやQrunchといったサービスなどを
利用して自分から発信することはなかったのですが
一人での活動に色々と限界を感じてきて
自分の活動内容やサービスを公開していこうという運びとなります。

1月からTwitterも初めてみました。もしよろしければどうぞ。
Twitter

つくったサービス詳細

サービスロゴ
ひとこと大喜利「ザブトン」
https://zabuton.co/

最初にも記載しましたが、大喜利サービスをつくりました。
このサービスのポイントは3つあります。
・大喜利の"回答"のみに特化したサービスサイト
・回答はTwitterへシェアする前提の設計
・OGPでお題、回答が概観できること

このサービスは大喜利の回答(コンテンツ)をTwitterへのシェアありきで作った、というところがポイントです。
競合大手の大喜利サービスではプラットフォームとしてコミュニティを形成させています。
(サービス内で閲覧→回答→閲覧のフローを促し回遊させ、継続させている)
ただ、結局のところコンテンツがどういった経路を辿り人々の目に触れていくかといえば、
結局はSNSだったりの影響が大きいのかと感じています。

そこで、コンテンツをサービスサイト内で流通させることなく、
Twitterでの流通に限定するようなサービスフローにしたらよいのではないか、という発想でこのサービスをつくりました。

・大喜利の"回答"のみに特化したサービスサイト
・回答はTwitterへシェアする前提の設計
・OGPでお題、回答が概観できること

はじめにあげた3点のうち、最初の2点については上記の発想からの理由で、
最後の1点については、このようなサービスフローにするということは、
Twitter上でもストレスなく1つのTwitter上のコンテンツとして閲覧できるような
設計にすべきだという理由からです。

なぜ作った

僕の目的サービスづくりであり、
多くの人に利用してもらい、売上を立てることです。

それを前提とした上でザブトンを作った理由は、二つです。
- 市場が大きいこと
- 既存サービスへのUX不満

一つめから説明します。

・市場が大きいこと
これはそのままの意です。
いまだに、某大手大喜利サービスにおけるコミュニティの活発性や
ニュースアプリ、まとめ系ブログなど様々な場所で取り上げられています。
日本のテレビ番組がお笑い一色なことからもわかるように
日本人の性質として"お笑い"に関して興味が高いことがわかります。

基本的に僕がサービスを作るときには
ニッチゆえに競合がいないブルーオーシャンは避け
必ず、競合もいるが需要が確立されているレッドオーシャンを攻めます。

ニッチな業界でのグロースハックはとんでもない根気と労力がかかります。
そもそも市場にユーザー数が少ないうえに、新しいサービス利用に対しての敷居の高さがあるからです。

なのであれば、レッドオーシャンだが需要(ユーザー)が溢れている市場から0.01%を取りに行くだけの方が、僕としてははるかにやりやすい。

そういった理由があります。

・既存サービスへのUX不満
かくいう僕もお笑いは大好きです。
くすっと笑える小ネタも、腹を抱えて笑える漫才も、
人の心を暖かくする、とてもハッピーなものだと考えています。

そこで、現在一強であるお笑い系サービス"bo●●te"さんですが、
実際に投稿者側として利用しようとするととんでもなく使いにくいです。

例えば、「ちょっと面白いお題を思いついた!」という場合にboketeを検索します。
選択肢は2つ。
1:アプリ
2:Web
まずはアプリから試してみました。
アプリをインストールし、開いてみるとまず「ログイン画面」。
まず会員登録しないと進めません。この時点で断念。

次にWebを試してみました。
TOP→お題一覧→お題詳細→このお題でボケる(おっ!)→

ボケたりお題投稿するには、ログインするか新規登録が必要です。

そうです。お題を登録したりボケたりするには会員登録が必須なのです。
しかもSNSログインもなし、いまどきメールアドレスを登録させるという苦行。

これには僕も膝から崩れ落ちました。
これではお笑いが廃れてしまう、と。

ただ、b●ke●eさんのサービス性を否定するわけではありません。
なぜならば、サービス内におけるコミュニティはかなり強固なものになっているし、
そのコミュニティに所属する人たちによっては大きな心の拠り所だと感じるからです。
そもそもこういったネットにおける大喜利が普及したのは、このサービスのおかげでしょう。

ただ現代のインターネット属性に合致しているかという部分で非常に疑念を抱いてしまったので
下記3点をポイントとして掲げ、サービス開発へと乗り出した経緯があります。

・大喜利の回答のみに特化したサービスサイト
・回答はTwitterへシェアする前提の設計
・OGPでお題、回答が概観できること

制作スケジュール

工程 工数
企画構想 3時間
ワイヤー作成 30分
デザイン 4時間
コーディング 5時間
インフラ&バックエンド 4日

TOTALで3日くらいで作りたかったのですが、
他作業もちょこちょこしたりして結局TOTAL工数としては一週間弱かかってしまいました。
あとは、OGP画像の自動生成ロジックになかなか手こずってしまいました。
企画〜コーディングについては慣れたものでトータル1日ちょっとでした。
ただ、かの有名なpeing(質問箱)を作ったせせりさんは、
peingを6時間で作ったとのことなのでまだまだ精進のしがいがあるなというところです。

なお、僕の場合、とにかく早く作って出すということを大前提にしているため
こういったスケジュール感になりがちです。

余談ですが、Facebookのマークザッカーバーグの言葉で好きなのがこちら。
「完璧を目指すよりまず終わらせろ」

途中経過

ワイヤー

ワイヤーサンプル
※ちなみにこれは違うサービスのワイヤーです。ザブトンのものはデザインで上書きしてしまって、残してありませんでした...すみません。

ちなみに、チームワークの場合と個人開発の場合では「ワイヤーフレーム」の利用用途は異なるのを前提として
僕の場合は、ワイヤーはこんな感じで機能要素だけをドカッと置いて、画面概要の確認にとどめます。
これにより工数の詳細な算出、必要な技術の確認を改めてしていきます。

デザイン

デザインサンプル
デザインは、そのままコーディング出来るレベルまで詰めます。
だいたい他サービスの同じコンテンツブロックを参考にさせていただきながら作っていきます。

正直、僕くらいのデザインレベルだとこだわっても対してクオリティ変わらないので、速度重視で作っていきます。

コーディング

コーディングサンプル
※左デザイン、右コーディングです

デザインだけではわからなかった、要素を追加していきながらコーディングしていきます。
今回の場合、ヘッダーをTOPにつけるかというのはデザイン時点ではやめていたんですが、
実際に触ってみるとヘッダーがないとめちゃくちゃ不便だったため取り付けています。

あとは、僕の場合XDを使ってワイヤーからデザインまで組みますが、
XDはカラーマネジメントしてくれずWebに乗せると色が変わってしまうので、
コーディングするときの感覚で色なんかも変えていっています。

利用技術

ホスティングはAWS
Linux(Amazon Linux)
Apache
MySQL
PHP
フレームワークはcakephp3系
Html(css/js)

今回は最低限しか利用していません。
サービスとしてログインや会員登録がなかったので、
サードパーティのAPIやライブラリもほとんど使ってません。
画像の合成にはImagineを利用しています。

ソース

https://github.com/nsk-dev-gh/zabuton
こちらにまとめてあります。
Cakephp3系の
src配下とwebroot(img/css/js/font)配下をアップしておきます。
利用ライブラリは前述の通りImagineのみです。

今回、Serviceを利用せずにController内でサービス処理を記載していたり
画像合成まわりの関数の可読性が最悪だったりするのですが
もしご参考になれば自由にご利用ください。

ControllerはPagesのみを利用しています。
app.phpで下記記述をすることでURLからコントローラー名を排除しています。

$routes->connect('/', ['controller' => 'Pages', 'action' => 'index']);
$routes->connect('/:action', ['controller' => 'Pages']);

まとめ

今回はサービスリリースを目処として、この記事公開とさせていただきました。
ただ、広告を貼ってることからも収益が出始めた場合には、
アクセス数の情報や、売上なども公開していく予定です。

他にもサービス作りを頻繁に発信していく予定ですので
改めてになりますが、よろしければTwitterフォローの方もよろしくお願いします。

Twitter

長々とした内容をここまでご拝読いただき
ありがとうございました!

ひとこと大喜利「ザブトン」
https://zabuton.co/

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした