2012-05-28
■環境構築2012May(1)
あるアプリをリメイクするにあたって行っている環境構築についてのメモ。
個人的なメインテーマは"CI"。もちろん、それをするにあたって必須と言える"テストの自動化"にも力を入れるし、ブランチ戦略(参照→見えないチカラ: A successful Git branching model を翻訳しました)というのも意識したい。アプリ本体についてもいろいろトライしようとしていることがあって正直手を広げすぎじゃないかという気もするので、完璧を求めすぎないよう自制しつつ着手。
今回のお品書き
CakePHP, XAMPP, Git(Lab), Jenkins, Redmine
開発環境
最近仕事で使い始めたということもあり、開発フレームワークは CakePHP を選択した。
そして、実行環境は XAMPP。Pleiades All in One(Eclipse)のPHP「JRE あり」版に XAMPP が同梱されているので、これを利用した。
セットアップ用のバッチ(setup_xampp.bat)を叩いてから、Apache, MySQLを起動。OK。
公式サイト(CakePHP: 高速開発 php フレームワーク。 Home)から CakePHP(2.1.3)をダウンロードし、htdocs に置いて確認。OKだが、幾つか注意が出てたので、[cakePHP1.2] インストール直後にやるべきこと: PHPを使ったWebサイト構築 備忘録 を参考に設定を変更した。
リポジトリは GitLab というのを社内で用意してもらったので、これを使う。
今使っている Eclipse には EGit が入っていなかった(バージョンは、3.5.2)ので、追加。http://download.eclipse.org/egit/updates より、"Eclipse Git Team Provider"を全部チェックしてインストールしようとすると、
Cannot complete the install because one or more required items could not be found. Software being installed: EGit Mylyn 1.3.0.201202151440-r (org.eclipse.egit.mylyn.feature.group 1.3.0.201202151440-r)
というエラー。EGit Mylyn を入れた覚えはないが、入っていると主張するのであれば、チェックを外して進めるしかない。･･･無事完了。
とりあえず、今日はここまで。
(5/29追記)
Eclipse3.7.2では作業対象サイト(URL)の追加は無く、「コラボレーション」カテゴリから選択するだけ。
そして、その中に EGit だけでなく、"Mylyn ビルド・コネクター: Hudson/Jenkins (インキュベーション)"というのを見つけた。良さげなので、ついでに入れてみる。
2012-05-04
■ 仮説検証についてのお勉強
･･･シテマス。
『リーン・スタートアップ』では頻りに仮説検証の重要さが説かれていますが、具体的な手法等は紹介されていませんでした。そこで、いざ自分が実践するときのための準備として、いろいろ調べたり探したりしようと思います。
以下、その中で見つけた有用な情報をメモ。
統計学のおさらい
コホート(cohort)とは共通した因子を持ち、時間を追って観察される集団のことです。
(統計学入門−第12章 より)
コホート分析だけでなく、統計の基礎から各種手法まですばらしいほど内容が充実している。統計学入門−前口上からしっかり読むべき。
検証に役立ちそうなライブラリとか
cohorts
jamesyu/cohorts ? GitHubは名前からするとコホート分析のためのライブラリっぽいが、実際はUIのABテストに使うもののようだ。
Google Analytics(以下、"GA")のイベント分析機能と連携して使う。GAってこんなことも出来たのかー。もっと使いこなせるように、改めて勉強しなきゃ、だ。
手始めにこの(イベント)機能から→ イベントトラッキングの使い方、まとめ10+事例 | カグア！Googleアナリティクス活用塾
cohortly
bhauman/cohortly ? GitHubはいかにもリーン・スタートアップ的なコホート分析を行うためのもののようだ。
どういうアウトプットになるのか、READMEを見た限りでは分からない。うーむ。
とりあえずGoogleべったりでいいんじゃない？
ABテストならウェブサイト オプティマイザーというサービスもある。Googleの無料サービスだけでかなりのことができそうなので、まずはどういうものがあるかを知って、必要なものをちゃんと使えるようにするべきか。
う、めんどくさ･･･！どういうスクリプトを埋め込むのか、小さくて読めないけど、動的に生成できるパターンだといいなあ･･･。
2012-04-30
■Webを流れるお金の5W2H
<目的>
リーン・スタートアップでは、仮説を検証する際に“もっともリスクが高い要素”、“挑戦の要となる仮説”から検証せよとしている。
それは一般的にどういう仮説か？
それはやはり、「誰は、何に対して/どのような理由で/どのようなときに/どれくらい お金を出す」といった仮説だろう。それ以外の仮説を、どんなにうまく立て、学び、本当のユーザ増加につなげたところで、十分な収益を得られなければ事業は継続できない(※１)。
よって、本エントリーでは“挑戦の要となる仮説”を構成するであろう最重要パーツ(5W2H)をいくつかリストアップしてみる。
※１．裏を返せば、「exitは売却しか考えてない」というのであれば別のタイプの仮説が“挑戦の要”だと言える。
Who
有料ユーザ
フリーミアムモデルを採用するWebサービスであれば、有料ユーザがお金を払う主体となる。一番分かりやすいパターン。
広告出稿者
直接出稿者と契約する場合であれ、AdSenseなどの広告サービスを利用する場合であれ、元々のお金は広告出稿者から出ている。
上記二つは仮説の主体として適当で無い気がしてきた。本当の Who は下記のように具体的な人物像、特性ではないだろうか。
元パチンコ遊技者(あくまで、一例として)
現在絶頂を迎えているソーシャルゲームの原動力となったのは上記の人たちだという話がある。
これをもし仮説化するならば、「パチンコに月数万円使う人たちが（ゲームが出来るくらい高性能な）携帯電話を持ったら、そこで提供されるゲームに同程度の金額を使う」等だろうか。同時に、対抗仮説(?)として「パチンコに月数万円使うのは、遊戯の結果同程度以上の金銭を得られる場合が稀にあるからである」等が考えられる。
→そうか、対抗仮説か･･･。仮説検証のメソッドは『リーン・スタートアップ』にほとんど記述は無かったけど、ちゃんと学び直さないといけないなあ。
(追記)対抗仮説というより帰無仮説？
※これら、斜線部分の記述は個人的な感想。以下同様。
Webサービス開発者・Webデザイナー
Webサービス開発者・Webデザイナーは新しいWebサービスへの関心が高く、アーリーアダプターとなる可能性が高いように思う。
→ただし、お金を払うかどうかは大いに疑問。そう考えると、収益に関する仮説は初期ステージでは検証困難あるいは不可ということもありえる。その場合、可能な限り早く仮説の検証をするためには、初期ステージでも稀にまぎれこむであろう(本来は)アーリー/レイトマジョリティーを識別するためのロジックを確立し、分離→比較検証をどれだけ精確にできるかにかかってると言える。
あと、仮説を定義するときは一つ(一種類のWho)だけでは不十分だと思われる。最初は、分かりやすさを重視して少なくすべきかと思っていたけど。
そして、対象がどのカテゴリ(アーリーアダプター/アーリーマジョリティ/レイトマジョリティー/ラガード)なのかは常に意識しておくべきだろう。
What
プロダクト・サービスそのもの
まあ、これは基本中の基本なので解説なしで。
特定の機能、容量等の制限撤廃
フリーミアムモデルのWebサービスでは「有料ユーザのみ、○○機能が利用可能」「無料ユーザは5GBまで保存可能」等の差別化を行って、有料契約のモチベーションとするのが常。
ソーシャルゲームにおける有料アイテムもこの類か。
これらは、個人的偏見として「マネタイズについての仮説をうまく定義できないチームが「逃げ」あるいは「格好つけ」として採用する」「かかるコストの割に収入は少ない」イメージだが、実際どうなんだろう？
Where
国・地域
ビジネス規模が全世界レベルの場合は当然、国・地域(実質的には文化や生活習慣？)毎の仮説が必要。
例えば、有料のビデオサービスは、有料のケーブルテレビが一般的なアメリカでは普及するかもしれないが、日本の一般視聴者に対しては厳しいかもしれない。
場所
Facebookは、今でこそ誰でも何処でも使っているサービスになっているが、その始まりはハーバード大学だったのは有名な話。
“小さく始める”にあたって地域・場所を限定するなら、どこをターゲットにするかというのは重要な要素となる。
When
タイミング
「写真を撮りたいと思ったとき」「感動する出来事があったとき」など、特定の行動・イベントが起こったタイミングというのは重要。特に、現代はモバイルの時代なので、アプリ/Webサービスは常にユーザとともにある状態。だから、それをいつ使うか？というのはとても重要。
日時
プロダクト・サービスの種類によっては特定の時期/時間帯にニーズが集中する場合がありうる。よって、仮説定義時に「○○の時期/時間帯は○○である」と適切な定義をしないと、誤った結論を道微意してしまう恐れがある。
ステージ
ハイプサイクルでいうところの黎明期-流行期-反動期-回復期-安定期、各ステージにおいて状況が異なる以上、別の仮説が必要になることは明らか。
Why
それが必要/欲しいから
一番シンプルで、まっとうな動機。
「ユーザの目的を達成するために、その機能/性能等が必須だから」「ユーザが、その機能/デザイン等を気に入ったから」というパターン。
買わずにはいられない
典型的な例は、ソーシャルゲームのガチャ。
最初にガチャを回す動機は「欲しい」という純粋な欲求だったかもしれないが、「ゲットするためにあと一枚のカードが必要(だが、なかなか出ない)」等の状況から「今さらやめられない･･･！(グニャア)」となるパターン。
こういうのは将来的に法律で規制されるリスクが大いにあるが、そこまで織り込み済みなら強い。
チャレンジに対する応援として
そのプロダクト/サービスが先進的であまり一般ウケしないものの場合、逆に、「俺はいいと思うぜ！」という気持ちを表明するために購入するということがある、かな？
これはあったとしても、きっと少数派。しかし、初期ステージを乗り切るための貴重な収入源として、検証すべき価値はあるんじゃないかと思う。
お布施として
上と似たものに、いわゆる「お布施」がある。これは結構侮れない。一番の成功例はApple。世の中には「Appleの新製品が出たら、まずは買う」というユーザが少なからずいる。
でも、これはスタートアップが検証すべき仮説の「パーツ」ではない。すでに成功した企業の構成要素だ。ということで、リストからは消しておく。
How
利用メディア
典型的な成長仮説では、ユーザがそのプロダクト・サービスを気に入ったときに他のユーザに紹介する。そのときにどのメディアを利用するかを仮説に組み込まないと、検証のためにどのデータを集めたら良いのか分からない。
→そういう意味で、“ただのアイデア”と“検証可能な仮説”を分けるのは適切な How & How much が盛り込めるかにかかっているんじゃないかとすら思う。
決済
決済手段・手順を適切にチョイスすれば成功の確率が高まるというより、むしろ、決済手順が煩雑だと潜在的な収益を逃してしまうという感じか。
How much
金額
いくらなら買うか？有料契約するか？
仮説的には「どんなに安くても有料会員にはならない」「多少高い値付けでも、気にせず買う」等のパターンもあるだろう。
コンバージョン率
「訪問者のうち何パーセントがユーザ登録をしてくれる」といった数値目標は仮説を定義する上で極めて重要･･･ですよね？
頻度
これはチームのレベルが低いときだけ意識すべきものかもしれないが、「こんなアプリがあったらユーザは面白いと思う」という類の仮説は、例え正しいと証明されたとしても『「なにこれwww マジウケる〜」→二度と使われない』のコンボが見え見えである。
よって最低限、「このアプリは非常に面白いので、違う友達に会う度に見せたくなる」程度の仮説でないと検証に値しないんじゃないかと個人的には考える。
極めて当たり前のことばかりを述べたつもり。
しかし、自分で仮説を定義するときはこれを見直して、検証のレベルを高めようと思う。
2012-04-22
■『リーンスタートアップ』を読んで(3)
第九章 バッチサイズ
- バッチサイズが小さい方が実は作業効率が良いという話は初めて聞いた。
- "免疫系"か、いい言葉だな。確かに、最近のシステムは生物に近い。まあ、生物もそもそも細胞が多数集まって出来ている"システム"なのだから突拍子もない話ではない。
第十章 成長
- 三種類の成長エンジン。特に目新しいものは無し。悪い意味じゃなくて。
- 「製品と市場のフィット」と「ピボット」は別問題。胸に刻むべし。
第十一章 順応
- 「５回のなぜ」、これも実行者の資質に大きく左右されるメソッドだと感じる。
- それぞれの「なぜ」の改善に比例投資。なるほど。
- 単に原因を探り、改善するだけでなく、参加メンバーの学びにもつながるというのは盲点だった。
第十二章 イノベーション
- 通常業務と革新が同居する大企業の話が興味深い。いわゆる“抵抗勢力”は人として当然の反応。潰すのでも隠れるのでもなく、うまく同居することが重要。
- ふと気づいたが、Webサービスが新UIを提供するとき、新UI切替のリンクをページ内に表示することがあるが、あれをクリックするのは「アーリーアダプター」だな。一方、一斉に新UIに切り替えたとき旧UIへのリンクをクリックするのは･･･「ラガード」。「レイトマジョリティ」も含まれるかな？
- 企業には４種類の仕事、開発→成長→最適化→レガシーがあり、それぞれで求められるものが違う･･･う〜ん、最初の二つは分けるべきなのかな？自分は２〜３種類かと考えていたけれど。
- 「リーン・スタートアップとは枠組みであって一定のステップを踏襲すればいいわけではない」。ただ真似だけするつもりはさらさらない。しっかり、エッセンスと事例とに分けて吸収したい。改めて自分に言い聞かせる。
- そして、これが本になってるということは“過去の話”だということも強く意識しないといけない。今は既に、この方法ではスピード不足かもしれないのだから。
第十三章 エピローグ〜無駄にするな
- 「無駄にするな」か。結果的には無駄になってない場合も有るが、自分は割とほいほいドメインを変えるからもっと意識していい。
- マネジメント関連の改革はすべてエンジニア主導で行われた。世界的なIT企業のトップがエンジニア出身ていうのもそれと関係あるのかな。
第十四章 活動に参加しよう
- 参考情報のインデックスなのでパス
総論
今まで個人でいろいろやって、MVPを作る手法も実は自力で考案・実行済みで(確かに、速やかにフィードバックが得られたっけ)、そこからたどりついた結論は「成功の要因は複雑で、人の手では制御不能。すなわち、運次第」だった。
そんな感じで、自分は祈祷に頼る“古代”から抜け出せずにいたわけだが、この本には科学的手法による“近代”の姿が示されている。これを手引きにタイムスリップしようと思う。
2012-04-21
■『リーンスタートアップ』を読んで(2)
第七章 計測
- 会計の目的は、リーダーを評価し、責任を問えるようにすること。
- (おそらく)一般的なイメージでは「会計で扱う数値＝金額」だが、上記のように定義すれば金額のみに限定されない。アクティブなユーザの数等も対象となる。
- (これもおそらく)一般的なイメージでは「数字での評価は客観的」。しかし、本当はいくらでも主観的にできる。
- 自分を気持ちよくするための評価ではなく、本当の成長に結びつく評価をできるかが重要。きっとこれは、『リーンスタートアップ』を読んだからといって出来るようになるものじゃないと思う。むしろ、人間には出来ないことじゃないかとすら思う。
第八章 方向転換(あるいは辛抱)
- 挙げられている例がすごくあいまいで、検証するには大雑把すぎると感じるのは自分だけだろうか？
- そして、それはいいことなのか悪いことなのか？
- 例で出てくるスタートアップがどれも微妙すぎる。理論には賛成するんだが、だんだん冷めてきつつある･･･
- それともこれは、「ソーシャルで成功しているスタートアップの一般的な知名度は驚くほど低い」という意味なのだろうか？
- いろいろなタイプのピボットが挙げられている。これだけあれば、自分が意識してなかった新しい切り口を見つけるのに良さそうだ。
以上、第２部について
