エンジニアなら顧客の前でホワイトボードの前で図を描き、優先順位づけをしなさい

良く言うじゃないですか。「視点を変えなさい。」って。意識しないと出来ないし、じゃあ、やろうと思ってもなかなか上手にできないし。でも出来ないと色々と仕事で都合が悪いし。

例えば、顧客から要件をヒヤリングしているとき、その要件の理解に努めようとするならば2つの観点で確認する必要があるわけです。

1つは顧客の視点で具体的に何を実現したいのか。

1つはエンジニアの視点でシステム要件としての実現することは何か。

エンジニアなのだから顧客要件を受け止めてた上で、システム要件としてどのような要望があるかを抽出して、理解し、それでよいかを確認することは当然のことだと同意できますよね。ではなぜ、もう一つ、顧客の視点で具体的に何を実現したいのかを受け止める視点が必要なんですかね。

顧客から実現したいことを訊いて、それを正としてシステム要件を考えることは普通のプロセスですよね。じゃあ、「それでいいじゃん？」って思うでしょ。そうですね、顧客が言っている「意図まで汲み取れるなら。」ですけど。どういうことかと言うと、顧客が言っていることはそのまま実現してはいけないんですよ。

それは、顧客が言っていることの裏を取っていないから。だから、インタビュー形式で教えてもらうわけですが。だから、エンジニアはエンジニアの言葉では話さず、自分が理解した顧客の言葉を一度はそのままオウム返しをしたうえで、顧客も理解できるシステムの言葉で自分の理解を言い直さないといけないから。

最初の顧客への反応の顧客の言葉でオウム返しするのは、顧客の言っていることを正しく受け止めていますよ、というメッセージでもあります。聴きながら、頷きながら、コレを実現したいのですね、と。

次に、顧客もわかりやすいシステムの言葉に言い換える。一つ気にしないといけないのは、実現仕様の話をするのはまだ早いのでグッと堪えて。今は、システム方式、論理のレベルです。1つの大きなシステムの箱のレベルです。それに対して、

顧客が実現したい要件がどう作用するのか。

何が制約としてあるのか。

何が前提としてあるのか。

それを聴きだす。それを聴きだすには、顧客が理解できるシステムの言葉で伝えることを試みるのですが、ここで先に顧客から顧客の要件を顧客の言葉で聴いているという事実があるのでソレを踏まえてから、でないといけないのですよ。

顧客からしたら、「今話したじゃないか。」「今、わたしの言葉で理解したことを述べたじゃないか。」と。それでさらに「何を聴くつもりなんだ？」と身構えるんですよ。

顧客の言葉を鵜呑みにして何度痛い目にあっているのですか。

「アレはそういう意味じゃない。」
「それはそこまで重要ではない。」
「この要件は制約があるんだ。」

顧客に聴いているのですから、目の前にいるのでしょう。その場所にホワイトボードがあるなら、前に立って、

1つしかない箱の中に顧客がやりたいことを箇条書きで書きましょう。

顧客の要件を1つの箱として図に描いて、その周りとの関係を描きましょう。

要件が複数あるなら実現したい優先順をつけてみて顧客にそれでいいか尋ねてみましょう。

ホワイトボードの前に立つには、顧客の要件を聴いたエンジニアが顧客の視点で図を描き、顧客の視点で優先順位を(仮)でつけられないといけない。

その場こそ、顧客の視点での理解の場、摺合せの場なのです。ここで如何に顧客とボタンをしっかり掛けるのかが勝負どころなんですよ。