エンジニア組織のあり方(前編)~気になる各社の仕組みを公開。組織を常に前進させるCTO・VPoEの選択~

(写真:左から、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向け色が強いかと思いますが、当社の状況もディスカッションの中でお伝えできればと思います。本日はどうぞよろしくお願いいたします。

CTOmeetupエンジニア組織のあり方 【モデレータ、Sansan株式会社 執行役員 / CTO 藤倉 成太さん】

長沢:株式会社LIFULLの長沢と申します。当社はLIFULL HOME’Sという不動産ポータルサイトを運営しています。LIFULLは組織としては事業×職種のマトリクス型を採用しています。事業部制の中で各職種のマネジメントを横軸で行っているという感じです。詳細はこのあとのパネルディスカッションでお話しできればと思いますので、どうぞよろしくお願いいたします。

LIFULLエンジニア組織図

白井:株式会社サイバーエージェントの白井です。サイバーエージェントはさまざまな事業に取り組んでいますが、私が担当しているのはゲーム・エンターテイメント事業部(SGE)です。10社以上あるゲーム・エンターテイメント事業の子会社のうち、株式会社Craft Egg、株式会社ジークレスト、株式会社サムザップの計3社でCTOを務めています。
組織について簡単に説明すると、まず事業部全体としては子会社制を採用しているのが特色です。子会社自体に裁量権があり、独自に運営していますが、子会社ごとに溜まったノウハウは子会社を超えて事業部全体に展開をして、同じ失敗を繰り返さないようにしたり、成功したものは積極的にほかの子会社も取り入れられるようにしてヒットの確率を上げています。
また、事業部全体を見ているボード組織も存在します。各社に裁量がある一方で、同じ事業に何社もが取り組むことになるので、効率が悪いところは横軸の組織が担ったり、間に入ってお互いの会社がプラスになるように調整をしています。

サイバーエージェント組織図

白井:事業部全体で1200名程度、このうち職種や雇用形態を問わずエンジニアが450名。私が見ている3社に関しては最も大きな子会社が200名規模で、エンジニアは50名ほどです。今回は規模感も交えてお話しができればと思いますので、どうぞよろしくお願いします。

木村:株式会社メルペイのVP of Engineeringを務めております、木村です。みなさんはメルカリをご存知だと思いますが、メルペイはその100%子会社です。いわゆるFin Tech事業を行っていて、「信用を創造して、なめらかな社会を創る」をミッション・ステートメントとして掲げています。
メルペイはメルカリのお財布部分のサービスで、メルカリでみなさんがモノを売ったお金をメルカリ内だけではなく、全国のお店で使えるようにしています。例えばiDのような決済手段を提供します。銀行からメルペイの口座に入金して利用することもできます。
組織はLIFULLさんと同じくマトリクス型で、エンジニアリング組織とプロダクト組織に分かれているのが特徴です。プロジェクトごとにプロダクトマネージャーが配置されており、エンジニアは私が全員管理しています。エンジニア組織は職能ごとに別れていて、各プロジェクトにアサインする形で運用中です。

CTOmeetupメルペイ組織図

業種業態ごとの組織課題・経営課題

プロジェクト予算、エンジニアの人件費。果たしてどう意思決定するのか?

藤倉:ではここからパネルディスカッションを開始します。まずはみなさんの会社全体とエンジニア組織の規模について改めて確認させてください。

長沢:グループ全体は1200名程度で、本社のある日本には800名ほど在籍しています。そのうちエンジニアは正社員が約150名、業務委託を含めると全体で200名ほどです。

白井:私が見ている3社に限って言えば合計すると400名規模。エンジニアは100名程度ですね。

木村:メルペイは営業の子会社なども含めると全体が300名ちょっと。エンジニアは100名ほどです。

藤倉:前半は開発組織を社内に持つ会社のCTOないしVPoEの人たちが、経営目線でどのように予算を見ているのか、どのように意思決定しているのか、社長決裁が必要な場合にどのような準備をするのかなどを伺っていきたいと思います。
そもそもプロジェクトや開発予算をどのようなロジックで取りに行っているのでしょうか?

白井:取りには行っていませんが、ゲーム事業はやはり「こういうゲームを作りたい」というアイデアが先にあって、プロデューサーにあたる人がある程度の予算規模を決めることでプロジェクトを生み出していきます。エンジニア主導というよりは、企画職にあたる人が予算取りを行います。

CTOmeetupIT戦略予算取り

藤倉:運用は別として、開発予算は基本的に社内エンジニアの人件費そのものです。取る、取らないというよりは、人件費を使って何をするのか、という理論になると思うのですが、各社ではいかがですか?

木村:メルペイの場合はまだプロダクトの立ち上げ期なので、いわゆる投資フェーズにあります。そのためコストも今はあまり細かくは言われていません。

長沢:うちの場合は事業の売上や利益を達成できるようなリターンを描けるかどうかが鍵です。もちろん短期的なものだけではないので、中長期を意識したリターンを描くことができれば、という感じですね。

藤倉:白井さんは企画職やディレクターの方がプロジェクトを発足するというお話でしたが、どんなプロジェクトをどのくらいの開発リソースをかけて進めるのかということは、誰が意思決定するのでしょうか?白井さん以外の方にも聞いていきたいと思います。

白井:企画のメンバーがプロジェクトを提案する際は月ごとの売上計画を立て、それを目指すために必要な予算も決定します。それを子会社内の役員会で通し、社長決裁を取ります。本当にその企画メンバーに任せて大丈夫なのか、きちんとエンジニアをアサインできるのかなどが焦点になります。よって、プロジェクトの内容によってはタイミングをずらすというケースもありますね。

木村:メルペイがマトリクス組織を採用している意図の一つが、エンジニアリングマネージャーに裁量をもたせることです。エンジニアリングマネージャーなら、プロジェクトに対してどんな人材が必要なのか、どんなコストがかかるのかを見積もることができます。エンジニアとしての差配をプロジェクトに組み込むことで、納期や予算が変な形でロックされてしまわないようにしたいという思いがあるのです。

長沢:プロジェクトの決裁に関してはまず金額と技術選定を決定します。金額基準によって会議体や決裁者の範囲を決めています。技術選定自体も各事業で運用含めて責任が取れればそれでよく、クラウドサービスを利用し、マイクロサービスの方針で進めているというのもあり、各技術チームに任せています。会社全体の技術方針は大枠を定めているので、そこから外れていないかどうかを確認していますね。

CTOmeetupエンジニア組織

技術力を停滞させない。CTOやVPoEが牽引すべき技術選定の方向性

藤倉:長沢さんが言及された技術選定について言えるのは、「慣れた技術を選べば絶対にうまくいくだろう」ということです。新しい技術が必要なケースもありますが、既存のものでやろうと思えばできることも多い。しかし、我々は新しい技術にもトライしていかなければなりません。
そういった視点を含めて、だれがどの技術を選ぶことを決定しているのか、さらにCTOやVPoEの立場でどのようにジャッジするのか、お話しいただければと思います。

白井:プロジェクトのエンジニアリーダーの判断に任せています。リーダーに誰を据えるのかを決めたらプロジェクトをどう進めていくのか、インフラはどうするのか、GCPなのかAWSなのかまで含めて一緒に話しながら決めてもらいます。リーダーも責任を持ってやってくれるのでそれが一番だと思っていますが、あまりに突飛な技術を選ぶとメンバーがついていけなくなってしまうので、必要があれば指摘をしますね。

木村:メルカリがPHPのモノリシックでサービスを作ったのに対して、メルペイは最初からマイクロサービスのアーキテクチャで作っています。これは、各マイクロサービスに応じて技術選定ができるという利点を活かしたかったからです。選定は運用責任が取れるかどうかが条件になっていますね。
ただし、スピードを引き換えにしなければならない部分はあるので、サービス立ち上げ期で採用も行いながらという状況下では、技術選定は空気を読みつつになっているのかなと思います。

長沢:LIFULLは数年前までは短期的な効率を追い求めていて、環境はオンプレミスだったため、リソースの効率化を求める文脈でも言語やフレームワーク、OSは固定していました。あるタイミングから、APIの機能は分離していって、サーバーサイドのエンジニアはAPIを呼ぶだけでサイトを作れる状態にしました。データベースの構造や検索エンジンについてほとんど知識がなくてもAPIを呼べば主要な機能をサイトにすぐ実装することができたので、短期的に見ればすごく効率が良かったです。ただ、そのまま3年ほど経過したときに、誰も新しい技術に対応できない状態になってしまいました。ユーザーや社内からの機能のリクエストに対して応えることはできても、サービス全体に新しい技術を用いて飛躍させるといったことには手を打てないし、問題にぶつかったときも、技術としての選択肢が少なくなくなっていってしまったのです。
このままじゃいけない、ということで、そこから当社は新しい言語を導入したり、インフラを刷新していったり、クラウド化→マイクロサービス化という流れをたどっていくこととなりました。 LIFULLマイクロサービス

長沢:マイクロサービスは各チームでオーバーラップしてしまう部分が出てきますが、一定は許容していました。合理的ではないのかもしれませんが、スピード感を持って分散していくのならそれしかないだろうと判断しました。現在はオーバーラップが気になる部分が大きくなってきたので、一部だけは統一しよう、という動きも出てきています。
ある意味そういった連続的な変化に対して転換を起こすのが技術戦略ですし、その方針を決めるのがCTOや組織の上層部だと思っています。実際に推進していくのは現場のエンジニアということも踏まえて、仮に非効率的ではあっても長期的に取り組むための判断ができるように意識しています。

白井:モノリシックなシステムからマイクロサービスに移行する最初のステップがあったと思うのですが、それは長沢さんが号令をかけたのでしょうか?

長沢:そうですね。当時私がマネジメントをしていた移行チームが技術の方針を決めていました。モノリシックで開発を進めた結果、システム規模が肥大化するにつれてどこを触っても影響範囲が大きくなってしまい、時間がかかるという状況になってしまいました。当社は不動産系のサービスなので、引越しシーズンである年明けから4月までが繁忙期です。そこに向けてサーバーを準備していた時期に、ここをクラウドに移行したら効率的なのではという話が出てクラウド移行していくことになったのですが、それにあたって、アカウント管理やサーバー分けをどう行っていくのかと試行錯誤していく中で、やはりサービスを小さく分割(≒マイクロサービス化)したほうがシステムの影響範囲を小さくでき、スピードを上げていけるのではないか、と結論づけて始まりました。

白井:方向転換に関して、組織としての納得感は自然とあったのでしょうか?

長沢:意図を含め説明もしたところ、自然と受け入れてくれましたね。アプリケーションエンジニアも今まで触ってなかったインフラから触ること担ったんですが、それに対しても、ほとんどのエンジニアが前向きに取り組んでくれました。

木村:「変える」というのは重要ですよね。技術選択は普通にすればいいのですが、マイクロサービスも、放っておくとマイクロサービス一つひとつがレガシー化してしまう。「技術選択し続けること」が大切で、それができる文化や環境、組織を作っていくのが私たちの役割なのではと思います。

長沢:そこに関しては私も気を使っています。当社は事業会社なので、事業に貢献したいという想いが強くそのためには技術だけではなくいろいろな手を尽くすという、エンジニアが多いです。当然、それ自体は素晴らしいことです。ただ、一方で、少し気を抜くと技術面がおざなりになってしまいます。エンジニアだからこそ技術で創造できるような価値や世界を作っていかなければなりません。
そこで当社では「エンジニアとして経営をリードする」という言葉を掲げ、4つのルールに従って変化し続けようという文化を浸透させようとしています。四半期に一度エンジニア全員を集めて事例や抱負を語ってもらうという取り組みも、3年ほど継続していますね。

CTOmeetupエンジニア組織 CTOmeetupエンジニア組織
白井:ゲーム事業において、エンジニアはエンジニアリングも経営もすごく好きです。事業目線の強いエンジニアが多いというのでしょうか。するとやはり同じ技術を使い続けてしまう傾向があり、新しい技術を取り込む力は相対的に弱くなってしまいます。停滞しない文化づくりや、効率的な方法があるはずだと問い続ける取り組みは、CTOの役割なのだと思います。

木村:その視点で言えば、メルカリとメルペイは「テックカンパニーになろう」と標榜しています。テックカンパニーは定義が難しいのですが、一つはテックドリブンによって事業を生み出すということが挙げられます。あるいはテックドリブンによって事業を変革する、コストカットをするということですね。それはエンジニアにしかできないことです。

一定範囲での業務委託や、専門性の高い外部人材は積極的に採用する

藤倉:外部委託の方の活用方法についても触れたいと思います。私個人の答えとしては、外部にも業務に協力いただける優秀な方が大勢いるので、マッチングすればジョインしてもらい、社員と同じように動いていただきたいですね。ルール上、本番のデータベースに入ることはできませんが、社内の教育制度などは使っていただいて構いませんし、同じチームの一員として切磋琢磨したいと思っています。
外部委託の方が正社員採用よりも早く入っていただけるので、そういう意味では両方に力を入れているというのが当社のスタンスなのですが、みなさんはいかがでしょうか。

木村:メルカリは業務委託をしないという方針でしたが、メルペイは私の参画を期に利用する方向へ転換しました。ただし、いずれは使われなくなるであろう技術やとQAのような繁閑の波がある部分と範囲を明確に決めています。

長沢:いくつかパターンはありますが、ポイントで人が必要になったときに業務委託することはありますね。
また、昨年の10月にAI戦略室を立ち上げたのですが、専門性が高い人材が必要になる一方、社内ではすぐに対応できるメンバーがいないといったケースに、顧問のような形でに参画いただくようなこともあります。

白井:当社もみなさんと同じような感じです。優秀な方も多いので、同じチームで協働してもらいます。外部委託の方だからと業務に制限はかけていないのですが、セキュリティやリスクヘッジの面で本番環境への権限を制限しているのがリアルなところです。

CTOmeetupエンジニア組織 【写真左から、Sansan株式会社 執行役員 / CTO 藤倉成太さん、株式会社LIFULL CTO 長沢翼さん】

質疑応答

技術的負債を可視化することで、継続性のある組織づくりを行う

藤倉:ではここからは質疑応答に入りたいと思います。いただいているもので多いのは技術選定に関してですね。分不相応な技術選定に対してCTOがどう向き合うべきか。技術的負債を返していくときにどう説明するのかなど、みなさんご意見ありますでしょうか。

長沢:技術的負債に関しては「属人化させずに説明すること」を意識しています。特定の誰かがいるから、うまく説明ができて負債返済に取り組める、という状態では、技術的に大きな課題に対して属人的すぎると思うんですよね。特定の人がいなくなったら負債について進言されず、全く返済されない状態になってしまうのは、良くないと思うんです。人に依らず信頼感を持って技術を説明できる仕組みを残す必要があります。そういう意味で、半年ほど前から現状を可視化するための取り組みを始めました。コードの複雑性を算出したり、サーバーの脆弱性なども目に見えるようにします。そのほかにも人の開発や調査にかかる時間、障害の頻度などの数字を複合的に見ながら、こうすれば調査の工数を減らせる、障害の数を何年前の時点にまで戻せるといった技術負債の返済方法を提示できるようにしようと取り組んでいます。

白井:なかなか難しい問題です。現在運用中のプロダクトの場合、大きなきっかけがない限りしっかりと期間を設けてシステムを直すといったことができません。わかりやすい例で言うと、ゲームはUnityで作ることがあるのですが、リリース時は問題がなくとも、運用を続けていくとバージョンアップしなければならないタイミングが出てきます。しかし運用中は大掛かりに期間を取ることができないので、よく手を入れるところを少しずつ良くする、という負債の返し方になっていますね。

CTOmeetupエンジニア組織 【写真左から、3社(株式会社Craft Egg,株式会社ジークレスト,株式会社サムザップ)CTO 白井英さん、株式会社メルペイ 執行役員 VP of Engineering 木村秀夫さん】

アサインのミスマッチに対しては厳しい選択も迫られる

藤倉:次の質問です。「CTOを任されたものの、蓋を開けてみたら、そもそもエンジニアに全くスキルが無いことがわかった。どうしたらいいですか」ということです。特殊な状況ですが、何かアドバイスはありますか?

白井:過去に似たようなことがありました。あるプロジェクトがピンチだから見てくれと言われて参画したら、質問者さんと同じ状況だったんです。ドライですが、スキルの低いメンバーは外し、優秀なメンバーを入れるという対応を取りましたね。

長沢:もちろん、スキルや能力上、実現すべきことを実現できない状況もあります。観察していると、スキルの問題というより、タスク管理やコミュニケーションが上手くいっていないことも多いんです。そのようなときはマネージャーにも協力してもらい、マイクロマネジメントをしてもらうようにしました。

木村:メンバーのアサインがミスマッチだったという話であれば、もうアサインを変えてあげるしかありません。一定の組織はやはり事業の規模やフェーズによって新陳代謝が必要ですし、そういった厳しいコミュニケーションができるかどうかも、マネージャーの素養の一つなのではないでしょうか。

藤倉:ありがとうございました。では、前半はここで終わりにしたいと思います。


flexy編集部より
●【CTOmeetup】エンジニア組織のあり方(後編)は、こちらから!
後編、”最先端の注目企業のCTOが語る、エンジニア採用と育成の手法”もぜひご一読ください。

●flexy主催 CTO meet upイベント応募ページは、flexyのconnpassサイトをご覧ください。

この記事を書いた人
flexy編集部
flexy編集部
ハイスキルIT人材への案件紹介サービス
サーキュレーションが運営するフリーランスのエンジニアを中心としたIT人材の案件紹介サービスflexy。エンジニアに役立つコンテンツも提供しています。【flexyのサービス詳細】★求人を募集している法人様向けお仕事をしたいご登録希望の個人様向け

週1日~/リモートの案件に興味はありませんか?

週1日~/リモートの関わり方で、「開発案件」や「企業のIT化や設計のアドバザリーなどの技術顧問案件」を受けてみませんか?副業をしたい、独立して個人で仕事を受けたエンジニア・デザイナー・PM・技術顧問の皆様のお仕事探し支援サービスがあります。

flexyでご案内できる業務委託案件

React

テーマ クラウド入居者管理システムのフロントエンド開発(リモート可)
勤務日数 2-3日/週
報酬 4万円/日
必要スキル React
勤務地 東京
リモート

外部CTO、技術顧問

テーマ 技術アドバイザリーとして知見と経験を生かす
勤務日数 1日/週
報酬 10万円/日
必要スキル エンジニア組織立ち上げや統括のご経験、コードレビュー経験、技術的なアドバイスが出来る方
勤務地 東京
リモート 相談可

Go

テーマ 家族型ロボットのサーバサイド開発
勤務日数 3-4日/週
報酬 5万円/日
必要スキル Go GCP
勤務地 東京
リモート 相談可

AI

テーマ AIを活用した新規事業立ち上げの技術顧問
勤務日数 週1日〜
報酬 5万/日
必要スキル Python、AIの知見、新規事業立ち上げの経験
勤務地 東京
リモート リモートと常駐のMIX

PMポジション

テーマ 複数のプロダクトごとにPMを必要としているため急募
勤務日数 2-3日/週
報酬 5万円/日
必要スキル PMとしての経験、PHP、JavaScript
勤務地 東京
リモート リモートと常駐のMIX
個人登録

お仕事をお探しの方(無料登録)
法人の方(IT課題の相談)