マネージャーが負うべき責任と役割とは？
3人のリーダーが“強いエンジニアリング組織”の作り方を語る

エンジニアのマネジメントと組織づくり

及川卓也氏（以下、及川）：今日のファシリテーターを務めさせていただきます、及川です。よろしくお願いいたします。

（会場拍手）

今日はこの「『強いエンジニアリング組織をつくる』～技術リーダー達が向き合うべき課題とは～」という題で進めていきます。改めて今日の登壇者を紹介させていただきたいと思います。

今、名前を先に申し上げてしまいましたけれども、私は及川と申しまして、現在クライス＆カンパニーの顧問を務めさせていただいております。

マイクロソフトでWindowsを作って、あとはグーグルでいろいろな検索系のプロダクトマネージャーをしたあとに、後半はChromeのエンジニアリングマネージャーを務めました。そのあとスタートアップで、Qiitaというプログラマの情報共有コミュニティサービスのプロダクトマネージャーなどをやったあとに、今年6月から独立し、いろいろな会社のお手伝いなどをさせていただいています。その1つにクライス＆カンパニーさんがあるというかたちになっております。

次、井原さん、自己紹介お願いします。

井原正博氏（以下、井原）：こんばんは。ゆるい感じでお手柔らかにお願いしたいんですけど（笑）。井原と申します。

今はビットジャーニーという会社で「Kibela」という情報共有サービスを作っています。及川さんが関わられた「Qiita:Team」の競合と見なされるようなサービスです。

前職はクックパッド株式会社というところにおりまして、エンジニアが数名ぐらいから50人ぐらいのところまで採用や組織づくりをやってきました。いろいろな失敗を数多くしているんですが、クックパッドの技術力向上ということだけはやれたかなと思っています。今日はよろしくお願いします。

（会場拍手）

及川：はい。では、杉浦さんお願いします。

杉浦正明氏（以下、杉浦）：みなさん、こんばんは。ニューズピックスの杉浦と申します。

NewsPicksというニュースアプリなんですけれども、知っているよという方はどのぐらいいらっしゃいますか？

（会場挙手）

ありがとうございます。8割ぐらいですかね。今日も使った方は？

（会場挙手）

ちょっと減りましたね、これは残念ではありますが、ぜひみなさん今日のニュースを見てください。

NewsPicksというニュースアプリを開発しています。NewsPicksはもともとすごく小さい状態から、今はだいぶみなさんにもお使いいただけるようになってきたので、今日はサービスが広がる中でエンジニア組織をどのように拡大してきたのか、経緯や拡大の過程で学んだノウハウをお伝えできればと思っています。

ちなみにニューズピックスは「Kibela」を使っています。

井原：ありがとうございます。

杉浦：Kibelaを使うとサービスを伸ばせるのではないかということで、ぜひみなさんKibelaをご検討いただいて。

井原：ゴリ押していただいてすみません（笑）。ありがとうございます。

杉浦：というところで、よろしくお願いいたします。

（会場拍手）

及川：ちょっとゆるい感じで始めたいので、乗っかって質問すると、私はNewsPicksでプロピッカーをやっているんですけれども、私をフォローしている人はいらっしゃいますか？

（会場挙手）

ありがとうございます。はい、それだけです。

井原：よかったですね。

日本のIT企業が強いエンジニアリング組織を作っていくために

（スライドを指して）ここにも書いておりますように、エンジニアの採用をしなければいけない。育成、評価はどうしよう？　そういったところにさまざま制度やプロセスが関わってくると思うんですけれども、ここにはなにか王道があるわけではなく、各社各様にいろいろな工夫をされていると思います。

ですので、今日はこの3人が中心ですけれども、みなさま方のコメントや質問なども受け付けながら、日本のIT企業もしくはITを活用している企業が、強いエンジニアリング組織をどう作っていくかというところを議論させていただければと考えております。

本日は2部構成になっております。1部がこの3人を中心としてディスカッションさせていただくというもので、2部がみなさま方からの質問を受け付けるというかたちになっているんですけれども、あまりそこを明確に分けることなく、1部から質問を受け付けて、あまり形式にとらわれずにインタラクティブに進めていきたいと思っております。

杉浦：Slido（注：会場からの質問を集められるサービス）はもうみんな入っているんですか？

及川：そうですね。（スクリーンを指して）これです。前回参加された方はどのぐらいいらっしゃいますか？　あんまりいないのかな。

（会場挙手）

若干いらっしゃいますね。前回も「Slido」というアプリケーションを使ったんですけれども、アプリをダウンロードしなくても大丈夫です。

（スクリーンを指して）これはモバイル版ではないんですけれども、これが実際にデスクトップで見たときの画面になります。質問を入力できるというだけのものです。

もうすでに出てきている質問に対して、投票できるようになっています。ですから、たくさん質問が出たときに「これ私も聞きたい」というものがあったら、ぜひ親指が上を向いているところをタップしていただくようにお願いします。

そうしますと、そのポピュラリティで順位がソートされるようになっておりますので、みなさんがお聞きしたい質問が上のほうに出てきて、それから答えていくことができるようになっています。ですので、こちらも同時に使っていきたいと思います。

なので、たまにこちら（Slido）を見て、そのとき回答したほうがいいものがありましたら適宜採用させていただきたいと思っております。

では、前置きはこれぐらいにしてさっそく進めていきたいと思います。今回はテーマを4つ設けておりますので、それぞれについて議論していきたいなと思います。

今回、エンジニアリングマネジメントにおいて、どういう役割を果たしてその組織を強化していくかという議論をしたいとは思っているんですけれども。そもそもマネジメントポジションにはどういうものがあるのか、あとはお二方と私も含めて、それぞれに対する認識はどうかということですとか、組織構造といったところについて最初にお話をうかがいたいと思います。

前回と若干かぶるところはあるんですけれども、今回初参加の方がほとんどですので、そのあたりはご容赦いただきたいと思います。

ニューズピックスの仕事の進め方は「プロジェクトベース」

杉浦：マネージャーの職種は明確に分けていないですね。ただ、私の中ではテックリードとプロダクトオーナー、あとはVPoE（VP of Engineering）の3つに分けています。状況に応じてその3つの役割を誰かが担うというかたちで組織を作っています。

及川：なるほど。明確に職種を作られていない理由は、臨機応変に変える可能性があるからということですか？

杉浦：そうですね。弊社の仕事の進め方は、プロジェクトベースなんですよね。タスクフォース。

例えば、「プロピッカー制度を始める」というミッションがあったら、それを成し遂げるために「じゃあこれは誰がプロダクトオーナーをやろう」「誰がテックリードをやろう」とか。担当を決めて一気に走るということをやっているので、あらかじめ決めておくというよりは、そのミッションごとに都度誰かを決めるやり方をとることが多いです。

及川：なるほど。井原さん、それをお聞きになってなにか質問やコメントはありますか？

井原：実際にいろいろな人がいろいろな役割をこなせるのかという問題がありそうな気がするんですが、そんなことはないですか？

杉浦：そこはやはりコーディングが得意な人やマネージャーが得意な人はあると思います。やはり「自分はあまり人といろいろコミュニケーションをとるのは苦手」というメンバーはいるので、そういうメンバーに無理やりVPoEみたいな役割を担わせることはないですね。

あくまで本人のやりたいことを尊重しつつ、ただ、チームとしてやるべきことを誰かが担う、というフォーメーションのとり方が多いかもしれません。

及川：なるほど。ごめんなさい、先に聞くべきだったんですけど、ニューズピックスには技術職の人は全部で何人ぐらいいらっしゃるんですか？

杉浦：エンジニアは今30名ぐらいです。

及川：じゃあ30名で、全員ではないけれども、なにか2つ3つのロールを持てる人がプロジェクトごとに役割を実践されるんですか？　どういうかたちでその役割が決まっているんですか？

杉浦：一番重視するのは、本人のやりたいことですね。Willというか。「なにがやりたいんだ？」ということを聞きつつ、全員の希望は叶えられないこともあるので、本人の希望と会社としてやるべきこと、あとは本人が得意なことをうまく掛け合わせて決めます。

及川：あと、杉浦さん自身はCTOという立場だと思うんですけれども、杉浦さんも今言った3つの役割をプロジェクトごとに使い分けているんですか？

杉浦：そうですね。私も役割をコロコロと変えています。例えば、去年は広告事業を立ち上げていて、アドサーバを内製したんです。そのアドサーバは私がアーキテクトとしてほとんどの部分を設計、実装しました。

最近だと、「NewsPicksアカデミア」という弊社の2つ目のアプリを先週リリースしました。このプロジェクトでは、私は一切コードを書かずにプロダクトオーナーとして、どういう世界観を作るかという点に注力したという感じです。

及川：私は、実はお聞きしているので知っているんですけれども、杉浦さんが1人でコードを書いているときに、例えば誰か30人のエンジニアのマネジメントしなければいけないわけですけれども、それはどなたがやられるんですか？

杉浦：それはほかのメンバーがやったりしますね。

及川：なるほど。もう少し具体的に。ほかと言っても誰でもなれるわけではないと思うんですよね。

杉浦：そうですね。弊社は経営メンバーも3人いるんです。共同創業者が3人いて、経営自体もフォーメーションを変えながら行っている。

だから時には、例えば1人体調が悪くなってしまって前線に出れない。これは実際にある話で、現在進行形なんですけど。新野（良介）という共同創業者の持病が悪化したということでIRも出しました。

そういうときは、もう2人の経営メンバーが「じゃあ今自分はなにをやるべきか」ということで、「今は自分が営業責任者をやる」「自分がプロダクトオーナーやる」「採用コミットメントする」だとか、なにを成し遂げて担っていくかということを変えながら経営を進めてきました。

そういう企業文化が経営層だけでなくチームやプロジェクトにおいても浸透していますね。だからリーダーメンバーやマネージャーになればなるほど、やはり今なにをすべきかというところを自分で考えて実行していくことが求められていますね。

及川：なるほど、わかりました。

リプレイス不可能な組織を目指したい

井原：エンジニアが業務委託の方も含めて4名です。エンジニア3名、エンジニア兼PM（プロダクトマネージャー）みたいな人が1名。あとデザイナーの方が1名ですね。

及川：なるほど。マネジメントポジションといったら、プロダクトマネージャー1人と、あとは井原さんというかたちですか？

井原：はい。そうなります。

及川：井原さんは、自分自身をどういうマネジメントスタイルというか、役割だと思われていますか？

井原：自分自身は、会社の掃除をするとか、トイレ掃除をするとか、会計処理をするとか、そういうポジションですかね。

及川：（笑）。技術的な面では？

井原：技術的な面では、僕は今はほとんどなにもやっていないです。完全にお任せしていますね。

及川：それは創業時からそうだったんですか？

井原：創業時は1人で始めたので、1人で考えて1人でコーディングをしていたんですが、だんだん人が増えてきて、もうそのあたりはお任せするようになっています。

及川：なるほど。井原さんに関しては少し私と似てるところがあって、ぜひお聞きしたかったんですけれども、ビットジャーニーと同時にいくつかの会社の技術顧問もやられているじゃないですか。そこはどういうふうにバランスをとられているんですか？

井原：もう赤裸々な話になるんですが、会社をやっていこうとするとお金が必要なわけですよね。お金ってすごく大事で、お金がないとなにもできない。

僕の場合は、ヤフーやクックパッドの経験から、「手伝ってほしい」と言ってくださることがけっこうありまして、それにできるかぎり応えたいと思っている。それはお金がどうこうというのとは別として応えたいと思っているんですけど、「とはいえ、お金も必要だよね」と。

通常ベンチャーは、調達してエクイティみたいなもので事業を進めていく、どこかでイグジットする、ということが多いかなとは思うんですけど。その調達の代わりに顧問業をすることで自分がお金を作っています。

弊社のメンバー構成を考えたときに、僕はもしかしたらプロダクトを作れるかもしれないし、エンジニアリングもできるかもしれないし、お金を作れるかもしれない。でもメンバーの人たちは、プロダクトを作ることはできるかもしれないんですけど、外貨を稼いでくることはプロダクトを通す以外ではなかなか難しい。

そのときに、今、自分たちが持っているアセットでどうやって能力の最適化を図るかを考えると、僕はプロダクトを作れるかもしれないけど、お金を作れるのであればお金を作り、プロダクトを作れる人たちにプロダクトを作ってもらうということが、能力を最適に配置するときには一番いいんじゃないかなと思っています。

ただ、僕がそのプロダクトを作りたいという思いは別として、というところですね。

及川：先ほど杉浦さんがお話しされたニューズピックスのチームのやり方を採用するということはあるんですか？

どういうことかというと、今言った、お金を稼ぐ、プロダクトを作る、あとコードを作る。プロダクトとコードを書くというところをあえて分けましたけれども。この3つの役割をこなせる人がもし井原さん以外にいたならば、そこはローテーションしたりすることは可能だと思うんですけど、そういうことは考えたりしますか？

井原：別になにが正しくてなにが間違っているということはないという前提で、僕はその人にしかできない仕事があると思っているんですね。成果や結果が同じだったとしてもプロセスは絶対違うと思っていて。その人のやり方でしかできないやり方があると信じているんですよ。

なので、逆に言うと、リプレイス不可能だと思っているし、リプレイス不可能な組織を目指したいと思っている節があります。

まあ、「死んじゃったら終わりじゃん」と言われると、それは弱い組織なのかもしれないですけど。その人の強みを活かした個人が集まった組織という意味では、それは僕は強い組織だと思っているので、その人の一番得意なやり方や成果を出せるやり方でなにか価値を出してほしいなと思うんですよね。

という意味では、リプレイスはたぶんできたとしてもやらないんじゃないかなと思います。

メンバーシップ型とジョブディスクリプション型

一方で、本当に倒れたときの話を考えたときに、ローテーションを日頃から組んでおいたならば、誰かがその仕事をちゃんと引き継げるというところは確かにあるかなと思います。

それで考えると、雇用のあり方として、メンバーシップ型とジョブディスクリプション型と言われるところとも似てくるのかなと思ったんですよ。

ご存じない方にご説明すると、メンバーシップ型は日本企業に非常に多くありがちなもので、要はいったん社員として採用したならば、「その人は社員です」と。すごく極端なことを言うと、技術職で採用した人であったとしても、技術的な仕事に向いてないとか、もしくはそのポジションがいらなくなったとなったら、「営業でどうですか？」「カスタマーサポートどうですか？」ということをするような雇用のやり方です。

ジョブディスクリプション型というのは、完全に一人ひとりを専門職というかたちで採りますから、例えばカスタマーサポートで入った人は、本人が望み、ちゃんと適性が判断されないかぎりにはほかの職には異動しないというようなことです。これはアメリカ型の企業に多いんですけれども。

ニューズピックスはメンバーシップ型にすごく重きを置いているように感じたんです。それは正しいですか？

杉浦：いいえ、そういう意味だと両方あると思います。ニューズピックスの価値観で大切にしているのは「異能は才能」という考え方なんですね。それぞれが持っている個性なり違いを才能として尊重する。プロフェッショナルを大切にする考え方です。

コーディングしかできない、ずばりコミュ障みたいなメンバーもけっこうたくさんいて、「学生時代にネトゲやりすぎて廃人になっていました」とか（笑）。

そういうメンバーも大活躍しているんですよね。やはりそういうメンバーにしか書けないコードがある。脳の構造が違うんですよね。普通の人とは違う脳みそを持っている。ただ、うまく日本語をしゃべることができなかったりしますが（笑）。

そういうメンバーは、コードを書いたほうがアウトプットが出るので、コードを書くべきだと思っています。これはプロフェッショナルですよね。

ただ、もう一方で、ミッション型というんでしょうか、ミッションを実現するためには自分の役割を小さく制約しないという考え方も大切にしています。例えば、私は昨日動画広告の営業に行っていました。自分で広告商品を企画して、コードを書いて開発して、それを売りに行く。商品企画した者が一番思いが強いので、商品の設計意図だとか、この商品がなぜ良いのかという点を一番熱く語れるんですよね。だから売りに行くと実際に売れるんです。これをオールラウンダーと言うのか。

要はやりたいことをただやっているだけなんです。私のモチベーションは、コードを書きたいことよりは、良いサービスをみなさんに提供したい。そのために、考え、作り、世に広めるというところをすべてやっているだけなんです。そういう職種があってもいいと思うんですよね。つまり、メンバーシップ型とジョブディスクリプション型は両立するんじゃないかというのが考えですね。

プロダクトマネージャーはなにをやる人か？

プロダクトマネージャーも両者で分かれていて。井原さんのところはプロダクトマネージャーという役割は固定でいらっしゃって、ニューズピックスのほうは、役割の1つというかたちでプロジェクトごとに決められると言われていました。ただ、それにしてもプロダクトマネージャーはプロジェクトごとにいるわけですよね。

杉浦：はい、そうですね。

及川：お二人に聞きたいんですけど、プロダクトマネージャーって、お二人の組織ではなにをやる人なんですか？

井原：開発の優先順位を決定する人ですかね。もちろんその人の独断ではなく、すごく小さい会社なのでみんなで話しながらやるんですが、最終的になにをどの順番で開発する、なにをいつリリースする、ということを決める人という定義だと思います。

及川：なるほど。ニューズピックスではいかがですか？

杉浦：やはり優先順位を決めるというところは同じですね。より明確に言うと「エッジを作る人」という表現をしたりしていますね。

やはりプロダクトを作るときには、エッジがないと誰にも刺さらないんですよね。僕らはまだ小さい組織なので、まん丸のボールみたいなプロダクトを作ってポーンと投げても誰の心にも刺さらない。

だからエッジを作る必要が、本当に針のように尖らせた、ある一定の人にだけ刺さるようなプロダクトを作る必要があるんですけど、そういうものって往々にして社内で拒否されるんですよね。ある少ない人にはすごく刺さるんだけど、それ以外の大多数、とくにおじさんとかにはよくわからない、みたいな。「インスタとかよくわからない」みたいなことと一緒だと思いますけど。

そういう反応をするので、あとはそういうところのケツ拭きですよね。「これがいいんだ」ということをちゃんと説明して、ちゃんとエッジを起こして、最後まで作り、世に出すというところ。これがそのまま優先順位の作り方と同じなのかもしれないですけど、それがプロダクトオーナーの最大の責務かなと思っています。

及川：そうですね。両者ともにエッジを利かせるというところはとくに同意できるところです。優先順位つけるというところで、なにかはやるし、なにかはやらないということをメリハリつけて開発を進めていくことになると思います。

このときに、当然、合意形成が難しいと思うんですね。おそらく完璧な合意形成は無理だと思うんですよ。今杉浦さんもおっしゃったように、誰かは反対するというところがあると思うんですけれども。完全な合意形成はできないものの、合意を取り進めていくということをお二方のプロダクトマネージャーの方はどうやってされているんですか？

井原：もうコミュニケーションをひたすら納得するまでやり合う。納得しないなら、前に進まない。

なんですが、そのやっている相手もエンジニアだったりするので、やはりこの議論がいかに非効率なものかということはある程度理解があるし、「どこかで止めて前に進まないと進まないじゃん」ということが根底にあると思うんですよね。

なので、毎回揉めることはあるんですけれども、だいたいPMの言っているとおりになる、みたいな。「なんだったんだ、お前は」みたいになるんですけど。それが多いですかね。

ただ、なんのコミュニケーションもとらず、AとBがあったら「Bはやらない。Aはやります」というのはちょっと乱暴だと思いますし、そこは本当に普通に話し合いをしています。

及川：要は、きちっと説明責任を果たしていくけれども、どこかでお尻を決める。そのお尻を決めたときは、最後はもうプロダクトマネージャーが決めていいよというような、組織のルールというか文化ができているような。

井原：そうですね。誰かが決めないと最後は決まらない。ただ、決める自由というか、決める権限とそれに伴う責任を負うというところですね。

及川：なるほど。杉浦さんのところはいかがですか？

杉浦：そうですね。（井原氏と）一緒で、オープンコミュニケーションと呼んでいるんですけど、ひたらすらオープンに議論をすることですね。組織文化として、忖度しないというか（笑）。

思ったことを率直に言う文化なので、例えばこれがもう当たらなそうだったら「これダメだよね」とか、そういうことは率直に議論をしますね。

重要なのは、やはりミッションが共有できているかどうかだと思います。ミッションがズレていたらそもそも一緒にやっている意味がないので、そこは必ず最初に一致させておかなければいけない。

それを実現するための機能がAかBかというのは別にどちらでもよくて、よりそのミッションに近いほうを選べばいいだけなので。自分の案が通らなくて、Bのほうがいいと思ったらそっちにしようだとか、そういう感じでけっこう柔軟に変えてしまったりしますね。

マネージャーの役目は「最後のケツを拭き切る」こと

ミッションは事業サイドのリクエストもたくさんあると思うんですね。ただ、それ自身がエンジニアがやりたいこと・やるべきことと相反することはままあると思うんです。そういったとき、お二人はどういうふうにそのシチュエーションをマネージされるんですか？

井原：「どうしてもやらなあかん」ということは絶対にあると思うので、そこは「まあまあ、やってください。やりましょうよ」ということだと思うんですけど。でも9割がそれになると、やはり「そうじゃないよね」とは思います。もちろん1割2割はあるかもしれないですけど。

ただ、エンジニアが作りたいと思えるものを出すというか、それを描くことも事業側の1つの責任じゃないかなとは思うんですよね。「作ってもらう」ではなくて、「作りたいから作っている」という状態をどうやって組織の中で作るかのほうが大事なのかなとは思います。

及川：なるほど。

杉浦：ニューズピックスでは相反しないですね。なぜならば、エンジニアが事業にコミットしているからです。

だから、マネージャーが事業リーダーを兼ねればいいと思います。私がそうなんですけど、要は「今期これだけ売り上げます」と言ってしまえばいいんですよね。責任を持って「プロダクトを作ります」と。そうすれば事業サイドとエンジニアサイドは目線が一致しているので、もうやりたい放題というか、自分の責任でやるという感じですよね。

及川：なるほど（笑）。

杉浦：目標達成しなかったら自分で売りに行ったりすればいいわけなので。そうやって物事の最後までコミットしてやり遂げることで、自分の作りたいものを作れる環境というのも得られるんじゃないかなと。

だから、マネージャーの役目というのは、やはり最後のケツを拭く、拭き切るというところがマネージャーとして求められる資質になってくるんじゃないかなと思いますね。

及川：そうですね。お話を聞いていると、ニューズピックスは事業の責任を持つ人がみんな技術に明るいという感じなんですけど、それは正しいですか？

杉浦：技術ですか？

及川：技術に明るい人が就いている。だからいざとなったら自分で、全部作れるかどうかは別にして、ある程度作るというところにコミットできる人がいる。

杉浦：そうですね。ビジネスサイドというのがあまりないので、エンジニアとビジネスサイドがほぼ一致しているような感じではありますね。

及川：なるほど。それが先ほどからおっしゃっている、ミッションが重要であり、そこさえ一致できているならば矛盾しないという話なわけですね。

杉浦：そうですね。

及川：それは先ほど井原さんおっしゃったこととだいたい一緒ですよね。わかりました。

マネジメントに就くきっかけ

お二人ともご自身でマネジメントをされていると思うんですけれども、最初から自分でマネジメントに向いていると思われましたか？　もしくはなにかターニングポイントがあったとしたら、それはどういう時だったか教えていただきたいんですけれど。

井原さんは、そもそもヤフーで最初からマネージャーだったわけじゃないですよね？

井原：「Yahoo!メッセンジャー」というIMのWindowsクライアントを作っていました。

及川：マネジメントに就くきっかけはなんだったんですか？

井原：最初はWindowsクライアントを作っていたんですけど、作っているうちに今度BSDのサーバ側を見るようになって。そうするとほかのチャットやYahoo!掲示板、Yahoo!グループなどいろいろなサービスが……もはや今はないんですけど、そういうサービスを作るようになっていって、だんだん技術リーダーみたいになり、そうするとメンバーがつく感じになって、なんとなくやるようになっていった感じですね。

及川：どこかで「違うんじゃない？」と思ったこと、もしくは「あ、マネージャーになった」「マネージャーに向いてるかも」ということを思ったきっかけはありますか？

井原：3ヶ月のうち2ヶ月ぐらいエクセルとパワポを使っているようになった時には「これはもうエンジニアではないんだな」と思いましたね。

（会場笑）

及川：（笑）。その時は悲しかったんですか？

井原：悲しかったですね。「パワポを作るのがめっちゃうまい」と言われても「このスキルはいらないぞ」みたいな。

及川：でも、そのあともずっとマネージャーを続けられたわけじゃないですか。

井原：そうです。

及川：実はパワポが好きになっていったとか？（笑）。

井原：そうですね。パワポはすごくいいツールだと思うんですけど（笑）。ヤフーを辞めた時に部下というか見ている人たちが60～70人ぐらいいて、そこから技術者数名のクックパッドに行くんですけど。その時は1年のうち3分の2がパワポとエクセルを使っていたので、これはもう人が死ぬと思って。

辞めて、「俺はものづくりをしたいんや」と思って行ったら、やっぱり「組織を作ってほしい」という話になりました。ものづくりに来たのに、まあ組織もものと言えばものなんですけど、組織を作ることになって。

その時は完全にもうコーディングもせずオフィスの内装をやったり、本当にそういうことをやっていました。別に嫌という気持ちはなかったんですけど、「コードを書くことはないんだな」という漠然とした寂しさはありましたね。

及川：なるほど。それはなんで嫌じゃなかったんでしょうね？

井原：僕はけっこう採用することや、採用した人が成果を出してくれるのを見ることが好きだったんだと思うんですよね。でも、それって別に自分でそれをやりたいと思ってやり出したわけではなく、どちらかというと「やってくれませんか？」と言われて「じゃあ、やりますか」とやったら意外とできた、みたいな。

及川：なるほど。わかりました。

マネージャーは「自分がやっていないから感動する」

杉浦：私も、根がプログラマーなので、昔はマネージャーになりたくないと思っていましたね。とくにSIer時代は、プログラムを書けない上司を見て「コードも書けないのに偉そうなことを言って高い給料をもらっている」っていうのが許せなくて。「自分はあの歳になっても絶対現場でコード書くんだ」と言っていたんですけど。

もし変わったとすると、きっかけは挫折ですね。とくにベンチャーに行ったあとの挫折です。1人の力では世の中が変わらないんですよね。1人でコードを書いているだけだと、製品はできていくんですけれど、遅いんです。

世界を変えるには仲間が必要だと。強いチームを作らないと改善スピードが上がっていかないんですよね。チームを作るとやはりそっちのほうが早いという実感があって。そうしているうちにだんだんと「組織で動いたほうがいい成果が出るし、いい成果が出るなら強い組織を作ったほうが合理的じゃん」という考えに変わってきたのがきっかけです。

今でも自分が向いているか向いていないかはよくわからないですね。ただ、そうするべきだと思っているからそうしている、というところが大きいです。

及川：やはりそうですよね。お二人の話の共通部分は、自分から率先してそこに関与するようになったかどうかは別として、やはり製品を出すためには組織がなければいけなくて、組織を作るという部分がいい製品を出していくためには重要だというところで、そこに携わるようになっていったということかなと思うんですよね。

もう1個、杉浦さんのお話で私がすごく同意するところがあります。最近の持論は、エンジニアがマネージャーになりたくない理由はすごく自然なんだけれども、けっこうな割合で「過去に自分の上司が嫌な人だったから」ということに帰着するところが多いと思うんですね（笑）。「あんな奴になりたくない」と。

それは人格的に問題がある人がいたりもするし、一方では板挟みになっていて楽しくないような仕事をしている人が多いと思うんですよ。だから、ついこの間まで優秀な先輩だったAさんが、マネージャーに昇格した途端、コードも書かないでエクセルとパワーポイントだけやっていて、なんか愚痴ばっかり言っていて「営業と下からの板挟みにあって大変そうだな。あんな仕事は就きたくない」と思ってしまう。

それがけっこう多いと思うので、これを払拭していくと、実はマネージャー職もけっこうおもしろい。先ほど言われたみたいに、1人ではできないことを、自分の影響力を行使することによって、自分のミラーコピーを何人か作れるようなかたちになるわけじゃないですか。

もう1つは、「製品を作る」と「組織作る」って、組織を作るのもけっこう科学的なところもあったりするかなと思うんですね。人間相手なので、コードを作るよりももっとヒューマンスキルが必要にはなるんですけれども。でもサイエンスな部分もたくさんあると思うんですよ。そう考えるとけっこうおもしろいんじゃないかなと思っています。

けっこう幻滅するような過去の体験だとか、もしくはそういったシチュエーションをほかの人が語ったりしているから、そういうふうに思われてしまっているところも多いかなと思うんですよね。なにか感想ありますか？

杉浦：まさにおっしゃるとおりで、ぜんぜんできなかった人が、リーダーにしたら突然活躍し始めたり、自分が関与していないプロジェクトで、自分のアイデアではないすごくいいアイデアがいつの間にか実装されていたりして、「こいつらすごいな」と思ったり、「俺の考えた組織配置すごかったな」みたいな（笑）。そういうことはけっこうありますよね。

そういう時って、本当に自分が何もやっていないから感動するんですよね。そういう感動があるとマネージャー職もだんだん楽しくなってくる気がしますね。