アジャイル開発を学ぶ ~ 『正しいものを正しくつくる』読書メモ ~

『正しいものを正しくつくる』を読了したので、読書メモと、それを踏まえて次の行動方針を立てる。

この本を読んだ経緯

アジャイル開発に興味を持ち、自分なりに調べていたところ、たまたま次の現場がスクラムを採用しているということでカイゼン・ジャーニーの著者が開催している勉強会に参加した。そこで改めて本著を紹介され、興味を持って購入した。

目的としては、アジャイルやスクラムが具体的にどういった方法でプロダクト開発を行っているのか、用語も含めて予備知識を入れておきたいと思ったからである。

本著の内容について、自分なりのまとめ

概要

本書は、プロダクト作りがなぜうまくいかないか、という問題提起から出発し、その問題に答えを出し、最終的に「うまくいくプロダクト作りとはどんな形になるか」という未来の姿までを述べている。

うまくいかないプロダクト作りの例として、ウォーターフォール開発を挙げているように思えるが特に開発スタイルを限定していない。

プロダクト作りがうまくいかない理由

プロダクト作りがうまく行かない理由として、著者は多様性の問題を指摘する。

• 作り手となる技術者に求められる技術範囲や、リモートワークなどの働き方など、作り手の多様性。
• SoR, SoEなど、開発するプロダクトに求められる多様性。

そして、プロダクト作りをうまく実現する方法としてこれまで行われてきたアプローチは、要件定義をしっかりすること、合意を重視すること、合意形成を遵守することだという。

たしかに上記の方法は、「やることが明確に決まっていて、あるべき姿が作る前にわかる」状態なら有効な方法だと自分も思う。しかし、サービス開発においてはそうではない。顧客も正しい姿がわかっていない場合もある。じっさい自分もとある自社サービスを開発する会社でサービス開発をしたときや、自社サービスを開発していたときは、要件定義をきっちりすることの無意味さについて悩んだ。サービスの仕様決定権が顧客の外部に存在していることが殆どであるため、仕様を決めて機能開発をしても半分以上はムダになってしまうので、作り手として非常にやるせなさを感じた。

さて、そんな状況に対応する手段として、アジャイル開発の存在が挙げられると著者は述べる。著者はアジャイルを「早く（少しだけ）形にする」方法であるとするが、そこには次のような困難さがあると指摘している。

• 作るべきものの決め方
• 合意形成の認識違い
• 変更が不可能となることへの関係者の不満

アジャイルとは

ではそもそもアジャイル開発とは何なのかについて、著者はアジャイルという言葉が生まれた経緯と日本で主要となる方法論である「スクラム」について解説する。

スクラムについては、自分の勉強対象なので少し詳しく書く。
※ といっても、書籍の内容なので詳細すぎる内容は避ける。

• 経験主義を旨とする方法論
  • 経験によるフィードバックの効果を最大化するため、透明性、検査、適応という姿勢をモットーとする
• スクラムチームについて
  • 自己組織化を行い、自分たちで作るものを判断して動く
  • 職能横断的であり、プロダクトを作るために外部の判断を必要とせずにチーム内完結できる
  • チーム内の役割
    • プロダクトオーナー
    • 開発チーム
    • スクラムマスター
  • スクラムで実施するイベント
    • スプリント
      • 一連のまとまった活動の単位
    • スプリントプランニング
    • デイリースクラム
    • スプリントレビュー
    • スプリングレトロスペクティブ
  • スクラムの成果物
    • プロダクトバックログ
      • プロダクト開発に必要なもののリスト
    • スプリントバックログ
      • ひとつのスプリント単位で開発するもののリスト。プロダクトバックログと比較して小さく、詳細化されている必要がある。
    • インクリメント
      • 実際に動かせるプロダクト

ざっくり、スクラムについての自分の認識をまとめた。

さて、次に著者はゴールデンサークルを紹介し、プロダクト作りについてどうありたいかを深堀りすることを勧める。アジャイルの導入が適切かどうかを判断するため、9つの意義をチェックポイントとして挙げる。しかしそうしてアジャイルを導入しても、開発は破たんする恐れがあるという。

破たんの理由は、「暗黙的な期待の放置」と「不確実性への対処から得られる学びが新たなる不確実性を生む」ことであるという。著者はこれらの問題に対する対応策を述べ、さらにアジャイルに訪れる２つの壁について解説してゆく。アジャイルの２つの壁とは以下のものである。

• アジャイルに作ることの困難
• プロダクトオーナーと開発チームの暗黙的なミッション境界

プロダクトオーナーと開発チームという、「作る人」と「作らない人」との境界が曖昧になってしまうため、何がプロダクトオーナーの役割で、何が開発チームの役割なのか、互いにお見合い状態になってしまうという。

自分はここの内容を読んで、プロダクトオーナーに求められる役割があまりに多すぎて辟易してしまった。ユーザビリティ設計はまだしも、ビジネスの収益性まで考えなければならないものかと。そこは経営層やマネージャ層がこれまで担保してきた役割なのかと思ったが、そういった縦割り式の組織だとプロダクト開発がうまくいかないからスクラムを採用するということになるのだろうか。

探索的な仮説検証

著者は暗黙的なミッション境界を越えるために、仮説検証を行って基準を作ることを提案する。
そこではまず、「正しくないものを作らない」戦略を取り、MVP(Minimum Viable Product, 顧客に価値を提供できる最小限の製品)をまず作るための探索的方法を紹介する。

MVPの範囲を決める方法として、モデル化とモデルの検証を繰り返して「これ以上は体験しないと検証効果が薄く、その体験を提供するにはソフトウェアが必要」となったときに初めて「作る」ことを開始すべきと提案する。

モデル化とモデル検証の具体的な方法については、ぜひ本著を参照してほしい。とても具体的に書かれている。

最後に本著は、MVPを実際に開発するために３つのアクションを挙げる。

• バックログの詳細化
• 精度と頻度の戦略
• わかったことを正しく作る

そして、現状の理解で解決できない課題が出てきたときの対応として、「越境」を挙げる。さらに、越境を実現したチームが実施する「問いと向き合い続ける共創によるプロダクトづくり」の未来を提示し、本著は締めくくられている。

自分はこの箇所を読んでいて（正確には本著6章）、大きな勇気を得たように思う。以前のサービス開発で自分の作った機能が全くリリースされずに破棄されてから、作り手としての大義を失っている自分にとって、「作り手がモノを作るときの高揚感」の存在を肯定してくれる本著は素晴らしい本であると感じる。自分はまだスクラムを経験していないが、アジャイルとその先にある未来の姿について、興味深い知見を得られたように思う。

次のアクション

• 自分の人生設計について、ストーリーマッピングを使って可視化する
• システム開発以外（心理学などの学問）の情報を吸収し、新しい視座を得る
• モノづくりの喜びを得るため、プログラミング、データベース設計について本気で取り組む