Reminus CEOのsumirenです。
CTO代行サービスを提供するなかで、意外に多くの経営者が悩まれているのが、「エンジニアとスムーズにコミュニケーションができない」というものです。
例えば以下のような会話はないでしょうか。
経営者「この機能はどうやって作りますか？何ヶ月かかりますか？」
エンジニア「API上で同期的にやる方法とジョブでやる方法があって、それぞれ1か月か3か月です」
経営者「（よくわからない…）1か月のほうだとリスクはありますか？」
エンジニア「技術的負債が溜まったり、将来開発生産性が下がる可能性が高いです」
経営者「（よくわからない…）」
こうした会話はスタートアップでは実によくあります。
実際、開発と経営の認識がズレると、仕様問題や開発の手戻りが発生して事業進捗に悪影響が出たり、徒労からくるお互いのストレス・組織内不和にもつながってくる点で、経営上も問題になりえます。
「エンジニアにビジネス目線がない」と愚痴を言いたくなる気持ちもわかるのですが、実はこのコミュニケーションには、経営者側が改善できるポイントも多いです。
この記事では、経営者起点でどうコミュニケーションを改善できるか書きたいと思います。上記の会話を例に、難易度の低いところから順番に改善していきたいと思います。
1.HOWを聞かない
課題
まず最初の問題は以下の「どうやって作りますか？」という質問です。
経営者「この機能は"どうやって"作りますか？何ヶ月かかりますか？」
経営者は、技術については素人です。仮に昔触ったことがあったとしても、今のあなたは経営者であり、現役の方と同じ目線で技術の会話ができるという前提は、働いてくれているエンジニアへのリスペクトにも欠けるでしょう。
にも関わらず、「どうやって」を聞いてしまっているために、エンジニアは手段に対する説明責任を覚えています。
エンジニア「"同期的な処理で"作ると1か月、"ジョブ化して"作ると3か月です」
その後の会話が、やたらと技術的な仔細の話に寄ってしまうのも、こうした会話のコンテキストの作り方にあります。
解決策
解決策はシンプルで、HOWを聞くのをやめることです。
経営者「この機能は
どうやって作りますか？何ヶ月かかりますか？」
これで、以下のような会話に近づくでしょう。
経営者「この機能は何ヶ月かかりますか？」
エンジニア「2つ作り方があって、それぞれ1か月か3か月です」
経営者「1か月のほうだとリスクはありますか？」
エンジニア「こういうユーザーのUXが悪くなりチャーンにつながる懸念があります」
補足：経営者は技術を学んではいけないのか
経営者の方によっては、むしろ自分から積極的にHOWを深掘ってしまうタイプの方もいます。しかし、これは特におすすめできません。
エンジニア「API上で同期的にやる方法とジョブでやる方法があって、それぞれ1か月か3か月です」
経営者「なるほど。API化して外部公開は特に考えていないので、その場合短くできますか？」
エンジニア「（そんな話は全くしてないんだけど、）あー、はい、可能性はあります」
技術をわかろうとする姿勢はソフトウェアの会社の経営者として素晴らしいです。しかし、重要なのは、わかろうとするとは、わからないことを認める姿勢であり、わかってるフリとは全く違うということです。
付け焼き刃の知識で会話できてるフリをしていると、エンジニアが経営者のズレた発言に忖度し、全体最適が失われることにもつながります。
2.WHYに目線を向ける
課題
もしエンジニアの方がジュニアであれば、前章のようにフラットな会話づくりに経営者側が改善しても、技術的なHOWの話ばかりしてしまう可能性もあると思います。
経営者「この機能は何ヶ月かかりますか？」
エンジニア「API上で同期的にやる方法とジョブでやる方法があって、それぞれ1か月か3か月です」
経営者「（よくわからない…）」
コミュニケーションコストが高くつくだけであればまだマシで、手段の議論ばかりしていると、「技術的には完璧だがユーザーには売れない無価値な機能」が完成する本末転倒な状況にもつながります。
人にはそれぞれ過去の経験からバイアスや仕事のスタイルがあるものです。「この議論の目的はなんなのか」というコンテキスト（文脈）の明確化が重要です。
解決策
経営者が達成したい目的をコンテキストとして補いましょう。
経営者「この機能は何ヶ月かかりますか？トライアル顧客数社のモニター期間がもうすぐ終わり、この機会を活かして有料化の営業をかけたいのですが、それにはこの機能が必須なため、最速で実現したいです」
これにより、以下のような会話の流れが作れる可能性が高まるでしょう。
エンジニア「1か月のやり方と3か月のやり方がありますが、1か月のほうでも致命的な問題はないと思います」
経営者「どのようなリスクがありますか？」
エンジニア「こういう既存ユーザーのUXが悪くなりチャーンにつながる懸念があります」
会話のコンテキストを意識的に示すことで、会話の目線をWHYに向け、生産的な会話ができるようになります。
3. 聞き出さない、WHYを預ける
課題
ここまでで十分、エンジニアとのコミュニケーションは改善されるかと思いますが、最後に応用的な改善アイデアを記載します。
こうしたコミュニケーションを突き詰めていくと、そもそもあれこれと聞き出す必要がなくなってくると思います。
というのも、今までの会話の形式はこうなっていました。
経営者「この機能は何ヶ月かかりますか？」
エンジニア「〜〜〜」
経営者「〜〜〜？」
エンジニア「〜〜〜」
経営者「〜〜〜？」
しかし、エンジニアが増えたときに、こうしたコミュニケーションは効率的でしょうか。
それ以前に、そもそも経営者は多忙で、Go-to-Market組織のセールスやCS、コーポレート部門も管理しなければなりません。ファイナンスや投資家コミュニケーションなど自分自身の作業もあります。
解決策
経営者がボールを持ってあれこれと聞き出すのではなく、エンジニア側にWHYを預けて意思決定してもらう形を目指してみましょう。
経営者「トライアル顧客数社のモニター期間がもうすぐ終わり、この機会を活かして有料化の営業をかけたいのですが、それにはこの機能が必要です。目的が実現可能か判断してほしいです」
もちろん、こうした振り出し方は、エンジニア側の能力が一定あること、社内のコミュニケーション文化が良い形で作れていることが前提にはなるでしょう。
しかし、うまくいけば、以下のような流れで当事者間で会話してもらいながら経営者のマインドシェアを下げて事業を前に進めることができます。
エンジニア「いつまでに作れていれば、タイミング逃さず営業をかけられますか？」
営業「1ヶ月後にあればなんとか」
エンジニア「こういう既存ユーザーのUXが少し悪くなるリスクはありますが、進めていいですか？」
経営者「はい、それで進めてください」
まとめ
創業者には、戦略に強い方、営業に強い方、財務に強い方など、様々なタイプがいます。しかし、20社以上と関わってきて、どのような創業者であれマネジメント力は必須の能力であると、個人的には感じます。
この記事で記載したような改善は、明日から経営者側が改善しても、エンジニアの方がすぐに改善するとは限りません。いままで培ってきた貴社のコミュニケーション文化があるためです。
また、経営者の皆さん自身にも、コミュニケーションの癖がついているはずで、無意識のうちに以前のコミュニケーションをしてしまう場合もあるでしょう。
焦らず地道に改善していけると良いと思います。
Reminusでは、CTO不在の企業様に向けて、CTO代行のサービスを提供しています。経営と開発現場をつなぎ、経営の意思決定に技術を持ち込みます。よければぜひサイトをご覧ください。
