2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
リンクをコピー
記事をブックマーク
海老原昂輔氏:「コードを書いていたいけど、マネジメントもやるようになっちゃった人のための生存戦略」というタイトルでトークをします。株式会社Lighthouse Studio CTOの海老原と申します。よろしくお願いします。
この「コードを書いていたいけど、マネジメントもやるようになっちゃった人」が何かと言うと、こういうキャリアがありがちなのではないかと思って持ってきました。(スライドを示して)言うまでもなく、私自身がこういうキャリアを歩んでしまっているというわけです。まず、プログラミングが楽しすぎます。楽しんでやっていながらお金になるとか、誰かの役に立つとか、最高だとはしゃいでいたところに、何かしらの環境の変化が生じてしまうことがあります。
例えば転職や創業、チームの拡大や事業の急成長、部門の統廃合、M&Aなど、ポジティブなところはいろいろありますが、ネガティブな場合、業績の悪化や離職者の続出、前任者の退職で繰り上がることもあります。内的要因、外的要因、さまざまありますが、このような変化が生じた結果、CTOやPdM、EMテックリードになっています。
本日集まってくださった方の中で、このような方がいたら挙手をお願いします。たくさん手を挙げていただき、ありがとうございます。オンラインなので、みなさんの挙手を目で見ることはできなかったのですが、しかと心の目で見たので、大丈夫です。私はこういう方がたくさんいることを実は知っていました。
というのも、最近スカウトのたびに、いろいろな方々の経歴やアウトプットなどをよく見ているのですが、最近本当にこういう方が多く、見つけるたびに私は「あ、仲間だ」と勝手にうれしくなってしまいます。ともあれ、このセッションはそうした方々がメインターゲットとなっているので、ぜひ楽しんでもらえればなと思っています。
(スライドを示して)免責ですが、本発表に含まれる内容は、CARTA HOLDINGSの前職も含め、各所での経験をベースに育まれた私、海老原の個人的見解に基づくものとなっています。CARTA HOLDINGS全体の方針と大きくずれていることはないと思うのですが、細かいところで食い違うところがあるかもしれないので、そのあたりはご容赦いただければなと思います。
それから、これはあくまで私個人の事例の紹介にすぎないので、すべての人に適用できるアプローチとは限りません。ただ、一種のパターンとして何か取り入れてもらって、みなさんの現実の問題の解決にお役立ていただければすごくうれしいですし、ポジティブでもネガティブでもフィードバックをもらえれば、非常に幸いだと思います。よろしくお願いします。
ちょっと前置きが長くなってしまって申し訳ないのですが、これはお願いです。私の経験に基づく話をする関係で、前職時代の経験にどうしても触れざるを得なくなってしまいました。これはちょっと私の中では黒歴史に近い部分があって、あまり触れたくない気持ちが正直本音としてあります。しかし、これは避けられなかったので、がんばってグッと堪えて、話そうと思います。
私もがんばるので、みなさんにもちょっとがんばっていただきたいことがあります。本発表の主題は、あくまで私自身の話であって、前職、プロダクトの話は主題をわかりやすくするための例に過ぎず、あまり関係ない話です。なので、説明が不十分だったり、一方的な見解だったり、言葉足らずなど、いろいろあると思うのですが、私の伝え方のところが言及されることによって、さまざまな印象がついてしまうことがないようにしたいので、これはご理解いただけますと幸いです。
前置きその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』というのがあります。これは引用させてもらっているので、読み上げます。
「ところが、そうなんだ。彼らは意図的にやったのだ。彼らがそれをやったのは、どんなソフトウェア会社でも犯し得る、最悪の戦略的誤りによる。彼らはプログラムをスクラッチから書き直すことに決めたのだ。」
前職時代に順風満帆だったプロダクトをフルスクラッチから書き換えて、リリースしたことを言っています。
私はジョエル・スポルスキのファンで、この書も愛読していたので、当然これは知っていました。なので、この方針の提案を受けた当初は猛反対をしていたのですが、いくつか議論していく中でちょっと気が変わって、パンドラの箱をひゅっと開けてしまいました。なんで開けたのか、その理由を話すのは非常に難しいのですが、本当の意味でジョエル・スポルスキの言っていることを理解していなかったのだろうということに尽きると思います。たぶんどこかで甘く見ていたんですね。
その結果、プロダクトはさまざまな要因によってシェアを落とすことになります。会社の主力事業だったので、シェアを落とせば会社は大打撃を受けます。私の軽率なジャッジが、プロダクト、事業、会社、ユーザーなど、あらゆるところにご迷惑をおかけすることになってしまいました。これは私の中ではトラウマ級の出来事で、今でもよく夢に見ます。結局のところ知識として知っていたとしても、実際に自分の身で経験してみなければ、本当の意味で彼(ジョエル・スポルスキ氏)の言ってることは理解できていなかったという出来事です。
(スライドを示して)総括すれば、これはあまりにも未熟だったということに尽きます。育成は行なっていなかったし、もともと適性がある人が私のように育っただけです。これはもちろん再現性がなく、開発組織を効率的に拡大できませんでした。
そうなってくると、会社として仕事をこなすためには即戦力の方々に業務委託して、どうにかがんばっていこうという感じになります。しかし、これもほとんどコードに近い設計を渡すという、マネジメントというより、マネジメントの皮を被ったプログラミングみたいな、要するに私のパフォーマンスに完全に依存するモデルで、スケーラビリティがない最悪な状況でした。
しかも、経営的な打撃を与える前述の技術的決断をしてしまいました。これをカバーする組織に育っていなかったので、リカバリーを自分自身がやることになるわけです。自分の尻を自分で拭うと言えば、美談に聞こえるかもしれません。ただ、事業的に他にもやることがたくさんあったにも関わらず、リカバリーに手一杯で手が回らなくて、しかも、そのリカバリーにものすごく時間を要して、悪循環としか言いようがない状態に陥っていました。
こうした未熟さを噛み締めながらいろいろやったのですが、結局私は転職をすることになります。そんな私に訪れた最初の転機として紹介したいのが、『リーン・スタートアップ』です。
(スライドを示して)2014年、当時のVOYAGE GROUPに転職した時、当時の事業責任者から『リーン・スタートアップ』という書籍をプレゼントされました。これはこれまでオープンソース開発と受託開発を中心にやってきて、自社サービス開発が初めてだった私にとっては、福音とも言える内容でした。『リーン・スタートアップ』はみなさんによく知られた書籍だとは思うのですが、改めてどういうものか説明します。引用を読み上げます。
「リーン・スタートアップという名前は、トヨタの大野耐一と新郷重夫が開発した生産方式にちなんだものだ」ということですが、これは正確ではありません。トヨタはリーン生産方式という名前を付けてはいません。続けます。「リーン・スタートアップでは検証による学び(validated learning)を単位として進歩を計測する。科学的な学びを基準にすれば、スタートアップの足を引っ張る無駄を発見し、源から断つことができるのだ」
というわけで、未経験だった私は、事業開発は企画者の思いを出発点として、それを体現していくモデルだと思っていました。そういうモデルでやっているところはあると思いますし、それで成功している事例も山ほどあります。ただ、この本で触れられているアプローチは、それとはまったく異なります。
この本で紹介されているのは、顧客と対話をしながら早いフィードバックサイクルで仮説検証を繰り返していくというもので、非常に科学的なアプローチだと言えると思いますが、エンジニアである私は、このアプローチに強く親近感を抱きました。
というのも、何かに似ているなと思ったわけです。出典はちょっと不明ですが、よく知られるフレーズとして、「Don't guess, measure!」という言葉がありますね。「推測するな、計測せよ」。そして、リチャード・P・ガブリエルの「Worse is Better」「悪いことはいいことだ」このどちらのフレーズも古くより、ソフトウェアエンジニアの中では知られたフレーズです。
こうした親和性を目の当たりにして、私は事業がなんだか一種のソフトウェアのように感じました。そうか、事業もエンジニアリングしていいんだなという気づきになったわけです。
『Engineers in VOYAGE』でちょっと触れていますが、ここで学んでいくつか試行錯誤を繰り返した結果、実は現職でも神攻略(神ゲー攻略)に至る前にいくつかの新規事業を手がけて、けっこう失敗してきています。その失敗要因は、MVPの意識を変えたり、仮説検証をサボるなど、『リーン・スタートアップ』に書いてあるようなことです。
書籍の知識を得たにも関わらず、失敗してしまうのは、まったく凝りていないなという感じではありますが、ともあれ、そうして築いていった価値観、教訓みたいなものが「神ゲー攻略」というプロダクトの成長に実際に反映されて、活かされて、今結果として出ているので、ある意味では前職からの失敗を、ちょっと克服できたのかなと思っています。ただ、未だトラウマは拭えていません。
事業に対する気づきを得た私に訪れた、転機その2は、「技術力評価会」です。(スライドを示して)CARTA HOLDINGSのエンジニア評価で有名なものとして、技術力評価会が挙げられると思います。VOYAGRE GROUP時代のCTOの小賀(小賀昌法氏)の「5分でわかる技術力評価会」という資料があります。いい資料なので読んでもらいたいのですが、時間の関係でこれを30秒で説明します。用意スタート。
技術力評価会は、エンジニアがエンジニアを相互に評価し合う制度で、半期でやったことや考えてきたことをレポートにまとめて、異なる部署のエンジニア2名に1時間半かけて説明して、議論し合います。評価者2名は、各々の専門性からそれを評価して、評価結果レポートを記します。このレポートは当事者だけではなく、全社に公開されてナレッジとなります。さらにこれは、人事評価においてかなりのウェイトを占めています。
(スライドを示して)こういうおもしろい制度があるわけですが、この技術力評価会における評価する側としての経験が、私を変えたと思っています。
私は、十数回ほど評価者として多種多様な評価会に参加していて、それが、知識としては知っていることでも実際にやってみたらどうなのかというリアルな事例や、社内的なトレンドに強制的に触れる機会となっています。
1時間みっちり話してもらって、質問などでガンガン深堀りするというのは、思考の過程を見せてもらっているのに等しいわけです。そうした中には、その発想はなかったとか、あるいは自分はこのやり方は取らないなというようなものも、あります。自分と同じプロセスのほうがいいこともあれば、被評価者の方が実行したプロセスのほうがいいことも山ほどあります。
ただ、いずれにせよ、自分は取らなかったであろうアプローチの結果を目の当たりにできるのは、「ifの世界」をいろいろ覗き見しているのに似ているなと感じました。
そうした中で、人の評価に関わることなので、評価される側よりも評価する側のほうが責任重大だなと感じることが多くありました。そうなると、自分とは違うアプローチも真剣に検討しますし、自分だったらどうするのかと思いを馳せて、常に考えることになります。
人のためのアクションなのですが、意外なことに他者とは違う自分の強みを自覚することにつながりました。自分だからできること、それからこの人だからできることはいろいろありますが、有効なアドバイスをするには後者の、この人だからできることの比重が高いほど基本的にはいいです。もちろんあえて崩す場合もあります。
思考プロセスをまるごと共有してもらって、それを踏まえて議論して、真剣に評価、アドバイスしていこうとすると、どうしてもこうした境界を浮き彫りにしないといけなくなるので、非常にいい訓練になったなと思っています。
(次回へつづく)
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには