【感想・ネタバレ】正しいものを正しくつくる－プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先についてのレビュー

市谷聡啓

[ブクログ · ★★★★★]

近代的なプロダクト開発で使われないようなものを作らないためにはどう実践すべきかの指南書になる。より詳細なプラクティスはスクラムやアジャイルの知識を参照しつつ、マインドセットとして参考にすると良さそう。必要性も含めて文章でしっかり説明されており、プロダクト開発の全てのフェーズで活用できるはず。
発売から4年経つので、第2版にも期待。

[ブクログ · ★★★★★]

目次
・アジャイルとは
・なぜアジャイルが生まれた？
・アジャイルの２つの要素
・クイックに開発するための開発組織
・開発組織の２つの壁
・仮説検証で重要な3つのこと
・多様性と共創

・アジャイルとは？
正しいっぽいプロダクトを小さく素早く走りながら作っていくこと

・なぜ生まれた？
➀課題が複雑で正しいプロダクトがなにかわからなきなってきたから
➁チームの役割も多様になったから

・アジャイル開発の２つの要素
➀クイックに動く開発組織
➁仮説検証

・クイックに開発するための開発組織
クイックに開発するために、
-開発のルール
-開発フロー
-スプリント(なに作る)
-機能ゴール
-定期的な開発フロー/組織KPT
の設定、実行が必要

・開発組織の２つの壁
➀アジャイル形式を実践できない
これは実践知になるまでPDCA回すのみ

➁開発側とプロダクトオーナーの言語の壁
これはBiz側がんばろう、あと専門用語ダメ

・仮説検証で大切な3つのこと
➀基準/組織・事業・プロダクトの目的設定/共有
➁正しくないこと(やらないこと)の設定/共有
③目的→機能→手段の順番での検証
(コード書く前に声聞いてPDCA回せ)

・多様性と共創
多様なメンバーの力で、多様な視点(上下、左右)から、問いに向き合う。

ユーザーをも巻き込んで、共創していく。

[ブクログ · ★★★★★]

正しいものには行きつかずとも、わかったものを正しく作る。分かるに行きつくことに、もっと向き合わねばと思った。

[ブクログ · ★★★★★]

‪なぜプロダクト作りやソフトウェア開発はいつまで経っても上手くいかないのか？この永遠の課題に立ち向かう武器となるアジャイル開発の解説本。体系的理論よりも実践と失敗をベースにした構成になっており、自分が何に陥っているのかカウンセリングされているかのごとく見えてくる（ただし本書でも繰り返し言及されている「習得は非常に困難」には留意すべし）個人的には不確実性との向き合い方が書かれた第3章、特に「学びから生まれる課題」の話は目から鱗。開発が進み次にやることの洗い出しの精度が上がるのに比例してスケジュールが混沌としてくる違和感の正体はこれだったのか。今後も末永くお世話になる一冊になりそう。‬

[ブクログ · ★★★★★]

# 読む前
アジャイル開発ができていれば価値あるプロダクトを作れるかというと、必ずしもそうではないということをまた改めて実感していた最近、まさになテーマの本だったので手にとった。

# 内容
プロダクトそのものの多様性と技術や作り手の多様化がプロダクト作りの不確実性を高めている。不確実性の中でいかに正解に近づけて行くか。その手法として早く少しだけ形にするアジャイル開発がある。

が、アジャイル開発をし、学びをすることでやることが増え、やることが変わり、よりプロダクト作りの不確実さが上がる。この不確実性に対処するためにやること
・共通理解（ミッション、目的）
・余白の調整（広さでコミット、深さで調整）、期間の余白、受け入れの余白
・成功循環、受入基準と受入テスト、ベロシティ計測とふりかえり

正しくつくっても間違ったものを作っていてはダメ
- 間違ったものを作ってしまう要因：開発チームとプロダクトオーナーの間の境界
作る人と作らない人/アウトプットとアウトカム
-> 「プロダクトとして何が正しいのか」の基準（あくまで見立て。
常に見直される。）にもとづいて越境

仮説検証とは分からないものを減らし、分かったことを増やしていく活動、
チームとしての何が正しいかの見立てを共通理解とする活動
- 正しくないことの学びを重ね、除外していくことで正しい（と思われる）もの
の範囲を狭めていくアプローチ
- 目的、実態、手段の順に段階的に絞っていく
- ユーザーに体験してもらわないとこれ以上の検証はできない、この検証のために
ソフトウェアを作る必要がある、という判断に達し多段階で初めてMVPの開発に
着手する
- MVP開発までの価値探索はモデル化（分かってることの図式化・言語化）と
検証の繰り返し

# 所感
アジャイル開発の理論は理解し、いざ実践してみるとぷつかる壁がいくつもある、そんな上手くいくもんじゃない。経験ある人ならほんとそれ、と思うことが冒頭イントロダクションの著者の経験、またそれ以降でも語られていた。そんな経験からくる「正しいものを正しく作れているか？」という問いかけは実践者にとても刺さる。

作る前の価値探索は間違ったものを作らないためにもとても大事。作ることはコストがかかる、作る前に検証できることはしてチーム共通理解の基準を持ってMVPを作る。

ただ、やっぱり絶対の正しさがないものを探索することは簡単ではないと思った。何を信じて分かった/分からないとするのか、何を検証していくのかはその時その時の判断をチームでしていくしかないんだろうなぁ。ただ、分からないことを分かったつもりになって進むのはやめよう。問い続けよう。

[ブクログ · ★★★★★]

著者の経験に基づいてプロダクト開発が上手くいかない理由を整理している感じです。
決して書いてある通りにやれば成功する、という話ではありません。
自分の言葉で論理を積み上げられており、筋が通ってる印象でした。

第3章で解説されている余白の話はなるほどそういう捉え方ができるんだ、と感心しました。

How に向きがちな意識を What や Why に向けること、そのためのスキルを身につけることが必要になってきているのだと納得しました。

ソフトウェア開発の方法論は海外からの輸入が多い中、日本語で思考し、綴られた優れた内容だと思います。

[ブクログ · ★★★★★]

正しいものを正しくつくることへの挑戦は未来永劫続く。

そして、「正しくつくれる」一部の「できる」エンジニア、マネージャーが暗黙的に持っている知見を見事に言語化した良書である。

スクラム開発についても言及しているが、あくまで本書を完結させるために記載したものである。スクラム開発を深く理解するためには、一度同著者が書いた「カイゼンジャーニー」を一読することをお勧めする。（カイゼンジャーニーを読んだ後、本書を読むと良いかもしれない）

私見だが、「できる」エンジニア、マネージャーに最も必要な要素は視座と視野だと考えている。それを上上下下左右左右過去未来とはよくもまあ良い表現を思いついたものだと感心した。

とはいえ、視座と視野を広げる「教育」が必要だと思うが、いっそメンバーを巻き込んだコンサル的な教育も取り入れられれば良いのかな、と考えている。

個人的には近年SoRの案件が多いため、不確実性に挑戦することは少ないが、SoEの案件に携わる際には参考にしていきたい。

しかし、カイゼンジャーニー含め、なにかの節目で必ず開く本になりそうだ。

[ブクログ · ★★★★★]

アジャイルに作るとは、作ることを通じて学びを得る活動

現在の私たちが手がけるプロダクトづくりは、誰かの頭の中に正解のイメージがあってそれをうまく取り出してコードにしていくという開発ではない

どうあるべきか本当のところ誰にもわからないが、なんとかして形に仕立てていく

顧客やユーザーという言葉は便利だが、代名詞でしかなく、その中身は多様だ

早く少しだけ形にする

アジャイルは開発手法の共通性を表現するための言葉

暗黙的な期待を放置したままでは合意形成にならない
自分自身の期待に当事者が気づいていない場合もある

広さでコミットし、深さを調整する

アイスボックス＝開発対象から外しておくための受け皿

仮説検証で正解を見つけにいこうとするのではなく、自分たちが捉えられていないことを見つけるつもりでいく。

ネガティブな反応は、それに対処し、条件を変えることで結果が変わるのか確かめるうごきをとれる

課題仮説
機能仮説
インターフェース仮説

正しいものを正しく作る、とは「わかったことを正しく作る」ということ

多様性は不確実性を高めるが、その不確実性に適応する術もまた多様性。

役割を中心とした調整によるプロダクトづくりから、問いと向き合い続ける共創によるプロダクトづくり

[ブクログ · ★★★★★]

昨日の「プロダクトをつくるとはどういうことなのか？ -正しいものを正しくつくる-」に参加して、言われてみたらまだ本を買って読んでいなかったこともあり帰りに購入。
著者の体験を書籍にまとめたとのことですが、特に衝撃だったのは「アジャイル開発は二度失敗する」という章。早く少しだけ形にすることで新たにわかってきたこと(特に不安的要素)を現実的にどう受け止められるかという第1の壁、そして、プロダクトオーナーと開発チーム間の境界線という第2の壁がアジャイル開発に存在するということを痛切に思い知りました。私自身はアジャイル開発の経験がほぼないに等しいのですが、実際に取り組むときはこの2つの壁を意識しつつ、仮説検証をして回せるようにしたいものです。特にアジャイル開発をして上手くいかないと感じる方には一読すると良いかも知れません。

[ブクログ · ★★★★★]

300ページを超える本書は、特に初めてプロダクトオーナーなど「プロダクトでの視座を求められる」エンジニアに勧めたい。

第一章 なぜプロダクトづくりがうまくいかないのか ではどこの現場でも失敗や混乱が起きていることを伝え
第二章 プロダクトをアジャイルにつくる ではアジャイル開発の基本について解説され
第三章 不確実性への適応 では「暗黙的な期待」「成り立たないトレードオフ」といったアジャイルを導入してもなお立ち上がってくる不確実性と向き合い、ひとまず「正しくつくる」方法を身につける。
第四章 アジャイル開発は2度失敗する では文字通り、2つの壁が提示され「正しくつくる」だけでは不十分であることが示され
第五章 仮説検証型アジャイル開発 では「正しいもの」を探索する方法を知り
第六章 ともにつくる で「目的に忠誠を誓う。しかし心中はしない、問いを持ち続け共創する」という価値観が掲げられ、またそのためには「正しいものを正しくつくれているか」という問いの重要性が説かれる。

上上下下左右左右過去未来、視座と視野を動かし
正しいものを探し
正しくつくる

300ページを超える重厚な本書を読めばたちどころにプロダクトがよくなるわけではないが、本書の内容を咀嚼し、実践し、失敗し、カイゼンし、血肉としていくことで「正しいものを正しくつくる」力がついていくのではないだろうか。
2019年、エンジニアにとって令和最初の必読書である。

[ブクログ · ★★★★☆]

アジャイルの実践が必要になり、メソッドとしての知識ではなく原則を知りたくて読みました。仮説検証型アジャイル開発というプロセスを提唱していますが、それが標準的なアジャイルと何が違うのかは(知識不足で)わかりませんでした。陥りそうなアンチパターンなどがわこりやすく、現在進行形で参考にしたい考え方ばかりでした。間違ったものを正しく作ることを避けること、そのために視座を意識的に行き来することが必要と感じました。

[ブクログ · ★★★★☆]

自分の抱えているシステム開発の悩みについて、さまざまなヒントが詰まっていた。システム開発の経典になりそうだ。

[ブクログ · ★★★★☆]

開発者、PMどちらも読むべき。とても勉強になったし、さっそく一部取り入れはじめた。今のプロダクトの開発前に出会いたかった1冊。

[ブクログ · ★★★★☆]

仮説を仮説のままに検証する仕組みを持つこと、
わかっていないことをわかっていないままに受け止めることの重要さを感じた

[ブクログ · ★★★★☆]

読み物的な側面が強いので万人にはオススメできないけど、正しいものを正しくつくるとはどういうことなのか、つまり正しくないものを作らないことが結果的にそれにつながる、ということが新たな発見として感じられたのでよかった。
正しいもの、正しくないものを見つけるために必要な活動をしていこう、と思った。

[ブクログ · ★★★★☆]

近年、ちまたにあふれているデザイン思考本より、よっぽど分かりやすい。アジャイル解説本であるが、より良いモノをつくりたい。という思い、考え方は、デザイン思考とベクトルは同じ。必要なマインドも同じ。というのが、よくわかる。

[ブクログ · ★★★★☆]

0→1段階のプロダクト開発における企画、仮設検証、チームビルディングの方法論や考え方がじっくりと書かれている書籍だと感じました。

[ブクログ · ★★★★☆]

正しいものを見つけ出す「価値探索」と正しくつくるための「アジャイル開発」について、著者の実践経験に基づく知見がまとめられた1冊。著者の市谷聡啓さんは『カイゼン・ジャーニー』の著者でもあり、日頃からリアルなプロダクトづくりを伝えてくださるので、とても興味を持っていました。また自分が普段、デザインスプリントという「価値探索」手法とアジャイル開発で仕事をしているので、より引き出すを増やせるのではないかと期待して読み始めました。

本書で特に参考になったのは、「スクラム開発でいうプロダクトバックログを用意するために、やっておくべきこと」「プロダクトオーナーとはどうあるべきか、その役割と観点」の2点でした。

著者が唱える『仮説検証型アジャイル開発』は、いきなりアジャイル開発を始めるのではなく、もっと他の手段で『探索』を進めて、「ユーザーに体験してもらわないとこれ以上の検証はできない」と判断したときに、初めて開発を行うほうがいい、と読み取りました。言い換えると「アジャイル開発のスタート地点に立つまでにやるべきことがたくさんある。」だと思います。

これまでのアジャイル開発やスクラム開発の書籍は、いきなりプロダクトバックログを用意して、開発を始める、そのためのプラクティスの観点が強いものが多いなと感じていました。どうやってプロダクトバックログを用意するのか、プロダクトバックログの正しさ/妥当性はどうやって評価するのかが抜けているのです。自分もデザインスプリントという手法を取り入れ、妥当性のあるプロダクトバックログを用意するようにしているため、本書のノウハウはとても参考になるところが多かったです。

プロダクトオーナーには求められる観点が3つあり、
・「要求は何か」→「要求(プロダクトバックログ)の言語化、整理」
・「インターフェースはどうあるべきか」→「UIの方針決め」
・「ビジネスモデルはどうあるべきか」→「ビジネスモデルの設計」
プロダクトづくりのBusiness, Technology, Design領域で言うところの、BusinessとDesignの要素が強いことを感じました。もちろんTechnologyの観点も蔑ろにするわけではないが、開発チームを頼ることができるので、割合は低いのだと思います。またプロダクトオーナーに求められる観点・役割が幅広いため、適切な権限移譲によって負担の軽減を狙うのもよいとのこと。

不確実性のあるプロダクトづくりでは、教科書的な成功法はないため、本書のようなベストプラクティスや、そこから予想される原理原則を知り、自分の中に選択肢を増やすことが大事であることを再認識しました。

[ブクログ · ★★★★☆]

著者の苦労して築き上げてきたであろう知見が分かりやすくまとめてあって、たくさんの気づきが得られた。

何度か読み返してまず私は守破離の守のフェーズとして参考にしていきたい。

ソフトウエア開発愛も感じられるいい本だった。

[ブクログ · ★★★★☆]

いったい、どれほどのチームが間違ったものを間違って作っているのだろうか。今の世の中の大多数が間違ったものを間違ってつくる、あるいは間違ったものを正しくつくっているのではないか。プロダクトをつくるということを、改めて考えさせられる。プロダクトつくりに関わっている人すべてが意識すべきことが書かれている。

[ブクログ · ★★★★☆]

アジャイルに取り組んでいるため、まさに知りたかった内容だった。きちんと理解するために、少しずつ実践しながら何度か読み直しが必要だなぁと思ってる。

[ブクログ · ★★★★☆]

デザイナーの立場で、スクラムについてモヤモヤしていたところが、結構解消されたので良かった。
デザイナーって、スクラムの中でどういう位置づけなの？とか、POとの責任範囲のすみわけとか。

[ブクログ · ★★★☆☆]

いわゆるアジャイル開発の進め方をスクラムをモデルとして具体的に解説。チームビルディングからチームにおける役割、日々のスプリントの回し方、マインドなどが解説される。
私は本書が想定する読者ではなかったため、あまり刺さらなかったけれど、アジャイル・スクラムを具体的に導入したい方には実践的ガイドとなっているだろう。
とはいえ、守破離に言及する文脈で、あえて不確実性を残すことも必要という観点は面白かった。新規プロダクト開発はややもするとみんなが想像できる安定感のあるプロダクトに落としてしまいがちだけれど、それをあえて揺さぶるために不確実性を残す、取り込むという観点は忘れてはならないだろう。何のために新規事業開発をつくろうとしているかはスプリントを回している内に見失いかねないけれど、それを思い出させてもらえるからだ。

[ブクログ · ★★★☆☆]

具体的なHowについては、実践しながらインプットするとして、一旦概念的なもののメモを残しておく。

◾️第二章: スクラム開発
4つの価値
・対話を重んじる
・早く動くものを作る
・顧客との協調
・計画よりも変化への対応

原則
・早く、継続的に
・変化を味方につける
・振り返り改善する

チーム
・PO）プロダクトの価値の最大化
・開発チーム）製造・完成
・SM）スクラムプロセスの実施中

スクラムイベント
・プランニング
・デイリースクラム
・レビュー
・レトロスペクティブ

成果物
・プロダクトバックログ
・スプリントバックログ
・インクリメント

9つの意義 ≒ 目的
・早く認識を揃える
・早く問題に気づく
・繰り返して学習する
・早く市場に出す

■第五章: 価値探索
基本スタンス
・モデル化とその検証の繰り返し
　モデル化）分かっていることの言語化・図式化

仮説の種類
・課題仮説
・ソリューション仮説

検証結果のジャッジ観点
・Problem-Solution-Fit
・Product-Market-Fit

具体的な方法
・叩き作成（仮説キャンバス）
・課題設定の正しさの検証
　ユーザーインタビュー
・課題に対する解決策の正しさの検証
　プロトタイピング
・参考）その他の手法
　アンケート）課題仮説、ユーザーが見えないとき

---

感想
・環境変化が激しい時代なので、ウォーターフォール型の開発プロセスが時代にフィットしないっていうのはこれまで何度も言われてきていること
・そういう状況に対してアジャイル開発という手法で立ち向かおうとするってのもよく聞く
・その整理でいくと、本質は「変化への適応」のように思う。それを達成するために「小さく・早く作る」という手段が採用される
・で、特に面白いのは後半の「価値探索」の話
・仮説をに種類に分けて、仮説検証を繰り返すことで「小さく・早く作る」ことを実現しよう、みたいな話

[ブクログ · ★★★☆☆]

不確実性に対処するためには、チームの多様性を最大限生かすような開発を行うことが重要、というのが本書の要旨と思います。システムに必要な要件="正しいもの"を探るにしろ、開発中の仕様変更や課題解決及び無駄の低減="正しく作る"にしろ、チームで共に考え創る体制を作ることが、正解のない問題に対してより良い結果を得る方法なのだと思います。また、アジャイル開発（主にスクラム）において陥りやすい問題や、その対処方法なども紹介されています。

ただ、アジャイル開発に関する説明は、本書だけで十分とは言えないと思います。尤も書中でも述べられている通り、アジャイル開発は理解は容易でも"習得は非常に困難"とされており、書籍で十分に説明するということ自体が難しいので仕方がないところではありますが。全体として書いてある内容は理想として理解できますが、実際の行動に起こすとなると困難は多そうです。とはいえ、アジャイル開発のアンチパターンや本書で初めて知った手法などもあり、読んでみて良かったとは思います。

[ブクログ · ★★★☆☆]

書店で数回目についたので購入
アジャイルに作る、という言葉だけが先行している企業もある中
実体験に基づいて書かれた本
2度失敗する、と書かれてあったり、定性的に言えるのか不明な部分もあったが
何より体験に基づいて言語化されている部分が多く有用な本と言える
結局読者も実体験と比較しながら読む類の本かと思う

[ブクログ · ★★★☆☆]

去年まではスクラムで開発を行っていたけれど、ずいぶん忘れている。そうだった。チームによってどのくらいできるかは違うから、開発を進めながらベロシティを測ってだんだんどのくらい進められるかが分かってくるのだった。残念ながら客先常駐だとそういった方法でやるのは難しいのかも。なぜか残業前提で働いていたり、残業をたくさんした方が偉いみたいな風潮の現場が多い。それじゃベロシティ測れないのでは？