アジャイルサムライ-第1章〜ざっくりわかるアジャイル開発〜

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

第１部「アジャイル」入門
第１章　ざっくりわかるアジャイル開発
1.1　価値ある成果を毎週届ける
1.2　アジャイルな計画づくりがうまくいく理由
1.3　「完了」とは完了のことだ
1.4　3つの真実

アジャイル開発をキーワードにしないためにも、本書を読んで実践してみよう。実践できなくても、アジャイル開発の原則、真髄についてを考え続けたい。第1章は、まずはざっくりアジャイル開発について説明しています。
それぞれ、気になった箇所を書き出して、感想書いてみました。

第1章では、次の3つがざっくりわかります。

1. アジャイルな計画の立て方
2. プロジェクトがうまくいっている度合いを測る方法
3. 3つの真実を受け入れることの効能について

アジャイルな計画づくりがうまくいく理由アジャイルなプロジェクトの計画づくりは、いろんな予定が立て込んでいる週末の準備とそう変わらない。違いがあるとすれば、ToDoリストやタスクのことをマスターストーリーリスト*1、ユーザーストーリーといったこじゃれた名前で呼ぶことだ。
この「マスターストーリーリスト」がプロジェクトのToDoリストということになるそうです。リストに載せるものは、開発対象となるソフトウェアで顧客が実現したいと思うフィーチャ*2(ユーザーストーリーとして実現する)
リストの項目に顧客が優先順位をつけて、開発チームが見積もったら、プロジェクト計画の土台はできあがりだ。
　具体的に成果をあげていくためのエンジンとなるのがイテレーションだ。イテレーションの長さは、1週間か2週間にしておく。この期間を使って、顧客が最も価値が高いと思うものから順番に、ストーリーをテスト済みのちゃんと動くソフトウェアへと変換していく。
　開発チームはベロシティ(1回のイテレーションで完了させられるストーリーの量)を実測することで、自分たちのこなせる仕事量を把握できる。
　やるべきことがたくさんありすぎる事態に直面したら、やることを減らす。スコープを柔軟にしておく*3ことが、計画のバランス、やり遂げるためには大事だ。

とはいえ、できないものはできないということは現実にはある。なので、当初から顧客には隠し立てをせず、誠実に仕事を進めることが大事だ。顧客に事実をありのままに伝える。現在の状況について十分な情報を得た上で、スコープ、予算、期日の判断を下す。

感想
顧客が要求に対して誠実に、返してくれることが成功に繋がるということを最初から言わないといけない。判断が遅くなることはリスクだということを、共有しないといけないと思いました。
プロジェクトのToDoについては、なるべく経験値のある人にクロスレビューなどをしてもらうようにしたいところだと思う。自分よりも、経験値の高い人が周りにいないと思ったら一緒に仕事をしているメンバーでもいい。メンバーが意見をあまり言わないのであれば、自分がそのメンバーと実はあまりうまく行ってない予兆かもしれないと思った方がいいと思います。

「完了」とは完了のことだ「あらゆる作業」には、分析、設計、コーディング、テストそれからUXデザイン。こうした何もかもすべて含まれる。これは最初からオプション機能まで全部揃えろとか、各イテレーションで完成したばかりの機能を公開しろという意味じゃない。これは心構えの問題なんだ。もしお客さんから「じゃあリリースしてください」と言われたら、すぐにリリースできるように備えておくことなんだ。
つまり、蓋を開けてみるまでリリース可能かどうかわからないんだとしたら、動くソフトウェアこそが進捗の最も重要な尺度です。

感想
完了についてを、じっくり確認し、理解し共有できるところにいるのは、幸せだし完了することは、開発時の安心感に繋がる。

３つの真実

1. プロジェクトの開始時点にすべての要求を集めることはできない
2. 集めたところで、要求はどれも必ずといっていいほど変わる
3. やるべきこといつだって、与えられた時間と資金よりも多い

忘れてはいけないことは、やり方がたった１つなんでことはないだということだ。
　アジャイル開発に関する記事や書籍はどれも、それぞれの著者たちが、自分たちの実体験から学んだことを、ただ共有しているだけ。だから、本書を読んで、学んだことを実際に試してみてほしい。
　だが忘れてはいけないのは、どんな書籍も手法も、必要とするあらゆるものを用意することはできない。だから、自分の頭で考えるのをやめてはいけない。ひとつとして同じプロジェクトはない。確かに、いつも当てはまる原則、プラクティスはある*4。そうだとしても、その原則やプラクティスをどう適用するかは、プロジェクト固有の性質と、そのときの状況次第なんだ。

感想
ソフトウェア開発には、銀の弾丸がないと言われます。達人の達人たる所以は、同じプラクティスにこだわらないが、しかし、巨人の肩にはしっかり乗るなど、どんな状況になってもゴールを見据えることができることなのではないかと思いました。

第1章を読んだ感想
アジャイル開発と聞くといつも思い出すのは、「7人の侍」という映画です。時代は戦国時代頃に野武士の恐怖に怯える農村を、街でよせ集めた7人の侍が農民と一緒に野武士たちを倒すという内容です。寄せ集めのプロフェッショナル集団が、皆で試行錯誤しながら目的を達成するところと、コアメンバーが7人でメンバーが農民というのを考えると、大規模なシステム開発と被る部分がたくさんあるなあと、システム開発を初めてから余計にそう思うようになりました。つまり、アジャイル開発の本質は「探し続ける、考え続ける」ことが、どんな事にも当てはまる普遍の原則なのかもしれません。

*1:顧客がプロジェクトの中で実現したい事を記述した一覧表。本書独自の用語。スクラムではプロダクトバックログと呼ばれているものと同じ

*2:フィーチャは、ソフトウェアの機能、特性や特徴、性能目標、見た目や使い勝手など、いわゆる「売り文句」などを総称する言葉として使っている。要求仕様、機能要件、大機能、ユースケースといった言葉が指すものとよく似ているが、決定的な違いは、ソフトウェアを使う側の視点から記述している点である。フィーチャはユーザにとっての価値なので、たとえば性能目標やセキュリティといったいわゆる非機能要件も含まれる。

*3:プロジェクトで行う作業の範囲と、成果物に何を含めるかを定めたもの。

*4:http://agilemanifesto.org