2008年に、当時日本最大のSNSだったmixiを運営する株式会社ミクシィに、第一期新卒エンジニアの一人として入社し、同社メディア開発部長、開発部部長、サービス本部長執行役員を務めた広木大地氏。2015年にミクシィを退社したあとには株式会社レクターを創業。今も多数の企業の技術・経営支援を行っているほか、一般社団法人日本CTO協会理事として活躍しています。

また、2018年2月に刊行した書籍『エンジニアリング組織論への招待　～不確実性に向き合う思考と組織のリファクタリング』は、IT業界を中心に、さまざまなエンジニア、そして、エンジニアを束ねるマネジャーたちに読まれています。

今回は広木氏が考えるエンジニア像、そして変化の激しい時代における不確実な事象との向き合い方について、ご自身の考えを伺いました。

エンジニアには2種類のタイプがいる

――はじめに、エンジニアの定義から入りたいと考えています。それに先立って、広木さんが考える、自分のなりたいエンジニア像はありますか？

広木さん（以下、「広木」）：私はエンジニアには2種類のタイプがいると考えています。

1つは何かを作りたい、作りたいものに向かって一直線に走っていくタイプ、もう1つは、作るうえで気になったことを知りたい、深掘りしていくタイプです。

そのどちらかで言うと、自分自身は後者のタイプ、深掘りするエンジニアです。ゼロイチで考え、目的を達成できるモノを作るより、その中身の部分、コアやシステムの仕組みに興味がわくタイプ、ライブラリやフレームワークを作っていくことやそれを支える思想や原理原則のような思想性が見えるものが好きなタイプです。

いちエンジニアとしての好みはそうなのですが、その一方で、仕事という観点でのエンジニアリングを考えると、中身の技術を深掘りするだけではなく、（多くの人やさまざまなアウトプットを）つなぎ合わせてでも目的の実現を目指すというマネジャー的仕事やリーダー的な仕事もとても楽しかったりします。

エンジニアとして仕組みや思想のようなものが好きな自分のようなタイプと、ものづくりのアイデアが豊富で実現に向かって一直線に突っ走るタイプというのは、良いプロダクトを作っていくために組織においてどちらも必要で、こういった多様な個性を束ねながら、協力していってこそ事業としてのアウトプットにつながるのだと思っています。

これらをまとめると、自分が考える良いエンジニア像の1つは、自分の中の原理原則を大事にしながらも、それにこだわりすぎず、また、他の人を矯正したり、排除したりせずに、チームとしてのエンジニアリングを楽しめる人材といえます。

――エンジニアという職業は、「何かを生み出す」という点から、アイデアの出し方や個性の部分に焦点が当たりやすく、個人技を重視するエンジニアが注目されやすいといえます。その中で、広木さんが今のような考えに至った背景や転換のポイントがあれば教えてください。

広木：私は2008年に株式会社ミクシィに入社しました。ミクシィとして、初めての新卒での入社、第一期新卒でした。当時入ったメンバーは、まさに個性派ぞろいでした。そのときは「自分は（他と違って）こうありたい」「周りのメンバーには負けたくない」という意識が強かったですね。若気の至りですかね（笑）。

それから、時間がたって振り返ってみると、やはり周りにいた同期は皆優秀で、そして、個性的でした。ですから、そのときに持った自分の意識は良い経験だったと思います。そして、今の自分が良いエンジニア組織の姿を思い浮かべると、「キャラクターを一言で語りづらいような個性的な面々がそろった、多様性のある組織」のイメージです。当時のミクシィもそうだったと思います。

そのような個性派ぞろいの組織の場合、きちんとまとめ上げ、それぞれのエネルギーや（考え方の）ベクトルの方向性をそろえるとすごい力を発揮でき、良い結果につながるという体験を多数してきました。そうしたひとつひとつの経験が、今、自分が「周りを意識し、個性を排除せずにまとめること」に意識し、また、楽しめるようになった背景だと考えます。

良い組織であり続けること、多様であり続けるにはこの部分、つねに個性的なメンバーがいて、同じ方向に向かえることが大事です。それができていることは、つねに組織が（年齢的にという意味ではなく）若いことの裏返しと言えますし、健全な状態だと思っています。

組織づくりのポイントは「役割の明確化」と「意思決定のタイミング」

――「個性的なメンバーが増えていくこと＝チーム・組織の成長」ということですね。おっしゃるように、多様であり続けながら、組織が拡大できることが、組織づくりの理想の1つと考えられそうです。

では、組織づくりの面で、個性的なメンバーがいやすい、定着しやすい、増えやすい環境になるよう心がけていたこと、取り組んでいたことはありますか？

広木：一番大事なことは役割、意思決定を明確にすることですね。中でもチームや組織でプロジェクトを進めるにあたっては、明確な意思決定をすることが最も大切です。あいまいな状態を許してしまい、空気や全員の納得や満足にばかり目が向くと、意見を聞くことや調整するといったプロセスに偏ってしまいます。物事を前に進めるのは意思決定だけですから、こういった事態は避けなければなりません。

かといって皆の意見を無視していいわけではありません。それぞれの意識や考えを聞くタイミングが大事です。物事を決める前には意見を聞き、議論を交わすことも大事です。そのうえで、何かを決めたのならば「何が意思決定されたのか」を明確にして、チームも意思決定者が最終的に決めたことに従って動き出せるとより良いチーム・組織として機能します。

事前に意識や考えを聞くタイミングを適切にしたうえで、意思決定者であるリーダーが責任を持って決めることで、個性的なメンバーがいるチームであっても合意までのプロセスを尊重しあえますし、決定したあとには全員が意思決定した方向へ動きやすくなります。

役割や意思決定が不明確なままでチームの中で不満が募ると、プロジェクトのゴールに対して内側に気持ちが向いてしまいます。プログラミングで言うところのスパゲッティコードのようなものです。

「意思決定のタイミング」と「役割の明確化」、この2つが、個性的なメンバーでのチームづくり・組織づくりのポイントです。

――「意思決定のタイミング」は非常に難しいですね。その大事さを認識していることが、良いチーム・組織につながるように感じました。一方の役割ですが、これはどのように決めるのが良いと考えますか？

広木：役割は時代とともに変化しているので、私が最初の会社に入社した時代から振り返ってみます。私がミクシィに入社した2008年から約12年がたち、その間、Webサービスの開発や運用に必要な役割は大きく変わり、明らかになってきました。

2008年当時のWeb開発・Web制作は、DTPの延長、映像制作の延長、ソフトウェアパッケージの延長など、類似する業界に属する人たちが、Webという「アプリケーション」を開発し始めた時期です。そのとき、良く言えば全体を見渡す役割、もう少し実直に表現するとなんでも屋という役割がWebディレクターでした。そこには今でいう、プロダクトマネジャー、プロジェクトマネジャー、UXデザイナーなども含まれていたと思います。Webディレクターには、DTPの流れから進行管理や、SIerであればSEがやっている要件定義といった役割が含まれていました。

このときと現在の一番の違いは、当時のWeb業界全体はまだ、継続的にソフトウェア・サービスを改善して開発することに慣れていなかったということです。その背景には、Web業界が生まれた1990年代後半までさかのぼります。Webだけを開発・制作してきた人が少なく、他の業界からWeb業界に関わる人が多かったのもあります。

2008年がその切り替わるターニングポイントで、最初からWebに関わる人がますます増え、Webに関わる人の「役割」が変わっています。Webサービスと同様に、一度開発したら終わりではなく、リリースして継続的に改善しながら開発する組織も増えてきました。

「そこで必要な役割は何か？」「どんなスペシャリストが必要なのか？」そういったことについて組織・チームで考えられながら、業界が成長しています。

Web業界には、今、さまざまな役割が増えた（呼び名が増えた）と言われますが、それは細分化ではなく、進化した結果の分化で、私は良いことと捉えています。私がミクシィに入社して10年以上が経ち、それまではエンジニアやディレクターのように大雑把なくくりでしたが、過去の世代がやってきたことに名前がついて、フロントエンドエンジニアやUXデザイナーのように、スキルセットがより明確な役割になってきています。

結果として、新しくそういった分野を目指す人がスキルを習得しやすくなり、また、その後のキャリアも描きやすくなりました。ぼんやりとしていた技術や役割、仕事の進め方が言語化されたことでコミュニケーションの齟齬が減っています。スキルセットの共通化で転職もしやすい時代になっているのではないでしょうか。

――明確かつ適切な意思決定の実現に合わせて役割の概念が変化していると感じます。

広木：おっしゃるとおりですが、1つ注意をしなければいけないのは、業務が説明できるようになり、分化とともに役割が明確になったことで、その間にあるものが見落とされてしまう危険性があることです。

機械学習のプロジェクトを例に取ると、プロジェクトマネジャーは、ひとつひとつのタスクを管理するだけでは、プロジェクトを管理できない場合があります。たとえば、プロジェクト初期に想定していたデータでは、精度が十分に上がらないなどの技術的な困難が隠れていたり、推論結果の利用方法のUIに倫理的な問題が潜んでいたりします。また、推論するモデルの品質を維持し継続的にアップデートするためのエンジニアリングに想定外のスキルや工数が必要になるなどもよく聞く話です。

このように根本的なプロジェクトリスクが発生した際には、プロジェクト全体の設計そのものを見直す必要があります。役割の分化で進められていたプロジェクトは、新しいリスクに応じてマネジメントの方法が変わってきます。そこにまた新たな役割（業務）が発生する余地がありますし、本質的な部分として、意思決定のタイミングが変わります。

2000年代の単純なWebアプリケーションでは、タスク管理や進行管理でよかったディレクター的な役割も、機械学習のプロジェクトの場合、データサイエンスに対する深い理解や達成可能性まで考慮した複雑なプロジェクトマネジメントスキルが必要になってきます。こういった部分に実験計画ディレクターやAI倫理コンプライアンス担当のような新しい役割が生まれるかもしれません。

また、従来のWebプロジェクトの場合でも、開発者へのハードルは年々上がっています。領域や役割が分割された結果、個々のエンジニアに求められること、キャッチアップすべき分野が限定され深さが求められることが増えたからです。

それを解決するのが、フレームワークなどさまざまな仕組みの活用です。この状況では、（特定の技術やスキルに）フォーカスしづらくなっていますが、キャリア戦略の観点で見れば、多様化して良いと私は捉えています。

――お話を伺って、役割の変遷、また、今見えている課題とこれからの可能性を感じられました。そのうえで、役割の決め方についてどのように考えているか、教えてください。

広木：まず、前提として、「役割を決めること」と「果たすべき目標を決めること」を切り分けないことです。経営者であればすべて自分の裁量で決められますが、そうでなければ自由裁量では決められません。エンジニアリングマネジャーならエンジニアリングマネジャーの、プロデューサーならプロデューサーの……という目標を決めがちですが、これは大きな誤解で、そうならないように注意が必要です。

目標は人を評価するためのものではなく、達成した結果、革新的かつ面白いプロジェクトになるために設定するものです。、ですから、今挙げたような個別の目標、いわゆるサブKPIが達成できたとしても、企業や組織全体の目標（目指す姿）に到達しなければ本末転倒です。

新しい発想、創造力・想像力を掻き立てることにこそ、目標の価値があります。

――全体の目標とともに役割を決める際、たとえば内製でエンジニアを確保すると、どうしてもエンジニア側に受託（受け身）感が出てしまうことがあると感じますが。また、そのときに課題になるのが評価です。その点についてどのように思いますか？

広木：その課題を解決するように、最近のベンチャー企業の流れとして、事業側にエンジニアを寄せていく動きがよく見られます。エンジニア自身が事業にコミットできる体制です。ただ、これは事業の成長に対し、あまり早くエンジニアを事業寄りに持っていくと、事業側がエンジニアを理解していない、あるいは、エンジニアが事業を理解していないというハレーション（悪影響）が起きることがあります。

それを防ぐために、事業側とエンジニア側のスキルが溶け合う役割や体制が求められるわけです。理想は組織の中にエンジニアがうまく溶け込んでいる状態です。私はこれを、水と油のようだったエンジニアと事業側が溶けていくため、組織のエマルション（互いに溶け合わない液体同士が混じり合っている状態）と表現しています。これはDXを推進する際には最も重要な視点の１つだと思っています。

また、これは人事評価、エンジニアの評価にもつながる話で、目標への達成度、成果へのコミットだけが基準ではありません。そもそも、評価とは企業に残ってもらいたい人物像で、（評価されるエンジニアが）辞めたとしてもかわるものではありません。

もちろん、事業達成にコミットすることを良しとする（そういう人材が定着する）ことが良しとする評価であれば、それも1つの基準です。

最も避けなければいけないのは、人事評価や制度に対し、もたらす結果が不明瞭な状態で、評価する側・される側にとっても悪い状況です。

エンジニアの採用とこれから

――組織を大きく、そして成長させていくにあたっては、採用も大きな意味を果たします。広木さんの今の立場から見て、採用に対するご意見はございますか？

広木：そもそもの話として、採用は本当に難しいですね（苦笑） 。100％うまくいく方法はありません。

その前提で、世の中で採用がうまいとされる企業や組織の共通点として、経営陣を含め、組織としてエンジニアコミュニティのカルチャーを理解していることが挙げられます。エンジニア採用がうまい組織は、エンジニアコミュニティに対してアピールする方法や認知してもらう方法、そして、何より正しく伝わることを意識している人が多く在籍しています。

他の職業がどうかはわかりませんが、エンジニアの場合、「テレビでCMをやってます」とか、「ビジネス部門がこういう賞を受賞した」といったメッセージよりも、エンジニアコミュニティの中で聞こえてくる声や認知度が大切になってきます。

また、こういった声は会社にとってきれいなことを言いがちなトップの発信ではなく、実際に所属している現場からの声が漏れ伝わるような状況のほうが良いですね。現場の声こそがまさにその企業や組織の生のリアルな声ですから。エンジニア経験者は、エンジニアとして良いことや辛いことに対して敏感で、エンジニアコミュニティの雰囲気を大切にしているように思います。

ソフトウェアエンジニアは誰よりも早く新しい技術に触れ、新しい付加価値を生み出せる仕事

――最後に、これからの社会におけるソフトウェアエンジニアの重要性、影響力についてどのようにお考えか教えてください。

広木：この先の社会を考えた場合、人口が増えていく速度とコンピュータの進化の速度を比較すると、圧倒的にコンピュータの進化のほうが早いです。

これは有史以降、人間が担う領域はどんどん機械（道具）に置き換わり、そして、コンピュータ誕生以降、その流れは加速しています。つまり、人間の仕事がコンピュータの仕事に置き換わる領域（自動化）はどんどん広がっています。

そして、その時代時代の先頭に立っている、最初に（置き換わりの）変化に気が付ける、すなわち誰よりもソフトウェアの価値がわかる場所にいるのが「ソフトウェアエンジニア」です。

たとえば、ここ数年、ソフトウェア業界ではSPA（Single Page Application）に注目が集まり、技術的な投資が進んだため比較的に簡単に高いクオリティのWebアプリケーションを構築できるようになりました。そのため、企業向けの業務SaaSのように複雑な要件やUIが必要になるようなサービスの開発も容易になりました。ソフトウェアエンジニアであればこのような変化にいち早く気がついていたはずです。このように、まだ多くの一般の人が知らない技術や変化に対し、その価値、凄さがわかるのがソフトウェアエンジニアという職種ですし、これはこの先も変わらないと考えています。

だからこそ、ただ触れるだけではなく、理解して使うこと、そしてその先の価値を広げていくことが大切です。こういった体感的なすごさや使いやすさ、複雑な問題の解決のしやすさの変化は、自身が触れることで意識できますし、結果として、今後のビジネスがどう変わっていくのかも気がつきやすくなります。

誰よりも早く新しい技術に触れられることを意識し、そして、それらを理解して付加価値を生み出していくこと、それがこれまでもこれからも、ソフトウェアエンジニアの最大の価値だと考えます。

――ありがとうございました。

（聞き手：株式会社技術評論社　馮富久）

広木大地さんに3つの質問