タベリーというプロダクトへ、グループ共有機能をリリースするにあたり、作成した仕様書を公開する。
新バージョン（1.5.1）で「グループ機能」が追加されました！・家族やパートナーを招待すると、献立がシェアできます😋・グループの誰か1人がタベリープラスに加入すると、グループ全員が利用可能に🎉献立作成をパートナーに任せてみたり、休日の料理をリクエストしたり、色々使ってみて下さい💡 pic.twitter.com/hMWKnwlhNi — #タベリー☺️献立作成アプリ (@tabelyapp) 2018年1月29日
仕様書の公開に踏み切ったのは、10Xのプロダクトがどうやって作られているか、について部分的に触れてもらえると思ったから。
10Xでは「細かな実装・デザインの白兵戦」・「認知と理解を獲得していく空中戦」を一緒に戦えるプロダクト・マネージャーを育てていきたいと思っているので、この仕様書を読んで「10Xで力を試してみたい！」という方はぜひこちらから応募してほしい。ユーザーの感情を科学できる人が10XのPMにはフィットすると思う。
仕様書の前提となる考え
仕様書は「チームのワーキングスタイル」によってその役割をかえるものだ。今の10Xは「ユーザーの前に積まれた膨大な課題の山に優先度を付け、とにかく早くプロダクトをプッシュしていくこと」が最優先のチーム。
そのため、「膝を突き合わせて瞬発力の高いコミュニケーション」を重視している。リモートはしない。
この環境では議論のすべてが口頭で実施される。たとえば僕が作成したUIも一緒の画面を見ながらブラッシュアップの議論ができる。そんな状態だ。
そこで仕様書の立ち位置を以下としている。
- 価値から認知獲得までの「Why」「What」「How」がミニマムで記載された設計書
- 意思決定のプロセスと内容を端的に追えるストック情報
- これを満たすためのドキュメントであれば十分である。実装における空白エリアは口頭で埋めることができる安心感がある。「完璧な仕様書」は志向していない。その必要性や姿はチームに合わせるべきであるというのが僕の基本的な考えだ。
この前提のもとに、以下の仕様書を公開する
献立アプリ「タベリー」への招待です。献立を共有すると、「これ食べたい」が簡単できます。
2ステップで「ゆまじろう」さんと共有できます！
①アプリをインストール
https://tabe.ly/hogehoge （インストール済の方は②へ）
②インストール後、以下の招待リンクをタップ
https://tabe.ly/hogehogehoge
（有効期限 : 1/31 10:59）
招待を受けるには、アプリのバージョンが1.5.0以上である必要があります。
何かご不明の点がありましたらタベリー運営事務局まで info@tabe.ly
6 / 招待リンクタップ後の挙動
グループへの参加許諾、参加するとできることを端的に伝える。なおタップするユーザーの性質によって大きく4パターンに挙動が別れる。
エッジケースとして「すでにタベリープラスに加入中の人がグループに参加した場合」に通知をいつどう送るか。グループのペアリングが完了時に上記の分類に当てはまる方には通知を送る、でよさそう。
通知の復帰導線 → 積み残し
本機能を利用する上で価値のある通知が届けることができる。システム設定で通知を許可していないユーザーに通知許可を促す導線を用意する。リリース時は除外。
8 / 課金のシェアについての仕様
- グループの参加者の誰かがタベリープラスに加入していれば、全員がタベリープラスを利用できる。
- タベリープラス加入者が訴求ページのリンクをタップしたときに表示されるモーダルには「加入済みです」と記載 通知周りは7を確認。
9 / グループ解除時の献立の表示
- グループにはそのグループに参加しているメンバーが作成した献立がすべて見える
- グループ解除時は、「自分の過去に作った献立」のみがカレンダーに反映される。
- 編集者は関係ない。
10 / バージョン配布について
1.5.0以前のバージョンの人は、グループ招待を受けられない。そのため、強制アップデートが必要となる。強制アップデートの影響を最小化するため以下の手順とする。
1.5.0では「グループを招待する」という導線を消した状態でアプリを配布。 その普及率が80%を超えたあたりで導線を復活させた1.5.1をリリース。強制アップデートを行い、機能自体は1.5.1で開放することとする。
11 / プレスリリース → 価値を言語化できないのでやめる
機能紹介+アルファのリリースを出す。目的はユーザー伝達と方針の認知獲得。ただしこのままだと面白くない。フックを入れる。
→プレスリリースを書きましたが、パンチが弱くて辞めました。
12 / Datastoreの仕様
User EntityにGroupIdをもつ。一人あたり必ず一つのユニークなIDをもつ。 Group Entityが新たに作成。このGroupIdあたりのUserIDが2以上のグループは実際にユーザーがつながっているグループである。 以上。本来であればKPIの設計も組み込むのだが、それは現状口頭とダッシュボード直編集で済むので仕様書には掲載していない。 （了）
本来、仕様書というのは会社の特色が現れ、またなかなか表に出てこないアウトプットだと思う。しかし僕は「仕様書自体に一切の価値がない」と思っている。
価値があるのは仕様書ではなく「プロダクトを発明していくプロセス」自体にあり、それは10Xのチームだから再現するものでもある。ので、仕様書は僕らのチームの片鱗を感じてもらえればと思い公開に踏み切った。
繰り返しになるが、10Xのプロセスが気になる、そのなかで力を発揮してみたい、という方はぜひこちらよりご応募下さい。