「強いエンジニアリング組織をつくる」
～技術リーダー達が向き合うべき課題とは～

今回は「強いエンジニアリング組織をつくる」をテーマにお二方に話をおうかがいしたいのですが、まず杉浦さんがCTOを務めるニューズピックスではどのような組織形態で仕事を進めていらっしゃるのですか。

弊社の場合はプロジェクトベースです。たとえば「プロピッカー制度を始める」というミッションが掲げられれば、それを成し遂げるためにふさわしいプロダクトオーナーは誰、テックリードは誰……と担当を決めて一気に走るスタイルです。ですからミッションごとに役割が異なることが多いです。

実際のところ、いろいろな人がいろいろな役割をこなせるものですか？

そこはやはり人によって得意不得意はあると思いますので、コミュニケーションをとるのが苦手というメンバーに無理やりVPoEのような役割を担わせることはないですね。あくまで本人のやりたいことを尊重しつつ、ただ、チームとしてやるべきことを誰かが担う、というフォーメーションが多いかもしれません。

井原さんが率いるビットジャーニーはいかがですか。

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

なので、逆に言うとリプレイス不可能な組織を目指したいと考えている節があります。まあ、「その人が死んでしまったらおしまいじゃん」という意味では弱い組織なのかもしれないですが、それぞれ強みを活かした個人が集まった組織のほうが僕は強いと信じているので、その人がいちばん得意で何か価値を出してほしいと思っています。

いまおっしゃったように、どちらが正しいということはなく、なかなか難しい問題ですね。確かに属人性は完全には剥がせないと思う一方、本当に倒れた時を考えると、ローテーションを日頃から組んでおけば、誰かがその仕事をきちんと引き継げる。

それを考えると、雇用のあり方として「メンバーシップ型」と「ジョブディスクリプション型」にも関わってくるのではないかと。ニューズピックスはメンバーシップ型に非常に重きを置いているように感じるのですが、杉浦さん、いかがですか。

いえ、そういう意味では両方あると思っています。我々が価値観として大切にしているのは「異能は才能」という考え方。社内にはコーディングしかできない、コミュ障みたいなメンバーも結構いるんです（笑）。

でも、そういうメンバーにしか書けないコードがある。脳の構造が違うんです。彼らはコードを書いたほうがアウトプットを出せるので、それを究めるべきだと思っています。ただ、もう一方で、ミッションを実現するためには自分の役割を小さく制約しない、という考え方も大切にしています。たとえば、私は昨日、動画広告の営業に行っていました。自分で商品を企画し、コードを書いて開発して、それを売りに行く。

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

なるほど。いまお二人はいわゆるマネジメントに関わるポジションに就かれていますが、事業サイドのミッションと、現場のエンジニアがやりたいこととが相反することもままあると思うんです。そうした状況をお二人はどのように対処されているのですか。

ミッションのためにどうしてもやらなければならないことは、メンバーに説いてやってもらいます。でも大半がそれになってしまうと、やはりモチベーションが下がる。エンジニアが作りたいと思えるものを世の中に出すというか、それを描くことも事業側のひとつの責任ではないかと。「作ってもらう」ではなく「作りたいから作っている」という状態を、どうやって組織の中に生み出すかが大事だと思っています。

ニューズピックスでは相反しないですね。なぜならエンジニアが事業にコミットしているからです。要は「今期これだけ売り上げます」と言ってしまえばいいんですよね。責任を持って「プロダクトを作ります」と。そうすれば事業サイドとエンジニアサイドは目線が一致するので、もうやりたい放題というか、自分の責任で何でもできる。目標達成しなかったら自分で売りに行けばいいので、そうして物事の最後までコミットしてやり遂げることで、自分の作りたいものを作れる環境も得られるんじゃないかと思いますね。

お話をうかがっていると、お二人ともマネジメントのスタイルが異なるようにお見受けしますが、そもそも最初から自分はマネジメントに向いていると思っていらっしゃいましたか？　何かターニングポイントがあったとすれば、それを教えていただきたいのですが……井原さんはかつてヤフーにいらっしゃいましたが、そちらで最初からマネージャーだったわけではないですよね？

最初は「Yahoo!メッセンジャー」というIMのWindowsクライアントを作っていました。そのうちBSDのサーバー側を見るようになって、そうすると他のチャットや「Yahoo!掲示板」「Yahoo!グループ」などいろいろなサービスの開発を任されるようになって、だんだん技術リーダーみたいなになって……そうするとメンバーがつくようになり、何となくマネジメントを手がけるようになっていった感じです。

当時、僕は人を採用することや、採用した人が成果を出してくれるのが結構楽しかったんですね。でも、それって別に自分でやりたいと思っていたわけではなく、どちらかというと周りから「やってくれませんか」と託されてやってみたら意外とできた、という感じですね。

杉浦さんはどのようなきっかけだったんですか。

私も根がプログラマーなので、昔はマネージャーになりたくないと思っていました。SIer時代は、プログラムを書けない上司を見て、コードも書けないのに偉そうなことを言って高い給料をもらっているのが許せなくて……もし変わったとすれば、きっかけは挫折ですね。特にベンチャーに移った後の挫折です。一人の力では世の中が変わらないんですよ。一人でコードを書いているだけだと、製品はできるんですが、とにかく遅い。

世界を変えるには仲間が必要で、強いチームを作らないと改善スピードが上がっていかないと強く感じました。そしてチームを作って仕事を進めるうちに「組織で動いたほうがいい成果が出るし、いい成果が出るなら強い組織を作ったほうが合理的だ」という考えに変わってきました。いまでも自分がマネージャーに向いているかいないかはよくわからないですが、ただ、そうすべきだからしている、というところが大きいです。

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

おっしゃる通りで、全然できなかった人をリーダーにしたら突然活躍し始めて、自分が関与していないプロジェクトで凄くいいアイデアがいつの間にか実装されていたりして、「こいつらスゴイな」とか「俺の考えた組織配置ハマったな」とか、そうして悦に入ることが結構あります（笑）。そういう時って、本当に自分が何もやっていないから感動するんですよね。そういう感動があるとマネージャーもだんだん楽しくなってくる気がします。

どんな人がマネージャーに向くのか、あるいはマネージャーにはどのようなスキルが必要なのか、お二人のお考えをお聞かせ願えますか。

マネージャーに向いているかどうかというより、とにかくいろいろなことをやってみたらいいんじゃないかと思いますね。僕も別に自分でやりたいと言って始めたわけではなく、「やってみて」と言われて取り組んでみたら意外と成果を出せた。でも、それはやってみなければ起きなかったこと。

だから「絵を描いてみたら意外とうまかった」とか「釣りをしてみたら実は凄くうまかった」とか、そういうのと同じレベルだと思うんです。必ずしも自分自身が選択したものが正しいわけではなく、それが与えられたものであっても、チャレンジしてみると世界が本当に広がると思いますね。

そう。向く人、向かない人はあまりないと思いますね。僕自身も向いていないと思っていましたし……マネジメントのスキルは後天的に身につくもので、必要になればやればいい。私の場合、スタートアップに転職したことで、おのずと自分がプロダクトマネージャーや人事のようなことまでやらなければならなくなり、そこで身につけていきました。

いちばん手っ取り早いのは、同じ立場の人と情報交換することでしょうか。同じようにスタートアップで戦っている人や、大企業でもマネージャーとして戦っている人とコミュニケーションする。業界の最先端の人と情報交換することで、自分がこれまで持っていなかった知見が手に入る。今日のこのイベントもそうですが、やはりこうした場に積極的に顔を出し、情報を集めることが大事だと思いますね。