エンジニアのセンスとスピード感を磨く方法

大切なのはセンスとスピード感、若手エンジニアに役立つチップス

打ち合わせでの結論のまとめ方で気になる事

ややこしい事項は、メール等の文章だけではなかなかニュアンスが伝わらない物です。

そのため関係者一同集めて、打ち合わせでお互いの理解をすり合わせて、結論を作り上げます。

 

顧客にある事項を了承してもらいたい場合は特に慎重に準備をして打ち合わせに望むことになります。いくら当方が契約に基づいていて正当だったとしても、一方的に押し切る事はしない物です。逆に契約的に不利な場合は頭を下げてお願いベースになることもあるからです。何事も持ちつ持たれつの精神は大事です。

 

 

答えが複数ありこちらの考える案に了承してくれるか自信がない場合、慎重に論理的に時にはメンタリスト的?!こちらの案に誘導しようとしますよね。

交渉相手が仕方ないなと折れて、理解してくれたとします。こうなれば交渉は成功です。

 

余談ですがビジネスなので議事録は必ず作成します。

打ち合わせをしながら議事録はその場で書くことが最近は一般的です。終わった後に書かれると内容をまた確認しないといけなくてこれが非常に手間になります。打ち合わせ中に皆で文言を確認しながら作って仕舞えば、打ち合わせは多少時間かかりますが、後で確認するより数段早く明確になります。

 

ここで本題です。

打ち合わせの目的は、こちら側の案(プランAとしておく)を顧客側に了承してもらうこと。

なので議事録としては、

「顧客がプランAを了承した。Client agreed to proceed .....」となります。

主語を顧客にしているのです。内容よりも顧客が決めた事実に焦点が当たります。

 

技術的な内容の場合、この形にまとめられてしまうと、気になる事があります。

 

プランAが論理的に一番適切だと説明をした結果、論理的に自然の流れとしてプランAになったと言えます。プランBを選ぶのは愚かで有ると説明の流れからなっているからです。

なので日本語だとどう書いて良いのか良く分からないのですが、英語だと「It is mutually agreed to ...」とかの形式主語にしたほうが、説得された方も結果を受け入れ易くなると思います。

 

もしかするプランAの選択は間違っていたことが後々判明するかもしれません。

その時に、打ち合わせのまとめ時に「Client agreed ....」的に結論を迫ったり記録すると、将来の責任追求を気にして、プランAではダメだと最後の最後に打ち合わせ結果をひっくり返される危険もあります。

 

人に判断させるという事は、判断を迫られた人は責任を感じます。

 

打ち合わせの目的は、こちら側の案を通す事。責任を相手に押し付ける事ではありません。

特に技術的な打ち合わせでは論理的な検討の結果、自然と結論が決まったとすることだと思いますね。

 

ちょっと書いていて自信がなくなったので思いますねとしておきます。