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

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

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

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

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

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

技術顧問の案件を探す

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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