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

ＩＷＰフェーズの進め方
 いよいよ最終的な解決策Ｃ策を合意します
 解決策の叩き台がいくつかできたので、

これからその内容を相対的に比較しながら１つの決めて（Ｃ案）合意します。

ＳＬフェーズと同様に、このＩＷＰフェーズでもアイデアを少しでも多く出して、

さらにより良い解決策にしていきましょう。

最後にキチンと詰めて、相手としっかり合意して、あとで問題が起きないようにします。
 ３つのステップで進めます。

複数案を１つに絞り込み、条件面を含めて細部を決め、相手と合意します。
 
ステップ９　各解決策の検討
 複数案のメリット、デメリットを検討し、１つに絞ります
 
一緒になって考えていきたいという姿勢を再度強調してから、

複数案の１つ１つのメリットとデメリットを検討していきます。

その際には、できるだけ相手にも意見を出してもらいましょう。

そして、複数案を相対的に比較していくと同時に、

各案でさらに改善できるところは＋αのアイデアを付加し、

さらに良いものにしていきます。

また、条件面の話もこのステップで出して、結論を出します。

そして、１つの案に絞り込んでいきます。
 
<協働の姿勢を確認>

それでは、各案のメリットとデメリットを検討して１つに絞り込んでいきたいと思います。

課長様にもご意見がございましたら遠慮なくご指摘いただいて、

少しでも良いものにしていきたいと思います。

よろしくお願いします

 <メリット・デメリットの検討>
 では、まず第１案です。

テスト環境を整備し、画面機能の変更には全て対応しようというものです。

このメリットは、エンドユーザ様の要望を全て対応しようというものです。

このメリットは、エンドユーザ様の要望を全て取り入れることができる点です。

具体的には・・・。
 デメリットとしては、テスト環境の整備に、ハード的な面で御社に少しご負担いただく必要がある点があげられます。
 また、本部の統計機能については、

カットオーバー後、１．５ヶ月後ということになりますので、

全ての機能が揃わないという点が・・・

 <相手の意見を聴く>

以上が私どもの考えですが、課長様はいかがお考えでしょうか？・・・

なるほど、そういう点もありますよね・・・

 <条件面の折衝>で、第１案の統計機能分についての１．５ヶ月の工数については、

大変申し訳ないのですが、御社にご負担いただきたいのですが。

といいますのも、今回はあくまでも仕様凍結後の変更ですので。

・・・そうですか、御社としては、初期の仕様範囲内とのお考えなんですね。

ところで、次期の開発と保守の件なのですが、

今、ほぼ私どもでやらせていただく方向と聴いていますが、

決定と考えてよろしいのでしょうか？

率直に申し上げて、そちらとの絡みで、

先ほどの工数分をどうするかを考えさせていただく余地はあるかなと・・・
 <＋αのアイデア付加>

どうでしょうか？第１案ですが、第２案にありますドキュメント類の作成を、

今から、御社のＡさん、Ｂさんに教育をかねてやっていただくというのは・・・
 <１つに絞り込む>それでは、総合的に考えて、私どもでは第１案が最も良いと思います。

というのは、エンドユーザ様の要望を取り入れていて、しかも、現状業務には悪影響が最も少ないという・・・
 課長様はいかがお考えでしょうか？
 ・・・
 そうですか、１案が良さそうだけれども、今ひとつというところですか。

２案、３案よりは良さそうでしょうか？・・・
 上記のように進めていくわけですが、その際には、次のようなことを踏まえて行いましょう。
 
①雰囲気に流されない状況対応力
 ＩＷＰフェーズのこのステップと次のステップは、

相手の出方に応じた、臨機応変な対応が必要とされます。

いわゆる、状況対応力です。
 もちろん、この状況対応力は交渉のどの場面でも必要ではあります。

たとえば、ＣＭフェーズで質問をして相手の考えを掘り下げて聴いていくところでは、

相手の返答に対してこちらがまさに適切に反応して、

あいづちを打ち、次の質問をしていかなければなりません。
 交渉というのは、本来的に、状況対応が必要な事柄です。

相手の出方を読んで交渉に臨むとしても、

相手がどう出てくるかに応じて進めていかざるを得ません。

こちらの思惑通りに進むのなら、交渉は必要ありませんし、連絡報告だけでよいわけです。
 この状況対応力が、

ほかのフェーズよりもＩＷＰフェーズの方により重要だというのは、

このフェーズが条件面にかかわってくる微妙な事柄を決める段階だからです。

工数の負担はどっちがどれくらいするのか、

どの機能を縮小するのかしないのか、

パフォーマンスはどの程度保証するのか等等。

開発作業に直結することで、

しかも、これがプロジェクトの採算を決めることにもなりかねないのですから、

その場の雰囲気にのまれて、安易に決めることはできません。
 熱意をもって、しかも冷静に、

数字的にキチンと考えながら状況対応を行う段階です。 
 
②根拠を明確にする
 このフェーズでは、いわば駆け引きが必要になってきます。

自分と相手の会社では、

表面的な意味では利害が対立してもおかしくないからです

（当然、ユーザ側はコストを少しでも抑えたいが、

ベンダ側としては少しでも沢山費用をもらいたい、

これはどちらが良い悪いの問題ではなく、

立場の違いです→６節参照）。
 とはいえ、単なる駆け引きと妥協の世界で交渉をしないようにしたいものです。

根拠を明確にして、是々非々で進めましょう。
 どれが良いのか、

やるのかやらないのか、１つ１つ判断を下していかないといけないわけですから、

何をもって良しとするのか、悪しとするのかを、

単なる感じやその場の雰囲気、相手に対する迎合、

自分の思いつきの押しつけ等にならないように、

具体的な根拠をもって決定しましょう。
 そのための具体的なやり方は、

昔から意思決定の手法として研究されてきましたが、

本書では、現実に簡単に実行できて、

しかも効果のある方法として、

「メリット・デメリットを比較する方法」を紹介しています。

各案のメリット・デメリットをあげて、

総合的にメリットが大きく、デメリットが小さい案に絞っていくのです。
 このとき、前のＳＬフェーズ、ステップ７で紹介した「⑤論理的整合性に留意する」と同様の考え方で、

論理的に考えて妥当かどうかで判断しましょう。

「なぜ、この案がほかの案より優れているのか？」という質問に、

論理的に答えることができるような根拠、理由を作って整理し、相対比較を行いましょう。
 
③勝ち負けではなく、創造的に１つに絞り込む
 最後のＩＷＰフェーズに入ってくると、ここで決まるかどうかという、

いわば瀬戸際に立たされるので、ここのフェーズでも勝ち負けの心理が働いてしまうことがあります。

自分の出した案を相手が素直にのもうとしてくれないと不愉快に思ってごり押しをしようとしたり、

その反作用ですぐに諦めてしまったりすることがあります。

また、相手が「これでどうだ」といってくると、

長いものには巻かれろだと思ってすぐに迎合して同意しようとしたりすることがあります。
 そうではなくて、論理的根拠に基づいて、具体的、定量的に検討していきましょう。
 そして創造的に、少しでも良い案に作り上げていくつもりで、＋αのアイデアを付加しましょう。

「では、こんなやり方を付け加えたらどうでしょう？」と。

相手と一緒になって考えましょう。
 いよいよ自分のＡ案と相手のＢ案を統合したＣ案を決めていくところですから、

最初に出した自分の案といい意味で異なっていくことを喜びましょう。
 勝ち負けの競争的交渉よりも、

統合的な交渉の方が、自分にとっても相手にとってもプラスになる、

メリットのより大きい案で決まる可能性が高いことを信じて交渉を行いましょう。
 
④すぐに引くな、押しつけるな、しかし決めていけ
 この決める段階に入ると、自分自身が強気になったり、

弱気になったり、不安に思ったりと、いろいろな感情が押し寄せます。

上の③で述べたように、ごり押し、諦め、迎合といったことをしたくなります。
 そこで、次のことに気をつけましょう。

スローガン風にいえば、<すぐに引くな、押しつけるな、しかし決めていけ>です。
 諦めたり迎合したりしてすぐ引けば、

波風が立たずに、相手にも良い奴だと思ってもらえるかもしれません。

しかし、それはその場限りのことです。

開発・作業が上手くいかなければ、

結局、相手は、貴方の責任にしてきます。

「あのとき、なぜ、これではない別の案を勧めてくれなかったんだ」

などといわれる結果にもなりかねません。

また、社内的にも、プロジェクトが赤字にでもなれば、

当然責任は貴方にかかってきます。

ですから、本当に相手に、そして社内的にも喜ばれることは何かを目指しましょう。
 なお、引いたことが結果的に上手くいった場合はどうでしょうか？

この場合は、ユーザからの貴方に対する評価は低くなります。

「私のいう通りだったでしょう。

これからも私のいうことを聞きなさい」と。

これが積み重なると、ユーザの使い走りにされてしまいます。
 だからといって、ごり押しの押しつけでは、決定を早めるかもしれませんが、

相手の納得感は乏しいものです。

その場は渋々収まったとしても、ちょっとでも問題が起これば、

鬼の首を取ったようにして貴方のことを責めてくるに違いありません。

「だからあのとき、私はおかしいと思ったんだ。

私の考えた通りになった。

いったい、どうしてくれるんだ」といい出しかねません。
 この押しつけの場合も、結果が上手くいった場合はどうでしょうか？

相手は感情的に面白くありませんが、それを正面切っていうことができません。

なんといっても上手くいっているのですから。

そこで、別の極めて些細なことにいちいちケチをつけてくるか、

いわばじっと復讐のチャンスを狙っているかです。

いずれにしても、信頼関係は構築できない方向に向かいます。
 そこで、あくまでも統合的に根拠を明確にして、

＋αのアイデアを付加していくのが良い方法です。

ただし、決めるべきことはキチンと決めないといけません。

中途半端のまま、だらだらとしていては時間の無駄です。
 
⑤条件面はここで出す
 納期、費用、機能削減等等の条件面の駆け引きはこのステップで出します。

では、ほかのフェーズでは条件面の折衝はどういうことになるのでしょうか？

前のフェーズのＳＬや、その前のＣＭ、さらには最初のＯＧフェーズでも、

チャンスと思えば条件闘争をしてしまった方がよいのでしょうか？
 基本的には、ノーです。しない方が良い、と考えてください。
 なぜかというと、明確な根拠に基づいて条件を決めたいわけですが、

その根拠の主なものが解決策です。

そしてその解決策は、このＩＷＰフェーズに入るまではできないからです。
 ＳＬフェーズでは解決策はいまだ候補の段階です。

このようなときに条件面の話し合いに入るとどうなるか、

根拠（つまり解決策）が見えていないのですから駆け引きの世界に入るしかありません。

しかもこの場合、一般にはお金をもらうベンダ側にとって不利な戦いになります。
 たとえば、ＣＭフェーズのヒアリングで、

「では、いろいろとお聴きしたいのですが、まず予算を増やしていただくわけにはいかないでしょうか？」

と最初に質問をしたら、

相手はなんと答えてくる確率が高いでしょうか？

９０％以上の確率で「増やせません」と答えてくるでしょう。

このようなノーをもらっては、その後の交渉を自らやりにくくしてしまいます。

たとえ自分が一番知りたい関心事であったとしても、

しない方がよい質問というのがあるのです。

自分で自分の首を絞めるようなことは止めましょう。
 したがって、根拠ができるＩＷＰフェーズで初めて条件面を話し合いましょう。
 ただし、ＯＧフェーズの提案するステップで、

意図的に条件面を打ち出し、意図的にその観点をＣＭフェーズで聴いていく、

というやり方がないわけではありません。

そのときには、きわどい勝負（？）を挑むわけですから、しっかりと戦術を練って臨むことになります。
 これは、例外だくらいに思っておいてください。
 
⑥経営メリットを判断基準にする
 何をよりどころにして、メリット・デメリットを考えたらよいのでしょうか？

成功確率が下がりますから、物差し（判断基準）なしに考えるのはまずいです。

場当たり的とは、まさに物差しなしに決めることです。
 最も確実なのが、自分の「経験」です。

この前はこうやって成功（失敗）したので、

今回も同じように（今回は違うやり方で）やろう、ということです。
 とはいえ、これは間違ってはいませんが、危険でもあります。

なぜなら、第１に、経験というのは限られた狭い範囲のものでしかあり得ないからです。

第２に、自分の都合、自分の作業のしやすさで考えがちになるからです。
 したがって、自分だけではなく、あくまでもユーザのメリット・デメリットを考えることを忘れてはいけません。

つまり、ユーザ側の経営メリットを考えるわけです。
 動かないシステムではもちろん困りますが、

動いても大して経営メリットにならないということでも困りますね。

システム開発に対する投資効果をシビアに（厳密に）測定する傾向がますます強くなっています。

交渉の１つ１つにおいても、１人１人が顧客の経営メリットという観点でのシビアな物差しで考えたいものです。
 しかし、切羽詰まると判断がにぶる場合があります。

この「ステップ９」のように、これで決まるか決まらないかという場面になると、

とかく近視眼的になって、判断基準が自分寄りにぶれてしまうことがありますので、注意が必要です。
 なお、ユーザの窓口の方も、必ずしも自社の経営メリットを第１の判断基準にしているとは限りません。

お互いが無意識のうちに馴れ合いになってしまい、

その場しのぎの「秘策」をこそこそと練る、という事態に陥らないようにしましょう。
 
◎根拠を明確にして、相手の意見も探り入れながら、柔軟に創造的に対応しよう。
 
あくまでも経営メリットを判断基準にして１つの絞り込んでいこう。
 
条件面の対応も適切に行おう。

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

ステップ８　解決策のリストアップ
 出てきた案を整理して、
 リストアップします

 このステップ８で複数の解決策を整理してリストアップし、
これだけでよいか、つまり案は出し尽くされたかどうかを確認します。
ほかの案がなければ、次のフェーズに入る合意を取ります。

 「そうしますと、課長様の案が３番目の案で、
私どものご提案が１，２の２案ということでよろしいでしょうか？
ほかに考えられる案はございませんか？
なければ、この３案の中から最終的な解決策を作っていきたいのですが、
よろしいでしょうか？
それでは、一緒になって内容の検討をしていきたいと思いますので、
よろしくお願いします」

 このステップの基本的な意図は、
ＣＭフェーズの「ステップ６　課題解決への協力確認」と似ています。
次のような確認をしたいのです。

 ①場面が変わること
 次に何をしたいのか、
場面が変わることを相手にわかってもらうことが大切です。
案を出すことと、それをチェックすることを明確に分けたいのです。

 ②信頼関係
 一緒になって決めていきたいという相手との信頼関係作りの姿勢を確認したいのです。

相手、特にユーザの場合は、

「私は案をチェックする人、貴方は案を出す人」というような姿勢、

いわば評論家的態度を取ろうとする人も実際にはいるわけです。

そのような人にもなんとか統合的に考えようという働きかけをしたい、

相手をコントロールしたいと「ステップ７　アイデア創出」で書きましたが、

ダメ押しの働きかけをこの「ステップ８」でも行いたいのです。

 

 ③共通テーマ

 さらにここで、相手の思考をほかのよけいなことに発散させないようにします。

今はアイデアが出たので、次にやりたいのは、

そのアイデアの内容を検討することですが、確率的にいって、少数とはいえ必ずいるのが、

話を元に戻したり、直接関係ない話をする人です。

「そういえば、こんな方法もあるんじゃないの？」

「やはり、問題は～というところにあるんだ」

「理想はなんといっても品質のチェックを節々で入れていくことで・・・」などといった具合です。

 そうなると話は前進しませんので、

「今は、この観点で頭を使ってください、意見を出してください」と、

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

これを、このステップ８でやりたいのです。

 以上の３点から、このステップ８は時間的にはすぐに済みますが、抜かさずにやる必要があるのです。

 

 ◎アイデアをリストアップして、次にその内容の検討に入りたいのだと、場面の転換を相手に示そう。

 統合的立場に立って、お互いに必要とする共通の事項について話し合うように働きかけよう。

 

 Ｑ＆Ａ　３

 Ｑ：ＳＬフェーズでは、

ＯＧ・ＣＭフェーズからの「現状→問題・課題→解決策」のロジックが明確になっていることが大切であって、

それが上手くいっていなければ、

話し方や表現の仕方等のスキル面をいくら工夫しても交渉はあまり上手くいかない、

と考えた方がよい？

 

 Ａ：話し方や表現の仕方等のスキル面での工夫の余地はたくさんありますし、

そのための努力は惜しまない方がいいに決まっています。

 しかし、いくら話し方が上手であってもロジックが不明確であるならば、

相手はなかなか納得しません。

ＯＧ→ＣＭ→ＳＬフェーズと進んできたわけですが、

なぜこうなるのか、なぜこういいたいのか／いえるのか等のロジックにおいて矛盾があっては、

たとえ素晴らしい解決策だと自分では思っても、

相手は疑問を感じたりして、交渉が前進しなくなるのは当然です。

 思うように進まなくなったときには、「自分は話し方が下手だから進まない」と考えるよりは、

まず、ロジックの再構築を試みる方が成功確率は上がります。　答：イエス

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

 ＳＬフェーズの進め方
 いよいよ、課題に対する
 解決策を作っていきます

 前節までで、自分のＡ案と相手のＢ案との対立点（ギャップ）を明らかにし、
さらにヒアリングをして、
問題点や課題（解決したいテーマ）を見いだして双方で合意しました。
 そこでこれから、課題に対する解決策Ｃ案の候補を作っていきます（Ａ＋Ｂ＝Ｃ）。
できるだけ相手にも案を出してもらって、一緒になって考えていくようにしてください。
何度もいうようですが、勝ち負けのレベルではなく創造的に、
しかも統合的に行いたいものです。
まさに、「より良い案ができればそれでよいのではないか」 という姿勢でやりたいところです。
ＣＭフェーズが終わったところでいったん交渉を中断し、
自社に戻って解決策を自分（自社）で作ってからこのＳＬフェーズに臨むことが多いかもしれません。
あるいは自社に戻らず、ＣＭフェーズからそのまま引き続きこのＳＬフェーズに入って、
解決策を考えることもあります。
解決策はいったん自社に戻ってから作るものだと思い込んでいる方も案外いますが、
その場で新たに考えて作り出してしまうという姿勢も、交渉を早く進めるためには必要です。
交渉を中断した場合も、続行した場合も、ＳＬフェーズの進め方としては同じです。
最初の挨拶が異なるだけです。
ＳＬフェーズは２つのステップに分けて進めます。
案を作り出すステップと、それを整理するステップです（メインは前者のステップです）。
 
ステップ７　アイデア創出 まずは自分の案を提示します
まずは自分のアイデア、考えを叩き台として提案し、それから相手にも案を出してもらいます。
たとえば、次のように進めます。
なお以下の例では、ＣＭフェーズでいったん中断して、
あらためてＳＬフェーズから交渉を再開する場合を想定していますから、
アイスブレイク（最初に話しやすい雰囲気を作るための導入の話。詳細は２７節）から始めます。
次に前回の確認を行い、それから提案ということになります。
 
<アイスブレイク>
「先日はお忙しいところありがとうございました。
数日前に新製品の発表会を大々的に催されたそうで、
流通工業新聞にも大きく出ていましたね。どうでしたか？・・・ で、
今日お伺いしましたのは、
先日いただきました課題をもとに解決策を作ってまいりましたので、
課長様のご意見をいただきながら、より良い案にしてまいりたいと思います。
ご一緒により良いシステムにしていこうと思っておりますので、どうかよろしくお願いします。
<前回の確認>
まず、前回の確認からさせてください。
課題としては大きく４つあったと思います。
第１点は、テスト環境の整備をして、バグの大幅な改善とスピードアップを図るということでした。
よろしいでしょうか？・・・
２点目は、・・・。
<解決策の提案>
そこで私どもでは、解決策として３点考えてまいりました。
まず、私どもの案の概要を説明いたしますので、
その後で、課長様の方の案がございましたらぜひお聴かせいただきたいのですが。
よろしいでしょうか？
それでは、第１案目ですが、テスト環境をハード面と人員面から改善いたします。
それにより、当社のベテランＳＥであるＭを、画面の修正の方に回し、
エンドユーザ様のご希望を満たそうとするものです。
詳細は、こちらをご覧いただきまして・・・。
<相手にも案を出してもらう>
私どもの案は以上です。
内容の検討はあらためて行いたいと思いますが、
その前に課長様の方で、ほかに何か案はございませんでしょうか？・・・」
上記のような感じで進めていきます。
どんなことに注意して行えばよいかを、以下に紹介します。

 ①アイデア創出に頭を使う
実はこのステップを行うための話し方レベルのスキルは、
ＩＷＰの全プロセスの中で、最も簡単だといえます。
なぜかというと、相手とのやりとりがそれほど複雑ではないからです。
上に紹介したようなトーク（言い回し）で、
後は、具体的な中身をいえばよいのですから。
しかしステップの内容の困難度は、ＩＷＰの全プロセスの中で、最も高くなります。
なぜなら、新しいアイデアを生み出していきたいからです。
「そんなに簡単に新しいアイデアが生まれるなら、誰も苦労はしないよ」といわれそうです。
しかし、あえてこれに挑戦しましょう。
まさにこういうところで苦労をしましょう。
ＳＥやＰＬは本来は創造的な仕事です。
ただ、現実の日常は、さまざまな事柄の対応に追われて、
必ずしも創造的なことは多くないかもしれません。
作業に埋没せざるを得ない部分もあるでしょう。
そこで、自分の仕事にメリハリをつけるとよいのではないでしょうか。
つまり、ＩＷＰの中では、ここが最も知恵を出すところ、頭を使うところだ、
と意識して、めいっぱい頭を回転させるのです。
意図的に頭を使いましょう。
ときどき、「自分は、アイデアを出すことがあまり得意ではない」という方がいます。
気持ちはわかりますが、厳密にいうとこうなるのです。
「私はあまりアイデアを出すことに頭を使ったことがないので、
今、アイデアを出せといわれても難しい」と。
使わない能力は低下します。
日頃から小さなことでよいですから、
ちょっとしたアイデアを出すことを心がけましょう。
たとえば、ミーティングのやり方を変えるとか、
ドキュメントのフォーマットを工夫するとか、いろいろあるはずです。
その日常の積み重ねが、
肝心のシステム開発での難しい問題に対する創造性として発揮されるのです。
 
②執念深く可能性を求める
新しいアイデアを生み出したいということは、
言い換えれば、未来に向かって可能性を求めるということです。
「こんなものだ」といってすぐに妥協しないことです。
ちょっと案ができたらといって、すぐに満足し、もうアイデア作りをしない、
ということにならないようにしたいものです。
「もっとないか、もっとないか、・・・」と、
より良い案を追い求める貪欲さが必要です。
その場しのぎタイプにならないようにしましょう。
また、このように追い求める貪欲さや執念が、
アイデアを生み出す能力を磨いていきます。
ノーベル賞とまではいかなくも、素晴らしいアイデア創出をした人は、
必ずこの執念深さをもって仕事をしています。
淡白な性格で素晴らしいアイデアを生み出した人はいません。
 
③相手にも案を出してもらう働きかけをする
今、目指しているのは、統合的交渉です。
勝ち負けの発想で自分の案を通すために交渉するのではなく、
より良い案を作るために交渉を行っているわけです。
そこで、自分でもベストを尽くして考えるわけですが、
相手にも考えてもらい、案を出してもらいましょう。
一緒になって考えましょう。
もちろん、ＩＴ技術寄りの話にならざるを得ない場合に、
相手が技術知識に深くないときには、相手は案を出しようがないということはあります。
しかし、考え方として、相手にも案を出してもらうのだ、という姿勢で行いましょう。
このように一緒に考え、話し合う中からアイデアを生み出していくのが、
統合的な交渉であり、創造的な交渉ということになります。
そこで、必ず、「以上が私の案ですが、課長様も何か案はございますか？
あればぜひ教えてください」と、
相手に働きかける質問をしましょう。
「どうせ聴いても出てこないから」
「聴いても良い案はないから時間の無駄だ」などと思って、
最初から諦めて聴かないということがありますが、
相手に対する働きかけは行うようにしましょう。
また、プロジェクトメンバーや外注先との場合は、
「案はありませんか？」と質問することは、
相手に考えさせることになるので、
教育効果が極めて大きいため、この点からも行ってください
（教育指導というものも、粘りが必要です）。
ただし、ユーザ相手の場合で、
相手が極度に競争的な場合（勝ち負けに異常にこだわる場合）は、
ちょっと難しいことがあります。
それは、「相手の意見を率直に聴く」のステップ３と、
ステップ７との違いを考えると明らかになります。
というのも、一見すると、ＯＧフェーズの「ステップ３　相手の意見を率直に聴く」の方が、
相手が強い反対をしてきてやりにくいのではないかと思われるかもしれません。
ステップ３では、確かに強い反対が出ることもあるでしょうが、
自分の感情のコントロールさえできれば、
つまり自分さえムキにならなければ、
相手の言い分を聴いていればよいのです。
しかしこの「ステップ７　アイデア創出」では、
こちらから質問して、できれば相手にアイデアを出してもらいたいわけですが、
この趣旨を理解せずに反論されてしまい、
コントロールしづらいことがあります。
「なんで私に聴くんだ、案を考えるのは貴方の仕事だろう、
それにお金を払っているんだ」というように。
このようにユーザにいわれてしまったら、
「申し訳ありません。それでは、今ご説明した私どもの３案で考えてよろしいでしょうか？」
というように引き下がるしかありません。
 
④叩き台として提案する
ベストの案を考えるという姿勢で行いたいのですが、
同時に、出した案にこだわらないようにしましょう。
このように一見矛盾したことを、
このＳＬフェーズと次のＩＷＰフェーズでは行わなくてはなりません。
なぜなら、「より」良い案作りを目指すのですから、
出したアイデアはあくまでも最終的に決定するＣ案の候補です。
そこで、いわばニュートラルな姿勢が必要となります。
謙遜しすぎるのもよくありません。
「大した案を思いつかなかったのですが、一応申し上げますと・・・」
等といわないようにしましょう。
なんといっても、ベストの案を考えたいということで臨むものだからです。
だからといって、「これがベストです。これでいきましょう」と押しつけてもまずいです。
いまだＳＬフェーズの段階で、
これからほかの可能性も求めるのですから。
 
⑤論理的整合性に留意する　ほかの案との関連性、
これまでの話の流れとの整合性（なぜ、この案なのか？）等にも注意を払いましょう。
解決策は、ＯＧフェーズで明らかになった対立点（ギャップ）やＳＬフェーズで
明確になったいろいろな問題点と、見いだした課題、さらにさかのぼり、
そもそもこの開発をすることになった理由や背景等を踏まえなければなりません。
それなのに部分的に問題を捉えてしまう場合がありますので、
気をつけてください。
たとえば【バグが多発してなかなか開発が進まないシステムの納期を守る】
という課題に対し、
「残業が増加して、なんとか納期内に納めます」といったとしても、
バグが多発している状況に対する解決策がないので、
気合は称賛されるかもしれませんが、アイデアとしてはまずいですね。
 
『戦略とは、必然性を説明できなければならない。
「なぜ？」という質問に答えられなければいけない』（サローナー『戦略経営論』）といわれています。

このＳＬフェーズにおける解決策も同様の考え方となり、
「なぜ？」を説明することが重要なのです。
 
⑥複数案作る 原則として、ここでの解決策は複数作ります。
選択の余地を広げるためです。
複数の案の中から選ぶことができれば、相手の納得感が高くなります。
また複数案あれば、それぞれを比較検討して良いとこ取りをするなど、
より良い案作りが行いやすくなります。
さらに、複数作るのだ、と思って臨んだ方がアイデアを絞り出しやすいものです。
実際には、２～３つくらいでしょう。３つというのは、
自分なりに最も良いと思う案と、
それを理想化したものと、
それを簡便化・容易化したものというイメージです。
しかし、３つ作るのはたいへんなので、２つでもよいでしょう。
現実には１つだけということもあり得ますが、
そういうときには、「残念ながら」１つだけだったという思いをもちましょう。
複数案の方がいろいろとメリットがあるのですから。
 
◎創造性を発揮して、より良い案作りに注力しよう。
相手に対する働きかけをして、勝ち負けではなくニュートラル な姿勢で、一緒になって案作りをしよう。
ロジックの整合性に留意しよう。

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

ステップ５　共通課題を見いだし、合意
ヒアリングがおおよそできたと判断したら、これまでに聴き出したことを整理し、
まとめて、問題点や課題を相手と合意します

「わかりました。それではこれまでお聴きしたことを整理させていただきます。
課題は大きく４点になろうかと思います。
第１点は、エンドユーザ様のご要望ということで、
この画面機能については・・・。以上でよろしいでしょうか？」

上記のように「問題点」を整理し、
そこから「課題」（解決策を作るべきテーマ）が何かを見いだし、
相手と合意するのです。

①キチンとまとめる
「ステップ４　相手の意見を掘り下げて聴く」が上手くできていれば、
要所要所でまとめたことをここであらためて確認すればよいのです。
話のまとめが不十分だったと思われることは、
このステップで、「先ほどの～は、・・・と考えてよろしいでしょうか」と確認します。

内容的には、「ステップ５」は「ステップ４」の流れに乗ってやればよく、
「ステップ４」が上手くいっていればいるほど、
この「ステップ５」は「ステップ４」の確認程度で済みます。

②コミュニケーションギャップを防ぐ
なぜ「ステップ４」とこの「ステップ５」を分けたのかというと、
課題の合意を意図的に、明確に、しっかりとやっておきたいからです。
話し合いをしていると、
自分が納得したことは相手も納得したと思い込む傾向が人にはあります。
しかし、相手が違う思いをもったということも大いにあり得ます。
自分はグレープフルーツは黄色だと思っても、
相手は赤色だと思うこともよくあることです。
コミュニケーションギャップは必ず生じるものですから、よく確認しましょう。

③信頼関係作りに向かう
ＯＧフェーズでは対立点を明確にしましたので、
対立感情がお互いにあります。
ところが上手にヒアリングを終えると、
「私のことをわかってくれた」と思って、
対立感情がやや和らぎます。
そこで、この「ステップ５」で、
その和らぎを一層確かなものにしていきたいのです。
両立の関係、つまり信頼関係の方向へと向かっていくわけです。
それを表すために、一緒になって考えていくという姿勢を出していきます。
特に言い方としては、自分の立場や都合を出さずに、
相手の立場に立った言い方にしましょう。
「貴方にとっての問題や課題はこうですね。
私はそれを解決するお手伝いをさせていただきます」
というスタンスです。
なお、これを言い回しのテクニックと矮小化して捉えないでくださいね。
相手の役に立ちたいという気持ちを素直に言葉で表現しましょう、
といっているのです。

◎次に解決策を作るテーマ、課題を明確にして、相手と合意しよう。

お互いに誤解を生じないようにするため、確認しよう。

相手のためになりたいという気持ちを、言葉に出そう。

ステップ６　課題解決への協力確認
解決策作りに入る前に、お互いの協力関係を確認します

課題の確認・合意ができたら次のＳＬフェーズに入って解決策を作りますが、
そのつなぎとして、この「ステップ６　課題解決への協力確認」を入れましょう。

「それでは状況がよくわかりましたので、
この課題を会社にもち帰りまして、解決策を作ってきます。
私どもにはデータベースの専門家もおりますので、
その者にも入ってもらって、できるだけ良い案を作ってきたいと思います。
来週の水曜日１０時ということでよろしいでしょうか？
課長様にも、良い案がありましたらその際に教えていただければありがたいです。
課長様と一緒になって、
御社にとってより良いシステムにしていきたいと思っています。
全力をあげて取り組みますので、どうかよろしくお願いします。
今日はお忙しい時間を割いていただきまして、ありがとうございました」
上記は、解決策を宿題としていったん帰社し、
次のＳＬフェーズは日をあらためて行うという場合の例です。

①信頼関係作りをキチンと表現する
実際の言い方はいろいろあると思いますが、
上記のようなことをキチンということが大切なのです。
「わかりました。それでは来週、解決策をもってまた来ます。失礼します」
という程度で終わることもあるかと思いますが、
これでは相手に対する配慮に乏しいですし、
自分の思いを相手に伝えられません。
「ステップ５　共通課題を見いだし、合意」
では対立感情を和らげる姿勢が必要だといいましたが、
この「ステップ６　課題解決への協力要請」では、
さらにそれを一押ししたいのです。
信頼関係を少しでも築いていきたくて、このようなことをいうわけです。
信頼関係は、ほんの一言で崩れることがあります。
しかし、信頼関係を作るのは一言では無理です。
いろいろな積み重ねを、時間をかけてやった結果として作られていくものです。
こちらからの働きかけをできるだけマメにやっていきましょう。
対立感情を少しでも和らげる働きかけをしましょう。

②場面の転換をわからせる
今のＣＭフェーズと次のＳＬフェーズでは、
やりたいこと、その内容、進め方が全く異なります。
ここまでは問題を洗い出してきましたが、
次のフェーズではアイデアを出し合います。
頭の使い方が全く異なりますので、
場面の転換をハッキリさせる必要があります。
相手によっては、解決策を話し合っているときに、
また問題をくどくどいい出す人がいます。
それでは交渉が進展しません。
その歯止めをしたいのです。
どこまでも相手をコントロールしましょう。

◎一緒になって良いシステムを作っていきたいという姿勢を表現して、
信頼関係作りに向かおう。

次に課題発見から解決策作りへと場面が転換することを、相手に示そう。

Ｑ＆Ａ　２
Ｑ：ＣＭフェーズでは、相手の言い分をうのみにせず、
場合によっては相手の言い分を疑って自分から仮説を立て、
「こういうことは考えられませんか？」等と、相手をリードする姿勢が必要である？

Ａ：ユーザのことはユーザが一番よく知っているはずですが、
誤解もあれば、専門家から見たらおかしな考えをしていることもあります。
したがって、相手のいうことは素直によく聴かなければいけませんが、
いわれる通りにやるという姿勢では、
より良いシステム作りには向かいません。
受け身型になってしまいます。
相手の言い分を疑ってかかるということも、場合によっては必要です。
専門家としてプラスαの案を作っていくには、
統合的な立場に立ってリードすることが大切です。
そのためには、自分なりの仮説をもって交渉に臨まなければなりません。
もちろん、それを的確に行うには、
自分に専門家としてのノウハウがあることが前提になります。　答：イエス

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

ＣＭフェーズの進め方
ギャップを明確にしたら、次は課題の合意を目指します

ＯＧフェーズが一応できたとします。
つまり、場をほぐし、自分の考えＡ案を相手に伝え、相手の考えＢ案を理解し、
対立点（ギャップ）が明確になったところです。
そこで次のＣＭフェーズでは、
この対立を両立に変える新しい解決策Ｃ案を作るために、まずはヒアリングを行います。
本当の問題、あるいは解決したい問題やテーマ、つまり課題を見いだして相手と合意するフェーズです
それを３ステップに分けて進めます。メインとなるのは１番目のステップです。
（ＯＧフェーズからの通し番号になっているので、１番目のステップは「ステップ４」になります）。

ステップ４　相手の意見を掘り下げて聴く（ヒアリング）
対立したままではもちろん困りますから、突破口を見いだします

「・・・ということですね。課長様のお考えはよくわかりました。
それでは、どうしたら最もよいのかを考えるために、
もう少しお話をお聴かせ願えないでしょうか？・・・よろしいですか。
それではまず、先ほど、エンドユーザ様のご希望ということでしたが、
それは具体的には・・・」
上記のように、いろいろと相手に質問をして、
あらためて状況把握をし直したり、
お互いの考え・意見の食い違いはどういうことなのかを掘り下げて調べていきます。
いわゆるヒアリングを行うわけです。
そして、本当の問題や課題を発見します
たとえば、Ｃａｓｅ１の「ＰＬとＡさんの交渉」では、
ＰＬはＡさんの話を全く聴こうとしていませんでした。
現在の仕事の状況や他メンバーとの関係、仕事をＹさんに振るときの問題、
スキルの問題、今後の希望、Ａさんの考える解決策等など、
いろいろと聴き出した方がよかったことがあったはずです。
ところが、自分の考え（「やってもらえませんか？」）に対する反応、
それもイエスのみをひたすら聴こうとしているとはいえません。
したがって、「Ｙさんに今の仕事を振ったらどうか？」
というＰＬのアイデアが良いとか悪いとかの理由ではなく、
交渉の進め方のまずさから押しつけになってしまい、
相手であるＡさんの納得感が乏しくなっていったのです。
ヒアリング不足のために、解決策の良し悪しそのものに関係なく、
決まることも決まらなかったり、不満に思ったりするのが、競争的交渉の特徴の１つです。
では、どんなことに注意してヒアリングをしたらよいでしょうか？
次に留意点を紹介しましょう。

①ヒアリングは、提案説明（プレゼンテーション）より大切
一般的に、交渉が上手な人は「話が上手い」というイメージがあるのではないでしょうか？
そしてこの「話」とは、提案説明（プレゼンテーション）をイメージしていると思います。
「しゃべり」が上手い、という意味です。
しかし実際は、交渉上手は「説明上手より質問上手」なのです。
提案説明が大事なことは前述しました。
ただし、いくら説明しても、それだけでは一方的な交渉になってしまいます。
そこで、考えや状況について相手に質問をしてよく聴き、
一緒になって問題解決を図ることが必要です。
質問上手でないと、話が先へ進まないのです。
また人は、自分のことを誰かに聴いてもらいたい。わかってもらいたい、
という気持ちがとても強いものです。
したがって、相手との信頼関係を作りながら、両立を目指すには、
質問をして相手のいうことをよく聴くことが大切なのです。
どちらかというと、受け身で聴くだけだったのがこの前のステップ３ですが、
このステップ４では、こちらから積極的に働きかけて聴いていきます。
本格的にヒアリングを行うのです。

②課題を見つけるために、トコトン質問していく
ここでは、相手の言い分を聴くという姿勢ではなく、
本当の問題や課題は何かを見つけるために質問をしていきます。
したがって、相手が考えていなかったことまで聴くこともあるますし、
相手が話しにくいこともいわせようとすることもあります。
トコトン聴いていく、つまり、こちらからどんどん質問をしていくのです。
それでは信頼関係がかえって崩れるのではないか、
と心配する人もいるかもしれません。
確かに、質問の仕方が下手だと、
「そこまで聴かれたくない。なんで貴方にそこまで教えなければいけないんだ」
という反応が返ってくることもあります。
しかし、皮を切らせて骨を断つ、みたいなところがあるのです
（肉まで切らせると、ちょっと辛い！？）。
相手の防衛線を越えたところに本当の信頼関係が生まれてきます。
また、本当の問題や課題が見えてきて、
より良い解決策Ｃ案を作れる可能性が高くなってきます。
つまり、統合的交渉になっていくのです。

③ヒアリングスキルはプレゼンテーションスキルより難しい
ヒアリングとプレゼンテーション、
同じ人でも上手くいかない確率が高いのはヒアリングの方です。
ヒアリングは一層スキルアップの努力が必要になります
（もちろん、プレゼンテーションは簡単だという意味ではありません。
あくまでもヒアリングに比べると、という点をくどいようですが確認しておきます）。
ではなぜ、より難しいのでしょうか？
プレゼンテーションの場合は、
①「事前にはほぼ準備を整えることができます」（自分の考えを整理し、まとめるのですから）。
②「一方的に進めているような点があってもおかしくないのです」（自分の主張を相手に話すのですから）。
では、ヒアリングはどうでしょうか？
①事前準備で質問項目や質問する順番などを用意することはできますし、
準備は重要ですが、自分が思ったように相手が答えてくれない、反応してくれないことがあります。
つまり、「事前準備を完璧に行うことは原理的に不可能です」。
②「ヒアリングは相手に話してもらわなければ意味がありません」。
自分が話す（プレゼンテーション）のも難しいですが、
それ以上に、相手に話をさせて、それを上手に聴くのはもっと難しいです。
自分とは違うやり方や考え方をする人の話を誤解が生じないように前進させるのは容易ではありません。
また、次の質問をどうするのか、結論はこれでよいのかなど、
その場での判断力が要求されます。
したがって、ヒアリングスキルは本来的に難しいのです。

④課題は創造するもので、お互いの手持ちカードにあるものではない
ヒアリングは難しいということでした。
実は、課題を見いだすことには、さらに本質的な難しさがあります。
なぜなら、課題は必ずしも、
あらかじめ自分もしくは相手のどちらかの手持ちカードにあるわけではないからです。
新しく創造していかなくてはならないこともあるのです。
本書で「課題」といっているのは、ヒアリングをして、いろいろある「不具合＝問題」をさまざまに引き出し、
検討した結果見いだした、今手を打つべき問題、解決策を作るべきテーマのことをいっています。
「問題」のどれかがそのまま「課題」になることもあれば、
「問題」の次元を上げて新たな「課題」を作ることもあります
（ＡとＢという問題からＣという課題を作るのです）。
たとえば「Ｃａｓｅ１　ＰＬとＡさんの交渉」における課題の候補としては、
「Ａさんが新しい仕事を消化する方法は何か」
「Ａさんの負担を減らすにはどうするか、
後輩のＹさんへＡさんの仕事をどのように引き継いだらよいのか」
「ＡさんがＰＬに向けて成長するにはどうするか」
「これらを総合的に解決する手はないのか」など等が考えられます。
これを絞り込むか、このままか、いずれにしても課題として相手と合意します。
実際上、課題の数は、１つに絞り込めればそれでよいのですが、
自信がもてないときには２～４つくらいになっても構いません。
むしろ、いくつかあると次の解決策作りをやりやすくする可能性もあります
（この絞り込み、合意を行うのは、次の「ステップ５　共通課題を見いだし、合意」になります）。
これらの課題は、交渉する前にあらかじめ決まっていたり、
わかっていたりするとは限りません。
相手も適確に課題を捉えているとは限りません。
「それでは、引き継ぎの件がポイントになりますかね？」
などといったように、交渉する中で「創造」していかなければいけないことも多いのです。
また、この課題候補が「正しい」か「否か」は、
極論をすればやってみなければわからないので、
「これで課題は良しとしよう」という決断力が問われます。
なお、くれぐれも、自分のＡ案を通すために都合のよい課題を設定しようなどと、
ずるいことを考えないようにしましょう（結果論としてはあり得ますが、
ＣＭフェーズのプロセスとしては考えないようにします）。

⑤統合的立場に立つ
特にこのＣＭフェーズでは、自分の立場に立った発想では上手くいきません。
なんといってもＳＥ（またはＰＬやＩＴコンサルタント）は、
相手の問題を解決する立場にあるのですから、
相手の立場に立ってヒアリングをしていきたいものです。
それを、自分の作業を進めるためにどうしたらよいかを聴こうとして、
自分の都合にばかり目がいってしまうと、
「肝心のポイント→課題」を見逃すことになります。
そうはいっても、やはり自分の都合を完全に無視することはできません。
そこで、自分の立場と相手の立場を統合した立場に立とう、
というのが今目指している統合的交渉ということなのです。
自分の都合は踏まえつつも、
「ヒアリングで聴いていくことは相手の立場に全面的に立って行う」のです。
「自分の立場→相手の立場→統合的立場」、
それが自分と相手の両者にとってプラスになる道なのです。

⑥自分の考えの説明や、解決策作りに先走らないこと
このヒアリングで、やってはいけないことが２つあります。
１つは、自分の都合に合わせた説明をしようとしないことです。
話の展開によっては、相手が疑問を出してきて
（「これは、どれくらいの工数がかかるのか？」など）、
それに答えなければいけないことがあります。
長々とこちら側の事情を話すことのないように、端的に答えましょう。
「はい、３人／月くらいかと思います。
そうしますと、課長様としては、この機能はやはり目玉として重要とお考えなのでしょうか？」などと、
できるだけ手短に答えて、本来の質問に戻りましょう。
相手をコントロールしましょう。
ここで、「はい、３人／月くらいかと思います。
その詳細はあらためて検討させてもらいますが、
すぐにかかれる人員を考えると・・・、今、テスト工程でそちらの方に人が・・・」などと、
だらだらと説明に入らないように、セルフコントロールしましょう。
ここで説明に入ると、ヒアリングができなくなり、
問題が見えなくなることはいうまでもありません。
２つ目は、解決策作りにすぐ入ろうとしないことです。
次のフェーズは解決策作りですが、あくまでも課題が見えてからのことです。
問題を整理して、課題が明確になるまでは、解決策は作れないはずです。
それを、ちょっとヒントが出ると、すぐに解決策作りに入り込もうとして、
良い解決策作りに失敗することがあります。
これでは目先の、その場しのぎの解決策で終わることが多いのです。
スピードは大切ですが、拙速にならないように注意しましょう。

⑦まとめ方、整理の仕方、メモの取り方
意外と個人差が出るのが、まとめ方や整理の仕方です。
問題は何かを明らかにするために、相手や自分がいったことのポイントを整理し、
要所要所でまとめなければいけません。
またその際には、前にいったこととの関連づけも重要です。
そのために、メモの取り方が重要になります。書いたものを見ながらまとめ、
関連づけをしていくのです。
視覚を使うのがコツです。
よく会議などで白板を使いますが、あれを交渉の場では１人で、メモでやるのです。
上手にメモを取り、上手にまとめていかないと、話が前進しません。
堂々巡りにならないようにしましょう。

⑧否定ではなく肯定で
言葉遣いで必ず守りたいことがあります。
それは、「否定語を使わず、肯定語を使うこと」です。
問題点を話し合うと、特にＳＥのような開発者側の立場からは、
「それはできません。無理です。ダメです。」といいたくなることが出てきます。
しかし相手から否定されると、誰でも面白くありません。
また、ＯＧフェーズとは違って、
このＣＭフェーズでは、どうしたらよいかを考えるために聴いているのです。
つまり、肯定語でなくては意味がありません。
ですから、このＣＭフェーズでは、「堂々と反論する」のは止めましょう。
あくまでも、問題を議論するにしても課題を見つけるためなのですから、
それにふさわしく、肯定的な言い方をしましょう。

「人員は確保できません」→「人繰りをどうするかを考えないといけませんね」
「仕様締結後なので、お受けできません」→「先日、仕様締結の合意をいたしましたよね」

⑨ＩＴ技術、業務知識が必要
ヒアリングの技術を実際に効果あるものとするためには、
ＩＴ技術、業務知識が必要なのはいうまでもありません。
これらをバックボーンとしてもっていて初めて、的確な質問が行えます。
経験がものをいうのは、この観点です。
いってみれば自分の頭の中のデータベースから、
今交渉している内容に類似した点を素早く検索して、
次の質問項目を出していかなくてはなりません。
これが的確にできればできるほど、早く効果的に交渉を進められるわけです。
しかし他業界に比べ、ＩＴ業界は技術進歩が速いので、
技術の習得が大変です。
そこで、ＱＣ（品質管理）でいう「水平展開」の力が問われてきます。
これは、ある分野を掘り下げて習熟した人が、
それとちょっと異なる分野をマスターする場合に発揮される力です。
あらかじめ習熟していた分野と少し異なる分野との、
類似点と異なる点を手際よく見極め、
異なる点を類似点と微妙にダブらせながら、
短時間で（少しのエネルギーで）習熟してしまう能力のことです。

◎対立を両立に変える突破口を見いだすために、本当の問題や課題を創造しましょう。

そのために、こちらから積極的に働きかけて、突っ込んだ質問をしていきましょう。

ヒアリングの重要性や難しさを認識して、スキルを磨きましょう。
総合的立場に立って、拙速にならないように、肯定的に、上手にまとめていきましょう。