この連載は、登場して20年が過ぎ、成熟期を迎えつつある「アジャイル開発」を解説します。アジャイル開発については、世の中にたくさんの書籍や情報があふれていますが、アジャイルコーチとして10年以上の現場経験をもとに、あらためて学び直したい情報を中心にまとめていきます。
第5回目のテーマは、「アジャイル開発の誤解」です。
この内容はUdemyで公開しているオンラインコース「現役アジャイルコーチが教える！半日で理解できるアジャイル開発とスクラム 入門編」の内容を元にしています。
よくある誤解： アジャイル開発はドキュメントを作らない
有名な誤解ですが、これは間違っています。
アジャイルマニフェストにも書かれているように、「ドキュメントよりも、動くソフトウェアを価値としよう」なので、ドキュメントを不要としているわけではありません。
よって、必要なドキュメントがあれば作ります。また、プロダクトの規模が大きくなればなるほど、必然的にコミュニケーションコストがかさむため、ドキュメントが重要になってくるでしょう。
それでは、アジャイル開発におけるドキュメントのイメージを持っていただくため、現場でよく見かけるドキュメントをいくつか紹介します。
- インセプションデッキ： アジャイル開発版のプロジェクト憲章のようなもので、プロダクトやプロジェクトにおいて、自分たちのチームは同開発を進めていくか？ チームの共通認識を生み出すための文書です。
- システム全体図： アジャイル開発は小さく開発していきますが、開発が進めば進むほどプロダクトは大きくなっていきます。ちょっとずつ組み立てていく過程を経験していれば、大きくなってもある程度理解できますが、途中から入ってきたメンバーにとっては、なかなか全体像が見えないものです。そういった場合、システム全体図のような高い視点のドキュメントが役に立ちます。
- 複雑な部分の仕様書： 仕様は全部整理しておきたいものですが、「仕様をドキュメントにまとめる」と決めた場合、それ自身が新しい仕事になります。そしてその仕事は、開発が続く限りずっと続いていきます。そのコストを払い続けても、それに見合ったリターンがあるなら良いと思います。もしそうといえないのであれば、まずは重要な部分の仕様書だけ整理しておくといいと思います。
- 振り返りのログ： アジャイル開発では、定期的にふりかえりを行います。そのときの学びをWikiやホワイトボードツールなどに残しておけば、過去の経緯や過去の学びが情報として溜まっていきます。
よくある誤解： アジャイル開発なら要件をいつでも変更できる？
これもよく見かける誤解です。
アジャイルソフトウェアの12の原則にも書かれているように、要求の変更はたとえ開発の後期であっても歓迎します。しかし、何でもかんでも変更していては、どんな開発でも進んでいかないでしょう。
変更するということは、その時点で再計画が発生するという意味でもあります。再計画無しの変更は無謀です。これも12の原則にもあるとおり、アジャイル開発であれば、無理や無茶がない、持続可能な開発を促進しなければなりません。
変化の多い現場であれば、開発サイクルを短くしたり、やることを小さくするといいでしょう。大きなものを大きなまま開発しているのであれば、アジャイル開発よりも従来型の方がやりやすいかもしません。
よくある誤解： アジャイル開発は優秀な人にしかできない？
筆者の回答は「誰にでもできる」です。
12の原則にあるように、アジャイル開発に必要なのは、意欲に満ちた人々です。意欲がないとはじまりません。
また、「試しにやってみよう」ぐらいの意欲だと失敗する可能性が高いです。きっかけとして悪くはないのですが、「必ず成功させよう」という意欲を持ったチームのほうが、成功率が高くなります。
優秀な人たちがチームにそろうといいことがありそうですが、個々の能力が高くても、チームの生産性が上がるわけでないという有名な研究結果がグーグルからも出ています。チームでの開発が主流のアジャイル開発では、個人の能力だけではだめで、チームという集団での知性が問われるのです。
続きを読むにはログインが必要です。
ご利用は無料ですので、ぜひご登録ください。
