■要約≪アジャイルサムライ≫
今回はJonathan Rasmusson氏の「アジャイルサムライ」を要約していきます。アジャイル開発の古典と呼ばれる本であり、エンジニアリングは勿論、プロダクトマネジメント・UXデザインを学ぶ上でも重要視される内容です。様々なアジャイルスタイルのプロジェクトマネジメントに従事する中で経験で体得してきた技法を改めて体系的に学び直したいと考えこのタイミングで読みました。エンジニア向けですが、ほとんどの項目はコーディングが出来なくても読むことのできる内容になっています。
「アジャイルサムライ」
■ジャンル：開発管理
■読破難易度：低（物語形式で非常に明瞭に説明がされているため読みやすいです。独特の表現技法・用語があるので読みづらいと感じる人は一部いるかもしれません。）
■対象者：・アジャイル開発について興味関心のある方
・エンジニアリング・デザイン・プロダクトマネジメントに関わる方全般
・顧客価値向上に興味関心のある方
≪参考文献≫
■LEAN UX アジャイルなチームによるプロダクト開発
■要約≪LEAN UX アジャイルなチームによるプロダクト開発≫ - 雑感 (hatenablog.com)
■エンジニアリング組織論への招待
■要約≪エンジニアリング組織論への招待≫ - 雑感 (hatenablog.com)
■カイゼン・ジャーニー
■要約≪カイゼン・ジャーニー≫ - 雑感 (hatenablog.com)
【要約】
■アジャイル開発の基本原理と用語
・アジャイル開発の原則は「顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します」になります。開発チームのケイパビリティをベロシティと呼び、継続的な開発サイクルをイテレーション（スプリント）と呼びます。イテレーションは平均で1～2週間で、TODOリストがプロダクトバックログです。顧客が実現したいソフトウェアの状態を可視化し、重要論点や進捗を可視化するフレームとしてユーザーストーリーマッピングがあります。品質・予算・期限は遵守しながら開発進捗によりスコープを柔軟に変容・対話して合意形成していくという感覚がアジャイル開発のプロジェクトマネジメントのミソです。顧客に継続的に価値を届けてなんぼなので、小さくとも顧客に動くソフトウェアを継続的に届ける・対話していくのが大事です。
・プロジェクトワークには時間と予算よりもやりたいことはたくさんあるものであり、常に優先順位付け・合意形成を柔軟にしていく感覚が求められます。アジャイル開発の手法にはスクラム・リーン・エクストリーム・プログラミングなどがあります。
■アジャイル開発のプロセス
・分析・設計・実装・テストという4工程を継続的に行い、役割を柔軟に変容していきチームで顧客に価値のあるソフトウェアを提供するということにこだわるのがアジャイル開発の基本の考え方になります。きっちりと区別しない区別しない役割分担・継続的な開発工程・チームで成果責任を果たそうとする態度の3つが重要な感覚です。開発は顧客に価値を届けてなんぼなので、継続的にビジネスサイドや顧客と対話しながらインサイトをアップデートする・建設的なフィードバックを得るなどのポイントを抑えることが重要です。顧客中心主義を徹底して、役割を柔軟に変容していく自律的なチームを構築し続けることで素早く価値を届けるのがアジャイル開発の美徳とする考え方です。
・プロジェクトを開始する前に「何を目指すのか」・「何を大事にするのか」といった価値基準に関する問いを立ててステークホルダー・開発チームの目線をすり合わせるという行為が欠かせなくなり、その為のツールとしてインセプションデッキがあります。具体的にはやらないことリスト・エレベーターピッチ・夜も眠れない問題などを言語化して事前にステークホルダーで不確実性や論点の整理をしておくことは大事になります。この初手の合意形成や対話プロセスに意味があるのです。尚、夜も眠れなくなる問題はプロジェクト遂行上のリスクをプロジェクト初期に洗い出して、対策やスコープを定めておくというもので、プロジェクトの生産性を大きく上げるために必要なものとされます。
・プロジェクトスコープの期待マネジメントは大事なプロセスでやること・やらないこと・後で決めることを言語化・可視化することでコミュニケーション齟齬を防ぐ大事な営みになります。ご近所さんを探せと呼ばれるステークホルダーを一覧で洗い出し最低限対話・関係性を築いておくことは不確実性やコミュニケーションコストの観点から初期に割くべき必要悪です。
・ユーザーストーリーは技術ではなくビジネス成果、アウトプットではなくアウトカムにフォーカスするためのコミュニケーションで顧客やプロダクト開発チームの共通言語を形成すします。ユーザーの目標や制約条件・ジョブを踏まえてユーザーストーリーを書くのがポイントであり、顧客自身かヒアリングを豊富にしたデザイナー・プロダクトマネージャーが作成するのが基本とされます。誰の・何を・なぜ・を明確にする、価値は測定できるように定量化するがセオリーです。
・アジャイル開発における見積もりの重要なポイントはユーザーストーリー毎にタスク工程とそれぞれの総工数を見積もることおよびプロダクト開発チームのメンバー毎のベロシティを可視化して、プロダクト開発チーム全体における工数見積もりや見積もりが前後する不確実性の正体に辺りをつけることなどがあります。
【所感】
・本書のフレームワークや考え方をチームに実装していくプロセスを小説仕立てで解説したのがカイゼン・ジャーニーであり、併せて読むことで立体的にイメージがつくので非常におすすめです。顧客中心主義・継続的に仮説検証を行うなどプロダクトの世界特有の感覚が細部に散りばめられた内容になっており、デザインやプロダクトマネジメントの理論やフレームワークに関する解像度も深まる非常に読み応えのある内容でした。
・顧客に価値あるものを届けながらビジネス目標を見たすような課題解決・ソリューション開発を心掛けるというバランス感覚・優先順位付けが何より大切であるということを考えさせられる内容であり、改めて様々なこれまでに行ってきたプロジェクトワーク・サービスデザインプロセスに関して顧みる格好の機会となるような内容でした。サービスデザイン・プロダクトマネジメントに従事する方は多かれ少なかれコトマネジメントプロセスはアジャイルな性質を持つので、エンジニアリング分野に関するお作法やフレームワークを理解しておくことは損がないのではないかと感じるので、食わず嫌いせず本書のような技術書を読むことをオススメします。
以上となります！