ITベンチャーの実務とリーダーシップ、そしてターンアラウンド | 金輝俊、Hwi Jun KIM

ITベンチャーの実務とリーダーシップ、そしてターンアラウンド | 金輝俊、Hwi Jun KIM

• euler.bonjour@gmail.com / https://github.com/khj1977 / @pcaffeine77

• 戦略コンサルタント 兼 ITアーキテクト

• 金輝俊 / Hwi Jun KIM

目次

• イントロダクション

• 本論

• 戦略子会社Coreでのベンダーコントロール。初の管理職 -リーダーに-

• デザイン周りのすったもんだ

• ベンダーコントロールと挨拶メール

• コミュ能力不足の早慶インターン

• CoreのPL、CFと本社管理部門長

• リリース周り、色々

• 鼻っ柱の強い元米系有名企業のデザイナー

• 運用とプロモーション、そして、振り返りミーティング

• 投資家がほぼ、Chief IT Architect時代と同じ件について

• 本社が営業利益ベースで赤字。ターンアラウンドへの決意と実行

• ターンアラウンド

• スマフォ版ポイントサービス開発。誤算の酷いレガシーコード

• スマフォ版会員登録機能とチーム全体での安堵感

• 各種施策の開発と執行

• リリース管理、安心感とスピード。ツールより重要なもの

• サーバーが過負荷に。誰が原因か分からない

• 毎月の表彰と保たれる緊張感

• 目標達成まで、あと100万円/月と緊迫感

• ターンアラウンド成功

• 成功と別事業部への移行。開発 / マーケ / オフショアのリーダーに

• 諸々の反省点

• 組織とマネージメント。当時のこの会社の欠点

• 職位の名称と組織。そして、JD

• 社内コミュニケーション。飲み会とは限らない

• 労務管理はマネージャーの基本

• かっこいいオフィスは要らない

• 社内ベンチャーのインセンティブ設計

• ベンチャー特有の未熟さ。では、どうすれば？

• 余談

• ベンチャーの実務で必要とされるもの

• ビジネスと大義

• 著者略歴

イントロダクション

ハイテクITベンチャーで検索エンジンとレコメンデーションエンジンの研究開発の日々。二社通算して、Product Manager、Chief IT Architectとして、筆者が主体的に使った額はおおよそ、1億3000万円くらい。両社の資本金と資本準備金を合計すると、約10億円近い。

Google Globalに資金力不足で敗れ去った。Google Japanは和文職務経歴書で応募できる。Google Japanに和文職務経歴書で応募して、英文経歴書を日本人人事から要求された。Google Japan所属の英米のエンジニアが書類選考と面接でもするのかと思ったが、何だか嫌になり、選考を降りた。

普通のWeb系の管理職の世界へ。

渋谷系のあるWeb系企業に内定した。入社初日は1月初営業日。社員数は数十人規模。オフィスは全面ガラス張り、非セキュリティエリアに会議室が5つある。一つは外から見えない和室。他は全て、壁面全体がホワイトボードになっている。机はブーメンラン型。部門ごとに机がハニカム状に連結され、人の回遊設計が上手い具合行くようになっている。もちろん、ウォーターサーバーとリクライニングチェアあり。カウンター席まである。最後に、この規模にしては珍しく、独立した社長室があり、これも、全面ガラス張りで中に6人くらい座れる、会議セットがある。

全社朝会で挨拶。サーバーサイドプログラムの金です。よろしくお願いします。さて、仕事と。

社員はMacとWindows、どちらか選べるが、当時はWindows派で、Windowsの13inchノートPCにした。全体的に薄肉軽量の合金で出来ていて、剛性が高い。キーボードが打鍵しやすい。VirtualboxとLAMPスタックでも、構築するか。その前に、POP/SMTPメーラーとスケジューラー、と。あ、ICカードも貰わなきゃ。あ、これ、筆者の名刺ね。

チームメンバーとのランチ？もちろん行くよ。えっ、社長も来るの？もちろん、いいですよ。

昼になった。社長が来ない。人事の人に聞く。おかしいですね。まだ来ないですね。1時間くらい後に来た。軽くウケたけど、まあいいか。社長は取締役で雇用契約じゃないし。緩い会社なのかな？入社前はそこまで読めてなかった。

じゃあ、昼飯、行きましょうか？あっ、社長が店選ぶんですね。最終面接以来ですね。よろしくお願いします。

新規事業、所属チームのメンバーとご飯を食べた。皆で骨つき肉にかぶり付く。

あー、ランチ、美味しかった。社長、奢ってくれるんですか。ゴチです。社長、MOとか知ってるんですね、懐かしい。軽くウケました。結構、気さくな人なんだな。馴染めそう。

そう言えば、子会社のCoreに出向措置になんだよね。本社にも席あるけど、サテライトオフィスあるんだっけ？人事の人、どこにそのオフィスあるの？教えて。あ、すぐ近くだね。ありがとう。では、行ってみるか。

普通の雑居ビル。子会社だから、PLを考えて、地代家賃は抑えめにしているんだろう。経営の定石だね。好印象。結構広いじゃん。40 - 50m2くらいかな。爆笑。この広さに一人しかいない。メンバーはこっちで仕事してるんだ。俺も、こっちにしようかな。Wifiあるの？あるんだ。ノートPC持ってこよう。ふーん、机は普通の超小径のやつ。ホワイトボードあるね。会議室のスラブもパーティションもなし。まあ、いいや。丸いカフェテーブルあるから、そっちで会議すればいいや。ドベンチャーだね。

これ、人件費は本社と子会社、どっちにつくの？本社か。じゃあいいや。資本金は1000万ね。後で、PL見せて。よろしく。あ、開発は協力会社なんだ。Coreは企画、管理ね。俺はベンダーコントロールするね。相手側の窓口のメルアド教えて、あいさつのメールするから。

インフラとの会議？あー、Coreの新規サービスのインフラ構成についてね。いいよ。本社でやるの？まあ、近いし、いいかな。新しく入りました、金ですよろしくお願いします。あー、こういうインフラ構成が協力会社から提案されてるんだ。Apache PreforkとApache Workerの二段構成なんだ。Workerはリバースプロキシーのつもりかな。nginxの方が、多分、理論的には速いと思いますよ。やっぱり、インフラもそう思います。では、リリースの時に私がnginx組み込みますね。何かありましたら、よろしくお願いします。

人事との本社での会議？いいよ。あー、管理職って三段構成なんだ。Sub Manager、Manager、General Managerね。まあ、でも、俺はmanagerになるつもりないし。管理はするけど。やっぱりそう思う？内心「別にヒラでもいつも通りの結構いい給与だし、リーダーでベンダーコントロールできるし、職位はどうでもいいや」。じゃあ、よろしくね。

エレベーターホールにて。金さんチース。あ、よろしくね。この企業、やっぱ、全体的にノリが軽いな。やりやすそう。

数日後。

エレベーターホールにて。あっ、金さん、おはようございます。あれ、なんだか改まってるな。そういう人増えたな。あー、なんか、俺が元Chief IT Architectだって漏れたみたいだな。まあ、いいや。さて、Coreオフィスに行くか。

戦略子会社Coreでの本格的な仕事が始まる。

本論

戦略子会社Coreでのベンダーコントロール。初の管理職 -リーダーに-

デザイン周りのすったもんだ

子会社のCore所属はとりあえず、3人。エンジニアでベンダーコントロール担当の筆者、プランナーの女性、早慶4年、インターンの男性。インターンはプランナー。一応、ディレクターなのかな。筆者が直ぐにリーダーシップを取るようになったんだけどね。今まで、チームを引っ張ったのかな。何かプランナーに偏ってるな。まあ、いいや。

ここで、今運用していているのはソーシャルギフトサービス。次期バージョンは完全に作り替える予定で、協力会社が開発中。メールでの連絡とたまに、Coreで会議をしているよう。ちなみに、車内のコミュニケーションはSkypeテキストメッセを使っているよう。まだ、Slack時代ではない。

現代のスマフォでSlackなら、余裕でスマフォでどこでも、仕事上のコミュニケーションができるが、Skypeは微妙に重く、スマフォのスペックも高くなくて、PCベースでしか、仕事上のコミュニケーションはない。メールもPOP/SMTPでスマフォで会社メールをするという発想がない。現代だと、独自ドメインのGMailとSlackでスマフォでどこでも、仕事上のコミュニケーションが出来て便利。特に管理職にとってはね。

やっぱりね。朝会やっても反応が悪い。そもそも、スタンドアップミーティング、やった事ないのかな。徐々にインプリしよう。これ、単なる儀式でもイニシエーションでもなくて、自分がやることをはっきりさせて、リーダーの意志を伝達して、日々、チームの見解をアラインするのに重要なんだよね。徐々に、分かってもらおう。

現在のバージョンのギフトサービスを見せてもらった。入社前の会社のリサーチをした時はこのサービスは知らなかった。一言で感想を言うと、酷い。何だ、このクリエイティブあり得ない。サーバーサイドのコードも大概。プランナーの女性も一致した意見。

社長とインターンは海外出張中。プランナーと話し合った。こんなの、自分の知り合いに紹介できない、と言うのが一致した見解。トップページだけでも、本社デザイナーに作り替えてもらおう。Viewだけなら、サーバーサイドは弄らなくていいはず。単純なアーキテクチャーっぽいし。

結構いいのができた。よし、デプロイしちゃおう。実はここでも、ウケる事があった。当時、capistranoでのコマンド一発でのリリースはメジャーになっていたと思う。ここでも、本社のサービスはWebstranoに統一されていた模様。このギフトサービスにはそれがない。しょうがない。筆者は本来、そう言う事をする人ではないが、設定した。めんどいけど、カスタマイズ用のスクリプトも書いて、テストデプロイ。OK。これで、安心して改造できる。

リリースされた。

翌日、社長からメール。怒られた。プロデューサーである自分を通さないのはおかしいと。ここは、社長直轄の組織。上長は社長である。うーん、社長承認、か。いちいち取るかな。でも、そうと言えばそうかな。Chief IT Architectで何でも自分で判断できた時の癖が残っていたかな。素直に謝った。ただし、現在のクリエイティブは認めてもらえた。そのまま、本番適用。

ベンダーコントロールと挨拶メール

ちょっと、ベンダーのCTOと社長のメルアド教えて。OKこれね。メール書くか。「こんにちは、初めまして、今度、Coreで管理窓口となりました金と申します。よろしくお願いします。ところで、キャッシュにRedis使われる予定ですね。なぜ、Memcacheじゃなくて、Redisなのでしょうか？多分、両者ともデータ構造はハッシュなのでは？Memcacheは確かデータを永続化してなくて、揮発性なのかな。Redisって、データを永続化するんでしたっけ？でも、仮にそうだとして、キャッシュに永続化、必要ですか？確実にRedisが有利な理由でもあるのでしょうか？よろしくお願いします。」さて、本社全員MLをCCに入れて、と。これで挨拶状になったかな。仕事に戻るか。

コミュ能力不足の早慶インターン

今日は協力会社とのCoreオフィスでのミーティング。小さな会社で社長がプロデューサーみたいな事をやっている。あっ、こんにちは、よろしくお願いします。じゃあ、インターン、司会進行よろしくね。あれ、その資料、君しか持ってないんだけど。えっ、ファイルサーバーにあります。場所どこ？聞いてないし。俺は知ってる？だから、速攻でプリントアウトして。すいません、まだインターンなんで。

こんな事の連続。意外にも色々出来ないとわかったので、プランナーと話して、このインターンを皆で積極的にサポートする事にした。仕事ができないのはインターンだから、それはそうかもしれないけど、どうだろう。でも、この人、DeNAでもインターンしてたんだよね。うーん。そんなものなのかな。まあ、いいや。ちょいちょい、指導入れよう。社長面接でも、社内教育の事、半ば言われたし。

CoreのPL、CFと本社管理部門長

Coreの資本金は1000万円。人件費は本社付。余裕じゃんと思ったら、よくよく考えたら、協力会社への開発費が発生する。ここにはリアルな数字は書かないが、聞いた。これ、やばいんじゃ。ちょうど、本社管理部門長がCoreオフィスに来た。どう調子？結構いいですよ、面白いですね、色々。どう、自販機置かない？赤字の投資フェーズでそれはないですねー。ところで、ここ、そろそろPL的にヤバいんじゃ。PLはそうでもないよ。CF、キャッシュフローだと確実におかしいですよね。ベンチャーはキャッシュ命だと思いますよ。減価償却とかどうでもいいし。そうだよねー。ちょっと考えておくね、じゃあ。

さて、ここから先は偉い人に任せて、ベンダーコントロールに戻るか。

リリース周り、色々

たまに協力会社の社長とオフィスで話して、進捗の確認、特にクリエイティブ。アイキャッチ、UIなど。前回が酷かったからね。皆、こだわった。議論して、小幅な改変がかかるくらい。うん、いいんじゃないかな。

リリース前に画像が納品された。ダメ、クオリティが低い。プロトタイプと絵そのものは同じだが、解像度が低い。プランナーは、しょうがない、と言う。おそらく、画像のロード時間を解っているんだろう。どうだろう？おそらく、行ける。画像が大量にあるわけじゃないし、光回線が主流だし。これはPC向けのサービス。画像のクオリティは重要。多少なら、画像の容量を増やしてもOKなはず。プランナーと話して、画像の解像度/クオリティを増してもらうように、先方に連絡をしてもらった。

リリース日前にコードが納品された。サーバーサイドのコードを確認。あまりにも書き方が古すぎる。DBはMySQLを使っているが、何故か、非正規化している。もしかして、あまりにも高負荷になると踏んで、やった？先方はどうやらソシャゲ案件もやったことがあるみたいだから、非正規化も知っているのかもしれない。軽く先方のCTOと電話で話して、終わりにした。

本番サーバーはクラウド。筆者がミドルウェアをセットアップして、Webstranoを設定。デプロイした。まだ、Basic認証がかかっていて、外部からアクセスできない。

リリース時間が来た。外部への正式アナウンスはまだしない。本社を含めた社内へのアナウンスだけした。

サーバーのレスポンスが遅い。予想通り。やはり、Apache preforkじゃパフォーマンスが出ない。写真が重いのもあるかもしれないが、それはおそらく、微小。許容範囲内じゃ。問題はUI周りで大量のJSを読み込んでいる。速攻であらかじめテストしておいた、nginxの設定を済ませて、リバースプロキシーとして、Apache preforkと協調動作させる。テスト。明らかに速くなっている。OK。全体的に軽くテストして、正式リリース。

本社に行き、社長に報告に行く。何で、最初、重かったのか、何故いきなり速くなったのか質問された。nginxの話をなるべく、分かりやすく説明して、終わり。お疲れ様。

Coreオフィスに戻った。しばらく、何らかのエラーがないか見守る。数時間経って、外に飯がてら、休憩に行った。解放感。システム開発と言えば、やっぱり、これだよね。

鼻っ柱の強い元米系有名企業のデザイナー

やっとデザイナーが来た。リリース後にアジャイルに開発するときに、どうしてもデザイナーは必要。開発は内製化をやはりしたいし。へー、昔、アメリカで働いていいたんだ。有名企業だね。凄いね。初日に皆でランチに行った。一発で鼻っ柱が強いと分かる。二日目か三日目くらいにThunderbolt Displayが私物で持ち込まれた。PCも何故か、私物のMacBook Proだし。ウケた。筆者も自分の23inchモニターを持ち込んでいて、デュアルディスプレイだけどね。実は本社組より、Coreの質素なオフィス組の方が、IT機器のコストは高い。時代は低い地代家賃とデュアルディスプレイだと思う。ディスプレイでランニングコストはほぼ増えないし。

運用とプロモーション、そして、振り返りミーティング

リリースされた。あとはプロモーション。adwordsとか何か、広告貼るのかな？インターンが担当なので聞いた。曖昧な返答。やっとくように言う。同時に本社に行き、プロモーションに詳しそうな人にヒントをもらいに行く。アフィでプロモーション？イマイチ腑に落ちなかったが、とりあえず、考えてみる事にする。今は腹落ちしているが、瞬時には掴めなかった。

そして、数日が過ぎる。PVもDAUも上がってない。インターンに聞く。どうプロモーション？何故、やらない？いきなり、100万張れとは言わない。とりあえず、5万円くらい使ってみたら？君の担当だよね？何故か、暗い感じを醸し出す。

実は子会社の残キャッシュを半ば分かっていて、期間は2 - 4週間しかないと分かっていた。本社に頼んで、増資しては？という意見も出ていた。インターンに何がこのプロジェクトでダメだったかをハッキリと理解してもらうために、ミーティングを組んだ。場所は本社会議室。壁全面のホワイトボードが必要だ。質問事項をインターンに浴びせ、何がここ数ヶ月で起こったのか可視化する。最後に、30秒、何故、ダメだったか考えて欲しいと伝えた。観念したようだ。次へ行こう。同席したデザイナーは何も言わなかったが、納得した様子。

同時に、このプロジェクトの一時中断が社長から伝えられる。本社でスマフォ向けポイントサービスのグロースを同じチームで担当して欲しいとのこと。ある程度、PVと売り上げ高は既にある。アーリーレイターかミドルアーリーくらい。

何故そうなったのか？次節以降、記述する。

投資家がほぼ、Chief IT Architect時代と同じ件について

閑話休題：実はこの会社のVC、投資家陣と前職のハイテクITベンチャーは重なっている会社が多い。最初から筆者が参画するか知っていたか知らないが、少なくとも、おそらく、途中で知ったであろう。それでも、筆者には余計なプレッシャーは来なかった。結論から言うと、筆者はこの会社で売上高増加に貢献し、VCに一勝一敗の戦績を渡した事になる。これで、貸し借りなしであろう。寛大なVC陣にこの場を借りて感謝する。もちろん、VCは経済合理的に動いていると知っているけどね。

本社が営業利益ベースで赤字。ターンアラウンドへの決意と実行

ターンアラウンド

本社に同じチームで呼び戻された。元DeNAの新卒プランナー、元米系有名企業のデザイナー、元ハイテクITベンチャーのChief IT Architect。そして、新卒のオペレーションとパーシャルアロケーションで熟練のプロデューサーが加わる。

全社ミーティングで会社が営業利益ベースで赤字になった事を具体的な数字入りで発表された。スクリーンには表ぐみが映し出されていた。

一度、Coreオフィスに戻って、考えた。

本社に戻ると同時に社長室にアポなしで行き、会社の残キャッシュ、サービスグロースまでの期間を聞き出す。現状の本社で運用しているサービスと全体の売上高、社員数、PVなどを考えれば、行けると踏んだ。

三ヶ月以内に単黒に持っていって欲しいと、社長に半ば言われた。キャッシュはそれ以上、あると筆者は知っているけどね。了解。

会社のターンアランドに挑む事にした。実はこの会社は売上高が結構出ていて、元々、営業利益率もそこそこ。資本金が結構低いROIが非常にいい企業。VCから見ても、配当を出してもらえば、かなり美味しいはず。結構な隠れ優良企業である。

スマフォ版ポイントサービス開発。誤算の酷いレガシーコード

スマフォ版ポイントサービスにCoreメンバー三人で参加。オフィスはあえて、本社にしないで、サテライトオフィスに。実は、こっちの方が地代家賃の高い本社オフィスより色々使いやすい。例えば、すぐそこにホワイトボードがあって、すぐに議論できるとかね。ベンチャーは会議室に入ったら負けだと思ってる。思い立ったら、すぐ議論。スピードを高めるためにね。

あとはアフィリエイトなどの上げ下げ、メルマガなどのオペレーション担当とプロデューサー。プロデューサーはPC版ポイントサービスと兼任。たまにCoreオフィスに来ることに。

最初の会議。会員登録機能を作って欲しいとの事。スマフォ版は一応あるものの、あまり機能がなく、色々不足してるっぽい。なるほど、会員登録がないのは意外だけど、重要。作りますよ。最速で3日で実装、テスト、リリースまで行けるけど、今回は初見のシステムでDBの構造も分からないから、安全策をとって、アジャイル通例の2週間で。

OK。それで行こう。

スマフォ版会員登録機能とチーム全体での安堵感

何故、酷いコードなのかちょっと考えてみた。このサービスのPC版は多分、会社設立当初からのサービスなのだろう。MVCですらないけど、まあ、MVCフレームワークがPHP用にあるかないかのギリギリの年代だから、しょうがないのかな。多分、プロのプログラマーじゃなくて、社長が書いたものだし。

しのごの言っていても、しょうがない。コードリーディングとDBの構造やリレーションを解き明かして、開発に行こう。

結局、多少、苦労したものの、2週間くらいでリリースした。デザイナーとの協調関係もいい。さて、昼休みも終わっただろうし、Webstranoでリリース。

何？管理画面を見て。すごい、もう、スマフォ経由の会員登録来てる。リロードすると面白いな。例のプロモーションの成果か。このシステムよくできてるんだよな。これは、PC時代の成果。プロデューサーはこれを狙っていたのかな。気づかなかった。面白い。

これだったら、行ける。皆、顔にそう書いてあった。

数時間待つ。夕方。バグ報告はない。軽微なwarningだから無視。ミッションクリティカルなシステムや重要なバグなら、速攻で直すが、そうでないなら放っておく。あくまでも、プログラミングはビジネスとマーケティングの手段だと思っている。

外で休んでくるから、何かあったら、携帯にSMS入れて。よろしく。夕方のカフェにいった。

各種施策の開発と執行

プランナーが企画書を作って、リーダー兼サーバーサイドプログラマーである筆者と議論して、OKなら、インプリしてのサイクル。デザイナーはデザイナーでやり合っている。朝会は相変わらず。いいね。徐々にチームとしてワークし出した。

施策を打つごとに徐々にグロースしていくし、これは行けるかも。ミドルステージって、何だか、アーリーとかシードより全然楽だな。PV、DAU、MAUの慣性が働くし。何だこれ。筆者はミドルステージは初。他のサービスもミドルかミドルレーターかレーターくらいだけど、ヒーヒー言ってるみたい。何でだろう。ずっと残業しているし。

とか、言いつつ、周りのエンジニアは徐々に抜けていく。会社が危ないからであろう。筆者には楽に思えるが、一般的にはそうではないのだろうと思った。やはり、シードとアーリーステージのベンチャーを経験しているから、感覚が人と違うのかもしれない。

相変わらず、余裕で定時ダッシュのOL。残業はしない主義。しかし、一度、23時まで残業した。ステージングに上げての、テストで仕様書の不備が発覚した。バグがプランナーから報告される。そんなの、仕様書に書いてないじゃんの連発。1つや2つでない。リリースが2日ずれた。23時まで、インプリ、テスト、フィックスのサイクルを回し、開発/テスト終了。翌日昼過ぎにリリース。夜中、金曜にはリリースしない主義。世の中に完璧はないと思う。特にWebにおいては。ということで、月-木の昼休み過ぎにリリースの風習。ふう、何とかなった。

リリース管理、安心感とスピード。ツールより重要なもの

リリースにおいて重要なのはなんであろうか？安心感である。capistranoでのwebistranoでもいい。何も考えないで、コマンド一発、ボタン一発で終わるのが望ましい。実は、git pushでもhookかまして、リリースできるし、やった事あるけど、ちょっと危険かな。すごいスピード感になるけどね。

途中から、ポイントサイトPC版、スマフォ版両方のリリースを管理した。コードベースは両者共通である。狙いは開発のスピードアップとロバスト性の確保である。使用バージョンコントロールシステムは最初、svnだったが、プロデューサー及び、メンバー全員の賛同を取り、gitに移行。リリースには会社標準のwebistranoを使用した。ITSは会社標準のredmineにし、チケット駆動開発を導入。ブランチ戦略は新規機能開発、プログラマー/デザイナーのコラボ、バグフィックスが全て容易なものを策定した。プログラマーは週何度も、デザイナーは一日何回もリリースが行われる中、策定だけでなく、skypeベースのリリース管理でインプリを行い、デザイン、開発をスピードアップし、よりロバストなものにした。

サーバーが過負荷に。誰が原因か分からない

コンビニから帰ってきた。あれ、インフラの周りにエンジニアが集まってる。何かあったの？ポイントサイト全体でサーバーのレスポンスが悪すぎる？いつから？あれ、それ、俺が原因？違うんだ。了解。よろしくね。

翌日。

全体の開発マネージャーが来た。検証の結果、原因はやはり、筆者らしい。何が原因か分からないけど。数十秒議論する。分かった。あそこだ！直すから、また後で。ここのSQLを書き替えよう。git push。Webstranoでリリース。ここまで、理由を頭の中で思いついて、15分くらい。しばらく待つ。インフラのところにいく。どう？サーバー負荷。あ、綺麗に引いているね。やっぱりね。これで、OK。

CTOがIRCで質問にきた。今回の件について。バッチ処理用なら高速なSQLだが、Webサーバーが多数ある場合だと、過負荷になるとここに書いている以上の理由を説明。納得した模様。

さて、コンビニへ行こう。

毎月の表彰と保たれる緊張感

PV、UUは線形ではないものの、施策を打つごとに上がり、KPIを毎月の用に達成。毎月の締め会で表彰される。報奨金も渡される。新卒リーダー、貰っとけよ。スピーチもお前ね。やっぱ、ミドルステージって楽だな。上場企業とか、直前の会社って楽なんだろうな。ここみたいに。

それでも、チームメンバーは誰も慢心しなかった。皆で自席で議論しながら、開発を進める。本社はハニカム状にデスクが接していて、議論しやすい。いつの間にか私の外部モニターは2枚になり、ノートPCはスタンドにたて、無線キーボードとワイアレスマウスに変更していた。デザイナーがこういうやり方で良さげなので、真似した。Thunderboltは流石に、真似しないけどね。外部モニターはWebの開発だと開発生産性に直結するので、重要。安い投資。

さあ、あとちょっとで三ヶ月だ。ターンアラウンドに残された時間は少ない。

目標達成まで、あと100万円/月と緊迫感

チームミーティングに管掌取締役が来た。あと、100万円/月が必要だと報告された。もう、機能開発の問題ではない。運用のガッツで乗り切れ、と取締役がプランナーとオペレーションにハッパをかける。彼らは、もちろん！と。

プログラマーとデザイナーは見守るしかない。あとちょっと、待とう。筆者は休憩のために、夕方通例のコンビニでカフェオレでも買ってこよう。リクライニングチェアあるし。筆者はイギリス出身である。クリエイティブであるために、この習慣は重要。

ターンアラウンド成功

ターンアラウンド成功！

システムの年間売上高を約6000万円/年から1億円/年くらいに三ヶ月間でチームで引き上げた。やった！一人当たり年間売り上げ高に換算すると2500万円/年である。担当システム全体の売り上げ高はそこまで大きくないが、一人当たりの年間売上高で考えると通常を上回る売上高を構成できたと思う。

2012/4当時、会社はそれまで黒字だったのが営業利益ベースで1000万円/月の赤字に転落した。残キャッシュは同等の赤字が続いた場合、1年持つくらいだったと記憶している。推測だが、当時所属のチームの成果でその赤字の半分くらいは穴埋めできたのではないだろうかと思う。

成功と別事業部への移行。開発 / マーケ / オフショアのリーダーに

サービス開発/マネタイズ成功後、別の事業部に開発とマーケティング両方のグループリーダーとして移籍。マレーシアのオフショア部隊も同時に見た。直ぐにバックエンドの要件定義を済ませ、次にフロントのサービス開発の施策をソーシャルゲームの本質を取り込みつつ、チーム全員で策定した。オペレーション担当の残業などの過負荷を救うためと、事業のグロースのためである。そして、会社を去った。

諸々の反省点

この会社での反省点はターンアラウンドの序盤戦で全社に対してプレゼンをすれば良かった事である。CEOが全社MTGで営業利益ベースで赤字に陥った事を報告。その他、報告もあったと思う。ただし、ターンアラウンドの方法は言っていた記憶はない。そこで、私が事業サイドからサービスグロースの開発/企画よりの話と多少の財務/会計の話をして、全体に安心感を与えて、全体をalignすれば良かったかもしれない。会計データはより詳細のものを財務より聞いても良かったかもしれないが、それは必ずしも必要ない。ただし、本当はそれは役員の仕事。LSDではそれに多少近かった。室長だしね。

もっと、言ってしまえば、ターンアラウンドのプロジェクト2ヶ月目くらいから子会社でのギフトサービス開発/運用とそれぞれパーシャルアロケーションで兼任にしてしまえば良かったかもしれない。筆者は基本的に10時出社だと16時くらいまでしかプログラミングと業務執行をしておらず、後は情報収集、会議とコミュニケーションの時間になっている。よくよく考えると、本社スタッフは既存サービスに人数を割きすぎなので、本社から、プログラマ、企画、デザイナの三つ組を子会社との多重所属にして、私が子会社の専務執行役員サービス企画開発部長として16時以降、2時間くらい、管理をすれば、新規サービス開発もできたかもしれない。そして、次の柱が出来たかもしれない。あえて、専務執行役員にしたのは現場と経営のブリッジを確実に行うためである。これは、アセットアロケーションの問題で、私発案で出しても良かったかもしれないが、基本的には本社取締役の仕事であると思う。

そして、本社のターンアラウンドが終わって、キャッシュフローに余裕ができたら、プランナー、プログラマー、デザイナーの三つ組を3 - 5個作って、ポートフォリオを組む。グループ内に多産多死のメカニズムを組み込めば、おそらく、3 - 5年で子会社から成功プロジェクトが出てくるはず。このくらいなら、バーンレート的に適正なはず。子会社のファイナンスは必要だが、VC抜きで親会社が全て出せるはず。

もう一つの反省点は本社のトップマネージメントにもっと声を出せばよかったことである。CEOは初期のサービス開発が上手く、戦略的な経営判断は上手いが、現場との距離がいまいち遠く、現場のオペレーションを誰が回しているのか不明な状態。各事業部長と事業部付でない、managerとgeneral managerがいるが、管理はイマイチワークしてなく、ミドルマネージメントも弱かった。結構いい会社だが、イマイチ噛み合ってない事がそこそこあった。筆者がいた部門では筆者が管理していたため、あまり問題はなかったが。COO不足だったかもしれない。ということで、筆者が本社執行役員COO, Japanになるのが良かったかもしれないが、それはやり過ぎでまだ早かったので、スマフォ版ポイントサイト開発が終わった時点で、本社執行役員CTO, Japanになり、本社全体の企画と開発を見て、大陸アジアに行っていた執行役員CTOに常務執行役員CTO, ASPACになってもらえば良かったかもしれない。そして、メンバーとmanager、general managerの関係性を再定義して終わりだったかもしれない。

組織とマネージメント。当時のこの会社の欠点

筆者がこの会社で職種としてはグループリーダーで最後は開発とマーケティング両方統括したが、実は職位は高くなかった。実はヒラである。年収はそこそこ高いが。何故か？グループリーダーになるのにmanagerやgeneral managerになる必要がないからである。そして、managerは立候補制であった。筆者は年収も高く、グループリーダーになれればいいと思ったので、managerに立候補しなかった。そもそも、他のmanager陣がワークしてないのも途中で分かったし、意味のない職位だと思ったのである。

そして、この会社には謎の職位leaderとprofessionalがあった。leaderはどうやら専門職らしいが、leader手当は月1万のみ。少なすぎる。professionalの職権はいまいち不明であった。そして、興味深いのはmanagerやgeneral managerは入社の初期で人事から説明を受けたが、leader/professionalについては何も説明を受けなかった。その存在を知ったのは、後でleaderから手当についてのボヤきを聞いた時である。

もっと言ってしまえば、他のところで述べているのと多少重なるが、CTOがアジアの事業開発に行って、かつ、営業利益ベースで赤字になった瞬間、あるいはしばらく後にエンジニア担当のmanagerに立候補して、なって、言っていい範囲内で会社全体の数値をエンジニアと共有して、エンジニアを引き止めればよかったかもしれない。この会社ではmanagerは立候補制である。別にエンジニア担当managerはいたが、その人だけでは重荷だったと思う。エンジニアは赤字になってから、段々抜けていった。もっと言ってしまえば、おかしいと思っていた、leader/professional制度ごと変えてしまえばよかったかもしれない。この会社ではかなり主導権を握って、主体的に振る舞い、会社を変えた自信はあるが、もうちょっと気になるおかしいと思う点を変えてしまえばよかったかもしれない。managerとしたのは、いきなりgeneral managerはいくらなんでもないだろうからである。managerの下にsub managerがあったと思うが、そのくらいは飛び級できたと思う。

この会社のmanagerがワークしていない、簡単で面白い例として全社朝会がある。この会社は固定労働時間制で出社は10時。確か、10時5分くらいから朝会が始まるが、あまり意味のある内容が話されていると思わなかったので、一回、全員の前でこの朝会は何のためになるか、聞いた事がある。その後、全マネージャー陣と会議室で話して、意義について話した。manager側の主張は例えば新卒が朝、時間通りに来るように会議を設定したとのこと。そこは自発的に自分をコントロールすべきで、その制度設定は会議の誤用だと指摘。日系企業全体にありがちだが、朝の出社時間にはうるさいが、会議の時間、特にケツにだらしなく、ダラダラとアジェンダもなく話す。成果に直結する会議の時間にうるさくすべきで、朝の時間などどうでもいいと筆者は思っている。朝の全員の時間を消費する大切な会議について、きちんと考えてないのは全体的に考えが浅い証拠だと思った。ということで、manager陣に再考するように促して、その会議室から出た。

職位の名称と組織。そして、JD

Web業界全体にヒントを出しておくと、RealWorldに顕著であるが、ほとんどの企業では職種と職位の分離がおかしい。職種として、アーキテクトやデザイナーを設定して、アーキテクトを4段階に内部処理で分けて、最初の2段階を係長。後の2段階を課長、などとすればいいと思う。これは外資流のやり方で、さまざまな組織を経験したが、これが一番いいと思う。

日系Webベンチャーは役職が英名のところが多い。筆者はバイリンガルなので、managerやleaderを直感的に理解できるが、ほとんどの人は分からないので課長や部長などの漢字の役職名の方がいいと思っている。面白い例として、課長や部長などの役職があるのに、同時にmanagerが存在する時がある。managerは大体において、課長。場合によっては部長である。明らかにこの並列はおかしいと思う。また、ほとんどの組織では役職のきちんとした定義がない。そこをきちんと定義するべきだと思う。

一部企業であったが、専門職、特に高度専門職は職位を与えた方が仕事がしやすいので、一言述べておく。普通、システム開発なら部のトップは部長であるが、現代の高度化した環境では管理職である部長だけで仕事を遂行するのは難しい。そこで、専門職であるスペシャリストと対になって行動するのがいいと思う。あるいはProject Manager(PM)とSystems Architectが対になって行動するのも同じである。実際、筆者はそういう組織でスペシャリストをやった事があって、その威力が分かっている。実は筆者はPM兼Systems Architectをやった事があって、一人で管理上の事と技術上の事を同時に判断していた事があるが、それは普通はできないので、管理職と専門職を分離して、対にするのをお勧めする。

ということで、筆者は役員にならない主義だったので、執行役員CTO, Japanでなく、Professional CTO補佐官, Japanが最適のポジションだったかもしれない。あるいは、Professional CTO補佐官, Japan 兼 General Manager 企画開発部長補佐官, ASPACのダブルポジションでも良かったかもしれない。その後、ダブルポジションをこなしている事から、当時でももしかしたら、多少難しいが、出来たかもしれない。

社内コミュニケーション。飲み会とは限らない

毎月末の全体飲み会などがあり、結構社員同士が仲が良く、風通しが良い会社であったが、仕事上の議論がイマイチ少なかったので、それを活発にするため、ビジネスランチミーティング、ビジネスカフェミーティングを促進しても良かったかもしれない。これはmanager、general manager、事業部長の役割。当然、manager以上にはbiz cardを渡す。管理する立場からすれば、そもそも、経費とはそういう性質のものである。

また、ターンアラウンドが終わった月の月末に全社MTGの場でターンアラウンドの完了報告のスピーチをして、全員分のスパークリングワインを買って来て、全員で祝杯を上げれば、完璧だったかもしれない。そこまで考える余裕がなかった。これも、会社の経費で。これは、本当は間接部門かCEOの仕事かな。これをやっていたら、会社のbizカードを要求するかな。

労務管理はマネージャーの基本

この会社でやり残した事を一つ挙げる。労働時間の全体的な削減である。既に、新規で移った事業部でのオペレーション負荷削減について触れたが、同様な事を横展開、あるいは各事業部長に掛け合って、同時展開しても良かったかもしれない。オペレーション負荷は特に月末、どの事業部にもあるように見えたし、プログラマー、デザイナーなどのクリエイティブスタッフにも見受けられた。オペレーションは業務改善とシステムへのインプリ。クリエイティブはスキル向上と見積の適正化とビジネスプランの適正化がポイントだと思う。ターンアラウンド中などの限られた期間であれば、残業漬けになるのはある意味妥当かもしれないが、通常の期間中は無理で、逆にパフォーマンスが下がる。ここを内部に切り込んで、調査、改善すれば良かったかもしれない。この会社は既に一定の売り上げ高がある、ミドルステージの会社なので、残業漬けにして、グロースさせるべきという指摘がもしあったら、それは間違いである。グロース中であっても、頭を使って仕事をすれば、労働時間は減らせる。これは筆者の経験上、正しい。

労務管理はマネージャーの基本であると筆者は思う。

これは経営者から見れば、人数を増加させざるを得ない状況があり得るので、営業利益の圧迫となる。あるいは、同人数なら、売上高上限を伸ばせない。投資家から見れば、営業利益あるいは営業キャッシュフロー圧迫はDCFで考えて、株価の減衰となる。管理部門長から見れば、残業時間が抑制できず、場合によっては、自分のKPIを達成できず、人数を増加させるなら、採用コストの増加となる。担当事業部長から見れば、チームメンバーの離反あるいは退職を招きかねないので、抑制すべき事となる。

かっこいいオフィスは要らない

この会社では実に興味深いことを発見した。オフィスの地代家賃はパフォーマンスに影響しないということである。本社は結構いいビルに入っていて、会議室は5個くらい。全面ガラス張り。デスクはブーメラン型。子会社オフィスはそこそこ広いが安いビル。どっちのがいいか？子会社である。何故か？直ぐにホワイトボードがあり議論がしやすいのと、そこら中にカフェテーブルがあって、リラックスしやすいためである。会議室で会議をやったら負け。その場で議論。そっちが正しいと分かった。ただし、見た目がいいオフィスには一つだけ利点がある。旧帝早慶を惹きつけるためにはそちらの方が有利と過去の傾向からある程度分かっている。かっこいい内装のオフィス？要らないよ。

社内ベンチャーのインセンティブ設計

どこかに書いたと思うが、本社は毎月のように表彰されて、報奨金をもらっていくが、子会社はseedステージのため、評価的に表彰はされない。ここにインセンティブの違いが出て、インキュベーション専門の子会社は難しいことになる。resolveの方法で思いつくのはストックオプションと多少の福利厚生である。単純に、ストックオプションを本社の10倍。ベース給与を本社と同等かそれ以上（元々、同等)。ウォーターサーバー、スナックバー、冷蔵庫、電子レンジ、電気ケトル、Thunderbolt Display付きにすればいい。パーティション、キュービクル、本棚は無し。ウォーターサーバーはよくよく考えれば、多分、ランニングコストに対するインパクトは大した事ない。ウォーターサーバーは本社CFOから、付けようか？と聞かれたが、PL的に無理、と断ったことがあるが、流石に絞りすぎで、やりすぎたかもしれないと思っている。ただし、子会社は別のオフィスを借りていて、本社に比べれば、端的に言えばしょぼい。PL的にもそうするのが定石。ただし、ストックオプションが多いため、当たるとでかい。期待値が低い？自分達次第で期待値は変えられる。それが、ベンチャーだと思う。

辞めた理由の一端はインセンティブ設計が歪んでいる事にある。端的に言うと、1. ストックオプションを出さない 2. ターンアラウンドの成功報酬が少なすぎる。5万円である。会社を死の淵から蘇らせなければ、その後はなかったかもしれない。VCは上場して、株式を売り抜けて儲けたかもしれない。しかし、一般従業員は身を粉にして働いてもほとんど報酬をもらえない。これはやりがい搾取以外の何者でもない。これだったら、安定企業に行った方がいい。

ベンチャー特有の未熟さ。では、どうすれば？

別の事業部に移った後も、その事業部の問題、会社全体の問題、両方あった。既に記述した事業部の業務システムに関わる事と、会社全体の人員配置に関わる事である。これらについてこれ以上は詳細は記述しない。しかし、両方ともある程度考えて、処方箋を多少切った。しかし、この危機を乗り切ってもまた報われない、と暗に思い、ドライブをかけない選択肢を選んだ。

実はこういったケースは日系ベンチャーに散見される。彼らはベンチャーとは何も理解してない。これが日本がシリコンバレーに全く追いつけていない理由の一つであると思っている。そして、グローバル化にも成功してない。成功していても、売上高はせいぜい数千億円から1兆円程度しかない。一言断ると、まともなベンチャーであれば、参戦の余地はある。

辞めた理由に補足すると、この会社は当時、設立7年くらいで年商約数十億円、従業員数70人くらい、代官山の一流のオフィスビルなのに、間接部門が弱すぎる。6人もいるのにも関わらずである。一旦を示すと、入社前に管理部門長にMacとWindowsどちらがいいか聞かれ、その後、担当人事に全く同じ事を聞かれた。伝達ミス。子会社用のテスト用携帯を頼んでも来ない。デザインは上がっているのに、子会社用の名刺は発行されない。人事評価シートはメンバーレベルはよくできているが、マネージャーレベルは笑いが込み上げるレベル。マネージャーとは何かを全く分かってない。このあたりも辞めた理由の一つである。これだけでは辞めないが、あくまでも補記である。

もし、ターンアラウンドのボーナスで500万くらい出て、かつ、Professional CTO補佐官, JapanでProfessional手当が月20万円、社員にピザとランチを奢るための10万くらいの枠のbizカードが出ていれば、会社に残ったと思う。そして、Professionalには執行役員に準ずる権限を付与する。そうしたら、残った全社改革を実行に移して、会社をより良性の方向に導いただろう。労働時間、オペレーション最適化、指揮命令系統、職位と人事評価精度、人事、情報の流通、エンジニアリング力の強化。期間はおそらく、1 - 3年であると思う。改革と同時に、既に書いたが、新サービスを多産多死のメカニズムで作り出し、ヒットを生み出し、会社のプロダクトポートフォリオを強化する。そして、売り上げと利益を伸ばし、かつ、よりロバストにする。CTO補佐官になって、10年くらいで全部決着をつけて、退任。最後に、ストックオプションを執行する。

余談

15年近く前、REST-XML RPCはパフォーマンスが出なくて使い物にならない、とSI関係者に言われた。完全に同意である。マイクロサービスは過度のアクセスに対しては難しいのではないだろうか？なぜ、このアーキテクチャをWebのフロントで取るか分からない。業務システムなら使うが。普通はバイナリープロトコルを使うと思う。Web業界通例で、CPUがわかってないのかもしれないと筆者は疑っている。経営から見ると、パフォーマンスを上げると、サーバーを減らせて、PLに対するインパクトもあるはずである。Web業界はもうちょっと技術を勉強して、考えて設計した方がいいと思う。

筆者はWebのサーバーサイドのフロント寄りの開発は半ばマーケティング目的でやっているだけである。例えば、一番簡単な指標で言えば、この施策をインプリしたら、PV取れるかな？とマーケを具現化するためにやっている。マーケだけでもダメ。技術だけでもダメ、と思っている。

もっと言ってしまえば、ユーザーのために開発をしている。こういう機能を作ったら、ユーザーが喜んでくれるかな。とか、使いやすいかな、とかそういう事を考えて、プランナーと話したり、実装したり、分析している。

ベンチャーの実務で必要とされるもの

ベンチャーの実務で必要とされるものは何であろう？データサイエンス？最新の技術的知見？巨額の資本金？もちろん、それらは重要かもしれないが、筆者は仮説ドリブンとガッツだと思う。特にガッツ。ベンチャーは中期になると過去データがあったり、ある程度PVやUUがあって、慣性が働き、グロースするのは簡単は言い過ぎでも、そこまで難しくない。初期やシードステージでは本当にデータも組織も何もなく、仮説の検証すら危うい。何故か？PVがないから。いきなり、月間1000万PVとか1億PVとかあるわけないし。

これが、この会社で半ばの失敗と成功、シードステージとミドルステージ、両方を経験して、つくづく分かった事。IQ、EQや技術力は必要だけど、結局はガッツだと思う。

ビジネスと大義

日系ITベンチャーは理詰めで考えると従業員サイドから見るとあまり儲からない。ストックオプションを計算に入れると違うけど、ベース給与はいいものの、すぐ破綻するから、期待値は大したことがない。技術的にも大した事がない。そして、大半の会社には大義もない。いくつかの例外を除き、大半は社会には必要とされてない。分かりやすい例がかつての、ソーシャルゲーム。ユーザーの心理を操り、心の隙間に漬け込み、たくみにマネタイズしていった。これがBest and Brightestがこない理由。ITは人材が全てである。

これが日系ベンチャーがそこそこしかグロースしない理由ではないだろうか？例えば、デンソーに比べれば、はるかに売上高で劣る。ベンチャーのグロースは日本経済全体から見たら、重要事項であると思う。日系Webベンチャーは筑波から見ると真のエリートではない。

せっかくグロースできる産業なのに、現状は中途半端すぎる。だからこそ、あえて、書いている。

そこそこ以上儲かり、VCに対して、適正ROIを叩き出せ、ベース給与、ストックオプション、その他で従業員に還元でき、きちんと技術に向かい合い、大義は言い過ぎでも、社会とユーザーの事を真剣に考えて、社会に必要とされているサービス開発を行なっている会社なら、手助けをしてもいいと思う。

これは、日系ベンチャーに対する忠告の文章である。

数年後、会社は東証マザーズに上場した。

著者略歴

金輝俊 / Hwi Jun KIM
戦略コンサルタント 兼 ITアーキテクト

ハイテクITベンチャーのProduct Manager / Chief IT Architect、Webベンチャーのグループリーダー、外資系IT企業のProject Manager 兼 Systems Architectなどを経験。会社を離れて数年後、Webベンチャーと外資系IT企業グローバル本社は、それぞれ東証マザーズとNYSEに上場した。

ファッションテックベンチャーのグロースハック室 室長 兼 システム開発部スペシャリストに。30人4部門を参謀長として指揮統括し、約10億円の株式による増資に成功。シーリズCへと導く。その後、起業。NMD Soft, Principalとして活動を開始。

社会貢献活動として、原爆の実相を伝えるためと、東日本大震災の解析のために、Nagasaki Archive、Hiroshima Archive、Mass Media Coverage Map of The East Japan Earthquakeなどの開発と一部企画に関わった。

主な著作にThe Real M.Phil Thesis: The Mathematical Foundation of Smart Material Systems / Yet Another Mori-TanakaやMBA Thesis: The Modern Strategy from Japanがある。

筑波大学 第三学群 工学システム学類 学士(工学) First Class (イングランド基準。70%以上がA評価)

Coventry University大学院 Control Theory and Applications Centre, Master of Philosophy (Upper Master, Research Degree)。飛び級入学。返済義務無し奨学金付き。

主な受賞にアレスエレクトロニカ展Honory mention、経済産業大臣賞、文化庁メディア芸術祭審査委員会推薦作品など。

詳細なプロフィールはこちら：https://www.khj1977.net/profile/

以上