非エンジニアCEOがエンジニアとギスギスにならないためのコミュニケーション作法
「なんでこんな簡単なことに時間がかかるの？」—その一言が関係を壊す
「え、この修正に2週間もかかるんですか？」
「前に言った機能、まだできてないんですか？」
「なんでそんなに難しいんですか？他のアプリでは普通にできてますよね？」
こんな言葉、エンジニアに言ったことはありませんか？
もし心当たりがあるなら、あなたとエンジニアの関係は、すでに危険信号が点灯しているかもしれません。
非エンジニアCEOとエンジニアの関係がギスギスするのは、珍しいことではありません。
むしろ、多くのスタートアップで繰り返される「あるある」パターンです。
- エンジニアが何をしているのかわからない
- 進捗を聞いても、専門用語で煙に巻かれる気がする
- 「技術的に難しい」と言われると、反論できない
- 本当に必要な工数なのか、判断できない
- 優秀なエンジニアほど、不満を抱えて辞めていく
この状況、放置していませんか？
エンジニアとの関係悪化は、プロダクトの品質低下、開発の遅延、そして最悪の場合、チームの崩壊を招きます。
でも、安心してください。
この問題は、あなたのコミュニケーション方法を変えるだけで、劇的に改善できます。
技術を学ぶ必要はありません。コードを読む必要もありません。
必要なのは、エンジニアの思考回路を理解し、適切な言葉で会話する力です。
あなただけではない。多くのCEOが同じ壁にぶつかっている
「エンジニアとのコミュニケーションが難しい…」
この悩みを抱えているのは、あなただけではありません。
実際、スタートアップの失敗原因の上位に「チームの人間関係の問題」が挙がることは珍しくありません。
そして、その多くがCEOとエンジニアの間のコミュニケーション不全に起因しています。
なぜ、これほどまでにコミュニケーションが難しいのでしょうか？
理由1：バックグラウンドの違い
非エンジニアCEOの多くは、営業、マーケティング、ファイナンス、コンサルティングなどの経験を持っています。
これらの仕事では、曖昧さの中で判断し、人を動かし、交渉することが求められます。
一方、エンジニアの仕事は、論理的に正しいコードを書き、システムを動かすことです。
曖昧さは敵であり、「なんとなく」で動くことはありません。
この思考様式の違いが、コミュニケーションのすれ違いを生みます。
理由2：言語の違い
エンジニアは、技術用語で思考し、技術用語で会話します。
「APIのレスポンスタイムが遅いから、キャッシュを入れてレイテンシを改善しよう」
これは、エンジニア同士では自然な会話です。
でも、非エンジニアにとっては外国語に聞こえるでしょう。
問題は、多くのエンジニアが「翻訳」を面倒に感じることです。
結果、説明が省略され、CEOは「よくわからないけど、任せるしかない」となります。
理由3：評価軸の違い
CEOは、ビジネス成果で物事を評価します。
- 売上は上がったか？
- ユーザーは増えたか？
- 投資家は満足しているか？
一方、エンジニアは技術的な品質も重視します。
- コードは保守しやすいか？
- システムは安定しているか？
- 技術的負債は増えていないか？
「売上が上がれば、コードの品質なんてどうでもいい」という姿勢は、エンジニアにとって受け入れがたいものです。
これらの違いを理解せずにコミュニケーションを取ると、互いに「わかってもらえない」というフラストレーションが蓄積していきます。
この記事でわかること：信頼関係を築く7つのコミュニケーション作法
信頼関係を築くコミュニケーション
この記事を読むと、以下のことがわかります：
- エンジニアが「わかってもらえた」と感じる伝え方
- 信頼を損なう「地雷ワード」とその回避法
- 技術がわからなくても適切に質問する方法
- エンジニアのモチベーションを上げる声かけ
- 対立を建設的な議論に変えるフレームワーク
これらは、私がこれまで多くの非エンジニア創業者を支援してきた中で、実際に効果があった方法だけを厳選しています。
明日から使える、具体的なノウハウです。
コミュニケーション作法1：「Why（なぜ）」から伝える
「これ作って」ではなく「これを実現したい」
多くのCEOがやりがちなのが、「What（何を作るか）」だけを伝えるコミュニケーションです。
「ログイン機能を追加してください」
「このボタンを大きくしてください」
「決済機能を入れてください」
これでは、エンジニアはただの作業者になってしまいます。
優秀なエンジニアほど、**「なぜそれが必要なのか」**を知りたがります。
なぜなら、目的がわかれば、より良い解決策を提案できるからです。
悪い例と良い例
悪い例：
「SNSログイン機能を追加してください。TwitterとFacebookとGoogleで。来週までに。」
良い例：
「今、新規登録の離脱率が40%もあるんです。ユーザーインタビューをしたら、『メールアドレスとパスワードを設定するのが面倒』という声が多くて。登録のハードルを下げたいんですが、SNSログインを入れるのと、他に良い方法があれば教えてもらえますか？」
後者の方が、エンジニアは目的を理解し、主体的に考えられます。
もしかしたら、「SNSログインより、マジックリンク（メールで送られるリンクをクリックするだけでログインできる方式）の方が実装も早いし、ユーザー体験も良いですよ」という提案が出てくるかもしれません。
伝えるべき3つのWhy
機能を依頼するときは、以下の3つの「Why」を伝えましょう：
- ビジネス上のWhy：なぜこの機能が必要なのか（売上向上？ユーザー獲得？解約率低下？）
- ユーザー上のWhy：ユーザーのどんな課題を解決するのか
- 優先度のWhy：なぜ今やるべきなのか（他のタスクより先に）
これを伝えるだけで、エンジニアの当事者意識は劇的に変わります。
コミュニケーション作法2：見積もりを「尋問」しない
工数を聞くときの姿勢が、信頼関係を左右する
「この機能、どれくらいで作れますか？」
この質問自体は問題ありません。
問題は、見積もりを聞いた後の反応です。
「え、2週間？そんなにかかるの？」
「他のサービスではすぐできてるじゃないですか」
「本当にそんなに必要なんですか？」
これは、エンジニアの専門性を疑っていることになります。
なぜエンジニアは「見積もり」を嫌がるのか
多くのエンジニアは、見積もりを聞かれることにストレスを感じています。
なぜなら、ソフトウェア開発の見積もりは、本質的に不確実だからです。
- 作り始めてみないとわからない技術的課題がある
- 要件が曖昧だと、想定外の作業が発生する
- 他のタスクとの兼ね合いで、予定通りいかないことがある
それなのに、「約束した期日を守れ」とプレッシャーをかけられると、エンジニアは防衛的になります。
余裕を持った見積もりを出すようになり、結果的に開発スピードが落ちるという悪循環に陥ります。
見積もりを聞くときの良いアプローチ
悪い聞き方：
「この機能、何日で作れますか？」（期日を約束させようとしている）
良い聞き方：
「この機能の難易度はどれくらいですか？もし実装するとしたら、どんな作業が必要になりそうですか？」（理解しようとしている）
さらに、こう続けると良いでしょう：
「もしボトルネックがあるとしたら、どこですか？私の方で解消できることはありますか？」
これは、「一緒にやろう」という姿勢を示しています。
エンジニアは、味方だと感じた相手には、正直に状況を話してくれます。
コミュニケーション作法3：「地雷ワード」を避ける
エンジニアが心を閉ざすNGワード集
以下の言葉は、エンジニアとの関係を悪化させる**「地雷ワード」**です。
無意識に使っていないか、チェックしてみてください。
地雷ワード1：「簡単でしょ？」
これは最悪です。
簡単かどうかを判断できるのは、実装する本人だけです。
CEOが「簡単」と言った瞬間、エンジニアは「この人は技術をわかっていない」と感じます。
言い換え：「難易度はどれくらいですか？」
地雷ワード2：「前にもやったでしょ？」
似たような機能を作った経験があっても、コンテキストが違えば難易度も変わります。
「前と同じ」と思っている機能が、実は全然違う実装が必要なケースは多いです。
言い換え：「前に似たようなことをやったと思うんですが、今回はどう違いますか？」
地雷ワード3：「他の会社では普通にできてるよ」
これは、エンジニアの能力を否定しているように聞こえます。
他社でできていることが、自社でできない理由は様々です（リソース、優先度、技術スタック、etc.）。
言い換え：「競合のこの機能、うちでも実現できますか？難しい場合、代替案はありますか？」
地雷ワード4：「とりあえず動けばいい」
これは、品質を軽視していることを示します。
「動くコード」と「良いコード」は違います。
「とりあえず動けばいい」で作ったコードは、後で必ず技術的負債として返ってきます。
言い換え：「最初のリリースでは、どこまでの品質を目指しますか？後から改善すべき点はどこですか？」
地雷ワード5：「そんなことも知らないの？」
これは論外です。
技術の世界は広く、全てを知っているエンジニアは存在しません。
知らないことを学ぶ姿勢を否定したら、チームの成長は止まります。
コミュニケーション作法4：「翻訳」を依頼する
翻訳を依頼するコミュニケーション
「わからないこと」を正直に伝える
技術的な話がわからないとき、多くのCEOは2つの間違った対応をしてしまいます。
間違い1：わかったふりをする
「なるほど、そういうことね」（実際はわかっていない）
これは最悪です。
わかっていないのに「わかった」と言うと、後で認識のズレが発覚し、「言ったはずだ」「聞いてない」の水掛け論になります。
間違い2：質問を諦める
「（どうせ聞いてもわからないから、任せよう…）」
これも問題です。
CEOが理解していない状態で進むプロジェクトは、意思決定が遅れ、方向修正が効かなくなります。
正解：「翻訳」を依頼する
わからないときは、正直に「翻訳」を依頼しましょう。
「すみません、今の説明、もう少しビジネス言語に翻訳してもらえますか？」
「技術的な詳細はわからないので、『何ができて、何ができないか』と『どれくらいの時間とコストがかかるか』を教えてもらえますか？」
「私のような非エンジニアに説明するとしたら、どう言いますか？」
これは恥ずかしいことではありません。
むしろ、「自分はわかっていない」と認められるCEOの方が、エンジニアから信頼されます。
なぜなら、知ったかぶりをするCEOより、誠実だからです。
エンジニア側の責任も明確にする
ただし、「翻訳」は一方的に求めるものではありません。
翻訳してもらえたら、感謝を伝えましょう。
「わかりやすく説明してくれてありがとう。おかげで判断できました。」
これにより、**「わかりやすく説明することに価値がある」**という文化がチームに根付きます。
コミュニケーション作法5：感謝と承認を「具体的に」伝える
「お疲れさま」だけでは伝わらない
エンジニアの仕事は、目に見えにくいことが多いです。
- バグを未然に防いだ
- システムの安定性を向上させた
- 将来の拡張に備えた設計をした
これらは、問題が起きなかったからこそ価値がある仕事です。
でも、問題が起きていないと、CEOは気づきません。
結果、エンジニアは「自分の仕事は評価されていない」と感じます。
具体的に承認する方法
悪い例：
「いつもありがとうございます」（抽象的すぎる）
良い例：
「この前のリリース、本番環境でエラーがゼロだったって聞きました。テストをしっかりやってくれたおかげですよね。ありがとうございます。」
「今回の設計、将来の機能拡張を見据えて作ってくれたんですね。長期的に見ると、この判断は大きいと思います。」
ポイントは、「何を」「なぜ」評価しているかを明確にすることです。
技術的な貢献を理解しようとする姿勢
「正直、技術的な詳細はわからないんですが、今回の対応がすごく難しいことだったって〇〇さんから聞きました。本当に助かりました。」
こう伝えれば、技術がわからなくても、敬意は伝わります。
「自分の仕事を見てくれている」と感じたエンジニアは、モチベーションが上がります。
コミュニケーション作法6：対立を「議論」に変える
意見の対立は「悪いこと」ではない
CEOとエンジニアの意見が対立することは、むしろ健全なことです。
それぞれが異なる視点を持っているからこそ、対立が生まれます。
問題は、対立を「個人攻撃」にしてしまうことです。
悪い対立：
「あなたはビジネスをわかっていない」
「あなたは技術をわかっていない」
良い対立（議論）：
「ビジネスの観点からは〇〇が重要なんですが、技術の観点からはどうですか？」
「技術的な懸念は理解しました。ビジネス上の制約も共有させてください。」
議論を建設的にするフレームワーク
対立が起きたときは、以下のフレームワークを使ってみてください。
ステップ1：お互いの「制約条件」を共有する
「私が譲れないのは〇〇です。あなたが譲れないのは何ですか？」
ステップ2：「共通のゴール」を確認する
「私たちが目指しているのは、△△ですよね？」
ステップ3：「第3の選択肢」を一緒に探す
「お互いの制約を満たしながら、ゴールを達成する方法を一緒に考えませんか？」
このフレームワークを使うと、「私 vs あなた」が「私たち vs 課題」に変わります。
コミュニケーション作法7：定期的な「雑談」の時間を作る
仕事の話だけでは信頼関係は築けない
多くのCEOが見落としているのが、「雑談」の重要性です。
エンジニアと話すのは、進捗確認や機能の依頼の時だけ。
これでは、「仕事を振る人」と「仕事をする人」の関係で終わってしまいます。
週に15分でいい
週に1回、15分でいいので、仕事以外の話をする時間を作りましょう。
- 最近ハマっている技術
- 趣味のこと
- 業界のニュース
- 将来のキャリアについて
目的は、「人として興味を持っている」ことを示すことです。
エンジニアは、自分に興味を持ってくれる人には心を開きます。
1on1ミーティングの活用
定期的な1on1ミーティングを設定するのも効果的です。
ポイントは、1on1をマイクロマネジメントの場にしないことです。
「今週の進捗は？」「あれはできた？」という詰め問いではなく、
「困っていることはない？」「何か手伝えることはある？」というサポートの姿勢で臨みましょう。
こんな方におすすめです
以下に当てはまる方は、今日から紹介したコミュニケーション作法を実践してみてください：
- エンジニアとの会話に苦手意識がある非エンジニアCEO
- 優秀なエンジニアがなぜか辞めていく会社の経営者
- 「技術的に難しい」と言われると反論できない方
- エンジニアから「わかってない」と思われている気がする方
- 開発チームとの関係を改善したいと思っている方
- これからエンジニアを採用・外注しようとしている方
今すぐ実践すべき理由：
エンジニアとの信頼関係は、一度壊れると修復が難しいものです。
そして、関係が壊れた状態で作られたプロダクトは、品質も、スピードも、犠牲になります。
「関係が悪化してから対処する」のではなく、今日から予防的に良い関係を築いていきましょう。
まとめ：技術がわからなくても、信頼関係は築ける
まとめ
この記事でお伝えした7つのコミュニケーション作法をおさらいします。
7つのコミュニケーション作法
- 「Why（なぜ）」から伝える：目的を共有し、エンジニアの当事者意識を高める
- 見積もりを「尋問」しない：理解しようとする姿勢で、防衛的な反応を防ぐ
- 「地雷ワード」を避ける：「簡単でしょ？」等の言葉で信頼を損なわない
- 「翻訳」を依頼する：わからないことは正直に伝え、説明を求める
- 感謝と承認を「具体的に」伝える：何を、なぜ評価しているかを明確にする
- 対立を「議論」に変える：「私 vs あなた」ではなく「私たち vs 課題」に
- 定期的な「雑談」の時間を作る：仕事以外の会話で人間関係を深める
最も重要なマインドセット
技術がわからなくても、エンジニアとの信頼関係は築けます。
なぜなら、信頼関係の本質は「技術の理解」ではなく「相互の尊重」だからです。
- 相手の専門性を尊重する
- 自分がわからないことを正直に認める
- 一緒にゴールを目指すパートナーとして接する
これらができれば、コードを1行も書けなくても、エンジニアはあなたを信頼します。
今日からできるアクション
- 明日、エンジニアに機能を依頼するとき、「Why」から伝えてみる
- 地雷ワードを使っていないか、過去の会話を振り返ってみる
- 週に1回、15分の雑談時間をスケジュールに入れる
- 次に技術的な話がわからなかったら、「翻訳してください」と伝えてみる
エンジニアとのコミュニケーションに悩んでいる方へ
- 何を聞けばいいかわからない
- 相手の反応から、自分の伝え方が間違っている気がする
- 関係改善のきっかけがつかめない
- エンジニアの採用・外注で失敗したくない
一つでも当てはまるなら、専門家に相談するのが近道かもしれません。
atelier binary（アトリエ・バイナリ）では、「技術がわからないことで挑戦を諦める非エンジニア起業家をゼロにする」というビジョンのもと、開発の失敗回避・コスト削減・技術選定のアドバイスを提供しています。
技術とビジネスの**「翻訳者」**として、あなたとエンジニアの橋渡しをお手伝いします。
30分の無料相談で、今抱えているコミュニケーションの課題についてお話しください。
