正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について（以下、「正しいものを正しくつくる」）を読んだので、特に大事だと思ったことや所感などをまとめます。
目次
「正しいものを正しくつくる」の概要
正しいものを正しくつくるはこれからのソフトウェア開発やデジタルプロダクトづくりに対してエンジニア、デザイナーなどの作り手と、そのソフトウェアやプロダクトを必要としている人（クライアント）がどう臨むかについて説明している書籍です。
| 著者 | 市谷 聡啓 |
| 発売日 | 2019/6/14 |
| ページ数 | 328ページ |
著者の市谷 聡啓さんは他にも「カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで」や「組織を芯からアジャイルにする」などを執筆されています。
本書（正しいものを正しくつくる）はこのような方は読んでみることをおすすめします。
この本がおすすめな人
- ソフトウェア開発、デジタルプロダクトづくりに関わる人
- アジャイル開発を始めたい人、導入している人
大事だと思ったこと
なぜプロダクト開発に苦戦し続けるのか
- 現在のプロダクト開発は誰かの頭の中に正解イメージがあってそれをうまく取り出してコードにしていくという開発ではなく、「どうあるべきか本当のところ誰にもわからないが、なんとかして形に仕立てていく」という開発であるから
- プロダクトづくりには銀の弾丸はない
- 確実なやり方などはなく、プロダクトづくりは不確実性の高い状況下で進めていくのが常
- 「仮説を立てる→検証する→その結果から学びを得て、次の仮説を立てる」この繰り返しによって、立案する仮説の正確度を高めていくアプローチを、不確実性の高いプロダクトづくりではとっていくべき
プロダクト開発で大切な考え方・アクション
- プロダクトは誰かに利用されて初めて価値が生まれる（価値はプロダクトに埋まっているわけでない）
- 使われなかったら存在意義はない
- 不確実性が高く誰にも正解がわからない世界では、自分たちがやっていること、向かっている方向が、誤っていないか問い続けるしかない
- フィードバックを早期に受けていくのは、プロダクトづくりの基準を「ユーザーにとって必要なこと」にするため
- プロダクトの中身を決めていくのは、リーダーやプロダクトオーナーだけではなくプロダクトに関わる全員で決めたほうが良い
- お互いがどんな仕事の進め方をすればより可能性が広がるのかを想像し、チームで言語化するのが効果的
アジャイル開発
- アジャイルに作るとは作ることを通じて学びを得る活動である
- アジャイル開発のメリットはユーザーにプロダクトを「価値があるモノなのか」「必要な機能は何なのか」「どういう形であれば使えるのか」を試してもらいながら開発を進めることができること
- 「アジャイル」は共通性を表現するための言葉であり、解釈は人によって異なる場合が多い（実態はXPかもスクラムかもしれない）
- プロダクトづくりを行うための詳細なやり方についてはそれぞれで違っていて同意のしようがなく、むしろ同意できなことを同意する「不同意の同意」という考え方がある
- 詳細なやり方まで同意しようとすると、やり方を統一しようという動きになり、それがかえって新しいプラクティス（習慣）の発見を阻むことになってしまう
- アジャイル開発に取り組むことが決まっている場合は「なぜ、アジャイルに作るのか」という問いにはチーム全員が答えられるべき
- 自分たちのとっている行動が正しい方向に向いているのかわからなくなってしまう
- 意外と「アジャイルで開発している理由や目的」を誰一人わかっていないことも十分にあるため、その問いに答えることに今更感があったとしても関係者と認識を共通させておくべき
- 本来問うべきは「自分たちのプロダクトづくりとしてありたい姿はどのようなものか？」
- 組織としてアジャイル開発に取り組むか関係なくこの問いに対する答えをチームで言語化しておくべきでチームの根本的な行動基準となる
- 「自分たちのプロダクトづくりとしてありたい姿はどのようなものか？」が曖昧なままHowに「アジャイルに作る」とかwhatに「スクラムの適用」などをあげても、自分たちの行動がありたい方向にどれだけ進んでいるか判断することはできない
- 仮説検証型アジャイル開発の根底には「正しいものを正しくつくる」という理想がある
- 「正しいものを正しく作る」という問いへの向き合い方は「わかったことを正しく作る」に読み替えるところから始まる
- 逆に「わからないもの（正しくないもの）は作らない」ことも大切
- 正しくないと判断できる情報を蓄積しつつ、その反面から確からしいと考えられる仮説を立てる
スクラム
- スクラムガイドには「軽量、理解が容易、習得は非常に困難」という表現で説明されている
- 経験主義にもとづくプロセスのフレームワーク
- やってみてわかったことから、次にやるべきことや試すべきことを自分たちの活動に組み込んでいく考え方が後押しされる（スクラムをフレームワークと定義している所以）
- 「外部からただ取ってきた知識を適用してもうまくはいかない」「実践に支えられた知識を頼りとする」のがスクラムの考え方
その他
- ゴールデンサークル：思考と行動のフレームワーク
- 人に何か行動を促してもらうためには、まず目的（why）を使えることから始めて、次にその目的を実現する手段（How）、さらに具体的な行動や製品（what）を伝えるという流れのフレーム
- 新たな取り組みのために準備することは大事だが、「準備し続けて何も始まらない」ということは避けるべし
- 結果として始められないでいるのであれば、まだ何もしていないのに等しい
- 予算あるいは人を追加すればソフトウェアが仕上がるというわけではない（ブルックスの法則）
- ただただアウトプットし続けること、あるいは大量のアウトプットを生み出すことが、アウトカムにつながるわけではない
- アウトカムにつなげるためのアウトプットとは何か？すなわち何を作れば良いのか？と問うことが大切
所感
- アジャイル開発が現在のソフトウェア開発に浸透している理由がよくわかった
- プロダクト開発の不確実性が高くなった（作り手にもクライアントにも正解がわからない）ので、間違うことを前提におきながらユーザーのフィードバックを早期に得ながら関係者で少しずつ合意形成して作っていくのが大切
- 多くのエンジニアは「なぜ弊社はアジャイル開発をしているのか？」に答えられないんじゃないか？と思った
- 弊社は今年からスクラムを導入するので、この辺ちゃんと言語化して共通認識を持っておきたい
- そうしないと「スクラムで開発する」（＝スクラムイベントを実施する）ことが目的になりそう（手段の目的化はアウト）
- スクラムイベントやチームの構成する役割が結構詳しく書いているのでスクラム初心者にはその辺の知識もインプットできてGood
- スクラムはあくまで「フレームワーク」なので、自分たちで実践してみて「自分たちのスクラム」を作っていくのが大切（正解はない）
- 内容は良いが少し長い
- 同じ内容を複数の箇所で微妙に言い方を変えているのがあってもう少しスッキリさせた方が読みやすいと感じた
- 「正しいものを正しく作る」を「わかったものを正しくつくる」「わからないものは作らない」と考えるととてもわかりやすい
コメント