スクラムによるOpsBear開発2-インセプションデッキ
- 2. インセプションデッキとは • ゴールの明確化・プロジェクトへの認識の共有のためのフ レームワーク – 基本は10項目 – それぞれの項目の結論に行き着いた背景なども残しておくと有 用 • プロジェクト開始時に数日〜二週間かけて作る – プロジェクトの根幹に関わるような変更があれば考え直すこと もある • 参加者は開発チームだけではなく顧客や何かしら関係の あるステークホルダーは参加可能 – O’REILLYの「ストーリーマッピング」でフィッシュボウル・コラボ レーションという手法が紹介されている。これはよさそう。
- 5. 我々はなぜここにいるのか • 何のためにこのチームは動くのか明文化する • 例えば – 「運用現場で人が苦労していることをなくし、自律的運用を実現する」 など • 何をハッキリさせたいか – 開発メンバーの行動(思考)の指針 – 顧客 or 役員の意図(裏の思惑みたいなものも) • 欄外でもいいので書いておこう
- 6. エレベーターピッチ • プロダクトの本質を明確に説明できるよなものを作っておく • 開発メンバー視点ではプロジェクトの定義する目的で作る • プロダクトに対するニーズであり最終的なゴールがこれ • 「対象顧客」が複数考えられるならそのぶんだけピッチを作成してみるの もあり エレベーターに乗っている時間(30s程度)で投資家に 自分のプロダクトをアピールできるような売り文句のこと 参考: エレベーターピッチとは
- 7. パッケージデザイン • このプロダクトを店頭に並べるとしたらどのようなパッケージ が付くとよいか絵を描く • どうしたら使ってもらえるかを考えるために作るもの – ユーザから見て欲しくなるようなもの – 胡散臭くなってもOK • 作るもの – 機能ではなく効能 – キャッチコピー – 上記を合わせたパッケージ or パンフ
- 8. やらないことリスト • このプロジェクトでやりたいことを上げ、その中で「やらない」と決めたもの をリスト化する • プロジェクトのスコープ内外をハッキリさせるのが目的 • ブレストなどでざっくりしたあると良い機能をあげてみてそのあとで分類 • やらないことは暫く作らないつもりのもの – 6ヶ月でリリースならそこに含まないもの – 本当に作らないものと追加開発があれば作るかもしれないものはわかるよう にしておきたい • どうしても微妙なものは「後で決める」欄に入れておく – あまり多くならないように
- 9. ご近所さんを探せ • 関係者を洗い出しプロジェクトの全体像をつかむ – 顧客(担当者の後ろにいる人も)、技術協力者、営業、役員、セキュリ ティ担当、監査、事務処理に関係しそうな人などなど • 具体的な人が出てくるとよい – 書き出すと思いの外プロジェクトがでかいことに気づく – 特に開発チームから直接見える人の後ろにいたりするので注意 • 関係者の立場やニーズを把握しておく – 良好な関係を気付いて協力をする・もらうことができる状態にしたい • 開発後半に出てくると辛い – 最初から開発に巻き込むか、インセプションデッキやバックログの同 意をとっておきたい
- 10. 技術的な解決策の概要 • 概要レベルのアーキテクチャ設計図を作る • 言語 ライブラリ ツール その他技術要素の洗い出し • メモしておきたいこと – 実現可能か考える – 難易度やリスクの確認 – プロジェクトのスコープの確認 • 詳細なものができて困ることはないがこれが決定で はない
- 11. 夜も眠れなくなる問題は何？ • 思いつくリスクを上げてみる • リスクが視覚化されるだけでもスッキリする • リスクが開発チーム内のリスクなのか外のリスクな のか – 内部のリスクならばコストをかけて立ち向かう価値がある のかも考える – 外部要因なら注意すべき人・事象も考えておく
- 12. 期間を見極める • 初回リリースに必要なものをあげてロードマップ的 に書いてみる • ただし、これはcommitされたものではないことに注 意 • 長くても6ヶ月程度で考えた方が良い – 長くなるほど見積もりが正確じゃなくなる – 開発の大枠にざっくり期間を割り振ってみる
- 13. 何を諦めるかはっきりさせる • トレードオフスライダーで考える – 複数項目が同じレベルはNG • 品質・予算・期間のスライダーを作る – 開発チームとしては品質はMAXにしたい – この3つは優先度はあれど固定のものと捉える • ここにスコープ(機能を全て作るかどうか)のスライダー を加える – スコープはMINであることを納得する • 最後に捉えどころのないものを加える – ex) 効果の検証、webサービス化、汎用性など
- 14. 初回のリリースに必要なもの • ここまでで決めたことを踏まえてリリースまでに 必要となるものをリストアップ – 期間・予算・開発環境などなど – 開発チームは何人必要でどのような能力が必要なのかも リスト化してみる • 俺たちのAチーム参照
- 15. 参考資料 • Scrumプロジェクト開始のベストプラクティス #RSGT2018 – https://slide.meguro.ryuzee.com/slides/90 • アジャイルサムライ • http://d.hatena.ne.jp/nawoto/20120412/1334219020 • Fintan – https://fintan.jp/?p=951 • https://www.slideshare.net/makopi/20140708-yokohamadojo • https://sec.ipa.go.jp/users/seminar/seminar_tokyo_20150708 -03.pdf
Editor's Notes
- #16: https://www.slideshare.net/makopi/20140708-yokohamadojo