技術だけでは足りない。フリーランスエンジニアがプロジェクト進行で大切にしている「お客様とのコミュニケーション」
はじめまして。
普段はWebシステム、業務システム、AI関連の開発などを中心に活動しているエンジニアです。
エンジニアとして約8年、AI開発にも約3年携わってきました。
これまで、要件整理・設計・開発・テスト・リリース・運用改善まで、プロジェクトの一連の工程に関わってきました。
現在はフリーランスとして、さまざまな企業・個人のお客様から開発案件をご相談いただきながら仕事をしています。
その中で、最近特に強く感じていることがあります。
それは、
「良いシステムを作ること」と「良いプロジェクトを進めること」は、同じではない。
ということです。
どれだけ技術力があっても、
- お客様の要望を正しく理解できない
- 現在の進捗が伝わらない
- 問題が発生したときに報告が遅れる
- 「できます」だけで終わってしまう
- 追加要望と当初の仕様の区別が曖昧になる
こうしたことが続くと、プロジェクトは簡単に不安定になります。
今回は、私自身がプロジェクトを進める中で意識している、**「お客様とのメッセージコミュニケーション」**について整理してみます。
1. エンジニアにとって「技術力」だけが仕事ではない
エンジニアというと、
- プログラミング
- アーキテクチャ設計
- データベース設計
- API開発
- インフラ構築
- テスト
などが重要だと思われがちです。
もちろん、これらは非常に重要です。
しかし、受託開発やフリーランスとしてお客様と一緒にプロジェクトを進める場合、もう一つ重要な能力があります。
それが、
「相手に安心してもらいながら開発を進める能力」
です。
お客様は必ずしも技術者ではありません。
そのため、
「Next.jsで実装しました」
「SupabaseのRLSを設定しました」
「APIのレスポンスを最適化しました」
と説明しても、それだけではプロジェクトの状況を理解できない場合があります。
お客様が知りたいのは、
「今どこまで進んでいるのか？」
「予定通り完成するのか？」
「問題はないのか？」
「自分が確認すべきことは何なのか？」
ということです。
だから私は、技術的な説明だけではなく、
「お客様が今知るべき情報は何か？」
を考えてメッセージを送るようにしています。
2. メッセージは「報告」ではなく「安心」を届ける
例えば、開発が予定通り進んでいるとします。
単純に、
「開発順調です。引き続き進めます。」
だけでも間違いではありません。
しかし、私はもう少し具体的に伝えることを意識しています。
例えば、
お世話になっております。
現在、○○機能の実装まで完了しております。
本日は主に、
・○○機能の実装
・データ登録処理
・エラーハンドリング
・スマートフォン表示の調整を進めました。
現時点では大きな問題は発生しておりません。
明日は○○機能のテストと、全体の表示確認を進める予定です。
引き続き、品質を確認しながら進めてまいります。
よろしくお願いいたします。
このようにすると、
「何をしたのか」
「問題があるのか」
「次に何をするのか」
が一度に伝わります。
お客様にとっては、これだけでもかなり安心感が違います。
3. 「できます」だけで終わらせない
お客様から追加要望をいただくこともよくあります。
例えば、
「この機能も追加できますか？」
と聞かれた場合。
ここで、
「はい、可能です。」
だけで返すのは、少し危険です。
なぜなら、
- どの程度の作業になるのか
- 現在の仕様にどのような影響があるのか
- 納期に影響するのか
- 追加費用が発生するのか
が分からないからです。
そのため、私はできるだけ、
「可能かどうか」＋「影響」＋「次の確認事項」
まで伝えるようにしています。
例えば、
ご要望の機能について、技術的には対応可能です。
ただし、現在の○○機能と連携する必要があるため、既存部分にも一部調整が必要になります。
実装内容を確認したうえで、納期・作業範囲・追加費用への影響を整理してご案内いたします。
まずは現在の仕様を崩さない形で実現方法を検討いたします。
このように伝えれば、お客様も判断しやすくなります。
4. 追加要望が出たときほど「一度整理する」
開発中に、
「やっぱりこの部分も変更したい」
という話が出ることがあります。
これは珍しいことではありません。
むしろ、実際にシステムを触って初めて気づくことも多いので、自然なことだと思っています。
重要なのは、
「追加要望＝悪いこと」と考えないこと
です。
ただし、追加要望をそのまま受け続けると、いつの間にか当初の仕様から大きく変わってしまいます。
そのため、
- 当初の仕様
- 今回追加された要望
- 既存機能への影響
- 工数
- 納期への影響
- 追加費用の有無
を整理します。
そして、お客様に確認していただきます。
例えば、
ご要望の内容を確認しました。
現在の仕様に追加する場合、以下の対応が必要になります。
・○○画面の変更
・○○APIの調整
・データ構造の追加
・スマートフォン表示の調整そのため、当初予定していた開発範囲から追加対応となる見込みです。
仕様を確定したうえで、追加工数と納期への影響を整理してご提示いたします。
ご確認いただいた後、正式に対応を進めさせていただければと思います。
このように、「できます」ではなく「どのように進めるか」まで示すことが大切です。
5. 問題が発生したときは「早く伝える」
個人的に最も重要だと思っているのがこれです。
問題を隠さないこと。
開発では、問題が発生することがあります。
例えば、
- APIに問題がある
- 外部サービスの仕様が想定と違う
- スマートフォンだけ表示が崩れる
- データ移行で想定外のケースが見つかる
- テスト中にバグが見つかる
などです。
このとき、
「まだ自分で解決できていないから、解決してから報告しよう」
と考えてしまうことがあります。
しかし、私はできるだけ早く共有するようにしています。
もちろん、単なる小さな実装上の問題まで逐一報告する必要はありません。
重要なのは、
「納期・品質・仕様に影響する可能性がある問題」
です。
例えば、
お世話になっております。
現在、○○機能のテスト中に一部想定外の動作を確認しております。
現時点では○○の条件でのみ発生しており、通常の操作では発生しておりません。
現在原因を調査しております。
現時点で納期への影響はない見込みですが、影響範囲を確認したうえで、必要があれば改めてご報告いたします。
ご心配をおかけしないよう、進展があり次第すぐに共有いたします。
このような報告を受ければ、お客様も状況を把握できます。
6. 「問題ありません」より「何を確認したか」を伝える
「問題ありません」という言葉は便利ですが、少し曖昧です。
例えば、
「動作確認しました。問題ありません。」
よりも、
「会員登録 → ログイン → 予約登録 → 決済 → キャンセルまで一連の操作を確認し、現時点で問題は確認されておりません。」
の方が信頼性があります。
つまり、
結論だけではなく、確認した範囲を伝える
ということです。
これは特に、
- 納品前
- リリース前
- 本番環境への反映前
- 大きな仕様変更後
に重要だと感じています。
7. お客様への質問は「まとめて」送る
開発中には確認事項がたくさん出てきます。
例えば、
- ボタン名はどうするか
- エラーメッセージはどうするか
- 管理者だけ見られるようにするか
- スマートフォンではどう表示するか
などです。
これを一つずつ、
「こちらはどうしますか？」
「これはどうしますか？」
「こちらは？」
と送ってしまうと、お客様も大変です。
そのため、私は可能な限り質問をまとめます。
例えば、
現在、以下3点について確認させていただきたいです。
① ○○について
A案：○○
B案：○○② ○○について
現在は○○という仕様を想定しておりますが、問題ございませんでしょうか。③ ○○について
○○の場合はエラー表示とする想定です。お手数ですが、①〜③についてご確認いただけますと幸いです。
この形なら、お客様も回答しやすくなります。
8. 「専門用語を減らす」ことも技術力
エンジニア同士なら、
「RLSを設定してSupabase側で認可します。」
でも通じます。
しかし、お客様によっては分かりません。
その場合、
「ユーザーごとに閲覧できるデータを制限し、他のユーザーの情報を閲覧できないように設定します。」
と説明した方が伝わります。
つまり、
専門用語を使わないことではなく、相手に合わせて翻訳すること
が重要です。
技術的な説明が必要な場合は、
技術的には○○という仕組みを利用していますが、簡単にいうと「○○できるようにする仕組み」です。
という説明も有効です。
9. 進捗報告には「現在・完了・次」を入れる
私がよく意識しているのが、
「現在」
「完了」
「次」
の3つです。
例えば、
現在
○○機能の実装・テストを進めています。
完了
- 会員登録
- ログイン
- パスワードリセット
- 管理画面の基本機能
まで完了しています。
次
次は予約機能と決済処理を進める予定です。
これだけでも、お客様はプロジェクトの位置を把握できます。
10. 「お客様に何をしてほしいのか」を明確にする
メッセージで意外と重要なのが、
相手に何をしてほしいのかを明確にすること
です。
例えば、
ご確認よろしくお願いいたします。
だけでは、何を確認すればいいのか分からない場合があります。
そこで、
以下2点をご確認いただけますでしょうか。
① トップページのキャッチコピー
② 料金表示の内容特に問題がなければ「問題ありません」と一言ご返信いただければ、そのまま実装を進めます。
とします。
これだけでコミュニケーションがかなりスムーズになります。
11. 私が考える「良いメッセージ」の基本構成
私自身は、プロジェクト中のメッセージを次のように考えています。
① 挨拶
↓
② 結論
↓
③ 現在の状況
↓
④ 詳細
↓
⑤ 問題・リスク
↓
⑥ 次の対応
↓
⑦ お客様への確認事項
例えば、
お世話になっております。
現在、予約機能の実装は予定通り進んでおります。
本日は、
・予約登録
・予約変更
・予約キャンセル
・管理画面での予約確認まで実装しました。
現時点で大きな問題は確認されておりません。
明日はスマートフォン表示を含めたテストを進める予定です。
なお、予約キャンセル時の返金処理について、仕様を1点確認させていただきたいです。
「キャンセル時は全額返金」という認識で問題ございませんでしょうか。
ご確認いただけますと幸いです。
引き続きよろしくお願いいたします。
このような形です。
12. 「速い返信」と「丁寧な返信」は両立できる
フリーランスとして仕事をしていると、
「すぐ返信しないといけない」
というプレッシャーがあります。
しかし、毎回完璧な回答を作ろうとすると、返信が遅くなります。
そこで私は、
「まず受け取ったことを伝える」
ことも大切にしています。
例えば、
ご連絡ありがとうございます。
内容を確認いたします。
現在の仕様への影響も含めて確認したうえで、本日中に改めてご回答いたします。
よろしくお願いいたします。
これだけでも十分です。
重要なのは、
「返信がない状態」を作らないこと。
すぐに回答できない場合でも、
「確認しています」
と伝えるだけで、お客様の不安を減らせます。
13. 実際のプロジェクトで特に大切だと感じたこと
実際にプロジェクトを進めていると、最初に決めた仕様が最後まで一切変わらないケースは、必ずしも多くありません。
実際に画面を触ってみると、
「ここはもう少し簡単にしたい」
「スマートフォンではこうしたい」
「この情報も管理画面から見たい」
という新しい要望が出てきます。
これは悪いことではありません。
むしろ、プロジェクトが具体化してきた証拠でもあります。
だからこそ、
「変更を受け入れる柔軟性」と「プロジェクトを管理する線引き」
の両方が必要だと思っています。
お客様の希望をそのまま全部受け入れることが「良い対応」なのではありません。
お客様の目的を理解して、
「この方法なら実現できます」
「こちらの方法の方が使いやすいと思います」
「この変更を入れる場合は、ここに影響します」
と、一緒に考えることが重要です。
14. 私が目指しているエンジニア像
私が目指しているのは、
「コードを書くだけのエンジニア」ではありません。
お客様が、
「この人に相談すれば、開発のことを一緒に考えてくれる」
と思っていただけるエンジニアです。
そのためには、
- 技術力
- 設計力
- 問題解決力
- コミュニケーション力
- スケジュール管理
- リスク管理
- お客様の立場で考える力
が必要だと思っています。
特に受託開発では、
「何を作るか」だけではなく、「どう一緒に作るか」
が非常に重要です。
まとめ
今回の記事で伝えたかったことをまとめると、以下のようになります。
お客様とのコミュニケーションで意識していること
- 「できます」だけで終わらせない
- 進捗は「現在・完了・次」で伝える
- 問題は隠さず、早めに共有する
- 専門用語は相手に合わせて翻訳する
- 追加要望は仕様・工数・納期への影響を整理する
- 質問はできるだけまとめる
- お客様に何をしてほしいのか明確にする
- すぐ回答できない場合も、まず受領を伝える
- 結論だけではなく「何を確認したか」を伝える
- 「システム」だけではなく「安心」も提供する
エンジニアの仕事は、コードを書いて終わりではありません。
お客様の課題を理解して、
「何を作るべきか」
を一緒に考え、
「どう作るか」
を設計し、
「今どうなっているか」
を伝え、
「問題があればどう解決するか」
を一緒に考える。
そこまで含めて、私はエンジニアの仕事だと考えています。
これからも、実際のプロジェクトで経験したことや、開発・設計・AI開発・顧客とのコミュニケーションについて、技術者の方にも参考になる形で発信していきたいと思います。
最後まで読んでいただき、ありがとうございました。