エンジニアに必要なコミュニケーションの力

スキル

» 2009/07/17

第5回：エンジニアに必要なコミュニケーションの力

　第3回、第4回は、技術的な話題をしましたが、今回はエンジニアに必要なコミュニケーション能力についてふれてみましょう。

　ソフトウェア開発に関わるエンジニアといっても、皆さまざまな環境で働いており、その立場によって必要とするコミュニケーション能力は異なると思います。自身の置かれている立場や環境によっては、他人とのコミュニケーションがあまり必要と感じていない方もいらっしゃるでしょうし、また、エンジニアの中にはコミュニケーションを得意としていない方もいらっしゃるかと思います。

　しかし、わたしは仕事をしていく上で非常に重要な能力としてとらえています。このように言っているわたし自身も、若い頃は人とのコミュニケーションはそれほど得意ではありませんでした。今のわたしを知る方には信じ難いことかもしれませんが、あまり話しをしなかった部類であったと記憶しています。現在では、あまり話し過ぎないように自分自身で注意をしていないと、ついつい話し過ぎる傾向にあり、話し過ぎてから反省をしていることも多々あります。　

　人とのコミュニケーションは、一方的に話すのではなく、会話のキャッチボールであり、むしろ相手の思いを聞き出す事が重要です。前述のとおり、わたし自身は、人とのコミュニケーションがあまり得意ではなかったのですが、その後も特にコミュニケーション能力向上に関する専門教育を受けたことはありません。しかし、現在では、特に他人とのコミュニケーションで困ることはありませんし、どちらかといえば他人との会話は好きなほうです。

　その理由はSE（システムエンジニア）やPM（プロジェクト管理者）という仕事を通して、人とのコミュニケーションの重要性を思い知らされ、その能力をなんとか身に着けなければと考え、努力したからだと思います。　エンジニアには高い技術力が備わっている必要がありますが、その高い技術力を活かすためにも、コミュニケーション能力は重要です。

　以降にエンジニアがコミュニケーション力を高めるために考えるべきことをいくつか紹介しますが、けっしてコミュニケーションのテクニックではありません。　

　エンジニアとして、企業のお客様と仕事を進める上で重要な事柄をわたしの経験からまとめたものです。また、今回は“関係構築”、“システムづくり”に焦点をあてていますが、他にもさまざまな局面があり、各局面ごとに順調に仕事を進めるための心構えとコミュニケーションの方法は存在していると考えます。

1．信頼関係を築くため

　人との関係は健全な信頼関係の上に成り立つもので、ビジネスでも同様です。立場を問わず企業の代表として相手企業の代表と会話をしていることを忘れてはなりません。　

　また、困難な仕事を乗り越えるためには、相手企業の担当者との信頼関係はなくてはならないものです。システム開発のプロジェクトを完遂させるまでには、幾多の困難と直面しますが、それらは、作り手企業の努力だけで解決できる問題だけではありません。発注者側企業の協力が有ってこそ乗り越えられる問題も多くあります。そのような局面での協力依頼などは、担当者同士の信頼関係の有無が大きくものをいいます。

　しかし、勘違いをしないでほしいのは、ここでいう担当者同士の関係とは、癒着するということではありませんし、飲み友達になることでもありません。お互いにビジネスマンとして信頼しあう関係を構築することです。では、具体的にどのように信頼関係を築いていくのか、わたしが心がけていることを以下にあげます。

●相手に礼を尽くし協力的である

• お客様である相手には礼儀正しい言動をする
• お互いに企業の代表として仕事を進めている立場ということを忘れない
• 自分が対峙している担当者の企業内での成功とは何かを考えた言動をする（相手の企業内での立場を理解する努力）
• Win-Winの関係を大事にする

●誠実である

• 約束を守り、正直な対応をする
• 問題発生時には早い段階で報告する

●信念を持つ

• 常に意見が一致しない場合もあります。しかし、相手企業の成功につながると思う提案は、多少の逆風には負けず、理解を得られるまで説得する努力をすることも大切です。
• 相手企業の見解に一貫性に掛けている部分がある場合には、その矛盾点を見過ごさず、勇気を持って指摘して改善に努めるように働きかけることが重要です。

　上記の項目は、コミュニケーションをとるためのテクニックというよりも“姿勢”になります。信頼関係を築く上で小手先のテクニックは通用しません。自分自身の取組み姿勢がにじみ出てくるものですから、相手の正面に立って正々堂々とぶつかっていくしかないと思います。

2．正しいソフトウェア・システムを構築するため

　1．は、主に人と人との感情の繋がり（信頼関係）における姿勢についてでしたが、2．はシステム構築におけるコミュニケーションになりますので、コミュニケーションの主体は感情から理論に移ります。　

　この領域においては、当然のことですが、ドキュメントやモデルによって情報の確認を取る手法が中心となり、記述された内容について齟齬が存在していないか判断することが多くなります。　しかし、すべての情報をドキュメントやモデルで網羅できないことがありますので、それを補完する上でその他のコミュニケーションが重要となります。顧客企業が求めるシステムを正確に構築するために必要なコミュニケーションの観点は以下になります。

●要求を正しく引き出す

　段階的に要求を整理することが重要です。ヒアリング → ドキュメント化 → レビューを繰り返して、相互に正しい理解を進めていくことになりますが、その順序や手順を誤ると、無駄に時間を費やすことになりかねません。　

　要求とは何の理由もなしに湧き出てくるものではありません。その裏側には、その要求発生の原因があるはずです。例えば、何らかの問題を抱えており、その課題を解決するための要求事項であったりします。また、その問題にも根本的な原因があり、要求項目の表面だけを見てもその本質を理解できない場合が多くあります。よって、原則的には、“川上から川下”へと段階的に要求事項を整理しながら纏め上げていくことが要求を正しく引き出し、整理する方法となります。　要求事項を整理していく大まかな流れは、以下のとおりです。

• 問題を分析し正しく理解する
• ユーザーニーズを理解する
• 課題解決のためのシステム化範囲を決定する
• システムの詳細化を進める

図1．要求管理の流れ
参考：「Managing Software Requirements A Unified Approach」　DeanLeffingwell/Don Widrig著

　このような基本的な流れを意識しながら相手とコミュニケーションをとることで、大きく論点を外すことなく、ミーティングの場をコントロールするのに役立ちます。

●抽象度と粒度

　要件のヒアリングをする際に、ユーザーはさまざまな事柄を1度に提示してくる場合がありますが、抽象度と粒度の観点から要求事項を的確に整理する必要があります。

　何らかの課題を解決することがシステム化の目的であり、漠然とした問題提起から、詳細なシステム定義に落とし込むには、前述のとおり段階を経て情報の整理をする必要があります。ここでいう粒度とは、ユーザーニーズを言っているのか、システム化において必須となるシステム要件を言っているのかなど、どのレベルについて話しをしているのかを聞き分けることです。　

　また、コミュニケーションをとる上で重要なのが抽象度です。相手が話している内容が、どのぐらいの抽象度なのかを的確に判断する力が重要になります。お互いに異なる抽象度の話をしても会話は噛み合いません。例えば、業務処理における一般的なルールなどは、抽象度が高い話であり、特定業務における処理手続きは、抽象度が低くより具体的な話になります。それぞれ抽象度が異なりますので、どちらについて議論をしているのか正しく理解できていないと会話は噛み合わず、適切な提案もできなくなってしまいます。これは、よりシステム的な議論でも同様のことが言えますので、重要な考え方だと思います。

●誰の要求なのかを追及する

　オーナー不在の要求事項があった場合には、そもそも誰が望んでいる要件なのかを聞いてみるとよいでしょう。もし、会話をしている相手が把握していなかった場合は、その件について認識している人に聞いてみる努力をする必要があります。

上記のような場面に出くわした場合は、システム要件を議論する場に、すべての利害関係者が揃っていない懸念があるからです。

●曖昧さを排除したコミュニケーション

　基本は文章、表、図、モデル化したドキュメントを介してお互いに齟齬が発生しないように努めることでできる限り曖昧さを排除します。　

　しかし、ドキュメントで全ての情報を漏れなく伝えることが可能なわけではありません。記述してある内容が正しくとも、読み手の理解が誤っている場合や、その逆の場合などがあり、最後は人が正しく理解しているかが焦点となります。　

　最終的な相互理解は、レビューの場で相互に正しい理解をしていることを確認するしか方法はありません。わたしが気をつけて実施していることは、重要な事を確認する時に、相手側が“Yes”or”No“ で返事ができないように問いかけ、実現したいことをなるべく相手の言葉で話してもらうようにすることです。　

　例えば、”～の要件はこれで正しいですね？“ という聞き方をした場合、相手は、”はい、正しいです“（または”いいえ“）と回答しますよね。この場合危険なのは、肯定された場合であり、後々、やはりこの要件は誤っていたと前言を翻すことを数多く経験しています。このケースの問題は、相手がこちらからの説明を100％正しく理解せずに”Yes“の回答をしてしまったことです。　

　このような場面では、”～の要件について最終確認をしたいので、要件の概要についてお聞かせくださいますか？“のように問い掛けるよう心がけています。このような場合、相手にひたすら話をさせるのも失礼になりますので、所々、こちらからも問いかけをして、会話を進めていくように努めますが、重要な事は相手の言葉で話していただくことです。これは、自分自身の思い込みによって誤った業務処理の理解や、それに伴うシステム設計段階での齟齬を少しでもなくすようにするためです。

3．最後に

　今回はエンジニアが身に付けたいコミュニケーションについてをテーマとし、企業ユーザーのシステム構築に関わるSEの視点で書いてみました。　

　この他にも、お客様やプロジェクトのメンバーと健全な関係を維持するためのコミュニケーションの秘訣はたくさんあると思います。また折を見てご紹介できればと考えております。