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

市谷聡啓(著者)

2021/04/13

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

2020/12/28

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

2020/05/04

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

2020/04/25

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

2020/03/10

守破離の守の本であり、離の本であるとのこと
Inspired で語られた PdM の役割をさらに踏み込んでどうやって作っていくか、という実践の本。になるのかな
あくまで一つの実践法、という立ち位置が気持ちよくて、同時に通底する本質的なプロダクト作りに大切な言葉が散りばめられている

「ここまでくると、プロダクトオーナーは本当に何もかも備えなければならないのかと途方に暮れるかもしれない。ただ、プロダクトに責任を持つということは、そのために必要なことであればどうにかして担保しなければならないということなのだ」

2020/03/17

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

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

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

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

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

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

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

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

2020/08/02

howに寄り過ぎていて、経験豊富な人でないと読み越せないだろう。そしてhowに寄り過ぎているからひたすらに長い。

2020/02/06

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

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

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

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

2020/01/28

仮説検証への取り組み方
そのためのアジャイル開発
考え方
視座など
リーンスタートアップよりもより実践的な気がする

2019/12/15

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

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

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

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

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

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