基幹系をAgile開発で実施した時の肝１（実践からの気づき）

ユーザーやステークホルダーの評価

スプリント中の成果をユーザーやステークホルダーへデモンストレーションを行い、評価してもらう場としてのイベントがスプリントレビューです。
このミーティングでは、開発チームがコミットしたプロダクトバックログ（スプリントバックログ）をITサービス（ソフトウェア）として実現したものを、操作しながら感想、変更、完了等の評価をユーザーやステークホルダーと共に行います。また、開発チームがコミットしたにも関わらず、実現できなかったものを精査し、対策評価もこの場で行います。ある意味で、従来のユーザー承認・評価に似ていますが、ドキュメントではなく、実際に動作するITサービス（ソフトウェア）で行います。
開発チームとユーザー側が対等の立場で、お互いに良い製品（ITサービス、ソフトウェア）を作り上げるという意志でこのイベントに望むことが重要です。様々なアジャイル開発現場の支援をしていますが、このスプリントレビューでのユーザーやステークホルダーの参画の姿勢によってプロジェクトの『成功の可否が決まる』と言っても過言では無いと感じています。

基幹系刷新プロジェクトを実施した時の気づき
ある、成功した基幹系の刷新プロジェクトでは、プロダクトバックログと併用して仕様変更確認リストというものを使用して、開発チームとユーザー、ステークホルダーとの間で、常に変化する仕様を、夫々の立場で優先度、難易度、関連度といった評価を見える化して、このミーティングの中で相互の摺合せを行っていました。この行為はプロダクトオーナーがバックログについて協議し改定するという行為と同じです。

基幹系システムなどの規模が大きいシステムでは、ある仕様変更が他の仕様へ波及する事象が発生します。本来なら、プロダクトバックログの一つ一つのユーザーストーリーの相互依存性が無くすことが、事業価値による並び替えを容易くするのですが、粒度によっては、時間的系列で異なった機能として実装を余儀なくせざる負えないケースがあります。ユーザー側がシステム的に波及する指摘か否かを、その場で考慮するのは難しいのです。

この見える化は、ユーザーには小さく見える変更でも、システム的には波及する問題を炙り出すことに有効に働き、過剰な変更、追加を抑制する効果がありました。
このプロジェクトのスプリントレビューに参加した時に、ユーザー側の仕様変更相談に開発チームが『この変更を受け入れると、今のシステムの各機能が伝染病にかかってしまいます。他の方法、対策を考えた方が良いと判断します。』と答えていたのが印象的でした。

このミーティングを滞りなく出来るか否かで、ユーザー、ステークホルダーからの開発チームへの信頼度が全く違ってきます。

ユーザー、ステークホルダーから信頼を得ることで開発チームのモチベーションが上がり、結果的に品質、作業効率が上がってきます。

とても単純な表現ですが、ユーザー、ステークホルダーから『ありがとう。』、『よく作っていただきましたね。』、『とても判りやすいです。』といった開発チームの行動を褒める言葉を引き出せたら、まず成功するための定石の一つは確保できたと判断して良いです。

他の支援したアジャイル開発プロジェクトでは、そのプロジェクト期間の中盤で開発チームの覇気が低下する現象が起きました、このプロジェクトの様々な状況を表すボード（一般的には情報ラジエターと呼んでいる）には注意、問題を示す事象は現れていませんでした、そこで、スクラムマスターが、このミーティングの前にユーザーへ訪問して、今日のスプリントレビューの最後に開発チームを何でも良いので褒めて欲しいとお願いし、ユーザーはその通りに、このスプリントレビューの内容に関連して、開発チームを褒めたそうです。

その後の開発チームの覇気は今まで以上に高くなり、プロジェクト成功へ導きました。
この事は、このプロジェクトに限ったものではなく、皆さんの現場、プロジェクトにも当てはまる事です。現場の方々のモチベーションは、スキルや個性と同等、もしくはそれ以上に重要なファクターです。信頼を得るには、ITサービス（ソフトウェア）にバグが存在していては、信頼を築けないのは言うまでもありません。

このミーティングで完了という評価を得たものがリリースの対象候補となります。