「解くべき課題の根源は最終的に経営にある」一介のエンジニアがアーキテクトそしてCTOへロールチェンジした理由

わたしの選択 CTO キャリア

読者の皆様、はじめまして。ベルフェイス株式会社で取締役CTO（最高技術責任者）とCPO（プロダクト最高責任者）を兼任する山口徹（@zigorou）です。自ら株式会社マギステルという会社も立ち上げて、アーリーステージのスタートアップから上場企業まで、技術顧問や経営顧問を幅広く行っています。

職歴を簡単に紹介すると、Web制作会社でキャリアをスタートし、GaiaX、サイボウズ・ラボ、DeNAと渡り歩いて、ソフトウェアエンジニアとしては19年ほどのキャリアになります。うち後半の数年ではソフトウェアアーキテクトとして振る舞うことも多く、開発責任者や事業責任者を務めたり、アライアンスや新規事業を主導したりと、普通のソフトウェアエンジニアとは違った異色のキャリアかもしれません。

古くはPerl Hackerとして活動したり、OpenIDのエヴァンジェリスト的なこともしていましたが、近年はコミュニティ活動もめっきりできなくなってしまいました。

前置きはさておき、この記事では、私が一介のエンジニアから経営者になっていくまでの軌跡を紹介しながら、ソフトウェア開発に必要なHow・What・Whyとどう向き合ってきたか、またパラレルワークや技術顧問の実情やメリット、さらにCTOや経営に興味がある方へのアドバイスまで具体的に書いていきます。

ソフトウェアアーキテクトとして課題解決に明け暮れたころ

前職のDeNAには2009年1月に入社し、2020年11月まで12年弱在籍しました。入社初年度の後半から 、今ではすっかり懐かしいモバゲータウン（現在の呼称に即して以降はMobageと記述）を、ゲームプラットフォームとして協業パートナー会社向けにオープン化するプロジェクトの技術責任者として、プラットフォームの根幹部分のアーキテクトと、APIサーバーの実装を担当しました。

Mobageでは、スマホブラウザ向け、スマホアプリ向け、韓国・台湾・中国向け、グローバル、Yahoo! Mobage、mixi Mobageと、さまざまなオープンプラットフォームを提供しており、この多くを技術責任者やソフトウェアアーキテクトとしてリードしていました。いくつかではアライアンス案件も手掛け、協業相手との折衝なども行ってきました。

当時のゲームプラットフォームにはOpenSocialという枠組みがあり、その仕様にのっとることでプラットフォームを提供していました。そのため「何を作るか（What）」にそれほど悩むことはありません。純粋に「どう作るか（How）」ばかりを考えていました。

しかし、インテグレーションしなければならないシステムコンポーネントが増えていく過程で、何を作るかが常に自明であることは次第に少なくなりました。やること・やらないことを決め、ユーザーにどのように届けるのかまで考えなければならない状況になってきました。

具体的には、タイムラインにゲーム上のアクティビティを出力するような仕組みを作る際に、アクティビティを記録するAPIを作るだけでなく、どのようなアクティビティをどうタイムラインに出していくかまで横断的に考えなければならない、といった話です。

このため興味・関心の軸足は「何を作るか（What）」に移りました。役割としても、純粋なソフトウェアエンジニアから、ソフトウェアアーキテクトに変わらざるを得なくなってきたのです。

サービス統括との二足のわらじでWhyも考える立場に

Mobageの勢いが陰りを見せ始めた2013年くらいから、UXをできる限りスマホアプリに近づけられるゲームプラットフォームを新規事業として企画し、開発することになりました。当時のモダンブラウザが注力したHTML5（現在でいうHTML Living Standard）の機能を惜しみなく利用し、ユーザー認証やAPI利用の認可に、OAuth 2.0やOpenID Connectを採用します。

こう書くと、より包括的でモダンなアーキテクチャを採用したゲームプラットフォームを構築するという技術的な課題として映るかもしれません。しかし、これを事業として成立させるには、技術的な強みをどのように売上につなげていくかを考えられる人が、事業を牽引しなければなりません。

そのため私には、それまでのソフトウェアアーキテクト業だけでなく、サービス統括という役割が明確に追加されました。サービス統括では、当然ですが事業としての成功責任も負うため、開発パートナーを開拓したりする上で、プラットフォームのシステムを説明してメリットをアピールするなど、営業に同行して技術営業のようなことも行ってきました。

この役回りの延長線上で、最終的にMobageという事業全体をサービス統括することになりました。SNSとしてのプロダクトや、その上でアバターを販売するプロダクトを含め、ユーザーにインタビューして実際の声を聞いたりしながら、サービスを改善する課題を見つけていく「何故やるのか（Why）」も考える立場にもなってきました。

この頃から、ちょっとしたプロダクトマネジメントのまねごとを、かじってきたように思います。

任天堂との協業で気づいた「モノづくり」のスタンス

サービス統括として新しいゲームプラットフォームの開発を進めていた2014年の秋、大ファンだった任天堂株式会社とのアライアンスを自分が提案できる機会が巡ってきました。

喜び勇んで提案資料の作成に取り掛かり、公式コンテンツの「社長が訊く」を熟読して企業カルチャーを読み取ろうとしてみたり、決算資料に見られる今後の戦略も参考にしながら、我々だからこそできる風呂敷を目一杯に広げて資料に落とし込み、意気軒昂に京都へと向かいました。

幸いにも興味をもっていただけて、具体的なアライアンスを年末まで検討し、2015年3月の資本業務提携発表に向けて年明けからさまざまなプロジェクトを同時並行で進める準備をしました。NDAのため詳しく書けないことが残念でなりませんが、もともと複数の事象を予測した上で何をどの順で作るかというビッグピクチャーを描いた提案で、大筋では想定した通りスムーズに提供できたと思います。並行してゲームタイトルにもうっすら関与したり、貴重な体験をたくさんさせていただきました。

特に最初に参加したMiitomoの開発では、任天堂のレジェンドの1人である坂本賀勇さん（参考記事）とそのチームに関わる機会があり、ここでさまざまなモノづくりに対するスタンスを学びました。Miitomoは純粋にゲームとはいい難いスマホアプリで、SNSの性質も兼ね備えていましたが、例えば「Miitomo内でフレンドになる」こと1つをとっても、チームで集まってその方法やUXをディスカッションします。

もし読者の皆さんがSNSを作らなければならなくなったなら、当然ですがすでに世間にあるSNSのUXを参考にしてしまうと思います。しかし、坂本さんとチームの方々にはMiitomoがターゲットにしたいユーザー像やコンセプトがあり、ときにちょっと斜め上な仕様が検討されたりもしましたが、UXの1つにもこれほど情熱を注ぐのかと感心させられてばかりでした。

「（良い意味で）くだらなくて面白いから周りの人に伝えたくなってしまうものを作っている」と坂本御大がおっしゃったことがあり、それで任天堂のモノづくりカルチャーって「やっぱり好きだな」と感じましたし、翻って「DeNAのモノづくりはどうか？」という素朴な問いや、自分が「どうしていきたいか？」を考える強烈なきっかけになったように思います。

パラレルワークと技術顧問で得られた他社の生の課題

任天堂さんとの協業プロジェクトから段階的に離れ、新規事業を模索するようになった頃、DeNAで副業が解禁になりました。大学時代の友人が創業したオイシックス・ラ・大地の技術顧問という機会が巡ってきたこともあり、個人事業主として開業したのが2018年でした。

それからいくつかの企業の技術顧問を経験する中で、自分が所属していない他社の生の課題に触れる機会をたくさん得ました。本業を通じて出会う他社の人は、文字通り他社の人です。会社の壁越しに接するため、実情を聞く機会はほとんどありません。しかし、技術顧問のようなパラレルワークでは、擬似的に中の人になります。そのため、通常のパスでは知り得ないこともたくさん見聞きしました。

特に技術顧問では、関係するステークホルダも一介のエンジニアではなくマネジメント層あるいは経営層であり、会話の対象もエンジニア組織そのものであったり、会社の経営課題の1つとしての技術だったりします。とはいえ技術顧問が与えられる影響は間接的なものであり、そのインプットを対象企業のステークホルダがどう受け入れて具体的なアクションに落とし込めるかが重要です。そしてステークホルダが経営層に近いほど効果的だということも、経験から分かってきました。

こういった経験から、自分が所属する会社も相対化して、「よりよいエンジニアリング組織はどうしたら作っていけるか？」を考えることも多くなりました。

この頃、技術顧問のようなパラレルワークは、次に参画したい企業を探す手段としても位置づけられるようになってきました。今でこそ「おためし転職」も当たり前になりつつありますが、ベールに包まれて見ることができない「他社の生の事情」も、パラレルワークを通じていとも簡単に知ることができます。

一方で、エンジニアのパラレルワークについては、まだまだ未経験の人がたくさんいます。パラレルワークで得られる知見はたくさんあり、井の中の蛙ではないかという不安も払拭できて、自分の市場価値を見つめ直すにはもってこいです。この記事の読者でパラレルワークを経験したことがないエンジニアは、今すぐ開業届を出した方がよいと思います！

ベルフェイスに参画してCTOとCPOを兼任

シード期から上場企業までさまざまなサイズの企業で技術顧問を経験する中で、DeNAを卒業しようかなという気持ちが次第に高まってきました。

やはりスタートアップのダイナミズムが刺激的で面白く、メガベンチャーに失われがちなスピード感もあり、顧客とダイレクトにつながっている感覚に興味をひかれたためです。スタートアップの中でも、自分の特性はシードやアーリーステージより、ミドル・レイターステージの方がフィットすることもしみじみと分かりました。

また、任天堂のモノづくりから感じたこだわりやパッションを企業の文化として根付かせるには、自分自身が経営者になるしかないと考えるようにもなりました。本業で1事業を成功させても、会社の意思決定に参画できる立場にならねば会社は動かないという限界を感じるようにもなり、解くべき課題の根源は最終的に経営にあるんだなということが理解できるようになってきたということです。

現職のベルフェイスと出会ったきっかけは知人の紹介で、CEOの中島一明（@k_nakajima_bell）と話して、まず技術顧問を担当しました。そして最終的にはCTO（最高技術責任者）として、2020年12月に入社しました。現職でも他社での技術顧問でもそうですが、CEOと強力なタッグを組んで物事を進めていく形が一番ドライブすると思います。できれば使役関係より対等な立場がよいと思います。

現在はCPO（プロダクト最高責任者）も兼務しており、プロダクト組織も管掌しています。CTOはWhatからHowの実行部隊であり、CPOはWhyからWhatまでを担当するので、そういった組織を同時にマネジメントすることは、コンテキストスイッチが難しくもあるのですが、同じ人間が担当することで意思疎通のコストがゼロであるというメリットも感じており、楽しんで仕事に取り組めています。

現在のベルフェイスでは、プロダクト主導の組織に生まれ変わっていくことを経営トップマネジメントが本気で意思決定し、全社に展開しています。

CTOに求められる幅広い知識を積極的に経験していこう

よく「CTOが採用できない」という話を聞きます。その理由には、経営者がCTOという技術的な人種を理解できず、どう接してよいか分からないといった話もあります。

これには、CEOにも歩み寄りの学習が必要だと強く感じています。現在のスタートアップでは、CEO自身が最初のプロダクトマネージャーというスタイルが多いでしょう。プロダクトマネジメントを通じてプロダクトやシステムについての理解を進めれば、自ずとCTOと会話ができるようになります。

一方で、CTOを担えるスキルを満たす人材が豊富にいるかという疑問もあります。自分がここまで歩んできたように、CTOに求められるスキルとしては、もちろんエンジニアリングそのものも必須ですが、プロジェクトの推進や、組織づくり、そして事業の成長と、幅広い知識や経験が求められます。

ソフトウェアエンジニアリングに純粋にコミットして行くキャリアも素晴らしいですし、やっぱりかっこいいと思います。

一方で、自らがエンジニアリング組織を主導し、顧客が求めるプロダクトを迅速に開発し、事業の成長に貢献していくというキャリアを志すことになる方もいるでしょう。CTOを目指すのであれば、一見するとエンジニアリングには直接関係ない仕事でも率先して体験し、早い段階から幅広い経験を積むことが大事だと感じています。

この記事を通じて、自身のキャリア形成で少し寄り道をして知見を広げてくれる人が増え、さらに将来のCTOを担う人材が1人でも多く出てくることを願って、結びとさせていただきます。

筆者近影

編集：はてな編集部