顧客対応

→プロジェクト管理

→プロジェクトマネージャー

→日本のITユーザー

→職業としてのエンジニア

打ち合わせ・交渉・調整など†

• ｢お前じゃ話にならないから上司を出せ!｣｢誠意を見せろ!｣と怒鳴る悪質クレーマーを撃退するスマートな返し 上司を出しても､謝罪するのもNG | PRESIDENT Online（プレジデントオンライン） 2024.11

• [ゼロから始めるプロジェクトマネジメント] プロジェクトの新規要件は工数を3倍にして請けるかどうかを判断しよう | DevelopersIO 2024.6

• こうすれば無理めな仕事を感じよく断れる…｢お断りメール｣の最後に添えるたった10文字の魔法のフレーズ | PRESIDENT WOMAN Online（プレジデント ウーマン オンライン） | “女性リーダーをつくる” 2024.6

• ｢高すぎるから半額にして｣という無茶振りに｢それは厳しい｣は三流…そのとき一流がする"うまい切り返し" ｢できる､できない｣で回答しようとしてはいけない | PRESIDENT Online（プレジデントオンライン） 2024.6

• 口頭で受けた指示に従ってはいけない…｢私は知らなかった｣が口癖の"責任逃れ上司"に事前に送るべきメール | PRESIDENT WOMAN Online（プレジデント ウーマン オンライン） | “女性リーダーをつくる” 2023.10
  • 論破しようとせず、フィードバックを求める
  • 記録に残す。１対１ではなく複数人いる場で伝える

• Noを伝える技術 #pmconf2021 - Speaker Deck 2023.9
  • こちらの立場をわかってもらう
  • 相手の話をよく聞く
  • どのような価値があるか共通理解を持つ。できれば数値化する
  • 必要になるコストを説明する

• 交渉の目的は「相手の説得」ではない　ビジネスで両者が合意できるゴールを達成するための3つのポイント - ログミーBiz 2023.8

• ｢この仕事量､本当に無理です…｣と上司に相談しても､｢もうちょっと頑張れ｣と返されてしまう本当の理由 感情ではなく､根拠と証拠をセットで話す (3ページ目) | PRESIDENT Online（プレジデントオンライン） 2023.1

• 「プロジェクトマネジメントの基本が全部わかる本」は序盤から『交渉』について書いてるところが良いと思った - フジイユウジ::ドットネット 2022.12

• 上流工程の問題解決 仕様変更編 2014.2

• 交渉や調整で「やってはいけない」いくつかのこと 2011.8.24
  • 1. 相手の面子を潰してはいけない
  • 2. 間違い探しに終始してはいけない
  • 3. 自分の主張を誇示してはいけない
  • 4. 相手の言ってることを鵜呑みにしてはいけない
  • 5. YESを無差別に使ってはいけない

• 返し方のTipsを学ぶより説明の方法を模索しようよ 2011.11.9

• 無理な注文には「なるほど」と言ってみよう 2010.7.12
  • 前向きに問題を解決しようとマインドセットを起動するのが、「なるほど」という言葉。起こることすべてには理由があり、その理由が分かれば「なるほど」と思えるはずだという姿勢です。クライアントが無理難題を言うときには、その理由があるはず。それが分かれば、注文そのものは無理なものであっても、何かしら解決案が見つかるものです。

• 「簡単ですよね」という挑発
  • そんなわけで、「簡単ですよね」という問いに「はい」と答えつつその「陰謀」を蹴る方法はいくらでもある。大事なのは、こういった問いは「挑発」の一種であり、必ず何か「余分な仕事」がついて来るということだ。その「余分な仕事」を避けるには、「技術的には簡単だけど実行するのは難しいと伝える」ことだ。

• 目的を忘れてはいけない 2009.10.9
  • システム開発プロジェクトでは，どうしても「物作り」の部分に焦点が当たってしまい，本来の目的を見失いがちである。確かに「物作り」は大事である。発注側である顧客ですら物作りばかりを気にする場合も多い。しかし，プロジェクトの本質は業務改善であり，システム開発やパッケージ導入といった物作りは，あくまでそれを実現するための手段である。

• ユーザーの機嫌を損ねる行為10選 2009.6.24
  • ＃1：見下した態度で相手に接する
  • ＃2：相手のスキルを過大評価した態度で接する
  • ＃3：相手の依頼を断る
  • ＃4：理解不能な相手だと思われる
  • ＃5：相手の説明を無視する
  • ＃6：独断的な態度で接する
  • ＃7：問題は「非互換性」にあると告げる
  • ＃8：ヒアリングや説明を十分行うことなく、また注意点をしっかり伝えることなく変更を求める
  • ＃9：コンピュータの使い方について口うるさく注意する
  • ＃10：ユーザーにとっての「自分のもの」という感覚を配慮しない

• 変更要求に対する選択肢 2009.3.4

• 顧客要求を安易に受けてしまう人の良いSE 2008.8.11
  • 変更管理委員会（CCB：Change Control Board）を設置して、ここで変更受諾の可否を決定すること 00第一に重要なことは、契約において仕様変更への対応方法をきちんと決めておくことである。具体的には、変更要求をどのように申請し、それに対してどのように採用の可否を決めていくかを決めておくことが重要である。
  • また、顧客と交渉する際に、自分たちの都合で変更要求を拒否するという姿勢ではなく、変更要求を受けることがプロジェクト全体にどれだけ影響があるかを説明しなくてはならない。変更要求の多さが結局は顧客にとっても良い結果をもたらさないということをしっかり伝えることが重要である。

• プロフェッショナルとして「NO」を言う
  • あなたがプロとしてＮＯを言うためには、2つの要素をきっちり述べる必要があります。
  • 1つ目は「ロジカルにこういうリスクがあるので、その意見には賛成できない」と言うこと。
  • 2つ目は「その意見に賛成できないのは、あなたや会社のために言っているのであって、自己保身のためではない」と言うことです。
  • 覚悟としては「自分はプロであり、ＮＯを言うことによって、ここにいられなくなっても信念を曲げることはできない。そうなったら他に移ってバリューを出そう」と思えるかどうかです。

• 顧客対応の超基本「○○はできます。ただし△△日かかります」 2008.7.11
  • まともなクライアントは、まともな相手を好む、ということを「オレンジジュース・テスト」は伝えています。まあちょっとできすぎた話ですが、私も請負を7年間やっていましたので、経験としても、この話は納得できます。
  • というのは、すぐやれ、と無理難題を言ってくるクライアントは、それを飲むと、要求がどんどんエスカレートしてくるのです。また、無理を聞いているうちに強固な上下関係が築かれ、馬鹿にされ、仲良くなりにくくなります。
  • 反対に、まともな反応をしつづけると、細かな失注はすることがありますが、長期的な関係をもてるクライアントが多くなります。

• アドホックな開発をしてはいけない 2008.5.22
  • PMは，例え進捗に影響を与えないような軽微なアドホックな変更要求であっても即答で了承してはならない。プロジェクトが順調に進んでいればいるほど，気軽に答えたくなる気持ちは充分理解できる。しかし，ユーザーに“当たり前感”を与えないためにも，一呼吸空けて返答すべきなのだ。
  • PMは，すべてのアドホック要求に対して，担当SEや営業担当者等と協議・合意した上で，対応を行うかどうかを決めるのが望ましい。また，ユーザーに対しては，プロジェクト開始時点で，どの範囲までならアドホックを受け入れるということを正式に書面で交わしておくことが重要である

デモ・プレゼンテーション†

• デモはものができあがっているように見せない 2007.1.1

• ダメプレゼン30の教訓

その他†

• IT・システム判例メモ 2022
  • 判例一覧 - IT・システム判例メモ 2022

最新の50件