第8回 コミュニケーションはリーダーシップの基礎
野村隆(eLeader主催)
2005/10/20
将来に不安を感じないITエンジニアはいない。新しいハードウェアやソフトウェア、開発方法論、さらには管理職になるときなど――。さまざまな場面でエンジニアは悩む。それらに対して誰にも当てはまる絶対的な解はないかもしれない。本連載では、あるプロジェクトマネージャ個人の視点=“私点”からそれらの悩みの背後にあるものに迫り、ITエンジニアを続けるうえでのヒントや参考になればと願っている。 |
■リーダーシップの基礎はコミュニケーション
前回の「中心は『ココロ』、リーダーシップトライアングル」で、私が考えるリーダーシップのフレームワーク、リーダーシップトライアングルの概要を説明しました。
前回も各構成要素について簡単に触れましたが、今回は予定どおり、リーダーシップトライアングルの構成要素のうち、全体の基礎となる「Communication」(コミュニケーション)を解説します。
図1 リーダーシップトライアングル。今回は「Communication」(コミュニケーション)について解説する |
コミュニケーションはリーダーシップの基礎なので、リーダーシップトライアングルでも下のレイヤに配置しました。
リーダーシップの各種教科書にもリーダーシップとコミュニケーションは表裏一体であると書かれています。私も同意します。プロジェクトが大人数になればなるほど、プロジェクトのリーダーとメンバーとの対話も増えるでしょう。
上下のコミュニケーションは指示命令系統となることが多いでしょう。そのほかに横に連携するコミュニケーションもあります。
例えば、チームをまたがって横断的に作業をする局面があります。チームに分かれてシステムを設計し、各チームの設計完了時点で、チームをまたがった設計の整合性確認をすることもあるでしょう。システム導入前のテスト(運用テストとか運転試験とかいいますね)において、システム全体を通してテストするための試験項目を挙げるような横の連携の取り組みもあります。
経験のある方なら、こういう取り組みは結構骨の折れる重要な作業だとご理解いただけるかと思います。
SI(システム開発)プロジェクトの規模が大きくなればなるほど、上下のコミュニケーション、横のコミュニケーションが複雑になる傾向にあり、コミュニケーションが滞ってしまうリスクも高くなるでしょう。リスクが高い状況で、上記のような縦横無尽のコミュニケーションをつかさどるべきリーダーが、何もいわずに「黙っておれについてこい」というのでは、メンバーはリーダーが何を考えているのか分かりません。やはりリーダーシップ、特に大規模SIプロジェクトにおけるリーダーシップの基礎はコミュニケーションなのです。
■コミュニケーションの手続きと本質
SIプロジェクトには、さまざまなバックグラウンド(過去に培った経歴や能力)を持った人が集まります。システムのユーザーの代表として、アプリケーション開発の専門家として、ハードウェアやソフトウェアの専門家としてというように、さまざまな経験・能力を持つ人が集まって、SIプロジェクトを遂行します。
SIプロジェクトでは、このようなバックグラウンドの異なる人を抱えて、一定期間に与えられたミッションを完遂することが求められます。バックグラウンドが異なれば、興味や関心も異なります。このような人たちを取りまとめてミッションを完遂するためには、電子メール、口頭、書面など方式を問わず、対話を通じてプロジェクト全員が共通認識を持つことが重要となります。問題は、いかに効果的・効率的にコミュニケーションをしていくかということになります。
効果的・効率的にコミュニケーションするために、一般的には以下のようなことがポイントとして挙げられます。
- 構造的な体制をつくり、上下関係を明確化する
- 体制に応じた会議を定期的に開催し、かつ会議のミッションをクリアにする
- 会議のアジェンダを事前に共有しておき、効率的に会議を運営する
- 電子メールと口頭の連絡を使い分け、コミュニケーションを円滑にする(電子メールは込み入ったコミュニケーションには不向き。口頭は記録が残らず、同一内容を一斉に通知するには不向き)
- 電子メールの書き方を工夫して相手に伝わるようにする(文を切る、だらだら書かない、個条書きにするなど)
書店に行けば、これらのポイントを紹介する良書が平積みされています。細かい解説はそれらの良書に譲ります。とはいえ本を読み、なるほど理解した、これでコミュニケーションはバッチリだ、と思い込むのはちょっと危険かと思います。なぜかというと、これらのポイントは手続きの議論、もっというと小手先の議論と考えるからです。
確かに手続きは大事なことですけれども、手続きを改善するだけでは単なる対症療法となることが多く、SIプロジェクトにおけるリーダーシップのためのコミュニケーションという文脈では不十分なのです。
手続きの議論の前に、コミュニケーションに関して本質的なことを考える必要があります。本質的なことを見落として手続きに固執してしまっては、意味がないといいますか、せっかくの手続きが生きないと思います。
■人間とコンピュータを混同しない
では、リーダーシップにつながる本質的なコミュニケーションについて考えましょう。この連載では分量の都合もあるので、主要な2つの視点、ITエンジニアに多い2つの問題点から解説します。
1.人間との付き合いをコンピュータとの付き合いの延長で考える人
2.後ろ向きな人でも何とかなってしまう社会
まずは1つ目の「人間との付き合いをコンピュータとの付き合いの延長で考える人」について解説します。
SIプロジェクトにおけるリーダーは、元ITエンジニアであることが多いですね。元ITエンジニアがリーダーになること自体は、歓迎すべきことと考えます。やはり現場で苦労した経験のある人が現場のリーダーになる方が、現場のITエンジニアを円滑に管理できるからです。
とはいえ、元ITエンジニアのリーダーにありがちな問題があります、コンピュータとのコミュニケーションと対人コミュニケーションをはき違えることです。
コンピュータは、とても気が利かないものです。例えば、仕事上重要なExcelやWordのファイルを間違えて削除してしまったという経験はありませんか。コンピュータは「これは重要なファイルだから消しちゃだめだよ!」とはいってくれません。人間だったら、重要な書類をゴミ箱に捨てるところを見たら「捨てちゃだめだよ!」と声を掛けてくれそうなものです。
一方、コンピュータのいいところは、気が利かないところの裏返しで、同じことを何万回でも繰り返し実行し、しかも正確であるということです。人間ではこうはいきませんよね。同じ計算を10回くらい繰り返したら、普通は飽きて嫌になるし、間違えることもあります。
こういう性質を持つコンピュータとの付き合いが長いITエンジニアが、「正しいインプットを与えれば、必ず正しいアウトプットが出る」という考えを持ってしまってもおかしくはありません。ただ残念ながら、コンピュータでなく人間を相手にしていると、このようにうまくはいきません。むしろ以下のような矛盾に悩まされることが多いでしょう。
- 正しいインプットを与えたにもかかわらずアウトプットが間違っている
- 間違ったインプットを与えたにもかかわらずアウトプットが正しい。もしくは予想以上である
人間を相手にしている以上、これは当たり前です。人間は間違いを犯します。間違うことのない人間はいません。人間は努力をします。努力の結果、少ないインプットから予想以上のアウトプットを生産することがあります。人間との付き合いをしている人は理解していることですが、コンピュータとの付き合いが長い人は、こういうあいまいさというか、良くも悪くも柔軟性が理解できません。そうなると、だんだん人間不信に陥るわけです。
つまり、コンピュータとのコミュニケーションに過度に親しむと、人間とのコミュニケーションとコンピュータとのコミュニケーションを混同してしまいます。人間はコンピュータほど正確ではないし、飽きっぽいし、いいかげんなのです。このことを理解していないITエンジニアが結構います。
このような、ITエンジニアの陥りやすいコミュニケーションにおける問題点を把握し理解することが、SIプロジェクトにおけるコミュニケーションの基礎となるのです。
■好感度に鈍感にならない
次に、2つ目の「後ろ向きな人でも何とかなってしまう社会」について解説しましょう。
上記の問題点に関連しますが、結論を先にいいますと、ITエンジニアは後ろ向きでも何とかなってしまうことが多く、コミュニケーション能力を身に付けるチャンスを失っていることが多いのです。
そもそもコンピュータとのコミュニケーションにおいては、キーボードとマウスを通してのものが主なので、前向きな態度を取り、さわやかなあいさつをする必要はありません。コンピュータにあいさつする人がいたらかえって気味が悪いですよね(たまにいますけれども)。つまりITエンジニアは、無愛想に接しても問題ないコンピュータと、継続してコミュニケーションする機会が多いといえます。
ITエンジニアに限らず、いわゆる専門家、スペシャリストという人たちは、自分の専門領域を持ち、その専門性を求めて他人が集まってくるので、人としての好感度に鈍感になる傾向にあります。例えば医者にかかったときに、医者の横柄な態度に不快になったことはありませんか。その医者に能力があれば、無愛想にしていてもお客さんは集まってきます。無愛想であっても商売が成り立つし、能力があれば、さらに無愛想になっても問題ないと勘違いをする医者もいるかもしれません。
同じことがITエンジニアにもいえます。ITエンジニアも、スキルがあるという理由で他人に頼りにされる限りは、無愛想でも何とかなります。周囲もITエンジニアが大半なので、自分が無愛想であることにすら気付かないでしょう。この点も、ITエンジニアのコミュニケーション能力が総じて低いことの根本的な原因の1つと理解しています。
しかし、職位・職制が上がるに従い、ITエンジニア以外の人とも接するようになります。無愛想なままでは相手に不快感を与え、円滑なコミュニケーションができなくなります。さらに職位・職制が上がり、コンピュータスキルを身に付ける機会が減ると、自分の部下の方が高いコンピュータスキルを持つようになり、コンピュータスキルにあぐらをかいて無愛想な態度を取ることができなくなります。
ここが元ITエンジニアのリーダーの1つの分かれ目と思います。自分の職位・職制にふさわしいコミュニケーションスキルを身に付け、好感を持たれる人間を目指すか。または過去の自分にしがみつき、コンピュータスキルに固執し、無愛想なままでいるか。
医者の例をまた出しますが、非常に人柄が良く、コミュニケーションも円滑で、かつ能力の高い医者はいます。こういう人は接していて気分がいいですし、人気があり商売も繁盛しています。皆さんも人柄が良く、コミュニケーションが円滑で、かつスキルのあるITエンジニアになりませんか。
■本質的なコミュニケーション能力を身に付けよう
このような根本的な原因を把握し、SIプロジェクトにおけるリーダーシップの基礎としてのコミュニケーションを身に付ける方策を考えましょう。やみくもにコミュニケーションの手続きに関する本を読みあさり、コミュニケーションの手続きだけを追い求めるやり方は、効率的ではないと思います。手続きも大事ですが、それだけでなく、SIプロジェクトにおける本質的なコミュニケーションについての考え方や問題点を把握したうえで手続きを学習し、実践することが重要と思います。
上記の問題点を理解することが、リーダーシップの基礎としてのコミュニケーションにとって重要であることは間違いないと思います。ただ、これで十分かというとそんなことはないでしょう。今回ご紹介した2点以外にも問題点はあります。
また、コミュニケーションは、世代が替われば方式も変わり、時代に応じたものが必要となります。私自身も日々コミュニケーションを学んでおりまして、新しい発見の連続です。今後の連載でも、コミュニケーションに関する考え方を紹介する予定です。
私が主催するブログサイトはリーダーシップトライアングルの構成要素、Communication/Vision/Management/Loveによってトピックが分類されています。興味のある方は参照してくださると理解が深まるかと思います。サイトトップページの右上に分類が表示されています。
次回はリーダーシップトライアングルの個別構成要素のうち、VisionとManagementを解説する予定です。ご期待ください。
筆者プロフィール |
野村隆●大手総合コンサルティング会社のシニアマネージャ。無料メールマガジン「ITのスキルアップにリーダーシップ!」主催。早稲田大学卒業。金融・通信業界の基幹業務改革・大規模システム導入プロジェクトに多数参画。ITバブルのころには、少数精鋭からなるITベンチャー立ち上げに参加。大規模(重厚長大)から小規模(軽薄短小)まで、さまざまなプロジェクト管理を経験。SIプロジェクトのリーダーシップについてのサイト、ITエンジニア向け英語教材サイトも運営。 |
@IT自分戦略研究所は2014年2月、@ITのフォーラムになりました。
現在ご覧いただいている記事は、既掲載記事をアーカイブ化したものです。新着記事は、 新しくなったトップページよりご覧ください。
これからも、@IT自分戦略研究所をよろしくお願いいたします。