駄目なお客さん、駄目な先輩、駄目な上司、駄目な後輩・・・はいくらでもいます。
そういう人達がいても業務が正しく進んでいる場合は良いです。大抵はそれを補うだけの戦力がアサインされますので、正しく進まない事態になることは、あまりありません。
しかし、明らかに業務が正しく進まないような状況では放置できません。
過去にあった事例を紹介したいと思います。
●駄目なお客さん①
＜反応が無い。しかばねのようだ。＞
メールを何度送っても何の返事も無いし、電話で質問や、お願いしてもやっておくと言ったまま、音沙汰無いお客さんです。
何かしらの反応があるなら、業務は進むと思います。意味が分かない返事だったりしても根気良く話を聞けば、少しずつでも業務は進みます。しかし、返事が無い場合は、一切進みません。
こういう場合はなんとしても一度、直接会う必要があります。で、その際に何としても定期的な打ち合わせを約束してもらいます。
また、会った時に必ずQA表（質問表）を印刷して持参します。その際、質問の解答期限を必ず書きます。少し早めの期限でいいです。値切り交渉に近いですが、無理と言われたら、少し期限を延ばせばいいです。
それと切羽詰まってなくても、ヤバい空気を出した方がいいです。この質問はいつまでに回答無いと進捗遅れになる旨伝えます。
更に、進捗遅れになる場合、自責では無いのでってリスケの話をぼそって出して危機感を煽ります。これはお客さんを怒らせる可能性もあるので（要はあんたのせいで遅れてますって面と向かって言ってることになりますので）、冗談っぽく言えると良いですね。私には無理ですが。リスケは言わない方が無難です。
●駄目なお客さん②
＜AさんとBさんの意見が反対、食い違う＞
窓口となる人を１人にして貰えばこんなことは起きません。普通のお客さんはそうします。
機能が多いなどの理由で、機能毎に別々の人が窓口となっている場合もいいです。
駄目なパターンは以下などのパターンです。
・お客さんのAさんが最初のレビューア、Bさんが次のレビューアになっている
・お客さんのAさんがこちらに指示して、Bさんがレビューアになっている
大抵、後にレビューする側（上記ではBさん）の方がリーダーに近いかリーダーだったり、偉いです。
Aさんの言った通り、ドキュメントを作ったにも関わらず、Bさんのレビューで覆されたりします。
当然、修正には工数（時間と思って下さい。）が掛かります。つまり、お金が掛かります（会社は私達に給料を払うわけですから）。正当な対価なはずですが、お客さんはその分のお金は出してくれません。こちらからするとAさん、Bさんどちらもお客さんです。お客さんであるAさんの言う通りに作ったにも関わらず、うちのお金を消費して修正する事になります。なんとも理不尽な話です（資本主義、ビジネス、お金の話を全く考えてないのでしょう）。
この時点でも困ったお客さんなのですが、最悪なのは、その二人の間で決着を付けてくれない場合です。
自社の意見が違った（纏まってない）状態で他社に依頼を出してる時点で恥ずべきこと（要求仕様書、要件定義書をお客さん側で作ってない、作ってもレビューしてないからこんなことになります。基礎中の基礎です。）なのに、それをズルズル引きずって、結論をいつまでも出せないなんて、はっきり言って小学校の学級会レベルです。
で結局は私がその２人を引き合わせて(下請けにこんな事させて本当に恥ずかしくないのか？)、話合ってもらったのですが、どちらも意見を曲げないので、こちらで中間案を出して納得してもらいました。
●駄目なお客さん③
＜理想を語るだけのお客さん。＞
ビジネスの世界では、期限が決まっていることが殆どです。SEでも納期はあります。
仕様検討、設計、実装、試験が終わり、期限は1週間後と言う状況です。にも関わらず、Aさんはこの機能を追加して欲しいと言ってきます。その機能が有るとユーザビリティが向上するものでした。しかし、無くても問題が起こるものではありませんでした。
しかも、その変更を入れるためには、Aさんの上司の許可を取らないといけないそうです。
Aさんに許可はいつ取れるか聞いたら、回答が曖昧で、上司を説得する必要があり、許可が取れるかも分からない、時間が掛かるかも知れないとのことです。
しかし、どうしてもその機能が欲しいらしく、その機能の有用性を繰り返し、色々な観点で主張します。
②と似たパターンですが、普通はその時期に変更はしません。Aさんの上司がまともな方なら、許可をは出さないでしょう。開発モデルにウォーターフォール開発モデルを採用していましたが、その場合、仕様検討の段階で、その意見を出して、設計、実装、試験をする必要があります。はっきり言って現実的ではありません。ウォーターフォール開発モデルと言うものを全く理解してません。
また、業務にもよりますが、本来の工程をかなり短縮して取り組んだとしたら以下などになります。
1日目:Aさんが上司に許可を貰う
私:仕様書修正
仕様書社内レビュー
2日目:仕様書修正を客先レビュー
私:設計書修正
設計書社内レビュー
3日目:設計書修正を客先レビュー
私:Make※1
社内Makeレビュー
4日目:客先Makeレビュー
私:試験仕様書(項目書)作成※2
試験仕様書社内レビュー
5日目:試験仕様書客先レビュー
私:試験実施
私:バグ修正
バグ修正社内レビュー
私:試験成績書作成
試験成績書社内レビュー
6日目:試験成績書客先レビュー
私:リリース準備
私:マニュアル修正
マニュアル修正社内レビュー
7日目:客先マニュアルレビュー
リリース
リスクを全く考慮してません。また、お客さん側のレビューをスケジュールリング出来るのか？と言う問題もあります。
上記のスケジュールはやろうと思えば更に短縮出来ますが、何れにしてもやるべきではありません。
結局は1日で許可が取れたら、間に合うが、それ以上掛かるなら、間に合わないと伝え、諦めて貰いました。
※1 コーディング、プログラミングのこと。
※2 一つにしましたが、試験は単体、結合、総合試験などに別れそれぞれレビューしたりします。
●駄目なお客さん④
＜言ってることとやってることが違う。
と言うとか、自分達のことを客観的に見られない。＞
打ち合わせがあった時に議事録(打ち合わせの内容をメモした文章) は自分で取るようにしてます。で、このお客さんは誰も議事録取ってないので、私がそれをメールで周知してました。
そうしたら、ある日お客さんから言われました。
お客さん『なんで、○○さんが議事録取ってるの？ウチの仕事でしょ？』
私『・・・』（あんたらが議事録取らないからでしょーが！！）
自分達が何をして、何をしてないのか分かってないなんて有り得るのでしょうか？それとも
●駄目なお客さん⑤
＜タスク・スケジュール管理してない＞
ある日、お客さんから打ち合わせコーナーに呼びだされました。そこで、
お客さん『明日までにこれこれこういうツールを作って下さい。』
私『・・・』
③で書きましたが有り得ないです。
こういう無茶ぶりな依頼は断ることも出来なくは無いです。しかしお客さんが、困ってたら受何とかしてあげたいと思ってしまいます。
詳細は書けませんが、そのツールはその業務では、無ければ業務が完了できない必須のツールでした。しかも、大きいプロジェクトでした。多分全体で業務従事者は、数百か1000人越えてたと思います。
実際のツール使用開始は数日後で、翌日と言うのはお客さんレビューでした。それでも普通はあり得ません。
で、そのツールを私達のチームで作ってリリースしたら、バグだらけ（バグを出したのは私ではなかったですが）でユーザーにさんざん私が文句言われて、平謝りしました。
しかも、そのバグのうち幾つかは仕様伝達ミスで、私達には誤った仕様を伝えられ、更にリリース前のユーザー試運転で、バグが見つかってユーザーからお客さんには報告があったにも関わらず、お客さんから私達に連絡が無く、運用前日に、ユーザーから報告したのに治ってないと私が文句を言われ、『こんな駄目なツール』位の罵倒を浴びせられました。
バグを出したのは私達です。ですが、ですがですよ？
やり場の無い怒りが、込み上げて来るんです。
やりましたッ！ やったんですよッ！！必死に！その結果がこれなんですよッ！
タスク管理、スケジュール管理は基本中の基本です。テスト用のツールならともかく、かなり重要なツールでしたので、１日でツールを作れなどあり得ません。こんなの4、5年目の社員でもできる人はできます。ホントに何考えて仕事してるのやら・・・
