なぜその機能を作るのか？

Transcript

1. なぜその機能を作るのか？ 要件・計画・設計をつなげて考える 要件 計画 設計
2. 今日の問題意識 一直線に進むはずの開発が、実際には何度も後戻りする 要件 要件が変わる 見積もり 設計 見積もりが外れる 要件・計画・設計を別々の活動として捉えていないか？ 実装 設計を見直す
3. 出発点は「何を作るか」ではない 現場で最初に届くのは、いつも「機能の要求」 ユーザーの声 ユーザーの声 ユーザーの声 「CSV出力が欲しい」 「承認機能が欲しい」 「検索を強化したい」 そのまま作ると「欲しかったのはそれじゃない」
4. 本当に知りたいのは「要求」ではなく「目的」 同じ要求でも、目的が分かれば作るものが変わる 要求（言われたこと） 本当の目的 CSV出力機能 Excelへの転記をなくしたい 承認機能 責任を明確にし監査に応えたい 高機能な検索 情報を探す時間を減らしたい
5. 機能は「課題」ではなく「解決策」 要求された機能は、誰かがすでに考えた解決策にすぎない 課題 解決策 機能 開発者が理解すべきはここ そのまま受け取らない 課題と成功条件 要求された機能
6. 要件は「完成形」ではなく「仮説」 理解が深まるほど、要件は書き換わっていく 最初に分からないこと 開発中に起こること 業務の実態 新しい事実が分かる 利用者の行動 制約が見つかる ユーザー理解が深まる → 要件変更は失敗ではなく学習の結果 技術的な制約
7. 計画が外れるのは、腕前だけの問題ではない プロジェクト開始時点は、未知がいちばん多い プロジェクトの進行 → 未知が大半 未知が減る 開発とは、未知を既知に変えていく活動である だから、新しい発見のたびに計画は変わる 既知が増える
8. 計画も仮説である 守るための約束ではなく、更新するための道具 計画 NG OK 計画 = 守るべき約束 計画 = 現時点での仮説 実行 学習 更新 再計画
9. 良い開発は学習し続ける 小さく作り、試し、学び、計画に反映する 作る 試す フィードバック 振り返る 改善する 学習して計画を更新し、また小さく作る 今の理解は正しいか 優先順位は変わっていないか 価値を届けられているか
10. 良い設計は良い理解から生まれる パターンやフレームワークの知識は出発点ではない 業務理解 モデル 設計 コード 理解すべきこと 理解が曖昧だと ユーザー / 業務 / 課題 / 成功条件 モデルも責務もコードも曖昧になる
11. 要件・計画・設計はつながっている 一方向の工程ではなく、学習で回り続ける一本の流れ 課題を理解する 要件を考える 計画を立てる 実装する 設計に反映 理解を更新 計画を更新 学習する それぞれ独立していない ― 価値の理解・学習・理解の深化が全体を支える
12. 実は、ここまで同じ話をしていた 手法名を出さずに語ってきた三つの軸 価値 学習 理解 本当に解決すべき課題は何かを問う 小さく試し、適応する 業務を理解しモデルとして表す
13. ネタバレ ― 三つの軸には名前がある ただし、重要なのは名前ではない 価値 学習 理解 Lean Agile DDD 価値に着目 学習と適応 業務理解とモデリング 重要なのは用語を知っていることではなく、その背景にある考え方
14. まとめ 機能を作る前に、なぜそれを作るのかを考える 機能より価値 予測より学習 要件も計画も仮説 ― 学習した結果を反映して更新する 計画を守る前に、学習した結果を反映しよう。 設計を議論する前に、何を理解すべきかを考えよう。 技術より理解