正しいものを正しくつくる の商品レビュー
いわゆるアジャイル開発の進め方をスクラムをモデルとして具体的に解説。チームビルディングからチームにおける役割、日々のスプリントの回し方、マインドなどが解説される。 私は本書が想定する読者ではなかったため、あまり刺さらなかったけれど、アジャイル・スクラムを具体的に導入したい方には実...
いわゆるアジャイル開発の進め方をスクラムをモデルとして具体的に解説。チームビルディングからチームにおける役割、日々のスプリントの回し方、マインドなどが解説される。 私は本書が想定する読者ではなかったため、あまり刺さらなかったけれど、アジャイル・スクラムを具体的に導入したい方には実践的ガイドとなっているだろう。 とはいえ、守破離に言及する文脈で、あえて不確実性を残すことも必要という観点は面白かった。新規プロダクト開発はややもするとみんなが想像できる安定感のあるプロダクトに落としてしまいがちだけれど、それをあえて揺さぶるために不確実性を残す、取り込むという観点は忘れてはならないだろう。何のために新規事業開発をつくろうとしているかはスプリントを回している内に見失いかねないけれど、それを思い出させてもらえるからだ。
Posted by
アジャイルの実践が必要になり、メソッドとしての知識ではなく原則を知りたくて読みました。仮説検証型アジャイル開発というプロセスを提唱していますが、それが標準的なアジャイルと何が違うのかは(知識不足で)わかりませんでした。陥りそうなアンチパターンなどがわこりやすく、現在進行形で参考に...
アジャイルの実践が必要になり、メソッドとしての知識ではなく原則を知りたくて読みました。仮説検証型アジャイル開発というプロセスを提唱していますが、それが標準的なアジャイルと何が違うのかは(知識不足で)わかりませんでした。陥りそうなアンチパターンなどがわこりやすく、現在進行形で参考にしたい考え方ばかりでした。間違ったものを正しく作ることを避けること、そのために視座を意識的に行き来することが必要と感じました。
Posted by
具体的なHowについては、実践しながらインプットするとして、一旦概念的なもののメモを残しておく。 ◾️第二章: スクラム開発 4つの価値 ・対話を重んじる ・早く動くものを作る ・顧客との協調 ・計画よりも変化への対応 原則 ・早く、継続的に ・変化を味方につける ・振り返り...
具体的なHowについては、実践しながらインプットするとして、一旦概念的なもののメモを残しておく。 ◾️第二章: スクラム開発 4つの価値 ・対話を重んじる ・早く動くものを作る ・顧客との協調 ・計画よりも変化への対応 原則 ・早く、継続的に ・変化を味方につける ・振り返り改善する チーム ・PO）プロダクトの価値の最大化 ・開発チーム）製造・完成 ・SM）スクラムプロセスの実施中 スクラムイベント ・プランニング ・デイリースクラム ・レビュー ・レトロスペクティブ 成果物 ・プロダクトバックログ ・スプリントバックログ ・インクリメント 9つの意義 ≒ 目的 ・早く認識を揃える ・早く問題に気づく ・繰り返して学習する ・早く市場に出す ■第五章: 価値探索 基本スタンス ・モデル化とその検証の繰り返し モデル化）分かっていることの言語化・図式化 仮説の種類 ・課題仮説 ・ソリューション仮説 検証結果のジャッジ観点 ・Problem-Solution-Fit ・Product-Market-Fit 具体的な方法 ・叩き作成（仮説キャンバス） ・課題設定の正しさの検証 ユーザーインタビュー ・課題に対する解決策の正しさの検証 プロトタイピング ・参考）その他の手法 アンケート）課題仮説、ユーザーが見えないとき --- 感想 ・環境変化が激しい時代なので、ウォーターフォール型の開発プロセスが時代にフィットしないっていうのはこれまで何度も言われてきていること ・そういう状況に対してアジャイル開発という手法で立ち向かおうとするってのもよく聞く ・その整理でいくと、本質は「変化への適応」のように思う。それを達成するために「小さく・早く作る」という手段が採用される ・で、特に面白いのは後半の「価値探索」の話 ・仮説をに種類に分けて、仮説検証を繰り返すことで「小さく・早く作る」ことを実現しよう、みたいな話
Posted by
近代的なプロダクト開発で使われないようなものを作らないためにはどう実践すべきかの指南書になる。より詳細なプラクティスはスクラムやアジャイルの知識を参照しつつ、マインドセットとして参考にすると良さそう。必要性も含めて文章でしっかり説明されており、プロダクト開発の全てのフェーズで活用...
近代的なプロダクト開発で使われないようなものを作らないためにはどう実践すべきかの指南書になる。より詳細なプラクティスはスクラムやアジャイルの知識を参照しつつ、マインドセットとして参考にすると良さそう。必要性も含めて文章でしっかり説明されており、プロダクト開発の全てのフェーズで活用できるはず。 発売から4年経つので、第2版にも期待。
Posted by
自分の抱えているシステム開発の悩みについて、さまざまなヒントが詰まっていた。システム開発の経典になりそうだ。
Posted by
開発者、PMどちらも読むべき。とても勉強になったし、さっそく一部取り入れはじめた。今のプロダクトの開発前に出会いたかった1冊。
Posted by
仮説を仮説のままに検証する仕組みを持つこと、 わかっていないことをわかっていないままに受け止めることの重要さを感じた
Posted by
- ネタバレ
※このレビューにはネタバレを含みます
読み物的な側面が強いので万人にはオススメできないけど、正しいものを正しくつくるとはどういうことなのか、つまり正しくないものを作らないことが結果的にそれにつながる、ということが新たな発見として感じられたのでよかった。 正しいもの、正しくないものを見つけるために必要な活動をしていこう、と思った。
Posted by
- ネタバレ
※このレビューにはネタバレを含みます
目次 ・アジャイルとは ・なぜアジャイルが生まれた？ ・アジャイルの２つの要素 ・クイックに開発するための開発組織 ・開発組織の２つの壁 ・仮説検証で重要な3つのこと ・多様性と共創 ・アジャイルとは？ 正しいっぽいプロダクトを小さく素早く走りながら作っていくこと ・なぜ生まれた？ ➀課題が複雑で正しいプロダクトがなにかわからなきなってきたから ➁チームの役割も多様になったから ・アジャイル開発の２つの要素 ➀クイックに動く開発組織 ➁仮説検証 ・クイックに開発するための開発組織 クイックに開発するために、 -開発のルール -開発フロー -スプリント(なに作る) -機能ゴール -定期的な開発フロー/組織KPT の設定、実行が必要 ・開発組織の２つの壁 ➀アジャイル形式を実践できない これは実践知になるまでPDCA回すのみ ➁開発側とプロダクトオーナーの言語の壁 これはBiz側がんばろう、あと専門用語ダメ ・仮説検証で大切な3つのこと ➀基準/組織・事業・プロダクトの目的設定/共有 ➁正しくないこと(やらないこと)の設定/共有 ③目的→機能→手段の順番での検証 (コード書く前に声聞いてPDCA回せ) ・多様性と共創 多様なメンバーの力で、多様な視点(上下、左右)から、問いに向き合う。 ユーザーをも巻き込んで、共創していく。
Posted by
不確実性に対処するためには、チームの多様性を最大限生かすような開発を行うことが重要、というのが本書の要旨と思います。システムに必要な要件="正しいもの"を探るにしろ、開発中の仕様変更や課題解決及び無駄の低減="正しく作る"にしろ、チームで共...
不確実性に対処するためには、チームの多様性を最大限生かすような開発を行うことが重要、というのが本書の要旨と思います。システムに必要な要件="正しいもの"を探るにしろ、開発中の仕様変更や課題解決及び無駄の低減="正しく作る"にしろ、チームで共に考え創る体制を作ることが、正解のない問題に対してより良い結果を得る方法なのだと思います。また、アジャイル開発（主にスクラム）において陥りやすい問題や、その対処方法なども紹介されています。 ただ、アジャイル開発に関する説明は、本書だけで十分とは言えないと思います。尤も書中でも述べられている通り、アジャイル開発は理解は容易でも"習得は非常に困難"とされており、書籍で十分に説明するということ自体が難しいので仕方がないところではありますが。全体として書いてある内容は理想として理解できますが、実際の行動に起こすとなると困難は多そうです。とはいえ、アジャイル開発のアンチパターンや本書で初めて知った手法などもあり、読んでみて良かったとは思います。
Posted by