今日はお客様とミーティングの日。雨の中だというのにわざわざ来ていただき、加えてお土産まで頂いてしまった。いいお客様です。今日のミーティングの議題は前回のイテレーションの反省点とイテレーション期間内での疑問点など。前回のイテレーションの反省点に基づいて新規にストーリーを起こし、次のイテレーションで前のイテレーションの少し残っているところを引き続き行うように決定しました。
前回のイテレーションの問題点に対して本腰を入れて問題解決を行うことにしたので、次のイテレーションで選択するためにストーリーとして新規に起こします。タスクのレベルからストーリーのレベルへ、つまりチーム内のレベルから顧客価値のレベルへ引き上げを試みます。このとき迷うのは、問題が発生したときの問題判別をどのように顧客価値に結びつけるかという点です。お客様はまさに問題解決を望んでおり、そして私たちは問題判別を行おうとしているのですが、これをどうやって顧客価値としてかたちづくるか。問題判別を行おうとしているときに私たちはお客様に対してどのような価値を提供しようとしているのでしょうか。
問題判別の組織化という行為自体は、他のストーリーをこなしてお客様に対して価値を提供する際にかかる時間を短縮するものと考えられます。これはリファクタリングと同じように、そのままで直接的に顧客価値を提供するのではなく、他の作業の効率化をもたらして結果として顧客に価値を提供する速度を高めるような、間接的な顧客価値といえるのではないかと考えられます。
このようなときのストーリーの原案としては、「〜と同様の問題を繰り返さない」であるとか、「〜に関する問題の解決までの時間を短縮する」などがラフスケッチとして出てきます。ただこの書き方ではお客様から見た価値としてはまだちょっと訴求力が足りないかなと感じます。ストーリーは「A user can 〜 (お客様は〜できるようになる)」の形式で考えるようにしているので、私たちが行うことがお客様に対する価値としてどのような意味を持つのかを考えるようにしてユーザーストーリーを書き直します。ということで今回はこのような方向性で間接的な顧客価値を直接的な顧客価値に近い形で記述してイテレーションプランニングに追加し、サインアップを行いました。
ストーリープランニングを考える際にはどうしても機能要件に目が行ってしまい、非機能要件が「やって当然」や「暗黙の了解」のレイヤーに入ってしまいがちです。非機能要件をどうやってストーリーにするかは、Ron Jeffriesがどこかに書いていたような*1。私たちのプロジェクトではまだ出てきていませんが、今後はパフォーマンスとか耐障害性とかもストーリーにしてみようと思います。出来れば定量的な指標を出したいですね。ただやりすぎはまずそうなので非機能要件を何でもかんでもストーリーにするのではなく、ある程度は常識の範囲内でおもてなしとして行うべきかなとも思います。あれ、発散してしまった。今日はそんなことを考えていました。
*1:今度調べてみます
