→プロジェクト管理
→プロジェクトマネージャー
→日本のITユーザー
→職業としてのエンジニア
打ち合わせ・交渉・調整など†
交渉や調整で「やってはいけない」いくつかのこと 2011.8.24
1. 相手の面子を潰してはいけない
2. 間違い探しに終始してはいけない
3. 自分の主張を誇示してはいけない
4. 相手の言ってることを鵜呑みにしてはいけない
5. YESを無差別に使ってはいけない 無理な注文には「なるほど」と言ってみよう 2010.7.12
前向きに問題を解決しようとマインドセットを起動するのが、「なるほど」という言葉。起こることすべてには理由があり、その理由が分かれば「なるほど」と思えるはずだという姿勢です。クライアントが無理難題を言うときには、その理由があるはず。それが分かれば、注文そのものは無理なものであっても、何かしら解決案が見つかるものです。 「簡単ですよね」という挑発
そんなわけで、「簡単ですよね」という問いに「はい」と答えつつその「陰謀」を蹴る方法はいくらでもある。大事なのは、こういった問いは「挑発」の一種であり、必ず何か「余分な仕事」がついて来るということだ。その「余分な仕事」を避けるには、「技術的には簡単だけど実行するのは難しいと伝える」ことだ。 目的を忘れてはいけない 2009.10.9
システム開発プロジェクトでは，どうしても「物作り」の部分に焦点が当たってしまい，本来の目的を見失いがちである。確かに「物作り」は大事である。発注側である顧客ですら物作りばかりを気にする場合も多い。しかし，プロジェクトの本質は業務改善であり，システム開発やパッケージ導入といった物作りは，あくまでそれを実現するための手段である。 ユーザーの機嫌を損ねる行為10選 2009.6.24
＃1：見下した態度で相手に接する
＃2：相手のスキルを過大評価した態度で接する
＃3：相手の依頼を断る
＃4：理解不能な相手だと思われる
＃5：相手の説明を無視する
＃6：独断的な態度で接する
＃7：問題は「非互換性」にあると告げる
＃8：ヒアリングや説明を十分行うことなく、また注意点をしっかり伝えることなく変更を求める
＃9：コンピュータの使い方について口うるさく注意する
＃10：ユーザーにとっての「自分のもの」という感覚を配慮しない 顧客要求を安易に受けてしまう人の良いSE 2008.8.11
変更管理委員会（CCB：Change Control Board）を設置して、ここで変更受諾の可否を決定すること
00第一に重要なことは、契約において仕様変更への対応方法をきちんと決めておくことである。具体的には、変更要求をどのように申請し、それに対してどのように採用の可否を決めていくかを決めておくことが重要である。
また、顧客と交渉する際に、自分たちの都合で変更要求を拒否するという姿勢ではなく、変更要求を受けることがプロジェクト全体にどれだけ影響があるかを説明しなくてはならない。変更要求の多さが結局は顧客にとっても良い結果をもたらさないということをしっかり伝えることが重要である。 プロフェッショナルとして「NO」を言う
あなたがプロとしてＮＯを言うためには、2つの要素をきっちり述べる必要があります。
1つ目は「ロジカルにこういうリスクがあるので、その意見には賛成できない」と言うこと。
2つ目は「その意見に賛成できないのは、あなたや会社のために言っているのであって、自己保身のためではない」と言うことです。
覚悟としては「自分はプロであり、ＮＯを言うことによって、ここにいられなくなっても信念を曲げることはできない。そうなったら他に移ってバリューを出そう」と思えるかどうかです。 顧客対応の超基本「○○はできます。ただし△△日かかります」 2008.7.11
まともなクライアントは、まともな相手を好む、ということを「オレンジジュース・テスト」は伝えています。まあちょっとできすぎた話ですが、私も請負を7年間やっていましたので、経験としても、この話は納得できます。
というのは、すぐやれ、と無理難題を言ってくるクライアントは、それを飲むと、要求がどんどんエスカレートしてくるのです。また、無理を聞いているうちに強固な上下関係が築かれ、馬鹿にされ、仲良くなりにくくなります。
反対に、まともな反応をしつづけると、細かな失注はすることがありますが、長期的な関係をもてるクライアントが多くなります。 アドホックな開発をしてはいけない 2008.5.22
PMは，例え進捗に影響を与えないような軽微なアドホックな変更要求であっても即答で了承してはならない。プロジェクトが順調に進んでいればいるほど，気軽に答えたくなる気持ちは充分理解できる。しかし，ユーザーに“当たり前感”を与えないためにも，一呼吸空けて返答すべきなのだ。
PMは，すべてのアドホック要求に対して，担当SEや営業担当者等と協議・合意した上で，対応を行うかどうかを決めるのが望ましい。また，ユーザーに対しては，プロジェクト開始時点で，どの範囲までならアドホックを受け入れるということを正式に書面で交わしておくことが重要である デモ・プレゼンテーション†
その他†
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
