第20回 その「リアリティ」はプロジェクトに不必要
野村隆（eLeader主催）
2006/11/22
| 将来に不安を感じないITエンジニアはいない。新しいハードウェアやソフトウェア、開発方法論、さらには管理職になるときなど――。さまざまな場面でエンジニアは悩む。それらに対して誰にも当てはまる絶対的な解はないかもしれない。本連載では、あるプロジェクトマネージャ個人の視点＝“私点”からそれらの悩みの背後にあるものに迫り、ＩＴエンジニアを続けるうえでのヒントや参考になればと願っている。 |
■リーダーシップトライアングルにおける位置付け
この連載では、システム開発プロジェクトにおけるリーダーシップを中心に、「私の視点＝私点」を皆さんにお届けしています。
今回の内容は、リーダーシップトライアングルLove／Communicationに関係します。Loveについては、第10回「正しいことをし、行動力を発揮するココロ」を、Communicationについては、第8回「コミュニケーションはリーダーシップの基礎」を、それぞれ参照いただければと思います。
 |
| 図1 リーダーシップトライアングル。今回は「Love」（ココロ）、「Communication」に関連する内容について解説する |
■「リアリティ」とは――前回のおさらい
前回お約束したように、今回は多様化した「リアリティ」をコントロールしてプロジェクトを管理するやり方を解説します。
簡単なおさらいもかねて、「リアリティ」という言葉の意味を再確認しましょう。「リアリティ」とは、ある人にとっての現実や真実、経験に基づく正しいことと理解してください。日本語の「現実」というよりも、英語の“Reality”の方が語感としては正しいでしょう。
「リアリティ」は、人それぞれの経験や環境によって形成され、本人にとっては「当たり前」のことになっています。当たり前のことを変えることは、右手でご飯を食べるのを急に左手にしなさいといわれるようなものです。納得できないでしょうし、最初はうまくいかないので、困難や苦痛を伴います。
大規模プロジェクトには多くの人が参画し、その分「リアリティ」が多様化します。多様化する「リアリティ」をコントロールすることは、プロジェクトメンバーの「リアリティ」を変えるということなので、非常に難しい課題だと理解してください。
しかし、プロジェクトリーダーたるもの、難しいからできませんといってはいられません。
プロジェクト内において「リアリティ」の異なるプロジェクトメンバーを説得して、プロジェクトを推進するやり方について具体的に解説しましょう。
■説得に当たり、最初の判断ポイント
「リアリティ」の異なるプロジェクトメンバーを説得するに当たり、最初に私がすること。それは、説得する相手の「リアリティ」がプロジェクトの円滑な遂行という目的から考えて、本質的に間違っているかどうか判断することです。
「本質的」というとあいまいですが、「相手の『リアリティ』がプロジェクト成功のためになっているか」という質問に対して答えがYESであれば「本質的に正しい」、NOであれば「本質的に間違っている」と判断しましょう。
そのほか、例えばQCDに基づいて考えるのもよいでしょう。具体的にいうと、Q（Quality：品質）、C（Cost：コスト）、D（Delivery：納期、スケジュールと読み替えるのも可）の視点から、プロジェクトに貢献するのであれば正しい、そうでなければ間違っているという視点で判断することです。
プロジェクト成功の視点から本質的に正しいか否かで、相手を説得する方法が異なります。
以下、場合に分けて解説します。
■本質的に間違っている場合
まず、プロジェクトメンバーの「リアリティ」が、プロジェクト成功の視点から本質的に間違っている場合について考えましょう。この場合は、何らかの形で相手を説得して行動を変えてもらう必要があります。
時として、行動様式を根本的に変えてもらいたい場合もあるでしょう。例えば、前回紹介した、いつも怒ってばかりのBさんです。プロジェクトの雰囲気が悪くなるので、人を怒鳴りつけてばかりの態度、つまりBさんの「リアリティ」を改めてもらいたいという場合です。
とはいえ前述のとおり、各人の「リアリティ」はそう簡単には変わりません。従って、少なくとも「プロジェクト遂行の邪魔はしないようにしてもらう」ことが目標となるでしょう。
また、相手の前でズバリ間違いを正してしまうのは考えものです。間違っている人に「間違っている！」というのは、時として相手を感情的にしてしまい、会話による説得がかえって困難となります。直接的な表現は避けるべきでしょう。
私は以下のような間接的な方法を取ることをオススメします。
- 説得相手に議論の余地を与えない。説得相手と議論をする前に、いくつかの事項についてほかのプロジェクトメンバーと事前に合意をし、説得相手に反論をさせないようにします。
- 説得相手の上司を事前に説得してしまう。これはいやらしくない範囲であれば最も効果的です。
- 説得相手と飲みにいって友達になり、その後でやんわりと説得する。安易かもしれませんが、これが最も有効な手段かもしれません。
いつも怒ってばかりという「リアリティ」を持つBさんを説得する場合、正面から説得しようとしても、労多くして実りはあまりありません。上記のように、「すでにみんなの合意事項になっています」とか「Bさんの上司も納得しています」という状況をつくり出します。その状況で、「従ってくれますよね」「納得してくれますよね」と説得する方法が考えられます。
■本質的に正しい場合
次に、プロジェクトメンバーの「リアリティ」が、プロジェクト成功の視点から見て本質的に正しい場合について考えましょう。
例えば、チーム内の会議で議論を延々戦わせ、結論を出すことを先延ばしにするチームリーダーがいたとします。このリーダーは、一見するとコスト度外視のチーム運営をしているかのようです。しかし、実は最終的な合意形成を重視し、会議で結論を急ぐことに起因する余計な争いを避けて、トータルコストを下げようと考えているのかもしれません。
このような場合、会議でテキパキと結論を出すタイプの人と、上記のような合意形成重視の人とでは、「リアリティ」が異なるように見えます。しかし、最終的なゴールや目的がコスト抑制であるのであれば、アプローチの仕方が違うだけだといえます。
両者の目的が一致し、そこに至るアプローチだけが違う場合、話し合いの余地はあります。最終的にはバランスの問題であり、会議運営のノウハウの違いだけかもしれません。コスト抑制が目的という根本を相互に合意できれば、見掛け上の「リアリティ」が異なっていても、プロジェクトを円滑に推進することが可能です。
つまり、プロジェクトメンバーの「リアリティ」が、プロジェクト成功の視点から見て本質的に正しい場合は、お互いによく話し合い、プロジェクトの成功のために何をすべきか確認することが大切だということです。確認した後は、お互いの持ち味を生かしつつ、相互に過度に干渉しないようにすみ分けることが可能です。
「話し合い」と「相互理解」。これらが重要となります。
■「リアリティ」の違いを克服し、円滑にプロジェクトを運営する
前回の最後で、以下のように「リアリティ」の特性をまとめました。
- 「リアリティ」は人それぞれに異なる。
- 「リアリティ」を変えるのは困難を伴う。
- 大規模プロジェクトでは、「リアリティ」が多様化する。
- 大規模プロジェクトを推進することとは、多様化する「リアリティ」をコントロールすること、と整理できる。
- 変えるのが困難な「リアリティ」が多様化する大規模プロジェクトを運営することは、多様化する「リアリティ」をコントロールすることなので、困難を伴う。
今回は「リアリティ」をコントロールするという視点から、プロジェクト運営を円滑にする方法をご紹介しました。
「リアリティ」の違う人同士が共同作業をすると、時として仕事がうまく進まず、職場でのストレスを生みます。正直なところ、「自分と同じ『リアリティ』を持つ人と仕事をしたい」と私も思います。
しかし、プロジェクト、特に大規模プロジェクトでは、必ずしも「リアリティ」が同じ人や似ている人と共同作業ができるわけではありません。さらにいえば、プロジェクトマネージャという立場の人は、多くのプロジェクトメンバーを管理・監督する責任があります。そのため、多様な「リアリティ」と直面することは避けようがありません。
今回、ご紹介した「リアリティ」の異なる人とのお付き合いの方法を、職場でのストレスが軽減や職場環境の改善、そしてプロジェクトの成功に上手に活用してみてはいかがでしょうか。
| 筆者プロフィール |
| 野村隆●大手総合コンサルティング会社のシニアマネージャ。無料メールマガジン「ITのスキルアップにリーダーシップ！」主催。早稲田大学卒業。金融・通信業界の基幹業務改革・大規模システム導入プロジェクトに多数参画。ITバブルのころには、少数精鋭からなるITベンチャー立ち上げに参加。大規模（重厚長大）から小規模（軽薄短小）まで、さまざまなプロジェクト管理を経験。SIプロジェクトのリーダーシップについてのサイト、ITエンジニア向け英語教材サイト、人材派遣情報サイトも運営。 |
＠IT自分戦略研究所は2014年2月、＠ITのフォーラムになりました。
現在ご覧いただいている記事は、既掲載記事をアーカイブ化したものです。新着記事は、 新しくなったトップページよりご覧ください。
これからも、＠IT自分戦略研究所をよろしくお願いいたします。
