connpassにおける 戦略の決定
株式会社ビープラウド 佐藤治夫
2014/12/15
BPStudy#88
自己紹介
• 株式会社ビープラウド 代表取締役社長
• Twitter: @haru860
• BPStudy主催(2007年9月~) 88回連続参加、懇親会88回参加(予定)
何をやるか?をどのように決めるか
どうしたら「納得感」のある合意形成ができるか?
テーマ
ステップ0 問題の発見(ブレスト・議論)
解決したい課題実現したい価値
現状
問題の発見
ステップ1 解決策のブレスト
解決したい課題実現したい価値
機能案と、ふわっとしたテーマ
片っ端から開発していけば良いわけではない!
機能案
戦略の検討が必要
解決したい課題実現したい価値
<解決策>
対象ユーザー
タイミング効果
企業戦略
コスト市場ビジョン
戦略 = 何をどのような順番でやっていくか?
何をやるか?をどのように決めるか
どうしたら「納得感」のある合意形成ができるか?
要求の優先順位のつけかた(参考情報)
第3章 要求のトリアージ に紹介されていた手法
100ドルテスト 各自が100ドルずつ持っていると想像してもらい、その100ドルを要求候補にステークホルダーが分配
イエス・ノー投票 要求を一つひとつ挙げていき、要求に関心がある場合は、ステークホルダーに挙手してもらい、優先度を決める。
5段階プライオリティ方式 ステークホルダーに要求ごとに5段階で投票してもらう。要求を次回のリリースに含めることに賛成ならプラス1~2票。どちらでもよいなら0票。反対ならマイナス1~2票を投票する。
「成功する要求仕様、失敗する要求仕様」
納得感ある?
よくあるチーム
意思決定者(企画担当者)
エンジニア デザイナー エンジニア
つくるもの考える
・上意下達の組織(企画者が上で、エンジニア/デザイナが下?)→ これで納得感のある開発ができるか?
<考える人>
<つくる人>
connpassで実践している方法
要求開発(匠メソッド)での戦略の決定
0. 問題の発見(ブレスト・議論) 1. 解決策のブレスト 2-1. 価値の検証と目的 2-2. 要求分析ツリー作成 2-3. 要求の優先順位づけ
ステップ2-1. 価値の検証と目的の抽出
解決したい課題実現したい価値
①ステークホルダーの洗い出し「ステークホルダーを見落とすことは要求を見落とすこと」
価値 価値価値②価値の検証→誰に対してどのような価値があるか? 目的 目的 目的③プロジェクトの目的を抽出→価値を実現するためのプロジェクトの目的を抽出する
解決策(案)
検証
ステップ2-1. 価値関連図
コミュニティのページをつくるページを省けて嬉しい メンバー管理が楽にできる
コミュニティ運営の手間削減
価値
目的
ステップ2-2. フルセットの要求分析ツリー作成戦略要求 業務要求 IT要求問題・課題プロジェクトの目的
ステップ2-3. 要求の優先順位づけ質問:1stリリースで、必須の要求はどれか?
①戦略要求に色づけ ②必要な業務要求に色づけ
③IT要求に色づけ
導入した結果と成果
かかった時間:約1日・午前中:価値分析モデル(2時間) ・午後:要求分析ツリー(4時間)
成果・19個のIT要求→ 7個のIT要求・メンバーの納得感→高かった 議論が迷走したり、行ったり来たりしなかった
建設的な議論が可能に枝葉のレベルだと議論が収集しない(具体的、そもそも論で話しにくい)
Aさんのアイデア
Bさんのアイデア
取捨選択の議論がしやすい
(そもそもの価値に近い)
プロジェクトの目的A
プロジェクトの目的B
<個人の価値観>
<Projectの価値観>
「要求の爆発」の恐怖からの解放赤色のIT要求=要求分析ツリーをつくってからアイデアとして出たIT要求
(通常)優先度を決める段階で、さらに新しいアイデアを出す→ 議論を収束させていきたい段階では敬遠されがち=議論が終わらない(要求の爆発への恐怖)
(要求分析ツリーによる方法)「ツリーに葉を足すだけ」というのが目に見えるので、精神的負担が軽く、新しいアイデアに対しても、前向きに議論できる
connpassでの企画・戦略(抽選機能)
必要充分でミニマムなリリース
connpassでの企画・戦略(グループ機能フェーズ2)
1次リリース後に明らかになった課題を 1次リリース時の要求分析ツリーに追加
1次リリースの要求分析ツリーをもとに2次開発を検討
戦略における「攻め」と「守り」<攻めの戦略要求>
<守りの戦略要求>
ユーザー向けの大きな機能開発 etc
小改善、運用向け改善 etc
・「前回のフェーズは攻めて効果が出たから、引き続き攻める」・「前回は攻めて一定の効果が出たから、今回は守りを固める」
戦略要求レベルで
取捨選択する
connpassの企画・開発・運営を通してやりたいこと
よくあるチーム
意思決定者(企画担当者)
エンジニア デザイナー エンジニア
つくるもの考える
・上意下達の組織(企画者が上で、エンジニア/デザイナが下?)
<考える人>
<つくる人>
これからの組織
リーダー
エンジニアデザイナーエンジニア
つくるもの
考える
メンバーが考えるよう導き、まとめ、力を引き出す
納得感
<考えてつくる人>
・個の力を合わせる製品開発
・フラットな組織
ご清聴ありがとうございました! !
2014.12.15 @BPStudy#88