1. DMMグループ3社CTOが赤裸々トーーク!事業規模でこんなに違った各社CTOの運営・意思決定方法

DMMグループ3社CTOが赤裸々トーーク!事業規模でこんなに違った各社CTOの運営・意思決定方法

DMMグループ3社CTOが赤裸々トーーク!事業規模でこんなに違った各社CTOの運営・意思決定方法 1番目の画像
左からnana music 辻川隆志氏、ピックアップ 乾夏衣氏、DMM.comラボ 城倉和孝氏。
 今回、編集部が取材したイベント「DMMmeetup」とは、個性豊かなテーマを題材に、来場者はもちろん、登壇者やDMM.comグループ社員も一緒に楽しみながら学ぶことができる勉強会。

 主催するのは、動画配信やゲーム、FX、英会話、3Dプリンターにロボット、ソーラーパネル、最近ではアフリカ事業など20以上ものサービスを展開している株式会社DMM.comだ。

 記念すべき第1回目は、テクノロジーアートで大きな話題となっている六本木にあるDMM.com新オフィスで開催!

 6月13日(火)に行われたこのイベントでは、約5人、50人、500人規模の開発チームを抱えるDMM.comグループ3社のCTOが登壇。

 「事業フェーズによって異なる悩み」「事業成長に伴って生じる問題」など、普段なかなか話しづらいようなテーマを“企業規模が異なる各社CTOの視点”で赤裸々にトークし、会場は大いに盛り上がった。

 気になる登壇メンバーは、2017年にDMM.comグループに加わった株式会社nana music、ピックアップ株式会社の2社にDMM.comグループを支えるDMM.comラボのCTO3名。

【登壇者プロフィール】
城倉 和孝氏:株式会社DMM.comラボ 取締役兼CTO。独立系Slerにて企業システムの受託開発、パッケージビジネスの立ち上げなどを行い、2011年にDMM.comラボにジョイン(現在の開発チーム規模は約500人)。

辻川 隆志氏:株式会社nana music CTO。2012年にローンチした音楽SNSアプリ「nana」の立ち上げ時からサーバーエンジニアとして開発からインフラ運用まで行う(現在の開発チーム規模は約50人)。

乾 夏衣氏:ピックアップ株式会社 副社長兼CTO。2012年に株式会社日本税理システムを創業。2014年にピックアップ株式会社を共同創業し、現在までCTOとしてインフラ運用やチームビルディングを担当(現在の開発チーム規模は約5人)。

 それでは、当日の流れに沿って、イベントをレポートしていく。

DMM.comグループにジョインして「採用課題」を解決!

DMMグループ3社CTOが赤裸々トーーク!事業規模でこんなに違った各社CTOの運営・意思決定方法 2番目の画像
 1つ目のテーマは「プロダクトの急成長で起こったことは?」。“急成長”を経験してきた3社に共通して起きたことは「人材」に関する問題。

 ピックアップ株式会社が提供する「POOL(プール)」は、デバイスの容量を使わずに写真と動画が保存し放題、という便利な画像保存サービス。現在POOLで保管している写真の数は30億枚超。DMM.comグループに加入するまでは、2人で全ての画像を管理していた

 ユーザー増加→画像急増→「人が足りない」という問題に直面し、採用活動をしたいが「自分が書かなきゃ仕事が回らない」……という状態に。そんな人手不足を脱するきっかけが、DMM.comグループにジョインしたことだった。

 ジョイン後は採用する余裕が出て、来月には10人体制になるとのことだ。

城倉氏「やっぱり1番は“人の問題”ですね」

 次に話したのはDMMの城倉氏。今でこそ500人規模のDMMも、人材を増やすという段階で開発拠点の中心を創業の地・金沢から東京へ移すという大きな決断をしている。

城倉氏:金沢ではエンジニアの母数が少なく、中途採用が困難でした。そこで、事業が増える→人が集められない→じゃあ東京に比重をおこう! という流れになりました。

 いざ採用活動を始めると、また別の問題が浮かび上がった。

城倉氏:採用を始めたときブランディングがとっても大切だな、と実感しました。「DMMってそもそもエンジニアいるんだ」と言われるほど、知名度が低かったんです。当時はDMMのエンジニアを見たことがないということで、「ツチノコ」と呼ばれるほどでした。

 そこから知名度を上げるために採用広告を出したり、WEB+DB PRESSという技術雑誌で記事を書かせてもらったりなどの地道なブランディング活動を行なったそうだ。

 やはり1番は「人の問題」と発言する城倉氏。急成長に伴い、なかなか人の採用が追いつかないのがピックアップとDMMの2社にとって課題だったようだ。

急成長企業の課題点

  • 運営メンバーが少なく、採用活動をしている暇がない
  • 会社の知名度やロケーションで人が集まらない

想いの強いエンジニアが揃ったが…

 採用活動についての悩みがあったという2社に対し、nana musicでは「自分が入ったら、絶対にいいプロダクトにする!」という想いの強いエンジニアが揃い、採用活動は成功していた。

 しかし、「こんなサービスにしたい」「こんな機能を入れたい」というエンジニアからの声が集まりすぎて、プロダクトがどうあるべきかで葛藤。全てを実行するのは不可能な状態に。

 今では、「プロダクトはどうあるべきか?」と考えて管理する人がいるため、想いの強いエンジニアたちをうまくまとめられているとのこと。

 1人1人のエンジニアの想いが強い場合、辻川氏はCTOとして以下のようにチームをまとめていくと語った。
  • プロダクトの方向性を決める人のサポートをする
  • 今取り組まなくていいことは、捨てていく
  • 社長と話し合って「何が優先か」を共有する
 エンジニアだけでなく、ビジネス側のチームビルディングをしている人にも参考になる「人材」に関する話。

 nana musicの辻川氏については、現在も悩んでいることについての話で「急成長中の会社」の熱量を感じるトークテーマとなった。

城倉氏「意思決定を早くするために“小さな組織化”を行なった」

DMMグループ3社CTOが赤裸々トーーク!事業規模でこんなに違った各社CTOの運営・意思決定方法 3番目の画像
イベント名「meetup」にちなんで、肉(meat)が振る舞われた。
 2つ目のテーマは「どんな開発体制ですか?」。エンジニアや会社をまとめる立場のビジネスパーソンであれば気になるテーマ。

城倉氏:DMMの開発体制は今年から変えているところがありまして——DMMは永遠のベンチャー企業だという認識でしたが、やはり大きな組織になるにつれて意思決定のスピードが遅くなりはじめているな、と感じていました。

DMMでは今、全社で原点回帰の「小さな組織化」を行なっています。

 DMMでは、意思決定までの時間を短くするためにスクラムを採用。スクラムとは、チームで共通のゴールを目指しながら仕事を進めるための枠組みのこと。

 DMMのように500人規模の大きな体制になった場合、「小さな組織化」で意思決定スピードを早くすることが重要になる。

 DMMと対照的なのが、約5人の開発体制であるピックアップの乾氏。乾氏は「1〜2週間の期間でやることを決めており、あまり長期的に考えていることはない」と話した。

 城倉氏は「開発体制が3〜5人というスピード感ある環境が羨ましい」とコメント。

辻川氏「スクラムマスターの存在が大きい」

辻川氏:現在、メンバーはかなり増えてきたが、スクラムマスターが入り、無駄な仕事を増やさないようになった。この2週間でこの仕事を確実にやろう! と決めている。

 2週間でやることを決め、スクラムマスターが「この仕事は無駄」と、やらないことを明確化していくことが50人規模のチームには必要になってくる。

大きなチームでも意思決定を早くするための方法

  • スクラムを採用することによる「小さな組織化」
  • 仕事の内容と期限を決めるリーダーを立てる
  • やること、やらないことの明確化

開発チーム規模によって異なる“意思決定”

 3つ目のトークテーマは「チームの意思決定はどのように行なっていますか?」。このテーマでは、チーム規模によって全く異なる回答になった。

 nana musicは、「プロダクトオーナー(PO)が機能要件を決め、スクラムマスターが開発統括を行う」と話した。毎日GitHubに上がってくる開発案件・機能要望の中から、POが毎日内容を精査し、2週間に1回のペースでスクラムマスターと開発チームが開発内容を決定するそう。

事業が多岐にわたる企業に重要なのは「柔軟なチーム作り」

 DMMでは、スクラムを採用している事業はPOが意思決定。スクラムを採用していない開発チームでは、エンジニアリングをするマネージャーと技術決定をするリードエンジニアのポジションを作り、それぞれが主導権を持って仕事を進めているとのこと。

 事業によって異なる、というのもDMMらしい柔軟さが垣間見える。

 3〜5人の開発チームにおいて乾氏は、技術選定などの決定は全部自分が行なっていると話す。スタートアップにとって、意思決定もスピーディでなくてはいけないのだ。

【規模別】意思決定をする人

  • 約500人規模:事業ごとに立てたリーダー
  • 約50人規模:POとスクラムマスター
  • 約5人規模:スピード重視でCTO自身が決定

乾氏「スタートアップが運用に時間を割くのは致命的」

 4つ目のトークテーマは「技術選定はどのように行なっていますか?」。このテーマについては規模での違いというよりも、企業によっての個性が出る回答に。

 乾氏はチームの意思決定と同様、自分で決めることが多いと言う。メンバーの少ないピックアップ社では、インフラ運用に時間をかけるのは致命的だと判断し、2014年にサーバーに「Googlel App Engine(GAE)」を採用。

 GAEはPaasを利用しているため、インフラを心配する必要がない。以前よりも開発に集中できるようになったそうだ。

 500人規模の企業にもなると、技術選定をトップダウンで行うことは難しい。例えばDMMのインフラはサーバー台数やデータ量の関係で、長いこと自社運営のデータセンターが中心だったため、AWSを本格的に使い始めたのは昨年からだという。規模が大きくなるほど“文化”が根付き、変化することが難しくなるのだ。

 DMMでは、人やサービスを増やさなければならないフェーズに入ったとき「1つのモジュールや言語に特化するのをやめよう!」と決定。文化を変えるシーンには、「企業スケールの変化」が関係しているのかもしれない。

各社の異なる技術選定

  • DMM.com:会社にとって必要な場面で技術を決める
  • nana music:最初はコストメイン。現在のAWSへの移行はCTOが決定
  • ピックアップ:インフラ運用に時間をかけないため、CTOがサーバーを決定

ビジネスサイドvsエンジニアサイド、そんな時どうする?

 4つのトークテーマについて話し終えた後は、来場者から事前に集めた質問に回答。

 教育やビジネスサイドメンバーとの衝突など、気になる質問が寄せられた。

質問①「ビジネスサイドメンバーとの衝突の有無は? その解決方法は?」

 1つ目の質問は、エンジニアサイドもビジネスサイドも気になる内容。

 ピックアップの乾氏は「ビジネス成果とエンジニアの工数が合ってないと意味がない」と明言。2人で会社運営をしていたときは「僕はやりたくない。めんどくさい!」ときっぱり発言して回避していたそうだ。

 50人規模にもなると、なかなか1人の意見は飲んでもらえない。辻川氏は「どちらかが妥協しないといけない」という大人の意見を述べた。

 メンバーの数だけ、衝突も多くなるのでは? とも思うが、城倉氏は「DMMは大人なエンジニアが多いので、ビジネスサイドの意図も汲んで仕事している」と話した。

 チーム規模に関わらず、コミュニケーションをとることがやはり重要なのだ。

ビジネスサイドvsエンジニアサイドの決着のつけ方

  • 「やりたくない」と根拠を持ってエンジニアサイドがきっぱり断る
  • どちらかが妥協する
  • エンジニアがビジネスサイドの意図を汲んで仕事をする

質問②「エンジニアを成長させるために取り組んでいることは?」

 2つ目の質問は企業文化がうかがえる内容。

 辻川氏の会社では「成長支援制度」と呼ばれる「お金を出すから自分のやりたいことをやりなさい」という制度があるという。エンタメ系の会社であるnana musicらしい取り組みだ。

 教育する余裕のある企業に対し、ピックアップの乾氏はスピード感のある教育をしている。いち早くコードに慣れてもらうため、新しくジョインした人とマンツーマンで話しながら初日にデプロイしてもらっている。

 この取り組みには登壇者、来場者ともども驚きの声が漏れていた。じっくりと教育をする時間のないスタートアップならではの取り組みだ。

 DMMでは、「チャレンジできる環境」を与えるようにしているとのこと。新卒社員に「アプリコンテストで賞をとれ!」とミッションを与えたり、インターン生にサッカーチームの公式アプリを作らせてリリースさせたりと、経験値に関わらずチャレンジする機会を与えている。

 その他にもDMMでは、現場のエンジニアたちが毎週勉強会を行なっているとのこと。時間と人材に余裕があってこそ、じっくりと教育ができるようになるのだ。

エンジニアを成長させる取り組み

  • 会社の特色に合わせた「成長支援制度」
  • エンジニアたち自身による勉強会の実施
  • チャレンジする場所の提供
  • マンツーマンで指導しながら、ジョインした初日にデプロイしてもらう

質問③「技術情報の共有文化、ツールはどんなものですか?」

 3つ目の質問は、社内で使っているツールに関するもの。

 3社共通して使用しているツールは2つ。コミュニケーション用に「Slack」、イシューの共有用に「GitHub」。ITベンチャーにとっては、言わずと知れた定番ツールだ。

 また、ピックアップとnana musicが共通して使っているのが「esa」という情報共有ツール。Slackで喋った内容などは、esaにまとめておくそうだ。esaの特徴は以下のとおり。

ドキュメント共有ツール「esa」

  • 書き途中の不完全なドキュメントを気軽に公開できる
  • 複数人でドキュメントに書き込める
  • 知見をストックして網羅的に管理する

質問④「チームメンバーをどのように評価してフィードバックしていますか?」

 4つ目の質問は、メンバーの評価に関する内容。

 メンバーの少ないピックアップの乾氏は、今は自分の判断でフィードバックをしているとのこと。やる気を上げるためのはずの“評価”は、やりすぎるとモチベーションが下がってしまうと述べた。

 辻川氏は、評価は現在の課題の1つだと話す。各チームのリーダーが、部下1人1人の成長に目を向ける必要がある。

 しかし、「自分では成長した!」と部下が思っていても会社にコミットしているかどうかが重要であるため、どう“評価”するのが最適解なのか? という点で悩んでいるようだ。

 DMMでは、人数の多さに苦悩している部分がある模様。目標管理制度(MBO)や、スキル評価など試行錯誤しながら変更を行なっているが、城倉氏は今の制度が完璧じゃないということを明かした。

 「評価」は、会社が大きくなればなるほど悩む課題ということがよくわかる3社それぞれの回答内容だった。


 DMM.com、そしてそのグループ会社2社のCTO3名が一堂に会してディスカッションするという豪華な勉強会になった第1回目「DMMmeetup」。

 約5人、50人、500人、それぞれの事業・チーム規模に応じた、それぞれの課題があるということが各社CTOの熱量とともに伝わってきた。

 主催のDMM.comによると、今後も定期的に開催していく予定とのこと。勉強会後にはイベント参加者や登壇者、DMM.comグループ社員が、ビール片手に交流できる時間もしっかりあった。

 今度もU-NOTEでは「DMMmeetup」をレポートしていく予定だが、新たな出会いや発見、刺激がほしい人はぜひ今後開催されるイベントに、足を運んでほしい。

U-NOTEをフォローしておすすめ記事を購読しよう
この記事を報告する