【書評】正しいものを正しくつくる
「正しいものを正しくつくる」という書籍
2019年6月14日出版、「正しいものを正しくつくる」という書籍が出版された。この本について詳しく話す前に、時計の針を一年ばかり戻したいと思う。
2018年に出版された、"カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで" という書籍がある。
アジャイル開発をいかに実践していくかを情感のこもったストーリーとともに伝えたこの一冊を読んだことがある・周囲に勧められたエンジニアは多いのではないだろうか。私自身、昨年のチーム運営に大きな影響を与えてくれた一冊だと感じている。
そしてこの「正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について」はカイゼン・ジャーニー著者のうちのお一人、市谷さんによる単独の著作となっている。
開発者コミュニティDevLoveのファウンダー。ギルドワークスのCEO。
多方面で活躍されている市谷さんだが、本書では「プロダクトをつくる」ことにフォーカスし、いかに開発を回していくか、またそれより手前のいかにつくるものを見出していくかということの言語化にチャレンジしている。
なぜ書評を書くのか
縁あって、本書が完成していく過程でレビュワーとして協力させていただいた。300ページを超える分厚い最終版を読み終え、少しでも多くのエンジニア(プロダクトの作り方、というとプロダクトオーナーやマネージャー層の仕事、と捉える向きもあるだろうが、そう線引をしてしまうエンジニアほどこの本を読んでほしい)が本書を手にとり、それぞれでエッセンスを咀嚼することで「正しいもの」が「正しく」作られる風土が作られるのではないかという期待を抱いた。
一方で、この本を届けるべきところへ届けるためにはハードルがある、とも感じていた。
おわかりだろうか。分厚いのである。
エンジニアは、得てして自然言語が苦手である。
読書に抵抗感を持つ者も少なくない。しかし、読書耐性がないエンジニアには届かないというのではもったいない。
本書評を書く狙いはそこにあり、本書の魅力をコンパクトに伝え、願わくば多くのエンジニアが覚悟を決めて本書を手に取るようになる…そう願って書評を書くことに決めた。
誰が読むべきか
特に、初めてプロダクトオーナーを経験するエンジニアにとっては不確実な「ただしいもの」をつくるための道しるべとなってくれるだろう。
ただ、個人的には「開発にしか興味がない」エンジニアにこそ読んで欲しいと思っている。自分のエンジニアリング対象から越境しプロダクト、そして事業の視座から眺める所作は、もはやプロダクトオーナー・マネージャーといった肩書を持つ人間でなくとも行うべきだと考えるからだ。
逆に、本書に「銀の弾丸」、つまり「このプラクティスを採用すれば万事OK!」という魔法のようなものを期待する人は手に取るべきではないかもしれない。本書では不確実性との向き合い方を言語化しているがゆえに、多分に定性的である。読者には、その定性的な記述、問いから自分自身の働き方へ落とし込んでいく消化力が求められる。
それでは、いよいよ本書の解説に入っていきたい。
第一章 なぜプロダクトづくりがうまくいかないのか
いきなり「なぜうまくいかないのか」、である。
不思議に思わないだろうか。5年、いや10年前までさかのぼってみても、今ここのプロダクトづくりが楽勝になった感じはしない。
言われてみればそうだな、と思わされる。
不確実性と向き合うために生まれたはずのアジャイル開発が、さらなる不確実性を呼び込んでいるという事実。
この一見ネガティブな出だしは、救いであると感じた。要するに「どこの現場でも失敗や混乱は起きている」のだ。
また、多様性がひとつのキーワードになっていると感じた。多様性は必要だが、不確実性をもたらす。不確実性をもたらすが、必要だ。
第二章 プロダクトをアジャイルにつくる
この章は、タイトル通り「アジャイルにつくる」ということを解説している。アジャイル開発を一通り経験している人ならば、概念としては触れたことがあるものが多いだろう。
上記のような書籍を読んだことがある人ならばある程度読み飛ばしが可能だが、筆者なりに解釈された「プロダクトを早く形にできることで得られる9つの意義」(p.90から)についてはぜひご一読いただきたい。
余談だが、私はこの章を読んで、改めてチームで「スクラムガイド」を読み合わせすることに決めた。
第三章 不確実性への適応
アジャイル開発を採用していてもなお立ちはだかる不確実性。
ステークホルダーの暗黙的な期待(期待はたいてい、暗黙的!)や成り立たないトレードオフ(トレードオフスライダーを定義したのに!)といった現実の開発現場で発生する課題と、そこにどう向き合うか。
ここではインセプションデッキやユーザーストーリーマッピング、OODAループやSARといった概念が紹介される。
余白で不確実性を受け止めるという戦略は無意識にやっている場合もあると思うが、ここで言語化されているように意識的にやることでより不確実性と向き合いやすくなるのではないだろうか。
プロダクトづくりをクリーンに保つことがスプリント強度につながる
受け入れ条件の明確化、ベロシティの計測と安定、受け入れテストの実施、ふりかえり、そして実運用相当のデータが揃っていること。
文字で見ると「うんうん、当たり前だよね」と思ってしまうこれらの条件を果たして満たせているだろうか?この章はそう問いかけてくる。
第四章 アジャイル開発は2度失敗する
またまた衝撃的なタイトル。この章と、次の五章が個人的には本書のハイライトだ。
・アジャイルに取り組み始めたけどうまくいかない
・アジャイルとしてはうまくまわるようになったけどプロダクトがユーザーに届いていない
なんとも身につまされる話だ。
チームとプロダクトオーナーとの溝、アウトプットとアウトカムの溝。
「何かしらアウトプットは出ているが成果にはつながっていない」、そんな経験はないだろうか。また、開発チームが「自分たちの仕事はここまで」と線引してしまうあたりも非常にリアルである。
いくら開発のやり方を正しくしたところで、間違ったもの(ユーザーにとって価値のないもの)を作っている限りは、その意義は薄い。
第五章 仮説検証型アジャイル開発
いよいよ「正しいもの」をいかにつくるか、核心に触れていく章だ。
仮説検証のアンチパターンを列挙し釘をさしたところで、いよいよ段階的な仮説検証の方法が示される。
https://right.guildworks.jp/ より引用
仮説キャンバスで静的な課題の構造を明らかにし、カスタマージャーニーマップやユーザーストーリーマッピング、サービスブループリントといった方法で動的なユーザーのフローをあぶり出す。
この章では筆者が経験してきた現場のノウハウが噴出しているように感じた。仮説検証の方法にせよユーザーの観察方法にせよ、かなり多様に、そして詳細に虫の目で描かれている。ここまで比較的「鳥の目」でプロダクトを眺めていた本書が、ここではグッと視座を変えてきている。読む時はその変化を意識したほうがいいかもしれない。
第六章 ともにつくる
いよいよ最終章。あくまでさりげなくだが、アジャイル、特にスクラムの原理原則からの脱皮が図られている点が興味深い。(プロダクトオーナー代行など)
視座・視野の変更、多様性の尊重。一人の人間のような状態に近づいたチーム。たとえばスプリントレビューを待つことなくプロダクトオーナーと交わされるやりとり。
結局のところ信頼関係とコミュニケーション、これらが絶対的に重要であると感じられる終章だ。
最後に。目的に忠誠を誓うチームのことだ。だが、目的が誤っていたとしても、目的に心中することなく、方向を自ら変えることができる。これが可能なのは、「自分たちは正しいものを正しく作っているか?」という問いを抱いているからだ。問いに向き合い続けられるならば、目的自体を捉え直すこともできる。
第六章で描かれるチーム像はいわゆる「自己組織化チーム」だが、最終盤で自己組織化チームが持っているべき問いについて提示される。自らに問いを向けられない組織は自家中毒に陥り崩壊する。「正しいものを正しく作っているか」、この問いの重要性に改めて気付かされたところで本書は終わる。
章立てに込められた想い
まえがきでも言及されているが、プロダクト開発の時系列としては4->5->2->3の順番となる。しかし筆者自身の経験した流れ、ジャーニーを追体験するという意図が込められ、この順番になっているとのことだ。
私個人の意見としては、この章構成でベストだと感じている。エンジニアの興味や特性を考えると、おそらくまずアジャイルに飛び込み、失敗し、プロダクトに立ち返るーという道を通るだろうからだ。なのでまずは章立て通りに読み、筆者の経験を追体験することをおすすめする。
まとめ
平成と令和の境界で書かれた本書は、プロダクトづくりのあり方を可能な限り言語化した強烈な一冊だ。
300ページを越えるボリューム、扱うテーマの不確実性ゆえに、曖昧で解釈の余地が残る記述。敷居は決して低くはなく、読めば、ここに書いてあることを機械的に反復すれば開発がバラ色になる、そういう書籍ではない。読者自らが咀嚼し、実践し、失敗し、カイゼンし、血肉としていく。そういう骨太な一冊だと感じた。
おそらく、これからこの本をベースにした勉強会や読書会が各地で開かれるのだろう。各々の現場で咀嚼されたエッセンスがどう昇華していくのか楽しみだし、自分自身も現場でしっかりと活かしていきたい。