【読書メモ】正しいものを正しくつくる
なぜプロダクトつくりがうまくいかないのか
- 技術もプロセスも進歩している
- チームもコミュニケーションも進歩している
- 正解のないものを作る
技術もプロセスも進歩している
ひとつのプロダクトバックログアイテムを倒すのに、サーバサイドからフロントエンドまで一人で担うことも今では珍しくなくなっている。プロダクトのコードを書くのみならず、テスト環境の構築からデプロイの仕組みまで準備する
チームもコミュニケーションも進歩している
役割の定義を細分化して、ボールの受け渡しをいかに効率よくやるかが問われていたが、今やスクラムを推し進めているチームであれば、スプリントごとにそれぞれの担う役割を変えながら状況に適応するようになっている
正解のないものを作る
誰かの頭の中に正解イメージがあってそれをうまく取り出してコードにしていくという開発ではない
どうあるべきか本当のところ誰にもわからないが、なんとかして形に仕立てていく
「決められていることを実現する難しさ」から「決められないこと、あるいはわかっていないことを実現する難しさ」に変わっている
要求なのか、要件なのか、仕様なのかをはっきりさせる
要求
「こうしたい、こうありたい」という希望のこと
要件
「こうしたい」という要求を実現するための条件
仕様
要件を満たすための詳細な条件
多様性がプロダクトの不確実性を高める
仕事についての共通理解は、技術者なのか非技術者なのかによってもさらに困難が増す。何しろお互いの仕事をやったことがないので、「何が難しいのか」「なぜそれほどの時間がかかるのか」が想像し難い。
バッファはプロジェクトでまとめて取る
バッファを有効に活用するためには、プロジェクトとしてひとまとめにすべきである。これが、期間の余白の要のひとつだ。見積もりの段階で、個々人がバッファを織り込んでしまう余地をなくす。
バッファの残りを管理する
スプリントプランニングでリリースプランの見直しを行い、残りのバッファを定量的に把握する。リリースプランの見直しとは、完成の着地時期をシミュレーションし続けるということ
残りバッファが5割を切ったり3割を切ったりした節目に、そのタイミングでの残りのリスクも想像して、関係者と状況の見立てについて共有を行う
バッファの消費加減によっては、変更の受け入れ度合いを調整する必要が出てくる。その理解をチームと関係者で得て、合意する
仮説検証のアンチパターン
1. 分からないからとにかくやる
情報と知識は違う。情報とは事実であり、データに過ぎない。それが意味があると識別できてこそ有用な知識になる
2. わからないから、教科書どおりに進める
いくらやり方が正しく、かつそれを計画的に進めていたとしても、その検証活動で「何を学ぶつもりなのか」がなければ、その活動自体の意義は乏しい。
3. わからないから、唯一分かっていることを頼りに進む
判断で忘れてはならないのは、今わかっていることを前提とした意思決定は、そのわかっている範囲内での判断でしかないということ
自分たちは「何がわかっていないかが、わかっていない」という可能性がある前提に立ってプロダクトづくりに臨む
感想
違和感をそのままにしないで、状況を言語化して、問題を可視化して、足りてない情報を認識して、必要な情報を参照して、実行に取り入れて、振り返るようにするのが大事だな。
この記事が気に入ったらサポートをしてみませんか?