広木大地さん「異なる文法を持つ場所へダイブして、コミュニケーションのハブとなれ」ーー広報とエンジニアリングが調和する組織のつくり方
INDEX
業界を問わず、あらゆる企業でエンジニアに対するニーズが高まっています。そんななか、エンジニアとのコミュニケーションがうまく図れないために採用に苦戦していたり、社内にいるエンジニアと組織的な溝ができしまったり、という課題を抱えている企業も少なくないのも事実です。
こうした悩みを抱える企業に対して、広木大地さんが取締役を務める株式会社レクターでは、組織としてのエンジニアの活かし方をコンサルタントやアドバイザリーとして支援しています。
SNS黎明期のmixiに新卒入社し、20代で同社の執行役員まで務めた広木さんに、PRや人事、経営者など、いわゆる“非エンジニア”がエンジニアをより深く理解し、理想的な関係性を築くためのヒントを聞きました。
Profile
広木大地さん Daichi Hiroki
新卒第1期として株式会社ミクシィに入社。同社メディア統括部部長、開発部部長、サービス本部長執行役員などを歴任。2015年同社を退社。現在は技術組織顧問として複数社のCTO支援を行なっている。著書に『エンジニアリング組織論への招待～不確実性に向き合う思考と組織のリファクタング』（2018）。
誰もが持っているコミュニケーションの“文法”とは？
――今日はエンジニアと企業の関係づくりについてアドバイスをいただきたいと思います。広木さんは現在「技術と経営をつなぐ」ことをミッションに、さまざまな企業の支援をしていらっしゃいますが、どのような課題が多いのでしょうか。
広木さん（以下、敬称略）：企業によって課題は千差万別です。しかし、根底にあるものは共通している気がしています。それは「極端なケースが起きる前の、小さなすれ違い」です。日常的なコミュニケーションのすれ違いが積み重り大きな問題になっていきます。今回のテーマで言えば、ちょっとした認識のすれ違いから、エンジニアから不信感を買ったり、心の溝をつくられてしまったりして、組織的な問題につながっていくことがしばしばあります。
非エンジニア職の方によくいるのが、エンジニアが必死に積み上げてきた「土台」をそうとは知らずに「気軽に崩してしまう」タイプの人ですね。これはエンジニアからの目線の表現になってしまうのですが（笑）。
――PRパーソンや経営者などの非エンジニアはその目線を知りたいのでありがたいです（笑）。具体的にはどういう人なのでしょう？
広木：技術の話だとわかりづらいので、エンジニアではなくWebデザイナーにたとえてみます。サイトの制作がある程度まで進んでいる段階で、プロデューサーや営業などの立場にいる人が突然、「このナビゲーションの色を赤くできない？」と言ったとします。特にデザインの分野では、何気ないこうした会話ってよくありますよね。
でも、デザイナーからすると、サイトのコンセプトに基づいて戦略を決めて、情報を設計して、UIやUXなど専門的な知識を積み重ねて、こういった土台の上に配色やフォントに至るように細部のデザインをしているわけです。単純に赤くしていない理由があるんです。ところが営業の人はライトな感じで意見を言っただけのつもりが、デザイナーにとっては、他者には見えない知識やスキルを根本から否定されるような攻撃的な言葉に感じられてしまうことがあります。エンジニアリングでも同様です。こうした些細なすれ違いが発端で会話ができなくなってしまうケースが多々あるのです。
――何気ない質問や意見でも、信頼感の喪失のきっかけになりうるわけですね。ただそれを怖がりすぎると、エンジニアに対して腫れ物に触るような接し方になってしまいそうです。
広木：違う例を出します。いま、ベンチャー界隈にいる僕たちのパソコンを見てみると、いろんな企業やサービスのステッカーが貼ってあります。仕事中の服装も、比較的自由度が高いですよね。私たちにとってはこれが普通のことかもしれませんが、証券会社に打ち合わせに行くと想定したらどうでしょうか。
「なんで会社のパソコンにステッカーを貼ってもOKなの？そもそも、仕事中なのに白いシャツじゃなくてもいいんだ？」と。こうした、自分では気づけないけれど他者に与えている違和感というか、振る舞いやコミュニケーションの「文法」みたいなものが、業界や職種ごとに異なると思うんです。この異なる文法の間に立って、物事を伝えていく必要があります。
でも、これってよく考えると、広報やマーケティングの仕事でも似たようなことが言えると思いませんか？ターゲットのペルソナがあって、ペルソナに合わせてコミュニケーションのチャネルやクリエイティブを考えて……みたいな。
エンジニアたちは「何に、どう価値を感じる」のか
――たしかにそうしたコミュニケーションのスイッチングは、広報やマーケティングの仕事において、とても重要だと思います。その意味では、「エンジニアの文法は、私たち（非エンジニア）とは違うから」で済まさずに、むしろ進んで理解するべきですよね。
広木：もちろん、相互の歩み寄りが大事です。非エンジニアの方が開発フローの上流に立ち、ものごとを依頼することが多いので、歩み寄りの姿勢がより大切とも言えますね。大事なのは常に歩み寄るのは相手でなく自分自身だと考えることです。
文法の違いを意識することはエンジニアとチームを組むときだけではなく、採用活動でも同様に大事なことです。たとえば、ある会社で、エンジニア採用広報の施策を考えているとします。従来の企業広報の文脈だけで考えてしまうと、著名な方と自社の人材を並べて記事にして、自社の信頼感を得ようとすることがありますよね。エンジニアの採用広報であれば、自社のCEOと有名なエンジニアとか、大企業の元CTOで本も書いてる人とか、その道の権威のような人を並べておくとエンジニアに訴求するのではないかと考えてしまいます。
でも実際のところ、ターゲットであるエンジニアは情報の信頼性を、権威的なものからは得ようとしない傾向があると思うんです。
――本質を見極めたいということでしょうか？
広木：そういう言い方もできるでしょうし、理屈で納得したい人が多いんですよね。「誰々が言っているから」というよりも、自分が納得できる情報かどうか。著名人を広報用に起用することがすべて悪いわけではありません。ですが、見せ方を工夫しないと逆効果になってしまいます。
へそ曲がりに見えるかもしれませんが、僕も「すごい人です」と言われても、本当にすごいかどうかは自分が決めるんだ、というように考えます。こうした傾向の人たちに対して、権威に笠を着るようなコミュニケーションをするのは、文法のズレですよね。
さらに言えば「エンジニアに訴求するのに、いいメディアはどこか、どこに掲載するべきか」が発想の起点になるのもずれているのかもしれません。まずは「どのような共感を生み出すためのコンテンツなのか」「誰に拡散をしてもらいたいか」など、メディア選定よりも共感の生み方や、情報の流通のさせ方が先にくるべきでは、と思います。
エンジニアから見たソーシャルゲーム会社とGAFAの共通点
――エンジニアだけでなく、ほかの職種にも当てはまりそうなお話です。もうひとつ、非エンジニアから見たエンジニア採用の難しさは、待遇にもあるのではないかと思っています。2010年代の後半から、ソーシャルゲームの会社が高給でエンジニアを大量に引き抜いている、という話を耳にするようになりました。
広木：ソーシャルゲームのムーブメントは最近では一段落して、お金で叩き合っている感じはあまりないのではないでしょうか。大手企業の参入で年収のベースが徐々に上がったことも事実ですが、この現象を分析するときに理解すべきなのは、「職場環境の差を埋められるほど、お金がそこまで万能ではない」ということなんです。
ちょっと質問しますが、なぜエンジニアがソーシャルゲーム会社や、最近だとGAFAに流れていると思います？
――お金が万能ではないとおっしゃいましたが、やはり待遇が一番に浮かびます。給与の良さや、無料でおいしい社員食堂がある、リフレッシュルームでテレビゲームができるなど……。
広木：そうしたことももちろんありますが、実はもっと大きなポイントがあります。それは、「エンジニアに対する正当なリスペクト」と「同僚のレベルの高さ」です。特にリスペクトの部分については、それが仕組みや社風に反映されているかが重要なんです。
リスペクトがないのはどういう会社かというと、何をするにも一から説明を求められ、上長の承諾を得ないと何も進められないフローになっている組織です。一方GoogleやFacebookを見ると、現場のエンジニアに権限が移譲されていて、かつ周りには相談できる優秀な同僚がたくさんいる。
ーー確かに、待遇以上にリスペクトがあることは重要な気がします。
広木：仮に給与が5倍、10倍高いとなれば話は別ですが、年収10%~20%程度の違いであれば、優秀な人にとっては決定的な転職理由にはならないでしょう。その意味で、ソーシャルゲーム会社はお金で買い叩いたからエンジニアを動かせたのではありません。規模の大きさにもかかわらずスピード感があり、潤沢なユーザーやデータを抱えるサービスに関われるからなんです。
ビジネスモデルにより賛否はあるかもしれませんが、「クライアントではなく、エンドユーザーの反応が直に見られるサービスで、しかも優秀な同僚がいるんだったら行きたいよね」と思ったエンジニアが多かったのだと分析するべきではないでしょうか。
――たしかにその見方をすると、ソーシャルゲームの会社とGAFAには、エンジニアを引きつける共通点がありますね。
“対営業” “デザイナー” エンジニアが対立の対象になる理由
――採用に関連して、入社した人が離職せず、上手くフィットしていくために、経営や人事にかかわる人はどんなはたらきかけをすべきでしょうか？
広木：会社によって抱えている課題の性質は違いますが、先ほども言ったように、エンジニアの仕事や文法に対して理解やリスペクトがあるべきだと思いますね。
それからこれは肌感覚なんですが、問題のある組織では、「営業VSエンジニア」「デザイナーVSエンジニア」という構図でトラブルが起きている傾向があります。なぜかというと、営業やデザイナーは、エンジニアに「指示したものをつくってもらおう」という感覚があるからなんです。
――SIerに発注している感覚に近いのでしょうか。
広木：そうですね。社内でチームを組んでというより、ソフトウェア開発を頼んでいるような感覚です。だから、「言ったのにできていないじゃない」というように、ともすれば受発注の上下のコミュニケーションが形成されてしまう。そもそもソフトウェアをつくるのがどういうことなのか理解されていない環境だと、開発チームとそれ以外のチームで社内が二分されてしまっていることが往々にしてあります。
一方で、テクノロジーがうまく浸透している会社は、社内向けであれ社外向けであれ、「ソフトウェアは改善が繰り返されていくものだ」という理解があるので、問題を発見する人とソフトウェアを書く人（＝エンジニア）の距離が近いんですね。そういった会社では、事業部やユニットごとに、エンジニアが配属されているような組織がつくられています。
――なるほど。「ソフトウェアをつくるのがどういうことか」について、非エンジニアはどう理解するべきか、より詳しく教えてください。
広木：エンジニアではない人が理解しておくべきなのは、「つくりたいものを“本当に明確に”頼めているのであれば、そのソフトウェアはほぼ完成している」ということです。ソフトウェアって、認識がずれようのないほど明確に記述しないと動かないんですよ。つまり細かい仕様のレベルまではっきりと書くことができるなら、それはプログラムと全く同じものなんです。そうなると、その細かい仕様を決める人が書いてしまえばいい。
でも現実には、そこまで明確な依頼がくることはありません。程度の差はあれ、曖昧で不完全な依頼に対して、互いに認識をすり合わせながらつくっていく作業が、現場のソフトウェア開発で起きていることです。
――つまり先ほどの「頼んだものができてこない」という言葉は、理論上はありえないということなのですね。
広木：そうです。だからこそ“発注”ではなく、“共創”している感覚が大切ですよね。優れたエンジニアリング組織はそのことをよく分かっていると思います。全社でこの感覚が共有できてくると、先ほど挙げたような、エンジニアとそれ以外で組織が分断されるようなことにはならないと思います。
「令和を生き残る組織」に必要な2つの資質
――エンジニアが活きる組織について、ほかにも必要な要素はありますか？
広木：事業部やユニットごとにエンジニアを配置するような組織をつくろうとすると、おのずとチームごとに権限や指示系統が必要になります。そのなかで、マネ―ジャーは「自分と違う職能の人をマネジメントする」ことが求められると思います。
――小単位のチームをつくる上では、営業出身の人がエンジニアをマネジメントしたり、反対にエンジニアが営業の人をマネジメントしたりする可能性もあるということですね。
広木：そうです。意思決定の単位が小さくなりスピードが上がることは、そのユニットや個人の存在が大きくなることとイコールです。そのときに、まったく違う常識や価値観を持った人を理解していく作法がないと、チームがうまく回らないんです。
なぜこれが大事かというと、「今までに求められなかったスキル」だからです。これまでのマネージャーは、自分と同じスキルを持つ、かつ自分よりレベルが低い人たちをマネジメントするのが当たり前でした。「俺がこうやってこういう成果を出せたんだから、おまえもそういう風にやれ」というやり方がまだ成立したんですね。
自分より経験が浅い人に、自分がすでに知っていることを伝えるだけで成長できたのが昭和、それが少しずつ変化しながらも、そのままで30年間やってこられたのが平成です。昨今は「不確実性の時代」とも言われていますが、先行きの不確実さだけではなく、自分にとって不確実なスキルや個性を束ねて1つの方向に向かわせるのが、令和時代の新しいリーダーシップの形だと思います。
――たしかにそうしたチームでは、「俺は昔これだけ成果を出した」はあまり意味をなさないと思います。
広木：はい、そのとおりです。そしてもうひとつ。組織としても小さい単位のチームで、自律的に意思決定やマネジメントがしやすい環境をつくる必要があると思います。具体的には、「派手な失敗を避けつつ、小さな失敗がしやすい環境」をいかにつくるかということです。
今までは「間違ったことは上司が判別できる」という前提で組織が成立していましたが、昨今、その判断をするのは上長ではなくマーケットになりました。そうなると、市場の不確実性は避けるべきものではなく、「うまくつき合う（マネージする）もの」だと考えるべきなんですね。社内で「ああでもない、こうでもない」と試行錯誤する前に、マーケットに問いただすためのチャレンジをどれだけできるかが競合優位性になります。
今の時代、成功は一回すればいいと思います。その一回をものにするためには、考えすぎる前に鉄砲をたくさん打つことです。そのためには、偉い人や特定の誰かがたくさん働くのではなく、意思決定の権限をどんどん下に渡していく仕組みが鍵になります。
PRパーソンは「異なるプロトコルの理解者・翻訳者」であれ
――最後に、広木さんの考えるPRパーソンが担うべき役割について聞かせてください。
広木： PR Tableは広報の情報発信業務の負担をSaaSにして解決しているので、まさにそのひとつですが、これまでの広報担当者がやるべき仕事がどんどん容易になったり、自動化されたりしていますよね。もちろん広報の業務に限らず、仕事が機械化された分、より本質的なことをやらないと価値がなくなる時代になり始めています。メディアに一件一件FAXを送るのは、広報の仕事であって、実は広報の仕事ではないんです。
では、Public Relationsの本質的な仕事の価値が何か？そう考えると、社内外のコミュニケーションのハブになることが挙げられると思います。たとえばエンジニアの採用も、もちろん人事の仕事ではありますが「社外との関係づくりを最適化していくこと」と捉えると、PRパーソンが担うべき仕事の一つだとも言えるのではないでしょうか。
自社の常識ではなく、採用したい相手が「普段何を見て、何を判断して、どんな価値観で生きているか」を理解する。もちろんデスクで検索しているだけではわからないことのほうが多いので、実際にエンジニアがいるコミュニティに飛び込んで話を聞いてみたり、逆に自分から話をして、相手にどんな風に聞こえているのかを感じ取ってみたり。そうした中で相手の文法が理解できてくるはずです。
――エンジニアのコミュニティで話ができるようになると、相手を理解するだけではなく、新しいアイデアや視点も生まれそうですね。
広木：視点という意味では、エンジニア採用がうまくできている人事・広報の方って、中身までは詳しく知らないけれど、エンジニアの言葉遣いというか、単語選びがわかっているんです。エンジニアが、話していて違和感を覚えない言葉で会話ができるだけでも、大きな違いがありますよね。
――エンジニアが、人間の言葉でつくった仕様をプログラミングに変換するように、PRパーソンは、自社の想いを相手の文法に則ったメッセージにしてあげるのが仕事と言えますね。
広木：そうですね。でも実はそれって、普段の広報の仕事でみなさんやっているはずなんですよ。経営者のメッセージを広報の視点でチェックして、メディアが取り上げてくれるような見せ方にしたり、不要な炎上を避けるためにデリカシーのない言葉選びをしないようにしたり。「対エンジニアだから特別」なのではなく、自分とは違う他者といかにコミュニケーションを取るのかということを、エンジニアに対しても考えていく、ということだけなのではと思います。
コミュニケーションのプロであるPRパーソンが、エンジニアとの良好な関係を構築する架け橋になる
他者とのコミュニケーションの文法を読み取り、リスペクトを持って接するーー。
PRパーソンであれば、当たり前のように行っている所作だと思います。
専門的な技術や、それを扱っている人ということだけに囚われると一見向き合うことが難しく感じられますが、相手を理解する文脈として必要であれば、むしろ積極的に向き合っていく必要があると思います。
テクノロジーがより発展していくことがわかっている時代。これからはエンジニアの存在が、これまで以上になくてはならないものになっていくはずです。そんな時にこそ、コミュニケーションのプロであるPRパーソンが、エンジニアと組織のよりよい架け橋として行動していけるのではないでしょうか。（編集部）