アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料）
そもそもアジャイルって何だろう？
みなさんこんにちは。@ryuzeeです。
Q:あなたは以下のどの理由でアジャイルではないのでしょうか？以下から１つ以上選んでください。
- a デイリースタンドアップミーティングしていない
- b ペアプログラミングをしていない
- c TDDをしていない
- d 象徴となるような人を雇用していない
- e スクラムマスターがいない
- f イテレーション計画ミーティングをしていない
- g インデックスカードを使っていない
答えはHで、上のどれでも無いです。 プラクティスは「アジャイルであることを助ける」ための道具であって、それ以上ではありません。 アジリティの意味するところは、頻繁に継続的に顧客のニーズにあった高品質なソフトウェアを届けることができる、ということに他ならないのです。
以下いくつかよくある例や思ったことの補足をしておきます。
- RedmineとかTracとかJIRAとかRTCとかTFSみたいなWeb系のアジャイル支援ツール使っている＝アジャイルである、というわけではない。ツールは道具であり、価値の実現に寄与して初めて価値があるといえる
- したがって、自分たちにとって価値の実現に寄与できる！と思う機能は現場ごとにも違うだろうし、ツールの全ての機能を使う必要性はない
- ツールの機能は一般的に「最高にうまくいっているチームはこうしてるよ！」というモデルをベースにして開発されるので、チームの成熟度が低いうちにツール化に走ると、かえって混乱に陥る可能性もある。もちろんツールをうまく使いこなせると生産性はあがる
- TDDやCIやペアプロはウォーターフォールにだって適用できるし、やっている現場は多々ある。アジャイルにおけるプラクティスがウォーターフォールにおいて排他なわけではない
- 一気に完璧なチームができ上がるわけではなく、チームのアジリティの向上はプロジェクトを通じて改善のループを回して、反映していけるかどうかである
- 現状がうまくいっていても、もっとうまくいくかもしれない。改善をやめた時点で、思考停止→組織の力が衰退していく
- そういう意味でも、アジャイルな開発プロセスを、書面で標準化して守らせよう、というアプローチを全面的に採用しない方が良いだろう。マイクロソフトにおけるVisual Studioの開発は多数のチームから構成される大規模分散開発だが、最低限のルールと品質チェック項目（クオリティーゲート）以外については、各スクラムチームの裁量が多い
