正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について [Kindle]
- ビー・エヌ・エヌ新社 (2019年6月14日発売)
- Amazon.co.jp ・電子書籍 (399ページ)
感想・レビュー・書評
-
詳細をみるコメント0件をすべて表示
-
自分のあり方ややり方と
チームや会社の現状やあり方ややり方にギャップがあるときに
自分とは合わない だったり そこは自分の範疇じゃない とかで線を引くのは簡単だけど
つくること(というよりアウトカムかな)から本当に目を逸らさないのであれば
そこを自分なりに認識して、受け止めて、消化して、理解することも必要なことだと思った
それが 視座、視野を広げる ということかな
絶対的に正しいものはないけれど、そこに向き合う姿勢を崩さず(崩されず)保ち続けることは大事で
そのさきに、そのときにおいての正しいものを見つけられて、その喜びも苦しみも背負えるチームがある
という意味で6章はこれからのビジョンの提示(表明かな)で、私たちがこれから選択できる可能性のひとつ。
そのための考え方ややり方として1〜5章という形にみえた。
表題にはないけれど、やっぱり"旅"というたとえがよく似合う。 -
とても勉強になった。構成も内容もよいと思います。
読み物的なのにしっかりおさえられてる感じ。
アジャイルかじったものには、あるある満載。
参考文献もうまく引用してくれてるので効率的に学べます。 -
プロダクト、プロジェクトマネジメントの本
仮設検証とアジャイル開発について -
アジャイル開発における起きがちな問題や
考慮すべき事項をまとめてくれている本。
確かにそうだなっと思うことが多く書いてあり、
プロダクト開発において、大変参考になりました。
何を大事にすべきか?といったことを意識しても、
日々忙殺されて忘れがちなポイントが多かったので、
繰り返し忘れないように学び続けて定着化したい。
【勉強になったこと】
・プロダクト開発における過去と現在
これまで:
決められていることを実現することの難しさ
現在:
決められないこと、あるいは分かっていないことを
実現する難しさ
より不確実性の高い課題に迎えるスキルや姿勢が
求められる時代になってきている。
・要求、要件、仕様の違い
要求:こうしたい、こうありたいという希望
要件:要求を実現するには何が必要か?
仕様:要件を実現するための手段、仕組み
・変化に対応するために必要不可欠なのは、
「誰も正解が分からないんだから、アタリを付けて、
間違う前提を念頭に置きつつ、合意形成しながら
進めていく」という一歩踏み出す勇気と、
リスクに対するあらゆる対策を考えておくこと。
・スクラムにおける、スプリントには、
スプリントプランニング
デイリースクラム
スプリントレビュー
スプリントレトロプロスぺクティブ
という要素で構成されている。
・デイリースクラムで共有することは、
①昨日何をやったか?
②今日やることは何か?
③昨日新たな障害を発見したか?
・早く少しだけ形に出来ることで得られる9つの意義
①フィードバックに基づく調整で、目的に適した
プロダクトに仕立てられる。
②形にすることで、早めに関係者の認識を揃えられる
③作るものやチームの問題に早く気づける
④チームの学習効果が高い
⑤早く作り始められる
⑥結合のリスクを早めに倒せる
⑦Time to Marketが短い
⑧サンクコストを小さく出来る
⑨開発チームのリズムを整えられる
・変化に耐えるためには、調整の余白を意識する必要
があり、調整の余白とは、
「広さでコミットし、深さで調整する」
ことを意味している。
広さとは「プロダクトへの要求の範囲」を言う。
・やり抜く力を高める力の強化が変化に対応するには
必要不可欠。あらゆる手段を考えてどうすれば出来る
といったことを常に考え、ゴールに向かって進んで
いく力が無いと上手く応対出来ない。
場合によっては、これまで検討してきたことも、
捨ててしまうといった思い切りも必要。
・成功循環モデル
関係の質 → 思考の質 → 行動の質 → 結果の質
・プロダクトづくりの状況をクリーンに保つ条件
①実運用担当のデータが揃っている
②受入条件を定義している
③受入テストを実施している
④ベロシティを計測し、安定させている
⑤振り返りを実施し、カイゼンし続けている
・SAR(Share-Assert-Reflect)
Share:共有
Assert:表明
Reflect:振り返り
・プロダクトを形にするために必要なスキルと知識
プロダクトがどうあるべきかの牽引のため:
・受入テストの実施とテスト結果の活用
・ユーザーテストによるフィードバック取得と
継続的な計測
チームとの協働のため:
・コミュニケーション設計
・プロダクトバックログの管理方法
プロジェクトを遂行するため:
・プロジェクトマネジメント
開発メンバーとの意思疎通のため:
・ソフトウェア開発の基本的な知識
・正しいことを見つけるのは難しいこともあるので、
むしろ正しくないことの学びを積み重ねることで、
正しいことに近づく努力をしていくアプローチの
ほうが効果的なこともある。
・仮説キャンバス
対象者視点:
ビジョン
状況(傾向)
代替手段
チャネル
顕在課題 潜在課題
想定する市場規模
提供者視点:
目的
提案価値
優位性
評価指標
実現手段
収益モデル
・プロダクトオーナー1人で回らないのなら、
「補佐」ではなく「代行」を置いて意思決定の一部を
委ねてしまうことも大切。
・別の視座を手に入れる手段として、
自分で経験してみる
その立ち位置の人との対話を通じて考えに触れる
の2つがあり、後者をより実践していくべき。 -
プロダクトを作る上で大切な事が書いてある本。
いわゆるプロダクトオーナーの教科書かな。
しかしながら、プロダクトに関わる人みんなが意識して良いと思う内容が詰められているので、プロダクトを作ることを理解したい人に読んでほしい。
不確実性や仮説検証は一人で立ち向かうんじゃなく、チームで立ち向かえるようにする。
そんな戦略や戦術と進め方が学べる本。
今でもたまに流しながら読んでいる。プロダクトやチームの向き直りにつかわせてもらっています。 -
エンジニアとしてもすごく学びの多い本。
是非プロダクト開発に携わるすべての人に読んでほしい。 -
アジャイル開発が世間一般に広く知られた今、「アジャイルで開発する」というのは珍しくなくなってきた。ただし、それをうまく運用できていない現場も多々ある。
以下のようなアジャイルがうまくいっていない案件に入っている人は読むべき本だと思う。
・アジャイル開発の案件に入ったがなぜかうまく機能していないチームにいる人
・明確な理由もなくアジャイルを選択したチームにいる人 -
アジャイルの中でもスクラム開発の手法を中心にプロダクトをどうプランニングし、どう開発するかの型が書かれている本。プロダクトオーナーであればある程度理解していることも多いので振り返りや辞書的に使うのがよさげ。
メモ
改めてSORはかたくつくる、SOEは不透明なので進化し続ける
要求は、こうしたい、ああしたいというユーザーの業務や活動として実現したいこと。オフィスの外から見積もりみたいなー、とか
こうしたい、の実現が要件
その詳細条件で仕様
回収不可能になったことをサンクコスト