Qiitaを開発する中でLeanStartupを実践して学んだことをシェアします

タイトルはちょっと大げさですが、実際にStartupをやっていて気づいたことをまとめてみようと思います。

先に謝罪すると、僕はまだLean Startupを読破できていません… が、一緒にQiitaを開発しているyaottiは読了済み、かつQiitaでかなり積極的に取り入れているので大体把握できている、と信じています。

↑洋書なのでちょっと読むのしんどいですが、渡辺千賀さんの記事と合わせて読むといいかもしれません。

Leanにやることと計画を立ててやることは相反するけど両立しないといけない

LeanStartupの注意点はだいたい下の通りだと思います。

• ユーザー体験をベースに、機能を考える
• できるだけ機能は小さな単位に切り分ける
• 最小単位でリリースし、成果を計測することで機能の取捨選択をする

つまり、とにかくスピードが大事。ガンガン作ってガンガン出す。そして計測して取捨選択する。という感じです。

上の注意点を踏まえた上で開発を回すプロセスはだいたい下みたいになると思います。Qiitaオリジナルな要素が多分に含まれているかもしれないですが、そこは了承を…

• ユーザー体験をベースに、ユーザーにどういう価値を提供することでどうなって貰いたいか、という観点で機能を洗い出す
  • Pivotal Trackerではこれをストーリーと定義しているし、自分もわかりやすいので以下ストーリーと言います
• ストーリーはできるだけ小さな単位に細分化する。どれだけ大きくても最大１人日で開発できるサイズにする
• 洗いだしたストーリーを、ユーザーにとって影響の大きいものから優先順位をつけて並べる
• 上から順番に、開発をスタートするが、作る前にまず計測するべき指標と実際に追加する内容を具体的にする
  • 例えば、再帰率を現状から○%アップさせる。計測期間は何日から何日まで。追加する内容は○○…みたいな。
• 指標と内容の具体化が終わったら開発し、そしてすぐにリリースする
• リリースしたら計測スタート
• 計測してみて、成果が現れたらそのままに。成果が現れなかったようならその機能はユーザーにとって価値がなかったことになるので、容赦無くプロダクションから削除する

だいたいこんな感じで回すわけですが、ここで注意しないといけないのは１つめの機能の洗い出し。 ユーザーの反応を見ながらやっていくと言いつつ計画は最初に立てないといけないし、計測した結果で今後のプランが変わると言ってもやっぱり計画は立てないといけない。ただ計画に尽力するのは間違っていて適当なところで開発にシフトしないといけない。そういうジレンマがあると思います。

じゃあそれをどうやって解決するのか。 それはもうその時に時間を決めてその時間内に立てられる計画を立て、そこを基準にスタートしてしまうしかない。スタートして開発して計測してその結果を計画に反映する。そういう感じで回すしか無いと思います。

優先順位の設定

開発の優先順位の設定はみんな悩ましいところだと思います。だってどれもこれも付けたいし、つけたら絶対ユーザーは幸せになると思う。そんなときどうするべきか。現状、アプローチの仕方としては２つあると考えています。

１つめは、サービスで提供するべき価値から掘り下げる方法。そのサービスで絶対に提供するべき価値を考えたときに、絶対外せない機能は何かを考える。その中で特に優先して付けないといけない、かつ早めに出してテストしてみないといけない機能はどれか、っていう形で掘り下げてやる。特に優先しないといけない機能の選び方は、「提供すべき価値を構成する最小限の機能は何か」という観点で見てやればいい。

２つめは、機能の相関関係から考える方法。サービス全体を把握できている前提ではあるけど、サービス全体を俯瞰してユーザー体験の流れを考えたときに優先して付けるべき機能はどれか、という感じで考える。そうすると例えば「○○は必要な機能だけど、○○を先に出したほうが波及効果が見込める」とか「○○だけ出しても効果は薄いから○○を先にやったほうがいい」とかが出てくる。

これでも解決しなかったら、開発が楽なほうからやってみるとか、もう後は好みで決めればいいと思います。

デザイナーは慎ましく、プログラマは意思を殺して挑まなければならない

これは非常に苦しい。一応Qiitaではデザインを担当していますが、過度な遊心や美意識は捨て去らないといけないと感じました。ユーザーにとっての価値は、美しいことではなく見やすく使いやすく飽きにくいこと。だから装飾は最小限に、ただレイアウトやタイポグラフィなどユーザーの使い勝手に影響するところは敏感にデザインし、とにかく早くリリースすることが大事。機能はできたけどデザイナーのこだわりのせいでリリースが遅れるなんてLeanStartupではあってはならない。

次にプログラマ。スピードが最優先でかつちゃんと動くものをある程度のクオリティで出す必要がある。だから最先端の技術がどれだけ面白そうでも、既存の技術で同様の成果が出せるのであればそこは既存の技術を選択しないといけない。学習コスト、世間に存在するノウハウの量、保守性を考えてバランスをとる、という感じです。

お金はいつか尽きるが、Leanだと長生きしやすいかも

やることを絞って絞って無駄をなくし、かつコストもできるだけかけないで最小構成で回し続けていると、結構長く続けることができます。後々スケールするかもしれないからーという淡い期待をもって最初からAWSを使ったりせず、移行コストは多少かかってもさくらのVPSをつかうことでコストを下げる。すぐに黒字化するから！とかいって高い家に住んだりせず、シェアハウスや友だちの家に住む。オフィスなんて必要ない、カフェで開発する。都内なら長居できるカフェなんていくらでもあります。そうすることで毎月の固定費を限界まで下げるとかなり余裕が生まれます。

そして売り上げが立ったら時間を割くなり人を増やすなりしてAWSに移ればいいし、家も引っ越せばいい。調達できるかなんてわからない、営業も成果が上がるかどうかわからない、ユーザーがつくかもわからない、そんな状態でスタートするならなおさら、固定費を削ることが大事。実際そうやってきたお陰で、Qiitaは長生きできている気がします。都内各所のルノアール、サンマルク、スタバを練り歩いて、コンセントが使えてかつ長居しやすいところを探しまわりましたし、サンマルクで190円のコーヒー一杯でまる１日粘ったりしました。(サンマルクさんすいません…)たまに閉店で追い出されたりもしました。でもオフィスをかりるより全然安かったです。幸い今はOpenNetworkLabに入れたおかげで快適に作業することができていますが、変にオフィスを構えて短期集中でやっていたら、OpenNetworkLabに入る前に資金が底をついていたかもしれません。OpenNetworkLabに入ることが決まっとき、できるだけ長く続けることも重要なんだと実感しました。

最後に

Leanに回しつづけて気がつけば7ヶ月半もQiitaを開発しています。会社で働いていたときとはやることも考え方も視点もすべてが変わりました。いいか悪いかは別として、非常にいい経験ができていると思います。これだけ長い間Qiitaというプロダクトを作り続けてきたわけですが、それももうすぐ転換期を迎えます。Qiitaは”ただのWebサービス”から脱却しようとしてるから。

Project “Kobito”。中で温め続けたアイデアがようやく形になって世界に羽ばたこうとしています。最初の頃は、エンジニアのためのWebサービスを作る中でまさかMacアプリを作ることなんて想像もできませんでした。だけどこのアプリこそ、Qiitaを支える重要な柱のひとつになると信じています。リリースを控えて、現在先行利用ユーザーを募集しているので、このブログを読んだエンジニアの方、もしよかったらエントリーしてみて下さい。

Qiitaで開発中のMacアプリ”Kobito”先行利用ユーザー募集 - Project “Kobito”