顧客とのコミュニケーショントラブルは「制約」と「前提」を意識して会話をしていないから

プロジェクトをやっていて顧客がエンジニアに、エンジニアが顧客に不満を漏らすことの一番の原因にコミュニケーション不足が上げられますが、何も顧客対エンジニアばかりじゃなくてエンジニアのチーム内でもあるし、プロジェクトの始まる前、見積もり時点から不満の種を蒔いてしまうかもしれないのですが、そういったことが気になったことはありませんか。

そうしたコミュニケーション不足は言ったに何に起因して起きているのでしょうか。コミュニケーション不足を感じるケースごとにその原因は数多にあるのでしょうが、多くはコミュニケーションをしないことから起きるという当たり前のことを思う立ち位置に立てばコミュニケーション不足を感じる双方でそれぞれが考えていることを

「こう考えているんだけど。」
「こう受け止めているんですが。」

ということを伝えているかどうかなのではないでしょうか。

見積もりのケースで考えてみましょう。「こう考えているんだけど。」と思うのはどんな場面でしょうか。見積もりのケースが思いつかない場合は、設計しているときに置き換えてみてください。顧客から要件が記述されている資料、例えば、情報システム化の企画の資料を受け取りました。提案をするのですがその資料を読めば実現したいこと、その資料から提案するするシステムを顧客と会話することなく提案することはとてもリスキーです。リスキーは提案するという行為は受注するという意味とイコールですから受注機会を棄損してしまう、という意味においてです。

インプットは顧客から受け取った資料のみです。それを読んで手ぶらでヒヤリングに行くのでは武器を持たずに戦場に行くようなものなのでお勧めできません。少なくとも話のとっかかり、たたき台になる双方が会話できる提案の素案ぐらいは携えて行かなくてはなりません。

そのたたき台を持って行って顧客と会話するのを「摺合せ」何て言いますが、そこで何を話しますか。

顧客の資料をどう読みこんだのか、どう理解したのか、それを実現するとしたらエンジニアが持っているソリューションとしてどのような解決方法をいくつもある候補から選択したのか、その選択肢から選ぶ時に何かに影響されたのか、そう言ったことを話すのですよね。

それって、何について何を確かめているのでしょうか。それは、

「制約」と「前提」

について摺合せているんですよね。逆に言えば摺合せの議論の対象に上記のような項目が抜け落ちているとしたらそれは後々にコミュニケーション不足のタネを自ら蒔いていることになるんです。ね、そう思うでしょ。だって、そうだもの。

じゃあ、その摺合せでいったい何をすり合わせているのかと言えば、「制約」と「前提」です。いつものように辞書を引くと、

せい‐やく【制約】引用　goo辞書
［名］(スル)ある条件や枠をもうけて、自由な活動や物事の成立をおさえつけること。また、その条件や枠。「法律上の―を受ける」「時間に―される」

ぜん‐てい【前提】引用　goo辞書
１ある物事が成り立つための、前置きとなる条件。「匿名を―に情報を提供する」「結婚を―につきあう」
２論理学で、推論において結論が導き出される根拠となる判断。⇔結論。

こんなんでました。制約は制限を受けること、前提は物事が成り立つための条件、と。じゃあ、見積もりで制約と前提はどのように関わるのでしょうか。想像つきますよね。

制約とは素案を作るエンジニアを制限する別の所で決められている事柄です。言い換えれば他者が勝手に決めている条件です。顧客の業務、システム連携の手順、パッケージの仕様などなど。こちら側では変えられないもの、givenであるもの。

これらの与えられていると思っている、そうしたことを素案に織り込んでしまっていることが制約です。それを会話の中で本当に制約なのかどうかを聴かなくてはならないのです。

今度は前提ですが、それは提案する側が提案が成り立つために仮説を置いている、成り立つために置いている根拠となる数字、など、こちら側が勝手に仮置きした条件が前提です。これもこちら側が勝手に妄想していることですから、顧客の立場になれば、供給側が好きに言っている制約に当たるわけです。この前提も摺合せで顧客が受け入れられるかを聴かなくてはなりません。

プロジェクトがトラブルになるその一番の起因はこうした制約や前提を提案時に同じテーブルに着いて受け入れて理解するという行為を軽んじているからです。

これが見積もりと設計と同じように考えらえるのかと聞かれれば「yes」です。会話するコンテンツが概念に近いレベルを話しているのか、実装のプリミティブな会話をしているのかの違いだけです。