コードを書いていてマネジメントもやるようになっちゃった人へ　背中で語っていた僕が、プロダクトとピープルに向き合うまで

エンジニアにありがちなキャリアの変遷

海老原昂輔氏：「コードを書いていたいけど、マネジメントもやるようになっちゃった人のための生存戦略」というタイトルでトークをします。株式会社Lighthouse Studio CTOの海老原と申します。よろしくお願いします。

この「コードを書いていたいけど、マネジメントもやるようになっちゃった人」が何かと言うと、こういうキャリアがありがちなのではないかと思って持ってきました。（スライドを示して）言うまでもなく、私自身がこういうキャリアを歩んでしまっているというわけです。まず、プログラミングが楽しすぎます。楽しんでやっていながらお金になるとか、誰かの役に立つとか、最高だとはしゃいでいたところに、何かしらの環境の変化が生じてしまうことがあります。

例えば転職や創業、チームの拡大や事業の急成長、部門の統廃合、M&Aなど、ポジティブなところはいろいろありますが、ネガティブな場合、業績の悪化や離職者の続出、前任者の退職で繰り上がることもあります。内的要因、外的要因、さまざまありますが、このような変化が生じた結果、CTOやPdM、EMテックリードになっています。

本日集まってくださった方の中で、このような方がいたら挙手をお願いします。たくさん手を挙げていただき、ありがとうございます。オンラインなので、みなさんの挙手を目で見ることはできなかったのですが、しかと心の目で見たので、大丈夫です。私はこういう方がたくさんいることを実は知っていました。

というのも、最近スカウトのたびに、いろいろな方々の経歴やアウトプットなどをよく見ているのですが、最近本当にこういう方が多く、見つけるたびに私は「あ、仲間だ」と勝手にうれしくなってしまいます。ともあれ、このセッションはそうした方々がメインターゲットとなっているので、ぜひ楽しんでもらえればなと思っています。

発表における注意点

（スライドを示して）免責ですが、本発表に含まれる内容は、CARTA HOLDINGSの前職も含め、各所での経験をベースに育まれた私、海老原の個人的見解に基づくものとなっています。CARTA HOLDINGS全体の方針と大きくずれていることはないと思うのですが、細かいところで食い違うところがあるかもしれないので、そのあたりはご容赦いただければなと思います。

それから、これはあくまで私個人の事例の紹介にすぎないので、すべての人に適用できるアプローチとは限りません。ただ、一種のパターンとして何か取り入れてもらって、みなさんの現実の問題の解決にお役立ていただければすごくうれしいですし、ポジティブでもネガティブでもフィードバックをもらえれば、非常に幸いだと思います。よろしくお願いします。

ちょっと前置きが長くなってしまって申し訳ないのですが、これはお願いです。私の経験に基づく話をする関係で、前職時代の経験にどうしても触れざるを得なくなってしまいました。これはちょっと私の中では黒歴史に近い部分があって、あまり触れたくない気持ちが正直本音としてあります。しかし、これは避けられなかったので、がんばってグッと堪えて、話そうと思います。

私もがんばるので、みなさんにもちょっとがんばっていただきたいことがあります。本発表の主題は、あくまで私自身の話であって、前職、プロダクトの話は主題をわかりやすくするための例に過ぎず、あまり関係ない話です。なので、説明が不十分だったり、一方的な見解だったり、言葉足らずなど、いろいろあると思うのですが、私の伝え方のところが言及されることによって、さまざまな印象がついてしまうことがないようにしたいので、これはご理解いただけますと幸いです。

「神ゲー攻略」運用チームの開発メンバーは6名、非開発メンバーはその10倍以上

前置きその2の、会社説明です。（スライドを示して）私が所属している株式会社CARTA HOLDINGSは、2019年1月にVOYAGE GROUPとCCIが経営統合して誕生した会社です。2019年時点では、純粋持株会社としてのCARTA HOLDINGSでしたが、2022年1月より事業会社としてのCARTA HOLDINGSとして一本化されました。これが何を意味するかというと、その傘下にあったVOYAGE GROUPは、長らくご愛顧いただいていた会社ですが、これに伴ってCARTA HOLDINGSとなりました。

VOYAGE GROUP時代、それからCCI時代、多種多様なサービスを運用している会社でしたが、CARTA HOLDINGSでもこれらを引き続き、多種多様な事業、サービスを独特なエンジニアリング文化で支えることで展開していくので、これからもCARTA HOLDINGSを何卒よろしくお願いします。

（スライドを示して）さて、私はそうしたCARTA HOLDINGSの100%子会社である、株式会社Lighthouse Studioで取締役CTOを務めています。ゲーム攻略サイト「神ゲー攻略」を中心としたメディア事業を行う会社で、直接開発業務に携わる開発チームのメンバーは6名です。そして、開発以外の非開発業務のメンバーは、その10倍以上の60〜70名います。かなり歪な組織構造に見えるかもしれませんが、そういう形態で運営している会社です。（スライドを示して）私どもが主に運用する「神ゲー攻略」というゲーム攻略サイトは、現在では数十万の記事を持ち、月間2億PVを超える規模のサービスとして成長しています。

というところで、先ほどの開発チームの人数を思い出してもらえればと思うのですが、6名です。さらにもっと言うと、私は今、別のメディアの開発にかかりっきりなので、実質5名です。5名で2億PVを支えているので、その大変さと言ったら想像に難くないと思いますが、やはり苦労しています。

このように、私たちのプロダクトや開発組織は、けっこう特徴的なところがあるのですが、これについては2020年に発刊された『Engineers in VOYAGE — 事業をエンジニアリングする技術者たち』という書籍の第4章に、主にサービス立ち上げ期のシステム構築の話について、t-wadaさん（和田卓人氏）のインタビューを通して、赤裸々に語らせてもらっています。

この本については、ありがたいことにいろいろな反応をいただいていて、歴の長い方々には第3章のECナビの章が大人気です。私も歴が長いので気持ちがよくわかるのですが、サービスの立ち上げ期の話も楽しいと思うので、興味を持たれたら、ぜひ第4章も楽しんでもらえればなと思います。

自己紹介

ということで、自己紹介です。（スライドを示して）私は海老原昂輔といって、インターネット上では「co3k」というハンドルとご覧のアイコンで活動しています。このアイコンを見たことがある方もいるかもしれませんが、2005年から株式会社手嶋屋に勤めて、2014年より現職、当時の名前のVOYAGE GROUPに転職しました。そして、2017年より新しく立ち上げたLighthouse StudioのCTOに就任しました。それで現在に至っています。経歴は、17年ほどになります。なので、Web2.0の黎明期からこの業界の末席を汚しているという立場の人間です。

（スライドを示して）ということで、そこそこ長い私のキャリアですが、このキャリアに占める、エンジニアリング系業務とマネジメント系業務の割合をイメージした図を持ってきました。大体こんな感じで、基本的にはずっとエンジニアリング100%でやりつつ、ちょっとマネジメント業務が乗っかっている感じで、基本的にはずっとキャパオーバーの感じでやっています。

途中マネジメント系業務が膨らんで、転職によってリセットされて良かったなと思っていたら、健闘むなしく、右肩上がりになって今に至っています。ここでもし、どうしてもコードを書きたいと転職したとしても、また同じような山を描くことは目に見えて明らかです。たぶん同じような状況に陥っている方が多いのではないかなと思っています。

最初期のマネジメントは「背中で語っていた」

本当の意味で、コードを書くことしか考えていなかった私が、プロダクトやピープルに向き合うに至った経緯を、これから紹介させてもらえればと思います。（スライドを示して）最初期のマネジメント。これはマネジメントと言うのもおこがましい感じです。プログラミングだけでなく、プロジェクト管理、要件定義、設計、いろいろな工程をやらせてもらっていましたが、ピープルマネジメントに関しては本当の意味でまったくやっていませんでした。

せいぜいやっていたことといえば、背中で語るぐらいです。背中がしゃべるのかという感じですが、私の背中はしゃべったみたいです。ちゃんとではありませんが、育成はしていたということなので、背中はしゃべったみたいです。

また、せいぜい会話といえば、コードを通して会話をする感じでした。別にコードはしゃべらないので、レビューやペアプロを徹底してコミュニケーションを取るスタイルでやっていました。

あと、これは本当に良くないと思うのですが、認識や期待と大きく異なる成果物が出てくることが、あるじゃないですか。そういう時、私は自分でベースとなるコードを書いて渡して、「これでよろしく」と言ってしまっていました。まあひどいものですね。しかも、コードを渡すだけで、フォローすることもなく、もし気が向いたらここから学んで次に活かしてねみたいなコミュニケーションを取っていたので、これは真似しないほうがいいと思います。

これでどうなるのかですが、どうにもならないわけです。もともと適性がある人はここから伸びていくのですが、そういう人に限られるのは明らかです。

「自分が成長したのと同じように人も成長するに違いない」と思っていた

（スライドを示して）なんでこんなことをやってしまったのか。これは私がどういうふうに成長してきたかとかなり深く関係していると思います。というのも、私は高校2年の時に、プログラミングを仕事でもやってみたいというモチベーションで、この業界に飛び込みました。もちろん未経験からのスタートで、わかりやすく一番の下っ端だったはずなのですが、いつの間にかあらゆる場面でリーダーシップを取るようになりました。端的に言えば、適性があったのではないかなと思います。

私がされてきたマネジメントは、先ほどお見せした、私がしてきたマネジメントや育成とほとんど一緒です。つまり、マネジメント、育成をされていませんでした。では、どういうふうに伸びていったかというと、実践、実務の中で、あるいはプライベートの時間で、勝手にいろいろとやり出して、勝手にメキメキと成長していったパターンです。

私はハチャメチャな経歴の持ち主で、どの現場に飛び込んでも一番年下であるケースが非常に多かったので、バックグラウンドや年齢などに一切左右されずに実力主義で活躍できる環境が居心地が良かったんです。これは一応成功体験だと思うのですが、「こんな自分が」ここまで来たのだから、他の人もきっとできるはずだという、訳のわからない思い込みが生まれていました。

自分が成長したのと同じように人も成長するに違いない。だから、背中で語るというスタイルになっていました。これは非常に不幸な話です。

ついに犯してしまったプログラマーとしての禁忌

そういうかたちでエンジニア人生を歩んできたのですが、後にプログラマーとしての禁忌を犯してしまうことになります。（スライドを示して）常用のソフトウェアの有名なエピソードで、『あなたが絶対すべきでないことPart1』というのがあります。これは引用させてもらっているので、読み上げます。

「ところが、そうなんだ。彼らは意図的にやったのだ。彼らがそれをやったのは、どんなソフトウェア会社でも犯し得る、最悪の戦略的誤りによる。彼らはプログラムをスクラッチから書き直すことに決めたのだ。」

前職時代に順風満帆だったプロダクトをフルスクラッチから書き換えて、リリースしたことを言っています。

私はジョエル・スポルスキのファンで、この書も愛読していたので、当然これは知っていました。なので、この方針の提案を受けた当初は猛反対をしていたのですが、いくつか議論していく中でちょっと気が変わって、パンドラの箱をひゅっと開けてしまいました。なんで開けたのか、その理由を話すのは非常に難しいのですが、本当の意味でジョエル・スポルスキの言っていることを理解していなかったのだろうということに尽きると思います。たぶんどこかで甘く見ていたんですね。

自身の技術的決断によって引き起こしてしまった最悪な状況

その結果、プロダクトはさまざまな要因によってシェアを落とすことになります。会社の主力事業だったので、シェアを落とせば会社は大打撃を受けます。私の軽率なジャッジが、プロダクト、事業、会社、ユーザーなど、あらゆるところにご迷惑をおかけすることになってしまいました。これは私の中ではトラウマ級の出来事で、今でもよく夢に見ます。結局のところ知識として知っていたとしても、実際に自分の身で経験してみなければ、本当の意味で彼（ジョエル・スポルスキ氏）の言ってることは理解できていなかったという出来事です。

（スライドを示して）総括すれば、これはあまりにも未熟だったということに尽きます。育成は行なっていなかったし、もともと適性がある人が私のように育っただけです。これはもちろん再現性がなく、開発組織を効率的に拡大できませんでした。

そうなってくると、会社として仕事をこなすためには即戦力の方々に業務委託して、どうにかがんばっていこうという感じになります。しかし、これもほとんどコードに近い設計を渡すという、マネジメントというより、マネジメントの皮を被ったプログラミングみたいな、要するに私のパフォーマンスに完全に依存するモデルで、スケーラビリティがない最悪な状況でした。

しかも、経営的な打撃を与える前述の技術的決断をしてしまいました。これをカバーする組織に育っていなかったので、リカバリーを自分自身がやることになるわけです。自分の尻を自分で拭うと言えば、美談に聞こえるかもしれません。ただ、事業的に他にもやることがたくさんあったにも関わらず、リカバリーに手一杯で手が回らなくて、しかも、そのリカバリーにものすごく時間を要して、悪循環としか言いようがない状態に陥っていました。

転機その1　『リーン・スタートアップ』との出会い

こうした未熟さを噛み締めながらいろいろやったのですが、結局私は転職をすることになります。そんな私に訪れた最初の転機として紹介したいのが、『リーン・スタートアップ』です。

（スライドを示して）2014年、当時のVOYAGE GROUPに転職した時、当時の事業責任者から『リーン・スタートアップ』という書籍をプレゼントされました。これはこれまでオープンソース開発と受託開発を中心にやってきて、自社サービス開発が初めてだった私にとっては、福音とも言える内容でした。『リーン・スタートアップ』はみなさんによく知られた書籍だとは思うのですが、改めてどういうものか説明します。引用を読み上げます。

「リーン・スタートアップという名前は、トヨタの大野耐一と新郷重夫が開発した生産方式にちなんだものだ」ということですが、これは正確ではありません。トヨタはリーン生産方式という名前を付けてはいません。続けます。「リーン・スタートアップでは検証による学び（validated learning）を単位として進歩を計測する。科学的な学びを基準にすれば、スタートアップの足を引っ張る無駄を発見し、源から断つことができるのだ」

というわけで、未経験だった私は、事業開発は企画者の思いを出発点として、それを体現していくモデルだと思っていました。そういうモデルでやっているところはあると思いますし、それで成功している事例も山ほどあります。ただ、この本で触れられているアプローチは、それとはまったく異なります。

この本で紹介されているのは、顧客と対話をしながら早いフィードバックサイクルで仮説検証を繰り返していくというもので、非常に科学的なアプローチだと言えると思いますが、エンジニアである私は、このアプローチに強く親近感を抱きました。

というのも、何かに似ているなと思ったわけです。出典はちょっと不明ですが、よく知られるフレーズとして、「Don't guess, measure!」という言葉がありますね。「推測するな、計測せよ」。そして、リチャード・P・ガブリエルの「Worse is Better」「悪いことはいいことだ」このどちらのフレーズも古くより、ソフトウェアエンジニアの中では知られたフレーズです。

こうした親和性を目の当たりにして、私は事業がなんだか一種のソフトウェアのように感じました。そうか、事業もエンジニアリングしていいんだなという気づきになったわけです。

『Engineers in VOYAGE』でちょっと触れていますが、ここで学んでいくつか試行錯誤を繰り返した結果、実は現職でも神攻略（神ゲー攻略）に至る前にいくつかの新規事業を手がけて、けっこう失敗してきています。その失敗要因は、MVPの意識を変えたり、仮説検証をサボるなど、『リーン・スタートアップ』に書いてあるようなことです。

書籍の知識を得たにも関わらず、失敗してしまうのは、まったく凝りていないなという感じではありますが、ともあれ、そうして築いていった価値観、教訓みたいなものが「神ゲー攻略」というプロダクトの成長に実際に反映されて、活かされて、今結果として出ているので、ある意味では前職からの失敗を、ちょっと克服できたのかなと思っています。ただ、未だトラウマは拭えていません。

転機その2　「技術力評価会」での評価する側としての経験

事業に対する気づきを得た私に訪れた、転機その2は、「技術力評価会」です。（スライドを示して）CARTA HOLDINGSのエンジニア評価で有名なものとして、技術力評価会が挙げられると思います。VOYAGRE GROUP時代のCTOの小賀（小賀昌法氏）の「5分でわかる技術力評価会」という資料があります。いい資料なので読んでもらいたいのですが、時間の関係でこれを30秒で説明します。用意スタート。

技術力評価会は、エンジニアがエンジニアを相互に評価し合う制度で、半期でやったことや考えてきたことをレポートにまとめて、異なる部署のエンジニア2名に1時間半かけて説明して、議論し合います。評価者2名は、各々の専門性からそれを評価して、評価結果レポートを記します。このレポートは当事者だけではなく、全社に公開されてナレッジとなります。さらにこれは、人事評価においてかなりのウェイトを占めています。

（スライドを示して）こういうおもしろい制度があるわけですが、この技術力評価会における評価する側としての経験が、私を変えたと思っています。

私は、十数回ほど評価者として多種多様な評価会に参加していて、それが、知識としては知っていることでも実際にやってみたらどうなのかというリアルな事例や、社内的なトレンドに強制的に触れる機会となっています。

1時間みっちり話してもらって、質問などでガンガン深堀りするというのは、思考の過程を見せてもらっているのに等しいわけです。そうした中には、その発想はなかったとか、あるいは自分はこのやり方は取らないなというようなものも、あります。自分と同じプロセスのほうがいいこともあれば、被評価者の方が実行したプロセスのほうがいいことも山ほどあります。

ただ、いずれにせよ、自分は取らなかったであろうアプローチの結果を目の当たりにできるのは、「ifの世界」をいろいろ覗き見しているのに似ているなと感じました。

そうした中で、人の評価に関わることなので、評価される側よりも評価する側のほうが責任重大だなと感じることが多くありました。そうなると、自分とは違うアプローチも真剣に検討しますし、自分だったらどうするのかと思いを馳せて、常に考えることになります。

人のためのアクションなのですが、意外なことに他者とは違う自分の強みを自覚することにつながりました。自分だからできること、それからこの人だからできることはいろいろありますが、有効なアドバイスをするには後者の、この人だからできることの比重が高いほど基本的にはいいです。もちろんあえて崩す場合もあります。

思考プロセスをまるごと共有してもらって、それを踏まえて議論して、真剣に評価、アドバイスしていこうとすると、どうしてもこうした境界を浮き彫りにしないといけなくなるので、非常にいい訓練になったなと思っています。

（次回へつづく）