「あの画面はこう変えたい」「この機能も追加したい」という仕様変更の要望が利用部門から挙がることは少なくない。多くの場合、こうした要望に「予算を超過するから無理だ」「このタイミングでそんなことを言われても困る」などと強く主張するのは難しい。

 そこで合理的な説明によって、相手が要望を取り下げるように促したい。そのためには、相手と認識をそろえていくことが不可欠だ。

 認識がそろっていないケースは主に二つある。一つは、要望が重大な問題を引き起こすことに相手が気付いていないケース。もう一つは、要望を出してきた相手と判断基準が異なるケースである。

相手目線の問題とその根拠を提示

 インテックの坂木俊夫さん(SI事業本部 MCIソリューション部 課長)は、前者のケースに直面した。具体的には、あるプロジェクトがテスト工程まで進んだ段階で「帳票印刷機能を追加したい」という要望を受けた。「どうしても必要な機能が見つかった。なんとしても加えてほしい」と利用部門のキーパーソンは話したという。

 大きな手戻りが発生するため、応じることはできない。しかも、業務のやり方を工夫すれば、帳票印刷機能がなくても大きな支障が生じることなく業務を行えそうだった。

 しかし利用部門のキーパーソンは、是が非でもという様子だったので、うまく説得しないと余計に態度を硬化させる危険性があった。

 そこで坂木さんは、まず利用部門にとって痛みが分かりやすいコストの問題を説明した(図2)。「開発期間が延び、コスト削減の目標を達成できなくなってしまいます」といった具合だ。

図2●要望を反映した場合の問題と、反映しない場合のリスク対策を整理
インテックの坂木俊夫さんは、あるプロジェクトのテスト工程で、「帳票印刷機能を追加したい」というテストのやり直しを伴う無茶な要望を受けた。その際、要望を実現する場合に発生する問題、要望を実現しない場合に発生するリスクへの対策を伝えることで、相手は要望を取り下げてくれたという
[画像のクリックで拡大表示]

 この主張を裏付けるため、坂木さんは二つの根拠を提示した。一つは、稼働が遅れる分、既存システムの運用保守契約を延長することになり、予算外のコストが発生すること。もう一つは、開発メンバーの増員による追加コストが発生することだ。二つの根拠を提示することで、「確かに、コスト削減を達成できなくなったら本末転倒だ」という声を相手から引き出した。

次期の開発に盛り込むことを提案

 相手にとっての問題についての認識を共有した上で、坂木さんは論理的な説明で相手が抱いている恐れを解消する作業に取りかかった。

 その恐れとは、「帳票印刷機能の要望が受け入れられないと業務が回らない(に違いない)」というもの。これに対して「機能を追加しなくても業務に大きな問題は発生しない」という主張を展開する。

 この主張の根拠は、新システムがCSVファイルの出力機能を備えていること。データをCSV形式で取得できるため、表計算ソフトを操作する手間はかかるが、帳票を作成できる。

 ただし、この根拠だけでは「以前より作業の手間が増える。やはり開発してほしい」と抵抗される可能性もあった。そこで「次期開発の要件に盛り込みましょう」という提案を坂木さんは加えた。「少し待てば不便な状態を解消できる」という安心感を利用部門のキーパーソンにもたらしたわけだ。一連の論理的な説得によって、坂木さんはキーパーソンの納得を得たという。

判断基準を可視化し理解を得る

 利用部門の説得が必要になる状況は、要件定義工程でも多い。ウルシステムズの植田 淳さん(事業開発本部 マネジャー)がある企業のプロジェクトの要件定義工程でリーダーを務めたときの事例を見てみよう。

 システム構築の対象は、申込用紙に記載された内容をデータベースに登録する業務。構築前の状況では、Excelのデータベース(DB)接続機能を利用して、Excelのシートに入力した内容を直接DBに登録していた。しかしシステム監査の結果、ExcelシートにDBの認証データが埋め込まれている点を解消しなければいけないことになった。

 そこで植田さんは監査を通せるように、Webブラウザーからデータを登録するWebアプリケーション方式を提案。当該業務を管轄する利用部門の担当者に画面イメージを提示した。すると「作業効率が大幅に悪化する。これでは業務が回らない」と反対されたのである。

 実はこの利用部門の担当者は、新システムによって自部署の業務効率が上がるかどうかに対する意識が強かった。一方、監査の問題は詳しく聞いておらず、さほど気にとめていなかった。

 システム監査を通るかどうかが重要な判断基準であることを、利用部門の担当者に理解してもらう必要がある。そこで植田さんは、さまざまな判断基準を踏まえて総合的に判断したという事実を可視化してみせた(図3)。

図3●判断基準を可視化して主張の意図を相手に伝わりやすくする
ウルシステムズの植田 淳さんは、ExcelをUI代わりに使いデータを登録する従来の業務システムの改修プロジェクトで、Webアプリケーション方式に変更する提案したところ、「業務が回らない」と反対された。そこでシステム開発の目的や判断基準を可視化し、説得に成功した
[画像のクリックで拡大表示]

 可視化する際には、Excelを使う別の方式を検討したことも示した。植田さんの提案がWebアプリケーション方式ありきだったのではなく、さまざまな検討をしたことを伝えるためだ。判断基準の可視化が功を奏し、利用部門の担当者は最終的に納得したという。

出典:日経SYSTEMS 2014年1月号 pp.52-53「困った時に役立つロジカル説得術」
記事は執筆時の情報に基づいており、現在では異なる場合があります。