この記事は CrowdWorks Advent Calendar 2017 13日目の記事です。
はじめに
クラウドワークスにて、プロダクトオーナーとエンジニア組織のマネージャーをやっている @teriyakisan です。
（最近は開発業務の比率がだいぶ下がってしまっているのですが）Webエンジニアの経験をベースに、クラウドワークス上の仕事発注者に向けた機能開発のプロジェクトを進行中です。
今回はプロダクトオーナーをやる中で考えることが増えている新機能などの中規模施策を企画するときに、どんなことを整理しておくとスムーズにプロジェクトを始められるかの話をしたいと思います。
クラウドワークスで馴染みのmini spec
クラウドーワークスでの小規模な機能追加や機能改修、キャンペーン企画の要件整理を進めるときにはmini specというフォーマットがよく使われています。
これは、2016年に「ペロリ流 開発要件のまとめ方」でも紹介されていた方法で、以下のような項目が含まれています。
（現状魚拓しか残っていないため、元記事へのリンクは避けます）
mini specの中身
- 解決すべき課題
- ユーザーストーリー
- プラットフォーム
- KPI
- リリース希望日
- 体制 / 規模感
- リスク
- ステークホルダ
- 参照
この枠組みは、短時間で開発要件の整理をおこないチームメンバーへの最初の共有を始めるのにちょうどよいサイズで、まずはmini specを書いて、そこから詳細な資料を拡充していくようなスタイルが組織内でも定着しつつあります。
mini specだと足りない部分
mini specは小規模施策のスタートを切るには良いのですが、課題ベースのアプローチにはなるため、少し大きな観点での企画や機能の立案の場合には、走り出しだとしても不十分だと感じるケースがありました。
これまではmini specのアジェンダを拡充しながら進めていたのですが、
mini specが小規模施策向けであれば、新機能など中規模施策向けがあってもよいのではないかと思い、さまざまな施策を進める中で足りない部分を補うフォーマットを作って運用し始めています。
新機能など中規模施策向けのmid spec
最近は以下に挙げる10項目をmid specとして、クライアント向け新機能や中規模施策の走り出しのときにまず整理しています。
運用し始めてから、やろうとしてることの全体像を関係者にまず伝え、次のアクションが決めやすくなる感触は持ててきています。
これらに計画としてKPIや体制・開発期間、開発フェイズ分けなどのマイルストーン、また追加資料としてサービスブループリントやワイヤーフレームなどを肉付けしていきながらプロジェクトを進める流れです。
1. どのような価値が生まれるか？
この機能やサービスを提供することで、誰にどんな価値を提供できるようになるかを記載します。
mini specと同じ考え方で、どんな課題を解決するか？と言い換えられるケースもあると思います。
ここででてきたアクターが、サービスや機能の利用ターゲットにもなります。
2. どのような仕組みか？
想定しているこの機能やサービスの枠組みや仕組みを、簡潔に記載します。
ここでは大枠のイメージが伝わることが大事かと思います。
3. 使われる見込みはあるか？
新機能を企画する時点で、根拠となるユーザーのデータやフィジビリによる検証結果を持っているケースもあると思います。
KPIなどは別途設定する前提ですが、定量・定性で現時点で利用される見込みと考えている情報を記載します。
4. 世の中に似たような仕組みはあるか？
同業他社サービスやそれ以外でも、似たビジネススキームのサービスや似た仕組みの機能があれば、開発をすすめる際に参考にできたり、共有時にメンバーに伝わりやすくなる可能性があるため記載します。
5. どのように利用するか？
ユースケース記述やシーケンス図、フローチャートなどを使って利用フローを明示します。
http://www.plantuml.com/plantuml/uml
を使うと、手軽にシーケンス図が書けるので便利です。
6. どのように運用するか？
サービス提供後に発生する運用作業や想定されるメンテンス業務などが見えている場合は、それらを記載します。
機能やサービスの運用者向けに、管理画面が必要化などの判断材料にもなってきます。
7. どのプラットフォームに展開するか？
PC/スマホ/アプリ等の展開予定プラットフォームを記載します。
8. 規約の修正や特約の追加は必要か？
既存の利用規約の見直しや、特約を結ぶ必要がありそうであれば記載します。
サービスの大きさや会社の規模によって調整に時間がかかる可能性もあるため、早めに検討しておきたい部分です。
9. 提供によるリスクはどう扱うか？
提供することで発生するリスクや、既存ユーザーへのデメリットなどがあれば対処方針を記載します。
既存指標への影響や、システムの負荷懸念なども含めておけると良いと思います。
10. どのように認知してもらうか？
ユーザー提供時の利用導線や対象ユーザーへの訴求などを記載します。
サイトメニューへの追加、ウェブ接客やメルマガなどのマーケティングについても検討している範囲で記載します。
おわりに
クラウドワークスには現在、プロダクトオーナー（PO）が数名いますが、昨期からアソシエイトプロダクトオーナー（APO）という形でPOを目指す役割を定義し、一緒にプロダクトを伸ばすべく動いています。
実際に今回提案のフォーマットをベースに整理してもらいながら、プロダクト開発方法のブラッシュアップや進化も続けている状況です。
個人的には規模が大きな機能や企画になればなるほど、フィードバックサイクルをどれだけ多く回して企画や開発要件を洗練させていくかだと感じているものの、まだまだこうすればうまくいくというレベルまでいけてないのが現状ではあります。
今回のようなやり方の変化や進め方の試行錯誤を続けながら、より良いプロダクト開発手法を探っていきたいと思います。
付録：Markdownテンプレート
もしニーズがあれば…。
mini spec
## 解決すべき課題
## ユーザーストーリー
## プラットフォーム
## KPI
## リリース希望日
## 体制 / 規模感
## リスク
## ステークホルダ
## 参照
mid spec
## どのような価値が生まれるか？
## どのような仕組みか？
## 使われる見込みはあるか？
## 世の中に似たような仕組みはあるか？
## どのように利用するか？
## どのように運用するか？
## どのプラットフォームに展開するか？
## 規約の修正や特約の追加は必要か？
## 提供によるリスクはどう扱うか？
## どのように認知してもらうか？
## 計画
### KPI
### 体制・開発期間
### マイルストーン
## 資料
### サービスブループリント
### ワイヤーフレーム
### 参考