この記事の概要

「アジャイルサムライ」の第一部を読み、自分なりの解釈をまとめたものです。
アジャイルに詳しい方は、認識の誤りやご意見をいただけたらと嬉しいです。

第一部: アジャイルの基礎

この本の中では

お客さん（ビジネスサイド）と開発チーム（エンジニアなど）だけの世界観で話が進む。
アプリを使うユーザのことは含まれていない。

あくまで、効率的にアウトプットを出し続けるの方法論に関してフォーカスしている。

アジャイルの12原則

1. 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供する。

この顧客というのはプロダクトをよく使う人・プロダクトの未来を考える人（ビジネスサイド）。
短い期間で価値のあるアウトプットを出すためには必死に開発するというよりも、期間内にゴールするための方法を考えることに頭を回す。

2. 要求の変更はたとえ開発の後期であっても歓迎する。変化を味方につけることによって顧客（ビジネス）の競争力を上げる。

方針が変わった時のことを考慮してやりたいことを列挙しておく、ということがなくなる。（ストーリーの無駄を減らせる）
事前に完璧にするよりも必要に応じて調整しておくことが望ましいことを顧客と開発の両者が学べる。

3. 動くソフトウェアを、2-3習慣から2-3ヶ月という短い時間間隔でリリースする。

4. ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければならない。

開発において、ビジネス側の人はプロダクトのフィードバックや助言・見解を開発者に提供し、プロダクトを魅力的にすることが役割。
開発者はビジネス側の人からの信頼を得るためにも積極的に関わりビジネス・そのドメインの理解に努める。

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

権限によって仕事に制限をうむことなく、信頼して任せることで、自分たちの課題を自身で解決できるようになる。

6. 情報を伝える最も効率的で効果的な方法はFaceToFaceで話すこと

ユーザーストーリーという必要最低限で本質を捉えられるものをベースに対話することで本当に欲しているものを提供する。

7. 動くソフトウェアこそが進捗の最も重要な尺度。

タスクが完了したというのは品質が担保されていてそれがソフトウェアに反映されていること。

8. アジャイルプロセスは持続可能な開発を促進する。一定のペースを継続的に維持できるようにする。

一定のペースで成果物を提供することがなくてもそれを共有する。
- 開発側はその羞恥心から以降の開発の期限に対する強い意志を持つことができるようになる。

9. 技術的卓越性と優れた設計に対する普段の注意が機敏さを高める

どんどんリファクタをして、それを続ける
積極果敢にリファクタリングを続けることでプロジェクトが終盤になっても開発速度が落ちることがなくなる。
ソフトウェア開発で一番大変なのは設計をきれいに保つこと。
イテレーションの終わりにまとめてリファクタリングするのではなくて、毎日たゆまず行う。

10. シンプルさ（無駄なく作れる量を最大限にする）が本質

リリースの単位はMMF(Minimal Market Feature Set)
なるべく早いうちから成果を届けるために最小であること
市場価値のあるリリースであること

11. 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出される。

与えられた役割に心理的な制限を感じることなく、オーナーシップを持って積極的に関わる方がいいプロダクトを作れる。

12. チームが最も効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整する。

どんな問題が出てきてもメンバーが全力を尽くしたと信じる
どんな課題であっても共有する
振り返りを通して、集中力を取り戻す

アジャイル開発に必要なこと

大きな問題を小さくすること

短い期間に継続的に価値ある成果を提供するために、問題を小さく・シンプルにして、提供。

本当に大事なことに集中して、それ以外のことは忘れる

価値あるプロダクトを提供することに集中しよう。

仕様書や実施計画書は必要なものではあるけど、そこに集中しなくて良い。無駄なものは省く。
例えば、過度に精密な実施計画書は本当に必要とされているものではない。

ちゃんと動くソフトウェアを届ける

お客さんに提供するものが動かないんじゃ意味がない。品質は担保されていなければならず、その責任は開発メンバー全員に課せられる。

フィードバックを求める

お客さん（ビジネスサイド）の意見がプロダクトにとっての未来なので大切にする。

必要とあらば進路を変える

プロダクトの開発計画が変わることには柔軟に対応する。

成果責任を果たす

毎週成果を提供し続けようとすること。
メンバーは仕事の質に責任を持ち、スケジュールを守り、お客さんの期待を裏切ることがあってはならない。

アジャイルなメンバー

非アジャイル
- メンバーが役割ごとに縦割りになっている。
アジャイル
- 共通の目的達成を目指し何かに特化したメンバーという感覚。
- アジャイルな開発メンバーは誰もが顧客以外のどの役割を担ってもいい。

アジャイルな顧客（ラクマではビジネスサイド）

開発チームに確固たる指針を与え、質問に答え、フィードバックを与えてくれる存在。
要求の優先順位づけも行う。
ビジネスの戦略をになっていて、何を作るかを決めるのが仕事。
顧客が直に開発に巻き込まれているほどプロダクトがよくなる。

アジャイルなアナリスト

顧客と密接に協力しあい、彼らが本当に必要としているものを明らかにする。
タスク作りを手伝うこともあるし、実際にタスクをこなすこともある。

アジャイルなプログラマ

質の高いソフトウェアを生み出すことに誇りを持つ。
常にソフトウェアをリリース可能な状態にするために、テストをたくさん書く。
アーキテクチャの設計や改善は継続的に取り組む。
顧客にも密接に連携して何を作るべきかをはっきりさせ、できるだけシンプルに実現する。

アジャイルなテスター

プロジェクトの早い段階から参加している。
顧客の要求をテスト形式に書き出すのを手伝っていたり、テストの自動化やソフトウェアの不具合を一緒に探したりする
負荷テストやアプリケーションをクラッシュさせる方法を考え、高い品質を維持するために様々な観点から探索的にテストする。

アジャイルなプロジェクトマネージャ

プロジェクトを成功させるためには開発チームを成功させることだと心得ている。
チームの障害を取り除き、継続的に計画を立てる。
計画の見直しやプロジェクトの方向性の調整も行う。
開発チームに期待できることをマネジメントするのも仕事。
社内の人間関係を円滑にする。
自律的な開発チームを作るために環境を整える。

アジャイルなUXデザイナ

使いやすく、利便性の高い、魅力的な体験を顧客に提供することに心を砕く。
他のあらゆる作業に先立って全てをデザインしてしまうのではなく、フィーチャを実装するタイミングに合わせて少しずつデザインしてくれる。

その他の役割

スクラムマスター

チームが悪い習慣へ逆戻りしないようにアジャイル開発の原則や考え方をチームに説明し、メンバーが受け入れていくことを後押しする。
最後までやり遂げられるチームにするのが仕事。

アジャイルができそうなメンバー

ゼネラリスト
- いろいろな役割を担当できるような人
曖昧な状況に抵抗がない人
- 予め何も決まっていなくても貢献していける人
我を張らないチームプレーヤー
- 役割に固執してしまわないような人