SEに求められるコミュニケーション力とは？　ヒューマンスキルとして必要なこと

# **はじめに**
社会人になってから10年が経ち、自分も周りも色々なチームや会社で経験をしてきました。
携わる業務や作るもの、時には職種も違う人とでも仕事の話をしていると、**ヒューマンスキル**でカテゴライズすると大体似たようなところに落ち着きます。
技術の話ではないですが、どうしても言語化しておきたかったので私の考える理想論として記事にします。

以下3点でまとめます。

- **コミュニケーション力**
- **推進力**
- **道徳心**

## **記事要約**

かなり長い記事になったので、先に要約と参考を記載しておきます。

- **コミュニケーション力**
	- 大事なのは、**会話を通じて目的を把握・達成すること**
		- この会話は何が目的なの？を意識して話す or 聞きだす
		- きちんとお互いの認識が合っていることを確認しながら話す

- **推進力**
	- みんなを**前に進めようと何かしらの行動すること**
		- リーダーシップを持ってグイグイ引っ張っても、フォロワーシップ(周りが前に進めるようにフォローする)でも、**手段は何でもいい。前に進めよう！**
	- 推進しない停滞した会議、どうしよう？
		- **会議はある目的に対する成果物を出す場**。それ以外の議論は別の場で
		- 議論が平行線で結論の出ないのは、大体「好みの問題」。**目的は果たせるならどっちでもいい。**
- **道徳心**
	- その人ごとの**好み、培った文化に違いがあることを理解する**。
		- 相手も正論を言っている議論では、**「あ～、この人の文化ではこういう考え方をするんだな」と思う**だけでも、自分が熱くならずに落ち着いて決断できるかも。
	- 人に対する思いやりをもつ。
		- 人間同士でやっていることなんだから、**どうせだったら気持ちよく仕事しましょうよ！**

### **この記事を書くにあたり、参考にしたいと思った手法**

- **コミュニケーション力**
	- 情報を引き出す話し方の参考にいいと思います	
	[SE的声かけ変換表](https://qiita.com/ukiuni@github/items/acd53340f19198d94998)

- **推進力**
	- 前に進むためのアイディアだしにいいと思います	
	[エンジニアの為の、アイデア効率化](https://qiita.com/Reyurnible/items/342352a0b145a4736ae0)
	- フォロワーシップ(書籍)(記事の参考にしてます)	
	[リーダーシップからフォロワーシップへ](https://www.amazon.co.jp/%E6%96%B0%E7%89%88-%E3%83%AA%E3%83%BC%E3%83%80%E3%83%BC%E3%82%B7%E3%83%83%E3%83%97%E3%81%8B%E3%82%89%E3%83%95%E3%82%A9%E3%83%AD%E3%83%AF%E3%83%BC%E3%82%B7%E3%83%83%E3%83%97%E3%81%B8-%E3%82%AB%E3%83%AA%E3%82%B9%E3%83%9E%E3%83%AA%E3%83%BC%E3%83%80%E3%83%BC%E4%B8%8D%E8%A6%81%E3%81%AE%E7%B5%84%E7%B9%94%E3%81%A5%E3%81%8F%E3%82%8A%E3%81%A8%E3%81%AF-%E4%B8%AD%E7%AB%B9-%E7%AB%9C%E4%BA%8C/dp/4484182033)
	- 会議手法	
	[会議の進め方 | 知らないと損する5つのフレームワーク](http://the5seconds.com/meeting-procedures-2443.html)	
	[知っておきたい会議の手法6選](http://heart-quake.com/article.php?p=1490)
- **道徳心**
	- 思いやりの詰まった会話術	
	[「進捗どうですか？」より2015倍捗る「困ってますか？」](https://qiita.com/tatesuke/items/fd5483be1b72727d3d34)

	- 楽しく仕事をするには？(書籍)	
	[フィッシュ!―鮮度100％ぴちぴちオフィスのつくり方](https://www.amazon.co.jp/%E3%83%95%E3%82%A3%E3%83%83%E3%82%B7%E3%83%A5-%E2%80%95%E9%AE%AE%E5%BA%A6100%EF%BC%85%E3%81%B4%E3%81%A1%E3%81%B4%E3%81%A1%E3%82%AA%E3%83%95%E3%82%A3%E3%82%B9%E3%81%AE%E3%81%A4%E3%81%8F%E3%82%8A%E6%96%B9-%E3%82%B9%E3%83%86%E3%82%A3%E3%83%BC%E3%83%B4%E3%83%B3%E3%83%BBC%E3%83%BB-%E3%83%A9%E3%83%B3%E3%83%87%E3%82%A3%E3%83%B3/dp/4152083263)

- **その他**
	- 人生にプラスになる要素が凝縮された[7つの習慣](https://www.amazon.co.jp/gp/search?keywords=%8A%AE%96%F3%207%82%C2%82%CC%8FK%8A%B5&__mk_ja_JP=%83J%83%5E%83J%83i&tag=jmatsuzaki-22)(書籍)、分厚くとも一読の価値あり。下のURLは概要です。	
	[今さら人に聞けない！7つの習慣が３分でわかる要約とまとめ！](https://jmatsuzaki.com/archives/3346)

その他これまでの経験の中で得た考えが沢山含まれていますので、ここで紹介した以外の様々なものを参考にしています。
上記の他にも沢山いい記事はあると思いますし、皆さん何かしらの考えを持って仕事されていると思いますので、是非飲み会等の場などで真面目にこういった話を聞いてみると、面白い持論や体験談が聞けるかもしれませんね。


以下本題です。内容は上記の深堀なので興味がある方だけどうぞ。

# **コミュニケーション力**

wikipediaによると以下だそうです。
>コミュニケーション能力（コミュニケーションのうりょく、communication ability）とは、一般的に「他者とコミュニケーションを上手に図ることができる能力」を意味する。

友達同士ならおしゃべりが上手とか誰にでも打ち解けられるみたいなイメージを持たれてますが、仕事におけるコミュニケーションってなんなんでしょうね？
私はコミュ障なので楽しいおしゃべりは苦手ですが、仕事内でのコミュニケーションに困ることはないし、矢面に立つ場面もよくあるので、単純なトークスキルは関係ないようです。

そんな私が今までで感じた仕事におけるコミュニケーション能力、一言でいうと
**会話を通じて、目的を把握・達成する能力**だと思います。

コミュニケーションなので、自分⇒相手と、相手⇒自分の2方向に対してこれが出来ればいいのかなと思っています。

##**自分の伝えたい目的を正しく言語化する**

自分が回答する場合、質問・依頼する場合で考えます。

###**コミュニケーション失敗例1: 回答が迷路のような会話**

例えばこんなことがありました。

とあるシステムのUIがあるケースだと動かなくなるので、AさんがBさんに調査依頼。Bさんから回答を受けます。
結果がわかりましたとうれしそうなBさん。
Aさん「お、原因わかったんだ！」
Bさん「はい、原因わかりました！モジュール2が動いてませんでした。」
Aさん「(UIの先で使ってるのかな？)じゃあモジュール2を直せば解決だ！」
Bさん「いえ、モジュール2が想定していないデータをモジュール3が送信してました」
Aさん「(？UIが直接使うのがモジュール3)てことはモジュール3の問題？」
Bさん「このモジュール3の渡しているデータの元はモジュール4でして…」
満足げなBさんに対して、Aさんにとっては今回の問題の原因調査結果からどんどん離れているように感じてしまいます。
この話、ゴールであるUIの件につながるんだよね…？

<img width="1000" alt="ゴールのない会話.png" src="https://qiita-image-store.s3.amazonaws.com/0/252277/9105721d-da5d-b09b-88d0-9d05429f567c.png">


実際の話はこうでした。

**UIが動かない理由**

- UIが動いていない原因は、異常データを受け取ったせいでモジュール2が動いていないから。
	- UIはモジュール2の持っているデータを表示するため、UIを動かすためにモジュール2が動くことが必須だった。

**モジュール2が動かない理由**

- 異常データをモジュール2に送信しているモジュール3の問題。このデータは異常値なのでどこかでエラーになる想定なのに、エラーにならずモジュール2に渡ってしまい、モジュール2想定外の動作で動かなくなってしまった。
- データの送信順はUI⇒モジュール4⇒モジュール3⇒モジュール2の順。解決策としては以下2点のどちらか
	- モジュール3がエラーを返す
	- モジュール4がエラーを返す

これを踏まえてBさんの会話を思い出すと、下図の**赤字情報が抜けているだけでBさんなりに情報を伝えている**んですよね。
<img width="1000" alt="ゴールに向かった情報を追加.png" src="https://qiita-image-store.s3.amazonaws.com/0/252277/32ccf0d0-df95-43f0-ad7c-e9281612db11.png">

でも実際には色々赤字を引き出して、やっとゴールにたどり着く形。
Bさんは正しく調査をして正しく状況を把握しているのに、**正しくその時々の目的を言葉にしてないだけで情報が伝わらない**。
こんなことってよくありませんか？

###**コミュニケーション失敗例1: どうすればよかったか**

**相手からの質問に対する回答を先にする。もしくはゴールまでの道筋を提示する。**これだけで大分目的が伝わりやすいと思います。

上の例なら、
UIが動かない原因は？
⇒モジュール2が動いていないことが原因です。

もしモジュール3, 4の説明も必要なら、

UIが動かない原因は？
⇒まずUIに関係のあるモジュール2, 3,4の関係性について説明させてください。これらがUIが動かない原因に関わるので。

といった形でゴールまでの道を伝えてあげるだけで大分印象が変わると思います。

後は情報量が多くなると忘れてしまうので**ノート等で記載しながら話す**のも手だと思います。
記載するのは絵じゃなくても、
**「UIが動かない原因」⇒「モジュール2が動いていない」のような事実の羅列**
があるだけでも私的には効果大です。

###**コミュニケーション失敗例その2: 依頼側の情報不足**

別のケース。開発中のスマホUIのキャプチャが欲しいとCさん。
実機は手元にないし、開発だからエミュレータ―(PC上でスマホを再現したソフトウェア)での画面キャプチャが欲しいんだよねとDさん。
でも実機でのサイズ感を見たかったらしく、Cさん激怒。Dさん的には知らないよって状態。
上司の依頼が情報不足で困ること沢山ありますよね。

こちらも**Cさんが目的を伝えてあげれば解決するのに**。
<img width="1000" alt="目的のない依頼.png" src="https://qiita-image-store.s3.amazonaws.com/0/252277/2446a55e-eddf-851a-5cfc-c5d121edb554.png">


###**自分の伝えたい目的を正しく言語化するには　まとめ**

1. **何がこの対話の目的か、意識して発言する**
	- 質問・依頼時の目的⇒相手から期待する情報を得ること。**期待する情報を正しく言葉にして伝える**。
	- 回答時の目的⇒相手の質問、依頼に沿う回答をすること。**相手からの質問に対する回答が優先。必要情報があるなら回答までの道筋を示してあげる**。
2. **認識があっていないようなら、整理しながら説明する。**筆記も交えると効果的。

どちらも出来るだけ自分も相手も頭を使わせないようにするというポイントがある気がします。

##**相手の伝えたい目的を正しく理解する**

先ほどの失敗例、極端な表現にしましたがよくある話だと思います。つい気付いたら相手も自分と同じように考えてくれてると思ってしゃべってしまう。本人に悪気はないので、聞き手が情報を整理してくれたら嬉しいですよね。

先ほどの**コミュニケーション失敗例1**の対話を質問上手のEさんがやるとどうなるでしょう。
雲型の枠内と会話内()はEさんの頭の中。()の内容に合わせて雲型の枠内の状況を整理して話をしています。

<img width="1000" alt="会話をゴールに向ける.png" src="https://qiita-image-store.s3.amazonaws.com/0/252277/b260ebb7-0f47-1abd-c8ae-28c4ca6ac3a9.png">

よく見てみると、Bさんの回答は変わっていないんですが、その都度**Eさんが話を頭の中で整理して認識を合わせてくれるため、ちゃんとBさんの調査結果を正しく引き出せています**。

私はスムーズに頭の中で出来ないので、やるならノートを片手に必死に認識合わせながら話を聞きます。

**コミュニケーション失敗例その2**でも、Cさんに「このキャプチャは何に使うんですか？」と**Dさんが目的を聞くだけで避けられたかも**しれませんね。Cさんめっちゃ切れてるから聞きにくそうだけど。

###**相手の伝えたい目的を正しく理解するには　まとめ**

1. **何がこの対話の目的か、意識して聞く**
	- 質問・依頼時の目的⇒相手から期待する情報を得ること。**話がずれるなら回答者が何に対する回答をしているのか認識を合わせる。**
	- 回答時の目的⇒相手の質問、依頼に沿う回答をすること。**相手からの質問に対する回答が優先だが、目的が合わない・わからないなら認識を合わせる。**
2. **認識があっていないようなら、整理しながら説明する。**筆記も交えると効果的。

といった感じでしょうか？

どちらにしても、相手と認識があっているか都度確認することが大事なのかなと思います。

##**コミュニケーション力 まとめ**

最初にも書いたように、**相手と目的を合わせる**ことが出来るかどうかがポイントではないかと思います。
良く教わる報・連・相。これもこういった認識合わせをするために必須なので、私は好きです。

# **推進力**

コミュニケーションにも通じるところですが、**結局仕事を前に進めないことにはしょうがない**です。
ここでも技術でも知識でもないヒューマンスキル的な部分も大いに関わってくると思っています。

## **ここでいう推進力とは**

推進力って聞くとリーダーシップを持ってグイグイ引っ張る力を思い浮かべるかもしれません。でもここでは、それだけに限定していません。
**手段は問わない、自分に合った手段でみんなを前に進めることの出来る力**のつもりで書いています。

今回は[リーダーシップからフォロワーシップへ](https://www.amazon.co.jp/%E6%96%B0%E7%89%88-%E3%83%AA%E3%83%BC%E3%83%80%E3%83%BC%E3%82%B7%E3%83%83%E3%83%97%E3%81%8B%E3%82%89%E3%83%95%E3%82%A9%E3%83%AD%E3%83%AF%E3%83%BC%E3%82%B7%E3%83%83%E3%83%97%E3%81%B8-%E3%82%AB%E3%83%AA%E3%82%B9%E3%83%9E%E3%83%AA%E3%83%BC%E3%83%80%E3%83%BC%E4%B8%8D%E8%A6%81%E3%81%AE%E7%B5%84%E7%B9%94%E3%81%A5%E3%81%8F%E3%82%8A%E3%81%A8%E3%81%AF-%E4%B8%AD%E7%AB%B9-%E7%AB%9C%E4%BA%8C/dp/4484182033)という本の中の話を例に説明したいと思います。詳細は本をご購入ください！

本の著者の中竹竜二さんは元早稲田ラグビー部監督。その前任は清宮克幸さんというリーダーシップ溢れる監督だったそうです。

### **リーダーシップ 引っ張る力**

前任の清宮さんが持つのは強烈なカリスマ性。部員はみんなこの人の説得力、実行力に惹かれ、従って大変な練習もこなします。そうやって強くなる早稲田ラグビー部。
自分が引っ張り前に進める、リーダーシップを体現したような方だったようです。

ただこういったカリスマ性を持っている人は一握りです。すべてのチームにこんなカリスマリーダーがいるんでしょうか？後任の中竹さんも違うタイプの方だったそうです。

### **フォロワーシップ チームが前に進むなら、引っ張るのは自分じゃなくてもいい**

中竹さん自身は、リーダーシップを持って引っ張るようなタイプの人ではなかった。
それでも早稲田ラグビー部で全国大学選手権2連覇を達成するなど、相変わらず強豪早稲田ラグビー部を作り続けました。
中竹さんはどのようにチームを前に進めたのでしょう？

中竹さんはチームを引っ張る力はそこまで持っていないけど、その代わりに人の能力を見極め、目的意識を持たせて**個人が積極的に動けるようにフォローをする**のが得意だったとのこと。
中竹監督としての理想の形は、「中竹監督がいなくても、僕らだけで大丈夫です！」と部員が自主的にこなすようになることだとか。
手段は違いますが、どちらもきちんとチームを前に進めることが出来る、立派な監督ですよね。

### **前に進める手段は各自に合ったスタイルがある**

上記もあくまで例の一つで、この2つのやり方が推進力だって話ではないです。
**これらは手段の1つ。前に進めるための自分に合う形のスタイル**があればそれでいいんです。どんな手段でも前進できるならそれでよし！

例えば私の今のスタイルはこんな感じです。

**私の仕事でのスタイル: とにかく参加、共有、発信**

- **自分が情報提示出来そうな問題があれば参加。**
	- 近くの人の会話を何気なく聞きつつ、解決策が出せるなら会話に参加する。	
	向かいの席にいる別チームの話でも、「こうなってたらしいですよ」と参加する。
- **情報はとにかく共有、展開**
    - 前に進むために必要そうな情報を聞けば展開します。大事な情報ならメール+口頭でキーマンに説明します。    	
    こっそり仕様変更しようとしてる人がいたら、本人に確認してすぐメーリスで仕様共有します。(チクり魔ではないです笑)
- **とにかくたたき台を作って発信**
	- 停滞している仕様検討の原因はものがないからってことが多いです。関わっていない検討話でも、たたき台ならやる気になればヒアリングしまくって状況整理すれば1日あれば作れたりします。	
	まずは滞ってる話のネタを作って発信。関係者にヒアリングしてブラシアップすればそれでベースの仕様案完成！	
	問題解決に携わるのって楽しくないですか？

こうやって色々なことに首を突っ込んでいたら、仕事も進むし、結果信頼を得られ、色々な場面で頼っていただけるようになったと思います(ヘイトも溜まってるかもしれませんが笑)
至らない部分、無駄な部分も多々あるのでこの辺は日々模索中です。

### **なんでもいい、前に進むための行動を起こそう！**

今までのものはほんの一例です。自分に合った、自分に出来る、前に進むための手段は何かあると思います。
それを実行できればそれだけでチームは動き出すはず！

<img width="600" alt="前に進める.png" src="https://qiita-image-store.s3.amazonaws.com/0/252277/8974c781-41b0-33ee-9935-50432cb2b3c1.png">

## **どうにかしたい、前に進むのを阻害する停滞した会議**

「前に進める」というキーワードで、私が必ず思い浮かぶのは会議。大勢に人を集めて数時間、結果何も得られませんでしたなんて無駄な会議、皆さん経験ないでしょうか？
私自身この辺りの手段については勉強中ですが、基本的な考え方は誰に聞いても共通な気がします。

よく見る停滞する会議、私の中では2種類あります。
1. 話が発散する。
2. 途中で複数の案に対してもめる。

(本当は「誰も結論を出さない」という停滞パターンもありますが、ただの愚痴になるので割愛)
それぞれの原因について考えていきたいと思います。

### **話が発散する会議。それは目的にあった議論？**

自分の経験する発散していく会議って、大体こんな感じなんですよね。

**例: とある製品1の仕様通りに作成したシステムの設計レビュー**

Aさん「システムの設計が完了しました。これらの仕様に対してこのような形で実現しました！」
上司B「あれ、そんなシステム構成になるんだ？製品1って製品2と似たような構成だったよね？」
Aさん「それは製品1には製品2のXXX機能が載っていないからでして…」
上司B「え！XXX機能載ってないの！？何か載せない理由あるんだっけ？」
Aさん「いえ、それは…」
上司C「XXX機能は製品1の形状には適してないので、工数的な面から省いたんですよ。」
上司B「え！なにそれ聞いてない。どういうこと！」
以下XXX機能を載せるか載せないかの**会議と関係ない議論が延々と**。

<img width="600" alt="時間泥棒.png" src="https://qiita-image-store.s3.amazonaws.com/0/252277/388df459-a822-b9f0-2e57-af656034dae0.png">


発散した理由は簡単です。会議に関係ない話を延々としだしたから。

**発散しない方法論**

- **今回の会議の目的と違う話は、改めて別の場で話す。**
- **その話が今回の会議に関わるいうなら、一旦この場は解散する**
	- この場で話が解決したとしても、その議論に必要な人がいないなら再度共有がいります。	
	また、この会議にはその話に関係ない人も沢山いるはずです。**会議はその目的・テーマに適したメンバーで**

その他議論時間を決めて管理するとか、色々な方法論はあると思いますが割愛

### **意見の対立で進まない会議。正直「好みの問題、どっちでもいい」のでは？**

これがSE業界では一番多い気がします。
せっかくレビューの場に持ってきた自分の仕様案。色々なことを考えてきたから自信もあります。
しかしとある作りの部分で上司と対立

Aさん「ここは効率性を考えてこうしました！」
上司 「でもそれだと既存のシステムと大分変ってしまう。保守性に問題があるよ！」
Aさん「こういう理由で保守性についても問題ないと思います！」
上司 「それは君が慣れているからだろ。それに実装の効率性だけじゃなくて評価も合わせて考えて効率的になるの？」
Aさん「それは同等くらいですけど。。。でも次の改造がある時はこっちの方が絶対いいです！」
以下略。**どちらが正しいかの議論が延々と**。

具体的なシステムのことを書いていないですが、似たような経験あるのではないでしょうか？
また、こういうケースで敢えてアンケートを取った場合、Aさん派、上司派、状況によると、色々な答えが出るんじゃないでしょうか？だって**どちらも正論だから**。
互いに相手の主張を否定して自分の主張を通そうとしてどんどん熱くなっていますが、**どっちも正しいなら、最終的に責任を取る人が好きな方を選べばいいのでは？**ってなるケースだと思います。

<img width="600" alt="正論同士.png" src="https://qiita-image-store.s3.amazonaws.com/0/252277/e7505621-1e56-cff7-2f8c-b563b015fe34.png">


昨日友達とこの辺の話をしていて、「もうこれって文化の違いと同じレベルの話だよね」という結論で落ち着きました。

SEの人たちは特にベテランであればあるほど自分の技術に自信があり、自分なりの理論を持っています。
これらの理論はもはや、**「その人の培ったSE文化」**なんだと思います。
それもこれだけIT業界が大きくなって方法論が沢山出てきても、「これが正解だ！」って1つの正解が出ていない時点で、もう**SEそれぞれに文化があり、それは多様性に富んでるんだな**と思うしかないのかなと。

文化を共有し、共感し高めあうことは大事ですし、好みもあるかもしれませんが**文化を否定してもしょうがない**ですよね。

なので、極端な話**目的さえ達成していれば、手段は問わない**、一番後腐れない方法をサクッと選びましょうよ。

# **道徳心**

この話もよく出てきます。結局は人と人が手を組んでチーム、会社が出来るんです。
人同士が過ごしにくいチーム、会社になってしまうととにかくその場にいたくないですよね。

## **多様性を理解する**

会議の時に**SE達は多様性に富んだ文化を持っている**と書きました。
人それぞれ本当に色々なこだわり、考え方があります。自分にも何かしらあります。
そのことを意識せず、自分の理論ばかりぶつけてしまうと相手にはストレスを感じますよね。

なので、相手はどんな考えて仕事をしてるんだろうとか、どういうことが好みなんだろうといった、**「相手の文化を理解する」といった気持ちで相手に向き合う**と、多少はストレスを与えることも減るのかなと。
そうすれば逆に相手が持論を押し通してきた場合でも、**「ああ、この人の文化ではこういう考え方をするんだな」と思えば、案外しょうがないかって気持ちで前向きに仕事出来る**かもしれませんね。

<img width="600" alt="多様性.png" src="https://qiita-image-store.s3.amazonaws.com/0/252277/396f3f69-5a1f-7b26-acbe-93e51e766566.png">


ちょっと関係ないですが、Twitterか何かで「やたら不機嫌な人を見たら、この人はトイレに行きたくて焦ってるんだなと思うと怒りが収まる」みたいな書き込みを見たことがあります。それに似たベクトルの心の余裕かもなとふと思いました。

## **人に対する思いやりをもつ**

よくある話です。
顔を見ずに話すより顔を向けて話した方が気分がいいし、挨拶くらいしないよりした方がいい。
何かしてありがとうと言われるとうれしい。
そういう道徳の授業で習う「**相手が嫌がるようなことをするのはやめましょう**」。
お金を介して関わる社会人関係にこそ必要なことなのではないかと思います。

# **最後に**

さんざん偉そうなことを書いていますが、これはあくまで私の理想論です。こうなれたらいいなという話。
自分自身こんなことが出来ているのかと質問されると至らない点が多いし、うまくいかないことも沢山あります。
でもこういった**ベースを持って仕事をすることが、求められるヒューマンスキルに繋がるんじゃないか**とは思っています。

自分のベースはここに言語化しました。何かある度にこの記事を見返して(必要であればブラシアップして)、その都度自分を振り返りたいと思います。