読者です 読者をやめる 読者になる 読者になる

【メモ】お客様との打合せの進め方

概要

システム開発・導入等において、お客様と打合せする際のポイントをまとめた。

準備段階

出席者

出席者、出席者の位置づけ(権限、キーマンかどうか)を確認する。 お客様だけでなく、自分の会社側の出席者についても、役割等打合せで何を期待するかは 事前にすり合わせしておく。役割が無いのであれば、出る必要はない。

必要なもの

会議のレジュメがあると進行しやすいし、後述の会議のイメージもつきやすい。 資料として出す必要がなくても自分用には作るべき。

目的

「打合せすること」が目的になりがちであるが、今一度目的を確認して 「今から準備しようしている打合せの準備は目的を達成できるもの」であるか確認する。

ゴール

目的を達成するために、何がどうなれば良いのか。具体的なゴールを定義しておく。 また、何かを決定する場合はお客様の「誰」に決定権があるのか事前に想定しておく。

例)XXX画面の画面レイアウトを決定する。
  XXXの担当者を決定する。

ゴールはレジュメなどに記載し、打合せ時に出席者と認識を合わせると良い。 また、ゴールが「運用フローを決定する」というような大きな場合は、細分化したものを リスト化し、ゴールを小口化すると良い。こうすると全部終われば達成であるし、残っているものは 残課題として今後対処すれば良いものとして明示的になる。

イメージ

準備した資料、出席者をイメージし、頭の中でざっとシミュレーションを行う。 そこで、懸案になりそうなものがあれば事前に回答の準備をしておく。 ここでどれだけイメージし、事前準備できるかが実際の打合せ時のパフォーマンスに大きく影響する。 打合せのパフォーマンスが上がれば、そのプロジェクトに大きくプラスに働く。

打合せ時

時間管理

  • 決まった時間に始める。当たり前のことではあるが、打合せの場所が初めて訪問した場所だと部屋がわからない。 また、お客様とうまく調整できておらず誰を尋ねれば良いかわからないなど、色々とトラブルが起きやすい。 リスクを想定しておき、早めに現地入りするべき。

  • 決まった時間に終わる。打合せは伸びがちであるが、お客様と約束した枠内の時間で終わるように進行すべき。 話が脱線してもすぐ戻したり、検討が長くなりそうであれば、持ち帰りにしてもらう等の工夫が必要。

資料

事前に席に配布し、数に不足がないか確認しておく。

システム画面

できるだけ実際の画面で説明して進める。口頭であれこれしても伝わりにくい。 ”百聞は一見に如かず”である。

最後に決定事項、懸案事項の確認

打合せは、何かを決定する場所なので決定事項は打合せ中に都度確認していくが、 打合せの最後にもおさらいとして全ての決定事項を確認し、認識に誤りがないか漏れが無い確認しておく。 懸案事項についても同様。

次回日時・内容確認/調整

後日でも良いが、可能であればその場に関係者がいるので次回日時も調整しておくと効率的。 次回の内容は、持ち帰りの懸案事項の結果が影響する場合もあるが、こちらもできる限りその場で調整しておいた方が良い。

(トラブルシューティング1)決定したいが、決定権がある人が欠席

「次回に出席してもらおう → また出席しない」というまずいケースになりがち (そもそも出席すべき打合せにでていないので、次回も欠席するケースが多い) 打合せ後にお客様内で確認してもらい、その結果を後日連絡してもらうか次回打合せ時に結果をもらう。

(トラブルシューティング2)決定したいが、そもそも決定する人が決まっていない

誰が決めるか決定してもらう。
→そもそもプロジェクト開始の時点で決まっていた方が良い(お客様含めた体制図)。  当初想定してないものであれば、後日体制図に加筆し関係者で認識を合わせておく。

打合せ後

議事録の作成

  • 定型の議事録フォーマットがあればそれで作成し、参加者に送付する。 打合せ時に配布した資料も添付すると良い。 形式張ったものでなくても良いのなら、メール文章内で書いたメモをそのまま送付でも良い。
  • 目的は「自分、その他出席者用の備忘録」だけでなく、出席できなかった人への情報共有、 また、言った言わないのトラブルを避けるため。

次回打合せに向けた課題事項への対応

決定事項、懸案事項には速やかに対応する。特に懸案事項について、早期対応の必要が高いものは すぐにやり、問題が小さいうちに対処する。

最後に

打合せをどう進めるのが効率的かどうかは、そのプロジェクトの性質に大きく影響する。 ある程度自分の中でフレームワークを作りつつ、そのプロジェクトに合ったテーラリングして効率化したい。