経営者とエンジニアはなぜ対立しがちなのか?〜不確実性に強い組織づくりのポイント〜

※本記事は2018年3月に公開された内容です。

【広木 大地さん プロフィール】

株式会社レクター取締役
2008年度に新卒第1期として株式会社ミクシィに入社。同社メディア統括部部長、開発部部長、サービス本部長執行役員などを歴任。2015年同社を退社。現在は技術組織顧問として複数社のCTO支援を行なっている。2018年2月22日に『エンジニアリング組織論への招待~不確実性に向き合う思考と組織のリファクタリング』を上梓。

AIやビッグデータ、ブロックチェーンなどの先端テクノロジーをビジネスに導入し会社の規模拡大を目指す……こうしたアイデアが頭をよぎった経験のある経営者は多いでしょう。ですが、いざエンジニア部門を立ち上げてハイスキルなエンジニアを雇用しても、経営者とエンジニアの間で主張がすれ違い、反発しあい、結果的にテクノロジー活用に失敗することも珍しくありません。

経営者とエンジニアが互いに対立する構図に陥りやすいのはなぜでしょうか?

今回は多数の企業で技術組織顧問として活躍し、CTO含め経営ボードメンバー全体への支援を実践されている広木大地さんにインタビューをおこない、経営者とエンジニアの間に生まれる「溝」の正体をお伺いしました。

技術顧問の案件を探す

原因は「リスペクトの相互欠如」と「不確実なものへの怖れ」

広木さんはエンジニア部門と経営部門の部署間で生じる対立には、どのような原因があるとお考えですか?

株式会社レクター取締役 広木 大地さん(以下、広木):この種の問題を議論する際、しばしば「エンジニアが特殊な存在だから」とか「経営陣のテクノロジーに対する無理解」といった批判が経営者とエンジニア、両陣営から噴出します。エンジニアも普通の人間ですし、経営者も普通の人間です。ただ、ちょっと見えている情報や課題意識が違うところにあるだけです。

この対立構造問題の責任はどちらか片方だけには帰属しているわけではありません。根本的な問題は、相手の仕事を「よく分からない」と理解せずにお互いへのリスペクトが欠如したコミュニケーションを意図せずに連鎖していってしまうことにあります。

壮大に見える部署対立や仕事を進める上での課題も、実はその発端は「あの人に○○と言われて腹が立った」とか「○○さんが嫌い」など個人的な感情であることが多いんです。経営者とエンジニアの意見が食い違うという問題も同様です。たとえば、エンジニアが営業から「冷房のきいた部屋で座っていればいいから楽ですよね」と嫌味を言われたら、怒りたくもなるでしょう。

しかし、エンジニアから「案件なんて少し外を回れば簡単に取れるでしょ」と言われて穏やかでいられる営業もいませんよね。互いの仕事に対する経緯の欠けたコミュニケーションが、個人的な反感に代わり、次第に集団全体に一般化し、部署間のセクショナリズムへと発展していってしまう。

どちらが原因というわけではなく、どちらも相手の仕事に対して敬意と理解が欠けていることが問題だと。

広木:はい。経営者とエンジニアがお互いに自分たちの「よくわからないもの」「不確実で怖いもの」から目を背け続けていることから問題が生じるのです。 エンジニアはシステムが分かるけど、自分で経営判断出来るほどの情報は持っていない。その反対に、経営者はビジネスについては分かるが、システムの中身はよく知らない。なので本当は両者が互いの情報を摺り合わせることが望ましいのですが、なかなか進まない。これは既存の関係性が壊れるリスクをお互いに警戒し、踏み込んだコミュニケーションを取ることを躊躇するからです。

本来、仕事というのは、「わからないもの」を確認し続ける仮説検証サイクルを回すことに他ならない。たとえば、この商品がヒットするかわからなければ、顧客に聞いてみるというマーケティングをしますよね。これは、組織の内部でも同じことです。要するに「わからないから聞く」という作業は仕事の基本だということです。

ところが、日本の企業文化では社内で同調を大事にして、互いに忖度する傾向が特に強いです。不要な発言をせず、和を乱さないことを重視します。相手に聞くべきことを、「あの人は多分こう答える」、「聞くのを嫌がられる」と決めつけて触れないでおくため、社内の問題に自分だけが気づいている場合でも、その問題点を指摘せず、外的要因で社員全員が強制的に向き合うことになるまで放置します。そしていざ会社にダメージが生じたら、「本当はまずいと思っていた」と後出しで言い出します。

このサイクルが積み重なり、自分には分からない問題、不確実性の高い問題に対しては互いに踏み込まない、という組織文化が熟成されてしまうのです。

仮説検証サイクルは「不確実なもの」に挑戦するために回す

先ほど「仮説検証サイクル」というお話が出ましたが、本来このサイクルはどのように社内で回すことが望ましいのでしょうか。

広木:物事を考える思考法にはいくつかあります。代表的な方法は演繹法と帰納法です。演繹法はいわゆるロジカルシンキングのことで、大前提と小前提から結論を導き出すという推論スタイル。帰納法は「今まで見てきた全てのカラスは黒いから全てのカラスは黒いだろう」というように証拠を積み上げて結論を導き出します。

これらに対して仮説法と呼ばれる推論方法は、「わずかな痕跡から仮説を立ててアクションを起こす」ことを特徴とするスタイルです。手元の積み上がったデータから「常識的な結論を導き出すこと」ではなく、「可能性として言えること」を、発想をいくらか大胆に飛躍させて考える、ここがポイントです。

たとえば、大陸移動説の例なんかがわかりやすいです。「アフリカ大陸とアメリカ大陸の海岸線が似た形をしているなぁ」というわずかな痕跡から、「もしかして大陸は1つだったのでは?」と仮説をたて、そのうえで「両海岸の地質を調べよう」という行動へと導きます。もし、違っていたら仮説を立て直せばいいだけです。当たっていたら、大発見へと繋がります。このように仮説検証とは、「もしかしてこうかもしれない」という発想から「だとしたら次の行動はこれだ」というように行動を促していくものです。

しかし、仮説検証サイクル自体は既に多くの企業が何らかの形で実践しています。現状では不十分なのでしょうか。

広木:仮説検証サイクルが演繹法や帰納法的な改善になってしまっているパターンが多い点が問題です。たとえば、何かサービス開発をするときを考えてみましょう。このとき、プロダクトをつくることを「仮説」と捉え、プロダクトを運用して数値をとることを「検証」と考えてしまう人が多い。しかしこれは仮説検証とは何かという観点からいえば間違いです。

「仮説」はビジネスの将来像、未来の話に関わる大胆な想定のことであり、「検証」はその想定の中で、一番不確実な部分を検証するための最小限の行動がプロダクトづくりということになります。たとえば、「サービスの成功のために一番不確実な部分がお客さんが利用して価値を感じてもらえるか」ということであれば、「サービスの価値が伝わる最小限の機能を実装して想定するお客さんに使っていただくこと」が検証になります。もしそれが違ったら、あまりコストを欠けずにそれがわかったので、次の挑戦ができます。成功したら、より多くの顧客や多くの利用されていくように必要な機能やマーケティングをすればいいのです。

つまり、仮説検証サイクルを回す一番大きなメリットは、不確実性の高い領域でも、最小コストでテストが出来るところです。ここでいう「不確実性」とは「どのようなプロダクトがマーケットに受け入れられるか分からない」という不安に関連する不確実性で、私が「目的不確実性」と呼ぶものです。ソフトウェア開発の文脈で言えば、マーケット駆動型のプロダクト開発に携わるプロダクトマネージャーが直面しやすい不確実性ですね。

マーケット反応の予測が難しくても、どんなプロダクトをつくるべきかを最小コストの枠内で考え、試行錯誤してプロダクトのバリューを高めていく。この場合、マーケット反応に応じてプロダクトを開発し続けるため、上手く行けば「終わりがない開発」になります。これが本来の仮説検証サイクルです。

しかし、経営者が開発の成否をプロダクトではなく、コストとスケジュールで測定すると問題になります。これは経営者が「どのような手段、計画がマーケットに受け入れられるか分からない」という、プロダクトマネージャーが経験する目的不確実性とは違う不確実性、「方法不確実性」に直面しているからです。 経営者は採算がとれないと判断したプロジェクトには、プロジェクトマネージャーをたてて終わらせようとします。本来「終わりのない」仮説検証サイクルが終わっていくことになります。この点にも経営者とエンジニアの見解の相違が潜在しています。

「不確実なもの」に強い組織をつくる鍵は、心理的安全性の向上

部署間で生じる不和の問題について話題を戻します。広木さんは経営者とエンジニアの対立を解消するために何が必要だと考えますか?

広木:社員間の心理的安全性をいかに高めていけるか、ここがポイントでしょう。

心理的安全性とは、コミュニケーション上の対人リスクを冒しても「この人たちはそれを受け入れてくれる」という安心感です。国民性を測定した指標であるホフステッド指数を参照すると、「不確実性の回避傾向の強さ」の項目の値が日本は他国に比べてかなり高いです。リスクよりも安定性を取る傾向が強いということですが、この傾向は企業内にも根強く、多くの社員が「せっかく就職したのだから、会社経営に都合の悪いことは言わず、上手くやり過ごそう」と考えがちです。まずはこのマインドを変えて、忌憚のない意見を交わせる社内環境を整備しなければ、強い技術組織が出来上がりません。

そこで心理的安全性の向上が課題となります。バズワード化した影響で、心理的安全性と聞くと「アットホームな職場」、「皆で仲良く」といった内容を連想する人も多いですが、これは不正確な理解です。「仲良くする」のは結構ですが、その結果社員が「和を乱さないようにしよう」と発現を控えるようになったのでは意味がない。本当に必要なのはリスクを恐れずにコミュニケーションがとれる人間関係です。

そうしたマインドの切り替えをサポートされるのが、広木さんのような技術組織顧問のお仕事なのですね。

広木:そうですね。すぐれた技術チームやエンジニアは、不確実なものに対して「より知っていきたい」「フィードバックを受けたい」「お互いに敬意を持って、しかし忌憚のない意見を言い合う」という関係性やマインドが出来上がっています。

ところが、うまくワークしていない組織においては、CEOやCTO、プロダクトチームやオーナーも含めて、社内の人間には見えていない、心理的な盲点となっている領域があり、お互いに遠慮しあってしまったり、忖度してしまって本当の問題に向き合えないでいるという状態があったりします。この盲点を可視化し、社内の課題や問題点の根っこがどこにあるのかを自ら気が付いてもらうことで、マインドの切り替えを外部からお手伝いしています。これが技術組織顧問としての僕の役割です。

人材のダイバーシティ確保が、世界に通用する組織づくりに繋がる

最後に、広木さん自身の今後の展望についてお聞かせ下さい。

広木:活力のあるテクノロジー関連の企業がなかなか日本で生まれないことに危機感を覚えています。私は日本のエンジニアがシリコンバレーの企業と比べて技術力の面で劣っているとは全く思いません。しかし、物事を実現しようとする姿勢、物事のエンジニアリングを図るマインド、文化、風土を内面化出来ていない、ここが問題だと考えています。

また、そのようなマインドを生み出すためには人材のダイバーシティに対する許容度の低さも日本企業が改善すべき課題です。これは、一般に想起される女性活躍や外国人の採用といった狭い意味合いだけではなく、多種多様な個性や専門領域を持った人材の掛け合わせをビジネスの中で行うという意味を含んだダイバーシティです。イノベーションの原点はダイバーシティにあります。統制がとれ、均質的な人材でスケールするビジネスから、異質なもの同士の掛け合わせからビジネスを生む方向に世界がシフトしているなか、日本企業はいまだに均質化された人材ばかり受け入れてしまいます。エンジニアにはぱっと見風変わりな人が多い傾向がありますが、そのせいで日本企業では疎まれがちです。そんなマインドでこれから世界と戦えるわけがない。

既存の企業文化を破壊し、企業人材のダイバーシティを確保することで、不確実性を力に変えることができる会社を日本全体に作っていく。今後はこうしたビジョンを実現すべく活動していきます。

本日はありがとうございました。

編集後記~エンジニアと経営者が協働する組織をつくるために~

経営者とエンジニアの対立の原因は「お互いの仕事へのリスペクトの欠如」と「不確実なものへの恐れ」だと語る広木さん。部署間の不和を緩和するために必要なのは、マインドの切り替えにより社内の心理的安全性を高めること、リスクに直面しても恐れずに乗り越えていけるように組織文化を再構築することだと指摘します。

今回のインタビュー全体を通して、経営者とエンジニアが互いに手を取り合い、「不確実なもの」を恐れず、世界で通用するようなプロダクトを作りあげてほしい、という広木さんの情熱がひしひしと伝わってきました。

広木さんの展開する技術組織論にご興味のある方は、同氏の著作『エンジニアリング組織論への招待~不確実性に向き合う思考と組織のリファクタリング』も是非ご一読下さい。

広木さん本の写真

FLEXYのご紹介

FLEXYは、エンジニア、技術顧問、CTO、デザイナーの方向けに案件をご紹介するサービスです。
リモートワークや週1-5日、高単価案件など、ご希望に合った案件をご紹介いたしますので、是非お気軽にご相談ください。

FLEXYに登録する

企画/編集:FLEXY編集部

FLEXYとはABOUT FLEXY

『FLEXY』はエンジニア・デザイナー・CTO・技術顧問を中心に
週1~5日のさまざまな案件を紹介するサービスです