QCon Tokyo 2014
QCon2014 My Report Top
Detail Report#8/8
リーン開発の現場 ～塹壕よりアジャイルなプロジェクト運営～
市谷 聡啓:ギルドワークス株式会社
当日のスライドはまだあがっていませんが、かなり似た内容がかきにあります。
http://www.slideshare.net/papanda/ss-31975018
今まで
DevLove Founder
リーン開発の現場 共訳
（なんかとてもよさそうなのが伝わってきて思わず公演中にポチってしまいました。みなさんもどうぞ！）
本の内容
- 現実的な作戦
- 理論より実践
- 大規模プロジェクト
- 看板の活用
- チーム編成
- 問題の原因分析とうとう 実践してみた書
Do the right things right (正しいものを正しくつくる)
- 相手の意図もこちらの意図も正しく伝わらない
- 誰かが正解を持っているわけではない
- 期待、リスクをどのように管理するか
期待
- 関係者が互いに持っているプロダクト、プロジェクト、チームへの暗黙的な望み
- 期待を明らかにして役割、責務を明確にする
- 各レイヤー（チーム、プロジェクトリーダー、プロダクトオーナー）それぞれに期待と目的をもっている
期待とリスクの時間変化
期待は最初大きく、最後はなくなる、、(以下の図がすごくおもしろかった)
期待マネジメントという言葉は”達人プログラマー”でも確認できる
PMBOK 第5版でステークホルダーマネージメントという項目があてられている
インセプションデッキ
* Whyを明らかにする
* Howも明らかにする
* "チームメンバーが誰もいないところで合意したことを前提にしているから、プロジェクトがダメになる。"
* デッキのゴールデンサークル
仮説検証型と最短距離型
(すごい役立つ概念、区分方法：言語化することが大事とあらためて思った)
仮説検証型
一緒に考えよう
* 選択肢がいろいろある
* 試行、検証する
* 期間契約型
最短距離型
いついつまでにつくる
* 何をどう作るか、徐々に決められる
* 請負契約型
危険なパターン
- 開発者は仮説検証のつもり、企画は最短型のつもり（期限が明確）
- 何をつくるか決めてないけど3月末までにラウンチしたい (最悪のケース)
Plan/Do/Check/Action
仮説検証時の道具
リーンキャンバス
- 誰の何のために、何を提供するのか
- 企画書を検証する
- エリア間の整合性をテストする
- なぜそれが課題と言えるのか というチェックが重要
エクスペリエンスマップ
- 時系列でユーザーの行動と感情を追う
- キャンバスの課題がこまったことに現れるか
- 提供価値が顧客の感情を変えられるか？
ユーザーストーリーマッピング
- 行動ベースでユーザーが求めることを洗い出す
MVPユーザーストーリー
- ユーザーにとって価値の高いストーリーを上げる
- MVPとして検証すべきストーリを上げる
- 最上段をMVP とする
- MVP で検証したいことは何か言えるか
インセプションデッキ
プロジェクト全員で確認し、最短距離型へ移行する
最短距離型開発の計画
- 不確実性の排除
- バッファでリスクに備える
- 各タスクやストーリーにバッファを設けるとそれぞれで消費されてしまう
- 個別にバッファを載せず全体として設ける
荒ぶる計画のかいならし
- 要求のMust, Want Tryをわけてもらう
- 8-9割をMustについやす
- 総ポイント数、手持ち残ポイント数の管理
本当に理解してもらう
- 顧客の先の上司にまで理解してもらう必要がある
- 全体の期間での見込みと深さ、幅で調整
- 幅でコミットメント、深さで調整
Do
仮説検証型
- 何のための反復？
- 意思決定する期間
- 計画ミーティング：何を検証するか
- スプリントレビュー：検証結果の確認
カンバン
仮説検証フェーズの場合
- ワークフローが定まりにくい
- 課題の見える化
最短距離フェーズの場合
- 全体ワークフローの見える化
- 1枚の絵を全体でみる
さいごに
書籍P109
"理想とはたどり着くべき場所のことではなく、
ありたい姿に向かい続けることなんだ！"
(市谷さんわかりやすい説明をありがとうございます)