この連載は、登場して20年が過ぎ、成熟期を迎えつつある「アジャイル開発」を解説します。アジャイル開発については、世の中にたくさんの書籍や情報があふれていますが、アジャイルコーチとして10年以上の現場経験をもとに、あらためて学び直したい情報を中心にまとめていきます。
第5回目のテーマは、「アジャイル開発の誤解」です。
この内容はUdemyで公開しているオンラインコース「現役アジャイルコーチが教える！半日で理解できるアジャイル開発とスクラム 入門編」の内容を元にしています。
よくある誤解： アジャイル開発はドキュメントを作らない
有名な誤解ですが、これは間違っています。
アジャイルマニフェストにも書かれているように、「ドキュメントよりも、動くソフトウェアを価値としよう」なので、ドキュメントを不要としているわけではありません。
よって、必要なドキュメントがあれば作ります。また、プロダクトの規模が大きくなればなるほど、必然的にコミュニケーションコストがかさむため、ドキュメントが重要になってくるでしょう。
それでは、アジャイル開発におけるドキュメントのイメージを持っていただくため、現場でよく見かけるドキュメントをいくつか紹介します。
- インセプションデッキ： アジャイル開発版のプロジェクト憲章のようなもので、プロダクトやプロジェクトにおいて、自分たちのチームは同開発を進めていくか？ チームの共通認識を生み出すための文書です。
- システム全体図： アジャイル開発は小さく開発していきますが、開発が進めば進むほどプロダクトは大きくなっていきます。ちょっとずつ組み立てていく過程を経験していれば、大きくなってもある程度理解できますが、途中から入ってきたメンバーにとっては、なかなか全体像が見えないものです。そういった場合、システム全体図のような高い視点のドキュメントが役に立ちます。
- 複雑な部分の仕様書： 仕様は全部整理しておきたいものですが、「仕様をドキュメントにまとめる」と決めた場合、それ自身が新しい仕事になります。そしてその仕事は、開発が続く限りずっと続いていきます。そのコストを払い続けても、それに見合ったリターンがあるなら良いと思います。もしそうといえないのであれば、まずは重要な部分の仕様書だけ整理しておくといいと思います。
- 振り返りのログ： アジャイル開発では、定期的にふりかえりを行います。そのときの学びをWikiやホワイトボードツールなどに残しておけば、過去の経緯や過去の学びが情報として溜まっていきます。
よくある誤解： アジャイル開発なら要件をいつでも変更できる？
これもよく見かける誤解です。
アジャイルソフトウェアの12の原則にも書かれているように、要求の変更はたとえ開発の後期であっても歓迎します。しかし、何でもかんでも変更していては、どんな開発でも進んでいかないでしょう。
変更するということは、その時点で再計画が発生するという意味でもあります。再計画無しの変更は無謀です。これも12の原則にもあるとおり、アジャイル開発であれば、無理や無茶がない、持続可能な開発を促進しなければなりません。
変化の多い現場であれば、開発サイクルを短くしたり、やることを小さくするといいでしょう。大きなものを大きなまま開発しているのであれば、アジャイル開発よりも従来型の方がやりやすいかもしません。
よくある誤解： アジャイル開発は優秀な人にしかできない？
筆者の回答は「誰にでもできる」です。
12の原則にあるように、アジャイル開発に必要なのは、意欲に満ちた人々です。意欲がないとはじまりません。
また、「試しにやってみよう」ぐらいの意欲だと失敗する可能性が高いです。きっかけとして悪くはないのですが、「必ず成功させよう」という意欲を持ったチームのほうが、成功率が高くなります。
優秀な人たちがチームにそろうといいことがありそうですが、個々の能力が高くても、チームの生産性が上がるわけでないという有名な研究結果がグーグルからも出ています。チームでの開発が主流のアジャイル開発では、個人の能力だけではだめで、チームという集団での知性が問われるのです。
よくある誤解： アジャイル開発は計画を立てない？
アジャイル開発でも計画を立てます。ただ、計画の立て方が従来型とは異なります。
アジャイル開発は短い期間で開発を繰り返します。小さいものを積み上げていく方法なので、全体像が見えにくいという欠点があります。よって、3ヶ月毎、半年ごと、1年毎、というように、中長期的なリリース計画やロードマップが必要になります。
注意したいのは、計画の解像度です。アジャイル開発は変化に対応していきたいので、従来型のようにかっちり計画をきめてしまうと、解像度は高まりますが、変化に弱くなります。変更があったときに、また解像度の高い計画を立てていては、スピードも出せません。
よって、アジャイル開発では、遠いものは見えにくいので低い解像度。近いものははっきりみえるので高い解像度・・・と、計画の解像度を変えて対応していきます。
つまり、遠くのものはざっくりと計画を管理し、現在に近づけば近づくほど解像度を高めていくのです。
よくある誤解： アジャイル開発は開発生産性を高める？
従来型でもアジャイル開発でも、開発生産性を高められます。よって、従来型よりアジャイル開発のほうが開発生産性が高いということはないと思います。
アジャイル開発は、従来型の開発生産性の考え方をあまり適用しません。考え方が異なる方法同士なので、導入が難しいためです。
そのかわりといってはなんですが、アジャイル開発では、ベロシティ（チームのアウトプット量）やリードタイム（アイデアがリリースされるまでの時間）といった別の指標を計測して、チームの状態を確認していきます。
よくある誤解： アジャイル開発にはプロジェクトマネージャは必要ない？
アジャイル開発でもプロジェクト型の開発を行っているチームは多いです。期限があるプロジェクトをやるというよりは、プロジェクトを繰り返しながら開発するイメージです。
アジャイル開発であろうと、チームの開発を運営は必要なので、プロジェクトマネジメントの考え方は大切だと思います。ただ、アジャイル開発は自律したチームですので、計画もチームで作り、進捗もチームで見ていくので、チームが自律してしまえば、プロジェクトマネージャーは必要なくなるかもしれません。
もし、現在が、プロマネという役割によってチームが管理されている状況だとすれば、アジャイルチームの目指す自律性を阻害している可能性があります。
よくある誤解： アジャイル開発では設計しない？
ソフトウェア開発において設計は重要な活動ですから、設計はします。
ただ、アジャイル開発は短い開発サイクルをまわしていくものなので、従来型のような明確な設計フェーズはないことが多いでしょう。
短い開発サイクルの中で、設計＞開発＞テスト・・・と繰り返していくイメージになりますが、これだと小さなウォーターフォールになってしまい、期間の最後にまとめてテストすることになり、期間分の手戻りリスクが発生してしまいます。
これを回避するために、機能 ＞ 機能 ＞ 機能 と、期間の中で小さな開発を繰り返していく方法をとっているチームが多いです。
よくある誤解： アジャイル開発にQAは必要？
従来型の開発の場合、作るべきものが明確なケースが多いので、品質を保証（Quality Assurance： QA）しやすいと思います。ここでいう品質は、仕様通り作られているかが中心になります。
アジャイル開発の場合、小さくリリースしたものに対するフィードバックを元に軌道修正していくので、「これは価値が大きい！」とリリース前に保証するのは至難の業です。ここでいう品質は、リリースしたものの価値の大きさが大きいほど品質が高いと言えます。
よって、アジャイル開発に従来型のQAという考え方を適用するのは難しいと思います。おそらく、網羅性の高いテストをリリースごとに繰り返していく形になるので、QAがフェーズになり、QAフェーズがボトルネックになる可能性が高いでしょう。
アジャイル開発には、アジャイル開発に適したテストや品質の考え方が必要です。まちがっても、速く作るからテストをすっとばそう！とはなりません。
よくある誤解： ユーザの価値、プロダクトの価値が重要？
最後の誤解は、「ユーザの価値、プロダクトの価値が重要」です。もちろん重要なのですが、注意したい点があるので、あえて最後に解説します。
たとえば、プロダクトを優先させるために、チームが犠牲になり、連日連夜デスマーチを続け、チームが疲弊して離脱者が増える・・・といったケースもたまに見かけます。
アジャイル開発では、持続可能な開発を大切にします。プロダクトを優先させすぎて、それ以外の価値や原則が歪んでしまっていないかを意識するようにしたいものです。何かを犠牲にして何かを達成するのは、決して持続可能な開発ではありません。
また、アジャイル開発はチーム開発が中心になりますが、チームだけでなく個人も大切です。こちらもチームのために、個人が犠牲になるようなことがないようにチーム運営していく必要があります。
よくある誤解： アジャイル開発を導入すればうまくいく？
世の中には「これを導入して売上UP」のような方法論やフレームワークがたくさんあります。たしかに、そういうベストプラクティスを駆使すれば、現状はよくなるかもしれません。
しかし、アジャイル開発は、成功を約束する方法論ではありません。あくまで成功率を高める手段です。
「アジャイル開発を導入したが良くならなかった」というケースがなくならないのは、この部分を誤解している可能性があります。
連載一覧
第1回：アジャイル開発の過去、現在、未来を知ろう！
第2回：声に出して読みたいアジャイルマニフェスト
第3回：従来型開発とアジャイル開発の違い その１
第4回：従来型開発とアジャイル開発の違い その２
第5回：アジャイル開発のよくある誤解を解いていこう！
第6回：世界中で大人気の秘密に迫る！スクラムを使ったソフトウェア開発
第7回：わかるようでわかりにくいスクラムチームの責任
第8回：スクラムイベントの実践方法
第9回：エクストリーム・プログラミングとその価値
第10回：エクストリーム・プログラミングの原則と基礎プラクティス
第11回：エクストリーム・プログラミングの応用プラクティス
第12回：リーンソフトウェア開発
第13回：ソフトウェア開発における「かんばん」
第14回：さまざまな方法論 − リーンスタートアップ・DevOps
