コラム：擬似顧客の声

XPを実践していくうえで、「オンサイト顧客」は重要な役割を果たすにもかかわらず、XPの多くの文献には「オンサイト顧客」に関する記述があまり見られないのも現状です。本コラムでは、これからXPを実践したい、XPの「オンサイト顧客」に挑戦したいという読者に少しでも参考になるよう、筆者が実際に「オンサイト顧客」の擬似顧客を実践した体験をご紹介していきたいと思います。

■「業務屋」と「技術屋」の不幸な行き違い

XPを実践していくためには、要求を把握している顧客が「オンサイト顧客」という役割でXPに参画することが非常に重要となります。しかしながら、顧客は自分自身のビジネスは詳しいがシステムは詳しくない「業務屋」であり、逆にプログラマはシステムやプログラムは詳しいが顧客のビジネスは詳しくない「システム屋」であることが多い。ここに「不幸な行き違い」が存在しているのです。

XPの「オンサイト顧客」は、要求仕様書を作成する替わりにストーリーカードを書きイテレーションを決めるという責務を担っています。ストーリーカードでは記述しきれない詳細な仕様は、その場でプログラマとディスカッションしながら指示していくのです。一見簡単そうに感じられるかもしれませんが、「業務屋」にはこれはかなり難題となってのしかかります。

そこで登場するのがこの「不幸な行き違い」のギャップを埋める「擬似顧客」という役割です。平たく言えば、擬似顧客は業務屋の視点を持ったシステム屋です。プログラマからは擬似顧客＝顧客と認識され、顧客からはシステム屋ではなく同業のパートナーとして認識されます。

■顧客との信頼関係がポイント

顧客が「業務屋」であるがゆえ、システム化の細かい部分は「いいのか悪いのかわからない」というのが本音です。「君がそう言うのなら、そうしてくれ」と言ってもらえれば良いですが、「そうかもしれないが、君の言うことは信用できない」という関係になると、これは大変つらい作業になってしまいます。

ではいったいどのようにしたら、顧客に信頼してもらえるのでしょうか？筆者はシステムコンセプトが重要な役割を果たすと感じています。顧客は「こんなことをしたい」というコンセプトはしっかり持っているものです。そのコンセプトの生まれた背景、必要性、方向性、真の意味などを理解し、システムに対する価値感を共有するところからまず始めました。書類上だけの理解だけでなく、システムが稼動するであろう現場（今回はお台場の商用複合施設メディアージュ）に何度も足を運び、そこでシステムが使われるであろう光景や、システムを利用して楽しんでいる施設利用者の表情、知人との会話の様子、施設店員の振舞いなどを想像しながら、「なるほど、この状況のときにシステムによって来場者を楽しませたいのだろう」とシステム化の背景に迫っていくのです。

「どのようにシステム化するか」（How）をつい考えてしまいがちですが、その前に「何をシステム化したいのか、それはなぜか」（What, Why）をしっかり顧客と共有しておくことが、顧客の信頼を得るポイントとなります。

経験上意外と有効だったのが、会議室でかしこまって打合せをするというのではなく、いわゆる「チャット」を顧客と多く行うことでした。会議室だとなかなか言いにくい考えなども、喫煙所や廊下などで雑談をしていると「そういえば、思いついたんですけどこんなことはできないですか」と気楽にシステム化への思いなどを打ち明けてくれたこともありました。

■ストーリーカードとユースケース

擬似顧客は、顧客と共同で仕様を決めてストーリーカードを書くのが主な役割になります（顧客がストーリーカードを書くことはありません）。このストーリーカードというのが実はクセモノです。いきなりストーリーカードを書き始めるとシステムの全体像がつかめず冗長な機能を作ってしまったり、ユーザーインタフェースが統一されていないという事態が発生します。いわゆる「木を見て森を見ず」状態です。筆者らは、概念モデルやデータベースのER図でシステムの全体像を捕らえ、それを踏まえてユースケースでシステムの振舞いを定義しました。このユースケース１つ１つが、１つのストーリーとなってストーリーカードに記述されていきます。

顧客とユースケースを記述していく際のポイントは、システム用語を避けて顧客の言葉を使うことです。それでも文字ばかりのユースケースは直感的にわかりやすいとは言いがたく、多くの場合はユースケースの内容を顧客にわかりやすいように図やフローで説明することになりました。なぜこうなるのか、こうしたほうがベターなのかを顧客に十分説明し、顧客と合意の上で仕様を決めていきました。

しかしながら顧客にわかりやすいユースケースだけでは開発チームに意図が伝わらないケースも存在します。そこで、ユースケースの粒度を「ユーザ目的レベル」と「サブ機能レベル」に分け、顧客と会話する場合には「ユーザ目的レベル」のみを、システム内部のイベントフローをある程度決めてしまう場合は「サブ機能レベル」のユースケースと使い分けることにしました。この「レベル分け」は意外と有効ですのでお試しになられてはいかがでしょうか。

■顧客と開発チームの狭間で

顧客：「水谷さん、このスタンプ蓄積機能はどうしても実現したいんですよ」 開発チーム：「水谷さん、残りの工数で開発するには無理があります。ほら、次のイテレーションまで残りは４デューク（理想エンジニアリング日）しかない。この機能は見積もったら２つのストーリーで６デュークもあるじゃないですか」 擬似顧客をやっていると何度もこういった「板挟み」を味わいました。擬似顧客であるがゆえに、「この機能は必要だ」という顧客の思いも、「こりゃ間に合わない」という開発チームの思いも痛いほどわかります。

「顧客の希望を最大限に活かしながら開発工数を最小限に抑えるような代替案を顧客に提示する」、ここが擬似顧客の腕の見せ所です。顧客が希望している機能にも、実現のレベル（深さ）というものがあり、松・竹・梅の3レベルの案を擬似顧客が考えて作成します。ここでもポイントは、顧客の立場から顧客にわかりやすい用語、言いまわし、表現方法できちんと顧客に説明することです。ズバっと機能を簡略化・削減する場合でも、きちんとした理由ときちんとした説明があると顧客も納得してくれます。（これが意外と難しく、実際できていないプロジェクトが多いようです）。

逆に、開発チームを説得するケースもあります。なぜこの「スタンプ蓄積機能」が必要なのかを開発チームにもしっかり把握してもらうのです。システム化の背後にある思想、将来の事業展開プラン、収益モデルなどプログラミングとは関係ない話も開発チームと共有し、「なるほど確かに実装しないといけないなぁ」と打開策を検討していきました。

このような「板挟み」に遭遇した場合は、顧客と開発チームの両方に対して何回かディスカッションしながら決めていくのがポイントです。顧客と代替案で一番可能性のあるものを詳細化し、開発チームとコミュニケーションしながら工数を見積もり、それを持ってさらに顧客と詳細を詰めていくというプロセスを数回繰り返しました。

■顧客名言集

ここでは、顧客とディスカッションしていった上でいくつか印象に残っている名言を集めてみました。それぞれのポイントを踏まえて、読者のみなさんも擬似顧客に挑戦してください。