はじめに
クライアントとの打ち合わせ、ビジネスサイドとのやり取り、チーム内の連携。
エンジニアとして働いていると、コードを書く以外の場面で「なんかうまくいかないな、、」と感じることがあるんじゃないでしょうか。
何を聞かれるか分からない。うまく説明できるか不安。認識がずれて手戻りが発生する。etc...
実は、自分のペースで仕事ができる上に「この人に任せると楽だ」「この人優秀だなぁ」と、評価される方法があります。
自分は現在、日々コードを書くエンジニアというよりも、エンジニアとクライアントの間に立つことが多い立場です。
クライアントからの要望や業務上の課題を聞き、それを社内のエンジニアへ共有する。
反対に、エンジニアから出てきた技術的な意見や懸念を一つ一つ教えてもらいながら整理して、クライアントが判断できる形で伝える。
いわゆる非エンジニアです。
その中で、「この人なら、クライアントとの対話を安心して任せられる」「複雑な要件を任せられる」と感じる人と、そうでない人には、はっきりとした違いがあると感じています。
その違いは、技術力が高いことでも、話がうまいことでも、営業が得意なことでもありません。
それは、誰と、なぜ、何を、どこまで、どのように 作るのかということを理解し、相手との共通認識をつくれるかどうかです。
これは、PMや上流工程を担当する人だけに必要な能力ではありません。
今後クライアントとの打ち合わせに参加したい、要件定義に関わりたい、チームの中でより大きな役割を担いたいのであれば、避けて通れないスキルだと思います。
この記事では、世の中でいわゆる「優秀だ」と評価される人に共通する、コミュニケーションの考え方を整理します。
1. コミュニケーション力は 「話がうまいこと」 ではない
エンジニアに必要なコミュニケーション力というと、
- 専門用語を使わず説明する
- 相手の話をきちんと聞く
- こまめに進捗を報告する
といった話になりがちです。もちろん、これらも重要です。
ただ、より本質的なのはこうだと思っています。
関係者の頭の中にある曖昧なイメージを、共通認識に変えること
コミュニケーションとは、ただ会話を続けることではない。
曖昧さを減らし、意思決定できる状態をつくること。
例えば、クライアントから次のように言われたとします。
AIを使って、問い合わせ対応を効率化したいです。
この言葉だけでは、何をつくればよいのかまだ分かりません。
- 誰からの問い合わせなのか
- 現在は誰が回答しているのか
- 月に何件あるのか
- 何に時間がかかっているのか
- AIが直接回答するのか、回答案を人間が確認するのか
- 間違った回答をした場合、どんな問題が起きるのか
- どのデータを参照するのか
こうした情報を一つずつ確認して、初めてシステムの形が見えてきます。
2. クライアントとは「機能」ではなく「目的」を確認する
クライアントとの会話で起こりやすいのが、依頼された機能をそのままつくってしまうことです。
CSVをアップロードして、一覧表示できる機能が欲しいです。
と言われたとします。
そのまま受け取ると、CSVアップロード機能の設計を始めることになります。
しかし、本来確認したいのは、なぜCSVをアップロードしたいのかです。
話を聞いてみると、「他のシステムから毎月データを出力している」「担当者がCSVを加工している」「加工したデータを社内システムに登録したい」という背景があるかもしれません。
それなら、CSVアップロード機能ではなく、外部システムとのAPI連携や自動同期の方が適切な可能性もあります。
クライアントが伝えているのは、多くの場合「解決策の案」。
その奥にある「解決したい問題」を確認する必要がある。
クライアントへのヒアリング項目の例
- この機能を使うのは誰か
- 現在はどのように作業しているか
- 何が一番大変なのか
- どの程度の頻度で発生するか
- 解決すると何が改善されるか
- 必ず必要なものは何か
- なくても業務が成立するものは何か
- 失敗した場合に何が起きるか
「何をつくりますか」だけではなく、なぜ必要なのか、誰が困っているのかまで聞くことが重要です。
3. ビジネスサイドとは「できる・できない」ではなく、選択肢を話す
ビジネスサイドから相談を受けたとき、つい技術的な可否で回答してしまいます。
「その仕様は難しいです。」「技術的には可能です。」「それはセキュリティ上できません。」
ビジネス側が知りたいのは、技術的に可能かどうかだけではありません。いつまでにできるか・いくらかかるか・どんなリスクがあるか・他の方法はないかです。
例えば、
完全自動化も可能ですが、開発に2か月程度かかる。
最初はAIが回答案を作り、人が確認する形なら、2週間程度で検証できる。
まず半自動で精度を確認し、その後自動化の範囲を広げる方が安全だと思う。
このように伝えれば、ビジネス側はコスト・期間・リスクを踏まえて判断できます。
技術的な正解をただ述べるのではなく、技術的な情報を、事業上の意思決定に使える形へ変換することが重要です。
4. デザイナーとは「画面」ではなく「意図」を共有する
デザイナーから受け取る画面は、単なる見た目の指定ではありません。
- ユーザーに何を最初に見てほしいのか
- どの操作を迷わず進めてほしいのか
- 何を重要な情報として扱っているのか
といった意図があります。
その意図を理解しないまま実装すると、見た目はデザインどおりでも、仕様変更やスマートフォン対応の際に、何を優先すべきか判断できません。
反対に、意図を理解できていれば、
この画面では、ユーザーが迷わず申請を完了できることが最優先、という認識で合っていますか？
スマートフォンでは補足情報を折りたたみ、申請ボタンを常に表示する形ではどうでしょうか？
といった提案ができます。
実装上の制約がある場合も、「できません」で終わらせるのではなく、デザインの目的を維持できる代替案を伝えることが重要です。
また、データがない状態や読み込み中、エラー、権限不足など、デザインに描かれていない状態についても、
そのときユーザーに何を伝え、次に何をしてもらうのか
まで一緒に考えます。
デザインをそのまま実装するのではなく、意図を理解し、制約や利用時の状態を共有しながら、デザイナーと一緒にユーザー体験をつくることが大切です。
5. 専門用語を使わないより、判断に必要な情報を伝える
非エンジニアには専門用語を使ってはいけない、と言われることがあります。
ただ、専門用語を完全に避ける必要はないと思っています。
大切なのは、相手が意思決定できるように伝えることです。
| ❌ 技術用語だけで終わる | ✅ 意思決定できる形に変換する |
|---|---|
| 「APIのレスポンスが遅いので、キャッシュを入れます」 | 「APIのレスポンスに約5秒かかっているため、キャッシュを導入します。2回目以降の表示を1秒以内にすることを目標にします。ただし、情報の更新が最大5分遅れるため、その条件で問題ないか確認したいです」 |
専門用語を禁止するのではなく、専門用語だけで説明を終わらせないという考え方の方が実践的です。
6. 良いエンジニアは、答えを持っている人ではなく、問いをつくれる人
上流工程に進みたいと思ったとき、要件定義書の書き方やプロジェクト管理の方法を学ぶ人は多いと思います。
もちろんそれらも必要ですが、その前に重要なのが、適切な問いを立てる力です。
- なぜ、この機能が必要なのか
- 誰が使うのか
- どの業務が変わるのか
- 本当にシステム化する必要があるのか
- 今回はどこまでつくるのか
- 何をもって成功とするのか
- どのリスクを許容するのか
- 誰が最終的に判断するのか
良い質問ができると、プロジェクトの曖昧さが減ります。
逆に、質問せずに実装へ入ると、後から大きな手戻りが発生します。
上流工程とは、会議に出たり、資料をつくったりすることではありません。
良いものをつくるために、必要な問いと意思決定を設計することだと思います。
7. 「めんどくさいやり取り」 が、主導権につながる
ここまで書いてきたことは、正直、面倒な作業です。
背景を確認して、目的を掘り下げて、選択肢を整理して、言葉を具体化する。
でも、この作業をしているだけで、自然と主導権を握れるようになります。
「できますか？」と聞かれたとき、イエス・ノーだけで返す人は、相手のペースで仕事が進みます。
背景を理解している人は、逆に選択肢を示して提案する事ができ、相手は選ぶだけでよくなる。
ここでいう主導権とは、相手をコントロールすることではありません。
相手の要望を理解したうえで、「何を決めるべきか」「どんな選択肢があるか」「次に何をするか」を整理し、仕事を前に進めることです。
この状態をつくれると、相手には「話が早い」「毎回一から説明しなくてよい」「会話の往復が少なくて仕事がしやすい」と感じてもらえます。
結果として、自分のペースで仕事ができる上に、「この人に任せると楽だ」という評価にもつながります。
仕事におけるコミュニケーション力は、相手に気を遣う力ではなく、相手と自分の双方が動きやすい状態を設計する力。
まとめ
非エンジニアとのコミュニケーションで重要なのは、話し上手になることではありません。
| シーン | 意識するポイント |
|---|---|
| クライアント | ソリューションの裏にある課題を掘る |
| ビジネスサイド | できる形に変換して、選択肢を提示する |
| デザイナー | 状態の抜け漏れを早めに確認し、代替案を一緒に考える |
| チーム全体 | Why・Who・Whenの3つのイメージを揃える |
- 相手の要望の背景を確認する
- 機能ではなく目的を聞く
- 技術的な話を意思決定できる形に変換する
- 曖昧な言葉を具体化する
- 複数の選択肢とトレードオフを提示する
- 小さくつくって、早い段階で認識を合わせる
- 正しい答えより、正しい問いを考える
- 共通認識をドキュメントに残す
こうした積み重ねが、手戻りを減らし、主導権を持ちながら仕事を進めることにつながります。
エンジニアの仕事は、与えられた仕様をコードに変換することだけではありません。
クライアントやビジネスサイド、デザイナー、現場の利用者と一緒に、何を、なぜ、どのようにつくるのかを決めていくことも、重要な仕事の一つです。
AI時代だからこそ、コードを書く力だけでなく、人と一緒につくる力が、これまで以上に重要になるのではないでしょうか。
出来ることから、ぼちぼちやっていこう。