FJORD, LLC（合同会社フィヨルド）

怖話（http://kowabana.jp）の1月のアクセス数と収益のまとめです。
（怖話とはスマホで怖い話がサウンドノベル風に見れる・投稿できるWebサイトです。）

アクセス数

約32万PVでした。先月が25万PVで先々月が19万PVなので徐々に増えてる感じです。PVは「怖い話」で検索した時の順位の変動に大きく影響を受けてます。

収益

約6.6万円でした。先月よりRPM（1000PV辺りの収益）が大きく下がっているので余り増えていません。Amazonは外しました。

今後

1月は投稿UIを改良して、Twitter・Facebookボタンをわかり易くしましたがあまりつぶやかれていません。（夜23時になると自動で怖い話をつぶやくkowabanaボットの方が役に立ってます。）

サウンドノベル風というからには音が必要です。音は怖さに大きく影響するので是非付けたいです。しかし、iPhone Webでは現状難しいのでiPhone版、Android版クライアントを開発予定です。

コメントはまだありません

怖話（http://kowabana.jp）の12月のアクセス数と収益のまとめです。
（怖話とはスマホで怖い話がサウンドノベル風に見れる・投稿できるWebサイトです。）

アクセス数

約25万PVでした。先月が約19万PVなので微妙に増えたという感じです。やはり年末はアクセスが落ち込んでますね。怖い話見てる場合じゃないか・・・。

収益

約6万円でした。PVはそれ程でもないのに収益は約2倍になっています。CTRやCPCが先月より上がっています。なんででしょうね・・・。

Amazonアソシエイト

私的に期待してたのが新しく付けたAmazonアソシエイト。メジャーなサウンドノベルゲーム、真かまいたちの夜が発売されるのでこのサイトにぴったりでは？と思って貼ってみました。

0円でした。

おいィ？

どうやら私の考えてるユーザー像は全くの的外れのようです。コレ外そう。すぐ外そうよ。ね？邪魔だし・・・。

今後

もう少しアクセス数が増えたらアドネットワーク（Adsenseみたいな奴のことをそういうそうです。）以外の収益方法も模索してみようと思っています。怪談や占い業界の方と何かコラボレーションできればと思うのですが・・・。手助けしていただける営業の方がいらっしゃったら@komagata, @machidaまでお願いします・・・。

コメントはまだありません

怖話 (http://kowabana.jp)の11月のアクセス数と収益のまとめです。（なるべく毎月公開したいです。）

アクセス数

月間約19万PVぐらいです。8月は約5万PVだったので4倍ぐらいになってますが、もっと増えて欲しいところです。

使われてる端末はもう圧倒的にAndroidですね。怖話はPC版もありますが、全部の中でAndroidブラウザーが60%っていうのはかなりのシェアだと思います。

収益

Google AdSenseを貼っています。月間約3万円ぐらいです。今の20倍ぐらい欲しいです…。

広告については全く分からないので、知り合いについていって広告代理店2社にお話を聞かせてもらいに行ったり、営業の電話が掛かってきたときに聞いて勉強していますが、イマイチGoogle AdSense以外を使うメリットがよく分かってないです。

（本当に不勉強なのでコツなどあれば教えて頂けるとありがたいです。）

年末年始は確かインターネット全体の利用率が下がるはずなので12月は余り期待できませんが、最怖のサイトを目指して改良を続けます。

1件のコメント

僕らはデザイナーとプログラマー２人の会社なのでWebサービスを作るのは得意なのですが、宣伝やマネタイズが深刻なほど下手です。

営業の方やマーケティングが得意な方会うたびにに「どうしたらいいですかね？」と聞いて回っています。

「このままじゃイカン！」

ということで怖話では初めてプレスリリースを書いてみました。

スマホで怖い話が1万7000話。怖い話投稿サイト～怖話～がリリース

合同会社フィヨルド（所在地：東京都渋谷区本町1-36-11ドエルヤマト203 駒形真幸）は、
スマートフォンで1万7000話以上のサウンドノベル風怖い話が読める『怖話.jp』
(http://kowabana.jp)を8月9日にオープンしたことを発表する。

常識かもしれませんがValuePress!というサービスで無料でいくつかのメディアにプレスリリースを打てるそうです。文章に全く自身が無かったのでたまたまオフィスにいらっしゃっていた子供とお出かけサイトいこーよの営業をされている@masasan1980さんに見てもらって直したりして送信しました。

掲載すると、とりあえず「うちのメディアに広告を掲載しませんか？」という営業の電話が沢山かかって来ましたorz…

しかし、女性向けのスマートフォン情報サイトのプリマ！様から記事の掲載依頼が来て載せてもらいました。

plima! » こわ～い話で盛り上がっちゃおう

僕らも怖い話は女性の読者が多いと感じていたところだったので嬉しかったです。しかしずいぶん前に掲載していただいたのに今更これを紹介するのは関係無い受託案件で僕らがデスマってたからです・・・。

PVはプレスリリース打った３日ぐらいはちょっと上がりましたがすぐ元に戻りました。なかなか難しいですね・・・。

コメントはまだありません

怖話を開くといきなり始まる怖〜いムービー。

これ、HypeというMacのアプリで作りました。

Hype

Hypeはすごく簡単にHTML5のアニメーションが作れて、しかも値段は ¥2,600！（2011年9月現在）
HTML5でムービーが作れるのでiPhoneでもちゃんと表示されます。

ホームページ制作会社の方がiPhoneサイトを作る際にHypeでムービーを設置したら、よりお客さんに満足いただくものを納品出来そう。操作は簡単なので、使い方を説明するまでもないのですが、まぁ、こんなことが出来るっていうのの参考に、Hypeの使い方や手順をこちらで紹介したいと思います。

Hypeを購入、インストール

HypeはMac版しかありませんので、Windowsの方はMacを買うところから（Macの購入はこちら）。

HypeはMac App Storeで購入します。こちらクリック。Mac App Storeなので金額が書いてあるボタンをクリックすればあとは勝手にインストールしてくれます。

今回つくるもの

今回はHypeを使って7枚の画像がそれぞれ別の動きをしながら次の画像に切り替わるスライドショーを作ることにしました。

画像が切り替わるまでの時間はそれぞれ8秒にします。8秒たったら次の画像に切り替わります。

「それぞれ別の動き」は、Hypeで簡単に設定できるシーンの切り替わり方の機能をそのまま使います。シーンの切り替わり方の一覧は以下になります。

シーンの切り替わり方の一覧

• Instant … 何の効果もなく次のシーンへ
• Crossfade … 前のシーンがフェードアウトしながら次のシーンがフェードイン
• Swap … 立体的に前のシーンが後ろに下がって次のシーンが前に現れる
• Push（Left to Right） … 左から右にスライド
• Push（Right to Left） … 右から左にスライド
• Push（Bottom to Top） … 下から上にスライド
• Push（Top to Bottom） … 上から下にスライド

…と、字にしてもいまいちわかりずらいですが、実際どう動くのかは出来てからのお楽しみ、ということで。

で、せっかくHypeはHTML5で書きだしてくれるので、iPhoneサイズでスライドショーを作り、iPhoneでも見れるようにしたいと思います。

ムービーのサイズを設定

では、早速Hypeを開いてみましょう。
「File > New」をクリック。

これからムービーを作るキャンバスが用意されました。

まずは、キャンバスのサイズを設定します。今回はiPhoneでも見られるように横幅を 320px、高さ198px のムービーの作成に挑戦したいと思います。

キャンバスと一緒に表示されたツールバーのココ（下図参照）をクリック。

で、ココ（下図参照）に「横幅を 320px、高さ198px」を入力。

Option について

先ほど横幅、高さを入力したボックスの下に「Options」というチェックボックスがあります。

「Show Loading Indicator」にチェックを入れると、ムービーを読み込んでる間、

というメッセージが表示されるようになります。

その下の「Draw Scene Backgrounds」にチェックを入れると、「Animation Timelines」で設定したBackgroundのcolorが有効になります。背景に色を付けたい場合はここにチェックを入れます。
今回はスライドショーを作ることに今決めました。なので今回は「Draw Scene Backgrounds」にチェックはいりません。

それぞれのシーンで表示させる画像を用意

それぞれのシーンで表示させる画像を７枚用意しました（合計7シーン）。

それぞれの画像に「次はXXXXで切り替わります。」という文字が入ってます。これは先ほど説明しました「シーンの切り替わり方」です。

例えば、

から、

へ、シーンが移動する際は、「Instant … 何の効果もなく次のシーンへ」の動きで切り替わります。

ちなみに今回使っている画像は、神戸市のデザイン事務所『Aqua style』さんが運営していらっしゃる、無料の写真＆イラスト素材サイト「Do U like? 」のものを使わせていただきました。ちなみに「Do U like?」はこれ以上ないくらいのゆるさで画像を配布してくれてる太っ腹なサービス（Policyはこちら）。「Do U like?」大好き！

シーンに画像を配置

画像をシーンに配置してみましょう。

「Insert Elements」をクリックして、「Image」を選択します。

この画像を選択します。

配置されました。

シーンに名前を付ける

今作った「次はInstantで切り替わります」という文字が入った画像が配置されたSceneに「next_instant」という名前を付けます。

ココ（下図）をダブルクリックで、名前を付けます。

シーンの追加

続いて、新たなシーンを追加してみます。

ココ（下図）をクリック。

このシーンにはこの画像（下画像）を配置して、「next_crossfade」という名前にします。

完成。

この手順（シーンの作成→画像の配置→シーンに名前を付ける）を７枚の画像それぞれに対して行います。

シーンの名前は、

• next_instant
• next_crossfade
• next_swap
• next_push_l_r
• next_push_r_l
• next_push_b_t
• next_push_t_b

と、します。

…7個のシーンが出来ました。

シーン「next_instant」のアニメーションの設定

最初のシーン，「next_instant」のアニメーションの設定を行います。

アニメーションといっても、今回は8秒間待ったら次のシーンに切り替わるスライドショーを作るので、ただ単に、「8秒間待ったら次のシーンに切り替わる」の「8秒間」の設定を行うだけです。

シーン「next_instant」を選択（クリック）します。

下のTimelineのカーソルを「00:08.00」に持ってきます。

次に、「Main Timeline」の下の部分をクリックして選択した状態にします。

菱形のアイコンがあるボタンをクリック。

すると、タイムラインの8秒のところに菱形のマークが置かれます。

これでシーン「next_instant」は8秒間ジーッと画像を映すだけのアニメーションが設定されました（実際何も動いていないのでアニメーションではありませんが…）。

では、全部のシーンにこの設定をしてしまいましょう。

シーンからシーンへの移動の設定

「next_instant」を8秒見せたあと、「next_crossfade」に移動する、という設定を行います。

シーン「next_instant」を選択（クリック）します。

次に、ツールバーのココをクリック。

「On Animation Complete」に注目。「On Animation Complete」は「アニメーションが終わったら何をするか」、という設定をするところです。

「On Animation Complete」の「Action」を「Jump to Scene…」を選択。
その下の「Scene」に「next_crossfade」を選択。
「Transition」に「Instant」を選択。

アニメーションが終わったら、シーン「next_crossfade」に「Instant」の動きで移行する、という設定をしました。

では、続いて、

シーン「next_crossfade」、シーン「next_swap」への移動の際は「Swap」。
シーン「next_swap」、シーン「next_push_l_r」への移動の際は「Push（Left to Right）」。
シーン「next_push_l_r」、シーン「next_push_r_l」への移動の際は「Push（Right to Left）」…

と、それぞれに順番に動きを設定していきます。
最後のシーン「next_push_t_b」はシーン「next_instant」へ移動するように設定して、延々とスライドショーがループするようにします。

書き出し

全シーンの設定が終わりましたらいよいよ書き出し。
その前にプレビューで確認をする際は、こちらをクリック。

では、書き出し。

File > Export As HTML5 > Folder をクリック。

なんか色々Warningが出てきました。

今回使ったHypeで簡単に設定できるシーンの切り替わり機能はIEだと全滅ですね。まぁ、今回はスマホだったらWindows Phoneを除けばOKだからよしとしちゃいます。

完成したのがコレ。

8秒は確認するには長かったので、2秒でシーンを移動するバージョンを作りました。こちら。

コメントはまだありません

Issue82の続き

こちらの開発レポート、プログラマー側はどうやっていくか実際のIssueをこなしながら紹介したいと思います。

Github for Mac を使ってデザイナーがブランチ作る、怖話の開発レポート | FJORD, LLC（合同会社フィヨルド）」

といってもプログラマーは黒い画面で黙々といつも通りやるだけなので目新しいことはありませんが・・・。

% git branch -a
  issue20
  issue26
  issue28
  issue47
  issue52
  issue71
* master
  refactor-string_size
  remotes/heroku/master
  remotes/origin/Issue82
  remotes/origin/master

@machidaさんが作ったIssue82ブランチがちゃんとありますね。（今度から全部小文字にしましょうと話しましたｗ）

% git pull origin Issue82

さて、該当のコードを見てみます。

あー、なるほど。数字の桁数が全部枠で囲われるデザインである以上、こういうマークアップになるのは仕方が無いけど、プログラムが面倒だな・・・。

文字をspanタグで装飾するhelperを作ります。

# test/unit/helpers/home_helper.rb
require 'test_helper'

class HomeHelperTest < ActionView::TestCase
  should 'decorated_story_count return decorated html' do
    assert_equal decorated_story_count(17000), '<span class="number">1</span><span class="number">7</span><span class="comma">,</span><span class="number">0</span><<span class="number">0</span><span class="number">0</span>'
  end
end

こんな感じのhelperがあれば楽かなあ。

テスト。（通常はrake testとguard-testを使っています。）

テストが通るようにします。

こんな感じかな？

OK。

decorated_story_countをviewに埋め込んで、後は怖話をランダムで読む部分。

これは重そうだ・・・。サイトの人気が出てアクセス増えたら直します・・・。

% git commit -am 'fixed #82'
% git pull origin master
% git rebase master
% git checkout master
% git merge Issue82
% git push

topic branchをmasterにmargeしてpush。

こちらに書いた通り、git pushするとgithubの該当issueが閉じて、jenkinsでテストされ、staging環境にdeployされます。

staging環境をPC, iPhone, AndoroidでチェックしてOKだったらproductionにdeployします。

良さそう。

% cap production deploy

で完了です。

zip納品 vs Githubインテグレーション

一般的なやり方（htmlとcssが毎回zipで送られてくる）とGithubインテグレーション（Issuesに登録しておくと勝手にできてる）を比べてみると生産性が圧倒的に違います。デザイナーもGithubを使ったWebサイト開発のイテレーションの中に入るべきだと思います。

一般的なやり方の場合にプログラマーが何をやっているか思い出してください。zipを解凍して、まず前回のzipとどこが違うのかわからなくなる。diffを取る。直接railsに置けるわけではないので、前回との差分を試行錯誤しながらrailsに入れる。何かちょっとデザインがズレた。どうやってデザイナーに伝えよう。該当部分をブラウザからhtmlに保存してメールする？・・・ああ、考えただけでも面倒くさい・・・。

デザイナーにとってはGithub for Macを使えるだけでなく、ローカルにRails環境が作れる必要もあるので若干敷居が高いですが、それを補って余りあるメリットがあると強く感じました。

1件のコメント

只今開発中のサービス、スマホで怖い話が17,000話以上が無料で読めるサイト「怖話」のIssueをGithub for Macを使ってブランチを作って作業をしたので、それのレポート。

今回はこのIssueをやってみます。

開発にはGithubにリポジトリを置いて、Issueの管理もGithubを使ってます。

このIssueで解決させたい問題と解決策

怖話には17,000話以上もの怖い話があるんだけど、全然そんなにあるように見えない！

なので、トップページにババンッと現在の怖話総数を表示します。

サイトを開いたらすぐに怖話を読みたい！

怖話の総数の横にランダムで怖話の個別ページに飛ぶリンクを配置します。

今回の簡単なラフ

こんな感じで作ってみようと思います。

ブランチ作成

今回はデザイン（コーディングも含む）を先に作って、後からkomagataさんにその部分にシステムを入れてもらう、っていう手順で進めていきます。

まずは今回のIssue用のブランチを作成。
Github for Macを使うとブランチ作成がすごい楽。Github for Macを使って作業を進めていきます。

Github for Macでkowabanaリポジトリを表示。Wクリック。

ブランチを表示。

ブランチを追加。今回は「Issue82」というブランチを作りました。

Issue82ブランチの作成直後は、Issue82ブランチが選択された状態になります。

これだけで、デザイナーにとってはちょっと怖いブランチの作成作業があっという間に完了。
UIも直感的！

デザイン＋コーディング

では、先ほど作ったdesignブランチにデザインを入れていきます。
ローカルで怖話を立ち上げて作業開始！

ちょこちょこっといじって … 完成。

リモートリポジトリへpush

まだデザインとコーディングが出来ただけで、システムは入っていない状態。
このブランチをpushして、komagataさんにシステムを入れてもらって、masterのブランチにマージしてもらいます。

Github for Macを使ったcommit

まずは作業内容をcommit。commitもGithub for Macを使ってやってみます。

「Changes」をクリック。

今回の変更点、追加画像ファイルなどが表示されています。チェックボックスでcommitする内容を選択できるのはかなり便利！

「1回のcommitには一つのIssueだけにする」、という決まりがあったのにcommitを忘れていた、なんてことがあった場合、commitを小分けすることが出来ます。
今回は一つのIssueの作業しかしてないので、全部のチェックボックスにチェックを入れます。

commitメッセージを記入したら「Commit Chenges」ボタンをクリックしてcommit。

Issue82ブランチにcommitしましたよ、と表示されました。

push

では、いよいよリモートリポジトリへpush。

Branchesに戻って、Issue82ブランチの「Publish」ボタンをクリック。

pushをすると、lingrの社内チャットにメッセージが流れるようになってます。

では、Githubに行って確認してみます。

出来ました！

Github for Macを使えばデザイナーでも簡単にブランチを作ってpushが出来てしまうのでオススメ。

3件のコメント

こちらのエントリーが大変参考になったので、僕らが作ってる怖話.jp（kowabana.jp）のシステム構成や開発方法についても公開していこうと思います。

怖話.jpはスマホ向けWebサービスなのでPC向けとはPVとかの傾向がちょっと違うかも知れません。

怖話.jpとは

スマホで17,000話以上のサウンドノベル風の怖い話が閲覧・投稿できるサイト（アプリではありません）です。詳しくは下記エントリーを参照してください。

スマホでサウンドノベル風怖い話投稿サイト | FJORD, LLC（合同会社フィヨルド）

7月16日にRubyKaigi2011に合わせて無理矢理ベータテストオープンして、8月9日に正式オープンしましたので正式オープンからは１ヶ月経ってないまだまだのサイトです。開発期間は約１ヶ月ぐらいです。

サイト情報

（これAnalyticsを直接貼るのはどうやればいいんだろう？）

直近一ヶ月のPVは49,220です。特徴としては、平均滞在時間が4:58とちょっと長い。直帰率が55.37%とちょっと少ないという感じでしょうか？

サーバー構成

サーバー：さくらVPS512（月額980円）

（社内で唯一の共通ステージング環境兼CIサーバーとしてさくらVPS512を別途借りています。）

ミドルウェア

OS：Debian Squeeze

Webサーバー：nginx（静的ファイル配信）

Appサーバー：unicorn

DBサーバー：MySQL

Ruby：1.8.7

Rails：3.0.8

CI：Jenkins

Deploy：capistrano

Testing Framework：shoulda

Integration Test：Test::Unit + Capybara（Capybara.default_driverはWebkit。時々Selenium）

Fixture Replacement：なるべくfixturesをそのまま使う。

Mock：なるべくfixturesや実DBを使う。時間関係や外部サービスの部分につかうMockは検討中。
（プログラマーが１人なのでテストの実行時間は余り気にならない。寧ろテストコード作成をどれだけ短時間でできるかを重視しています。）

（RubyとRailsはRails3.1が正式リリースしたらRuby1.9.2, Rails3.1にアップデートしようと思ってます。）

サーバー監視

pingdom

昔作ってたサービスではLivedoorデータホテルパトロールやmontasticなどを
使ってました。pingdomは無料プランの制限がキツイのでmon.itor.usを検討しています。）

参考：ホントに小規模なサービス運営者のためのサーバ監視入門 – もぎゃろぐ

リソース監視

Librato Silverline

各ソフトウェアのCPU・メモリ使用料などを素敵っぽい見た目で見せてくれます。Githubが使ってるらしい。CPU 8 Coreまで無料なのが嬉しい。さくらVPS512は2 Coreなので。

開発フロー

デザイナー: @mahicda

プログラマー: @komagata

の二人で作っています。

1. Github IsseusにIssueを登録する。（Privateリポジトリ）
2. プログラマー・デザイナー共にローカル環境でテスト・実装し、Githubにpushする。
3. LingrのFJORD, LLCに通知が来る。
4. GithubのPost-Receive URLsで自動的にJenkinsのテスト+ステージング環境

（kowabana.fjord.jp）へのデプロイが行われる。 （コケた場合はメールで通知が来る）

5. ステージング環境でiPhone+Androidでの動作確認をし、問題無ければ@komagataがローカルからプロダクション環境にデプロイ（$ cap production deploy）する。
6. 1に戻る。

社内の情報のやり取りはIRCではなくLingrを使っています。（IRCはデザイナーにちょっと敷居が高いきがするので。SkypeはP2Pなので2人のタイミングによっては暫く情報共有されないことがあるので。）

感想

僕も@machidaさんも以前の会社では社内サーバーにSVN+Skype+Redmine+capistrano+cronベースのCIを行っていたので、ツールがちょっと変わったぐらいで基本的なフローはたいして変わっておらず、あまり戸惑うことはありませんでした。

とはいえ、移行前につかっていたHerokuに比べれば大分面倒です。Lokkaの開発で使っていますが、オープンソースであれば、Heroku + Travie-CIの方が楽かなとは思います。

サーバーの性能に関してはHerokuに比べたら面倒な代わりに大分余裕がある感じがします。さくらインターネットは国内バックボーンへの回線が凄く太い印象があります。今までの経験からの超感覚的な数字なんですが、Railsプログラミングで特殊なキャッシングなどをしなくても50万PV/月ぐらいは全く問題無さそうなイメージです。Herokuは楽ですが、2 Dynosになった時点でさくらVPS512よりお金掛かるので・・・。

50万PV行ったら単にDBサーバー用にさくらVPS512をもう一台借りるかなあぐらいに楽観しています。

スマホならではの部分では、見た目小さいですが、画像の解像度が相当高いので写真などの画像ファイルのサイズがかなりデカイです。画像の代わりにCSS3のエフェクトを多用したり、画像ファイルの最適化がサイトの表示スピードに体感でもかなり影響する印象を持ちました。

後はiOS用にトップページのアイキャッチ的なアニメーションはHype(JS + CSS3)を使っています。これについては@machidaさんが後で詳しく書いてくれるハズ！

スマホWebで楽なのはJS+CSS3が思い切り使えることです。一応PCからも見れますが、前述の利点を活かすためにIEを捨てました。（Chrome, Safari, Firefoxを使うように警告が出来ます。）

問題点

• Androidエミュレーターが遅すぎる。ステージング環境にアップされてからか、ちょっと重いProxyLocalを使って実機（僕が持ってるので）で確認する必要があるのでもどかしい。
• システムとデザインなど、手分けする必要があるタスクはそのままではアップできない状態でコミットされる。（システム面は実装したけどデザインが入ってないからproductionにはアップできない状態になり、リリースのタイミングを調整する必要がある）

  これは@machidaさんがGithub.appでのリモートブランチの使い方を習得しつつあるのでリリースブランチを作れば解決しそう。（デザイナーには酷な気がするが・・・）

4件のコメント