Justin.tvがTwitchやSocialcamに成長する以前、私たちは製品開発に関してよく理解しないまま、何年も過ごしていました。紆余曲折のある製品ミーティングを開き、そこでは決定事項を書き記すこともありませんでした。新製品の仕様を細かく詰めることもしなかったため、私たちが構築しているものについて、チームメンバー間の考えが少し異なっていることもしばしばでした。いつも、MVPではなく完全に形成された製品をつくろうとしていました。そして新製品の分析を細かく記録することもほとんどなかったため、ローンチ後はどのように機能しているかわかっていないこともざらでした。
開発サイクルは、しばしば数か月に及びます。製品をローンチする時期にはすでに新しい機能にうんざりしていたため、それを反復することはありませんでした。私たちの製品ロードマップはとても長かったため、チームメンバーは新製品のブレインストーミングに乗り気ではありませんでした。なぜなら、実際にそれらの製品をつくるかどうかはっきりしていなかったためです。そして非常に恐ろしいことに、製品の決定はもっぱら創業者たちが不透明なプロセスで行っていました。状況は混乱を極めていました。
今回の投稿では、私が学んだ製品開発サイクルの基礎を取り上げ、上記のすべての問題を解決する助けにしたいと思います。これを読めば、チームとよく関わりながら、製品の素早い反復や測定、テスト、改善がしやすくなるでしょう。MVPのリリースと同じ部分はあまりありません。あなたはMVPをリリース済みで、次にすべきことの検討段階という前提でお話します。この検討に、ほとんどのスタートアップが大部分の時間を費やします。
開発サイクルの長さを決める
開発サイクルはあなたの製品の特徴によって決定されるべきです。Socialcamでは私たちはiOS向けに開発していたので、2週間のサイクルに落ち着きました。その期間があれば、App Storeでのリリース前に徹底的にテストできました。ウェブアプリを開発しているならサイクルをもっと短縮できるでしょうし、ハードウェアならもっと長くなるかもしれません。チームメイトのモチベーションを維持しながら、新しいアイデアをブレインストーミングする気分になれるサイクルを構築することが鍵です。
目標を決め、プロダクトリードを特定する
私たちは、たった一度だけチームミーティングを開きました。それは製品ミーティングで、開発サイクルの初日に行われました。このミーティングはときに5時間続くこともありました（面目ない）。
すべての製品ミーティングは、以下の3つの目標のいずれかに特化していました。
1. コンテンツ製作を増やす
2. 新たなユーザーを増やす
3. リテンションを増やす
どの目標を選んでもそれがミーティングの焦点となり、したがってその後の2週間の焦点となります。
チームの製品担当として、私の役割は開発サイクルを守り、改善させることでした。そして製品ミーティングを取り仕切り、すべてのチームメンバーが気持ちよく貢献できるようにする役目もありました。しばしば、自分のアイデアを表明してボードに書き込む機会があるだけでも、（たとえ実際に製品にならなくても）プロセスに関わろうという気持ちが大きく増します。
整然とした包括的なブレインストーミング
私たちがブレインストーミングしている間、以下のいずれかのカテゴリーでアイデアがホワイトボードに書き込まれました。「新機能/新たなイテレーション」「メンテナンス」「A/Bテスト」。全員が貢献するように求められていました。他メンバーのアイデアを議論したり、こきおろしたりすることは禁止です。それは、評価される不安なしに自由に貢献できると全員が感じた機会でした。プロダクトリードは、そのような環境の創出と維持に責任があります。
そこから、ブレインストーミングで出された各項目が、ミーティングに参加しているエンジニアによって「簡単」（いくつかを1日で完了できる）、「普通」（1人で半日がかり）、「難しい」（開発サイクルの大部分）と格付けされます。別のサイクルまで突入するほど困難な項目は認められません。そのような項目は小さな塊に分解します。通常この格付けは、その特定分野で最も経験のあるエンジニアによって項目ごとに行われます。iOSの機能はiOS担当者によってランク付けされる、といった具合です。これにより技術職以外のメンバーも、どのアイデアが構築しやすく、どれが難しいかがとても理解しやすくなりました。その理解があったために、自身のアイデアのMVPを考え出す力がどんどん上がる事態がしばしば見られました。それらの簡単なアイデアはその後構築され、それが有効なら反復されます。
合意の形成
ひとたびアイデアを書き出したら、取り組むべき内容について合意を通じて選んでいきます。私たちは難しいアイデアから手を付けました。難しいものは1つしか実行できないことが分かっており、新たな開発サイクルを2週間後には開始できると理解しているため、合意形成が楽なのです。その後「普通」→「簡単」と進みます。それらの合意形成もさほど難しくありませんでした。全員に自身のアイデアを提案する機会があり、各アイデアの実行にかかりそうな期間について、明確な目標や客観的な測定値があったためです。このプロセスのおかげで、自身のアイデアの質を格付けることができた一方、持論を強引に押し通すことは許されませんでした。
明確な仕様と明確な成功の測定
その後、私たちのリストの各項目の仕様を詳細に決定し、各項目を1人のチームメンバー（もしくは複数のチームメンバー）に割り当てました。また機能の効果を測定するため、追跡に必要な統計データを細かく記録しました。その機能の分析結果をリリースせずに、また自分たちが生み出したいと思う、特定の測定可能な結果を理解せずに機能をリリースすることは決してありません。最後に、リストの「あれば素晴らしいもの」から「必要なもの」を分けます。時間がない場合は「あれば素晴らしいもの」は構築しません。それが完了したらホワイトボードの写真を撮り、内容を消します。この2週間以外には製品ロードマップはなかったため、製品ミーティングのたびにゼロから始めました。新しい目標や、過去2週間から得た新しい分析データを用意しました。さらに、ひと月に一度試みていた、実際に製品を利用してみるユーザーテストからの新しい知見もしばしば用意されました。
開発サイクル中の作業
私にとって、開発サイクルの最初の月曜の後の作業は静かなものでした。私の仕事は、すべてのビジネスや運営のタスクを完了することでした。その後Mixpanelを閲覧し、興味深い製品の知見や潜在的なバグを探します。最後に、月に一度のユーザーテストセッションも私たちのオフィスで実行しました。私のチームメイトのエンジニアやデザイナーも、仕様がしっかりしている、範囲の限られたプロジェクトであることを知っており、静かに素早く作業を進めます。最後に各開発サイクルの最後の3日間で、構築作業をすべて止めてテストします。エクセルにテストのリストがあり、基本的な機能すべてに関する手動のテストが含まれていました。各サイクルにおいて、そのサイクル中に構築された新機能のテストを追加し、テストリストのすべての項目を二度テストしました。チームの全員がテストを行いました。しばしば誰が一番早くテストを終わらせ、一番バグを見つけられるかの競争をしました。テストは退屈なので、負担をシェアすることは重要です。
結果
つまるところSocialcamでは、「動画版Instagram」になるという私たちの夢は叶いませんでした。実際のところ、Snapchatにかなり近い見た目にすべきだったのです。しかしこのプロセスにより、イテレーションを極めて短縮できました。その結果、素晴らしい機能を列挙した長いリストをとても素早く作成できました。ビデオフィルターやビデオボーダー、ビデオタイトル、映像サウンドトラック、ビデオフィードの最適化、複数のビジュアル再設計、ユーザープロフィール、お勧めチャンネル、再生中のフロント/バックカメラの切り替え、などなどです。また、約3か月で1600万回のダウンロードを生み出した成長機能を試すこともできました。同じ期間に、1億人以上が私たちのサイトで動画を閲覧しました。しかし最も重要なのは、私たちがこれらの作業を素早く、効率良く実行したという点です。大きな言い争いや創業者の関わりといった問題、チームの問題もまったくありませんでした。会社を売却せずに、さらに1年続けていたら… と時々思うことがあります。しかし、それはまた別の話です。
本記事の執筆を手伝ってくれたJared、Geoff、Craig、ありがとう。Socialcamを一緒に立ち上げたAmmonとGuillaumeに感謝いたします。また、Justin.tvの古き良き時代の苦労を切り抜けたJustin、Emmett、Kyleにも感謝いたします。
著者紹介
Michael Seiebl は YC の CEO です。彼は Justin.tv と Socialcam の共同創業者であり、CEO でした。Socialcam は Autodesk に 2012 年に売却され、Emmett Shear の下で Justin.tv は Twitch.tv となり、Amazon に 2014 年に売却されました。スタートアップに関わる前、彼は US の上院議員選挙で財務ディレクターを1年勤め、2005 年に Yale University を Political Science の分野で BA を取って卒業しました。
記事情報
この記事は原著者の許可を得て翻訳・公開するものです。
原文: Product Development Cycle Fundamentals (2016)
