キャリア Vol.404 中島聡氏が語る、世界で戦えるプロダクトリーダーを生む4つの条件【キャリアごはんvol.1レポ】

【Web・アプリサービス「次のデファクト」を生む現場リーダーになるには？】をテーマに開催した第1回キャリアごはん

日々の仕事に追われて普段はなかなか考える機会のない「ひとつ上のキャリア」について、ごはんを食べるように自然に考えてもらいたい——。そんな想いを込め、エンジニアtypeと「今よりもっと満足できる仕事」との出会いを応援する姉妹サイト『@type』は共同で、新たにワークショップ型イベント『キャリアごはん』を立ち上げた。

第1回は9月29日、東京・青山にある『Royal Garden Cafe青山』で開催し、約60人のエンジニアが参加する形となった。テーマは、【Web・アプリサービス「次のデファクト」を生む現場リーダーになるには？】。MicrosoftでWindows 95/98開発のチーフアーキテクトを務めた中島聡氏と、国内企業5社の開発リーダーをゲストに招き、トークセッションとパネルディスカッション、ワークショップの3部構成で開催した。

ここでは、【世界で戦えるプロダクトリーダー論】と題して行われた中島氏のセッションを中心に、当日の模様をレポートする。

中島氏は自身のエンジニアとしてのキャリアに照らして、理想的なリーダーを「（部下である）自分が能力を最大に発揮できる場を提供してくれた人」と定義。その上で、こうした理想的なリーダーになるため、さらに組織内に理想的なリーダーが生まれるための条件として、4つのポイントを挙げた。

1、仕様書なんていらない。リーダーはエンジニアに任せよ

中島聡氏が考える世界で戦えるプロダクトリーダー像とは？

30数年エンジニアをやってきましたが、過去に出会った中で最高のリーダーだったと思うのは、Windows 95の開発をリードしていたBrad Silverbergです。

当時のチームはあらゆる意味で素晴らしく、私自身あんなに働いたことは後にも先にもないし、いいモノが作れたし、市場でも成功した。一緒に働いていた人たちとの関係は、リリースから15年が経った今も続いています。

Bradのすごさをひと言で言うなら、Empowerment。つまり、部下の力を最大限に発揮させるということになります。私自身、何とか再現したいと思っているのですが、この概念を言葉で説明するのは非常に難しい。

ただ、一つ徹底されていたのは、現場のエンジニアを信頼して、仕事を任せていたということです。

あれだけ市場で成功したWindows 95ですが、仕様書と呼べるものはわずか2ページしかありませんでした。その2ページに、どんな商品を作るのかが10項目ほど書かれているだけで、後はエンジニアが自由に作ることが許されていたのです。

私がWindows 95（当初は3.1）の開発グループにアサインされて最初に上司に挨拶に行った際も、「独立して存在しているアプリケーションを一つにまとめる仕事をしてほしい」と言われ、ソースコードの在り処を教えてもらっただけ。後は、仕事の指示もデザインレビューも、相談もありませんでした。

前に所属していたグループがミーティングばかりで最悪だったこともあり、とにかくコードが書きたくて仕方がなかった自分にとっては夢のような環境でしたね。

エンジニアに任せることがなぜそれほど重要なのかと言えば、ソフトウエアエンジニアリングというのは、他の多くのモノづくりとは根本的に異なる産業だからです。

ビルや橋であれば、設計書さえできたら、後はそれに従ってルーチンで作業を進めることもできるかもしれません。しかし、ソフトウエアの開発は設計に近いものですから、個人の能力、アイデア、モチベーションなくして成立しません。

エンジニア一人一人の力が求められるのがソフトウエアエンジニアリングなのです。

2、「作ったもん勝ち」のカルチャーを作ろう

関連してもう一つ大きかったのは、私がいた当時のMicrosoftには「作ったもん勝ち」のカルチャーがあったことです。

かつてMicrosoftが独禁法違反で訴えられたことがありましたよね。その原因の一つは、Internet ExplorerをWindowsにバンドルしたことですが、実はあれは私がやったことなんです（笑）。

Windows 98（当初は97）を作るにあたって、ビル・ゲイツからはインターネットを中心に考えるという方針こそ示されていたものの、具体的な方法については決まっていませんでした。Windows 95とInternet Explorer両方の開発に関わっていた私は、そうした会社の方針とは全く無関係に、勝手に自分のPC上で両者をつないで遊んでいたんです。

それをたまたま目にしたBradが気に入って、本当に採用してしまった。私自身は何を説明したわけでもありません。仕様書だとか承認だとかもそこにはありません。あるのは、PC上で動いているという事実だけです。

OSやアプリケーションを作るには、クリエイティビティを発揮しなければなりません。クリエイティビティに、仕様書とか承認とかいう概念は合わないと思います。私自身も、まさにこれからクリエイティビティを発揮しようというタイミングで、「まず承認を取れ」とか言われたら、萎えてしまって作れるはずのものも作れなくなってしまいます。

3、「ダメなコード」、「淘汰されたサービス」は躊躇なく捨てよ

ソフトウエアエンジニアの仕事にクリエイティビティは不可欠。思いついたらすぐ作れる環境の創出が大切と説く中島氏

大事なのは、許可を待ったり評価を気にしたりすることなく、まずは作ってみることです。作ってみて思ったようなモノができなかったのなら、それを上司に見せなければいいだけの話ですから。

私にとってのエンジニアリングは、粘土細工で皿を作るようなもの。まず作ってみる。形は後からついてくるという感じです。丁寧に設計するというのではなく、思いついたものを思いつくままに30分くらいで作ってみて、それで動かなかったらリセットしてまたイチからやり直します。

作っては捨てるを繰り返し、本当に面白いと思うものができた時だけ、それを世に送り出す。つまり、世に出ているものの背後には、気に入らずに捨てたものが山ほどあるということです。私は、世に出したコードの10倍くらいは捨てています。

もちろん、出してはみたけれど周囲の理解が得られなかったものもまた、大量にあります。でも、まずは作ってみないと、それがいいか悪いかの判断なんてつかない。まして、作る前にはそんなこと分かるわけがない。

こういう話をすると、「コードを捨てるのは嫌だ、もったいない」と言う人も少なくないですが、それでは良いプログラマーにはなれないと思います。リジェクトされるというのは世の中の仕組みとしての自然淘汰ですから。私自身は嫌だと感じたことはありません。

むしろ、グループにおいても会社全体においても、ちゃんと淘汰の仕組みがあり、そこで残ったものが初めて、ビジネスサイドの人たちの力を借りて市場に出るという流れが良いのではないかと私は思います。

コードを捨てることにおびえるよりも、思いついたらまずは手を動かすということをオススメします。

4、会社はコードを書きながら出世できる道筋を作れ

2000年に自分でUIEvolutionという会社を立ち上げ、最初に学んだのは、社長をやっていると思うようにコードを書けないということでした。自分がCEOをやっている間は、会社としてもあまりうまくいきませんでした。

うまくいきだしたのは、私はFounderとして会社に関わることにし、経営を他の人に任せるようになってからです。この体制にしてからは、あらためて自由にコードを書けるようになったので、個人としても会社としても理想的な形になっています。

エンジニア個人がコードを書き続ける道を選ぶのか、人を束ねる側へと進むのかは人それぞれですが、両立が難しいということは言えるでしょう。

しかし現実には、日本の会社ではコードを書きながら出世することは難しいと聞きます。もしも偉大な何かを成し遂げるエンジニアリングチームのリーダーになりたいのなら、プレイヤーのまま出世する道も会社の中に作ってあげないといけません。

これはエンジニアに限った話ではない。例えばジョナサン・アイブは、今でもデザインし続けていますよね？

この点に関しては、当時のMicrosoftはうまくいっていた気がします。給与を決める個人の評価が組織体系とは完全に独立していたため、給与額は必ずしも組織内のポジションと一致していませんでした。

私自身、上司より給与が高いという状況が何度かありました。上司を務めていたのは、コードをそこまで書けるわけではないけれど、人を使うのがうまい人。私自身は純粋にプログラマーとして評価してもらえる環境にあったということです。

ワークショップは「仕事やキャリア」についての課題解決の場に

ワークショップでは、参加者から「仕事やキャリアについての課題」を募り、課題意識の近い参加者同士がグループになって、解決策を議論した

中島氏のトークセッションに続いて、国内企業5社の開発リーダーによるパネルディスカッションを行い、各社の開発の進め方や直面している課題を話してもらった。登壇者は以下の通り。

■AWA株式会社（サイバーエージェントグループ） 辻 純平氏

■GMOインターネット株式会社 次世代システム研究室 シニアクリエイター 稲守貴久氏

■スマートニュース株式会社 SmartNews Ads プロダクト担当ディレクター 渡部拓也氏

■freee株式会社 リードエンジニア 若原祥正氏

■株式会社メルカリ プリンシパルエンジニア 鶴岡達也氏

企業規模や手掛けるサービスジャンルが異なる5社だったが、チームづくりにおける「ビジョンと方向性」の大切さや、それを前提とした採用の重要性などの点で意見が一致。中島氏も話していたEmpowermentのやり方について、各社の具体的な事例が披露された。

そして最後のワークショップでは、こうしたトークセッションの内容を踏まえて、参加者から「仕事やキャリアについての課題」を募り、課題意識の近い参加者同士がグループになって、解決策を議論した。

議論のテーマは「事業方針重視の会社でキャリアパスどう作っていく？」、「メンバーの力を最大限発揮できる環境づくりとは？」、「全くカルチャーの違う会社と一緒に仕事をするコツ」など。各グループにはゲスト登壇者も1人ずつ参加し、一緒に解決策を探った。

手前味噌ではあるが、食事をとりながらのカジュアルなスタイルだからか参加者同士の距離は非常に近く、また自身の課題意識に端を発する議論だからか、積極的に発言する姿が目立ったのが印象的だった。

全ての課題がその場で解決したわけではないだろう。だが、サービスの種類や規模、フェーズも異なる会社同士でありながら、参加者へのアンケートでは「課題解決の良いヒントを得られた」というポジティブな感想が多く寄せられていた。

エンジニアtypeでは今後も、「仕事やキャリア」にまつわるさまざまなテーマを設けて、継続的に「キャリアごはん」を開催していく予定だ。

文・撮影／鈴木陸夫（編集部）