原則として、要件の洗い出しとプロトタイプのレビューに２回以上のスプリント（編注：ここでは１スプリント＝２週間）が必要な場合、それがどんなものであっても複雑すぎると言えます。そのような場合、プロジェクトを保留するか中止しましょう。
私の経験上、２回のスプリントで問題を解決できなければ、プロセスやシステムに深く関わる複雑な問題があるか、あるいは未知の課題が潜んでいると思われます。
いずれの場合も、少し待ってください。このルールにおける唯一の例外は、『Fixing the Enterprise UX Process ebook』で説明したように、重要度と実現可能性が高い機能の場合です。
では、少し前に私が行ったプロジェクトから例を挙げてみましょう。
突如現れた「メッセージ機能」
このストーリーの要となるのは、ユーザー間のシンプルなコミュニケーションとして使用されるメッセージ機能です。当初、メッセージ機能はプロトタイプに含まれていませんでしたが、２人の主要なステークホルダーが同席したスプリントプランニングのミーティングで提案されました。
ステークホルダーたちからの仕様書は、私たちの具体的な質問攻めを受けて、次のようにまとめることができました。
- メッセージの必要性―評価者が承認者と話す用に。しかし、ほかの役割の人も関与する可能性があります。お互いに話をすることはできるはずですが、ほかの部署やクライアントと話す必要があるときもあるでしょう。しかし、それは特定の問題についてのみです。
- Outlookのような操作性―メールボックスなどの機能は除きます。コメントスレッドのようなものですが、全員が返信できるものではありません。
- 中央でなくても良い―ほかの画面で表示しなければいけない場合があるため、メッセージ画面は中央にある必要はありません。
- 質問するときに表示される―そして、質問が出たら全員に知らせる必要があります。
以上が、私たちが得た情報のすべてです。今、あなたの頭の中に浮かんでいる明確な問題はすべて、私たちの質問とまったく同じでしょう。危険信号が潜んでいるのがわかると思います。
このように曖昧で未定義のものは、ビジネス要件とはなりません。すべての画面にコメントスレッドを組み込むつもりはなく、またそれが意味あることなのか確信できませんでした。しかし、コンテキストを考慮するとコミュニケーションの必要性はあると確信できたので、そのプロトタイプに同意しました。
スプリント１のレビュー
２週間後、プロトタイプのレビューを行いました。同じステークホルダーが、甲高い声で話し始めます。（再び要約です）
「ユーザーがログインした際、iPhoneのようにメッセージが届いていることを知らせる小さなバッジを表示すべきです。」
ああ、バッジ。なるほど、今はっきりしました。思い出してください、私たちはこのメッセージ機能の具体化をしていませんでした。もちろんメッセージ"画面の計画もありませんでした。私たちにとってメッセージは、シンプルなコメントにすぎなかったのです。
こうして２週間後、私たちのスコープは急激に拡大しました。私たちは現在、アラートと通知を備えたメッセージのアプリを構築しています。誰も本当に必要かどうかわからなかったので、とりあえずどう機能するかやってみましょうということになりました。そこで私たちは質問してみたのです。
「メッセージのステータスを確認する際に、何らかの警告やポップアップなどが表示されるべきではありませんか？ 顧客がメッセージをチェックするのが面倒と感じるかどのように確かめましょうか？」
「きっと、顧客は面倒だと思っています。」
ちょっと待ってください。このような要件が定まっていないプロトタイプを作るには、最低でも12人 × 80時間分の工数が必要で、そうすると計画と予算を超過することが予想されます。私たちは、「きっとそうだろう」という単純な言葉によって、約７万ドルも費やしているのです。
私たちは、このような懸念をできる限り完璧に、そしてわかりやすく表明しました。このメッセージ機能は、別のシステムとして切り出せるくらい大規模なものであり、当初より長い時間と高い費用がかかる可能性があると提案したのです。
きっと最終結果はわかるでしょう。私たちは次のスプリントを実行しました。
スプリント２のレビュー
２週間後、もう一度レビューを行うことになりました。 Outlookにおけるメールのアプローチに似たメッセージングダッシュボードが用意されました。スレッド、フィルタ、アドレス帳など、全体で９つのセクションがあります。レビューセッションの途中で、突然以下のように言われました。
「この会話、保存することができませんね。」
待ってください、どういうことでしょう？
「顧客が機密情報を漏洩してしまう可能性があり、法律上、サーバーに保存できないのです。」
つまり、評価者、承認者、そして顧客の３者間でのコミュニケーションが必要で、それには機密情報のやりとりも含まれます。しかし、そのやりとりを保存することはできないのです。ご想像の通り、難しいどころの話ではありません。
答えの出ない長い会話が続きます。そこで私たちは方向転換をして、残りのプロジェクト予算と、さらに２週間プロジェクトを続行するために必要な費用を説明しました。ステークホルダーは随分長い時間苦い顔をしたあと、このプロジェクトは壮大なブラックホールであるということを理解したようです。
また、顧客または組織が法的責任に問われないように、足りない情報について入念な調査をするべき必要があることを意味していました。
我々はバージョン1.0のローンチまでメッセージ機能を保留することを、全面的に同意しました。
声にする ― さもないと、報いを受ける
過去30年間、私はさまざまな製品やプロジェクト、そして企業でこれと同じようなストーリーが繰り返されるのを見てきました。２回目のスプリント以降、しっかりと定義されていないものが残っている場合は、それを保留する必要があるということを何回も失敗しながら学んできました。
もし、あなたの頭の中で叫び声が上がり、何か問題が起こりそうな気がしたら、耳を傾けてみましょう。あなたの懸念のすべてを明確に、そしてもちろん礼儀正しく声に出してみてください。
私が今までに受けた最高のアドバイスの１つに、沈黙は合意と等しいというものがあります。あなたが何も言わないならば計画に同意したということだけでなく、実行することにも同意したということになるのです。
その同意の代償は、関係者全員の苦悩となる可能性もあります。
より実用的なアドバイスを得るには、Joe Natoli氏による電子書籍『Fixing the Enterprise UX Process』をダウンロードしてください。
