プロジェクトの会議体で議論になったとき,持論を押し通し,ほかの人の意見を聞こうとしない人がいる。本人としては自分の主張が一番正しいと思うあまり聞けなくなっているのかもしれない。その主張がプロジェクトにとってベストな選択であれば問題ない。しかし,その主張が間違っている場合,そういう人を説得するのは非常に困難である。主張している人がユーザーだったり,意思決定権者だったりする場合には,なんとしてでも説得し,こちらの主張を理解してもらう必要がある。

相手の心にわだかまりを残した筆者の失敗

 筆者が以前勤めていた会社でのことである。そのプロジェクトは,数千人月単位の大規模なシステム開発だった。筆者はプロジェクト・マネージャ(PM)として指揮を執っていた。このシステムはユーザー要件により,一部の機能で高速なレスポンス・タイムが要求されており,オブジェクト・データベースの採用が確定していた。一方で,オブジェクト・データベースでは扱いづらいデータ用には,別のデータベースを選定する必要があった。筆者は国内ベンダー製のデータベースを使うことを考えていた。それは,次のような理由による。

・当該データベースは,今回のシステム開発を引き受けるベンダーの製品であり,データベースに関する知見が高い。
・今回オブジェクト・データベースとの連携がキーワードであり,この連携部分については独自にミドルウエアを構築する必要がある。

 要件定義フェーズで,非機能要件について検討しているときである。若手データベース担当者Y君から国産データベースを使うことについて異論が出た。Y君の主張はこうである。

 「大規模なシステムで採用するデータベースは,できるだけデファクトスタンダードを選定すべきである。世界的に見てシェアの低い国産データベースを使うべきではない。私は,実績もあり世界的に有名なO社のRDBMSを採用することを推奨する」。

 これに対して,筆者は国産データベースを選定に至った経緯について説明した。しかし,Y君は持論を曲げない。それどころか議論は段々とエスカレートしていった。

 「データベースに関しては,PMよりも私のほうが詳しいです。その私が言うことが信用できないと言うのですか?そうであればこのプロジェクトから外してください」。

 そのときは,筆者も感情が高ぶっていたこともあり,次のような理由で持論を押し通し,国産ベンダーのデータベースを採用することを決定した。

 「駄目な物は駄目だ!どう考えても国産ベンダー製を使った方が良いに決まっている。今回の開発は一般論では片付かない問題を多く含んでいるので,O社のデータベースを採用することはできない!なぜ分からないんだ!」。

 実際の開発では,ミドルウエア開発に当たり多くの問題が出てきた。その際,当該データベースを開発した技術者が工場から現場に駆けつけて問題を解決してくれた。そのおかげで,オブジェクト・データベースとの連携はうまくいったのだった。

 確かに,結果的には筆者の主張は正しかった。しかし,そのとき生じたY君のわだかまりは残ったままであり,Y君との人間関係はこじれてしまった。この人間関係を修復するのに数年かかってしまった。今思えば,浅はかで幼稚な対応であったと反省している。

「クレーム」と「データ」と「ワラント」

 自分の主張をしっぱなしで,相手のクレームについて攻撃していては,テレビの討論番組や,国会答弁と変わらない。結果として水掛け論に終わってしまう。ここで言うクレームとは,英語のClaimの事であり,要求やその正当性を主張することである。一般的に日本語で使われる「苦情」という意味ではない。

 議論を行う場合には,「クレーム」と「データ」と「ワラント」を明確にする必要がある。クレームとは,これを言いたいという主張である。データとは,クレーム(主張)を支えるための具体的な事実・物証である。ワラントとは,データ(事実)からクレーム(主張)を導くための根拠(論拠)である。クレームとデータとワラントは,ディベートにおける三角形()とよばれるもので,一つの主張に対して常に成り立っていなければならない。論証責任を果たすとは,クレームに対してデータとワラントをきちんと提示することを意味するのである。

図●ディベートにおける三角形
図●ディベートにおける三角形