概要
以前紹介した『アジャイルプラクティス』においては、アジャイル開発に取り組む上での姿勢や習慣について書かれていました。
【感想】『アジャイルプラクティス』を読みました！ - LEFログ：学習記録ノート
今回紹介する『アジャイルサムライ』では、具体的な手法がたくさん提示されており、現場でアジャイル開発を実践していく方法が述べられています。
特徴としては、たくさんのイラストが載ってあることです。また、色んなユーモアも散りばめられています。
もし、アジャイル開発にこれから取り組もうと考えているチームや組織にとっては、必読書の一つだと思いました。
本日の記事では、自分が特に学びになった点について、簡単にまとめていきたいと思います。
スコープを柔軟にしておく
スコープを柔軟にしておくことが、計画のバランスを保ち、やると決めたことはやり遂げていくための秘訣だ。（p. 9）
この引用が、実は『アジャイルサムライ』において最も重要な部分かもしれません。
スコープとは、「プロジェクトで行う作業の範囲と、成果物に何を含めるかを定めたもの」のことです。より分かりやすく言い換えるなら、作業の内容と実装する機能のことです。かなり単純化するなら「実装計画」とも言えるでしょう。
このスコープを柔軟に変化させることで、時間・予算・品質を保つことができるようになってきます。
なぜスコープは変えられるのか？
それは、実際に開発を始めるまでは分からない要素が多いから、です。ソフトウェアの開発においては、不確定な要素がたくさんあります。
- 顧客の求める要素に変更がある
- 開発者が増減する（転職や体調不良）
- 技術検証の結果、実装が困難／不可能だと分かる
スコープを固定化してしまうと、そうした変化に対応することが難しくなります。
状況は常に変化します。ヘラクレイトスの言うように、万物は流転します。
時間・予算・品質という変えられない成約の中で、柔軟に対応させるべきはスコープなのです。
では、どうやって契約を結ぶか？
ここで、この記事の執筆者であるレフ蔵はこう思いました。🐘
「なるほど、スコープを変えることで変化に対応することができるのか。しかし、そうすると、顧客の方とどのように契約を結べば良いのだろう？」
疑問に思ったレフ蔵は、マスター・AIセンセイに尋ねました。マスター・AIセンセイいわく、次のような回答をご教示されました。
- 変更が生じることを前提とし、変更への対応を契約に組み込む。
- 固定価格の契約よりも、時間と材料に基づく契約や、イテレーションごとの支払いベースの契約を検討する。
- 両方のパーティーがリスクを共有する形態を取る。例えば、収益共有モデルやボーナス/ペナルティの導入など。
- アジャイル開発は進行中に要求が変わることがあるため、定期的に契約内容を見直し、必要に応じて調整することができるような条項を組み込む。
総じて、アジャイル開発における契約は、変更と柔軟性を前提とし、両方のパーティーがリスクと利益を共有する形を取るべきです。これにより、プロジェクトの成功の可能性が高まります。
つまり、「スコープの変更自体を契約に入れること」「機能が実装されるごとに課金されること」が具体的な案として挙げられていました。
機能が実装されるまで金額が発生しなければ、お客さんも納得がいくでしょう。イテレーション*1で取り組む予定の新規機能が実装困難だった場合は、途中でお客さんと相談してスコープを変えることもできるでしょう。
最近ですと、サブスクリプション型の契約体制も増えているようです。
情報共有するためのコツ
アジャイル開発においては、顧客と開発チームが密接な関わりを持つことが重要になります。
つまり良質なコミュニケーションを取れるようにしておかなければなりません。
とはいえ、そのためには有効な方法を知る必要があります。ただ単にミーティングを増やすだけでは、無駄な時間を浪費してしまうからです。
ユーザーストーリーを考える
文書化の落とし穴は、誤解を生む可能性があることと、その労力に見合わないことです。ミーティングで話し合ったことを細かく文書化していても、それが後から変更する可能性は高いです。
そのため、文書化する際には工夫する必要があります。
具体的には「ユーザーストーリー」を作っていきます。
ユーザーストーリーはそれぞれが小さなカードになっていて、分かりやすく端的である必要があります。それらを並べていくことで、必要な機能の全体像を共有しやすくなります。
簡単！楽しい！5分でわかるユーザーストーリーマッピング(User Story Mapping) - Qiita
こちらの記事から引用致しました。
上の画像のように、誰が見ても分かりやすい言葉で並べ、お客さんとのコミュニケーションを促します。
開発速度を見極めるために
プロジェクトによって、どのくらいの速度で予定が進んでいくのは異なります。
この開発速度を見極めるために、「ベロシティ」と「バーンダウンチャート」という考え方を取り入れます。
ベロシティ
ベロシティとは、「チームがユーザーストーリーを動くソフトウェアに変換する速度」のことを指します。
このベロシティを見積もるためには、実際に開発を始める必要があります。
開始時点では、完全に推測でベロシティを見積もる必要があります。開発がある程度進んだら、ポイントのつけたTODOリスト（マスターストーリーリスト）を、一定期間（イテレーション）で割ることで、適切なベロシティが見積もれるようになっていきます。
バーンダウンチャート
バーンダウンチャートとは、残りのTODOをどれだけ燃やし尽くしたか（完了させたか）を分かりやすく図にしたものです。
縦軸を「残作業量」、横軸を「時間」にして、その傾きを「ベロシティ」にしています。
このチャートを用いることで、現在自分たちがどのくらいのタスクをこなし終わったのか、大体いつくらいに完了できそうなのか、途中でどんな不足の事態があったのか、を視覚的に捉えることができるようになります。
全体の進捗状況を共有する上で、これは分かりやすいです。
作業する上での注意
カンバンの使い方について
まず、カンバンについて説明します。
タスクの書いてある付箋を「作業前」「作業中」「作業完了」という仕切りに貼って移動させることで、現在の進捗状況を共有する方法です。
このイラストを見ていただければすぐに理解できると思います。
このカンバン方式のプロジェクト管理は、アジャイル開発のみならず、色んな場面で活用されています。
さて、この『アジャイルサムライ』においてもカンバンは紹介されているのですが、その利用方法において注意がありました。
カンバンでは仕掛り（WIP: Work In Progress）に上限を設けていることだ。チームが同時に着手する作業の数はこの制限を超えてはいけない。
例えば、このIn Progressの仕切りの中に、たくさんのタスクが置かれている状態はあまり好ましくありません。なぜなら、一度に一つのことに取り組んだほうが、混乱せずに済むからです。
個人でカンバンを使う場合でも、In Progressには一つのタスクだけ置くようにしたほうが良さそうです。また、TODOの左側に、TODOに入れるか分からない仕切り（IceboxやStories）を作るのも有効的な手段です。
マスターストーリーリスト＆イテレーションを用いる方法と、カンバンを用いる方法は厳密には異なっています。しかし、これらを組み合わせて使うことはできるはずです。実際、フィヨルドブートキャンプのチーム開発では、カンバンにポイントを付け、それを一週間サイクルで回していました。
おわりに
『アジャイルサムライ』ではアジャイル開発を実現するための、様々な具体的な手法が載っていました。今回の記事では紹介できなかったものもたくさんあります。
アジャイル開発が難しい場面でそれを実践する方法や、現実に発生する様々なシナリオも掲載されています。アジャイル開発をすでに知っていても、学ぶ点は多いと思います。
ぜんぜん話が変わるのですが、本書に出てくるこのイラストを見るたびに、自分の脳裏に『ニンジャ・タートルズ』が浮かぶのは、気のせいでしょうか……🐢
追記
Opening Keynote for AgileSamurai BaseCamp - Speaker Deck
アジャイルサムライ制作秘話はこちらの角谷さんのスライドにまとまっていてオススメです！
*1:開発における一定の期間
