投稿元：
レビューを見る
仮説検証型アジャイル開発の進め方をベースに「正しく作るとはどういうことか？」が書かれている本。
＜特に印象にのこっている点＞
- 不確実性の高い中でのプロダクトづくりには共創によるプロダクトづくり(プロダクト作りの民主化)の開発スタイルが求められる。
- 心理的負荷がかかる時(わからないことが発生した時/境界線の越境時など)の乗り越え方/対処の仕方が書かれている。
- 仮説検証⇒アジャイル開発の流れで開発する上での作業の流れ、ポイントが書かれている。
より詳細なコメントは下記に記載。
https://fatherofikura.hatenablog.com/entry/book/2019_16
投稿元：
レビューを見る
いったい、どれほどのチームが間違ったものを間違って作っているのだろうか。今の世の中の大多数が間違ったものを間違ってつくる、あるいは間違ったものを正しくつくっているのではないか。プロダクトをつくるということを、改めて考えさせられる。プロダクトつくりに関わっている人すべてが意識すべきことが書かれている。
投稿元：
レビューを見る
300ページを超える本書は、特に初めてプロダクトオーナーなど「プロダクトでの視座を求められる」エンジニアに勧めたい。
第一章 なぜプロダクトづくりがうまくいかないのか ではどこの現場でも失敗や混乱が起きていることを伝え
第二章 プロダクトをアジャイルにつくる ではアジャイル開発の基本について解説され
第三章 不確実性への適応 では「暗黙的な期待」「成り立たないトレードオフ」といったアジャイルを導入してもなお立ち上がってくる不確実性と向き合い、ひとまず「正しくつくる」方法を身につける。
第四章 アジャイル開発は2度失敗する では文字通り、2つの壁が提示され「正しくつくる」だけでは不十分であることが示され
第五章 仮説検証型アジャイル開発 では「正しいもの」を探索する方法を知り
第六章 ともにつくる で「目的に忠誠を誓う。しかし心中はしない、問いを持ち続け共創する」という価値観が掲げられ、またそのためには「正しいものを正しくつくれているか」という問いの重要性が説かれる。
上上下下左右左右過去未来、視座と視野を動かし
正しいものを探し
正しくつくる
300ページを超える重厚な本書を読めばたちどころにプロダクトがよくなるわけではないが、本書の内容を咀嚼し、実践し、失敗し、カイゼンし、血肉としていくことで「正しいものを正しくつくる」力がついていくのではないだろうか。
2019年、エンジニアにとって令和最初の必読書である。
投稿元：
レビューを見る
アジャイルに取り組んでいるため、まさに知りたかった内容だった。きちんと理解するために、少しずつ実践しながら何度か読み直しが必要だなぁと思ってる。
投稿元：
レビューを見る
デザイナーの立場で、スクラムについてモヤモヤしていたところが、結構解消されたので良かった。
デザイナーって、スクラムの中でどういう位置づけなの？とか、POとの責任範囲のすみわけとか。
投稿元：
レビューを見る
著者の苦労して築き上げてきたであろう知見が分かりやすくまとめてあって、たくさんの気づきが得られた。
何度か読み返してまず私は守破離の守のフェーズとして参考にしていきたい。
ソフトウエア開発愛も感じられるいい本だった。
投稿元：
レビューを見る
昨日の「プロダクトをつくるとはどういうことなのか？ -正しいものを正しくつくる-」に参加して、言われてみたらまだ本を買って読んでいなかったこともあり帰りに購入。
著者の体験を書籍にまとめたとのことですが、特に衝撃だったのは「アジャイル開発は二度失敗する」という章。早く少しだけ形にすることで新たにわかってきたこと(特に不安的要素)を現実的にどう受け止められるかという第1の壁、そして、プロダクトオーナーと開発チーム間の境界線という第2の壁がアジャイル開発に存在するということを痛切に思い知りました。私自身はアジャイル開発の経験がほぼないに等しいのですが、実際に取り組むときはこの2つの壁を意識しつつ、仮説検証をして回せるようにしたいものです。特にアジャイル開発をして上手くいかないと感じる方には一読すると良いかも知れません。
投稿元：
レビューを見る
アジャイルに作るとは、作ることを通じて学びを得る活動
現在の私たちが手がけるプロダクトづくりは、誰かの頭の中に正解のイメージがあってそれをうまく取り出してコードにしていくという開発ではない
どうあるべきか本当のところ誰にもわからないが、なんとかして形に仕立てていく
顧客やユーザーという言葉は便利だが、代名詞でしかなく、その中身は多様だ
早く少しだけ形にする
アジャイルは開発手法の共通性を表現するための言葉
暗黙的な期待を放置したままでは合意形成にならない
自分自身の期待に当事者が気づいていない場合もある
広さでコミットし、深さを調整する
アイスボックス＝開発対象から外しておくための受け皿
仮説検証で正解を見つけにいこうとするのではなく、自分たちが捉えられていないことを見つけるつもりでいく。
ネガティブな反応は、それに対処し、条件を変えることで結果が変わるのか確かめるうごきをとれる
課題仮説
機能仮説
インターフェース仮説
正しいものを正しく作る、とは「わかったことを正しく作る」ということ
多様性は不確実性を高めるが、その不確実性に適応する術もまた多様性。
役割を中心とした調整によるプロダクトづくりから、問いと向き合い続ける共創によるプロダクトづくり
投稿元：
レビューを見る
0→1段階のプロダクト開発における企画、仮設検証、チームビルディングの方法論や考え方がじっくりと書かれている書籍だと感じました。
投稿元：
レビューを見る
去年まではスクラムで開発を行っていたけれど、ずいぶん忘れている。そうだった。チームによってどのくらいできるかは違うから、開発を進めながらベロシティを測ってだんだんどのくらい進められるかが分かってくるのだった。残念ながら客先常駐だとそういった方法でやるのは難しいのかも。なぜか残業前提で働いていたり、残業をたくさんした方が偉いみたいな風潮の現場が多い。それじゃベロシティ測れないのでは？
投稿元：
レビューを見る
正しいものを正しくつくることへの挑戦は未来永劫続く。
そして、「正しくつくれる」一部の「できる」エンジニア、マネージャーが暗黙的に持っている知見を見事に言語化した良書である。
スクラム開発についても言及しているが、あくまで本書を完結させるために記載したものである。スクラム開発を深く理解するためには、一度同著者が書いた「カイゼンジャーニー」を一読することをお勧めする。（カイゼンジャーニーを読んだ後、本書を読むと良いかもしれない）
私見だが、「できる」エンジニア、マネージャーに最も必要な要素は視座と視野だと考えている。それを上上下下左右左右過去未来とはよくもまあ良い表現を思いついたものだと感心した。
とはいえ、視座と視野を広げる「教育」が必要だと思うが、いっそメンバーを巻き込んだコンサル的な教育も取り入れられれば良いのかな、と考えている。
個人的には近年SoRの案件が多いため、不確実性に挑戦することは少ないが、SoEの案件に携わる際には参考にしていきたい。
しかし、カイゼンジャーニー含め、なにかの節目で必ず開く本になりそうだ。
投稿元：
レビューを見る
書店で数回目についたので購入
アジャイルに作る、という言葉だけが先行している企業もある中
実体験に基づいて書かれた本
2度失敗する、と書かれてあったり、定性的に言えるのか不明な部分もあったが
何より体験に基づいて言語化されている部分が多く有用な本と言える
結局読者も実体験と比較しながら読む類の本かと思う
投稿元：
レビューを見る
正しいものを見つけ出す「価値探索」と正しくつくるための「アジャイル開発」について、著者の実践経験に基づく知見がまとめられた1冊。著者の市谷聡啓さんは『カイゼン・ジャーニー』の著者でもあり、日頃からリアルなプロダクトづくりを伝えてくださるので、とても興味を持っていました。また自分が普段、デザインスプリントという「価値探索」手法とアジャイル開発で仕事をしているので、より引き出すを増やせるのではないかと期待して読み始めました。
本書で特に参考になったのは、「スクラム開発でいうプロダクトバックログを用意するために、やっておくべきこと」「プロダクトオーナーとはどうあるべきか、その役割と観点」の2点でした。
著者が唱える『仮説検証型アジャイル開発』は、いきなりアジャイル開発を始めるのではなく、もっと他の手段で『探索』を進めて、「ユーザーに体験してもらわないとこれ以上の検証はできない」と判断したときに、初めて開発を行うほうがいい、と読み取りました。言い換えると「アジャイル開発のスタート地点に立つまでにやるべきことがたくさんある。」だと思います。
これまでのアジャイル開発やスクラム開発の書籍は、いきなりプロダクトバックログを用意して、開発を始める、そのためのプラクティスの観点が強いものが多いなと感じていました。どうやってプロダクトバックログを用意するのか、プロダクトバックログの正しさ/妥当性はどうやって評価するのかが抜けているのです。自分もデザインスプリントという手法を取り入れ、妥当性のあるプロダクトバックログを用意するようにしているため、本書のノウハウはとても参考になるところが多かったです。
プロダクトオーナーには求められる観点が3つあり、
・「要求は何か」→「要求(プロダクトバックログ)の言語化、整理」
・「インターフェースはどうあるべきか」→「UIの方針決め」
・「ビジネスモデルはどうあるべきか」→「ビジネスモデルの設計」
プロダクトづくりのBusiness, Technology, Design領域で言うところの、BusinessとDesignの要素が強いことを感じました。もちろんTechnologyの観点も蔑ろにするわけではないが、開発チームを頼ることができるので、割合は低いのだと思います。またプロダクトオーナーに求められる観点・役割が幅広いため、適切な権限移譲によって負担の軽減を狙うのもよいとのこと。
不確実性のあるプロダクトづくりでは、教科書的な成功法はないため、本書のようなベストプラクティスや、そこから予想される原理原則を知り、自分の中に選択肢を増やすことが大事であることを再認識しました。
投稿元：
レビューを見る
読めば読むほど違和感が募る。とりあえず導入してみたけどうまくいかなかった感が強い、ベストプラクティス症候群とでもいうべきか。自社の開発プロセスの問題を明確にすることなくプラクティスを入れるだけなのではないか？
プロダクト開発に明確な答えはない。「正しいものを正しくつくる」というタイトルは誤解を招く、私なら「不確実な時代のプロダクト開発」くらいに思う。
何のために、何を、どのようにつくるのか、本書では「何を」と「どのように」について言及している。
多くの開発者に共通する悩みなのか、それとも筆者特有なのかいまいちわからないところが多い。
例えば、
「何をつくるべきかの構想を練ってきたが、その内容には根拠がなかった」とあるが、プロセスを正しく踏んでいないだけではないか。
「チームの多様性がプロダクト開発を不確実にする」とあるが、最低限のルールと開発に必要なロールを集めていれば問題にならないのではないか。
なぜアジャイルであるべきなのか（MECEにしたい）
・フィードバックに基づく調整で目的に適したプロダクトに仕立てられる
・形にすることで早めに関係者の認識を揃えられる
・つくるものやチームについての問題に早く気づける
・チームの学習効果が高い
・早く作り始められる
・結合のリスクを早めに倒せる
・Time to Marketが短い
・サンクコストを小さくできる
・開発チームのリズムを整えられる
ーぼやきー
・不確実性という言葉に踊らされている。何が不確実なのかを明確にすべき。要求なのか要件なのか見積もりなのか。
答えを出したいトピック
・なぜアジャイルであるべきなのか。
・なぜ内製化すべきなのか。
投稿元：
レビューを見る
仮説検証への取り組み方
そのためのアジャイル開発
考え方
視座など
リーンスタートアップよりもより実践的な気がする
