「アジャイルとは？」については色々な方が説明されていますが、自分の言葉で説明できるように言語化しておきたいって思ってこの記事を書いています。アジャイルに関する書籍やそれ以外の書籍を読んだり、スクラムを実践した中で僕なりの「アジャイルとは」についてまとめておきます。
上記にも書きましたが、アジャイルは色々な方が説明されていて人によって説明が異なることがあります。この記事も僕が考えていることをまとめた記事です。この記事だけでなく色々な方の「アジャイルとは？」を知ることで理解が深まると思いますし、この記事がその手助けになればとてもとても幸いです。
アジャイルとは顧客に寄り添いながら継続的に学習している状態
アジャイルといえば”スクラム”や”XP”や”カンバン”が有名ですが、それらはアジャイルであるための一つの手法で「アジャイル」とは異なります。アジャイルは特定の開発手法を指すものではありません。では、アジャイルとは何なのでしょう。
アジャイルとは、顧客に寄り添いながら継続的に学習している状態だと考えています。
もう少し具体的にしていきましょう。
アジャイルは2001年に宣言されたアジャイルソフトウェア開発宣言(アジャイルマニフェスト)から始まります。
アジャイルソフトウェア開発宣言
従来の計画重視な開発手法と異なる開発を進めていた17名が集まってお互いの共通する価値観をまとめたものがアジャイルマニフェストです。
アジャイルソフトウェア開発宣言
私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。
Kent Beck、Mike Beedle、Arie van Bennekum、Alistair Cockburn、Ward Cunningham、 Martin Fowler、James Grenning、Jim Highsmith、Andrew Hunt、Ron Jeffries、 Jon Kern、Brian Marick、Robert C. Martin、Steve Mellor、Ken Schwaber、 Jeff Sutherland、Dave Thomas
© 2001, 上記の著者たち
この宣言は、この注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい。
このとおり、アジャイルマニフェストは具体的な手法を定めたものではなくて私たちは左よりも右を重視して開発してますという宣言です。「(左)よりも(右)を」の項目は4つあり、それぞれに共通する大切なことがあると思っています。
よりよい開発方法を見つけだそうとしている
継続的によりよくするための共通の価値観が「(左)よりも(右)を」の項目なんですね。そして、よりよい開発方法を見つけるために必要なことは学習です。
アジャイルの学習とは
よりよい開発方法とはなんでしょうか。残念ながら答えはありません。そもそも、よりよい開発って「今よりよい」だから終わりがありません。
だから、継続的な学習が必要だと思っています。
従来の計画重視な開発手法は開発初期に計画と作るモノを決めて作ります。ユーザーの欲しいものが分かっている場合はこの手法でいいと思います。
しかし、ユーザーの欲しいものが分からない場合は何を作るか決められないため(決めたとしても、あっているかどうか分からないため)仮設を立てて検証する必要がでてきます。「プロトタイプを作り、ユーザーに使ってもらい、製品にフィードバックする」を繰り返すのです。そして、これがアジャイルに必要な学習です。分からないことを学ぶのです。
何か新しいフレームワークやツールを使うことがアジャイルではなく、開発しながら学習することがアジャイルなのです。そして、効果的な学習をするために様々なフレームワークやツールがあるのです。*1
そして、その学習はユーザーに価値を届けるために行うのです。自分たちのためではなく、上司のためでもなく、ユーザーに価値を届けるために行うのです。顧客に寄り添いながら継続的に学習するのです。
「ふりかえり」は学習するために立ち止まる場
学習、学習と言ってきましたが、じゃあどうやって学習するのか。その方法の一つが「ふりかえり」です。ふりかえりは「KPT」が有名ですね。それ以外にも色々な方法があります。このブログでもいくつか記事にしています。
ふりかえりに喜びをプラス「KJPT」 - はんなりと、ゆるやかに
僕なりの Fun Done Learn の進め方 - はんなりと、ゆるやかに
また、「ふりかえり」は @viva_tweet_x さんのブログがとても参考になります。私もよく参考にさせていただいています。
viva_tweet_x - Qiita
特に、以下の記事はふりかえりの手法84個が整理されていて圧巻です。
ふりかえりを拡張する「ふりかえりチートシート」 - Qiita
「ふりかえり」は大きく分けると2種類あると思います。「作った製品」のふりかえり、「開発プロセス」のふりかえり。この両面をふりかえることがよりよい開発に近づく方法です。
早く学習する
開発が終わった後にふりかえりをするケースがあると思いますが、もったいないと思います。開発終わりに「あれが良かった」「あれが悪かった」「次はこうしよう」と話すなら、開発中にふりかえって今の開発をよりよくしたほうが良いです。そのため、ふりかえりは定期的に実施しましょう。
スクラムは学習が組み込まれたプロセス
アジャイルは学習が大切だと書いてきました。アジャイル開発で有名な「スクラム」は学習がプロセスに組み込まれているので紹介していきたいと思います。スクラムガイドにスクラムイベントと呼ばれる5つのイベントが書かれています。
(プロダクトバックログリファインメントもイベントだと思うのですが、スクラムガイドのイベントの項目にはなかったので省略します)
スプリント・・・固定された期間(例：1週間)。この期間を単位に開発を進める。
スプリントプランニング・・・スプリントで開発する機能を計画する場
デイリースクラム・・・スプリントプランニングで決めた機能がスプリント期間中に完成するか確認する場
スプリントレビュー・・・スプリントで開発した機能をレビューする場
スプリントレトロスペクティブ・・・スプリント中の開発の進め方についてふりかえりする場
デイリースクラム、スプリントレビュー、スプリントレトロスペクティブは学習する場です。スプリントプランニングは学習した結果を反映する場、そして、スプリントはこのサイクルを早く回せるように短い期間で設定されています。
学習せよ！だけでは難しいですよね
アジャイルとは顧客に寄り添いながら継続的に学習することだと書いてきました。アジャイルは具体的な手法ではないので「アジャイル開発しよう！」と意気込んでも「じゃあ、どうすれば？」となると思います。その答えも現場によると言われると煙にまかれた気持ちにもなるかもしれません。
でもやっぱり、より良くする答えは現場にあると思います。
ヒントは外にたくさんありますよ。書籍やブログに情報はたくさんありますし、探すと勉強会もたくさんあります。スクラムだったり、XPだったり、カンバンだったり、アジャイル開発として語られる手法はたくさんありますし、開発に欠かせないチームをよくする方法もたくさんあります。
しかし、その方法だけ憧れて取り入れると現場の仕組みと相性が悪く上手くいかないこともあります。そして、「アジャイルはうちには合わない」ってなってしまいます。
まずは現場と向き合って課題を探すことがスタートかなと思います。
アジャイルマニフェストにリンクが張られているアジャイルソフトウェアの12の原則(アジャイル宣言の背後にある原則)もヒントになると思います。
