コミュニケーション能力が低いと稼げるSEになれない

コミュニケーション能力（コミュ力）が高い人って、どんなイメージがありますか？

学生の方だと、話が面白い、一緒にいて飽きない、友達が多い、といったイメージがあるかもしれません。

そういったリーダーシップ的なコミュ力も重要ですが、システム開発で特に重要となるコミュ力は「ユーザーの話を聞いて、ユーザーが納得いく説明をできる」能力です。

話を聞いて説明するって、当たり前では？と思うかもしれません。

だけど、これが、かなり奥が深いのです。高いレベルでこれを遂行できるSEは、業界全体の10％以下だと思います。

要件定義工程などで、エンドユーザーとコミュニケーションする際の注意点についてまとめてみます。

ユーザーとの会話は異文化コミュニケーション

受注したばかりの最初の段階では、ユーザー企業の事務はまったくわかりません。ここから、最初のステップとして現状事務のヒアリングを行ないます。その際、現状事務を100％ちゃんと説明できるユーザーはほぼいません。

「以心伝心」という言葉がありますが、日本人は「細かく説明しなくても何となく理解してもらえるさ」といった風潮があります。また、ユーザーは説明のプロではないので、説明に抜け漏れがあったり、同様の社内文化を経験していない人に対してわかりやすい説明はできません。

従って、システム開発を進める上で、必要な情報をユーザーから漏れなく聞き出すためには、独特のコミュニケーション方法が必要になります。

コミュニケーション上の注意点

ユーザーは必ずしもコミュニケーションが上手とは限りません。また、このシステム開発プロジェクトに上司の指示で仕方なく参加しているのかもしれません。従って、あなたがやる気を持ってユーザーヒアリングしたとしても、無策では、ユーザーからうまく話を引き出せない可能性があります。

共感する

ユーザーの話を「共感」して聞くことを心掛けましょう。「共感」を辞書で調べると「他者と喜怒哀楽の感情を共有すること」とあります。つまり、相手の話を聞く際に、できるだけ相手の立場に立って積極的にヒアリングすることで、相手は気持ちよく話しやすい状態になっていきます。アクティブリスニングというコミュニケーション技法が有効です。これにより、より多くの情報をユーザーから引き出すことができます。

IT用語(カタカナ言葉）はできるだけ使わない

ユーザーとの会話は、異文化コミュニケーションと言いました。あなたがユーザー業務の専門用語がなかなか理解できないのと同様に、ユーザーは、あなたの話すIT用語の理解に苦労しています。できるだけ平易な言葉を使い、IT用語の使用は極力控えましょう。

＜システムエンジニアがユーザーに思わず言ってしまいそうになる言葉と、その言い換え＞

・本番リリース日　→　システムが完成して実際に利用できる日

・UAT　→　ユーザー側で行なう最終確認の受け入れテスト

・データベース・(RDBの)テーブル　→　登録情報などを蓄積したデータの塊

・ログ履歴　→　操作情報の蓄積データ

アクティブリスニング

アクティブリスニングの手法はいくつかありますが、システム開発のコミュニケーションでは「オウム返し」、「明確化」の２つを多用します。

オウム返し

「オウム返し」とは、相手が言った言葉を”そのまま”繰り返すことです。ただし、ユーザーとのコミュニケーションでは、”そのまま”繰り返すのではなく、より具体的に言い換えて曖昧な点を確認します。ユーザーは細かい部分まで説明していないことが多く、詳細設計を作る上で、踏み込んだヒアリングが必要だからです。

一例をあげます。

こんな感じで、ユーザーの説明を確認しつつ、細部を確認していきます。できれば、ユーザーが実際に事務で使用している資料を入手し、質問点をまとめておくと効率的に進められます。その際、以下の点に気をつけましょう。

・時限性：通常、何時に行っている業務なのか。遅延すると何が起こるか。

・データバリエーション：各項目のデータ種類はどのようなものがあるのか。

・事務量：何件くらいの事務か。またそれを何時間以内に処理する必要があるか。

・事務のパターン：事務フローに種類はあるか。また、特殊な事務フローはあるか。それはシステム開発の対象外として問題ないか。

 

明確化

「ほとんどやっています」「あんまり行っていない」という言い回しはよくありますが、「ほとんど」「あんまり」は人によって程度が違います。こういった曖昧な表現は、数値化して確認しましょう。例えば、「１０件中の何件くらいでしょうか？」といった聞き方をします。

また、ヒアリング結果を可視化して再度、確認してもらうことも大事です。口頭でヒアリングしたことは認識相違があったり、時間が経つと忘れたり、他のユーザーは違う意見を言うかもしれないからです。

具体的には、設計書のドラフト資料や、議事録などを作成して確認してもらいましょう。開発者の人数が多い場合は、ユーザー事務の専門用語をまとめた用語集を作るのも効果的です。

質問のやり方

オープンクエスチョンとクローズドクエスチョンを使い分けましょう。

オープンクエスチョンは、「それはどのようなものですか？」という風に自由に回答できる質問です。クローズドクエスチョンは、「これでよいですか？」という風に「Yes」「No」のどちらかで回答する質問です。

要件定義工程でのユーザーヒアリングは、前半と後半に分かれます。

前半は、ユーザーに作って欲しいシステム・機能を自由に聞き、できるだけ、オープンクエスチョンで質問します。この方が、レアケースのヒアリング漏れが少なくなります。

後半は、ヒアリングした結果をまとめていきます。作成した資料や、ちゃんと確認できていないがおそらくこうであろうという要望を可視化して、認識相違がないかをクローズドクエスチョンで確認します。

ヒアリング相手について

開発体制図を作成し、ユーザー体制のうち、それぞれの所属の方に最低1名以上、ヒアリングをします。できれば、部長以上の経営目線でシステム化戦略を考えている方、システム化対象範囲の部署の取り纏めの方、エンドユーザーの方の3者にはヒアリングしましょう。エンドユーザーは、事務フロー上の登場人物のうち事務に詳しい方、数名にヒアリングします。

まとめ

ユーザーへのヒアリングが不十分で要件の認識相違が発生して、ユーザー受入テストの段階でそれに気づき、大きな手戻り（開発のやり直し）が発生したというのは、よくあるシステム開発の失敗パターンです。

システム開発は上流工程で固めた内容が後続フェーズ全てに影響を与えますので、ユーザーヒアリングがちゃんとできることは、開発を成功させる上で死活問題になり得ます。アクティブリスニングをうまく活用して、ユーザーとうまくコミュニケーションを取りましょう。