前回は1章についてまとめました。

引き続き2章についてまとめていきたいと思います！

• 典型的なアジャイルチームの姿
• 自分のチームはどう構成すべきか
• チームに入る際の心構え

アジャイルプロジェクトの特徴

1. 役割分担ははっきりとわかれていない
2. • プロジェクトを成功させるためになんだって協力する。肩書き役割関係なし
   • 強みをいかすのもいいが、自分の強みにこだわりすぎることもある。役割を細かくきめないことでこれを回避する。　
2. 開発工程がどれも、途切れることなく連続で続く
3. • 分析 → 設計 → 実装 → テストの工程が他の工程から独立して行われない
   • メンバーがそれぞれの工程を密接に連携させながら作業を進める。
3. チームが一丸となって成果を出すという考えを重視している
4. • 品質に責任をもつのはチームである。品質保証部門なんてない。
   • 担当がなんだろうが、品質も達成するのは自分の仕事である。
   • 「あいつのせいで、こんなバグを見逃した」という声はあがらない。

チームをアジャイルするためのコツ

上記のような特徴のチームを実際に作り上げるのは、難しいと思うかもしれない。
でも、挑戦してみる価値のあることはある。

• 同じ仕事場で働く
  本書では、「チームの生産性を劇的に改善できる方法をひとつ挙げるとしたら」、
  全員が同じ職場に集まって働くことと記載がある。
  理由:
  じゃあ、物理的に分散していたらどうするの？
  本書では、プロジェクト開始前や１週間に一度など定期的に集まれと書いてある。
  実際に会うことが、高いパフォーマンスを出すチームを作るためには欠かせないのかもしれない。
  ただし定期的に会う機会を前提に、Slackのハドルなどのソーシャルメディアツールを活用すれば、
  実際に会っていると同等の働き方になるようです。
  「分散チームの壁をSlackやハドルで超える工夫も紹介されていましたが、やはり物理的な近さには勝てない部分も多いですね。今のプロジェクトでは、メンバーリモート出社の日を合わせているので、続けていきたいです。」
• • 質問があればすぐに答えてもらえる
  • 問題があってもすぐに直せる
  • 意思疎通の摩耗も減る
  • 信頼関係を築きやすい
• 積極的に深く関わる顧客の存在
  顧客が積極的に関わらないチームによって開発されているソフトウェアはたくさんあるが、犯罪的である。

重要な原則・概念

1. BizとDevはプロジェクトを通して一緒にはたらかなければならない。
2. • ビジネス担当者（Biz）と開発者（Dev）は、プロジェクト全体を通じて毎日密に協働しなければならない。
   • アジャイルの4番目の原則として定められている。
2. 自己組織化
3. • 自己組織化されたチームからは最良のアーキテクチャや要件、設計が自然に生まれる。
   • アジャイルの11番目の原則に裏付けられている。
3. 意欲に満ちた人々を集めてプロジェクトを構成する。
4. • 意欲のあるメンバーに適切な環境と支援を与え、終わるまで信頼して任せることで成功に近づく。
4. 職能横断型チーム
5. • クロスファンクショナル（職能横断型）チームとして、ビジネス側からの「アジャイルな顧客」や「アナリスト」「プログラマ」「テスター」「PM」「UXデザイナー」など多様な役割が組み合わさることで、外部依存なく価値を完結させる。

役割分担

1. アジャイルな顧客（Product Owner）
2. • ステークホルダーの声を代表し、バックログの優先順位付けやフィードバックを継続的に行う。
2. 職能横断的な開発チーム
3. • 設計・実装・テストなど必要なスキルをチーム内で完結できるように、プログラマ、テスター、UXデザイナーなどを含む。
3. アジャイルなアナリスト（Business Analyst）
4. • ビジネス要件をユーザーストーリーに落とし込み、開発側とのコミュニケーションを円滑にし、バックログを整備。
4. アジャイルなプログラマ（Programmer）
5. • アジャイルプログラマは情熱的なテスターのような人物
   • 自分の仕事に誇りを持つ
   • 常に質の高いコードを生み出すための高みを目指す。
   • ペアプログラミングや継続的インテグレーションなどの技術を駆使し、迅速に実装。
   • 当然顧客と連携して仕事を行う。
5. アジャイルなテスター（Tester）
6. • テストファーストや自動テストを用いて、早い段階でフィードバックを提供。
   • ソフトウェアはちゃんと動いてこそ意味がある
   • ユーザーストーリーがどうなればうまくいっているかを前もってテストとして定義できればすぐにテストできる
   • アジャイルでは何もかもテストしなければならない。
6. アジャイルなPM（Project Manager / Scrum Master）
7. • プロジェクトを成功させる＝開発チームを成功させること
   • チームの障害除去やプロセス改善を支援し、自己組織化を促進。
   • 関係者へ状況を報告して、社内の人間関係の円滑化。
   • 有能なマネージャーなら誰でもアジャイルに関わらずやっている。
   • マネージャーが手助けすることは環境を整えること。
   • １週間いなくても、大丈夫な状態にする

その他、役割もたくさんあるが、すべての役割が開発チームに含まれ同様に扱われる。

チームメンバーを探すコツ

高いパフォーマンスを発揮するアジャイルチームで働くことをほとんどの人は楽しめるはず
その資質を探すメンバーを探すコツは？

• ゼネラリスト
  ゼネラリストはアジャイルに向いている。
  プロジェクトの最初から最後まで自らの力を発揮することである。
  ゼネラリストはさまざまな帽子を被ることに慣れている。
• 曖昧な状況に抵抗がない人
  あらかじめ何もかもがしっかりきっちり整っていることはない。計画は変わる。
  この状況に適用できなければならない。
  野球で例えると、ストレートを待っていて、カーブを投げられても対応できるような人がよい。
• 我を張らないチームメンバー
  我を張らないチームメンバーで構成されていることが、うまくいく条件。
  誰しもが曖昧な役割分担を気にいるわけじゃない。でも、この役割は俺の役割だと、固執する人もいる。
  お互いに学び合って成長することを心から楽しめる人を探す。

アジャイルチームがうまくいくには、役割の特徴だけでなく、メンバー自身にも柔軟性や主体性といった資質が求められることがわかりました。
2章で学んだ「肩書きにとらわれず協力する」「自己組織化を意識する」「顧客と密に連携する」といったポイントを忘れず、チームに貢献できる存在となるよう行動し続けたいです。

参考文献
Rasmusson, Jonathan. 2011. アジャイルサムライ――達人開発者への道. 西村直人, 角谷信太郎, 近藤修平, 角掛拓未 訳. 東京：オーム社.