【アジャイルサムライ】まとめと目次｜−達人開発者への道−

「アジャイルサムライ- 達人開発者への道」という書籍の要約（まとめ）と目次の紹介をしたいと思います。その中でどのように解釈すると良いかを可能な限り解説します。本書を手にとって読みながら、もしくは読んでから記事をご覧いただければと思います。

※まだの方は前記事も読んでいただけますと幸いです。

この「アジャイルサムライ」を一言で表現すると、「アジャイル宣言の背後にある原則」の実践の仕方について具体的に説明したもの、となります。

ちなみに「アジャイルソフトウェア開発宣言（アジャイル宣言/アジャイルマニフェスト）」については、巻末に紹介されているものの、本文には登場しません。著者によるとアジャイル宣言は「当たり前である」ため載せていないということです。

私としてはその「当たり前」が難しいと思うのです。

理解の順番としてはアジャイル宣言の「価値観」があっての「原則」となりますので、「価値観」の部分は「アジャイルサムライ以外」で学ぶ必要があります。

例えば、本記事にてゆっくり学ぶことができます。笑

さて、12個ある原則がちりばめられているのですが、登場する原則を数えてみると、11個しかないことに気づきました。こんな風に全て揃っているか数えるのは私ぐらいかもしれません。笑

唯一抜けているのは下記です。

8. アジャイル・プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
アジャイル開発の原則

なぜ抜けているのか分かりませんが、いつか著者に会う機会がありましたら聞いてみたいです。単純に紙面の都合かもしれません。

ただ、この原則は特に今の時代に必要なものです。SDGsや働き方改革が叫ばれている今、アジャイルはソフトウェア開発を持続可能なものとする、大きな手段のひとつになります。

それでは、目次単位に要約（まとめ）をしていきます。

ご参考として、各章の原則も引用します。

アジャイルサムライ――達人開発者への道

アジャイルサムライ達人開発者への道【目次】
侍｜アジャイル侍
0. お目にかかれて光栄です｜アジャイルサムライの意味
1. ざっくりわかるアジャイル開発｜3つの真実
2. アジャイルチームのご紹介｜成果責任はチーム
3. みんなをバスに乗せる　｜インセプションデッキ
4. 全体像を捉える｜ 5. 具現化させる
6. ユーザーストーリーを集める｜INVEST
7. 見積り：当てずっぽうの奥義
8. アジャイルな計画づくり：現実と向き合う
9. イテレーションの運営｜トヨタ生産方式（ジャストインタイム）
10. アジャイルな意思疎通の作戦｜レトロ（ふりかえり）
11. 現場の状況を目に見えるようにする｜透明性
12. ユニットテスト：動くことがわかる｜13. リファクタリング：技術的負債の返済｜14. テスト駆動開発｜15. 継続的インテグレーション：リリースに備える
荒ぶる四天王｜品質コストスケジュールスコープ
アジャイルサムライ達人開発者への道まとめ

アジャイルサムライ達人開発者への道【目次】

ざっくりわかるアジャイル開発
アジャイルチームのご紹介
みんなをバスに乗せる
全体像を捉える
具現化させる
ユーザーストーリーを集める
見積り：当てずっぽうの奥義
アジャイルな計画づくり：現実と向き合う
イテレーションの運営：実現させる
アジャイルな意思疎通の作戦
現場の状況を目に見えるようにする
ユニットテスト：動くことがわかる
リファクタリング：技術的負債の返済
テスト駆動開発
継続的インテグレーション：リリースに備える

侍｜アジャイル侍

アジャイルサムライはなぜ「侍」ではなく、カタカナの「サムライ」なのでしょう。

ウィキペディアにて「侍」を検索してみました。

侍（さむらい）は、古代から中世にかけての日本における官人の身分呼称、あるいはそこから発展的に生じた武士の別名である。「伺候（しこう）^[1]する」「従う」を意味する「さぶらう」（旧仮名遣いでは「さぶらふ」〈候ふ／侍ふ〉）に由来する。
アジャイルサムライ

上記だけではまだよくわかりません。読み進めてみましょう。

0. お目にかかれて光栄です｜アジャイルサムライの意味

本書を手に取る誰もが「アジャイルサムライの意味って何？」「なんで侍なの？」「アジャイル開発とどんな関係があるの？」という疑問をもたれるかと思います。その答えが最初に載っています。

目次をざっと見て、必要なところだけ読んで効率化しようとする方も、この章は大事ですので読んでください。方針を理解すると、読み進めやすくなります。

「マスター・センセイ」というキャラクターはあまり気にしないで構いません。笑

先生・教科書からの言葉だな、という程度で大丈夫です。

ポイントは弟子に「熱心な」という形容詞が付いていることです。

新しいことを学ぶ場合に熱心でないと身につきません。ぜひ、熱心なマインドで、学び取るという意識で読み進めてみてください。

そして、熱心な弟子が「アジャイルサムライ」となり、「アジャイルサムライ」が「マスター・センセイ」となり、また熱心な弟子を育てる、、、そんなサイクルができたらと思います。

3. 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
アジャイル開発の原則

1. ざっくりわかるアジャイル開発｜3つの真実

たったの13ページを読むだけでざっくりとアジャイル開発がわかります。

さて、「価値ある成果を毎週届ける」を少し読み解きます。

「価値ある成果」とは「顧客」にとっての価値がある、リリース可能なソフトウェアです。
「毎週届ける」は短期間のサイクル（反復）で継続的にリリースするということです。

上記の2つが揃って初めて「アジャイル開発をしている」と言えます。

注意が必要なのは顧客にとっての価値、の解釈です。顧客（発注元）に依頼された通りに作ると「価値あるもの」になるのか？ということです。

ソフトウェア開発を経験されている方であれば、顧客の要求・要件・仕様通りに開発したものの、使われない機能となることが往々にしてあることをご存知のはずです。

つまり、「価値」を見つけてソフトウェアに「価値」を吹き込んであげる必要があるんです。多くの場合、そのソフトウェアを利用するユーザーに対する価値となりますが、これをおざなりにして開発してしまうことがあります。アジャイルでは開発する前に「価値」を見つけて定義します。

短期間で反復することはアジャイル開発の大きな特徴のひとつです。重要なのはただ反復するのではなく、価値を届けてフィードバック、リターンを得る、というサイクルにすることです。

そして、私が「ハッ」とさせられたのは、「誰もがこの働き方を気に入るわけじゃない」という警告です。

「アジャイル」はなんでもある程度のことができる万能型のゼネラリストを求めて入るような気がしていて、それに合わない人には辛いだろうな、と思うことがあります。例えば、「アジャイリスト（アジャイル開発実践者）」ではなく、なんらかの「スペシャリスト」を目指すという考え方もあるかと思います。

ただ、「アジャイル」「Be Agile」という世界は、もはやソフトウェア開発に止まらず、あらゆるビジネスのほぼすべての機能に対して適応するマインドセットであり手法となっています。

新人教育で学ぶべき社会人としての基礎、さらには学生の必須科目となる時代もそう遠くないと考えています。

「アジャイル」に苦手意識、抵抗感、反発感がある方も少しずつ理解を深められたらと願っています。

最後は3つの真実です。ここで著者が言いたいことは分かりますが、日本社会における階層構造がこの3つの真実を歪ませてしまって入るように思えます。結局は発注元のお金を出す企業が一番えらく、受注元、下請け、孫請けの企業が無理な論理を押し込まれ、従わざるざるを得ない状況になることがよくあります。

もっと、社会の構造がフラットに対等になれば良いのですが、どうすればそのような世界にできるのか分かりません。もしかすると、「共創（Co-creation）」という世界が答えのひとつなのかもしれません。

1. 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
アジャイル開発の原則

3. 動くソフトウェアこそが進捗の最も重要な尺度です。
アジャイル開発の原則

2. アジャイルチームのご紹介｜成果責任はチーム

ここで紹介されている「アジャイルチーム」はかなり純度の高い理想像であるため、あまり真に受けないようにしてください。

役割分担がはっきりと分かれずうまくいくのは、ひとり一人のスキルが高く、作業が見える化され、互いの役割を補完できるほどにチームが成熟している状態にある場合です。逆に言いますと、これらの条件を満たすことを目指せば良いということになります。

どの工程も連続的な取り組みになるというくだりは、反復による学びが大事というだけでなく、ウォーターフォール開発でもアジャイル開発でも、やるべき工程はやるべきで、省略できるものではないという本質があります。

もちろん、各工程内で無駄なことは省略しますが、本当に必要なことは当たり前ですが必要です。

「アジャイルだから」と変な論理で必要な工程を省いてしまうと、「リリース可能なソフトウェア」にすることができません。

顧客と同じ場所で働くと良いのは昔から言われて入ることです（コロケーション）。ウォーターフォール開発でもみんなが大部屋に入ってそこをプロジェクトルームとすることがよくあります。ただ、それが難しい場合にいかにコミュニケーションを円滑にするか、ということが大事になります。場所が物理的に離れるとコミュニケーションロス、ミスが発生するということを前提に、どうカイゼンすれば良いかを考え、調べ対応していきましょう。

「自己組織化」はアジャイルで最も重要とされる概念のひとつです。価値を生み出す単位は会社でも部門組織でも個人でもなく、チームであると考えているため、開発チームが組織として成り立つことの重要性を理解します。ステークホルダーは開発チームを大事にして欲しいですが、開発チームもまたステークホルダーを大事にすることで、プロジェクト全体がうまくいくと考えています。

チームメンバーを探すコツにあるものは、そのまま「アジャイル」への適正となります。

ただ、環境は状況によっては、「スペシャリスト」「明確にルールを決めて従わせる人」「空気を読まずにある方向へ導く人」が求められることがあるため、コツに当てはまらないからといって悲観的になる必要はありません。

4. ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
アジャイル開発の原則

11. 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
アジャイル開発の原則

5. 意欲に満ちた人々を集めてプロジェクトを構成します。
環境と支援を与え仕事が無事終わるまで彼らを信頼します。
アジャイル開発の原則

3. みんなをバスに乗せる　｜インセプションデッキ

インセプションデッキは下記の問いに答える形で作成します。

大事なのは作成したあとであり、チーム内の共有だけでなく、顧客やステークホルダー全員に共有、宣言しましょう。壁に貼って誰でもいつでも見える状態にしておくとよいでしょう。

一度作成して終わりではなく、定期的に見直して最新化してよりどころの一つとしたいものです。

我々はなぜここにいるのか
エレベーターピッチ
パッケージデザイン
やらないことリスト
プロジェクトコミュニティ（「ご近所さん」を探せ）
技術的な解決策の概要
夜も眠れなくなる問題
期間を見極める
トレードオフスライダー
なにがどれだけ必要か

プロジェクトの規模が大きくなればなるほど、自分たちの役割、向かうべきところがわからない場合があります。そして、役割もスコープも明確になっていない場合に、人から依頼されたことをただやることになったりします。

どこに向かって頑張ればいいのか（どこを頑張らなくていいのか）を明らかにし、後になって、期待されて入ること貢献できるとのころの乖離が大きくならないようにすることは、プロジェクトの成功に大きく影響を与えます。

4. 全体像を捉える｜ 5. 具現化させる

インセプションデッキの重要度は理解できますが、顧客の時間が避けない場合はプロジェクトを停止させるというくだりは「アジャイルサムライ」の潔さを感じます。それほど、顧客の関わり度がプロジェクトの成功を大きく左右するということです。それは、ウォーターフォール開発でもアジャイル開発でも変わらないと感じています。

インセプションデッキについては量も多く重要なプラクティスのひとつであるため、スピンオフし、まとめて別記事にする予定です。

6. ユーザーストーリーを集める｜INVEST

良いユーザーストーリーの条件は「INVEST」
・独立している（Independent）
・交渉の余地がある（Negotiable）
・価値がある（Valuable）
・見積もれる（Estimatable）
・小さい（Small）
・テストできる（Testable）

今までどれほど無駄な文書を作成することに時間をかけ、書いてしまった文書に囚われてしまっていたかを思い出します。

ユーザーストーリーはユーザー視点で書かれるため、ユーザーが必要とする価値のあるものでなければならないため、必然的に使われないフィーチャー（機能）は開発されなくなります。そして、ユーザーストーリーをきっかけとして、顧客と背景を含めて会話をするため、自分たちは何のために機能開発をしているかを理解することができます。

そのユーザーストーリーを顧客（プロダクオーナー）が書くのを基本とするのは良いのですが、現実的にはかなりの無理があります。それはスキルの問題だけでなく、それに割く時間が取れない（多忙すぎる）などの理由によります。

そのため、顧客がPOチームを作って作成、もしくは開発チームが代行して書くことが多いです。ただ、ユーザーストーリーの作成プロセスには関わること、優先順位付けは顧客がやるなど一定の線引きは必要です。

6. 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
アジャイル開発の原則

7. 見積り：当てずっぽうの奥義

「当てずっぽう」という表現が使われていますが、適当で良いということではありません。

正確に見積もることはできないということを前提に、ざっくりと全体のプロジェクトをやり切れるかの見通しを立て、直近の作業についてはチーム内の過去実績をベースに相対的な見積もりをします。

見積もり作業もタイムボックスを設けて、限られた時間で最善を尽くして見積もります。

開発の速度をベロシティとして計測し、今後の見通しを立て、プロジェクト全体のやり遂げそうか感もイテレーションごとに調整していきます。

8. アジャイルな計画づくり：現実と向き合う

「スコープ」「期日」「予算」「品質」の全てが固定化されている場合でも変化は起こる

何が大事（固定）で、何が柔軟（変化）なのかというマインドセットが従来型と大きく異なります。そして、そのマインドセットをベースとした進め方について、可能であれば、顧客と認識を合わせ、合意することが必要となります。この顧客やステークホルダーと合意せずに、開発チーム内だけでアジャイルな計画で進めようとすると、誤解から不信感が生まれ、プロジェクトリスクは日を追うごとに積み上がっていきます。

2. 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
アジャイル開発の原則

10. シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
アジャイル開発の原則

9. イテレーションの運営｜トヨタ生産方式（ジャストインタイム）

イテレーションはアジャイル用語ですが、スクラムでは「スプリント」と呼びます。

タイムボックスは時間を区切って、その時間内の作業にフォーカスするという意味で、多くのプロジェクトのイテレーションは1〜2週間のサイクルが採用されています。

ジャストインタイムは「トヨタ生産方式」の流れを汲んでいます。興味のある方は関連書籍を読んでいただけますと、よりアジャイルを深く理解できるようになります。

10. アジャイルな意思疎通の作戦｜レトロ（ふりかえり）

イテレーションでやるべき4つのことは、ストーリーの計画を立てること、イテレーションの計画を立てること、フィードバックを得ること、ふりかえりをすること

こちらもスクラムとの用語の違いがありますが、ストーリー（バックログ）の計画を立て、イテレーション（スプリント）の計画を立て、ショーケース（スプリントレビュー）でフィードバック得て、レトロスペクティブ（ふりかえり）をする流れとなります。

ただ、反復した開発にすれば良いというわけではなく、しっかりをフィードバックを得ながら進めて入るのか、レトロで振り返って次のアクションに落とし込めて入るかが、アジャイルであるための必要条件となります。

12. チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。
アジャイル開発の原則

11. 現場の状況を目に見えるようにする｜透明性

貼りもののオススメは
「インセプションデッキ」
「ストーリーボード」
「リリースボード」
「ベロシティとバーンダウンチャート」

従来は開発チームが報告のためのだけの資料を多くの時間を割いて作成していました。

体裁を気にしたり、数字を集めたり、何を話して何を隠すかを考えたり、報告書を書いている途中で状況が変わって修正したり、、そのような時間をいかに減らすか、が重要です。

その答えのひとつとして、チームの状況やありたい姿、チーム内のルール等をホワイトボードや模造紙、付箋などで表現し、壁に貼ることを提案しています。そうすると、経営陣やマネージャー、ステークホルダーだけでなく、開発チーム同士のコミュニケーションも促進されます。

可能であれば壁に入って見える化（いつでも目に入る状態）をしたいですが、それが難しい場合もあります。その場合はTrelloボードやmiroなどのツールの活用をご検討ください。ツールにもデジタルにデータが残ることや、現場にいなくても状況が見られるなどのメリットがあるため、使い分けが肝要だと考えています。

スクラムの用語（原則）で表現すると「透明性」ということになります。

12. ユニットテスト：動くことがわかる｜13. リファクタリング：技術的負債の返済｜14. テスト駆動開発｜15. 継続的インテグレーション：リリースに備える

残りの章（12〜15）は技術的なXPのプラクティスであるため、別途の記事とする予定です。

9. 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
アジャイル開発の原則

荒ぶる四天王｜品質コストスケジュールスコープ

本書では「品質」「コスト」「スケジュール」「スコープ」の四つが「荒ぶる四天王」と称されています。

これらは相関関係があり、全てを満たすのは難しいものです。

例えば、スコープを大きくしたいのであればスケジュールをのばして欲しいですし、コストを下げたいのであれば品質を下げたくなるものです。

実際にはどれもなんでもかんでも高いレベルで要求しようと主張されることが多く、「荒ぶる」という表現になっています。

一般的には下記のように言われます。

	固定	可変
ウォーターフォール	品質、スコープ	スケジュール、コスト
アジャイル	品質、スケジュール、コスト	スコープ

しかし、現実のウォーターフォールはプロジェクトの開始時点、サービスイン（リリース日）が決まっており、予算も決まっています。進捗の遅延がくとスケジュールが荒ぶりますし、想定外の作業が出てきたり、想定した生産性が出ないとコストが荒ぶります。

アジャイルにおいても、固定化されたチームの実力の範囲内で持続的なペースを維持できるように、スコープを柔軟に調整できることが理想ですが、より多くのフィーチャーを要求されるケースも多いでしょう。

ただ、ソフトウェア開発におけるコストの大部分は「人（工数）」となります。ウォーターフォールではプロジェクトに対して人がアサインされますが、そんなに都合よく良い人材を集めることは大変です。アサインされる方も急に大きなプロジェクトに突っ込まれたり、フェーズ（工程）が変わったらリリースされるなど、落ち着きません。

一方で、アジャイル開発では「人（チーム）」が先にあって、そこにプロジェクトがアサインされるため、人が安定します。これは私がアジャイルに携わることになって、最もよかったと感じていることのひとつです。