# KT#006-hokaguchi アジャイル開発のすゝめ
###### tags: `アジャイル`
## 参考
[アジャイルサムライ](https://www.amazon.co.jp/dp/B00J1XKB6K/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1)
↑かなりおすすめ。スラスラと読める。サクッと理解したい人は[【図解サマリ】アジャイルサムライを読んだので紙芝居にまとめました](https://qiita.com/osapiii/items/753d21e2944fd72d89a7)を見るといい。

## アジャイル入門編
アジャイルとはソフトウェア開発の進め方の1つ。ざっくり説明すると、短い単位で設計・実装・テストを繰り返し開発を進めていくやつ。
アジャイル開発では、**価値ある成果を定期的に届ける**ことをベースとしている。価値ある成果を定期的に届けるために大事なこととして、本書では6つの大事なことを述べている。
1. 大きな問題を小さくする
2. 本当に大事なことに集中して、それ以外のことは忘れる
客が本当に必要としているものは価値のあるもの。それは動くソフトウェアだったり、従来課題を解決しているソフトウェアだったり。その上で無駄なものは省いて必要なことだけに集中しようねって話。
3. 動くソフトウェアを届ける
4. フィードバックを求める
5. 必要とあらば進路を変える
これは、現実を変えるのではなく、計画を変えるということ。後述。
6. 成果責任を果たす

これらを踏まえた上で、顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供することがアジャイル開発での原則。なおかつ以下の点を認めながら開発に望む必要あり。
- プロジェクト開始時点ですべての要求は集まらない
- 集めたところでだいたい要求は変わるもんだ
- やるべきことはいつも時間+資金より多いもんだ

アジャイル手法のフレームワークとして、スクラムとか、エクストリーム・プログラミングとか、リーンとかがある。今回はこのへんの内容は割愛する。

## アジャイル第一歩
### アジャイルチームの特徴
アジャイルチームに見られる特徴は次の3つ。
1. 役割分担が明確でない
肩書、役割関係なく、プロジェクトの成功に寄与することならなんでもすることを軸とする。ただ、人それぞれにも強みはあるし、得意分野に傾倒することもある。細かく役割を定義せず、ざっくりと用意しておくのであればOK。

2. 開発工程の連続的な取り組み
分析、設計、実装、テストといったような開発工程がどれも途切れることなく取り組まれることが特徴。逆に言えば、プロジェクトの途中で終わる開発工程がない。チームメンバーで各開発工程を密接に連携し、作業する必要がある。

3. チームが一丸となって成果責任を果たす
各人が成果責任を果たすことに気を配る必要がある。理由として、アジャイルなプロジェクトには品質保証部門なんてものは存在しないから、確かな品質を達成するのは各人の仕事になる。

### チームをアジャイルにするコツ
1. 同じ仕事場で働けよ
チームの生産性をあげる一番の方法はなんだって聞かれたら、同じ仕事場で働けよ、って書いてた。質問があればすぐに答えてもらうし、問題があってもすぐに直せる。意思疎通における摩擦も減るから信頼関係も豊か。ただ、この本にも記載があるが、みんなが顔を知っている状態であれば、なんでもいいらしい。ビデオツールもよし、チャットツールでもよし、あたかも同じ環境で働いている感覚であればいい。

2. 顧客は積極的に関われよ
顧客が積極的に関わらないプロジェクトは地獄。プロジェクトにおいて顧客は重要な存在になる。じゃあその顧客の役割はなにかというと、デモを見に来る、質問に答える、フィードバックしてくれる、等。アジャイル開発では短期間構成の開発工程を含んでいるため、顧客が積極的にフィードバックしてくれなければ成立しない(これは外口的考察)。顧客が思っていたものと違うのであれば舵取りを変える必要があるし、作った上で新しい課題があり、それの優先順位が高ければマスタストーリーリストだって変わる。これを繰り返していくうちに顧客との信頼関係も築けるし、顧客も親身になってフィードバックしてくれるようになるだろう。

3. 自己組織化しろよ
かんたんに言うと、エゴを出しすぎるなよ、って話。各々がチームの一員として、どう振る舞えば最善の成果を客に届けるかを考え抜くことが大事。チームを自己組織化するコツとして、「自分たちで計画をたて、当事者意識をもつ」「肩書や役割は気にしない」「自ら動ける人を探す」を挙げている。

4. 成果責任と権限委譲しとけよ
さっき言ったとおり、チームが一丸となり成果責任を果たす必要がある。成果責任を果たせるようになるためには、権限が開発チームにちゃんと渡されてることが大事。そうすればチームは自発的に自分のやり方で動くようになる。許可なんて待つ必要はない。ヘマをやらかすっていうリスクもあるが、その見返りも大きい。

5. 職能横断型チームをつくれよ
客の要望に最初から最後まで応えられる開発チームになれよって意味らしい。これを実現するには、チームに適切なスキルと専門知識が備わっており、客が必要とするフィーチャを届ける必要がある。

### 役割分担Tips
役割を明確に決める必要はない。何を作るべきか分かっている人(顧客)とそれを作れるひと(開発チーム)がアジャイル開発にはいるだけである。本書では一応役割を出してるが、ちゃんとチームにその役割が割り当てられてるかどうかとかは気にしていない。その役割によって果たされる仕事が誰かによってこなされてるかどうかが大事。以下に役割例の図を置いておく。

- 顧客

- アナリスト

- プログラマ

- テスター

- プロジェクトマネージャ

- UXデザイナ

## アジャイルな舵取り
### プロジェクトを失敗させないために
プロジェクトがダメになる理由として、「答えるべき問いに答えられない」「手強い質問をする勇気を持てない」ってのを本書では挙げている。ここでの「答えるべき問いに答えられない」というのは、その成功について思い描く姿が人それぞれ異なっている、ということを意味してるっぽい。これの問題は、プロジェクトの開始時点で関係者の認識が揃っていないことではなく、関係者全員でプロジェクトについて話し合うことより前にプロジェクトを始めることだと述べてる。
こうならないためにも、ゴールやビジョン、背景についてよく話し合っておくこと、ステークホルダーに情報を提供することが必要である。さらにさらに、これを実現するためには、手強い質問をする必要がある。これは、始めた段階であれば終盤と違っていろんな質問をする余裕があり、それによってストーリーも変わりうる、というところに基づく。一応質問例載せておくが、あまり直結しなかった...
- どれくらい経験を積んでるチーム？
- この仕事の経験はある？
- プロジェクトを統括するのは誰？
- 2人のアナリストに30人のプログラマという体制で問題ないとでも？
- 過去プロジェクトでオブジェクト指向の経験がほとんどない新人開発者ばかりのチームを率いて、レガシーなシステムをアジャイル手法を使ってリプレイスするのを成功させた事例はある？

### インセプションデッキ
じゃあプロジェクトが失敗しないよう、プロジェクトに対する期待をマネジメントするツールとしてインセプションデッキというのを以下で紹介する。どこまで使えるかどうかは未知数。以下の10個の質問&課題から構成されてる。

デッキを並べると、このプロジェクトが何であり、何でないのか、また価値を届けるためにはどこに力を注ぐべきか、が分かるらしい。本書では、プロジェクトに関わる人全員を巻き込んで作ることが大事らしい。この10の質問に関する具体的な説明はQiita参考でオナシャス。ここでは10個あるとどうなるかを書いていく。

- 我々はなぜここにいるのか？
要はなぜこのプロジェクトを進めていくことになったのかを話す。どちらかというと顧客要素が多いと思ってる。この「なぜ」をちゃんと理解しておくと、
- より的確な判断を下せる
- 対立点やトレードオフのバランスを保てる
- 自分たちで考える権利が与えられてるので、斬新な解決案を生み出せる

といった振る舞いができるっぽい。こいつを理解するために、「自分自身が現場で確かめる」こと、「司令官の意図を掴む」ことが大事らしい。正直前者はきちい。「司令官の意図」は、プロジェクトのゴールを簡潔な言い回しや声明として表現したもの。これがあると、土壇場で攻め引きの決定を下す指針として役に立つ。
この課題で大事なのは、「我々はなぜここにいるのか？」への答えに対する理由が何なのか話し合うこと、そしてその認識が客とあっているか確認することにある。

- エレベータピッチを作る
語源の由来がおもしろいので口述。ごく短い時間でアイデアの本質を伝えると、明快になり、チームの意識を顧客へ向けさせ、核心を捉えることができる。うまく作れない人はテンプレもあるらしいのでぜひ。

- パッケージデザインを作る
もし仮に自分たちのプロダクトがスーパの棚に並ぶとすると、どんな商品パッケージになってると思う？そんでそれを見て買いたいと思うか？ということらしい。買う人目線に立ってみて、買うとしたらその理由を考えてみる。買い手に訴求している要素は何かとか、プロダクトの値打ちは何なのかとか。

- やらないことリストを作る
何がプロジェクトのスコープ内で何がスコープ外なのか明確化すると、客がプロジェクトに期待することを把握させるだけでなく、開発側が本当に重要なことだけに集中できる、ということもある。

- ご近所さんを探せ
予め知り合っておかないと、「途中から入ってきてコイツ誰やねん」みたいになってスケジュールが台無しになることもあるっぽい。助け舟を出す前から声をかけておくと、何かあってもよそ者扱いされなくなる。

- 解決案を描く
ここからはプロジェクトのHowについて。解決案が目に見えるようになると、技術的な課題がわかりやすくなり、解決策が実現手順として適切か確認できる。ざっくりとシステムを図で書き、どこにリスクがあるか明確にすること、そして解決策に同意しているか確認することが必要。

- 夜も眠れなくなるような問題は何だろう？
先にやべーってなりそうなことを整理しておこう、みたいなスタイル。こいつを早い段階で整理しておくと、プロジェクトの課題を早い段階で明らかにできるし、不安感情を分かち合うと単純にすっきりする。もちろん、取り組む値打ちのあるリスクは何なのか選別する必要はあるけども。

以下3つは今はあまり関係なさそうなので省略。
- 期間を見極める
- 何を諦めるのかをはっきりさせる
- 何がどれだけ必要なのか？

## アジャイルな計画づくり
外口的にはこれ大事だと思ってる。ユーザストーリー(ToDo)、見積もり、現実に合わせて変えられる計画の立て方について載ってる。アジャイル開発では、絶対に文書化しろ、とは言わないらしい。理由として、
- 変化に対応できない
- 客の欲しい物に合わせるのではなく、仕様に合わせて作ることになる
- 下手な憶測や誤った前提を招き寄せる
- 多くの時間を無駄にする

とか。文書に頼りすぎてはいけない(外口的にも同意)。

### ユーザストーリーやろうぜ
ユーザストーリーは、客がソフトウェアで実現したいと思っているフィーチャを簡潔に記述したもの。大事なことは、フィーチャの本質を捉えるキーワードを書き留めること。フィーチャを思いついたばかりの時点では本当に必要になるかどうかはわからないから。後で本当に必要になったら詳細に突っ込めばいいらしい。

ユーザストーリーの特徴として、客にとって何かしらの価値が書かれていることが挙げられている。ユーザストーリーはビジネスの観点から評価できないといけない。技術用語を使っても客はわからないので。もう1つの特徴は、EndtoEndで書かれてること。HTMLだけとか、Javaだけとか、SQL Serverだけとか小出しに提示しても客は嬉しくない。全レイヤ一貫した書き方が必要。ユーザストーリのいい書き方として、
- 独立している(Independent)
- 交渉の余地がある(Negotiable)
- 価値のある(Valuable)
- 見積もれる(Estimatable)
- 小さい(Small)
- テストできる(Testable)

があるらしい。

## とりあえず
今回はここまで。こっからは実際に始まってからのことだと思うので、別日で話せれば。