アジャイルソフトウェア開発の導入

私がKRAYでアジャイルソフトウェア開発の布教活動を始めて、そろそろ１年になります。組織のアジャイル度はまだまだ成長中ですが、アジャイル開発導入の経験を話すと興味を持って聞いてくれる人が何人もいました。そこで今日は、アジャイル開発の導入について、その段階と課題を、KRAYの例を使って紹介します。

何から始める？

スクラムやXPといったアジャイル開発のフレームワークには、組織のあらゆる部分に関わる様々なプラクティスが含まれています。例えば、朝会、イテレーション計画ミーティング、ふりかえり、テスト駆動開発、継続的インテグレーション、ペアプログラミング、完了の定義、ユーザーストーリー、リリースバーンダウンチャート、バックロググルーミングなどです。

断言しますが、それらのプラクティスを全て一度に導入することはできません。そんなことをすれば、プラクティスに意識を取られ、関係者の理解度の違いから混乱がおき、全く開発は進まないでしょう。組織をアジャイルにするには、必ず段階を経なければなりません。アジャイルコーチ、あるいはエバンジェリストは、何から始めるか決めることになります。

KRAYでは、ふりかえりとユーザーストーリーから始めました。ふりかえりは定期的な反省会みたいなもので、ユーザーストーリーは要件定義のやり方の一つです。「定期的な」と書きましたが、定期的に繰り返すことはふりかえりのルールではなく、アジャイル開発そのものの原則です。よって厳密には、定期的な反復も最初に導入したと言えます。

ふりかえり

ふりかえりでは、参加者が１回の反復（イテレーションやスプリントと呼ばれる）を思い返し、うまく行った点や問題点を挙げ、次のイテレーションでどうすべきかを考えます。例えば誰かが問題に気づきながらそれを周囲に知らせるのが遅れたのであれば、次のイテレーションでは問題を共有する機会を増やすなどの改善策を取れます。つまりふりかえりは、新しいことを導入するちょうど良い機会として機能します。

ふりかえりにこのような機能があるため、最初にふりかえりを導入することで、他のプラクティスを導入していく原動力となります。しかもそれは誰かがやらせるのではなく、関係者が話し合って、同意を得た上でやることになります。このときアジャイルコーチは、参加者を誘導するような介入をすべきではありません。ただ参加者が問題点に気づいていながら、その解決策を見いだせない時、自分の引き出しからいくつか選択肢を提示してあげることは大切でしょう。誰かにやらされるプラクティスは、効果が激減してしまいます。

ここまでふりかえりの当事者を単に「参加者」と書いてきましたが、参加者にも何種類かの立場があります。スクラムの定義で言えば、チームとプロダクトオーナー、それにスクラムマスターです。チームは開発を担当する人たちで、ふりかえりの主役です。プロダクトオーナーは開発している製品やサービスのビジョンと要件に責任を持つ人ですが、プロジェクトによって別の立場（例えば管理職、営業、顧客など）を兼務することが多く、その組織へのアジャイルの浸透度や、プロジェクトの方針によってふりかえりに参加するかどうかが異なります。スクラムマスターは組織とプロジェクトをアジャイルにすることが仕事ですので、アジャイル開発の導入を進めている段階であれば参加すべきでしょう。

ふりかえりの参加者によって、次に導入できるプラクティスは変わってきます。チームだけのふりかえりであれば、チームだけで導入できるプラクティスが進んでいきます（そういうプラクティスが比較的多くあります）。逆にアジャイルの導入に積極的なのがプロダクトオーナーであれば、チームのプラクティスの導入には困難が伴うでしょう。いずれの場合でも、遅かれ早かれアジャイル開発に積極的でない人がボトルネックになる段階が来ます。その時が組織のなかでアジャイルを広める機会になり、初期からのアジャイル実践者の働きかけが次の段階への鍵になりますが、その話はこの章の範囲を越えますのでまた別の機会に。

まとめると、ふりかえりは次のプラクティスを導入する機会になり、それは当事者が決定します。アジャイルコーチは選択肢を提供します。具体的なふりかえりのやり方については、オブラブのふりかえりガイドなどが参考になります。

ユーザーストーリー

ユーザーストーリーは、製品やサービスの個々の機能が具体的にどのように利用者の役に立つのかを描写したシナリオです。例えばワープロであれば、「見出しだけを表示して文書のアウトラインを確認できる」というユーザーストーリーがあるかもしれません。アジャイル開発における要件は、原則として全てユーザーストーリーで記述します。ユーザーストーリーはプロダクトオーナーとチームの両方に関わる極めて重要なプラクティスですが、比較的簡単なので最初に導入します。

ユーザーストーリーはプロダクトオーナーが作成します。もちろん最初はアジャイルコーチが手伝うことが多いと思います。短い文を書くだけのことを「手伝う」というのは奇異に聞こえるかもしれませんが、効果的に機能するユーザーストーリーを書くには意外とコツがいります。よくある失敗は、システムの都合だけを書いていて利用者にとっての価値が書かれていないとか、内容があいまいで具体的に何を作れば達成できるのかがわからないなどです。

チームはユーザーストーリーを実現する役割を担います。たいていの場合、ユーザーストーリーを実現するためには幾つかのより小さな仕事（タスク）が必要になります。このタスクを決めたり、やり方、順番を決めるのはチームのメンバーです。また、チームはユーザーストーリーの実装に必要な時間やコストを見積ってプロダクトオーナーに知らせます。

以上のようなプラクティスを導入することで、アジャイル開発の重要なポイントをいくつが実現できます。

価値のあるものだけを開発できる

要件を分けて、それぞれの価値とコストを明確にすることで、それらの要件に優先順位をつけやすくなります。そして優先順位の高いものから実装することで、掛けたコストに対して常に最高の価値を得られることになります。

完成のタイミングをプロダクトオーナーが決められる

ユーザーにとっての価値で実装を区切ることにより、開発に“仕掛品”がなくなります。つまり「データの処理は全部できるんですが画面がまだ全然…」などという事態をさけられるのです。仕掛品がなく、ぴったり掛けたコスト分の価値が得られるなら、プロダクトオーナーはどの時点で完成とするかの完全なコントロールを得ることができます。

チームの自治権を守る

プロダクトオーナーは一度ユーザーストーリーをチームに伝えたら、チームにそれ以上の干渉をすることはできません。仕事のやり方、順番、ヘッドフォンの着用、おかしの量に口を出すことはできないのです。仕事にかかる時間もチームが決定します。それに対してプロダクトオーナーが「長すぎる、もっと速くやれ」ということはできません（ただしチームが手を抜いてプロダクトオーナーを満足させられなければ次のイテレーションはないかもしれませんが）。プロダクトオーナーはイテレーションの終わりにできあがってきたものだけを評価します。そもそも、それがプロダクトオーナーの欲しいもののはずです。

まとめると、ユーザーストーリーはプロダクトオーナーにプロジェクトの満了に関する完全なコントロールを与え、チームには自治権を与えます。これらはアジャイル開発によって得られる重要な価値で、導入も比較的簡単です。

書かなかったこと

今回は省略しましたが、ふりかえりやユーザーストーリーをうまく実践するために補完し合うプラクティスがあります。例えば、「プロダクトオーナー」をおくこと、その役割を果たしてもらうことは、ユーザーストーリーを実践する際に重要なプラクティスと言えます。それ以外にも、ユーザーストーリーの完了時にやり残した仕事が発生しないようにする「完了の定義」、絞り込んだユーザーストーリーを全員で分担して開発できる「職能横断チーム」などがあります。これらについて、KRAYでどのように取り組んできたか、次回以降に詳しく説明します。

また部分的にアジャイル開発を導入したことで発生した問題もありました。そのことについても順を追って説明していきたいと思います。最後まで読んでくださりありがとうございました。

参考文献

ふりかえりガイド（PDF）