2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

エンジニアコミュニケーションのコツ掴んだわ

2
Posted at

はじめに

IT業界に入り2年目となり、最近では基本設計やクライアントとの打ち合わせ、仕様調整などを任せてもらえる機会が増えてきました。

実は私は元警察官で、毎日のように職務質問や事情聴取など、人と話す仕事をしていました。そのため、正直「コミュニケーションにはかなり自信がある」と思っていました。

しかし、エンジニアとして働き始めてからその自信は見事に砕かれます。

「質問したのに意図と違う回答が返ってくる」
「説明したのに伝わっていない」
「最終確認の場で認識がズレている」

こんなことが何度もあり、「なんで伝わらないんだろう…」と結構落ち込みました。

でも、伝わった打ち合わせと伝わらなかった打ち合わせを比べてみると、ある共通点がありました。

今回は、開発2年目の私が実際の業務で気付いた「伝わるコミュニケーション」のコツを書いていこうと思います。


まず質問が伝わってなかった

最初に気付いたのは、「質問しているつもり」だっただけで、質問自体が伝わっていないことが多かったことです。

例えば昔の私はこんな聞き方をしていました。

APIって修正できますか?

これだけ見ると、相手からすれば

  • どのAPI?
  • 何のため?
  • どこを修正したいの?
  • 可否を聞いているの?工数を聞いているの?

と、情報が足りません。

そこで質問する前に、

  • 今どういう状況なのか
  • 何を実現したいのか
  • 何を確認したいのか

この3つを意識するようにしました。

すると、聞き返される回数がかなり減りました。

「質問する」ことより、「相手が答えられる質問になっているか」の方が大事なんだなと実感しました。


箇条書きにしたら全部変わった

次に変えたのが、打ち合わせ前のメモです。

以前は頭の中だけで

「これ聞こう」
「あとこれも」

と思っていました。

当然、打ち合わせ中に忘れます(笑)

なので今は必ず箇条書きでまとめています。

例えば、

  • バッチ実行タイミング
  • エラー時の挙動
  • リトライ回数
  • ログの保存期間

こんな感じです。

さらに終わった項目はチェックを付けるだけ。

これだけで

  • 聞き忘れがない
  • 話が脱線しない
  • 相手も何を確認したいのか分かる

と良いことだらけでした。

「メモ」ではなく「打ち合わせの設計書」を作るイメージですね。


プライベートのノリは仕事じゃ通用しない

これは結構衝撃でした。

友達との会話なら

「この前のあれなんだけどさ」

で伝わります。

でも仕事では「あれ」が存在しません。

相手は自分の頭の中を見られないので、

  • 対象
  • 前提
  • 背景
  • 目的

を共有しないと話が進みません。

仕事は雑談ではなく、情報共有なんですよね。

当たり前のようで、これを意識するだけで会話の質がかなり変わりました。


結論から話すだけでめっちゃ伝わる

これもかなり効果がありました。

昔の私は

「○○で、△△で、その結果…」

という順番で話していました。

でも相手からすると、

「結局何が言いたいの?」

となります。

なので今は

結論

理由

詳細

の順番で話すようにしています。

例えば、

「今回のリリースは予定通り可能です。
理由は○○の修正が完了しており、残タスクも確認済みだからです。」

こんな感じです。

結論が最初にあるだけで、相手も頭の中を整理しながら話を聞けるので、認識合わせがかなりスムーズになりました。


コード見せても伝わらん

これも最初はやりがちでした。

エンジニアなので、

「ここ修正しました!」

と言ってコードを見せたくなります。

でもクライアントが見たいのはコードではありません。

知りたいのは

「何ができるようになったの?」

です。

なので最終確認では、

「このボタンを押すとCSVがダウンロードされます。」
「このエラーは表示されなくなります。」
「この画面から登録できるようになります。」

と、実際の画面や動きを見せるようにしました。

その方が圧倒的に伝わりますし、その場で合意も取りやすくなりました。


「伝える」じゃなくて「伝わる」が大事

今回一番学んだことはこれです。

昔は

「ちゃんと説明したのに。」

と思っていました。

でもそれって、自分視点なんですよね。

相手が理解できていなければ、それはまだ伝わっていません。

コミュニケーションって話す能力ではなく、

相手が理解できる形で情報を届ける能力

なんだと感じました。

この考え方に変えてから、設計レビューやクライアントとの打ち合わせも以前よりずっとやりやすくなりました。


おわりに

エンジニアになる前は、「コミュニケーションなら負けない」と本気で思っていました。

でも実際の開発現場では、話す力よりも「伝わるように整理する力」の方が何倍も重要でした。

もちろん、まだまだ改善できることはたくさんあります。

それでも今回紹介した

  • 質問に背景を付ける
  • 箇条書きで整理する
  • 結論から話す
  • コードではなく価値を伝える

この4つを意識するだけでも、打ち合わせの質はかなり変わりました。

もし最近「なんか話が噛み合わないな」と感じている方がいたら、一度試してみてください。

私と同じように、「コミュ力」ではなく「伝え方」が原因だったことに気付くかもしれません。

2
1
0

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
2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?