ＩＴ技術者のための「交渉力」

研修参加者の感想
 筆者らは交渉力の研修を２～３日間で行っている。

参加した方々の受講後の感想を少しだけ紹介しよう。

研修や交渉というものを、ほかの人がどのように捉えているか、参考にしてほしい。
 なお、文体等はそのまま記載した。
 
１．これまでお客様との交渉は数多くやってきましたが、

今回の研修で知ったことのほとんどについて、できていなかったと思います。

過去にどんな交渉をしていたのかと思うと少し恥ずかしくなります。（４３歳・男性）
 ２．実際に自分で交渉（ロールプレイング）を行えた部分は非常によかったと思う。

録画していただいたので、自分の交渉が客観的に見られてよかった。（２８歳・男性）
 ３．ロールプレイング等、多少照れがあったが、

交渉する上で必要なものの考え方や進め方がわかりやすかったため、応用できると思った。（３３歳・男性）
 ４．実際に行ってみると自分の癖がよくわかったので、今後意識的に直していこうと思います。（２７歳・女性）
 ５．今回の体験を実生活に応用し完全に自分のモノにすることが必須だと思う。

（かなり困難とも思える）（２８歳・男性）
 ６．想定外のユーザの反論、反意に対処ができなかった。

どうしても対決方向にいってしまう。（３３歳・男性）
 ７．ユーザ役を体験することにより、ユーザの気持ち（感情）についてよくわかりました。

同じことをするにも手順によって良くも悪くもなると、あらためて実感しました。（３０歳・女性）
 ８．初めて聞く言葉が意外と多かった。

それが一般的なのか、この世界のものなのか悩むこともあった。

自分の悪い点が明白となり非常に良い経験であった。

えてして、自分の利益を考えがちだが、Ｉｎｔｅｇｒａｔｅｄという考えをもって行う大切さを知った。（４３歳・男性）
 ９．やはり交渉の前には必ず準備が必要であると、その必要性を感じた。（３０歳・男性）
 １０．ロールプレイングに入る前に少し間がほしかったです。気持ちの切り替えがうまくできませんでした。（４５歳・男性）
 １１．２日間という限られた期間内での研修でしたので、

各段階の進みが早かったです。もう少し時間をいただきたかったところがありました。（４２歳・男性）
 １２．交渉としては当然だと思ったが、実際行うと難しいと感じた。（４０歳・男性） 
 
上手に話すコツ
 
交渉力のベースになります
 
これまでに、上手な話し方というのを随所で取り上げてきましたが、

ここでそれらをまとめておきます。

フェーズやステップ、またどんな話の内容かを問わない、

一般的に共通する事柄ですから、交渉力のベースとなります。
 
①難しく考えないで、「キチンと」話すことを心がける
 話すことに苦手意識をもっていると、イヤだなという気持ちのために、

もそもそと話すことになり、逃げに入りがちです。

それを振り払って、とにかく、しっかりと「キチンと」話せばいいのだと、まずは考えましょう。
 「立て板に水」のごとく話すことが目標ではありません。

芸能界で活躍することを狙っているわけではないのですから、

おもしろおかしく、必ず笑いを取らなくては、というレベル

（これには、努力ではなく才能と運が必要です）での工夫は必要ないのです。
 また、周りの環境によっても意外なほど話し方は変わってくるものです。

性格や資質で全てが決まるわけではありません。
 「口下手でもいい」くらいに気軽に考えましょう。
 
②相手を見て話す
 相手を見ることが鉄則です。

３～４割くらいの人が相手を見て話していません。

相手を見なければ、自分のいったことに対する相手の反応がわかりません。

相手の反応に対して自分が反応するのがコミュニケーション（→交渉）というものです。
 目と目を合わせるのが究極ですが、

それは疲れますので、通常は相手のあごかネクタイの結び目あたりを見ましょう。
 相手が複数いる場合は、

特定の人（目指すはキーマンです）だけでなく、

関係する人全部をまんべんなく見るようにしましょう。
 
③身振り、手振り、表情などに変化をつける
 どうすれば効果的かというよりも、

少しも動かないというのがいけないのだと考えてください。

生きているのですから、動きをつけましょう。
 「Ｃａｓｅ１　あるＰＬとＡさんとの交渉例」に出てくるＰＬには、

全くといって表情に変化がありません。

それが交渉全体が一本調子であることの象徴です。

そういう手抜きではなく、相手を引きつける工夫をしましょう。
 たとえば、話の内容に応じて自然に手を動かす、

大きくうなずく、笑顔を出したり真面目な顔になったりする、

立って話をしているときには意図的にちょっと歩く、

体の向きをまめに変えるなどです。

プロジェクター等を使っているときに、そちらばかり見るのでなく、あちこち向きを変えましょう。
 
④一言ずつハッキリ発言する
 率直にいって、手抜きをしておいて

「上手くいかない」と嘆いている方がいるのです。

いい加減にすませないで、一言ずつ、口をしっかり開いて、

あるいは使って、明確に発言しましょう。

話が下手というよりも、一言ずつハッキリと話していないことの方が多いのです。

特に、語尾はフェードアウトではなく意図的に力を入れていい切りましょう

（基本は「です。ます。ございます」）。
 話し方のトレーニングというと、

「あえいうえおあお」を一言ずつハッキリと大きな声で話すことから始めるのが常套手段です。
 また、言葉と言葉の間の「間（マ）」を取りましょう。

相手にわかってもらおうという気持ちがあれば、

わかりやすくするために、必然的に一言ずつの間を取ることになります。

ワンセンテンスごとに「間」を取るようにしましょう。

「間」が大切なのは、スポーツ、演劇、楽器演奏などと同じですね。
 声の大きさですが、「大きな声」で話す、と考えましょう。

一言ずつハッキリと話せば、必然的に十分な声の大きさになっていくはずですから、

声が小さいことはあまり気にしなくてもいいのですが。
 また別の観点でいうと、交渉においては相手に対して勢いでは負けるな、

ということもあります。

そうしようと思えば、声の大きさも相手の勢いに負けない大きさ、ということになります。
 
⑤メリハリをつける
 たとえばサッカーやテニスなどでも、「単調な攻め」では良いゲームはできません。

何事にもメリハリが大事ですが、話し方においても同様です。以下のことに配慮しましょう。
 ・ワンセンテンスの中では、どの単語を強調するのか？
 ・プレゼンテーションでは、どのセンテンスを、あるいはフレーズを強調するのか？
 ・今日の交渉では、どこをポイントにするのか

（どこで身を乗り出すのか、真剣さや熱意をどこで出すのか）？
 ・相手のいうことに対して、自分は引いて聴き役に徹するときと、

すぐに反応して相手をリードしようとするとき等、

意図的にどこでどうするのか？

（その状況判断を意図的に行うためにも、

ＩＷＰのフェーズやステップ、スキルを念頭に置いて交渉しましょう。

たとえば「アクセプト」では、原則はどうすると良かったのですか？　引く方ですね）
 
⑥わかりやすい内容にする
 話が上手だということは、突き詰めると、内容的にわかりやすいということになります。

内容的にわかりやすければ、多少言い方が下手でも相手にはちゃんと通じるわけです。

この当たり前のことを十分に認識しておきましょう。
 では、わかりやすいとは、どんなことでしょうか？
 難しい言い回しをしないということです。

したがって、相手のレベルに応じて専門用語を使うといったことも大切です。

また、ワンセンテンスでは１項目、にしましょう。

一度にあれもこれもいおうとせずに、１つずつやりましょう。
 また、筋道を立てて、論理的に構成することが重要です。

この点がキチンと押さえられていれば、相手にとって理解しやすいものになります。

論理的にするために、大項目、中項目、小項目の整理はキチンとしましょう。
 この前提は、話す内容を自分がよくわかっている、という点です。

よくわかってもいないことを上手く話そう

（ハッタリでなんとかしよう）とする人がいます。

これでは上手くいかなくて当たり前なのですが、

意外と、これで失敗していることが結構あるのです。
 また理解しているだけでなく、自分が信じていなければなりません。

「本当はこの案は良くないと思っているのだが、

ほかに思いつかないからこの辺でまあいいか、主張しよう」程度で、

難しいテーマを相手にのませることはできません。信念が山をも動かすのです。
 
⑦身なり、姿勢をキチンとする
 身なり、服装や髪型などをキチンとしましょう。

また、姿勢は相手を見て話せば一応いいのですが、

あまり猫背だと映えません。背筋を伸ばしましょう。
 これらは、話し方と直接関係ないといえばいえるのですが、

相手に与える印象として、かなり大きな影響力をもっているので、

ばかにできないのです。

外見の良い人のいうことは信用しても、

貧相な印象の人がいうことには疑いを感じてしまうものなのです。
 なお、服装や髪型の「キチンと」の基準は何かというのは個人の趣味の問題が入り、

一律では決めがたいものです。

しかし、奇抜でないこと、ということはいえると思います。

また考え方としては、「自分は他人からどう思われたいか？」

という点でチェックするとよいでしょう。

ＩＴ技術者のための「交渉力」

交渉をシミュレーションする
 
職場でのトレーニング方法を紹介します
 
では、交渉のトレーニング方法を具体的に紹介します。

頭でわかっていても、いざ実践となると難しいものです。

シミュレーションを行ったりして、トレーニング（練習）するとよいですね。
 まず、交渉のスタートから合意に至るまでの全プロセスをシミュレーションして、

交渉の進め方やスキル、つまりＩＷＰを理解するとよいでしょう。
 また、実際に交渉する際の事前準備としても、

シミュレーションを行うことが必要です。

すでにわかっている状況を踏まえた上で、

今日の交渉はどのようなに進めるのか、進めたいのか、

つまり、交渉のシナリオを作って臨まないとコントロールできません。
 これによって、全体を通して見て、

理解を深め、事前準備のやり方、シミュレーションのやり方をイメージしてください。
 さらに、実際にあった例を「Ｃａｓｅ２」のような形にまとめて、

社内で交渉力の勉強会をするのも効果的です。
 では、その代表的な方法、

ロールプレイング（「役割演技」）で行うやり方を、以下に紹介しておきます。
 
◎職場でのトレーニング方法
 １．状況設定：社内で実際にあった典型的な事例を整理して、

状況設定する（「Ｃａｓｅ２」のようなものを作る）。

ＳＥ・ＰＬは知らないが、ユーザは知っている情報が当然あるので、それも用意しておく。
 
２．役割分担：ＳＥ・ＰＬ役、チェック役を作る。
 
３．事前準備：ＳＥ・ＰＬ役は、ＩＷＰに基づいて、

ユーザに対してどのように交渉を進めたらよいかの構想を練り、準備する。いわばシナリオを作る。
 
４．ロールプレイング実施：状況設定に基づいて模擬的に交渉を行う。

１０～１５分程度に限って行う。

実際の交渉時間はもっと長いことが多いが、

長くするとだらだらとなり、かえってポイントが見えにくくなる。

できればビデオに撮り、あとでの検討に使うとよい。
 ＩＷＰのプロセスを全部、もしくは半分を凝縮して行う。

状況設定中の＜ユーザ役だけが知っていること＞を見ながら、

ＳＥ・ＰＬ役の話がその内容に合致しないようなときは、遠慮なくＳＥ・ＰＬ役に反論する。
 
５．振り返り：ロールプレイングが終わったら、必ず振り返りをする。

「チェック役」は、感想や経験談で終わらないように、

ＩＷＰの観点で「チェックリスト」を事前に作っておき、

それに基づいて良い点、改善するべき点をコメントする。

ロールプレイングによる「練習」が効果的なものになるか否かは、

このコメントの的確度にかなりかかっている。

人の振り見て我が振り直せで、

チェック役は自分の交渉力をチェックするつもりで行うとよい

（実際の交渉では、セルフチェックすることになる）。
 また、ＳＥ・ＰＬ役は、マイナス面を指摘されるとどうしても「言い訳」をしたくなるものだが、

素直にそのまま受け入れるとよい。

「聞くは一時の恥、聞かぬは一生の恥」だ。
 
Ｃａｓｅ２　状況設定例～仕様設定～
 テスト段階（納期まであと１．５ヶ月）で、

ユーザから一部機能を追加する仕様変更の依頼があった。

基本設計作成時には見えてこなかった使用上の問題点が発覚し、

ユーザの担当者から依頼を受けた。

対応可能なのか、または別途請負作業なのかを見極めて、合意形成を図る。

 ■ユーザ会社概要
 会社名：あさひスーパー
 業種：生鮮野菜、食肉販売小売業（やや高級志向）
 年商：１６０億円
 社員数：１５５名
 店舗数：３０店舗　ホームセンター３店舗
 
■ユーザ担当者プロフィール
 氏名：藤堂俊介
 役職：店舗運営部長
 年齢：４９歳
 システム開発キャリア：１年
 
■システムの概要
 システム名：宅配管理システム
 システムの目的：電話注文等に対応して、各家庭に宅配を行うための販売管理システム 
 
開発方針：高齢者や介護老人を抱え、

買い物になかなか出ていけない主婦層を対象に、

電話やインターネット注文で各家庭への配達を行う。
 郊外店を除く都心部店舗を中心に、

注文を受けた商品項目・数量を配送部（３ヶ所）で一括管理し、

午前・午後の２回に分けて配送する。

その際に、お客様の住所を地域別に選別し、

配送経路を示す機能と顧客データベースへの落としこみを図る。
 
■このシステム開発の現状と問題
 ・要件定義はユーザ側が担当。開発側は基本設計～詳細設計段階を担当。
 ・システムは自社製の宅配管理パッケージを使用しており、スーパー対策用にカスタマイズを行った。
 ・ パッケージはピザのフランチャイズ店舗用に開発されたものなので、

数量設定や品名項目が単純だったが、スーパーの扱い品目用に大幅改定を行った。
 ・ところが、テストの段階で、数量（グラム単位）と料金の比率値が時期により異なることが多いと判明。

料金算出方法が一定して組み込まれているために、

日々変化する野菜の値段や品質によって異なる肉類価格変化に対応できないことがわかった。
 ・納期変更はできず、追加予算も現状では考えられない。
 ・バグが多発していて、仕様変更を受けなくても納期を守るのが難しい情勢である。
 
■交渉のスタート時の状況
 最終テストを実施した場面で仕様変更要求が発生。

要望に対して、当社の対応を回答するために交渉を行うことになった。
 
◎＜ユーザ役が知っていること＞
 注：以下の事項を、ＳＥ・ＰＬ役は知らないでロールプレイングを行います。
 一方、ユーザ役はこれに基づいて対応します。
 
●ＳＥ・ＰＬの主張内容に対するユーザの反対意見（ＯＧフェーズのステップ３で反対する内容）
 今回要請した機能は、宅配を始めるに当たって重要なファクターなので、

ぜひとも追加してもらいたい。

カットオーバー後に追加するのは、従業員の再教育や電話注文方法の途中変更を余儀なくされるので避けたい。
 納期は厳守。宅配のスタート時期をずらすことは難しい。
 
●ユーザ側の事情・背景

（ＣＭフェーズでＳＥ・ＰＬが聴き出さなければならない情報、ユーザ役が聴かれたら答える内容）
 ・お客様からの注文時に、

手間取った対応をすれば、一度試しに注文してくれたお客様からのリピートオーダーにつながらない。
 ・システム稼動の社内テストとシミュレーション計画の短縮で、

少しは納期に関して対応できるかもしれない。
 ・宅配サービスのスタートは、カットオ－バー後すぐである。
 ・顧客層はやや高級志向にして、客単価を上げていきたい。低価格だけの勝負から脱皮したい。
 ・流通業界において、「価格競争以外に他店舗との差別化がなかなか図れない」

という問題点があり、今回の宅配サービスのスタートで顧客との密着化を図る経営方針が出ている。
 ・宅配サービスについては今回がテストケースなので、

それほど大幅な予算が計上されていない。
 ・宅配を行うのは住宅地がそれほど離れていない都心部だけである。

郊外店舗では配送の輸送費用がかかるという理由で見送られているが、

今回のプロジェクトである程度の採算性が見込めたら全店舗に展開していきたい。
 ・顧客管理を、この宅配をきっかけに見直したい。

したがって、顧客データベースの作り方、活用の仕方も今後レベルアップしたい。
 ・運営指導（社員教育）については、

多少切り詰めて行うことが可能なので、納期遅れは２週間程度なら許容できる。
 ・画面の変更依頼は別紙の通りにしてほしい。
 ・バグはそちらの問題なので、それを理由に納期を遅らせることはできない。
 ・当社人員はぎりぎりでやっているので、人的応援は不可能。
 ・料金設定を手動入力すると、お客様との応対に時間がかかるため、自動設定で行えるように設定変更したい。
 
（次の項目「ユーザ側の思い」は、以上の情報を要約したもの）
 
●ユーザ側の思い（ＣＭフェーズで合意したい内容）
 品質を改善して、納期、予算共に当初計画したとおりで納めてほしいが、

こちらの要件定義にも問題がなかったわけではないので、

料金追加は多少なら仕方がないと考える。

しかし、宅配のスタート時期については、

経営戦略上の重要項目であるために避けていきたい。

今後も協力してもらえるところはしてもらいたい。
 
（以上の「ユーザ側の事情・背景」と「思い」を基にして次の「解決策」を作る。

ＳＥ・ＰＬ役は、ロールプレイングの中で聴き出せたことだけから解決策を作る）
 
●解決策の提案例（ＳＬフェーズで提案したい内容）
 注：もちろん、現実的には解決策としてはいろいろな可能性がありますので、

以下に限るわけではありません。

ユーザ役が納得すれば、ほかの解決策でも構いません。

ただし、「ユーザ側の事情・背景」は、制約条件とします。
 
Ａ案：納期１ヶ月延長（宅配サービスも１ヶ月遅れ）
 　　　メリット：■品質的に万全なものができる
 　　　　　　　　■バグ・画面変更・機能追加（宅配サービス）の全てに対応できる
 　　　　　　　　■費用増大はＢの１／２、Ｃの１／３
 　デメリット：■１ヶ月分の費用増大
 　　　　　　　■宅配サービスのスタート遅れ１ヶ月（経営方針に反する）
 Ｂ案：画面変更は２ヵ月後、機能追加は完全な形では１ヵ月後（１ヶ月間は手作業で対応）
 　　　メリット：■宅配サービスは予定通りできる
 　デメリット：■費用増大（Ｃ案より少ないが）
 　　　　　　　■１ヶ月間電話応対の手作業が増える
 　　　　　　　■２ヶ月間使いづらい
 　　　　　　　■２ヶ月間バグ対策が続く
 Ｃ案：自動テスト方式を導入、機能追加は対応、画面変更は１ヶ月後、人員増（開発側） 
 
　　　メリット：■宅配サービスが完全な形で予定通りできる
 　　　　　　　　■品質も万全
 　デメリット：■費用増大　Ｂ案より３０％増、Ａ案より６０％増
 　　　　　　　■画面変更は１ヵ月後
 （■費用増加分の半分は開発側でもつ
 （ただし、次期案件の受注を条件として））
 
●最終的合意内容のワク取り（ＩＷＰフェーズで合意したい内容）
 宅配サービスを優先に解決してもらいたい。

当面なら、使い勝手は多少なら目をつぶってもやむを得ない。

これからの顧客データベースについて、

情報システム面での総合サポートを支援してほしい。

具体的な次期要件を、今回次第では考えてもよい。

費用追加については、開発側も考えてほしい。
 
（ＳＥ・ＰＬが、この方向で具体的に詰めることができれば、

ユーザは最終的に合意するが、そうでない場合は決裂する）

ＩＴ技術者のための「交渉力」

スキル８　プシュザバック
 最終決定に対するためらいを処理して決定します
 
いよいよ交渉の最後の段階です。相手のためらいを解消して、最終案を決定します。

相手を決定に向かって「プッシュ；押す」のです。相手の「ザバック；背中」をひと押しするのです。
 交渉の最後で、次のような中途半端なことにはならないようにしましょう。
 
「最後に今日の話をまとめさせていただくと、Ａ案ということでよろしいでしょうか？」 
  
→【この言葉に対するユーザ側の気持ち】　

オイオイ、１時間以上話して、最初に出てきたＡ案でよいかだって？

　何を１時間話したんだ！　こちらの言い分を取り入れる気はないのか
 
「仕様の詳細についてはここではご返事できませんので、後日あらためて・・・」
→【この言葉に対するユーザ側の気持ち】

　詳細がここで決められなくてもいいけど、今日決まったこともあるだろう？
 
「では、納期厳守、予算内で、機能はご要望を全て盛り込むということでよろしいでしょうか？」
→【この言葉に対するユーザ側の気持ち】

　ああ、よろしいですよ。でも、そちらは会社としては困らないの？
 
「納期を守ることは現状では難しいので、また検討してきます」
→【この言葉に対するユーザ側の気持ち】

　ウン？　だから、今日の交渉があったんじゃないの？
 
「わかりました。では、そういうことで」
→【この言葉に対するユーザ側の気持ち】

　何が「わかった」の？　「そういうこと」ってどういうこと？
 
①狙い
 ①最終決定に対するためらいを処理して、決定する
 人は重大な決定になるほど「本当にこれでよいのだろうか？」

というためらいの気持ちが出てきます。

それを１つ１つ処理して、決定にもち込みます。
 
②ポイント
 ①相手のためらいの気持ちを聴き出し、つぶしていく
 人により「ためらい」の気持ちを積極的にいってくる人と、

あまりいわない人がいます。

いわないからといって、ためらいの気持ちがないのかというと、それはわかりません。
 そこで、こちらから聴き出す必要があります。

その上で１つ１つ決着をつけていきます。

この「聴き出し」と「つぶし方」が甘いと必ずあとで出てきますから、

ためらいを吐き出させることが重要です。
 「ためらい」の内容は、状況や人によりさまざまです。

観点は２つあって、「技術的」観点と「その他」に分けられます。

技術的観点の場合は、技術力は問題としても、

議論すること自体の困難度は高くないと思います。

「バグ対策はこれで本当に万全なのか？」

「そういうけど、レスポンスはもっと改善の余地があるのではないか？」

といったようなことですから、

技術者どうしの本音の話し合いは行いやすいでしょう。
 一方、「その他」の観点からの「ためらい」は、

実際の交渉で話がこじれる原因になることがあります。

感情が絡むことが多いからです。

これに対しては理屈だけではいけませんので、

上司とも相談して、

条件譲歩や「おまけ戦術」（ちょっとしたサービスをしてひと押しする）

を絡めていく駆け引きが必要になります。

「どちらの部門寄りにしていくのか」

「いったん良しとした手前・・・」

「これまでの付き合いがあるので・・・」など、

想定しなければいけない事情、条件はいろいろとあり得ます。
 
②タイミングを見て押す
 ただし、いつまでもためらいの処理をしていたのでは決定に至りません。

ある程度ためらいの処理をしたと思ったら、

とにかく押してみましょう。

ときどき押してみる、と考えるとよいでしょう。
 実は、この交渉の最後の段階、詰めにおける押す「タイミング」というのが、

昔から悩ましいところなのです。

早すぎるとためらい処理が不十分になりますし、

遅いとなかなか決まらないということになります。
 そこで予想される相手のためらいを事前準備しておきましょう。
 それを交渉の場でつぶしてください。

用意したものがなくなったら、押してみてください。

決まらなかったら質問をしてみてください。そして、また押すのです。
 
③今日決めるという気持ちで
 この段階では、決めるということに最大の価値を置きましょう。

また明日がある、というのではなく、今日決めるという気持ちで行いましょう。
 
③やり方
 １．相手の心配ごとを聴き出したり、相手の不安を質問に変えていきます。

ためらいを吐き出させるのです。

本音を聴くつもりで行いましょう。

相手の性格的なことまで踏まえて行えると理想的です。
 ２．相手の答えに対して補足説明をしたり、

リスクを分担することなどを説明して安心してもらいます。

あるいは、相手に共感を示して相手の感情面に配慮をします。

また、「では、～したらどうでしょうか？」というように、ここでも＋αのアイデアを付加していきましょう。
 単調にならないように、あの手この手でゆさぶりをかけていきます。

「どうでしょうか？」といった同じ言葉ばかりいうのではなく、

ここで紹介したようなことをさまざまに行うのです。
 ３．最後のひと押しをする条件譲歩をここで出すことができると、

詰めが効果的に行えます

（「スキル７　オプションセレクト」で条件譲歩を出し尽くしてしまうと、

スキル８で決める圧力をかけにくくなります。

そこで、１つくらいは温存しておくと理想的です）。

「それでは、その必要な工数の負担についてですが、

私どもとしては・・・とさせていただこうかと思います。

これでいかがでしょう？」のように行います。
 ４．そして、押します。

相手がこれでイエスといわない場合は、１．に戻って再度質問をし、

ためらいの原因を引き出します。

ここまできたのですから、理想（１００点）を目指すことが前提ですが、

現実的にこれで良しと判断できる最低ライン（６０点）に到達したと思ったら決めてしまいましょう。

「ためらい」のところでぐずぐずしているのは時間の無駄です。

出そうと思えば、ためらいはいくらでも出せるものです。

また、自分から「またきます」といって帰らないようにしましょう。
 なお、決まった事柄の確認や次回の約束などは、

本書では「ステップ１１　クロージング」でやることにしています。
 
Ｑ＆Ａ　２３
 Ｑ：プッシュザバックは、相手に納得して決めてもらうことが重要である。

したがって、こちらから働きかけるというより、

相手がいってくることをよく聴き、相手が決めるまで待っているべきである？
 
Ａ：相手の言い分をよく聴くことは大切ですが、今は決めるところです。

多少相手がためらっていても、決めるしかないという強い押しが必要とされます。

待っていては交渉はダメです。

受け身型では相手に有利になるばかりです。　答：ノー
 
Ｑ＆Ａ　２４
 Ｑ：相手に納得してもらうには、熱意や迫力といった、

理屈ではない部分に頼りすぎるのは危険である。

特にプッシュザバックで最後の詰めに入ったところで、

「私に任せてください」みたいな、熱意で押し切ろうとするのは邪道である？
 
Ａ：最後に入ったからこそ、熱意を表面に出して、

「私に任せてください」のような言い方も大いにやるべきです。

論理の一貫性は重要ですが、今はほぼ案が絞られていて、

ためらいの処理ですから、熱意で押しましょう。　答：ノー

ＩＴ技術者のための「交渉力」

スキル７　オプションセレクト
 解決策を絞り込みます
 
複数案を相対比較して、１つに絞り込んでいきます。

「オプション；選択肢」を「セレクト；選択」するのです。
 ただし、「選択」といっても単純に１案を選ぶのではなく、

ここでも、より良い案作りのために創造的に案を改善していきます。
 「では、各案の検討をさせていただきます。

Ａ案は～の点がメリットだと考えますが、～の点がデメリットだと思います。

課長様はいかがお考えですか？」という具合に始めます。
 
①狙い
 ①解決策を絞り込む
 複数の案を１つに絞り込んでいきます。決定にまではいきません。決定はスキルで行います。
 
②ポイント
 ①各案のメリット・デメリットをさまざまな観点から検討する
 比較的容易にできてしかも効果的な、メリット・デメリットの相対比較を行います。

各案ごとにメリット・デメリットを出し、

そのあとで全体的に見てどの案が最も良さそうかを検討します。
 
②お互いが率直に意見を出し合う
 もちろん、ＳＥが進んでメリット・デメリットの検討を行うのですが、

相手にも必ず意見をいってもらいます。

前の「スキル６　ブレイクスルー」と同じ考え方で、

統合的に、協働関係でやっていきたいからです。

「～と私は考えるのですが、貴方はいかがお考えですか？」と語りかけます。
 これにより、お互いが公平な姿勢で案の検討を行えます。

自分の出した案にこだわることなく、客観的に検討していきましょう。
 
③判断基準をしっかりもつ
 検討するときには、何をもって良いとし、悪いとするのか、判断基準を明確にもっていることが必要です。
 その場の雰囲気に流されたり、相手に迎合したり、

自分がいい出したのでそのメンツでいい張ったり、

といったようなことが実際にはあります。

自社と相手（組織）の経営メリットを、

具体的に判断基準としてもって臨みましょう。
 
④条件面はここで出す
 いよいよ条件面はここで出して、できるだけ決着をつけていきます。

「できるだけ」というのは、

ここで決まらずに次の「スキル８　プッシュザバック」にもち越すことがあり得るからです。

ただし、大半はここで決めることが望ましいです。

もち越しが多いと、次で決めるのが大変です。
 
⑤統合的に、案をより良いものに改善する
 メリット・デメリットを検討して１つに絞る過程で、

各案の細部の検討をすることになりますが、

その際には、各案の良いとこ取りをしてさらに新しい案作りをするくらいのつもりでやりましょう。
 「それでは、Ａ案の～をＢ案でも行うことにしたらどうでしょう？」のように提案するわけです。
 
③やり方
 大きくは２段階になります。
 １．メリット・デメリットの検討を各案ごとに行います。
 ２．各案の優先順位づけを行います。
 こうして１案に絞り込みます。またこの過程で、条件面の話もします。
 ①メリット・デメリットの検討
 事実に基づいて、できるだけ数字を使って定量的に客観的に評価し、説明します。

事前準備が肝心です。

各案ごとに評価基準がバラバラにならないように統一します。
 なお、一方的な説明で終わらないよう、

必ず相手にも意見をいってもらってディスカッションするようにしましょう。
 
②優先順位づけ
 【絞り込み】
 ・複数案の中から「自分はＡ案が、～の理由でよいと思いますが、

貴方はどうお考えですか？」と問いかけて、絞り込んでいきます。

自分の意見をいわないで、相手に「この案でいいですか？」と問いかけるのは、

自分の意見がないことになります。

プロとしては失礼な態度です。
 ・ここで、相手も「Ａ案でいいです」といえば、即（もたもたせずに）「わかりました」といって、

次の「スキル８　プッシュザバック」に入り、Ａ案の細部の詰めを行います。
 ・自分がＡ案でも、相手が「Ｂ案がいい」といって、

意見が分かれた場合は、そのＡ案・Ｂ案の２案に絞って検討します。

できるだけ早く２案に限定してしまい、議論の焦点を絞りましょう。
 ・お互いに、「どれもマズイなあ」となったら、

残念ながら、１つ前のＳＬフェーズ、さらに前のＣＭフェーズにまで戻ってやり直しをします。
 【２案の検討】
 ・「安易に迎合しない」ようにします。

交渉がスタートしてからやっとここまできたのですから、

ここで話を壊したくないという気持ちが出て、

「まあ、この辺でいいや」と安易に相手に合わせたくなる気持ちもわかります。

しかし、ここでいい加減な案にすると、

あとになって、自分が最も困ることになります（相手も困ると思いますが）。

もうひと踏ん張りして、良い案作りを行いましょう。
 ・もちろん、自分の意見を通すことにこだわらないようにしましょう。

ここは勝ち負けの気持ちに陥りやすいですから、統合的立場を意識しましょう。
 ・「やりやすさよりも効果を」と考えて判断しましょう。

ここでの「やりやすさ」とは、自分の作業のしやすさのことです。

「効果」とは、相手の経営メリットのことです。

もちろん自社の経営メリットのことも考えますが、

ここでは、相手のメリットを前面に出した言い方をしましょう。

Ｑ，Ｃ，Ｄを含めた判断基準をしっかりもっておきましょう。

自分のやりやすさは、そのあとで考えます。
 【条件面を詰める】
 条件面は、ここで出していきます。

「その工数の件なんですが、私どもとしては・・・」のように、

関連した話が出たら、その場で決めていきましょう。

条件を詰めることができないと、解決策の絞り込みの妥当性が判断できませんから。
 ただし、条件面は、譲歩ということができないと、

解決策の絞り込みの妥当性が判断できませんから。
 ただし、条件面は、譲歩ということを視野に入れておかなければいけません。

その場の思いつきではなく、事前に社内で、

今日のこの交渉で自分に許される条件譲歩の範囲はどこまでかを明確に決めてから交渉に臨みましょう。
 交渉最中にその場で対応できない、というのでは困ります。

お互いに時間の無駄になりますし、

相手に自分を低く見積もられてしまいますから、

今後の交渉が不利になります。
 もちろん、予想もしない条件の話（値引き要求とか）が突然出てくることはあり得ます。

そのときは、うろたえて安易な回答をせずに謝って次回に回しましょう

（「えっ、それでは御社のご要望に沿う形にさせていただきます」

→「えっ、たいへん申し訳ありませんが、社へもち帰らせていただいて、検討させてください」）。
 
Ｑ＆Ａ　２１
 Ｑ：オプションセレクトは、メリット・デメリットの検討をユーザ（相手）の立場に立って検討するものであって、

自分（自社）のことは考えるものではない？
 Ａ：設問の表現がやや微妙になっています。

しかし、最後に「自分（自社）のことは考えるものではない」というところが、間違いです。

そこまでいい切らない方がよいのです。

統合的立場を目指していますから、自社のメリットも当然考えに入れます。

ただし、交渉の場では、自社のメリットについてはあからさまにはいわない方が、

誤解を受けないので安全です。　答：ノー
 
Ｑ＆Ａ　２２
 Ｑ：オプションセレクトは、各案の良し悪しを検討するため、

当該部門の状況をよく踏まえなければいけないので、

一般的な判断基準をもとうとしてもあまり役に立たない？
 
Ａ：「一般的な基準」というのをもとうとしないと、

客観的な基準作り（その観点は

「ステップ９　各解決策の検討」も参照）が自分の中で進まないので、ノーになります。

いつも、その場限りの思いつきか、過去の狭い経験で終わってしまうことになります。

一般的な市場の要求は何かを、よくふまえることが必要です。
 ただし、ある程度の一般的な基準が身についたら、

「当該部門の状況」に落とし込んで考えなければいけません。

言い方としても、「こちらの部門では～という事情がありますので、・・・」となります。

一般的なものの言い方では相手は納得しません（「うちにはうちの特殊な事情がある」などのように）。　答：ノー

ＩＴ技術者のための「交渉力」

スキル６　ブレイクスルー
 相手と一緒に考え、新しいアイデア・解決策を生み出します
 
課題に対する解決策を作り出します。

できるだけより良い案を作りたいので、

「ブレイクスルー；現状突破、限界突破」するようなアイデア作りを行います。
 
①狙い
 ①相手と一緒に考え、新しいアイデア・解決策を生み出す
 課題解決する案を作ります。プロのＳＥとして、

自らが素晴らしいアイデア創出を心がけますが、

同時に協働作業として、相手にも考えてもらいます。
 
②ポイント
 ①できるだけ複数案を作る
 できるだけ複数の案を作ります。

そしてそれを並べます。

つまりリストアップします

（それで、ＳＬ（ソリューション・リストアップ）フェーズという名前をつけたのでした）。

選択の幅を広げ、議論をしやすくし、柔軟性、創造性を高めるためです。
 
②自分と相手の両者にとって利益となることを目指す
 自分、自社にとってメリットがなければ困りますが、

相手にとってもメリットがある案でないと、

相手が納得するわけがありません。

足して２で割るという妥協的な案を目指すのではなく、

両者のメリットを極大化する案作りを目指します。

勝ち負けではなく統合的にアイデア創出をしましょう。
 
③実現の可能性を問わない
 案を考えるときには、実現の可能性をあまり考えない方がよいでしょう。

なぜなら、まず実現可能性が高いものを、と考えはじめると、

当然これまでに経験のある、実績のあるアイデアを考えたくなってしまいます。

すると往々にして、

斬新な、まさにブレイクスルーするような案は思いつかなくなる傾向に向かうからです。

過去の延長線から抜け出るのは、いうほど簡単なことではありません。
 
④論理的整合性に注意する
 論理的整合性に注意を払いましょう。

プレゼンテーションでの主張、SLフェーズで聴き出したことや課題、

それらとここでのアイデアとに整合性がないといけません。

首尾一貫性があるかに注意しましょう。

そのためにも、アイデア・解決策の説明のやり方は、

「プレゼンテーション」のスキルを使って行いましょう（スキル２）。
 
③やり方
 ①壁を作らない（組織の壁・技術の壁など）
 アイデアを考えるときには、

自分だけの能力ではなく、組織全体の能力を活用しましょう。

しかし現実には、部門が異なるとお互いにどのようなノウハウをもっているのかがわからず、

使えるノウハウがほかで生きない、ということがあります。

つまり、組織が壁になってしまうのです。

最近ナレッジマネジメントということで、

この点を克服する努力が始まっていますが、

なかなか難しいのが現状で、今後の問題です。

とりあえずは、インフォーマルな情報網というのを作っておくと便利ですね

（こういうことはどこへ、誰に聴くとよい、という情報網）。
 また、技術の壁というのもあります。

既存の技術でそこそこ上手くいっていると、

それにとって代わる新技術の導入には心理的抵抗感があるものです。

それを超える気持ちをもって、論理的に判断することが大切です。
 
②やりたくないから解決策を作らない、ではなく、一度解決策を作ってみる
 ここでの解決策（案）というのは、多くの場合、

決定したら自分が作業をしなくてはいけません。

ですから、自分がやりたい、やりたくない、が先に立ってしまいがちです。

そうなると、自分のこれまでの世界の中だけで考えることになり、

革新には向かわない危険があります。

とにかく案を作ってみて、実際にやるか否かは次のフェーズで決めればよい、

という考えに立って作りましょう。
 
③A or BからA＋B＝C（統合）へ。これを目指す
 いよいよC案を作るのです。
 
④相手の意見を否定しない
 相手にもアイデアを出してもらうのですが、

その際、相手が案を出したら、それを否定することはいわないようにします。

評価は次のフェーズで行います。

否定すると、出たかもしれない良いアイデアが埋もれてしまう危険があります。

人は否定されると面白くないので、次に考えたくなくなるものです。
 特に、相手が自分より立場が低い場合（プロジェクトメンバーや外注先など）は、

この点に注意しましょう。

つい「あっ、それはダメです」と頭ごなしにやってしまって失敗することがあります。
 
⑤発言は全て記録して、あとの展開に備える
 お互いの発言は、役に立つ／立たない、採用する／しないにかかわらず、

記録しておきます。

あとで役に立つことが出てこないとも限りません。
 
⑥アイデア・解決策を考え出すことと、それを評価することとは必ず分ける
 SLフェーズ（つまりこのスキル６　ブレイクスルー）では、

アイデアを出すだけで終わりにしています。

アイデア、解決策候補の検討や評価は一切行いません。

評価は、次のＩＷＰフェーズで行います。
 評価を行うと、（否定と同じように）出たかもしれないアイデアが出なくなる恐れがあるからです。

アイデアを出し切ったことを確認してからこのSLフェーズを終え、次のＩＷＰフェーズに入りましょう。
 このアイデアを出すときと評価するときを分けることが、

創造的な議論をするときのコツです。

交渉に限らず、ミーティングなどで複数の人と協働で案作りをするときも同様です。

ごっちゃにやると良い案作りに向かわないだけでなく、

堂々巡りしやすくなります。

そして最後は、役職の高い人や、声の大きい人の案が通ることが多くなるのです。
 少なくとも案を出すときには、

その場にいる全員が可能性を求めて、

案を出そうとして考えることです。

たとえ結果的に案が出なかったとしても、

考えることが必要です。

ある人は案が出てくるのを待っているだけ、

またある人は問題点を蒸し返しているといったように、

バラバラに頭を使っては創造的な議論はできません。
 
⑦相手を評論家にしないよう、作成に参画させる
 「貴方は案を作る人、私はそれをチェックする人」という、

評論家的姿勢を取るユーザも結構います。

これに乗せられて、ＳＥの側でも一生懸命に案を考え説明して、

ユーザにチェックされ続けることになることも、現実には多くあります。
 確かにお金をもらって仕事をしているITのプロとしては、良い案を出すべきです。

しかし、あくまでもユーザ業務に関わるシステムなのですから、

ユーザにも考えてもらうべき事柄です、

結果的に良い案が出るかどうかは別にして。
 また、より良い案を作りたいのですから、

自分の頭脳や思考の範囲内だけではなく、

相手の頭脳も活用して、相手と話し合う中から、

さらに良いアイデアを作り出していきたい、

生み出していきたいのです。

相手と議論する中からアイデアを創造する

（勝ち負けではなく）ということをしたいのですが、

これが現実にはあまりされていません。
 ３人寄れば文殊の知恵、

という言葉がありますが、

実際には、３人寄れば利害の対立、で終わることが多いです。
 「ほかに何か案はございませんか？」と、

相手にも案作りに入ってもらって、

つまり参画させて、創造的な議論をしましょう。

いつもアイデアが生み出されるとは限りませんが、

複数の人間で知恵を出し合おうとする場を積み重ねることが、

創造的なチームを作るのです。
 
⑧出し切られた提案の中から、解決策を選択するように相手を囲い込む
 この「スキル６　ブレイクスルー」で案を作ったら、

次のフェーズに入って案を評価し、決めていきます。

上で説明したように、案を作ることと評価することを分けるのがコツです。
 しかし、評価するフェーズに入っても、

「そういえば、こんな案もあり得るのでは・・・」などと、

前に戻って案をいい出す人はいるものです。

これに対応していると話が先に進みませんから、

案を出すときは出すだけ、評価するときはするだけ、

と相手をコントロールする必要があります。

そこで、案が出尽くしたと判断したら、

次のようにいって歯止めをかけます。

「では、このA、B、Cの３案でよろしいでしょうか？

ほかになければ、この３案の中から最終案を決めていきたいと思いますが、よろしいでしょうか？」
 
Ｑ＆Ａ　１９
 Ｑ：ブレイクスルーでは、現実的な案ができたら、

案を複数作ることにこだわらず、

プロである自分が主導権を取って、

早く次のフェーズに入って早く決めていく方がいい？
 
Ａ：確かにＳＥやＰＬはシステム開発のプロですから、

主体的に、責任をもって解決策を作っていきたいです。

「会議は踊る」みたいに、議論にばかり時間をかけるのは良いことではありません。

しかし、「考える時間」を正当に使うことも必要です。

また、相手に考えてもらうことも大切です。

これらの点の区別を自分なりにキッチリとつけて判断しましょう。

プロだからといって、独善的に自分のペースで進めないようにしましょう。　答：ノー
 
Ｑ＆Ａ　２０
 Ｑ：ブレイクスルーでは、案を作る際に自分（自社）の開発のしやすさもよく考えないと、

あとで自分の首を絞めることになる？
 
Ａ：開発のしやすさは、次のフェーズでよく考えましょう。

ここでは、結果的に開発ができた場合、その効果はどうかについて十分に考えます。

経験にもとづいて開発のしやすさを考えてはいけない、

というのではもちろんありませんが、

それに走りすぎると大して面白い案ができないものです。
 一般的にいうと、アイデア創出では経験が大事ですが

（さまざまな経験があればあるほど、いろいろな観点のアイデアが出る）、

逆に経験が思考を縛り、革新的なアイデアを出しにくくしている

（過去の延長線のアイデアで終わる）、ということを知っておきましょう。　答：ノー