正明氏エンジニアのキャリアVol.003人材マネジメントをぜひ経験してほしい。そこで得たスキルは必ず大きな価値となる。Vol.002これからのソフトウェアエンジニアは、ヒューマンスキルがなければ生き残れない。Eになれるエンジニア、なれないエンジニア」。刺激的なタイトルですが、まずは開発系のトップであるCTO・VPoEがそれぞれどういうポジションかを理解したうえで、皆さんと一緒に紐解いていけたらと思います。僕は大学卒業後、15年ほどITに携わっています。受託開発の会社からスタートし、はてなにジョインして2009年頃からはてなブックマークの運営等々に携わりました。2010年にマネージャーを経験してみて、やはりエンジニアをやりたいなと思い、クックパッドへ移りました。1年半ほど一エンジニアとして経験後、組織に所属する以上は一個人の力には限界があると感じていた時に、技術部長としての話があり引き受けることにしたんです。そこで10数名のエンジニア組織作りを行いました。その後、ちょうどCTOのポジションが空いたタイミングで、経営視点を持ったエンジニアとして何ができるだろうと興味を持っていたので役員としてCTOに就任。その後、WAmazing代表の加藤と出会いジョインして、現在CTOを務めています。僕は大学時代に松尾豊准教授が所属する工学部システム創世学科でニューラルネットワークなどに携わっていました。起業したい思いがあり、学生時代から会社をつくったりしていてそのまま卒業後も2社の経営は継続しながらも、自分でサービスをつくっていきたいという想いもあり、ヘルスケアが事業領域としてしっくりきたのでFiNCへジョインしました。溝口と出会い、一緒にやりましょうということになりまして。初めはCTO専任として参画し、技術戦略をつくるのがメインの役割でした。昨年、FiNCテクノロジーズの代表に就任してからは、技術をメインに置きつつ、資金調達から事業計画まで経営全般を管掌しています。及川お二人とは実はかなり前からの知り合いなので、エンジニアだった時代もよく知っているのですが、まさか今になってこのような形でお付き合いができるとは(笑)。ここからは一問一答でお二人にお願いします。今でもコードを書いていますか?南野・舘野はい。今、興味がある技術は何ですか?南野ディープラーニングですね。典型的な1日の過ごし方を教えてください。朝の8:00からミーティングをしていて、ランチは外部の人たちと一緒に取ることが多いですね。午後もミーティングが続き、18:00からは会食や社内のイベントが入っていたり、飲みに行ったりします。大体、予定が24:00くらいまで埋まっている感じです。僕は朝の8:00から中国語を学んでいます。曜日ごとに予定を分けていて、水・木はあまり予定を入れず、技術リソースをつくることに集中していますね。自分の時間の使い方ですね。意思決定の確度をどう上げられるかということです。困っているというか、今取り組んでいることとしては、スケールする組織をどうつくっていくか、ボードの運営をどうやっていくかということです。舘野エンジニア採用ですね。宣伝になってしまいますが(笑)及川ありがとうございました。ここからはディスカッションに入っていこうと思います。経営状態を理解して、技術の選定やプロダクトのつくりかたを決めていくのがCTOの役割と考えています。僕も南野さんと同じで、技術を持ったうえでいかに経営をしていくかということかと思います。技術がコアコンピタンスの会社は、CTOがその技術を全面的に引っ張っていくことが大切です。一方で、僕が今いるのは「旅行×IT」という会社なので、旅行事業を理解してどう技術に反映していくかが自分のミッションです。会社によって異なる面はありますが、いずれも経営視点を持って技術をリードしていくという点では共通していると思います。及川お二人のお話からは経営視点という言葉が出てきますが、一方でその視点を持ったエンジニアは少ないと思うんですね。好きなコードだけ書きたいという人も多い。南野さんは学生時代から起業されていたので元々経営志向だったのかもしれませんが、舘野さんは一エンジニアからスタートしたということで、まずは舘野さんに聞いてみたいと思います。いつから経営視点を持つようになったんですか?きっかけは?舘野クックパッド時代に印象的な出来事がありました。技術部長をしていたときに、当時の社長から「もしお前が社長だったら、(技術部長である自分自身に)どう動いて欲しいの?」と聞かれたんです。技術を生かしてどうユーザー価値・事業価値に置き換えていけるのかを考えないといけないということで、視野が広がったのですが、これがきっかけでしたね。僕が経営に興味を持ったのは、祖父が起業家で高校時代から祖父の会社を手伝ったりしている過程からでしたね。経営者って面白いなと思っていて、大学も起業に適したところを選んでいます。ソフトウェアかというと、スケールが小さい段階から活躍できるというところです。言え、最初の頃はあまり深く考えてはいなくて、お客さんにどうバリューを出せるのかとか、1円稼ぐのも大変だなと思っていました。それは今でも大変ですが(笑)。自分の技術をどう価値に換えるのか?ということは大学からずっと考えていました。及川お二人の共通点は、事業への想いがあることだと思います。一般的なエンジニアは、必ずしも事業への熱意が無いことも多い。いう人たちが多少なりとも事業へ興味を持つためのアドバイスはありますか?南野お客様を知ることが一番大切なんじゃないでしょうか。どれだけお客様を喜ばせられるか。自分がもしお客様だったらという目線を持つことかと思います。僕がエンジニアとよく会話するのは、自分が書いているコードの価値がどこにつながるのかを考えてみようということです。社内のスタッフの作業が効率化するとか、ユーザーに違う体験を与えられるとか。何かにつながっている。目標を決める時に、その技術を使うことでどんな価値につながるのかを考えてもらうようにしています。今のお話はとてもいいメッセージですね。次に、お伺いしたいのはVPoEについてです。当社はVPoEを置いています。組織をどう活発化していくかを考えていくというように切り分けています。及川VPoEは南野さんの部下という位置づけですか?南野はい。自分が代表を務めているので、そうなります。技術戦略を描く担当の方もいるのでチームで補完し合いながらやっています。前職ではVPoEがいましたが、現職では絶賛募集中です。一人が両方やっているケースも多いと思いますが、組織が大きくなってくると、組織をどうしていくかを選任でやれる人がいた方がいい。CTOとの役割を分けたほうが良いと思います。僕らは、「お茶会」と呼んでいますが、代表の3人で情報共有する場を週に1度設けています。間違った意思決定がなされないよう、情報を細かく共有していますね。各々がイメージで話してしまいがちなので、ドキュメント化して皆の理解が同じ状態を鮮度高く保てるようにしています。舘野これは個人的な話ですが、1年半周期で僕は飽きがくるので、できる人に権限移譲するようにしています。考え方のズレは1on1で整合性を取りつつ、基本的には現場で決めていいよ、と。経営に大きく影響を与えるところはCTO、という切り分けですか?舘野そうですね。あと、セキュリティは問題が起きると大きいものですが、問題が起きないとあまり重視しない。セキュリティ関連のところは、CTOの役割として持っていたいです。技術的な仕事は何をどこまでやっていますか?参加者の方からの質問にもありますが、技術に触れる時間が短いと、技術選定で不安になりませんか?自分の中でその技術を咀嚼できるレベルにしないといけない。大きい組織の場合は、常に権限移譲できる人を探していたところがあります。自分ひとりが万能でやるのは不可能です。そのため、技術で信頼できるメンバーに権限移譲するというのは意識的にやっていましたね。逆に、CTOだからこそやれることもある。肌感覚を持たないと意思決定できないので、リサーチしながらやっていく。今はエンジニア10名程度の組織で、判断材料が危なそうだなというところは自分で引き取っています。及川リサーチ系のところは多少ペースを落としても経営には影響しませんが、中国事業の方はそうはいかないじゃないですか。最初は僕ともう1名のエンジニアで手を動かしていましたが、ある程度技術がつかめた時点でもう1名に移譲しました。どのタイミングで別の人に渡すかということがポイントですね。僕の場合は、外部の人と一緒にやることを意識しています。色々なCTOネットワークとか、技術に詳しい人リストをつくって日々洗練させていく。「ここ危ないよ」というのも、色々な人から情報収集して精度を上げていくようにしています。確かに、私がFiNCを手伝い始めた当時はエンジニア20名くらいで南野さんも一部手を動かしていましたね。今はエンジニア70名ほどになり、かなり任せているようですが。ところで、事業系の人たちや経営陣はかなり声が大きく圧の強い人たちも多い中で、技術のトップとしてそこに負けずに対峙していくのはどうやっていますか?南野この事業をやる意味ってこうですよね、だったら技術もこうした方がいいと。選択肢を冷静に箇条書きにして、オプションを示して選んでもらうのがいいんじゃないかと思います。舘野ちゃんと説明できるということが大切ですね。事業サイドとしてどうにか早く進めたいんだけどという話が出た時に、短期的にはできるかもしれないけど長期的には破綻するということをしっかり説明すると、大抵の人は納得します。何でこれができないのか、やるべきでないのか、これならできるよという対話をすることを心掛けてきました。技術者は技術が分からない人に説明するのが苦手なところがあり、じゃあやりますよと半分諦めて言ってしまいがちだけれど、それをやると負け。僕の場合は、色々なベンチャーのアドバイザーをしているのですが、通訳としての役割を期待されることも多いですね。技術と経営の橋渡しという役回りです。及川さて、ここで参加者からの質問に戻ります。経営状況を理解したうえで技術を選定すると、必ずしも新しい技術が適切でないこともある。長期的な視点を持つべきだと思います。エンジニアが大事なリソースとなってくる中で、採用とリテンションは最も大事。当社が求める人材と技術選定をしてるかは経営のKPIになる。自分が恥ずかしくない意思決定をするということです。本当にその技術って必要?というのが大事です。新しい技術を採り入れるのかどうかは長期的に考えないといけない。それは短期的にはエンジニアのモチベーションに有効かもしれないけれど、やはり全体最適を見極めながらの意思決定になると思います。古い技術を採り入れ続けることのリスクは確実にありますが、最先端の技術を取り入れたとしても本当に使いこなせるのか、皆に使われ続けるのかという問題もある。本当にその技術が必要かどうか?次第ということですね。育てるというよりも、もともと他社でCTOをやっていた人で、3年ほど一緒に仕事しました。一緒に仕事をすることかなと思います。そのうえで、この人に任せても大丈夫と思えるかどうか。経営陣との相性もあります。ボードからの信頼を得ることも大事です。経営陣ときっちり会話ができるかというのは大事なポイントですね。舘野1つは、僕以外の人にメンターになってもらうことです。自分は1on1をしょっちゅうやっていて、エンジニア同士だと視野が狭くなる。自分以外の社長にメンターしてもらうことで、考えを広げることに役立ちます。1つは、自分自身が経営者になるとしたら経営課題に対してどうするのかというお題を与えて解いてもらうことですね。