「正しいものを正しくつくる」
本を読みました。
前から気になっていた、市谷さんの本。
スクラムマスターとしてプロジェクトを牽引したり、いくつかのプロダクト開発プロジェクトに参画したりして、アジャイルの概念的なものは理解できていたつもりですが、
この本を読んで一番面白いなと思ったのは、日本企業における「現実的なアジャイルの適用の仕方」について、さらにはプロダクト開発の永遠のテーマでもある「不確実性との戦い方」について非常に丁寧にステップバイステップで書かれているところでした。
個人的に心に刻んで置きたいところをいくつかピックアップで記載します。（主に開発者・開発リーダー目線です）
不確実性に適応するための「余白の戦略」
プロジェクトマネジメントやスプリントプランニングやっていて、期間に余白取るのは当たり前ですが、この本の余白の考え方は一段も二段も深かったです。
一つは、「調整の余白」。市谷さんは調整の余白に関して「広さでコミットし、深さで調整する」と述べています。
広さとは、プロダクトに備わるべき機能の数、深さとはその各機能の実装の程度を指します。
なぜ、広さはコミットして、深さは調整枠としておいておくのか？それはプロダクトが直面している不確実性に対してもっとも柔軟に対応できるからです。
例えばECサイトの構築の際に、ログイン、商品一覧表示、商品をカートに入れる、購入、などの一連の機能が揃っていないと、プロダクトを世に出して実験することすらできず、プロダクトがマーケットに受け入れられるかと言うもっとも重要な実験がいつまでもできません。
なので、広さ＝プロダクトが備えるべき最低限の機能群には、調整の余地は基本的にはないのです。
一方、深さについて、例えばログイン機能にID/Pass認証の他にOAuthやToken認証など、複数の実装を施すことはプロダクトの不確実性実証にそこまで影響を与えないケースが多いと思います。PMF（プロダクトマーケットフィット）が済んでいないプロダクトにとってこれらは蛇足で、OAuthを実装している時間があったらもっと本質的な機能実装を早めて実験すべきです。
そういった考えのもと、「調整の余白」として、「広さでコミットして深さで調整する」考え方を提唱されています。
もう一つ興味深かったのは「受け入れの余白」です。
プロダクトをマーケットに晒して実験していると、どうしても追加で実装したい機能や治したいバグがいくつも出てきます。
その時、それらのチケットをプロダクトバックログに詰んでいく運用をしていると、どうしてもそのチケットの優先順位が高くなってしまい、いつまでたっても残りの機能実装やコードをクリーンに保つ活動が疎かになってしまいます。
そういった自体を防ぎ、正しくプロダクトを成長させるために、発覚した課題はプロダクトバックログに積むのではなく、一旦アイスボックスという別の箱に蓄積し、その中から優先順位を決めてプロダクトバックログに積み直していく運用を提唱されています。
事業が求める優先度に応じて開発していると、全てが後手後手になってしまいがちですが、これによって一度冷静な目で優先順位を立て、スムーズにプロダクト開発を進めることが可能になります。
スプリント強度を高めるための「背骨駆動開発」
「背骨駆動開発」というキャッチーな言葉を今回初めて聞きました。内容は特に難しいものではなく、要はスプリントの中で、プロダクトの「背骨」になる部分から作っていこうという話です。
最初の数スプリントでプロダクトの根幹となる「背骨」を作り切ってしまって、残りの期間で肉付けを施していくような開発プロセスです。
また、最初に作る背骨は、単に基幹機能としての役割を果たすだけではなく、その後の開発のアーキテクチャ、フレームワーク、コーディングスタイルの手本となるガイドラインとしての役割も果たします。
周囲の肉付けで背骨と全く異なる実装をすることは現実的ではないので、暗黙的にコーディング規約を定めるなど、スピード以外に保守性の観点でも背骨から作っていくことにメリットがあると記載されていて、ほんとその通りだなと思いました。
事業と開発の間に生じる「ミッションの境界線」
プロダクトオーナー（事業）と開発チームの間には、往往にして軋轢が生じやすいものかと思います。
その原因として、大きくは暗黙的な責任分界が根底にあるのではないかと記載されていて、具体的には「作ると作らないの壁」の他に、「アウトプットとアウトカムの壁」が大きいのではないかと記載されています。
「作ると作らないの壁」は直感的にわかるかと思います。多くの場合、プロダクトオーナーは設計も実装もしないので、開発者との壁ができてしまうのはなんとなく理解できますね。
では、「アウトプットとアウトカムの壁」とは一体何でしょうか。
アウトプットとは「成果物」です。プロダクトコードや設計ドキュメント、テストコードなど、プロダクト開発においてたくさんのアウトプットが作成されます。
アウトカムとは「成果物によって得られる成果」です。生み出されたプロダクトをユーザーに届け、価値を感じてもらい、金銭などのリターンを得ることが多くの場合成果となり得ます。
一般的にエンジニアはアウトプットを、プロダクトオーナーはアウトカムを追い求めるものだと思います。それは職性や役割を考えると当然のことでしょう。
しかし、お互いが追い求めているものの違いを認識して理解しないと、会話のプロトコルが合わず、結果として溝ができてしまう原因になります。
溝を埋めるためには、お互いが自分の責務を全うすることに加えて、越境することが重要だと記載されています。エンジニアはアウトカムを意識し、プロダクトオーナーはアウトプットを意識する。そこには一種の混沌が生まれますが、「プロダクトとして何が正しいのか」という仮説検証を基準において、お互いが共通の言葉で話せることが重要だと述べられています。
「正しくないものを作らない」という戦略
「正しいものを正しく作る」なんて言われてみれば当たり前のこと、実際どうやったら実現できるのか？というのは結構難しい問題だと思いますが、この本で書かれている、この命題に対する待遇を考えると言うのは結構目から鱗でした。
つまり、「正しくないものを作らない」というプロダクト開発戦略を取るのです。
正しいか正しくないかの判断のために、ユーザーは本質的に何を求めているのかを探る「価値探索」のPhaseが前段にあります。ここでユーザーインタビューやプロトタイピングを経て不確定要素をなるべく取り除き、「正しくない」仮説を除外していきます。
そして、何が正しくないかがおおよそ見えてきたら、正しくないものでないもの、つまり、より正解に近いと考えられるものに対してアジャイルでプロダクト開発を行います。
これにより、不確実性の高いアジャイル開発において、プロダクト開発の前段である程度の不確実要素を除外することができ、結果的に「これ作ったけど正しくなかったね」という状態を最小限に抑えることができるはずです。
最後に
僕が特に心に残ったトピックを抽出して自分のメモがてら記載しましたが、この本は読む人の状況によって、もっと示唆に富んだ内容になっていると思います。
アジャイル開発をこれから取り入れたい人にとっては、教科書通りのアジャイルの適用の難しさと、現実解を知ることができ、
プロダクトオーナーとして不確実性と戦っている人にとっては、開発組織を巻き込んでいかに間違い少なくプロダクトを開発していけるかを知ることができると思います。
僕はあくまでも開発者・開発リーダーとしての立場でストーリーをピックアップしました。
ぜひ手にとって読んでみてください。きっと何か仕事に繋げるヒントが散りばめられていると思います。