アジャイル開発に組織が興味を持ったならどうすればいいか？

みなさんこんにちは。@ryuzeeです。

http://kaji-3.hatenablog.com/entry/2012/04/05/072641 にてこれから導入を検討されているkaji_3さんが悩みを書かれていたので、プロのコーチとして感想を書いてみたいと思います。

新プロダクト作成にアジャイル開発が有益ではないかと組織が興味を持ってきているため、会社にどのように導入していくか提案予定です。しかし、社内にアジャイルコーチなどいるはずもなく、テストの自動化すらできていない状況でどう進めていけばいいか悩み中です。ゴールは来年、から開発する新プロダクトにスクラムを適用する。。です。

まず新プロダクトにアジャイル開発が有益だと考えた理由をはっきりさせた方が良いでしょう。

従来型の開発では難しいと思った理由や、それが本当にアジャイルで解決できる(可能性が高い)ものなのか？そもそも現状の開発プロセスにどのような問題があるか把握していて、それを改善しようとしているか？といった点です。

ゴールはスクラムを適用することなのではなく、そのプロダクトを早くマーケットに投入し、早くビジネス上の価値を得ることであって、スクラムやその他の手法はその手段でしかありません。さらにいえばアジャイルな開発を行ったとしても必ずしもプロジェクトが成功するとは限りません（成功の定義は難しいですが、まずはビジネス価値の実現）。往々にしてアジャイルに対して銀の弾丸のようなイメージをもつケースが多いですが、アジャイルな開発は理論を学ぶのは難しくなくても実践するのはそれなりに難しいですし、はじめて行うような場合は苦労もするし、それでも続ける覚悟が必要になります。

それから新プロダクトの規模も重要なファクターで、アジャイル開発を初めてやるようなケースでいきなり複数チームでの開発を行うことは相当に難しいです。さらには分散とかオフショアとかが絡むとコーチなしで（コーチがいても）初めてでやるのはほぼ無理なのではないかと思います。

まずはFail FastやSmall Successの観点から小さめな実験的プロジェクトで経験を積むことは効果があるでしょう。

以下の事を1年かけてやろうと思うのですが、順序と優先度をどうすればいいと思われますか？ご意見をいただけると嬉しいです。今は以下の順序、優先度ならできるのではないかと考えています。

自分と数名がCSM研修に行き、スクラムについての知識を蓄積する。まずは正しい作法を習うため。あと、CSMを取得し組織内で「認定者がいる」という事実を作るためです。
予算を確保し勉強用プロジェクトでスクラムをやってみて知識の蓄積をする。正しい作法をならった上で、自分の会社でスクラムをやってみる。理想は勉強用プロジェクトを新規に立ち上げ、予算内で実施。予算が確保できないなら、導入ができそうなプロジェクト（そんなのあるのか？）に適用。
チームを作成するまえにテストコードの書き方の学習を蓄積する。最低限テストの自動化はある程度できるようになっておかないと定期的にリリースができないと思っているのでテスト自動化については別途メンバーに習得して貰う予定です。
組織に対して勉強会を設けて、理解を深めてもらう。スクラムってどうやるの、どんな方法で開発をしようとしているのをPMOなどに説明しようと思っています。そして会社としてOKが出るようにしたいなと。

僕がコーチとして関わる場合は、チーム全員に対して研修を行なって、その上で実際にスプリントを進めながら都度必要な知識やプラクティスを深堀りして教えていくスタイルが多いです。

チームの特定の人が十分な知識を持っていることは重要なことの1つではありますが、CSM研修にいきなり行っても実地での経験がないと十分に自分の腑には落ちないと思います。 2日間で学ぶのはスクラムの基礎やスクラムマスターとしての振る舞いについてですが、自分のコンテキストに合っているわけではなく、あくまで教科書的な話が中心です。そう考えると、まずは小さな案件で実際に試してみて、それを行なってから、もしくはその途中で、自分の経験を補完し補強するためにCSM研修にいった方が効果は高いんじゃないかと思います。

テストについては自動化しなければ継続的にリリースできないので、今からでもやれば良いでしょう。これはウォーターフォール型の開発だろうとアジャイル型の開発だろうと、プロダクトのライフサイクルが長ければ長いほどROIが高い取り組みになります。

組織に対しての説明はした方が良いでしょう。よく黙ってアジャイル型の開発を導入し、契約上や報告上はウォーターフォールでやっているというのを聞きますが、アジャイルな開発の基本はタイムボックスと要求を優先順位にしたがって実現すること、調整すべきはスコープ、という考えなので、いずれ従来型の考えとあわずに破綻します。なので、アジャイルな開発の基本思想を組織に理解してもらい、組織の協力を得ることは必要不可欠です。さらにはアジャイルは銀の弾丸ではないということももちろん伝える必要があります。変化への対応を拒む人は、自分の昔からのやり方がよく失敗するのを棚にあげてでも、新しい取り組みの1回の失敗をことさら強調する傾向があります。そうではなく、そもそも変化に対応できないと組織としてマーケットの中で生き残れないということも含めて、現状を理解し、変化への協力を得ていかないといけません。同じことが開発チームのメンバーに対しても言えます。「指示してくれないと分かりません」とか「言ったとおりにやります」とかいうマインドセットの人が多いとアジャイルな開発はなかなか大変です。

ということで僕の答えは3→4→2→1の順になります。テストについては今日からでもできるはずです。

それでは。