顧客や開発メンバーなど膨大な人員が関係する大規模プロジェクトでは，コミュニケーション不足が致命傷となる。プロジェクトを破綻から守るには，「聞き返し」や「無駄話」などのスキルが欠かせない。
奥井 規晶 インターフュージョンコンサルティング 代表取締役
| |
|
図1●日本のITプロジェクトが失敗する原因 顧客やチーム・メンバー間のコミュニケーション不足によって，多くのプロジェクトが失敗している |
システム開発プロジェクトで最も効率が悪いのは，開発・テスト段階で要件が追加・変更されたり，現場の担当者が要件を勘違いしていたりして，設計段階まで手戻りする“逆流現象”である。この逆流現象が，コスト超過や納期遅れ，低品質といった失敗プロジェクトを引き起こす。
プロジェクトの逆流を防ぐには，要件定義の段階で顧客から要求仕様をきっちり聞き出して文書化し，関係者で合意を形成しておけばよい。これで，プロジェクト終盤での追加や変更は激減するはずだ。
ところが，日本において大規模プロジェクトの失敗は後を絶たない。「テストフェーズになって，顧客から『話が違う』とクレームがつき，仕様を大幅に見直さざるを得なくなった」，「グループごとに実装がバラバラで，全体の整合性が取れなくなった」という悲鳴をよく聞く。その大きな原因は，プロジェクト内のコミュニケーション不足にある（図1）。
ベテランほど期待に応えられず
| |
|
図2●コミュニケーション・スキルの，各職種における年代別平均値 プロジェクト・マネジャーのコミュニケーション・スキルは，ほとんどの年代を通じてプログラマやSEより高いが，30代前半をピークに緩やかに下降している |
ここで，日本のITプロジェクトの実態を見てみよう。図2は，414人のプロジェクト・マネジャーと，プログラマー／SE1464人のコミュニケーション能力を上司や同僚といった他者が評価。その結果の平均値を，年代別にグラフ化したものである（データの出所はITイノベーションの「スキルポジション分析」）。これを見ると，プロジェクト・マネジャーのコミュニケーション能力はプログラマーやSEより明らかに高い（20代後半のプロジェクト・マネジャーの平均値が低いのは，対象者が極端に少ないためと考えられる）。高いコミュニケーション能力を持つことは，プロジェクト・マネジャーの条件なのだ。
ところが，である。図2をよく見ると，プロジェクト・マネジャーのコミュニケーション能力は，30代前半をピークに緩やかに下降している。筆者はこの分析結果に，日本のソフト開発力，とりわけ大規模プロジェクトにおける品質低下の一因を見る。
30代後半以上のプロジェクト・マネジャーと言えば，ベテランだ。担当するのは，比較的大規模なプロジェクトだろう。プロジェクト規模が大きくなれば当然，アーキテクチャ設計や開発，運用の複雑性も高まる。当然，顧客やチーム・メンバーといった関係者の数も増える。それを取りまとめるマネジャーには，高いコミュニケーション能力を持つことが期待されることは言うまでもない。分析結果は，プロジェクト・マネジャーの能力がそうした期待に追いついていないことを示している。
しかし，プロジェクトが逆流して失敗に至る原因を，プロジェクト・マネジャー個人の能力不足だけに帰することはできない。その背景には，日本的なコミュニケーション文化が内包する問題が横たわっている。
要件を推測せざるを得ない
第１回でも述べたように，日本はかつて「一億総中流社会」と呼ばれたほど言語や価値観，嗜好に共通性がある。このため，いちいち口に出して言わなくても，相手に自分の考えをある程度は伝えられる。あいまいな言い方から相手の言わんとすることを推し量る「忖度（そんたく）」や，何も言わなくても理解し合う「あうんの呼吸」。こうした言葉が，伝統的な日本のコミュニケーション特性を端的に表している。
ITプロジェクトでも，顧客は物事をあいまいに表現しがちだ。一方のITエンジニアも，顧客の言うことに不明点があっても突っ込んだりはしないし，異論があっても顧客と議論を戦わせることはない。「顧客のプライドを傷付けるわけにはいかない」という配慮からである。結果的に，ITエンジニアは顧客の要望を“推測”して仕様書を作るしかなくなる。
要件が少ない小規模システムを開発する際は，このやり方でもなんとかなる。要件定義フェーズにミスがあっても，途中でなんとか修正できる。しかし，開発量が膨大な大規模プロジェクトではそうはいかない。結果的に，仕様書は顧客の本当のニーズとずれてしまうケースが多い。
大規模プロジェクトのマネジメントで日本の先を行く欧米では，事情は大きく異なる。多様な民族や異なる生活様式が共存する欧米では，あうんの呼吸は通用しない。コミュニケーションを成立させるには，とにかく口に出して話す必要がある。事実，米国人が1日に話す会話量は，日本人の2倍という調査結果がある。「それだけ会話しなければ相手に伝わらない」というのが，欧米の常識なのだ。顧客は自分たちの要望をきっちり言葉で表現するし，ITエンジニアは不明点を遠慮なく理詰めで追求する。何事もあいまいさを残さず，白黒はっきり付けることを是とする。
では，日本で大規模プロジェクトを成功させるには，欧米流に歯に衣着せずなんでも言葉にすればよいかと言うと，ことはそう簡単ではない。欧米人は，たとえその時は激しく意見を戦わせても，その後の人間関係に禍根を残さない。しかし，日本で論戦などしたら，負けた方はいつまでも恨みに思い，しばらく口もきいてくれない。もし，ITエンジニアが論戦で顧客をうっかり言い負かしてしまえば，取引停止になってしまう。
コンサルの手法を応用
日本的なコミュニケーションのあいまいさが，多くのプロジェクトを失敗に追い込んでいる。だからといって，欧米流にクールにズケズケと主張することは，あうんの呼吸を美徳とする日本の企業社会にはそぐわない。では，日本のプロジェクト・マネジャーはどうすればよいのか。
解決策は，ある。明快な論理と信頼関係に裏打ちされた「ロジカル・コミュニケーション」を，プロジェクト・マネジャー自身が強い意思を持って実践するのである。
ロジカル・コミュニケーションを実現するためには，以下の3つのスキルが不可欠だ。相手の話を深堀りする「聞き返し」，合理的な結論を導き出して相手を納得させる「ロジカル・シンキング」，信頼関係を築いてコミュニケーションを円滑化する「インフォーマル・コミュニケーション」である（図3）。
| |
|
図3●要求仕様をうまく取りまとめるためのロジカル・コミュニケーション 誰も傷つけない「玉虫色の決着」を好む日本のプロジェクトにこそ，「論理性」が不可欠だ |
ロジカル・コミュニケーションの第一歩は，地道な「聞き返し」から始まる。ヒアリングの際，顧客が話した内容を深く確実に理解するために，「それは具体的にはどんなことでしょうか」，「例えばこんなことでしょうか」，「それはこんなことを意味していませんか」などと，自分の理解と顧客の話が一致するまで繰り返し聞くのである。「顧客に不快感を与えないこと」，「逆に顧客が喜んで話してくれるように話を振ること」がコツだ。
聞き返すことで顧客の話を理解したら，次は「ロジカル・シンキング」である。顧客を納得させられるように，自分の主張を論理的に構築して伝える。例えば，顧客側の要件すべてを仕様に盛り込むには時間やコストがかかり過ぎると判断したとしよう。この時，「そんなの無理です」と突っぱねては顧客を不快にさせる。といって，顧客の機嫌を損ねないように「いやあ，ちょっと難しいかなあ」などとあいまいに濁すと，顧客が「難しいが，やってくれるんだな」と誤解する危険性がある。こうしたことが，納期直前のクレームや仕様変更へとつながっていってしまう。
そこで，要件絞り込みの必要性を論理的かつ具体的に説明する。相手の立場や必要最小限の要件を考慮して説得すれば，顧客は深い納得感を得られるため，開発側の主張を快く受け入れるだろう。
