正しいものを正しくつくる の商品レビュー

市谷聡啓(著者)

2019/10/22

読めば読むほど違和感が募る。とりあえず導入してみたけどうまくいかなかった感が強い、ベストプラクティス症候群とでもいうべきか。自社の開発プロセスの問題を明確にすることなくプラクティスを入れるだけなのではないか？

プロダクト開発に明確な答えはない。「正しいものを正しくつくる」というタイトルは誤解を招く、私なら「不確実な時代のプロダクト開発」くらいに思う。

何のために、何を、どのようにつくるのか、本書では「何を」と「どのように」について言及している。

多くの開発者に共通する悩みなのか、それとも筆者特有なのかいまいちわからないところが多い。
例えば、
「何をつくるべきかの構想を練ってきたが、その内容には根拠がなかった」とあるが、プロセスを正しく踏んでいないだけではないか。
「チームの多様性がプロダクト開発を不確実にする」とあるが、最低限のルールと開発に必要なロールを集めていれば問題にならないのではないか。

なぜアジャイルであるべきなのか（MECEにしたい）
・フィードバックに基づく調整で目的に適したプロダクトに仕立てられる
・形にすることで早めに関係者の認識を揃えられる
・つくるものやチームについての問題に早く気づける
・チームの学習効果が高い
・早く作り始められる
・結合のリスクを早めに倒せる
・Time to Marketが短い
・サンクコストを小さくできる
・開発チームのリズムを整えられる

ーぼやきー
・不確実性という言葉に踊らされている。何が不確実なのかを明確にすべき。要求なのか要件なのか見積もりなのか。
答えを出したいトピック
・なぜアジャイルであるべきなのか。
・なぜ内製化すべきなのか。

2019/09/21

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

2019/09/19

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

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

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

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

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

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

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

2019/09/06

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

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

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

2019/08/14

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

2019/08/01

仮説検証型アジャイル開発の進め方をベースに「正しく作るとはどういうことか？」が書かれている本。

＜特に印象にのこっている点＞
- 不確実性の高い中でのプロダクトづくりには共創によるプロダクトづくり(プロダクト作りの民主化)の開発スタイルが求められる。
- 心理的負荷がかかる時(わからないことが発生した時/境界線の越境時など)の乗り越え方/対処の仕方が書かれている。
- 仮説検証⇒アジャイル開発の流れで開発する上での作業の流れ、ポイントが書かれている。

より詳細なコメントは下記に記載。

https://fatherofikura.hatenablog.com/entry/book/2019_16

2019/07/14

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

2019/07/14

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

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

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

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

早く少しだけ形にする

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

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

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

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

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

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

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

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

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

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

2019/07/02

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

2019/06/28

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