エンジニア組織のあり方とは？ 組織を前進させるCTO・VPoEの選択
※本記事は2019年2月26日のCTOイベントをもとにした内容です。
【写真：左から、Sansan CTO 藤倉さん、LIFULL CTO 長沢さん、イベント主催者flexy岡田、3社CTO 白井さん、メルペイ VPoE 木村さん】
2019年2月26日、大人気イベントとなり席枠を拡大して開催されたCTO meetup。「エンジニア組織のあり方～気になる各社の仕組みを公開～」をテーマに、各社のCTO、VPoEがディスカッションを行いました。
エンジニア組織をまとめあげる立場の方たちがどのように意思決定を行うのか、どのような意図をもってさまざまな仕組みを導入しているのか、CTOのミッションとは一体どういうものなのかを紐解く、充実の内容となりました。豪華なご登壇者をお迎えし、成功事例だけではなく、困難な状況や失敗事例などに対する生の声を織り交ぜながらのディスカッションをレポートします。
目次
CTO meetupご登壇者
■パネラー
株式会社LIFULL CTO 長沢 翼 氏
3社(株式会社Craft Egg、株式会社ジークレスト、株式会社サムザップ)CTO 白井 英 氏
株式会社メルペイ 執行役員 VP of Engineering 木村 秀夫 氏
■モデレータ
Sansan株式会社 執行役員 / CTO 藤倉 成太 氏
マトリクス型や子会社制を採用しているエンジニア組織のCTO・VPoE
藤倉：今回ファシリテーターを務めさせていただきます、Sansan株式会社CTOの藤倉です。当社では法人向けに名刺管理サービスを提供しています。本日ご登壇の方々の中では最もBtoB向け色が強いかと思いますが、当社の状況もディスカッションの中でお伝えできればと思います。本日はどうぞよろしくお願いいたします。
【モデレータ、Sansan株式会社 執行役員 / CTO 藤倉 成太さん】
株式会社オージス総研に入社し、ミドルウエア製品の導入コンサルティング業務に従事。赴任先の米国・シリコンバレーで現地ベンチャー企業との共同開発事業に携わる。帰国後は開発ツールやプロセスの技術開発に従事する傍ら、金沢工業大学大学院（現・KIT虎ノ門大学院）で経営やビジネスを学び、同大学院工学研究科知的創造システム専攻を修了。2009年にSansan株式会社へ入社し、クラウド名刺管理サービス「Sansan」の開発に携わった後、開発部長に就任。2016年からはプロダクトマネジャーを兼務。2018年、CTOに就任し、全社の技術戦略を指揮する。
長沢：株式会社LIFULLの長沢と申します。当社はLIFULL HOME’Sという不動産ポータルサイトを運営しています。LIFULLは組織としては事業×職種のマトリクス型を採用しています。事業部制の中で各職種のマネジメントを横軸で行っているという感じです。詳細はこのあとのパネルディスカッションでお話しできればと思いますので、どうぞよろしくお願いいたします。
【ご登壇者】株式会社LIFULL CTO 長沢 翼さん
2008年株式会社LIFULL（当時 株式会社ネクスト）入社 LIFULL HOME’Sの不動産売買の領域のWebエンジニアとして、フロントエンド、サーバーサイドを開発した後、 iOS版 LIFULL HOME’S の立ち上げメンバーとして、iOSアプリ開発の従事 その後、当時、社内ではまだ利用実績のなかった言語を利用して、API基盤の刷新を実施した後、 事業系システムをオンプレミスからAWSへの移行するチームを責任者として牽引した。 2017年4月からCTO就任し、技術の戦略の策定や組織のマネジメントを行う。 情報システム部門の責任者、ベトナムの開発系子会社の委任代表なども務めている。
白井：株式会社サイバーエージェントの白井です。サイバーエージェントはさまざまな事業に取り組んでいますが、私が担当しているのはゲーム・エンターテイメント事業部（SGE）です。10社以上あるゲーム・エンターテイメント事業の子会社のうち、株式会社Craft Egg、株式会社ジークレスト、株式会社サムザップの計3社でCTOを務めています。
【ご登壇者】株式会社サイバーエージェント SGE CTO 白井 英さん
2009年、サイバーエージェントのゲーム系子会社に中途入社し、グループのゲーム運営の基礎を築く。2014年、サイバーエージェントのゲームやエンターテイメント事業に携わる子会社が所属するSGE(Smartphone Games & Entertainment)事業部設立とともに、CTOに就任。2018年10月より、SGEの子会社３社（Craft Egg、ジークレスト、サムザップ）のCTOを務める
組織について簡単に説明すると、まず事業部全体としては子会社制を採用しているのが特色です。子会社自体に裁量権があり、独自に運営していますが、子会社ごとに溜まったノウハウは子会社を超えて事業部全体に展開をして、同じ失敗を繰り返さないようにしたり、成功したものは積極的にほかの子会社も取り入れられるようにしてヒットの確率を上げています。
また、事業部全体を見ているボード組織も存在します。各社に裁量がある一方で、同じ事業に何社もが取り組むことになるので、効率が悪いところは横軸の組織が担ったり、間に入ってお互いの会社がプラスになるように調整をしています。
白井：事業部全体で1200名程度、このうち職種や雇用形態を問わずエンジニアが450名。私が見ている3社に関しては最も大きな子会社が200名規模で、エンジニアは50名ほどです。今回は規模感も交えてお話しができればと思いますので、どうぞよろしくお願いします。
木村：株式会社メルペイのVP of Engineeringを務めております、木村です。みなさんはメルカリをご存知だと思いますが、メルペイはその100％子会社です。いわゆるFin Tech事業を行っていて、「信用を創造して、なめらかな社会を創る」をミッション・ステートメントとして掲げています。
【ご登壇者】株式会社メルペイ VP of Engineering 木村秀夫さん
ISPでエンジニアとしてのキャリアをスタートさせ、独立起業や通信キャリア等での開発業務を経て、2009年DeNA入社。Mobageオープンプラットフォームの立ち上げ、グローバル展開、Mobage全体のマネジメントに従事。2013年に執行役員に就任。その後もオートモーティブ新規事業立ち上げ、システム&デザイン本部長を経て、2018年5月、株式会社メルペイ執行役員 VP of Engineering に就任。
メルペイはメルカリのお財布部分のサービスで、メルカリでみなさんがモノを売ったお金をメルカリ内だけではなく、全国のお店で使えるようにしています。例えばiDのような決済手段を提供します。銀行からメルペイの口座に入金して利用することもできます。組織はLIFULLさんと同じくマトリクス型で、エンジニアリング組織とプロダクト組織に分かれているのが特徴です。プロジェクトごとにプロダクトマネージャーが配置されており、エンジニアは私が全員管理しています。エンジニア組織は職能ごとに別れていて、各プロジェクトにアサインする形で運用中です。
業種業態ごとのエンジニア組織課題・経営課題
プロジェクト予算、エンジニアの人件費。果たしてどう意思決定するのか？
藤倉：ではここからパネルディスカッションを開始します。まずはみなさんの会社全体とエンジニア組織の規模について改めて確認させてください。
長沢：グループ全体は1200名程度で、本社のある日本には800名ほど在籍しています。そのうちエンジニアは正社員が約150名、業務委託を含めると全体で200名ほどです。
白井：私が見ている3社に限って言えば合計すると400名規模。エンジニアは100名程度ですね。
木村：メルペイは営業の子会社なども含めると全体が300名ちょっと。エンジニアは100名ほどです。
藤倉：前半は開発組織を社内に持つ会社のCTOないしVPoEの人たちが、経営目線でどのように予算を見ているのか、どのように意思決定しているのか、社長決裁が必要な場合にどのような準備をするのかなどを伺っていきたいと思います。
そもそもプロジェクトや開発予算をどのようなロジックで取りに行っているのでしょうか？
白井：取りには行っていませんが、ゲーム事業はやはり「こういうゲームを作りたい」というアイデアが先にあって、プロデューサーにあたる人がある程度の予算規模を決めることでプロジェクトを生み出していきます。エンジニア主導というよりは、企画職にあたる人が予算取りを行います。
藤倉：運用は別として、開発予算は基本的に社内エンジニアの人件費そのものです。取る、取らないというよりは、人件費を使って何をするのか、という理論になると思うのですが、各社ではいかがですか？
木村：メルペイの場合はまだプロダクトの立ち上げ期なので、いわゆる投資フェーズにあります。そのためコストも今はあまり細かくは言われていません。
長沢：うちの場合は事業の売上や利益を達成できるようなリターンを描けるかどうかが鍵です。もちろん短期的なものだけではないので、中長期を意識したリターンを描くことができれば、という感じですね。
藤倉：白井さんは企画職やディレクターの方がプロジェクトを発足するというお話でしたが、どんなプロジェクトをどのくらいの開発リソースをかけて進めるのかということは、誰が意思決定するのでしょうか？白井さん以外の方にも聞いていきたいと思います。
白井：企画のメンバーがプロジェクトを提案する際は月ごとの売上計画を立て、それを目指すために必要な予算も決定します。それを子会社内の役員会で通し、社長決裁を取ります。本当にその企画メンバーに任せて大丈夫なのか、きちんとエンジニアをアサインできるのかなどが焦点になります。よって、プロジェクトの内容によってはタイミングをずらすというケースもありますね。
木村：メルペイがマトリクス組織を採用している意図の一つが、エンジニアリングマネージャーに裁量をもたせることです。エンジニアリングマネージャーなら、プロジェクトに対してどんな人材が必要なのか、どんなコストがかかるのかを見積もることができます。エンジニアとしての差配をプロジェクトに組み込むことで、納期や予算が変な形でロックされてしまわないようにしたいという思いがあるのです。
長沢：プロジェクトの決裁に関してはまず金額と技術選定を決定します。金額基準によって会議体や決裁者の範囲を決めています。技術選定自体も各事業で運用含めて責任が取れればそれでよく、クラウドサービスを利用し、マイクロサービスの方針で進めているというのもあり、各技術チームに任せています。会社全体の技術方針は大枠を定めているので、そこから外れていないかどうかを確認していますね。
技術力を停滞させない。CTOやVPoEが牽引すべき技術選定の方向性
藤倉：長沢さんが言及された技術選定について言えるのは、「慣れた技術を選べば絶対にうまくいくだろう」ということです。新しい技術が必要なケースもありますが、既存のものでやろうと思えばできることも多い。しかし、我々は新しい技術にもトライしていかなければなりません。
そういった視点を含めて、だれがどの技術を選ぶことを決定しているのか、さらにCTOやVPoEの立場でどのようにジャッジするのか、お話しいただければと思います。
白井：プロジェクトのエンジニアリーダーの判断に任せています。リーダーに誰を据えるのかを決めたらプロジェクトをどう進めていくのか、インフラはどうするのか、GCPなのかAWSなのかまで含めて一緒に話しながら決めてもらいます。リーダーも責任を持ってやってくれるのでそれが一番だと思っていますが、あまりに突飛な技術を選ぶとメンバーがついていけなくなってしまうので、必要があれば指摘をしますね。
木村：メルカリがPHPのモノリシックでサービスを作ったのに対して、メルペイは最初からマイクロサービスのアーキテクチャで作っています。これは、各マイクロサービスに応じて技術選定ができるという利点を活かしたかったからです。選定は運用責任が取れるかどうかが条件になっていますね。ただし、スピードを引き換えにしなければならない部分はあるので、サービス立ち上げ期で採用も行いながらという状況下では、技術選定は空気を読みつつになっているのかなと思います。
長沢：LIFULLは数年前までは短期的な効率を追い求めていて、環境はオンプレミスだったため、リソースの効率化を求める文脈でも言語やフレームワーク、OSは固定していました。あるタイミングから、APIの機能は分離していって、サーバーサイドのエンジニアはAPIを呼ぶだけでサイトを作れる状態にしました。データベースの構造や検索エンジンについてほとんど知識がなくてもAPIを呼べば主要な機能をサイトにすぐ実装することができたので、短期的に見ればすごく効率が良かったです。
ただ、そのまま3年ほど経過したときに、誰も新しい技術に対応できない状態になってしまいました。ユーザーや社内からの機能のリクエストに対して応えることはできても、サービス全体に新しい技術を用いて飛躍させるといったことには手を打てないし、問題にぶつかったときも、技術としての選択肢が少なくなくなっていってしまったのです。
このままじゃいけない、ということで、そこから当社は新しい言語を導入したり、インフラを刷新していったり、クラウド化→マイクロサービス化という流れをたどっていくこととなりました。
長沢：マイクロサービスは各チームでオーバーラップしてしまう部分が出てきますが、一定は許容していました。合理的ではないのかもしれませんが、スピード感を持って分散していくのならそれしかないだろうと判断しました。現在はオーバーラップが気になる部分が大きくなってきたので、一部だけは統一しよう、という動きも出てきています。
ある意味そういった連続的な変化に対して転換を起こすのが技術戦略ですし、その方針を決めるのがCTOや組織の上層部だと思っています。実際に推進していくのは現場のエンジニアということも踏まえて、仮に非効率的ではあっても長期的に取り組むための判断ができるように意識しています。
白井：モノリシックなシステムからマイクロサービスに移行する最初のステップがあったと思うのですが、それは長沢さんが号令をかけたのでしょうか？
長沢：そうですね。当時私がマネジメントをしていた移行チームが技術の方針を決めていました。モノリシックで開発を進めた結果、システム規模が肥大化するにつれてどこを触っても影響範囲が大きくなってしまい、時間がかかるという状況になってしまいました。当社は不動産系のサービスなので、引越しシーズンである年明けから4月までが繁忙期です。
そこに向けてサーバーを準備していた時期に、ここをクラウドに移行したら効率的なのではという話が出てクラウド移行していくことになったのですが、それにあたって、アカウント管理やサーバー分けをどう行っていくのかと試行錯誤していく中で、やはりサービスを小さく分割（≒マイクロサービス化）したほうがシステムの影響範囲を小さくでき、スピードを上げていけるのではないか、と結論づけて始まりました。
白井：方向転換に関して、組織としての納得感は自然とあったのでしょうか？
長沢：意図を含め説明もしたところ、自然と受け入れてくれましたね。アプリケーションエンジニアも今まで触ってなかったインフラから触ること担ったんですが、それに対しても、ほとんどのエンジニアが前向きに取り組んでくれました。
木村：変えるというのは重要ですよね。技術選択は普通にすればいいのですが、マイクロサービスも、放っておくとマイクロサービス一つひとつがレガシー化してしまう。「技術選択し続けること」が大切で、それができる文化や環境、組織を作っていくのが私たちの役割なのではと思います。
長沢：そこに関しては私も気を使っています。当社は事業会社なので、事業に貢献したいという想いが強くそのためには技術だけではなくいろいろな手を尽くすという、エンジニアが多いです。当然、それ自体は素晴らしいことです。ただ、一方で、少し気を抜くと技術面がおざなりになってしまいます。エンジニアだからこそ技術で創造できるような価値や世界を作っていかなければなりません。
そこで当社では「エンジニアとして経営をリードする」という言葉を掲げ、4つのルールに従って変化し続けようという文化を浸透させようとしています。四半期に一度エンジニア全員を集めて事例や抱負を語ってもらうという取り組みも、3年ほど継続していますね。
白井：ゲーム事業において、エンジニアはエンジニアリングも経営もすごく好きです。事業目線の強いエンジニアが多いというのでしょうか。するとやはり同じ技術を使い続けてしまう傾向があり、新しい技術を取り込む力は相対的に弱くなってしまいます。停滞しない文化づくりや、効率的な方法があるはずだと問い続ける取り組みは、CTOの役割なのだと思います。
木村：その視点で言えば、メルカリとメルペイは「テックカンパニーになろう」と標榜しています。テックカンパニーは定義が難しいのですが、一つはテックドリブンによって事業を生み出すということが挙げられます。あるいはテックドリブンによって事業を変革する、コストカットをするということですね。それはエンジニアにしかできないことです。
一定範囲での業務委託や、専門性の高い外部人材は積極的に採用する
藤倉：外部委託の方の活用方法についても触れたいと思います。私個人の答えとしては、外部にも業務に協力いただける優秀な方が大勢いるので、マッチングすればジョインしてもらい、社員と同じように動いていただきたいですね。ルール上、本番のデータベースに入ることはできませんが、社内の教育制度などは使っていただいて構いませんし、同じチームの一員として切磋琢磨したいと思っています。外部委託の方が正社員採用よりも早く入っていただけるので、そういう意味では両方に力を入れているというのが当社のスタンスなのですが、みなさんはいかがでしょうか。
木村：メルカリは業務委託をしないという方針でしたが、メルペイは私の参画を期に利用する方向へ転換しました。ただし、いずれは使われなくなるであろう技術やとQAのような繁閑の波がある部分と範囲を明確に決めています。
長沢：いくつかパターンはありますが、ポイントで人が必要になったときに業務委託することはありますね。また、昨年の10月にAI戦略室を立ち上げたのですが、専門性が高い人材が必要になる一方、社内ではすぐに対応できるメンバーがいないといったケースに、顧問のような形でに参画いただくようなこともあります。
白井：当社もみなさんと同じような感じです。優秀な方も多いので、同じチームで協働してもらいます。外部委託の方だからと業務に制限はかけていないのですが、セキュリティやリスクヘッジの面で本番環境への権限を制限しているのがリアルなところです。
【写真左から、Sansan株式会社 執行役員 / CTO 藤倉成太さん、株式会社LIFULL CTO 長沢翼さん】
質疑応答
技術的負債を可視化することで、継続性のある組織づくりを行う
藤倉：ではここからは質疑応答に入りたいと思います。いただいているもので多いのは技術選定に関してですね。分不相応な技術選定に対してCTOがどう向き合うべきか。技術的負債を返していくときにどう説明するのかなど、みなさんご意見ありますでしょうか。
長沢：技術的負債に関しては「属人化させずに説明すること」を意識しています。特定の誰かがいるから、うまく説明ができて負債返済に取り組める、という状態では、技術的に大きな課題に対して属人的すぎると思うんですよね。特定の人がいなくなったら負債について進言されず、全く返済されない状態になってしまうのは、良くないと思うんです。
人に依らず信頼感を持って技術を説明できる仕組みを残す必要があります。そういう意味で、半年ほど前から現状を可視化するための取り組みを始めました。コードの複雑性を算出したり、サーバーの脆弱性なども目に見えるようにします。
そのほかにも人の開発や調査にかかる時間、障害の頻度などの数字を複合的に見ながら、こうすれば調査の工数を減らせる、障害の数を何年前の時点にまで戻せるといった技術負債の返済方法を提示できるようにしようと取り組んでいます。
白井：なかなか難しい問題です。現在運用中のプロダクトの場合、大きなきっかけがない限りしっかりと期間を設けてシステムを直すといったことができません。わかりやすい例で言うと、ゲームはUnityで作ることがあるのですが、リリース時は問題がなくとも、運用を続けていくとバージョンアップしなければならないタイミングが出てきます。しかし運用中は大掛かりに期間を取ることができないので、よく手を入れるところを少しずつ良くする、という負債の返し方になっていますね。
【写真左から、3社(株式会社Craft Egg、株式会社ジークレスト、株式会社サムザップ)CTO 白井英さん、株式会社メルペイ 執行役員 VP of Engineering 木村秀夫さん】
アサインのミスマッチに対しては厳しい選択も迫られる
藤倉：次の質問です。「CTOを任されたものの、蓋を開けてみたら、そもそもエンジニアに全くスキルが無いことがわかった。どうしたらいいですか」ということです。特殊な状況ですが、何かアドバイスはありますか？
白井：過去に似たようなことがありました。あるプロジェクトがピンチだから見てくれと言われて参画したら、質問者さんと同じ状況だったんです。ドライですが、スキルの低いメンバーは外し、優秀なメンバーを入れるという対応を取りましたね。
長沢：もちろん、スキルや能力上、実現すべきことを実現できない状況もあります。観察していると、スキルの問題というより、タスク管理やコミュニケーションが上手くいっていないことも多いんです。そのようなときはマネージャーにも協力してもらい、マイクロマネジメントをしてもらうようにしました。
木村：メンバーのアサインがミスマッチだったという話であれば、もうアサインを変えてあげるしかありません。一定の組織はやはり事業の規模やフェーズによって新陳代謝が必要ですし、そういった厳しいコミュニケーションができるかどうかも、マネージャーの素養の一つなのではないでしょうか。
エンジニア組織の成長についてのディスカッション
リファラル採用が活発な企業の文化や仕組みと、加速しない企業の特徴
藤倉：ここからは、採用・評価・育成をテーマにディスカッションしていきたいと思います。ここにいらっしゃるのは、苦労を苦労と思わない、苦境に立たされても成功を導き出せる強みをお持ちの方々だと思いますが、成功事例を聞いて終わってしまいそうだという懸念もありますので、いかにして困難を乗り越えてきたのか、ないしは困難を乗り越えられなかったといったお話も含めてディスカッションいただければと思います。
まずは採用について、いかがでしょうか。
木村：前職に比べてメルペイに入ってみて知ったのはリファラルを行うなど、工夫の仕方はあまり前職と変わりないんです。ただ、リファラルを社員全員で行うという点は大きく違いましたね。インセンティブはありますがそれも前職と大差ありませんから、会社をメンバーと一緒に大きくしていくという意識が若干メルペイの方が強い気がします。
採用コストもかけています。エンジニア自らイベントやセミナーに登壇して話したりするという機会が一週間のうちにも結構な頻度でありますし、当然そのファシリテーションも大変ですから、業務にも影響します。リリースが近づいている時期はギアを落として調整をしなければなりませんが、工夫は無い分、「とにかくがんばっている」という印象です。
もう一つは、やはりサービスが当たるというのが重要ですね。前職もサービスがヒットしていたときは放っておいても優秀なエンジニアがたくさん来てくれた。しかし、陰りが見えると去ってしまう人が多くなるフェーズがありましたし、その後新しい事業にチャレンジしたらまた人が入ってきたりと、何を誰と作っているのかに大きく左右されます。
白井：サイバーエージェントの場合、新卒は全社で一括採用した後、各事業部に配属しています。中途採用は各子会社が行うので、それぞれが戦略を立てて採用をしています。新卒採用に関してはエンジニアが採用の現場に赴いて学生と話をするなど、採用協力が活発です。難点は、ゲーム事業はゲームを作りたい人が多いので、サーバーサイドのエンジニアがあまり来ないことです。大規模アクセスをさばく技術だったり、いつでもスケールできる設計だったりに向き合うのが魅力の一つなのですが、なかなか伝えることができていません。
長沢：中途採用にはなかなか苦労してますね。認知度アップのために発信を広げてはいますが、やはり売り手市場なこともありなかなか思ったように仲間が集まらないこともあります。木村さんにお伺いしたいのですが、社員全員がリファラルすることについて、紹介したことによるインセンティブ以外に、会社をグロースさせていくことに対するインセンティブはあるのでしょうか？
木村：ありません。本当に一般的な制度なので、他の会社と変わらないと思います。
長沢：では、前職と比べてリファラルに対するモチベーションの持ち方の違いの要因として大きいのはどこなのでしょうか？
木村：Meetupの回数と、そこに参加するエンジニアの人数は圧倒的に多いですね。協力的な文化が根付いています。強いて言えば会社の目標設定時にOKRを組み込むことで、会社をグロースさせていくことへの意識を高めるようにしています。
藤倉：LIFULLさんの場合、人々のライフサイクルに寄り添ったサービスを持っていますから、新卒に限らず中途の方も会社組織やプロダクトが好きで入社するのではと思います。その傾向とリファラルが加速しない部分は、関係があるのでしょうか？
長沢：みんな、「あらゆるLIFEを、FULLに。」というビジョンを大事にして人々の生活を豊かにしていきたいという思いで入社しているので、リファラル採用で紹介できる母数が少なくなってしまうのかもしれません。
藤倉：私が所属するSansanという会社自体は、エンジニアから見た会社の認知度は低いんです。BtoBのプロダクトは日常生活の中でタッチポイントが一切持てないので、当たり前ではあるのですが、認知度が高い会社に比べてビハインドしてしまう分、どうしても苦労しますね。その点はやはりみなさんがおっしゃってるようにとにかく頑張る部分ですし、リファラルも行います。
もちろん、事業が確実に伸びているという事実もいい人材を集めるには絶対に必要ですが、働く環境と評価できる仕組みをきちんと作って、事業に貢献した人には経済的なフィードバックするといったことも必要なことかもしれません。
定量・定性・キャリブレーション評価の納得感を高めるたった一つの要素とは
藤倉：ここからはエンジニアの評価・育成の話をしていきたいと思います。各社ともエンジニアの人数は少なくありませんので、CTOやVPoEがエンジニア全員を見るのはほぼ不可能な規模です。評価に関して恐らく年間2～3回のアセスメントタームを持っているのではと思いますが、実際にどのような仕組みでエンジニアを評価しているのか、簡単にご紹介いただければと思います。
【ファシリテーター】 Sansan株式会社 執行役員/ CTO 藤倉成太さん
長沢：LIFULLはエンジニア150名に対して、エンジニアマネージャーが12～13名ほど存在します。各マネージャーが10～15名の範囲でエンジニアを見ていて、評価は年2回。その間に中間面談を挟み、事業経営を見ているマネージャーと一緒に評価を行います。エンジニアマネージャーはスキル評価と育成のサポートを行う形ですね。メンバーとの関わり方は、各エンジニアマネージャーの裁量に任せています。
白井：プロジェクトごとにエンジニアが動いていることが多いため、それぞれのプロジェクトが評価の裁量を持っています。基本的にはプロジェクトのエンジニアリーダーがメンバーを評価して、その評価をさらに上のマネージャーや私が会社全体のバランスを見ながら調整するピラミッド型です。ただ決裁者は子会社の社長なので、私が出した評価にさらに調整が入ることもあります。
普段のコミュニケーションとしては、期初に事業成果と個人成果の目線で目標設定してもらい、それに対する達成度を期末に評価します。その間は毎月1on1を行い、きちんと目標に向かって走れているかを都度確認します。プロジェクトの状況に合わせて、目標を都度調整することもあります。
木村：今メルペイでトライしているのは、テックOKRです。これはプロジェクトサイドのOKRに対して、エンジニアとして何を目標とするのかを設定するものです。個人の成長かもしれませんし、技術負債の返済かもしれないし、新しいチャレンジかもしれない。それをクォーターごとに設定しています。プロジェクトにアサインされているエンジニアには、プロジェクトのOKRとテックOKR、それぞれの目標を立ててもらうことになります。
あとはキャリブレーションという客観評価を行います。私たちの会社の規模ではCTOやVPoEがメンバー一人ひとりを見られないという話がありましたが、当社の場合基本的にはエンジニアについているマネージャーが評価をしつつも、クォーターごとの全員の評価を経営陣含めたマネージャー陣でキャリブレーションという形で客観評価を行っています。二週間ほどキャリブレーション漬けの毎日になってしまいますが、事業への貢献や本人の成長も含めて、一人ひとりをフラットに評価できるのが利点です。
藤倉：気になるのは労力の評価です。チームプレイである以上、一番難しい花形の部分に貢献した人が評価されるということはあると思いますが、一方で誰も好んではやらないような作業を片付けてくれる人も評価されるべきです。そのあたりはみなさんどうされているのでしょうか？
長沢：LIFULLではテクニカルな評価と業績への貢献を明確に分けています。技術的に難しい部分を満たせば事業が伸びることは往々にしてありますが、業績貢献は単純にいかに業績に貢献したかを評価するので、様々な方法でチームを助け、事業に貢献する成果を出すことができていれば評価されます。
テクニカルスキルに関しては細かくマトリクスを作成していて、プログラミングにおける能力、インフラにおける能力などをスキルベースで一覧にしてあります。それらの成長が売上などの短期で見ていく直接的な数字結びついていなかったとしても、テクニカルスキルとしては一定の評価をするというわけです。
木村：貢献度や成長度を日々の1on1や業務の中で見るのがマネジメントだと思っています。ただ、マネージャーの質によってどうしてもぶれが出てきてしまうので、それを平たくするのがキャリブレーションという認識ですね。あまり定量評価にはこだわっていません。
白井：現在の評価はマネージャーに依存してしまっている部分があるので、グループ全体として評価制度を見直すタイミングではという話が持ち上がっています。目立たないけれどきちんと事業貢献しているメンバーを評価するにはどうしたらいいのかといったこともそうですし、子会社制であるがゆえに、「隣の会社に在籍した方が評価されるのではないか？」と思われることがあり、そういう意味でも評価基準を明文化すべきだという流れになっています。
藤倉：エンジニアの評価軸はいくつかありますが、定量評価は非常に難しい。ですから真髄になるのは、納得感と成長度合いだと思います。優秀なマネージャーには、納得感を醸造できる方が多いという印象があります。ある程度は仕組みでケアできるからこそ、みなさん仕組みづくりに腐心されていて、マネージャーの育成も行っているということになるのではないでしょうか。
私もかつて開発部門の部長として100人程度のエンジニアを全員フラットに見ていた時期があります。感覚としては、お互い人間なので、信頼感さえあれば大部分がうまくいく印象ですね。
木村：それはかなり重要だと思います。メルカリグループでは1マネージャーあたりマネジメント規模は8名以下に抑えるようにしています。私は今30名ほど見ているので、社内でもことあるごとに批判されてしまうのですが、それはきちんとメンバーと向き合うために仕組みを運用すべきだということだと思うので、今まさに私自身のマネジメント規模を減らすように権限委譲などを行う努力しています。評価そのものも定性であれ定量であれ仕組みで解決できないかどうかを、現在模索中です。
長沢：メンバーに「この人は自分のキャリアや育成についてすごく考えてくれている」とわかってもらえれば、信頼感は築けると思います。評価は育成のための重要なツールでもあるので、工数がかかったとしてもある程度仕方ないものですね。
白井：評価者やマネージャーを育成することも大事ですが、それをできるエンジニアは極少数です。コードは書きたいが人のマネジメントはしたくないという人が大半なので、組織のあり方を考えたときにマネジメント目線の人をどう増やすのか模索したいと思っています。
各社が掲げるミッションによって異なる、到達すべき理想のエンジニア像
藤倉：育成の部分にあまり言及できませんでしたが、前半よりも生の声を引き出せたのではと思います。最後にCTO、VPoEとして今現在ご自身が見ている組織をどうしていきたいと思っているのかを語っていただけますでしょうか。
長沢：LIFULLはやはりメンバー全員がビジョンに共感しているのが大前提です。その中でLIFULLのエンジニアは、エンジニアだからこそできる提案をしたり、最初にあった企画や想像以上の価値を創出することで、人々の暮らしをより良いものにできると信じています。自分たちがアイデアを発信し、なおかつ変化し続けることで、人々の暮らしの本質的な部分を追い求めていくエンジニア集団になっていきたいと思っています。
白井：ゲームはクリアするとエンドロールが流れますが、そこにプログラマーの名前が載ります。それを見たときに涙して、自分の仕事に誇りを持てるような組織にしたいですね。ゲーム会社としては、自分がこのゲームを作ったのだと胸を張れる状態が理想だと思いますから。
木村：メルペイは「信用を創造して、なめらかな社会を創る」という少しふわっとしたミッションを掲げていますが、それを具現化できるエンジニアを育てていきたいですね。組織を通じてエンジニア一人ひとりが成長することで、1+1を3にできるような組織が理想です。
藤倉：ありがとうございます。当たり前ですが、みなさんは組織の長としてその会社のミッションに一番共感していて、誰よりも体現したいと思っている立場です。それだけの熱意を持っているからこそ、困難があってもナチュラルにクリアできるのではと感じました。
ではディスカッションは以上で終了します。ありがとうございました。
（FLEXYのfをモチーフにした、FLEXYポーズをやっていただきました。貴重なお話、有り難うございました！）
CTO関連記事のご紹介
ここからはCTO・VPoE関連の記事をご紹介します。
スタートアップ企業がサービス成長させる方法
スタートアップ企業が外部からVPoEを迎え入れるメリットや具体的な業務内容について語っていただきました。
コロナ時代のエンジニア組織戦略
こちらのmeetupでは、CTOとVPoEがコロナ時代のエンジニア組織戦略について語っています。
まとめ
参加者の応募が220名以上を記録し、枠を増席したものの会場の関係で当日も100名以上のキャンセル待ちとなる大人気のCTO meet upとなりました。注目の集まるCTOが語ってくださったエンジニア組織やマネージメント手法、直接ご本人から勉強できる貴重な会となりました。
多数のCTOやVPoE、エンジニア、経営者の方々にお集まりいただきましたが、ご来場いただけなかった皆様にも本記事がお手元に届けば幸いです！
■FLEXYのご紹介
FLEXYは、エンジニア、技術顧問、CTO、デザイナーの方向けに案件をご紹介するサービスです。
リモートワークや週1-5日、高単価案件など、ご希望に合った案件をご紹介いたしますので、是非お気軽にご相談ください。
