920
544

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

チャットやメールの文章をないがしろにする人はチーム全体の開発効率に悪影響を与える

Last updated at Posted at 2019-11-25

この記事のターゲット読者

この記事はなんらかのチームに所属しているまだ経験の浅いエンジニアの方や、組織の業務効率に課題を感じていらっしゃる方に向けた内容です。

設計や実装スキル以前に求められるスキル、コミュニケーション能力

エンジニアとして活躍する上で技術的な知識・スキルだけでなくコミュニケーション能力もとても大事です。コミュニケーションをないがしろにすると、いくら技術力があったところでコミュニケーション能力が足枷となってしまい、パフォーマンスを最大化することができません。コミュニケーション能力と一口に言っても様々ありますが、この記事ではチャット(Slack等)やメールなどの文字を利用したコミュニケーションにおいて意識すべき点を私なりに纏めます。

コミュニケーションをないがしろにするとどんな問題が起こるのか?

開発を進める上で工程や立場にかかわらず、基本的に誰しもが誰かしらとコミュニケーションを取る必要があるのは言うまでもない事でしょう。(例外的に、仮に個人開発でかつ受託ではなく自前でサービスを開発されていらっしゃる方であれば、こうした機会はほとんどないのかもしれません。)

この様に仕事を進める上でコミュニケーションというものは必ずと言っていいほど付いて回るもですが**「コミュニケーションの取り方を工夫する事の重要性」を意識できていない方を見かけることも少なくありません。当人は軽視しているつもりはないのででしょうが、周囲からはそう見られてしまうこともあるでしょう。結局、その人を評価するのは自身ではなく周りの人なのです**から。

さて、コミュニケーションを疎かにすると具体的にどの様な問題が起こるのでしょうか?大きく3点にまとめてみました。

1:無駄なやり取り/時間が発生する

例えば作業担当者からリーダー格の人に以下の様なメッセージを送ったとします。(なお、口頭等での補足は無いものとします。)

先日依頼された件やっているんですが、●●機能ってどうすればいいですか?

これを受け取った人は頭の中が「?」だらけになります。具体的には:

  • 「依頼された件」ってどの話?
  • 「やっている」って具体的にどんな作業を?どんなステータスなの?
  • 「どうすればいい」って具体的に何に悩んでいるの?

などの質問が思い浮かぶわけです。そしてこれらの内容が明確になって初めて、質問を受けた側は回答内容をようやく考え始めることができる訳です。

もし、先程挙げた質問のやり取りがすぐに行われるのであれば、大したロスでは無いでしょう。しかしながら、別の打ち合わせ等を理由にすぐにメッセージに反応できない事も往々にしてあります。その様な場合、質問者は暫くのあいだ作業を進める事ができず、チームにとっても個人にとってもマイナスでしかありません。

上記で挙げた様な内容を盛り込んだ文章をあらかじめ送れていれば、もしかすると打ち合わせ中であってもタイミングを見計らって短文や短時間の電話で回答を返したりと、何かしら前進させる為の策を打つことができるかもしれません。

改善した例としてこの様に送っていたとしましょう:

先日依頼された▲▲の件(チケット番号: PRJ-XXX)ですが、●●機能の要求は■■という点において課題があると考えています。仕様を見直すべきか、このまま仕様として取り込んで設計側での対応を考えるべきか相談したいです。

このように書かれていれば議論のポイントが明確になり「目線合わせ」に要する時間を最小限に抑えられます。

この後の話も同様なのですがめんどくさがらずに最初から必要十分な情報を与えた方が結果として効率的であることは往々にしてあります(※)。めんどくさがって短文で済ませようとすると、かえってめんどうなことになります。

※交渉や育成などの観点から戦略的に情報を小出しにする場合を除きます。(交渉術やコーチングの領域の話になるので本記事ではスコープ外とします。)

2:意識齟齬が発生する

良い例が思い浮かばなかったのですが、以下の様な場合のことを指します:

Aさん「Bさん、こないだ話した”あの件”やっといてー」 ←α作業をお願いしている認識
Bさん「(“あの件”って何や・・・あ、βの件か!)了解ですー」 ←β作業を依頼された認識

(数日後)

Aさん「α作業でお願いしたデータ、そろそろできた?貰えるかな?」
Bさん「・・・・・α作業???あーっ!!!」

特に経験の浅い方はこういったミスをした経験が記憶に新しいのではないでしょうか?
無論これは確認をしないBさんにも問題がありますが、初めから内容を明確に伝えていれば意識齟齬が発生するリスクを格段に低減できていた筈です。

また、仕様書などドキュメントを作成する際に用いられがちな表現で意識齟齬につながりかねないものとして**「既存踏襲」**という言葉があります。この言葉が意味をなすのは既存仕様について関係者全員の解釈が一致している場合のみです。既存仕様を全て書く必要はもちろん無いですが、人によって解釈にブレが発生しない程度にはなんらかの補足を書いておくべきです。

3:主導権を握れない/主体性がないと見られる

これは副次的な話になりますが、一つの話題に対して内容を明確に伝えるところに至るまでに何度もやり取りが発生すると「この人、相手のことを意識して伝えようとしていないな」と思われかねません。ひいては**「主体性がない人だな・・・」**と思われてしまうかもしれません。また、調整ごとにおいては主導権を握りづらくなるでしょう。

全体効率を意識したコミュニケーションをとろう

上述の様に、あまり深く考えずにコミュニケーションをとってしまうと相手を手間取らせたりミスリードするリスクがあるだけでなく、めぐりめぐって自身の作業効率にも悪影響を与えかねません。

「何も考えずに10秒でメッセージを送り、意図が伝わらないが故にお互いが他の作業の手を止めて何度かやりとりを交わし、目線合わせができるまでに10分を要する」ほうが良いのか、「3分考えてメッセージを送り、他の作業を進めながら2分後には明確な回答をもらえる」ほうが良いのか、答えは火を見るよりも明らかです。

技術的に優れたものを持っていたとしても、それと同等かそれ以上にコミュニケーション能力は大事なのです。

今現在、職場で特にその様な課題認識がなかったとしても盲目的に「問題がない」と思い込んでいるだけであって、実は改善すべき課題が眠っているかもしれません。

自身にとって「言わなくても分かるだろ」と感じることをめんどくさがらずに伝えること、結構大事です。

920
544
22

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
920
544

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?