2014年12月15日のBPStudy発表資料。

1. BPStudy#88
connpassにおける
戦略の決定
2014/12/15
株式会社ビープラウド
佐藤治夫

2. 自己紹介
• 株式会社ビープラウド 代表取締役社長
• Twitter: @haru860
• BPStudy主催（2007年9月～)
88回連続参加、懇親会88回参加（予定）

3. テーマ
何をやるか？
をどのように決めるか
どうしたら
「納得感」のある合意形成ができるか？

4. ステップ0 問題の発見（ブレスト・議論）
解決したい課題
現状実現したい価値
問題の発見

5. ステップ１ 解決策のブレスト
解決したい課題
実現したい価値
機能案と、ふわっとしたテーマ

6. 片っ端から開発していけば良いわけではない！
機能案

7. 戦略の検討が必要
解決したい課題
実現したい価値
戦略 = 何をどのような順番でやっていくか？
＜解決策＞
対象ユーザー
タイミング
効果
企業戦略
市場コスト
ビジョン

8. 何をやるか？
をどのように決めるか
どうしたら
「納得感」のある合意形成ができるか？

9. 要求の優先順位のつけかた（参考情報）
「成功する要求仕様、失敗する要求仕様」
第３章 要求のトリアージ に紹介されていた手法
100ドルテスト
各自が100ドルずつ持っていると想像してもらい、
その100ドルを要求候補にステークホルダーが分配
イエス・ノー投票
要求を一つひとつ挙げていき、要求に関心がある場合は、ステー
クホルダーに挙手してもらい、優先度を決める。
５段階プライオリティ方式
ステークホルダーに要求ごとに５段階で投票してもらう。要求を次回のリリースに含めることに賛成な
らプラス１～２票。どちらでもよいなら０票。反対ならマイナス１～２票を投票する。
納得感ある？

10. よくあるチーム
考える
意思決定者
（企画担当者）
つくるもの
エンジニアデザイナーエンジニア
＜考える人＞
＜つくる人＞
・上意下達の組織
（企画者が上で、エンジニア／デザイナが下？）
→ これで納得感のある開発ができるか？

11. connpassで実践している方法

12. 要求開発（匠メソッド）での戦略の決定
0. 問題の発見（ブレスト・議論）
1. 解決策のブレスト
2-1. 価値の検証と目的
2-2. 要求分析ツリー作成
2-3. 要求の優先順位づけ

13. ステップ2-1. 価値の検証と目的の抽出
①ステークホルダーの洗い出し
「ステークホルダーを見落とすことは要求を見落とすこと」
②価値の検証 価値価値価値
→誰に対してどのような価値があるか？ 目的目的目的
③プロジェクトの目的を抽出
→価値を実現するためのプロジェクトの目的を抽出する
解決したい課題
実現したい価値
解決策（案）
検証

14. ステップ2-1. 価値関連図
コミュニティのページをつ
くるページを省けて嬉しいメンバー管理が楽にできる
コミュニティ運営の手間削減
価値
目的

15. ステップ2-2. フルセットの要求分析ツリー作成
問題・課題戦略要求業務要求IT要求
プロジェクト
の目的

16. ステップ2-3. 要求の優先順位づけ
質問：１stリリースで、必須の要求はどれか？
①戦略要求に色づけ②必要な
業務要求に色づけ
③IT要求に色づけ

17. 要求分析ツリー全体（最終形）

18. 導入した結果と成果
かかった時間：約１日
・午前中：価値分析モデル（２時間）
・午後：要求分析ツリー（４時間）
成果
・１９個のIT要求→ ７個のIT要求
・メンバーの納得感→高かった
議論が迷走したり、行ったり来たりしなかった

19. 建設的な議論が可能に
枝葉のレベルだと議論が収集しない
(具体的、そもそも論で話しにくい）
Aさんの
アイデア
Bさんの
アイデア
取捨選択の議論がしやすい
（そもそもの価値に近い）
プロジェクトの目的A
プロジェクトの目的B
<個人の価値観>
<Projectの価値観>

20. 「要求の爆発」の恐怖からの解放
赤色のIT要求
=要求分析ツリーをつくってから
アイデアとして出たIT要求
（通常）
優先度を決める段階で、さらに新しいアイデアを出す
→ 議論を収束させていきたい段階では敬遠されがち
＝議論が終わらない（要求の爆発への恐怖）
（要求分析ツリーによる方法）
「ツリーに葉を足すだけ」というのが目に見えるの
で、精神的負担が軽く、新しいアイデアに対しても、
前向きに議論できる

21. connpassでの企画・戦略（抽選機能）
必要充分でミニマムなリリース

22. connpassでの企画・戦略（グループ機能フェーズ2)
１次リリースの要求分析ツリーをもとに２次開発を検討
１次リリース後に明らかになった課題を
１次リリース時の要求分析ツリーに追加

23. 戦略における「攻め」と「守り」
<攻めの戦略要求>
戦略要求レベルで
取捨選択する
<守りの戦略要求>
ユーザー向けの大きな機能開発 etc
小改善、運用向け改善 etc
・「前回のフェーズは攻めて効果が出たから、引き続き攻める」
・「前回は攻めて一定の効果が出たから、今回は守りを固める」

24. connpassの企画・開発・運営
を通してやりたいこと

25. よくあるチーム
考える
意思決定者
（企画担当者）
つくるもの
エンジニアデザイナーエンジニア
＜考える人＞
＜つくる人＞
・上意下達の組織
（企画者が上で、エンジニア／デザイナが下？）

26. これからの組織
つくるもの
納得感
エンジニアデザイナーエンジニア
リーダー
考える
＜考えてつくる人＞
メンバーが考えるよう
導き、まとめ、力を引き出す
・個の力を合わせる製品開発
・フラットな組織

27. ご清聴ありがとうございました！
!
2014.12.15 @BPStudy#88