「正しいものを正しく作る」まとめ
「正しいものを正しく作る」を読了したので内容をざっくりまとめてみました。
感想
- ゴールデンサークル(why,how,what)が迷った際にどちらへ進むかの道しるべになる
- チームとして働く際にビジョンやミッションなどからチーム全体の共通の認識を作っていくことは重要そう
- 以前読んだ「グロースハック完全読本」と同じく仮説と検証を繰り返して進めていく
- 正しくないものを作らないことで結果として正しくなるようにする
第一章 なぜプロダクトづくりがうまくいかないのか
- プロダクトや働き方に多様性があることがプロダクトづくりを難しくしている
- プロダクトの多様性
- SOE (System of engagement) : 顧客との関係性を育むためのシステム
- SOR (Syatem of recording) : 正確に情報を管理するためのシステム (基幹システム)
- 働き方の多様性
- リモートワークなど
- プロダクトの多様性
- いままでの不確実性へのアプローチ
- 要件定義で確実性を上げる
- 要件定義とは
- 要求 (様々な決済方法を使えるようにしたい)
- 要件 (カード決済機能を追加する)
- 仕様 (利用可能なカードの種類・キャンセルできるか)
- 要件定義とは
- 合意を重視する
- 合意形成を遵守する
- 要件定義で確実性を上げる
- 上記では本当に必要なものを作ることができないので、「アジャイル開発」が誕生
- 誰も正解がわからないので、間違えることを念頭に置き担当者間で合意形成をしながら進める
- アジャイル開発は経験による知識を元に実践していく必要があり、以下の問題がよく発生する
- 作るべきものの決め方の混乱
- イテレーティブに進める上で何を作るかを決定しないといけない
- 合意形成についての認識違い
- バックログの詳細さが決まっていないと曖昧な記述が生まれる
- とりあえず作ってしまうのもあり (要関係者との合意)
- 変更が不可能になることへの関係者の不満
- スケジュール的にフィードバックを反映する時間が確保できない
- 作るべきものの決め方の混乱
第二章 プロダクトをアジャイルにつくる
- アジャイル開発とは
- XPやリーンなどの複数開発手法が合わさって誕生した開発手法
- 以下の要件を満たしていればアジャイル開発ということができる
- プロセスやツールよりも個人との対話を
- 包括的なドキュメントよりも動くソフトウェアを
- 契約交渉より顧客との協調を
- 計画に従うよりも変化への対応を
- プロセスやツール、ドキュメントをないがしろにしてよいというわけではない
- スクラムとは何か
- 経験主義に基づくプロセスのフレームワーク
- 3つのコンセプト
- 透明性 (チーム内で認識の齟齬が発生しない為に状況の「見える化」)
- 検査 (作成物や状況の検査を頻繁に行う)
- 適応 (検査で問題があった場合にチームとして適応する)
- スクラムチーム
- 3つの役割
- プロダクトオーナー
- バックログの管理
- フィードバックから施策(チケット)を作成
- 開発チーム
- 目的に合った仕様(要求)の実現
- スクラムマスター
- 透明性・検査・適用を高めるための支援を行う
- プロダクトオーナー
- 自己組織化と職能横断
- 自己組織化 (自分たちでミッションを達成するための取捨選択をしていく)
- 職能横断 (チームの外側に頼らずに仕事を成し遂げる)
- 3つの役割
- スクラムイベント
- スプリント
- スプリントプランニング
- プリントの最初に実施する
- チーム全員で何を作るかを決める
- 実現可能かファイブフィンガーで確認する
- デイリースクラム
- スプリント期間中に日次で行う
- 昨日の実績の報告
- 本日の予定の共有
- 問題の報告
- スプリントレビュー
- スプリントの最後に実施する
- 成果物のフィードバックを行う
- PO(プロダクトオーナー)も参加するとよい
- スプリントレトロスペクティブ
- スプリントとスプリントの間に行う
- スクラム活動自体の検査
- 反省会(誰かを詰める)にならないように注意する
- スプリントプランニング
- スプリント
- スクラムの成果物
- プロダクトバックログ (プロダクトに必要な課題が管理される)
- スプリントバックログ (スプリントで行う課題が管理される)
- インクリメント (スプリントで作成したプロダクトの機能)
- 自分たちのアジャイル開発とどう向き合うべきか
- アジャイルを導入する前にゴールデンサークルを考える
- whyが抜けて手段が目的かしないように優位する
- ゴールデンサークル (人に行動を促すフレームワーク)
- 目的を伝える (why
- プロダクトづくりとしてありたい姿はどのようなものか
- アジャイルで開発する意義で当てはまるものはあるのか
- 目的を実現する手段を伝える (how)
- アジャイルで開発する場合、最初はスクラムがおすすめ
- 文献がいっぱいある為
- 具体的に何をするのかを伝える (what)
- 具体的に誰が何をするのかを考える
- CI環境を構築
- ミーティングの出席者
- フレームワークの選定
- などなど
- 目的を伝える (why
第三章 不確実性への適用
- アジャイルで乗り越えられない不確実性
- 合意形成の課題
- 関係者との合意をどのように進めていくか
- 暗黙的な期待があることが原因 (基本は以下の4つ、特に品質についてが難しい)
- Quality (品質)
- Cost (コスト)
- Deliver (ローンチタイミング)
- Scope (機能の範囲)
- 期待マネジメントをして解決する
- 学びから生まれる課題
- わからなかったことが分かるようになり想定外の作るべきものが生まれる
- 作るべきものを作るためにトレードオフ(作らないもの)が必要なことを関係者が認識する
- 合意形成の課題
- 不確実性へ適応する術
- 前提として「共通の軸」が必要
- 適応する術は以下の3本
- 余白の戦略
- スプリント強度を高める戦術
- 全体への共通理解を統べる作戦
- 共通の軸を持つ
- 不確実性に適応する術として、共通の軸(ミッション)が必要
- ミッションを定義することにより自立的に動くことが可能 (ミッションコマンド)
インセプションデッキを実施してチームとしての共通認識づくりをする- 我々はなぜここにいるのか: プロジェクトのミッションは何か
- エレベータピッチ: プロダクトの特徴を短いステートメントにまとめる
- パッケージデザイン: 利用者から見たプロダクトの価値を表現
- やらないことリスト: 大まかなスコープの特定。特にスコープ外について
- ご近所さんを探せ: プロジェクトコミュニティ(関係者)を明らかにする
- 技術的な解決策: 採用する技術の利点とリスクの説明
- 夜も眠れない問題: チームや関係者が認識しているプロジェクトのリスク
- 期間を見極める: 必要なプロジェクト期間の算出
- トレードオフスライダー: QCDSの優先順位
- 何がどれだけ必要か: ミッション達成に必要な期間、予算、チーム編成
- いつ期待マネジメント(潜在的/暗黙的な期待を捉える)を行うのか
- 初回はできるだけ早く行う
- プロダクトの形成が進むにつれて期待は膨らんだり萎んだりする
- 余白の戦略
- 調整の余白
- 「広さと深さをコミット」
- 要求も機能も明確になっている必要があるため難しい
- 「深さでコミット」
- 全体としてユーザに必要な機能が完成しないケースがあるため難しい
- 「広さでコミットし、深さを調整する」
- 上記2つでコミットできないため、この方法でコミットするのが現実的
ユーザストーリーマッピングを行い必要な機能の洗い出しを行う- ユーザの行動から機能を洗い出して、以下の内容から優先度付けを行う
- ユーザがどのような存在か確認する
- ユーザが関わるシーンを洗い出す
- シーンごとにユーザの行動を洗い出す
- 各行動に対して課題を挙げる
- 課題解決に必要なユーザストーリーを取り出す
- ユーザストーリーを優先度付けする
- 最初に作る範囲(MVP)を特定する
- ユーザの行動から機能を洗い出して、以下の内容から優先度付けを行う
- 「広さと深さをコミット」
- 期間の余白
- プロジェクトとしてバッファはひとまとめにする
- 各担当者が暗黙的なバッファを積むと相当なバッファになってしまう
- バッファの残管理を行うようにする
- 受け入れの余白
- プロダクトに対する学習で出てきた要求は「アイスボックス」(保留用のスロット)で管理する
- アイスボックスの課題は、必要に応じてバックログに取り込みを行う
- 調整の余白
- スプリント強度を高める戦術
- スプリント全体の不確実性は余白の戦略で受け止める
- チームの成熟度を上げて目の前のスプリントを確実に遂行していく必要がある
- 成功循環モデル (スプリントを完遂することでチームへの期待感が高まり、以下の質が順番に上がっていく)
- 関係の質 (チームとしての関係性が確保される)
- 思考の質 (問題について議論が進みやすくなる)
- 行動の質 (適した行動をとれるようになる)
- 結果の質
- 成功循環モデル (スプリントを完遂することでチームへの期待感が高まり、以下の質が順番に上がっていく)
- 背骨で駆動する
- ユーザストーリを完遂するために必要な機能に注力する
- 背骨ができてから追加機能(ソートなど)を実装する
- プロダクトをクリーンに保つ
- 受け入れ条件を定義している
- バックログアイテム単位での受け入れ条件を定義する
- 最初から完璧にやるのは難しいので徐々に進めていく
- ベロシティを計測し、安定させている
- 課題の工数見積もりが正しいことが前提となる
- 過去に対応した課題などから想定的な工数見積もりをして確度を上げていく
- 受入テストをしている
- 受け入れ条件がある前提
- テストは自動化を推奨 (機能が必要か検証が済んでからでも可)
- 振り返りをして改善を続けている
- ベロシティを安定させるために必要
- netflix式のフィードバック形式
- 個々の振る舞いについて以下をフィードバックする
- Start (始める)
- Stop (やめる)
- Continue (続ける)
- チーム単位だと個々のフィードバックが薄くなるので個人単位
- 個々人の目がチームに向くように動機づけをする (MVPを表彰するなど)
- 個々の振る舞いについて以下をフィードバックする
- 実運用相当のデータが揃っている
- フィードバック時に実際の動作と遜色なく確認できる
- テストデータを作成する際に貯まる知見がある
- 受け入れ条件を定義している
- 全体への共通理解を統べる作戦
- 現在のプロダクトの状況が正しく把握して、正しく判断できるようにする
- プロダクトの状況を把握するために以下を実践する
- 個人レベル
- Share (共有): 個人の考えや行動を共有する
- Assert (表明): その内容を踏まえて意見を述べる
- Reflect (ふりかえり)
- チームレベル
- 線表を作る (大まかなスケジュールが確認できるようにする)
- スケジュールは絶対ではなく、プロダクトのあるべき方向に合わせて更新する
- ファシリテーターレベル
- 必要に応じてイベント (チームビルディング、振り返り)を企画する
- 個人レベル
第四章 アジャイル開発は2度失敗する
- チームは2度壁にぶつかる
- アジャイルへ移行するタイミング
- あらゆる場面で問題が発生する
- 顕在化した問題には対応できるが潜在的な問題は気づくのが難しい
- 外部から経験者のフィードバックをもらい気づくとよい
- 小さく失敗することを意識する
- プロダクトがローンチした後にユーザにマッチしないタイミング
- 開発者チームは正しく間違ったものを作っていた
- 開発者チームの役割は作るところまでという認識がある
- 暗黙的な役割の境界線が存在している
- アジャイルへ移行するタイミング
- プロダクトオーナーの果たすべき役割
- プロダクトの方向性の管理 (なぜこのプロダクトを作るのか)
- ビジョン (世の中にどのような変化をもたらしたいか)
- ミッション (ビジョンの実現のために実現するもの)
- プロジェクト (ミッションに予算や期限が付いたもの)
- スプリントゴール (ミッションをスプリント単位で分割したもの)
- コンセプト
- バックログアイテムとビジョンの粒度の差を埋める
- 誰のどんな問題を解決するかシンプルにまとめたもの
- バックログアイテムの優先度を考える際に利用する
- プロダクトの仮設の管理 (プロダクトの世界観を実現するために何を備えるのか)
- ユーザにどのような体験を提供するか (バックログアイテムの作成)
- インターフェースはどうあるべきか (UIの方針決め)
- 持続可能なビジネスモデルはどうか (ビジネスモデルの設計)
- プロダクトを形にするために必要な運用スキルと知識
- ソフトウェア開発における基本的な知識
- プロダクトバックログの管理方法
- 受入テストの実施とテスト結果の活用
- ユーザテストによるフィードバックと継続的な継続
- プロジェクトマネジメント
- コミュニケーション設計
- プロダクトの方向性の管理 (なぜこのプロダクトを作るのか)
- チームとプロダクトオーナー間に横たわる2つの境界
- 「作る」と「作らない」の境界
- エンジニアリングへの知識の度合い
- スクラムへの理解の度合い
- アウトプットとアウトカムの境界
- アウトプット (結果)
- スプリントを通して生み出される機能など
- エンジニアがメインで取り組む
- アウトカム (成果)
- プロダクトをユーザが利用して価値を感じること
- プロダクトオーナーがメインで取り組む
- アウトプット (結果)
- 「作る」と「作らない」の境界
- 越境する
- プロダクトオーナーは万能ではないので、チームとして補完(越境)をする必要がある
- 越境時は、チームとしての基準がないため混沌とした状態になる
- チームとして「プロダクトとして何が正しいのか」(基準)をつくるため「仮説検証」を行う
第五章 仮説検証型アジャイル開発
- 自分たちの基準を作る
仮説キャンバスを利用して基準を共有する- 最初から信頼性の高い基準を作ることは難しい
- 仮説検証をすることでわからないことを減らし、分かったことを増やしていく
- 仮説を立てる前にユーザへの理解が足りていない場合は
エスノグラフィー調査を実施する - 検証内容や進むべき方向を管理するため、計画を立てる必要がある
- 開発の計画を作る
- ゴールに向けていつまでに何をするか (状況整理をつけ意思決定に利用する)
- 開発中に何度もテコ入れを行う
- 検証の計画を作る
- ビジョンに向けてわからないことをわかるようにする活動の計画
- わからないことが発生するたび、計画を立てる (誰、いつ、どうやってなど)
- アンチパターン
- とにかく始める (現状がわからないと徒労に終わるかも)
- 教科書通りに進める (活動の意味を理解しないと)
- 唯一わかっていることを頼りに進める (これからわかるようになるものがある)
- 開発の計画を作る
- 検証は一回きりではなく段階的に行う必要がある
- 正しくないものを作らないための原則
- 意思決定(絞り込み)の段階には大きく以下の３つがある
- 何のために必要なのか(目的選択の段階)
- 問題が解決できるかを確認するためにコンセプトを検証する
- 実現のために何が必要なのか(実態選択の段階)
- ユーザストーリーマッピングなどでユーザにとって有用な最小範囲の要求を取り出す
- どうやって実現するか(手段選択の段階)
- 機能設計
- UIデザイン (形態(UI)は機能に従う)
- データ構造
- 何のために必要なのか(目的選択の段階)
- 上記が進むにつれ、最初に検証すべき範囲のプロダクト(MVP)が特定される
- MVP開発はユーザに体験してもらわないとこれ以上の検証ができない場合に行う
- 意思決定(絞り込み)の段階には大きく以下の３つがある
- 仮説検証型アジャイル
- 実際に仮説検証を進めてMVPを特定していく方法
- モデル化と検証を繰り返し進めていく
- モデル化 (わかっていることを元に立てた仮説のこと)
- 検証 (モデルを検証して新しいわかっていることを増やす)
- モデル化と検証はそれぞれ二回以上行う
- 一回目のモデル化 (課題仮設)
- 仮説キャンバスを作成する
-
提供者側と利用者側の視点を突き合わせてマッチするか確認する
| 提供者 | 利用者 | | — | — | | 目的 | ビジョン | | 実現手段 | 状況 | 優位性 | 代替手段 | | 評価指標 | チャネル | | 提案価値 | 課題 | | 収益モデル | 市場規模 | - 仮説の一本線 - [仮説] > [代替手段] > [不満] > [提案価値] > [実現手段]とつながるとよい
- 一回目の検証 (ユーザインタビュー)
- 想定ユーザの状況を知り、課題を集め、優先度の高い課題を抽出する
- 仮説キャンバスで上げた状況に当てはまるユーザにインタビューを行う
- 仮説の一本線が成り立つか、提供価値を受け入れそうかを確認する
- インタビューでは以下に注意する
- 判断の根拠を確かめる
- 課題が具体的にいつどこで発生したのかなど
- 同じ質問を繰り返し行う
- 最初と最後に同じ質問をした際、回答が変わることがある
- 最初の回答は直感的になりがち
- 主語を確かめる
- 主語がインタビューイーからずれることがある
- 比較による回答を得る
- 相対的なほうが判断がしやすい
- インタビュー自体の仮説を立てる
- インタビューの仕方についてより良いインタビューができるよう仮説を立てる
- 判断の根拠を確かめる
- 二回目のモデル化 (ソリューション仮説)
- 一回目の仮説検証で得た情報を元に以下を利用してユーザのフローをモデル化する
- カスタマージャーニーマップ
- サービスブループリント
- ユーザストーリーマッピング
- 完成したフローに仮説キャンバスで上げた課題仮設が登場することを確認する
- 課題仮設が登場しない場合は、フローの完成度が低いか課題が間違っている
- 一回目の仮説検証で得た情報を元に以下を利用してユーザのフローをモデル化する
- 二回目の検証 (プロトタイプによる検証)
- 抽出された課題に適したソリューション(解決策)を特定する
- プロトタイプをユーザに利用してもらい、よりリアリティのある反応を見る
- プロトタイプはソリューション仮説で作成したユーザの行動フローを元に決める。
- 一回目のモデル化 (課題仮設)
- その他の検証手段
- アンケートによるセグメント絞り込み
- ランディングページによるチャネル検証
- ユーザや現場の観察
- アクティングアウト
- 検証キャンバス
第六章 ともにつくる
- 正しいものを探すから正しいものを作るへ
- プロダクトバックログ詳細化
- 機能仮設の段階
- 予算確保のために概算見積もりを行う
- 概算見積もりは、各機能仮説毎に過去の事例から相対的に行う
- 詳細がわからないものを想像で保管して数字出してもムダ
- MVPを特定する段階
- ユーザストーリーマッピングを用いてMVPを特定する
- 取り出した機能仮設をリスト化してストーリー形式(XとしてYしたい、Zだから)で整える
- リストを元にメンバーで再度見積もりを行う
- スプリントプランニングの段階
- プロダクトバックログに対する受け入れ条件をまとめる
- 機能仮設の段階
- 仮説検証の精度と頻度
- 頻度
- プロダクトの構想が固まっていない場合は高頻度
- 作らないで行える検証をできるだけ行い、多くのわかったことを手に入れる
- 精度
- 一通りの検証を終えた後に精度を重要視する
- 断片的な情報を得ただけで精度を上げても無駄が多い
- 頻度
- わかったことを正しく作る
- 同調圧力、確証バイアスに負けずにわからないことを分かったことにしないように注意
- わからないことが多いことはいいことなのでどんどん増やす
- プロダクトバックログ詳細化
- 視座、視野を越境する
- 視座を動かすことで見えるものが増える
- 視座の高低: プロダクトの目的、ユーザの目的、ビジネスの目的など
- 視座の広狭: スコープとするユーザや関係者の範囲
- 視座を動かすことで見えるものが増える
- チームとともにつくる
- 多様性は不確実性を高めるが、不確実性に対応するためには多様性が必要
- 一人で全てのことができる人は少ない
- 言語化(会話やドキュメント)で伝えても文章内のことしか伝わらないのでシミュレーションなどを通して解釈の幅を持たせたい
- 作り手で基準を持ち、それをスプリントの中ですり合わせて共通の基準にしていく
- 多様性は不確実性を高めるが、不確実性に対応するためには多様性が必要