経歴書 (Curriculum Vitae)

基本情報

  • 氏名: 金輝俊(キムフィジュン)/ Hwi Jun KIM
  • Email: euler.bonjour@gmail.com
  • Social ID: @pcaffeine77(インスタThreadsnoteX (旧Twitter)
  • GitHub: https://github.com/khj1977
  • 専門: 戦略、IT、応用数学
  • 職業: 独立研究者(フリーランス。お仕事のご依頼はメールでよろしくお願いします)
  • GPG公開鍵: 公開鍵(必要な場合はこの公開鍵で暗号化して、私に渡して下さい)
  • 生年月日: 1977/5/6
  • 出身地: 東京
  • 国籍: 韓国籍、日本国特別永住権(2013年取得)
  • センター試験: 総合83% (一浪。主要科目得点:物理90点/100点以上。英語196点/200点。受験科目: 数学(2教科)、物理、化学、国語、地理、英語)
  • TOEFL CBT: 233/300点、2002年(カルフォルニア大学 大学院 バークレー校レベル)
  • スポーツ:
    • 4000mチームパーシュート関東大会入賞。インターハイ出場権獲得。インターハイ出場辞退 (高校三年)
    • 40kmチームタイムトライアル。神奈川大会3位入賞(高校三年)
  • 主な奨学金:
    • EUレート奨学金/授業料90%以上免除、Coventry University大学院、2002 - 2004
    • 授業料全額免除/半額免除、信州大学、1997 - 1998
  • 主な受賞一覧:
    • Prix Ars Electronica 2013, Honorary Mention in Digital Communities Category, 2013
    • アジアデジタルアート大賞2011,エンターテインメント部門大賞(経済産業大臣賞), 2012
    • 第14回文化庁メディア芸術祭審査委員会推薦作品
    • その他多数受賞
  • 学位:
    • Master of Philosophy (Upper Master, Research Degree), 飛び級入学, Coventry University大学院, 2004年
    • 学士(工学), 筑波大学, イングランドでのFirst Class相当(70%以上がA評価), 2002年
  • FAQ(よくある質問とその答え): FAQ

略歴

国家と社会のために働く。始めは違った。

究極の自転車、複合材料とロバスト制御、そして、エネルギー問題。統一朝鮮半島実現のための韓国経済グローバル最適化。Better検索エンジンの研究開発とグローバルコミュニケーション、そして世界の平和。ユーザー/クライアントのちょっとした幸せと管理職/戦略担当官としての修行の日々。最後は日本のターンアラウンド: 働き方改革2とビジネスWebアプリケーションフレームワーク、負の所得税/better負債と日本国経済最適化などの日本の国家戦略立案。これがこれまで歩んできた道のりである。

筑波大学 第三学群 工学システム学類 機能工学システム主専攻をFirst Classで卒業(イングランド基準。70% 以上がA評価)、学士(工学)取得(2002年)。UMIST(後に、Manchester大学に併合)Master of Science課程の入学許可をもらったものの、奨学金が無いため、入学辞退。Manchester大学はグローバル大学ランキング28位(2022年)でCalifornia大学Berkeley校(27位)や東大(23位)とほぼ互角である。Manchester大学は20人以上のノーベル賞受賞者を輩出している。

Coventry University大学院 School of Mathmatical and Information Sciences, Control Theory and Applications Centre M.Phil/Ph.D課程(3年制の一貫制博士課程)に返済義務なし奨学金付きで飛び級留学。スマートマテリアルシステムのための適応ロバスト制御理論の構築に従事。研究を成功させ、Master of Philosophyを取得(2004年)。機械システムのエネルギー削減を狙っていた。20年後、40年後の実用化を狙った基礎研究であった。自分から研究提案書を持って行ったため、予算権は無いものの、事実上のPrincipal Investigator(PI)に近かった。

PI経験がその後の職業人生で急速に伸びる素地を作ったと思う。自分で企画立案、物理モデリングをし、LaTeX16ページの提案書を作成。指導教官に提案、説得。2年のプロジェクトを回し、競合調査のための、必要な参考文献を探し出し、定理と証明、理論の応用を160ページに渡って作成。プロジェクトを完遂。VIVA(最終口頭試問)に通り、学位を取得した。

「I will go to economics.」 そう言い残して、CoventryのグローバルPh.Dグループを後にした。

その後、日本のIT業界に転身し、ERPシステム開発を目指した、Web系制作会社を経て、ハイテクベンチャーにおいて自然言語処理分野でのブログ分析及び検索エンジンの研究開発に従事。早期にプロダクトマネージャーに昇進。その後、DeNAの検索エンジン開発チームの話を断り、研究開発のトップで上級専門職であるChief IT Architectに。大量のブログデータなどを元にした、仮説ドリブンの数値実験を主に行っていた。表向きは検索エンジンであるが、実際は自然言語、例えば、英語から日本語への機械翻訳を狙っていた。詳細は別途文書に記述してあるが、世界を平和に導くために機械翻訳を狙っていた

Chief IT Architectあるいは、上級専門職としての活動を終え、管理、すなわち、リーダー/マネージャーの世界に。Web系企業でグループリーダーとして、ターンアラウンドを行った。破綻気味であった企業をグロースさせ、救い出した。外資系グローバルIT企業でSystems Architect 兼 Project Managerとして、大手広告代理店や大手製造業相手のシステム開発でのマネージメント業務に従事。オフショアでの開発の難しさを経験。同時に分析的なマネージメントのスタイルを身につける。マネージメントでは仕組み、場、リスク、先読みが重要だと気づいた。そのスタイルは後の室長としての仕事の基礎となる。

そのWeb系企業は後に東証マザーズに上場。外資系グローバル企業も後にグローバル本社はNYSEに上場した。

IT系事業会社である株式会社ライフスタイルデザインに転調し、最初は業務委託で、週3勤務のお気楽プログラマ 兼 データ分析官として従事。その後、正社員に見いだされ、上級管理職 兼 上級専門職である、グロースハック室 室長 兼 システム開発部 スペシャリスト 兼 マーケティング部 スペシャリストとなる。6部門、約30人の 部隊を会社のNo.3 すなわち、分析 / 数学 / ITをエッジとした参謀長(戦術担当官) 兼 現場の最高指揮官として 全社を引っ張り、総額約10億円の増資に成功。アーリーステージからミドルステージに導いた。

Systems Architect、スペシャリスト、Principalは全て似た職種で、上級専門職の一種でシステム開発部 部長やProject Managerを高度専門職としてサポートする存在である。グロースハック室 室長、すなわち、参謀長あるいは経営幹部としての知見もある。もしかしたら、技術顧問に近いかもしれない。CTOに対する技術戦略のサポート × 経営陣に対する経営戦略のサポート = 技術顧問だと考えている。

exitし、起業。NMD Soft Principalとして、0. フレームワーク開発、1. プログラマ 兼 分析官、2. プロジェクトマネージャー 兼 アーキテクト、3. 戦略コンサルタント 兼 ITアーキテクトなどを行う。日本の平和と発展を祈り、 税と社会保険オペレーション改革(働き方改革の続編)及び、Web 3.0に取り組む事となる。

経歴要約

大学進学時、家庭の事情で学費を捻出できなかった。都市銀行は学費を貸さないと言ったので浪人中のバイト で約200万円をかせぎ、信州大学へ進学。その後、筑波大学に編入。信州大学では全額あるいは、半額の授業 料免除だった。

筑波大学をイングランド基準でFirst Class(70%以上がA評価)で卒業後、Coventry University大学院 M.Phil/Ph.D課程へ返済義務なし奨学金付きで留学。最短で三年でPh.Dを取れるコースである。三年目の生 活費が足りないため、Ph.Dへの移行要件は満たしていたが、二年目で終わらせる事にし、Ph.Dは諦めることにした。そして、二年目の初めから、M.Phil取得を目指した。

CoventryのグローバルPh.Dグループでシステム制御工学の大学院生として基礎を築いたあと、日本のIT業界に転身した。自然言語処理分野での研 究開発でプロダクトマネージャー及びChief IT Architectを経験。研究開発のトップの重圧を経験した。

社会人二年目に500万円を株式で、翌年、プロダクトマネージャーとして、1億円の株式での資金調達の技術プ レゼンを担当。資金調達は両者とも成功に終わった。自分の研究開発で億単位の資金を投資家から調達でき るということを理解した。

Chief IT Architectとして、新型検索エンジンの研究開発に取り組んだ。具体的には共起ネットワーク型クエリ拡張検索エンジンの研究開発に取り組んだ。この検索エンジンはC2Cube時代に大量の数値計算を行った結果 得た仮説をベースとしている。

プロダクトマネージャーあるいはChief IT Architectとしては技術的には一定の成功をおさめたと思うが、ビジネスとしては失敗に終わった。正確に言うと、研究の成果で1億円の株式による増資の成功を収め、これもまた、研究成果の一つから、レコメンデーションエンジンをNTTコミュニケーションズに納入したが、それ以外は商業的に爆発的な成功はしていない。

SIでオフショアのプロジェクトマネージャーを経験。一つ目のプロジェクトである程度プロジェクトマネージメントを 経験的に理解した。複雑度が上がった二つ目のプロジェクトではシステム開発自体はほぼ成功裏に終了してい たが、いくつかの要因で、途中離脱した。1勝 / 1分だった。

ただし、そこでの経験は次の会社での上級管理職である室長としての仕事への基礎となった、具体的にはプロ ジェクトマネージャー時代に行っていたリスク管理やチーム編成の問題点の洗い出しへの分析的アプローチを 応用し、会社全体で30人ほどへ影響を及ぼす室長としての仕事への基礎となった。

最後にIT系事業会社でグロースハックチーム リーダー、後に、グロースハック室 室長として約6部門ある組織を 分析と戦術、リスク管理を軸に横串を指した。この役割はプロダクトマネージャーとプロジェクトマネージャー、両 方の要素を取り入れている。グロースハックチーム リーダーになった当時は会社はアーリーステージだったが、 2017年1月ごろにミドルステージに到達できたと思っている。2017年1月にかけて、会社は億単位の資金調達を 成功させた。

室長としての第三者割当増資への貢献度はだいたいにおいて、60%程度であると考える。あとは他の経営幹部及び、業務委託の方や派遣社員を含む一般従業員の方たちの努力の結果であると考える。室長としての全てをつなぐ役割及び、他の経営幹部と一般従業員、両者の働きがなくては、上記の結果は得られなかったと考える。

室長としての最後の仕事は以下の通りである。マーケティング戦術立案の後、経営企画部の事業計画、すなわ ち、戦略がおかしいのでは、という仮説の元、exitの方法を含む、事業計画の修正及び試算を始めた。経営企 画はそれとは別にシリーズCの事業計画を出してきた。経営企画側の事業計画にはいくつかの問題点がある が、決定的に間違っている点が2つあった。問題点について考察すると、問題点はさらに一つに集約されると考 えても良い。メインポイントは早すぎる黒字化の時期である

それを展開すると、高すぎるバーンレート、ECではあるが店舗が絶対必要なので、元々は売上 / 地代家賃を既 存のスーツ屋より高くするという、ビジネスモデルの根底を覆す、ありえない店舗計画、それに紐づく、店舗関連 従業員の採用計画と店舗従業員に対する予想される扱い、とそこから予想されるクレーム率の高騰、及び、そのありえない事業計画を支えるジェットコースターのような資本政策である。

2016年秋から2017年1月にかけて、何度も経営企画部長と一対一で議論を重ねた。しかし、その決定的な間 違いを認めず、その後となる。2017年になって何度も一対一で議論を重ねても無駄なので、株主及び、全役職 員の事を考えて、2017年1月19に全社員の前で公開で議論を挑む。その間違いを認めなければ、普通に考えて、会社は破綻への道を突き進むか、会社は残っても、実質的に超低ROIあるいはマイナスのROIとなるか、債務超過となるであろう。数値上は事業計画を変更可能であるが、仮に、その事業計画上の間違いを認めたとし ても、他の要素を勘案すると、事業計画は実質的に修正不可能に近い問題点をすでにはらんでいた。そして、 会社は破綻への道を突き進んでいく可能性が高いと判断している。役職員から見たら、そのうち、会社は倒産。 株主から見たら、exitは不可能である可能性が高い、というのが私の予想である。

しかしながら、2017年1月19日の時点では元室長として、株主との議論に及んででも、資本政策を含む、事業 計画を変更してみせようと考えていた。

そして、2016年10月から会社を仕事事由の病気で不定期な出社となる。病名は自律神経失調症である。2016 年10月以降の事は上で述べられているとおりである。

注記 2020/6/1) 株式会社Fabric Tokyo (旧株式会社ライフスタイルデザイン)の会社情報を見ると資本金が 5000万円まで減っていた。私が在籍していた当時は約13億円ほどあったと記憶している。それがなぜ減ったの であろうか?よくある勘違いの一つにキャッシュを使うと資本金が減る、というのはあるが、それは間違い。純資 産が減るだけである。

ではなぜ、資本金が減ったのであろうか?答えは100%減資処理が入って、事実上の倒産処理が走った後、 5000万円が株式として入ったか、債権の一部のデットエクイティスワップが実行されたものではないかと予想す る。かなりの数のデットが入ったはずである。デットで会社を回したのだろう。

どちらにせよ、会社は一度事実上の倒産をした。私の予想通りである。私の予想通りになってしまった。実に残 念な事である。

皆で頑張って勝ち取った10億円の資本金を溶かした旧ライフスタイルデザイン経営陣の罪は重い。悔い改めな さい。必ず、exitすること。株主に適正レートで配当を出す事。無茶なハイグロースな事業計画を作らない事。従 業員に高負荷をかけないこと。お客様、取引先、従業員、銀行、株主に感謝する事。なぜ、あの会社が生き残れ たのかきちんと考える事。カッコつけたホームページを作っていますが、もうそういうベンチャー遊びを止めて、き ちんとした大人の組織を作り出す事。私ほか数人の初期の功労者に対して、数千万円から数億円のベスティン グ付きのストックオプションを出す事。

注)当時の私のexit戦略は以下の通りである。1. 会社を優良中小として育て上げる。2. 株式上場はさせない。 代わりに配当を出す。 3. 配当と同時に適正レートで内部留保も積みます。正直銀行はあまり信用していないの で、短コロすら出さないのでは?と思ったので、何かあった時のために、キャッシュをため込んで置くことは必要 であると考えたからである。 4. 株式は非上場でも相対で取引できる。したがって、売りたい時は相対で投資家 同士で売買してもらう。ただし、長期ホールドすれば絶対儲かりますよ、という発想であった。そういった事を盛り込んだ、財務モデルの資料も作っていた。もちろん、ROIも計算していた。しかし、当時、自律神経失調症になっ てしまい、株主や経営陣、そして全従業員に対してプレゼンをする機会が無かったのが残念である。

注記 2020/6/12) ニッセイ・キャピタルに対して警告を出します。なぜ、あんなふざけた2017年のバーンレートと 資本政策を認めたのでしょう?確かに、2017年初頭の数億の第三者割当増資を引き受けたくれたのは事実で す。感謝します。とはいえ、旧LSDはぶっちゃけ、最速で2016年12月末で資金ショート(残キャッシュがゼロにな る。すなわち、倒産)する可能性がありました。

ただし、2016年秋に約1.5億円の資本増強があり、なんとか、しのげました。一度、株主会議(正式名称NCC Report。代表取締役と執行役員、ニッセイ・キャピタルの担当VCの会議。通常 は室長も部長も出席しない。取締役会は当時は存在しなかった)にグロースハック室 室長として出た事がありま す。そこで、担当VCが執行役員経営企画部 部長 兼 CFOに向かって言ったセリフを今だに覚えてます。「何々 君、強気だね」当時、私はバーンレートが高すぎる、最速で2016年末に資金ショートする可能性があると認識し てました。なぜ、バーンレートの設計に問題があると、早期に気づかなかったのでしょうか?なぜ、気づいていた のなら、早期に修正しなかったのでしょうか?

2016年初夏に一回、人斬りを実行に移しました。しょうがないのかもしれません。しかし、人斬りの数が少なく て、あまり効果がありませんでした。

なぜ、取締役会を設置しなかったのでしょうか?なぜ、VCで取締役陣を複数送り込まなかったのでしょうか?な ぜ、代表取締役 執行役員 CEO 兼 マジョリティ投資家などというありえない設定を許すのでしょうか?これは、 私が経験してきたベンチャー通例です。日本にWeb系ベンチャーができて20年ほど経っているかと思います。なぜ、同じミスを繰り返すのでしょうか?情報共有はしていないのでしょうか?

過去に、ハイテクベンチャーの研究開発のトップを勤めた事があります。ハイテクベンチャーに対応できるVCが いないに等しいのはしょうがないのかもしれません(とはいえ、実はダブルマスター、すなわち、機械/情報/物理 いずれかのマスターとMBAホルダーなら対応できるかもしれません)。

私の一般のWeb系ベンチャーあるいは、IT系事業会社に対するVCの見解は以下の通りです。ビジネスモデル は理解できるでしょう。色々足りないことは横の繋がりを生かして、繋げてくれるかもしれません。でも、なぜ、同 じミスを繰り返すのでしょうか?なぜ、いつも過少資本しか入れないのでしょう?なぜ、いつもバーンレートの設 計でミスるのでしょう?なぜ、いつも代表取締役 執行役員 CEO 兼 マジョリティ投資家という存在をゆるすので しょうか?

委員会等設置会社はご存知でしょうか?ぜひ、一度、会計、ファイナンス、システム、組織論、アントレについて学ぶ事をお勧めします。

注)とは言え、VCは必要だと思います。なぜでしょうか?答えは産業あるいは企業の育成と勃興だと思います。 つまるところ、産業の創造です。単に金を儲ける事だけがVCの目的でしょうか?もちろん、私も含めて金儲けは 誰でも必要です。でも、それだけではないと思います。産業の創造に賭けているVCがいると信じたいです。

負の所得税の話しオペレーションの話しはあくまでも日本の守りの戦略です。では、攻めの戦略、すなわち、成長戦略はなんでしょうか?答えの一つはVCによる新規事業あるいは産業の創造だと思います。

また、何処かで会うかもしれません。その時はよろしくお願いします。

注記)その、ニッセイ・キャピタルのリードインベスターは後に社外取締役になったが、その後、辞めたようである。解任されたのかもしれないし、自分で降りたのかもしれない。また、たまにこの会社の社外取締役は総入れ替えがあるようである。リーダー陣もそうだし、創業後結構経っているのに、いい加減会社が安定しない。経営幹部は何をやっているのかと、正直思う。

注記 2021/12/13) 約5年前の今頃、旧LSDでシリーズCの中期経営計画を練っていた。LSDは一回、事実上の倒産をしているし、経営戦略をかなり変えたので、当時の目算の一部を記述したいと思う。

結論から言うと、今頃、資本金約60億円。今から5 - 10年後に年間売上高100億円。営業キャッシュフロー率10%だったかもしれない。

月間だと季節変動がかなりあったが、当時の年間売り上げ高は誤差があるものの約1億円くらい。シリーズCで在庫リスクを取り、季節変動を抑え、CVR改善の施策を打って、リピート率を3回以上リピートの第一種リピートをそれなりにグロース。3 - 5年に一度買い直す第二種リピートもそれなりにグロース。それらの施策をPDCAサイクルを5年間回し、解析をかけ、両リピート率を向上させ、CVR10倍にして、シリーズCは終了。

ただし、本社地代家賃、店舗数と従業員人数は極小に抑えるが、一人辺り従業員人件費は厚めに設定する。少数精鋭の良い人材を集めるが、固定費を抑えるのはベンチャー経営の鉄則だと思う。

シリーズDのロードショーにシリーズCの結果を持って挑み、15 - 50億円の大規模増資をし、大規模マス・コミュニケーション戦略に打って出る。広告宣伝費10倍。CVR10倍で売上高100倍。年間売上高100億円、営業キャッシュフロー率10%。年間営業キャッシュフロー10億円を目指す。両リピートがついてくるので、疑似ARPUとLTVが上がり、サーバー代もあまり要らない。それでも、あえて中小優良なんだけどね。

そして、シリーズEで株式あるいは債権あるいは、その組み合わせで100億円から1000億円を調達し、工場を垂直統合する。工場買収代金はCFOマターで私は把握してないので、あくまでもワイドレンジでのアテである。なぜ、工場の垂直統合なのであろうか?答えは工場納期の短縮である。例えば、工場納期を1日に減らし、注文からお客様納期まで、3日でこなせば、この会社の参入障壁になるし、お客様もついてくるはずだと踏んだ。そして、競合他社をぶっちぎる。これは当時既に、アイデア自体は室長会議で執行役員 経営企画部 部長と共有していた。

これが、当時の戦略。現在はまったく違う戦略を取っている。誠実で堅実なビジネスを行い、是非とも、2015 - 2016年のオリジナル組と過去の投資家を今後の利益で儲けさせて頂きたいと思う。御社の御成功を心からお祈り申し上げます。

主な経験

  • システム開発部スペシャリストとして、平均ではシステム部長に譲るものの、圧倒的なプログラムの設計/実装能力で部長を抜いた経験。注)ただし、スペシャリストは部長と対になって行動し、部長をサポートする職種である
  • プロダクトマネージメント経験
  • プロジェクトマネージメント経験
  • マーケティング、オペレーション(スーパーバイス)、財務/会計分析経験
  • Webアプリケーションフレームワーク開発経験
  • UI設計経験
  • ビジネス上の判断でコードのクオリティを犠牲にして、速攻で機能などをリリースした経験
  • 1億程度のレコード数のDB取り扱い経験(2008年当時。HDD使用)
  • 自然言語処理/制御工学分野での研究開発経験
  • 英語(アカデミック及びビジネスの場での使用経験)
年代 役割 肩書 開発 研究開発 製品/サービス計画 分析 マネージメント / リーダーシップ  全部門に横串
2006/から 専門職(エントリーレベル) プログラマ
2008/7から プロダクトマネージャー / 専門職 プロダクトマネージャー
2009/7から プロダクトマネージャー / 上級専門職 Chief IT Architect
2012/1から 専門職 / リーダー級 プログラマ・グループリーダー
2015/1から 中間管理職 Systems Architect 兼 Project Manager
2016/6から 専門職(プログラマ 兼 分析官) マーケティングエンジニア
2016/8から 上級管理職 兼 上級専門職 グロースハック室・室長 兼 システム開発部スペシャリスト 兼 マーケティング部スペシャリスト

言語

  • 日本語: ネイティブ言語
  • 英語: バイリンガル。TOEFL(CBT) 233/300点 (2002年)。イギリスの大学院でのアカデミックな場面で使用していた。年月が経ち、若干英語力が落ちたものの、オフショアのプロジェクトマネージャーとして、英語を公用語としたチームを 管理した。
  • フランス語: そこそこの日常会話を訳さないで、そこそこ流暢にこなせる
  • 韓国語: 大幅に語彙力に劣るものの、簡単な挨拶+アルファ程度の日常会話を訳さないで一応、話せる

開発環境、開発支援環境など

  • サーバーサイドサイドOS: Linux
  • 言語: PHP、Ruby、Python、Java、C++、C
  • DB: MySQL、Memcached、TokyoCabinet/Tyrant
  • その他:HTML、Apache、nginx、Varnish、RabbitMQ、CodeIgniter、Smarty、jQuery、 Hadoop(MapReduce)、Thrift(RPCフレームワーク)、git、redmine、Jira

職歴

NMD Soft

2011/10 – 現在
代表 CEO 兼 Principal

- Vision

全ての人が安心、安全で活発な社会生活を送ることをリサーチ/テクノロジーと戦略の力でサポートすること

- Principle

  • プロフェッショナリズムを持って行動せよ
  • エシックスを持って行動せよ
  • 全ステークフォルダー -お客様、取引先、仲間、銀行、株主- を向いて行動せよ

- 対象業界

Web、SI、小売、製造業

- 提供バリュー

NMD Softは戦略、IT、応用数学を主たる事業領域とする技術研究所である。IT/応用数学プロダクトの研究開発/販売および、ITや戦略などの労務提供を行う。興味分野はオペレーション分析/最適化(続働き方改革/DX)、税と社会保障、経済/金融、Web、データサイエンス/機械学習/AI、機械工学。

労務提供は下記のURLを参照のこと。

プロダクトは研究開発中も含めて、以下の通りである。問い合わせはメールでお願いします。

  • ToyFramework: ビジネスWebアプリケーションフレームワーク。HMVC + Scaffold + Composite View Pattern + Facade/Processを基調とする、主にオペレーション最適化用のフレームワーク。詳しくはこのURLを参照の事。コアは動いているものの、現在、研究開発段階。寄付ベース。寄付額などはライセンスをご参照下さい。
  • クラスタリングエンジン: SVD-PCAkmeansのgithubリポジトリを参照の事。自然言語処理、データサイエンスやWeb解析用。データのスーパーバイズ不要のエンジンで、教師学習を必要としないので、使用するのが簡易。元々、自然言語処理向けだが、他の用途だと、例えば、アクセスログを適切に加工して、ユーザーをクラスタリングして検討するなどの用途に向いている。寄付ベース。寄付額などはライセンスをご参照下さい。
  • Twitter News: 大量のデータをMySQLに高速インサートするシステム。Webゲームのアクセスログ分析などに向いていると想定している。元々、TwitterのStreaming APIを捌いて、自然言語処理のアルゴリズムに使うのを目的として開発した。改造すれば、マスターを分割して、シャーディングも可能で、主にWebでの大規模処理に適している。Redshiftなどももちろんいいと思うが、Webは大規模化するとミドルウェアの限界がくる。このコードを参考に改造して使用するのをお勧めする。寄付ベース。寄付額などはライセンスをご参照下さい。
  • デジタルラグランジアン: 有限要素法の一種。筆者がイングランドの大学院生(M.Phil/Ph.Dコース)の当時、Smart Material Systemsを制御にかけるため、モデリングに研究した。理論的にはあらゆる偏微分方程式系(PDE)を常微分方程式系(ODE)に変換可能で、材料だけでなく、流体、例えば、人工心臓の制御用のモデリングに使用可能だと推察される。モデルは制御可能な形に変換される。寄付ベース。寄付額などはライセンスをご参照下さい。
  • K-Disturbance Observer: 元々、Smart Material Systemsの適応ロバスト制御のために研究された制御手法。任意のN次元のODEに対して適用可能。数値的には普通、有限だが、Smart Material Systemsは例えば、飛行機の羽に応用されれば、100万や1000万次元になる事が予想され、理論的にロバスト制御が可能である事を示すため、任意のN次元について定理と証明を研究した。K-Disturbance Observerは元々、Smart Material Systems用だが、人工心臓や化学プラントの制御、あるいは免震構造のビルの適応ロバスト制御にも使用可能だと推察される。次元は低いがロボット、ドローン、自動運転自動車の適応ロバスト制御にも適用可能かもしれない。K-Disturbance Observerの研究のコア部分でM.PhilがCoventry University大学院より授与された。寄付ベース。寄付額などはライセンスをご参照下さい。
下記に戦略、経済、金融分野での成果物を示す。ライセンスは基本的に修正BSDライセンスで寄付が望ましいが、政府系組織に限って、無償で使用可能とする。目に見えない政策や戦略ですが、公共物の一種という事で、もし、興味がありましたら、寄付をお願いします。
  • The Modern Strategy from Japan: 日本のターンアラウンドのための国家戦略。主に税と社会保障や関連するシステムについての論考集。
  • 経済工学システム原論: インフレがなぜ起きたのか?と今後の日本の経済/金融の先行きについての論考集。MP4 Podcast on Instagramとnoteのマガジンからなる。

株式会社ライフスタイルデザイン

2016/1 - 2017/2
注: 2016/1 - 2016/5 業務委託契約。2016/6 - 2017/2 雇用契約(期間の定めなし)
エンジニア => マーケティングエンジニア => グロースハックチーム リーダー => グロースハック室 室長 兼 シス テム開発部 スペシャリスト 兼 マーケティング部 スペシャリスト => グロースハック室 室長 兼 システム開発部 スペシャリスト (システム部とマーケティング部統合のため) => エンジニア

分析、戦術立案、リスク管理、スコープ管理、CFO補佐、システム開発、UI設計、コードレビュー

初日は週3勤務のお気楽、業務委託のプログラマとして出社。どういう機能開発をするのか、伝えられていた が、まず、組織図をチェック、その後、ECサイトをもう一度、ざっと見て、全体を把握。部門の関連性とECとの関 連性を紙に書き出して、会社全体をなんとなく把握。各部門の人に現状の業務と困っている事などを聞いて、こちらの質問も何個かして、内部の状況の把握を深める。その後、大雑把な財務状況を聞き出した。いくつか、システムとして作るべき機能はあると思ったが、まず、あらかじめ、割り振られた機能開発を進める事にした。

当時は人数10人くらいの小さな会社だった。

3月にはオペレーションが崩壊。それに伴って、4月末には配送の破綻が予測された。人数が増え始め、 4月には機能別組織がはっきりとできあがりはじまり、会社が機能し始めたように見えた。システム開 発部のリソースをオペレーション構築に投入。システム開発部、生産部、共同でオペレーション構築に 乗り出し始める。夏の終わりまでに決着を付ける予定であった。2016年6月に正社員に。6月頃には全体 が機能しているようで、なんとなくチグハグのように見え始める。社長から何をやってもいい、と言わ れたので、プロダクトマネージャー制を導入。グロースハック・チームを組成。チームリーダーに。そ の一ヶ月後、グロースハック室に格上げ。グロースハック室 室長 兼 システム開発部 スペシャリスト 兼 マーケティング部 スペシャリストに。

LSDツリー状組織図
注:最初、グロースハック室はチームであったが、その時は経営企画と同列とされた。その後、一段階下げる事 になる。しかしながら、機能と権限についてはまったく変わってなかった。むしろ、室員が増え、仕事が加速して いく事になる。あくまでも、組織図上の事である。

LSD組織図
図:全部門とグロースハック室、経営企画部の関係。部門は時期によって増減する。また、場合によっては、部 の下に課やチームが存在する場合もあった。ただし、機能としてはだいたい、この通り。プロダクトマネージャー制は機能別組織に横串を指すものであるが、ここではそれを変形して、経営企画部とグロースハック室の二部 門共同で横串を指した。経営企画部とグロースハック室は戦略と戦術で住み分けたが、どちらが上あるいは下 という事ではなく、戦略が戦術に影響を与える場合もあれば、戦術が戦略に影響を与える場合もあった。また、 過去の経験から、財務/会計に対するサポートも行った。また、戦略の上にはVisionとPrincipleがあるが、それ は別問題である。

約10年前、31歳の時、C2cubeでプロダクトマネージャー(PdM)を行った時は研究開発能力は高かったが、粗利も知らないありさまで、MBA的知識はまったくない。ミドルマネージメントの経験すらない。横串を指す相手は40代の役員数名。そして、複数の技術系役員がいた。C2cube時代の途中から勉強し、実践した MBA的知識と経験、数度の会社の破綻と増資、CI&T Pacific時代に経験したプロジェクトマネージャー(PM)で得たマネージメント能力、全てを投入して、事にあたる事にした。

室長はPMとPdM、ファイナンスを含めたMBA的知識と多少の経験のミクスチャーだが、PM的なスキルとして、CI&T時代に実戦経験を積んだ、リスク管理、場、仕組み以外に先手を読むことを心がけた。CI&TのPM時代はある程度先手を打てたり、後手になったり、いまいちだった事もあったが、LSDでは割と先手を打つのが多く、得意になったと思う。

グロースハック室 室長として全部門を分析、リスク管理、戦術で統括。経営企画部が戦略で全部門に横串を刺 したのに対応し、グロースハック室は戦術で全部門に横串を刺した。プロダクトマネージャー制の変形である。室長としての業務の主な目的は全社のKPIをマクロでコントロールする事である。

グロースハック室はMBA的な知識と多少の経験、製造業のプロダクトマネージャー制とSIのプロジェクトマネージャー、両方の要素を取り入れているが、さらに、戦略コンサルタントのマネージャー、投資銀行のヴァイスプレジデント(VP)、あるいは大学准教授のやり方をヒントにしている。すなわち、室には室員が複数所属。室長として、室員に対して仮説を振り、情報あるいはデータ収集及び、分析を担当 してもらう。室長としても、分析を自分自身でも行い、さらに、各種室員の分析結果や他部門から上がってくる分 析結果、全てを統合し、さらに、各部門や経営企画部にフィードバックをかけていた。

すなわち、基本的には各部門が独自に動いているが、全体が何らかの理由で機能しにくい場合、あるいは部門 横断で取り組むべき事はグロースハック室や経営企画部が担当していた。経営企画部、グロースハック室、各部 門がそれぞれ分析を通して、フィードバックループを生成し、うまく組織として、機能するように持っていっていた。

2016年4月以降、マーケティング、生産/オペレーション、カスタマーサポート関連の分析及び、部門改善の施策立案及び、その補佐を担当。例えば生産/オペレーションが将来の売り上げ予測に対してその時点では対応不可能な体制だったため、将来予測売り上げ高に耐えられるためのプランの策定及び、実行計画策定の補佐を 生産部長と共同で行った。

Webの真実はアクセスログにあり、店舗の真実は店舗にある。渋谷マークシティ、羽田、有楽町、船橋、みなとみらい。室長になっても、店舗やその周辺に降り立って邪魔にならないようにたまに見ていた。店舗データはスプレッドシートにあったが、それだけではダメだと判断したからである。WebはGoogle Analytics、User Local、その他BIを同時に使ってさらにスプレッドシートで加工して、データ分析をしていた。店舗フィールドワーク、アクセスログ、両者とも明確に現場である。室長は上級管理職で会社とビジネスをマクロで分析し、動かす立場にあるが、現場を重要視し、常に見ていた。踊る大捜査線の室井管理官の話は真実であると思う。

全社のリスク分析及び、リスク軽減のためのプランを策定。リスク軽減の実行を執行役員経営企画部 部長と共 同で行った。組織が機能不全におちいっていたため、組織の問題をリスク軽減の側面から改善した。

2016年夏ごろ、リスク管理の結果、組織がある程度機能し始めたと判断したが、マーケティング部に解決が難し い問題が残っていた。関連メンバーに聞き取り及び調査を行った。Web、店舗など関連データを集計/分析し当 時の現状を把握。マーケティング戦術を立案、全社と共有した。そのマーケティング戦術にはWeb側のUI、広告 のみならず、リアル店舗への誘導のフレーム、リアル店舗のオペレーション限界、リアル店舗の地理/立地特性 における分析結果、及び、成長スピードを勘案に入れた全施策を盛り込んだ。もちろん、暗に在庫リスクと関連 する財務会計も関係している。

システム開発部スペシャリストはシステム開発部 部長と対をなす存在で、管理能力を含め、平均的能力については部長が上だが、複数の一部能力について圧倒的な能力差がなければ、スペシャリストとは名乗れない。もう一度書くと、スペシャリストは部長と対を成す存在で、普段は部長をサポートする。これは外資系ファームのProject ManagerとSystems ArchitectやPrincipalの組みと似た組織構造である。

スペシャリストは現場寄りであるものの、もしかしたら、執行役員CTOや経営陣に対して助言をする技術顧問に近い存在かもしれない。

システム開発部スペシャリストとしては次のような役割を担った。1. JavaScriptでのフロントエンドも含む、部員全員のコードレビューを行い、システム開発部のプログラムの質を担保した。2. 運営サービスがアタックを受けた時など、緊急事態には部長と共同でシステム開発部の指揮を執った。3. また、実際の開発、特に一般の部員では難しい機能の開発も行った。

グロースハックチーム リーダーになった当時、すなわち2016年7月頃は会社はアーリーステージだったが、 2017年1月ごろにミドルステージに到達できたと思っている。2017年1月にかけて、会社は億単位の資金調達を 成功させた。

室長としての最後の仕事は以下の通りである。マーケティング戦術立案の後、経営企画部の事業計画、すなわ ち、戦略がおかしいのでは、という仮説の元、exitの方法を含む、事業計画の修正及び試算を始めた。経営企 画はそれとは別にシリーズCの事業計画を出してきた。経営企画側の事業計画にはいくつかの問題点がある が、決定的に間違っている点が2つあった。問題点について考察すると、問題点はさらに一つに集約されると考 えても良い。メインポイントは早すぎる黒字化の時期である

それを展開すると、高すぎるバーンレート、ECではあるが店舗が絶対必要なので、売上 / 地代家賃を既存の スーツ屋より低くするという、ビジネスモデルの根底を覆す、ありえない店舗計画、それに紐づく、店舗関連従業員の採用計画と店舗従業員に対する予想される扱い、とそこから予想されるクレーム率の高騰、及び、そのありえない事業計画を支えるジェットコースターのような資本政策である。

2016年秋から2017年1月にかけて、何度も執行役員 経営企画部長と一対一で議論を重ねた。しかし、その決 定的な間違いを認めず、その後となる。2017年になって何度も一対一で議論を重ねても無駄なので、株主及 び、全役職員の事を考えて、2017年1月19に全社員の前で公開で議論を挑む。その間違いを認めなければ、 普通に考えて、会社は破綻への道を突き進むか、会社は残っても、実質的に超低ROIあるいはマイナスのROI となるか、債務超過となるであろう。数値上は事業計画を変更可能であるが、仮に、その事業計画上の間違い を認めたとしても、他の要素を勘案すると、事業計画は実質的に修正不可能に近い問題点をすでにはらんでい た。そして、会社は破綻への道を突き進んでいく可能性が高いと判断している。役職員から見たら、そのうち、会 社は倒産。株主から見たら、exitは不可能である可能性が高い、というのが私の予想である。

しかしながら、2017年1月19日の時点では元室長として、株主との議論に及んででも、資本政策を含む、事業 計画を変更してみせようと考えていた。

そして、2016年10月から会社を仕事事由の病気で不定期な出社となる。病名は自律神経失調症である。2016 年10月以降の事は上で述べられているとおりである。

シーアイアンドティーパシフィック株式会社

2015/1 - 2015/11(雇用契約)、2015/11 - 2016/2(業務委託契約)
注: 雇用契約(正社員、期間の定めなし)及び、業務委託契約
Project Manager、Systems Architect

スケジュール管理、予算管理、リスク管理、クライアントコミュニケーション(ハイレベルコミュニケーション及び、場合によっては日常のコミュニケーション)、チーム管理、アーキテクチャ設計補佐

ブラジルを本社とするグローバルIT企業。東京オフィスはアジア・パシフィック地域のヘッドクォーターでマネージ メントと設計の一部を担当。中国は設計の一部と開発を担当。

ToBのWebシステム開発のオフショアでのプロジェクトマネージメントを行った。5-12人からなる人数をスクラム をカスタマイズしたアジャイル開発手法で管理した。コミュニケーションは英語をチームの公用語とし、補助的に 日本語を用いて行った。コミュニケーションの手段としてはSkypeやHangoutでのテキストチャットやボイスカン ファレンスを使用していた。テキストチャットであろうが、ボイスカンファレンスであろうが、ほぼほぼ全て英語である。

補足のために、プロジェクトのメンバー構成について述べる。例えば、12人の場合のプロジェクトメンバーの構成 は以下のようになる。

以下、東京オフィス

  • Systems Architect 兼 Project Manager(私)
  • ITコンサルタント
  • Program Manager

以下、中国オフィス。チーム内コミュニケーションは上記のように主に英語を用いて行った。基本的には英語が公 用語だが、中国側リーダー(ブリッジSE)と話す時に、アーキテクトなど他のメンバーが絶対に会話に加わらない時などは日本語を使用した。

  • リーダー(ブリッジSE。日常のクライアントコミュニケーションの一部などを担当)*1
  • リーダー補佐*1
  • Software Architect(インフラ、及びシステム設計担当)*1
  • サーバーサイドエンジニア*2
  • フロントエンジニア*1
  • テスター*2
  • ホライゾンタルリーダー*1(中国側の全リーダーのアドバイザリー的な存在)

ただし、リーダーとのコミュニケーションでもメールやチャットはほぼ全て英語であった。先のような例外的な場合 を除いて、中国側とは、ボイスカンファレンスでの会話も含めてほとんど英語でのコミュニケーションであった。プロジェクトの全メンバーがなるべくプロジェクトの全貌を把握するためである。クライアントは日本の企業である。

PMとしては主に仕組み作りとリスク管理に注力した。多少であるが、場にも着目した。この3つに着目すると、プロジェクトが上手く回ると途中で思ったからである。

1つ目のプロジェクトでは、クライアントコミュニケーションはPMが行い、リーダーは中国側の日常の管理と一部リスクに言及、であったが、位置関係を変え、クライアントコミュニケーションは主にリーダー。技術的にやビジネス的に難しいところだけ、PMが行った。リスク管理も主にPMが行うように変えた。ただし、クライアントとのメールはリーダーは中国人なので、日本語のチェックを軽くだけした。また、チームの公用語が英語になったのは、PMの決断でプロジェクト途中からである。その方が、チームメンバー全員がプロジェクトの状況が分かりやすくなり、現場作業も捗ると思ったからである。

2つ目のプロジェクトでは経費の決裁権も持ったので、クライアントデモが成功した時、逆にスプリントで残業が多発した時は経費で中国側にご飯に行ってもらった。英文メールで全チームメンバーに状況を伝え、今回はこういう事があったから、ご飯へ、と伝えていた。東京はPMOでPMのポジションは普通から見て重いので、意見の交換が活発になるように、プロジェクトの入りで、なんでも奇譚なく意見を交換するように中国側ホライゾンタルリーダーに伝えた。ただし、最終決定権はPMにある。実際、スプリントごとの振り返りミーティングは意見が活発に出て、中国人の一般的な性格もあるが、これは成功だったと思う。

注:当時のCI&T Pacificの開発手法はアジャイルと言っていたが、事実上のウォーターフォールで問題が多 かった。CI&T Pacificでの開発手法は統一されていたため、それはProject Manger級では変更が許されない。 本来のアジャイル型でないため、Project Managerとして管理するのが難しかった。例えば、プロファイリングの結果、チームメンバーのSoftware Architectによる設計が破綻してすざましい量のクエリが発生した事が分かっ た。キャッシュを入れても全てを吸収するのは無理であった。その時にDBの構成を変更すれば高速化される事 が分かったが、インフラ構成もアーキテクチャ仕様書にある定義の変更が許されないことをカントリーマネージャーから言われたため、DBの構成変更を行えなかった。

ただし、システム開発自体は終了していた。残りは上記に書いてあるパフォーマンスの問題、データ移行、管理 画面のUI / UXの問題であった。

データ移行については事前にプロトタイピングがしてあり、ある程度当時の進捗を見て、もう東京のSystems Architect 兼Project Managerマターではなく中国マターだと判断していた。つまり、中国の現場にまかせても大 丈夫であった。

パフォーマンスの問題はプロファイリングを当時しかけていて、最初の1時間未満くらいで、どのモジュール由来 かは別にして、上記のとおりクエリの問題自体はすぐに見抜いていた。クラスでなくて、モジュールという概念で 管理するパッケージを使用していた。他の要因も丁寧にプロファイリングすれば、どのモジュールが大量のクエリを出しているかなどを見て、モジュールのリファクタリングとシステムの高速化などが可能なはずだった。しか し、インフラの事であるが、上記にあるとおり、シニアマネージャーと意識のずれが起こり、プロファイリングも途 中で止め、途中で頓挫する事となる。

UI/UXも日本の地方にあるクライアントの本社で一度、ミーティングをセッティングしたが、シニアマネージャーにミーティングを半ばハイジャックされ、本来の趣旨とずれる事となる。ただし、多少UI / UXは落ちるものの、パ フォーマンスの改善も含め、当時おそらく、期日どおりにカットオーバー可能なはずだった。

インフラ周りでCountry Managerと意識のずれが起きたあと、疲れ切っていたので、有給を数日取るが、その 後出社。Country Managerから「もっと休みなさい」、と言われたため、さらに数日休んで出社したところ、 Sysmtems Architect 兼 Project Managerを突如解任された。意味が分からなかった。そもそも、パフォーマン スの問題をあと2 – 3週間かけてfixさせ、UI / UXをエンハンスメントすなわち、実行サポートフェーズで改良する という事にしておけば、期日どおりにカットオーバーできたはずである。実に下らない措置であった。

以下、ビジネスサイドから書く。対応したクライアントは2社で一社目は大手広告代理店子会社、2社目はハイテクグローバル製造業である。両者とも開発したシステムはCMSであるが、前者はある高額商品の売上に関わる、グローバル対応したシステムで色々な意味で多言語化もしていた。後者は特許法もからんだシステムで単純なCMSではない。グローバル展開の話も内々に出ていて、これも、売上に対するインパクトファクターはあったかもしれない。CI&Tグローバル本社はその数年後に上場した。

注記:もう明かしてもいいと思うので、当時のクライアント名を明かそうと思う。一社目はもう、読者は分かっているかもしれないが、博報堂子会社。2社目は島津製作所である。島津はノーベル賞も出している本当の超ハイテク企業である。筆者は普段、ジーパン、Tシャツ、サンダルであるが、こういうトラディショナルな企業の対応もできる。他にも、丸の内の白シャツ、ネクタイの金融マンと仕事をした事もある。

株式会社アルフレッドコア

2012年9月 – 2012年12月
注: 業務委託契約
Project Manager

Web Application Frameworkを開発
  • O/R Mapper
  • AOP
  • Composite View Pattern * Scaffold

に代表されるフレームワークを開発した。いわゆるMVCフレームワークであるが、Struts/RailsのようなFront Controllerパターンベースより、クライアントアプリケーションにおけるObserverパターンベースのMVCフレーム ワークに近い。概念としては、SmallTalk / SqueakやNeXTStepを参考にしている。Observerパターンの実装 にCometを考えた。ただし、2006年に作成、英語ブログ上 -たしか、タイトルはA Web Programmer’s Log- で 公開したCometフレームワークはやりすぎたので、そこまでは求めず、あくまでも、Front Controllerパターンと Observerパターンの中間を目指した。

O/R MapperはRailsのActive Record型のO/R Mapperである。O/R Mapperのクラスメソッドによるクエリの 結果によって、modelのインスタンスのコレクションを返す。Joinは一つに制限してあるO/R Mapperの意味と複 数のJoinによるO/R Mapperの意味の消失を考えると複雑なJoinになる場合はSQLを直接発行した方が良い、 という判断である。

AOPはFilterの事を指す。O/R MapperとFilterを組み合わせて使う。O/R MapperのインスタンスにFilterのイ ンスタンスをインジェクトする事によって、機能を拡張できるようになっていたかもしれない(後述)。記憶が定か ではないが、FilterのインスタンスをO/R Mapperのインスタンスにインジェクトするか、あるいはControllerの基 底クラスのメソッドのフックにインジェクトする事によって、Controllerのサブクラス自体には手を加えない設計に した。Filter数 × O/R Mapper数の組み合わせの方がControllerの総数あるいは、クラスライブラリの設計上 や、そもそもMVCとは何か?という事とScaffoldと組み合わせてほとんどの画面を自動生成する事を考えると、 Controllerにはあまり手を加えない方が意味論的に適切であるという考え方である。

注:当時、すでにBackbone.jsは存在し、WebSocketはあったかもしれないが、どちらにせよ、WebSocketを使 うのは当時の想定業務から考えるとオーバースペックとの判断で完全なObserverパターンベースにするのは避 けた。

注:端的にはFront ControllerパターンとObserverパターンの違いはobserverのイベントトリガーによるオートアップデートであるが、それはプログラム側から見るとfat controller / thin modelとfat model / think controller の実装方針の違いになる。fat model / thin modelの考え方とカスタムscaffoldによる画面の自動生成を考えると上記のような考え方に至った。

注:管理画面側での実装効率を上げるために作ったカスタムフレームワークであり、いわゆる、Webサービスなどでのユーザー側での使用は考慮していない。

PHPでもその機能をフルに引き出せばRubyに並べる可能性があるという事を示した。

ビジネスサイドから書くと、具体的には明かせないが、国家の予算配分に関わる重要なシステムであった。そのシステムをProject Managerとして、フレームワークをプロトタイピングしていた。実はそのシステムは何故か本籍は某有名広告代理店子会社が主体となって、プロジェクトを進める事になっていたが、記憶が曖昧だが、色々な企業から人が来ていた、混成部隊で興味深いプロジェクトであった。その広告代理店子会社に私の島もできる予定であった。

もう明かしてもいいので、どの広告代理店か明かそうと思う。ぶっちゃけた話、電通子会社である。つまるところ、筆者は電通、博報堂、両社に対してプロジェクトマネージメント業務を提供していた事になる。T-Servでバイクメッセンジャーのバイトをしていて、両社に100回以上通った15年以上後にである。

株式会社リアルワールド

エンジニア・グループリーダー · 2012年1月〜2012年8月
注: 雇用契約(期間の定めなし)
要件定義、設計、実装、データ分析、Webサービス運営

この会社ではマネージメント、企画指向で行った。また、新卒教育も行った。

入社初日に新規事業専門の子会社Real Coreへ出向。ギフトサービス開発に。今から振り返ると、本社のサービスは儲かっているものの、次の柱が欲しいということで、あえて、子会社で新規サービスを開発して欲しいとの事だったと思う。直属の上司は社長。サービス開発途中から参加。開発は協力会社が行い、プランニングとベンダーコントールをReal Coreで行った。筆者はベンダーコントロールとReal Coreの管理担当である。

本社オフィスは代官山にあるいい感じのビル。全面ガラス張りでセキュリティエリア外に会議室が4 - 5個ある。外から全く見えない和室あり。ウォーターサーバーあり。Real Coreはあえて、サテライトオフィスを借りていた。安い雑居ビル。ある時、CFOがサテライトオフィスに来て、ウォーターサーバー置く?自販機もありでは?と聞いてきたけど、PLが良くないから、ダメ、と答えた。PLはそうでもないでしょ?CFはダメですね。で決着がついた。よく考えたら、入社初日は本社で作業をしていて、Coreのメンバー分の机は偶然あった。地代家賃分、PLが軽くなるから、本社で仕事をしても良かったかもしれない。

カットオーバーは予定通り行ったものの、サービスはもっさりして重い。画像が重いのとJavaScriptのファイルが多すぎるためだと思い、入社初期からの想定通り、nginxをリバースプロキシーとして入れる。アプリケーションサーバーはApache Prefork/mod_phpである。高速化されて、サービスとして成り立つレベルまで持っていった。

ただし、リリースしてから2週間くらいしか運用期間がなかった。何故か?次のサービスを同じチームで本社でやるためである。理由?ターンアラウンドを行い、会社の赤字を救い出すためである。

本社に同じチームで呼び戻された。

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

このターンアラウンドではグループリーダーを行った。ポイントサイトスマフォ版の開発/運営である。PC、スマフォでシステムはある程度共有しているが、レスポンシブでなく、企画的にも別れていた。ビジネスサイドから言えば、チームメンバーで簡単なデータ分析をして、アジャイル型で開発。担当していたシステムの年間売上高を約6000万円/年から1億円/年くらいに三ヶ月間でチームで引き上げた。一人当たり年間売り上げ高に換算すると2500万円/年である。担当システム全体の売り上げ高はそこまで大きくないが、一人当たりの年間売上高で考えると通常を上回る売上高を構成できたと思う。

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

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陣に再考するように促して、その会議室から出た。

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を達成できず、人数を増加させるなら、採用コストの増加となる。担当事業部長から見れば、チームメンバーの離反あるいは退職を招きかねないので、抑制すべき事となる。

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

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

辞めた理由の一端はインセンティブ設計が歪んでいる事にある。端的に言うと、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取れるかな?とマーケを具現化するためにやっている。マーケだけでもダメ。技術だけでもダメ、と思っている。

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

日系ベンチャーは理詰めで考えると従業員サイドから見るとあまり儲からない。技術的にも大した事がない。そして、大半の会社には大義もない。いくつかの例外を除き、大半は社会には必要とされてない。分かりやすい例がかつての、ソーシャルゲーム。ユーザーの心理を操り、心の隙間に漬け込み、たくみにマネタイズしていった。これがBest and Brightestがこない理由。ITは人材が全てである。これが日系ベンチャーがそこそこしかグロースしない理由ではないだろうか?例えば、デンソーに比べれば、はるかに売上高で劣る。ベンチャーのグロースは日本経済全体から見たら、重要事項であると思う。日系Webベンチャーは筑波から見ると真のエリートではない。

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

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

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

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

株式会社Spicysoft

エンジニア · 2011年4月〜2011年5月
注: 正社員
ソーシャルゲーム開発

プログラマ兼データマイニングエンジニアに転向しようと思って転職。社風に合わないため、転職した。

CLON lab

IT Architect, Chief IT Architect · 2008年11月〜2010年9月
注: 正社員
研究プラン策定、要件定義、アーキテクチャ設計、設計、実装

CLONでは体制変更後、新型検索エンジンの研究開発に取り組んだ。具体的には共起ネットワーク型クエリ拡張検索エンジンの研究開発に取り組んだ。この検索エンジンはC2Cube時代に大量の数値計算を行った結果得た仮説をベースとしている。

共起ネットワーク型クエリ拡張検索エンジンでは発見性のある検索エンジンを目指して開発をした。通常、 Googleなどで検索をするときは自分が何を欲しいのかはっきりと分かっている必要があるが、そうではなく、何となく分かっているが、はっきりとは何が欲しいのか自分で認識できてない時にみつけられる検索エンジンを目指して開発した。

最終的には使わなかったものの、途中、Webのデータから生成した巨大行列から固有ベクトルを求めていた。たしか、スパースマトリックスでも行列がメモリに乗らなかったため、HadoopのMapReduceで並列分散処理化して、パワーイテレーティブメソッドで固有ベクトルを求めていた。

2010年代前半、Hadoopでは何故か、並列分散DBがあったり、何故か並列分散ディスクIOに向かっていた。並列分散DBなら、MySQLでシャーディングフレームワークを組めばいいだけなのに、と思っていた。サイバーエージェントもたしか、シャーディングのためにNoSQLを使ってたっぽいので、教えてあげればよかったかもしれない。Hadoopは本来はMapReduceなど、CPUドリブンであるというのが筆者の意見である。ただし、ソシャゲなどの開発になると取るポジションが違うのかもしれない。

検索エンジンはフロントエンドはPHPだが、バックエンドはJavaを使っていた。初期のバージョンは全てPHPで実装されていたが、1検索クエリ辺り、大量のDB問い合わせが発生して重いため、Javaの永続プロセスにデータをキャッシュしていた。PHPとJavaの永続プロセスはThriftで繋いでいた。

To Cのサービス開発からTo Bの製品開発への体制変更時、残キャッシュは2500万円。これで一年持たせよう という計画であった。

To Bに切り替わる前に会社内で内紛があった。一度、私と代表取締役を含む数名が切られそうになった。一部 株主(事業会社)と当時のCLON Lab社員によるクーデターであったと聞いている。物事が転換し、私を主体とする組織に転換された。同時に逃げる目的で受けたDeNAの検索エンジン開発チームのオファーを断る。体制変更後、私以外の社員は全員解雇された。根本的な原因はその事業会社が株式と債券の違いを理解していないことにあると推測される。

表向きは新型検索エンジンの開発だが、実際には大量のWebデータから一種の人工知能が生成できるのでは ないかという仮説のもと行っていた。検索エンジンはあくまでも具現化すなわち、応用事例の一部である。

しかし、研究開発期間があまりにも短く、検索エンジンの精度を上げる事ができなかった。役員及びベンチャー キャピタルの工学及び技術的知識の不足、研究開発に対する無理解を感じ、もう研究開発はベンチャーではやらない事にした。

追記 2021/12/26)では、他に道はなかったのであろうか?後付になるし、FAQに書くべき事かもしれないが、現時点での考察をあえてここに書きたいと思う。エンジンの基礎研究は実は半年で終わっていたのではないかと今になって思う。理由は、エンジンの精度が65% - 73%くらい出ていたからである。ある人に70%出ていると言われたが、それは言い過ぎで、だいたいにおいて、68%くらいであると思う。どっちにしろ、基礎研究は終わりで、後は応用研究と応用開発であった。キャッシュ的にショートまであと、半年あったので、応用研究と平行して、応用開発に1ヶ月から3ヶ月くらいで1サービスをリリースして、うまく出来た物の結果をもって、次のファイナンスのラウンドに望めば次に繋げられたかもしれない。

ただし、応用開発には1. CLON時代に作った特殊検索エンジン 2. C2cube時代のレコメンデーションエンジン 3. プライベートの時間に作ったSVD-PCA & Kmeans 4. CLON時代に作ったチャットエンジンの4組で挑む。チャットエンジンはCLON制で、私と外部の会社の合作である。チャットエンジンのコントリビューションは私4.5割。外部の会社5.5割。あとは全て、私のコントリビューション10割である。

組織編成的には私の肩書と役割を執行役員Chief Research Officer 兼 Product Managerにし、1. 基礎研究、2. 応用研究、3. プロダクト企画立案の指揮を取り、プロデューサーに応用開発の1. サービス企画立案と2. 指揮を取ってもらう。Webエンジニアに私とプロデューサーが作ったざっくりとした要件定義とアーキテクチャー仕様書でアプリを作ってもらう。代表取締役には組織構築、政治と経営に徹してもらう。そして、私は執行役員として取締役会に出て、経営と現場のブリッジをする。

そして、次のラウンドで最低1億円。最大5億円くらいの株式による第三者割当増資をし、年間バーンレート3000万円から8000万円くらいで回し、次のラウンドに望むか一気にマザーズ上場まで駆け抜ける。そして、IPOで30億円の公募増資をしてたら上手くいったのかもしれない。

このパートは完全に後付である。では、当時リアルタイムで解を捻り出せなかったのであろうか?他にもできなくはない方法を思いついた。答えは、戦略コンサルタントを私のディスカッションパートナーとして契約する事である。別に、Excelでモデルを組めとは言わない。100ページのパワポを組めとは言わない。私と議論して、第三者の冷静な視点で見て、こうしたらどうですか?とか、それでいいと思いますよ、と言ってもらう。それだけで良かったのかもしれない。

実は当時から、戦略コンサルタントのちょっとした知り合いがいた。現マッキンゼーJPパートナーの倉本由香利さんである。東大物理学修士、MIT MBAのダブルマスター。私が考えているアルゴリズムを理解できる素養はおそらくあっただろうし、まだポジションはシニアアソシエイトくらいだったかもしれないが、同年代だから、うまいこと噛み合ったかもしれない。当時の残キャッシュだと多額の月額報酬は支払えないが、成功報酬として、数千万円から億単位の多額のストックオプションは用意できたはずである。

これは南場さんのジャガーの経営企画室 室長への解に近いと思う。倉本さんならできたかもしれない。

追記 2021/12/29)思い出したので、追記する。2009年、秋か冬くらい、基礎研究が終わった時くらいに代表取締役に「Product Managerみたいになってほしかった」、あるいは「Product Managerになってほしい」と言われた。その場では何も答えなかったが、しばらく考えて「Product Managerになります」と正式回答してChief IT Architect 兼 Product Managerになれば良かったのかもしれない。

そして、元々考えていたが、さらに、研究と同時にプロダクト企画を考えればよかったかもしれない。何故、そこまで考えなかったのであろうか?答えはちょっとした余裕だと思う。シードステージで半年間、極限状態で基礎研究をして疲れていたのかもしれない。5日の有給で9連休にして、どこかに旅行でもして、美味しいものを食べてリラックスすれば終わりだったかもしれない。そして、Chief IT Architect 兼 Product Managerとして、一人二役でグルグル思考を巡らせ、CLON時代の特殊検索エンジンとC2cube時代のレコメンデーションエンジンの組み合わせを一人でも思いついたかもしれない。戦略コンサルタントと組んだらもっといい解は出たかもしれないが、その1/4歩手前くらいは一人でもたどり着けたかもしれない。

最後にファイナンスについて書く。先に基礎研究終了からショートまで半年と書いたが、これは当時の見解。本当はあと1 - 2年あった。何故か?答えは、一回小規模受託を入れたのと、デットがあったはずであるからである。受託でショートまで期間が伸びたという認識が無かったのは代表取締役の計算ミス。デットファイナンスは聞いたわけではないが、代表取締役のスケジューラーを見ていて半ば分かった。当時は上記のような見解に至っておらず、研究を半ばで辞めたので、無理だと思っていた。あとちょっとだけ、休んで余裕をもって、ちょっとだけ周りと議論し、できれば戦略コンサルタントを入れたら、Chief IT Architect 兼 Product Managerとして応用研究 / 応用開発 / 事業を成功に導けたかもしれない。

追記 2022/9/27)根本的に間違っていたのが、コミュニケーションではないかと思う。私と代表取締役とのコミュニケーションが少なすぎた。ToBの体制に変更して、PLの圧縮のために、間借りのオフィスにしたが、秘匿事項について、話しにくく、一々、会議室を借りなければいけなかった。通常、ベンチャーではスピード命で、デスクでの会話がものが進んでいった方がいいと思う。会議室で話したら負けなのかもしれない。その上で、ロードマップを作り、計画について握り、研究と開発、両方ともアジャイルに進めれば良かったかもしれない。執行役員CROもPdMのいいかもしれないが、やはり、根本的にはコミュニケーションだと今は思う。

そして、Googleに対抗する力を手にするために室長への道を歩み始める事になる。

主要開発技術:共起ネットワーク型クエリ拡張検索エンジン、twitter botによるpush型レコメンデーションエンジ ン。

株式会社C2cube

エンジニア、プロダクトマネージャー · 2007年3月〜2008年10月
注: 正社員
研究プラン策定、要件定義、アーキテクチャ設計、設計、実装、営業管理

自然言語処理分野でのアルゴリズム開発、ブログ分析。大規模データベースを元に、大量の数値計算を行い、数値ベースの仮説ドリブンでPDCAを回し、自然言語処理関連のアルゴリズム開発をした。

自分の研究開発に使っていたDBで一日あたり1000万 - 3000万レコードを扱った。合計で1億-4億レコードのデータを取り扱ったと記憶している。ハードウェア、データベースの性能が貧弱であった当時としては大量かつ取り扱いが難しいレコード数である。

計算量は短くて数十分、長くて3日間ほど連続して計算しつづけさせた(個人用PC or サーバーを占有)。CPUはXeon 2CPU、1CPU辺り、2コア。メモリは16GB。今なら、当たり前のスペックだが、当時はかなり高スペックのサーバーだった。当時の個人用マシンはメモリは1GBだけだった。使用していた言語は主にRubyあるいはC++。言語が動的型付けの言語であるか静的型付けの言語であるかかわらず、計算量を最小化するために、最適なデータ構造を選択するように心がけた。

CPUの限界、メモリ容量の限界、ディスクIOの限界、ネットワーク帯域の限界に皆で挑んだ。単純な企画であっても、大量のデータを扱っている関係上、計算量が発散してしまい、計算不可能で、企画を実行不可能な場合も多々あった。DeNA、GREEは当時、そのような事には気づいてなかったようだが、その数年後、ソシャゲブーム辺りでエンジニアリングの重要性に気づいたようである。

一番分かりやすく、Webで応用可能ということで、DBについて書こうと思う。当時、日本全体のブログの80 - 90%をクロールして、独自のエンジンで分かち書きをして、MySQLに入れていたが、新型のテーブル設計で全テキストデータを入れようとすると、いくらMySQLをチューニングしようと、バルクインサートしようが、insertの処理が追いつかなかった。

記憶が多少曖昧だが、24時間で2億インサートしなければいけないところで、1億インサートしかできなかった。これを別のシニアエンジニアがシャーディング用のフレームワークを作って解決しようとした。シャーディングの発案は私である。別の文章で書いたかもしれないが、エンジニアリング的にはほぼ解決できたが、財務会計上の限界が来るから、シャーディングと全件インサートはあきらめて、サンプリングにした。

RDBMSは普通、テーブルを正規化して、joinさせて集計などをかけるが、テーブルに入れるデータ数があまりにも多いとインデックスを張っても、計算量が爆発的に増え、join不可能になってしまった。従って、非正規化も行った。まだ、NoSQLが流行る前の時代の話しである。

また、旧型テーブル設計でも、インデックス(おそらくBTree+かその変種)を張っても、クエリの実行スピードがかなり遅くて、事実上、selectがwhereと共に、実行不可能な場合があった。これも理由はおそらく、単純でBTree+がうまくバランスできてなくて、事実上のlinear chainに近くなり、O(log n)でなく、O(n)に近くなってしまったのかもしれない。AVL平衡木などで解決可能なのかもしれない。

ただし、これも推論だが、仮にBTree+インデックスが完全にバランスされていたとしても、レコード数が多すぎるといくら、BTreeと言えど、木の高さが大きくなりすぎて、BinaryTreeほどではないにしろ、ディスクIOが増えすぎて、遅くなっていた可能性も否定しきれない。これも、検証は特にしてなく、あくまでも推論である。

アルゴリズムとデータ構造など関係無い事を書くと、当時のテラバイト級のデータベースにコネクションを張ろうとすると、コネクションだけで、具体的な数字は忘れたが、数秒から数十秒かかった。普通はコンマ数秒で一瞬で張れるにも関わらずである。

最後にロックの問題について書く。今のWeb業界ではMySQLのストレージエンジンはInnoDBが主流だが、当時はそちらの方が速いという事でMyISAMが主流だった。MyISAMの欠点はselectをかけるとテーブルロックがかかってしまい、同時多発的にselectがかけられなくなる事である。これは通常のWebサービスなら、同時アクセス処理数の減少に陥る可能性がある事を示唆すると思われる。ブログ分析などの研究開発では同時複数人が複数のアルゴリズムを同時発行できない事を意味する。筆者は断続的に20 - 100件のselectをかけるなどして、DBに複数人が擬似的に同時アクセスできるようにした。

ということで、当時から、筆者はMVCCであるInnoDBを使い始める。ただし、記憶が曖昧だが、InnoDBはまだそれほど成熟していなくて、パーティションもまだ出たてだったかもしれない。それでも、全社的には違うかもしれないが、自分の研究開発専用では導入した方が良いと判断した。当時はまだ、SSD登場前であるが、SSDになると、たしか、信号線が増え、並行readができるので、明らかにInnoDBの方が有利であると思われる。ただし、ベンチマークは取ってないので、理論上の話しだが。

総額2億円の株式による資金調達のうち、500万円の資金調達案件で自分が開発したアルゴリズムのプレゼンを担当。その事業会社からの資金調達は成功に終わった。全体でも資金調達は成功し、2億円の第三者割当増資が行われた。

実はC2cubeは2007/8か2007/9辺りで資金ショートを起こしている。つまり、残キャッシュがゼロになった。本来はその時期に億単位の増資があったにも関わらずにである。その3 - 4ヶ月に上記の2億円の第三者割当増資が行われた。その間は給与ゼロ。リストラの嵐。ただし、私は残る方で月額報酬は上がった。私以外にも10人位が資金ショートしても残っていたが、1.5ヶ月くらいでキレ始める。人間はそんな物だと、当時理解した。真性のベンチャーだとそういう事がある。若きMBAでベンチャーで挑戦したいと軽い気持ちで思っているなら、一度深く論考してみる事をオススメする。本当のリスクを取るというのはどういう事か。リスクを取れないなら、投資銀行か戦略系ファームをオススメする。

2億円の第三者割当増資が走ったのは事実だが、この株式は特殊黄金株で既存株主の権利を無効化していた。日本法において、合法らしい。誰かの説明を受けたわけでなく、自分で株式契約書を解き明かした。すなわち、当時の代表取締役CEOはおそらく、マジョリティ投資家であったと思うが、マジョリティではなくなったので、権限が弱まった。下記に述べられている通り、 後に、Product Managerとして、私が、研究戦略で優位に立ち、事業上のワークフローで互角になったので、代表取締役CEOとしての権限も半ば無効化した。

数ヶ月後の別の事業会社相手の株式による資金調達の技術プレゼンを担当。後に1億円の第三者割当増資が 行われたと記憶している(記憶が完全にさだかではない)。同時にその事業会社の社長と元の社長の交代が あったと記憶している。

私が在籍していた当時の社長が暴走を始めたので、Product Manager、CTO、CEOの三権分立にし、 Product Managerの承認がなければ物事が進まないようにした。

C2cubeでの最後の技術開発はチャットエンジン融合型レコメンデーションエンジンであった。チャットエンジンは技術系取締役の作。レコメンデーションエンジンは私の開発。全体の企画立案は私であった。エンジンの内容は数学のテクニックの嵐で秘匿情報であるため、明かせない。NTT Communicationsとの共同プロジェクトでプロダクション環境に実際載せた。当時はSiriもしゃべってコンシェルも存在しなかった。

主要開発技術:trie-btreeハイブリッド型kvs、ジャンル判定確率フィルタ、trieを用いた品詞/活用情報の推定、助詞/助動詞の出現パターンを用いた単語羅列型スパムフィルタ、twitter向けユーザーレコメンデーションエンジ ン、共起語計算アルゴリズム、再起的共起語取得とそのブランド分析などへの応用、チャットボット/レコメンデーションエンジン融合型システム。

Wiseknot株式会社

エンジニア · 2006年4月〜2007年2月
注: 2006/4 契約社員、2006/5 - 2007/2 正社員
要件定義、設計、実装

Web制作会社でのPC自社Webサービス開発、品質管理業務。ERPを開発し、経済のグローバル最適化を狙っていたが、路線変更のため転職した。

Coventry University大学院 (M.Phil/Ph.D課程)

Control Theory and Applications Centre. School of Mathematical and Information Sciences. 2002年10月-2004年11月

学位: Master of Philosophy (通常の理工学系修士号であるMaster of Scienceより上位の学位)

  • 研究の目的: 機械システムのエネルギー消費を抑える事
  • 研究の題目: スマートマテリアルシステムのための適応ロバストコントローラーの提案及び、漸近安定性の証明
  • 研究提案書: Control Problems Arising on Smart Structural Systems (1.デジタルラグランジアンの提案 2. デジタルラグランジアンを使用したスマートマテリアルシステムの物理モデリングと制御問題の提案)
  • Master of Philosophy論文: Disturbance Estimation and Cancellation for Linear Uncertain Systems (線形スマートマテリアルシステムを前提とした適応ロバスト制御アルゴリズムの提案と漸近安定性の数学的証明、及び、その応用)

上記論文はよく考えたら、Mori-Takanaのmicro mechanicsに対する証明を与えたのかもしれないと 思う。記憶が定かではないが、M.Phil二年目に気づいて、リファレンスを入れ忘れたのかもしれない。

Mori-Takanaの方法のDynamics版は読んでないが、おそらく、静的な方でもdisturbanceとvoidや reinforced-materialから始まることから、根本となる発想は同じである可能性が高い。しかし、その後のdisturbanceのestimationの方法の違い及び、それ、つまりsystem matrixがN次元の場合に対する 証明を与えたことから、少なくとも線形領域に対する動的挙動のMori-Takanaのmicro-mechanicsに 対する証明を与えた可能性が高いのではないかと思う。

断りを入れると、M.Phil論文は主査及び、副査によって全ての論文を審査されている。具体的には論 文提出からviva (最終口頭試問)まで3ヶ月の期間をおいた。通常は1.5ヶ月と聞いている。主査は同じ 大学の同分野の別の教授。副査はスコットランドの同分野の教授である。

追記:Mori-Tanakaのmicro mechanicsは学類4年で筑波大学で取り組んだ卒業論文のテーマのベー スとなったものである。

  • 16ページの研究提案書を書き、提案。指導教官を説得し、与えられた研究テーマから提案したものに変更
  • International proceedingsで一本、論文を発表
  • 返還義務なし奨学金付き (本来の授業料:約180万円/年が以下の額に減額:一年目、約50万円。二年目、約5 万円)
  • Ph.D(博士)課程への移行要件を満たしていたが、思う所あってM.Phil(修士)で終わりにした。具体的には EU外の出身で完全な外国人である私にイギリスの HSBC銀行は授業料及び、家賃を貸してくれると言ったが、 三年目の生活費を家庭の事情で捻出できなかったため、2年で切り上げ、Ph.Dは諦めた。
  • UMISTのMaster of ScienceとCoventryのM.Phil/Ph.Dの合格通知を受領した。奨学金が出ると いう事でCoventryを選んだ。UMISTはのちにThe University of Manchesterに併合された。Coventryは Master of Science by Researchでapplyしたが、M.Phil/Ph.D課程が奨学金付きでオファーされた。
  • アメリカのThe University of Texas at Austinはエッセーを書き直せば来年入れる可能性がある と言われた。当時、アメリカの大学院にいくつか応募したが、Austinを含み、全て初年度より授業料 全額免除及びResearch Assistantとしての給料をもらう事を前提として応募した。

* 注:スマートマテリアルシステム:電圧をかけることで動かすことができる材料

そもそもなぜ、海外大学院でPh.Dを取ろうと思ったのか?結論から言えば日本では就職が無理か極めて難し いと判断したからである。就職はできても生きていくのは無理だと思った。当時、日本での在日韓国人差別は結構あって、もう日本に住んでいるのが嫌になった。というより、日本で生きていくのは無理だと思った。だめ押しに 早稲田工学修士卒の伯父さんに某社からapplication formすら送られてこなかったと言われた。

高校在学時にどこからか仕入れた情報ではアメリカのアカデミックスクールでResearch Assistant (RA)をやれば授業料全額免除でさらに、生活費もRAで出るということであった。これだ、と思った。在日韓国人は韓国でも 馬鹿にされがちということなので、第三国で工学系Ph.Dを取れば生きていけると判断した。

イギリスは後に第二志望グループにいれたが、その理由は単純で奨学金の額が少ないからである。 結果、アメリカではAustinがエッセーを書き直せば来年入れる可能性があると言われた。UMISTのMScと CoventryのM.Phil/Ph.Dがオファーされた。博士課程飛び級入学で、奨学金が出るという事でCoventryを選んだ。

バックパック、ダンボール2つ、オファーレターを手にヒースローへ向かった。事実上の亡命だった。

M.Phil/Ph.D課程2年目に問題に突き当たる。EUレートの奨学金をもらっているものの、合計3年か4年Ph.Dコースを継続するためにはイギリスのHSBC銀行から借入が必要となる。借りるのは学費と寮費である。当時の為替レートで、学費年間50万円、寮費年間50万円(水道光熱、インターネット代込み)である。残り3年分を借りると仮定すると、100万*3で300万円の借入となる。今なら、将来キャッシュフローの増大をかなりの確率で期待できて、得だと判断して借りるだろう。イギリスの市民権取得にも近くなる。

結局のところ、プライベートのモチベーションと公的なモチベーション、両方必要だという結論に、今は至っている。損得を別にすると、自分の与信で借入可能で、連帯保証人も要らないはずとはいえ、Ph.D候補生として、銀行借入で乗り切っていいものか考える。生活費の借入ができないのも関連している。生活費は月4万円もあれば、足りるので、軽いプログラマーのバイトでも入れれば、よくよく考えればよかったかもしれない。週20時間のワークパーミットも持っていた。エネルギー問題のために研究をしているものの、プライマリーのモチベーションは自分の夢のためであって、そのために銀行借入はないのでは、という結論に至った。銀行借入はしないで、M.Philで終わりにすることにした。

院卒後は経済のグローバル最適化のためにITでERPか外資系投資銀行の投資銀行本部に行こうと考えた。学位取得後、日本に戻った。

IT業界に行ったら、そこに自由はあった。実力次第でもぎ取れる自由が。また、学生時代にあった在日韓国人差別もなくなっていた。

学歴/アルバイト歴

信州大学, 筑波大学

学位: 学士(工学), 2002年, 筑波大学, イングランドでのFirst Class相当(70%以上がA評価)
2000年-2002年 筑波大学 第三学群 工学システム学類 機能工学システム主専攻 (三年次編入学。3-4年)
1997年4月-1999年9月 信州大学 繊維学部 機能機械学科 (1-2年)
主専攻: 機械システム
副専攻(アンオフィシャル): コンピューターサイエンス
  • 授業料全額あるいは半額免除 (信州大学)
  • 育英会第二種奨学金 (信州大学)

信州大学の専攻はメカトロニクス。機械工学及び、電気回路、初歩的なプログラミング及び、CPUの構造など。 具体的には、微積、線形代数、確率統計、複素関数論、ラプラス変換、線積分、古典力学、固体物理、熱力学、 材料力学、流体力学、電気回路、初歩的なプログラミング及び、CPUの構造など。

筑波大学の専攻はシステム制御工学。この場合のシステムは具体的には機械システム。主専攻の特性上、科 目を選ぶのにかなりの自由度がある。具体的には古典制御工学、現代制御工学、システムダイナミクス、デジタ ル信号処理、電子回路、電磁気学、複合材料学、システム最適化、人工知能、画像処理、データ構造とアルゴ リズム、自然言語処理、運動力学、解剖学など。

授業のレベルははっきり言って、信州大学の方が上だった。信州大学松本キャンパスは元旧制高校である。しかし、筑波大学の特性を活かし、手広く授業科目を取る。また、図書館もフルに使い、乱読。また、スマートマテリアルシステムの存在を知る。信州大学2年次の時点で総合80%以上がAだったが、筑波大学では上記以外にも手広く広げたため、成績が落ち70%くらいがAだっ た。

筑波大学4年次は複合材料学の研究室に所属。そこで、結局、物理モデルを高精度化しても実験結果とモデル の誤差はなかなか縮まらない事が分かった。そもそも、モデルを複雑化すると、オーバーフィッティングの問題 や、そもそも、それはモデルではないのでは、と思い、モデルとは、何か考え始める。同時期に大学院での専攻を結局何にするか考え始め、全てを統括して研究するために、応用数学にしようかと考えていたが、最終的にある先生との問答の結果、制御工学に決めた。最終的に非線形制御とロバスト制御の二択になったが、ロバスト制御を大学院での専攻と決めた。

その先生に新しい分野を切り開いて下さい、と言われたが、まだ、そこまでは至ってない。

株式会社T-serv

バイクメッセンジャー · 1996年3月〜1997年3月 アルバイト

当時、家庭の事情で大学の学費を捻出するのが不可能だった。大学進学の際、都市銀行がお金を貸してくれないと言ったので、自分で学費を稼ぐことにした。浪人中にバイトで1-2年分の学費、生活費200万円を稼いだ。

途中から歩合給になりましたが、ゴールドマン・サックス、メリルリンチ、モルガン・スタンレー、UBS、クレディ・スイス、ブルームバーグ、マッキャンエリクソン、第一企画、博報堂、電通様などの大量発注などと、そして、もちろん、T-Servの方々のおかげで、な んとか学部在学中の学費(入学金)や生活費の一部を稼ぐ事ができました。ありがとうございました。

大学に行かなくても、プログラマとして、そこそこの収入を得られた可能性はあると思います。しかし、大学院で鍛えられた結果、思考の明瞭さと研究開発の力を得ました。それにより、仕事上では、高度なプログラミング能 力と自然言語処理分野でのアルゴリズム開発能力、そして実務上での仮説立案能力とPDCAを回す力を手に 入れました。それがなければ、スピード出世を重ねることや、その後、分析官や室長としてある程度結果を出す 事はできなかったと思います。収入の伸びもそんなになかったかもしれません。2011年に偶然にも母親を養う必要性が出てきましたが、収入の絶対値もそんなに高くなく、伸びも早くなかったら、それも不可能だったかもしれ ないのではないかと思います。

博報堂様とゴールドマンサックス様との奇妙な縁について、記述したいと思います。CV中にあるとおり、 C2cube時代に増資のプレゼンを複数行っていますが、その一つは博報堂様の子会社でした。場所は恵比寿ガーデンプレイス。時期は2007年秋頃。恵比寿ガーデンプレイスはモルガン・スタンレー様が入っていた場所で す。まさか、大学に入った1997年から10年後に博報堂様の子会社に対して、恵比寿ガーデンプレイスでプレゼ ンをして、500万円の投資を受けるとは考えていませんでした。また、同時に博報堂様本体からも3000万円の投資を 受けました。さらに、数年後、外資系グローバルITファームで博報堂様子会社に対して、Project Managerを行っていました。

ゴールドマンサックス様についても同様で2008年の1億円の増資のプレゼンにC2cubeサイドとして、既存投資家 の方が列席していました。その方は元興銀の方でした。興銀様はゴールドマンサックス様からよくデリバーに行っ たところでした。それを考えると、博報堂様の兼もゴールドマン・サックス様 / 興銀様の件も、浪人時代に一日 100kmとか走って、一年で200万円貯めた事を考えると、感無量です。ありがとうございました。

最後に、特別永住権を得たのは2013年の事で、それまでは外国人登録証を持つ、一人の外国人として暮らしていました。高校生の途中からアメリカあるいはイギリスの市民権を取るのが唯一つの生きる道だと思い、アメリカあるいはイギリスの市民権の取得を目指して、両国いずれかのPh.D取得を目指していましたが、日本で就職した後は、違和感はなくなっていた事と、2013年に特別永住権を取得した事で、日本に対する、まだ残ってい た、ある種の違和感 --例えば2012年頃にはTier 1 generalを取得してイギリスに戻ろうと考えていた-- はほぼなくなりました。

T-servの方々のおかげです、ありがとうございました。

法政大学第二高等学校

1996年卒業

  • 4000mチームパーシュート関東大会入賞。インターハイ出場権獲得。インターハイ出場辞退。(三年)
  • 40kmチームタイムトライアル。神奈川大会3位入賞(三年)
  • 4000m速度競争、関東大会出場。(二年)
センター試験(自己採点):
  • 一年目、総合78%
  • 二年目、総合83% (主要科目得点:物理90点/100点以上。英語196点/200点)
  • 受験科目:数学(2教科)、物理、化学、国語、地理、英語

まったくやる気がなかったが、さすがに大学くらい行くかと高2の夏から勉強を始めた。

法政大学第二中学校

1993年卒業

英単語3000単語を丸暗記した以外は特に何もしなかった。

目黒区立田道小学校

1990年卒業

当時まだバブル崩壊前で一億総中流という幻想の中にいた。いい大学に入り、一流大企業に入れば人生順風 満帆という事になっていた。家は確かに目黒だが、当時住んでいたマンションはボロく、まともにご飯も食べれな かった。しかし、母親の実家と親戚は金持ち。周りも金持ち。

ここで不合理性を感じる。

小学校ではまったく授業を聞かなかったが、高得点を連発。白金台方面にある塾では適当にやっていたが、トッ プのクラスに在籍(注:結構面白かった)。塾の同学年の全クラスでの全員入れ替え戦でも総合一位。四谷大塚 の目黒教室所属の準会員でおそらく目黒教室トップ3-5位(会員番号から推測)。準会員の週報には途中からほ とんど毎週乗っていた。四谷大塚の正会員との入れ替え戦では1点差で正会員を逃すくらい。四谷大塚の参考書?1回だけぺらぺらめくったことがある程度。連立方程式の解法的なことだったと思われる。加えると小学校教師のミスを指摘したりしておちょくっていた。

注:小学校でほとんどの科目のテストで高得点を連発していたが、通信簿の評価は低かった。どういう基準なのだろうか?一回、6年の時の担任に言われた事がある。「そういう事していると、私立中学の内申書の内容ひどくするわよ」だいたいにおいて、こういう内容だった。公権力あるいは独占的権力を持った公務員がこういう事を立場が弱い生徒に言っても許されるのだろうか?付け加えると小学校教師をおちょくる事はあったが、他の事は普通で誰かと喧嘩するなどはなかった。総合的に見ると、小学校教師をおちょくる以外は真面目だったのではないだろうか?

不合理性とは何か?上記事実から全国的に見てもそこそこ頭がよかったと言えると思う(あくまでもそこそこ)。 兄も結構頭が良かった。しかし家は貧しく、当時の日本の考え方を受け入れなかった。

そして、そこに親戚は金持ちという事が加わる。単純な矛盾ではないのである。当時は深く考えてなかったが、 直感的におかしいと感じていた。(おそらくほとんどの生活費や私立中高の学費は母親の実家から出ていたと推測される。大学の学費は自分で稼げという事だった)

そこに母子家庭という事実と在日韓国人問題が加わる。差別対象だった。通名?わけが分からなかった。

注:兄は大学を中退したが後に中小ITの部長級まで上り詰める。私自身もなんとか地方国立大学( undergraduate)を卒業(England基準でFirst Class)し、多額の返還義務無し奨学金をもらいながら、 Coventry University大学院でM.Philを取得。その後、ITベンチャーや外資系グローバルIT企業で研究開発をしたり、 Project ManagerあるいはProduct Managerを仕事とし、それなりの給料をもらい、それなりの生活を送る事ができるまでになった。

注2:M.Philを取得後、日本で働いているときにアメリカ合衆国での難民へのサポートについて本で読んだと記憶している。日本でそんな事が少なくとも私の学生時代にあっただろうか?いやまったくない。むしろ差別されていた。

不合理性とは何か??

キャラクター・基本能力

高い設計及び実装能力
  • KVSとWebアプリケーションフレームワークを設計、実装した
高い解析能力
  • イングランドの大学院生時代のM.Phil/Ph.D課程でのスマートマテリアルシステムのための適応ロバスト制御理論の研究で任意のN次元(工学的には事実上の無限次元)の時間変化する行列を解析にかけた
  • NLP、機械学習分野での数値実験/解析ベースでの新規アルゴリズムの研究開発。NTTコミュニケーションズに研究の成果であるレコメンデーションエンジンを納入/販売した
  • 室長、すなわち参謀長として室員、執行役員 経営企画部 部長、各部門長と共同で複雑に各部門が絡みあう全社を解析にかけ全部門の戦術/戦略を立案。最後にマーケティング戦術/戦略を立案。複数部門が絡む複雑なビジネスの全容が見えた
アントレプレナーシップ
  • 株式で1億数千万円と5人ほどのチームでGoogle USにChief IT Architectとして戦いを挑んだ
  • 売上高数十億円のIT企業が赤字転落した時に4.5人のチームを引っ張り、営業利益ベースで黒字転換のターンラウンドに挑み、成功へ導いた。その数年後、会社は上場した
  • ファッションテック企業で組織も未発達で何も会社になかった頃から、グロースハック室 室長 兼 システム開発部スペシャリストとして、30のチームを引っ張り、1. オペレーションでエッジを立て、参入障壁を儲けるべきだと考え、2. 週一の全体会議、Slack、メールによる日報、口頭によるコミュニケーションを通じて、有機的に相互フィードバックがかかる組織を作り出し、事業構築をし、シリーズBで成功し、億単位の増資。チームをシリーズCへと道いた
高いコミュニケーション能力・提案力
  • クライアントワークでオールド産業である島津やエスタブリッシュメントである博報堂子会社の人達と主にテレカンベースで仲良く会議とプロジェクトを運用していた
  • イングランドの大学院でLaTeX16ページの提案書を指導教官に提出、説得し、研究テーマを元々振られていた物から変更。そのまま、研究を進め、オリジナルだと認めてもらい、M.Philを取得。国際学会も出た。国際学会は一番簡単な制御理論で出た。やろうと思ば、100%でないものの、合計最低3回、国際学会で発表できたかもしれない
  • IT業界でも単に言われた事を実装しているのではなく、常に企画側と議論、話し合いながら、システムを作っている
  • IT側とトップマネジメント、両者の共通言語を使い、システム部門とトップマネジメントの橋渡しをしていた
  • たまに他部門の人とお菓子の交換をして遊んで、お互い仕事を振りやすくしていた
教育指向
  • 中小優良の子会社ベンチャーで主導権を握ってビジネスを回していたインターンをビジネスの途中から補佐。その学生は一度、ビジネスに失敗し、資本金1000万円を溶かし、心理的に痛手を被る。その学生が新卒になり、次の本社でのプロジェクトに一緒に挑んだ。皆でビジネスを成功させ、心理的ブロックを一部外すのに寄与したと思う
  • 室長時代、執行役員 経営企画部 部長が能力が高くて、大企業出身であるものの、ベンチャー特有の事をあまり分かってないようなので、たまに、小出し小出しにヒントを教えていた。また、中期経営計画にも現実味がないので、直接的に言うとどうかと思うので、議論で隠喩的に間違っているよと教えて、良い方向性に導こうとしていた
全体思考
  • イングランドの大学院のM.Phil/Ph.D課程の院生として、まだほぼ存在しなくて制御可能な材料であるスマートマテリアルシステムの数学的基礎理論をロバスト制御の観点から迫り、その漸近安定性を数学的に証明。実用化にはまだ、30-40年ほど、時間がかかるものの、理論物理/数学的にはスマートマテリアルシステムを実現可能だと証明した
  • PdM/Chief IT Architectとして、自然言語処理分野での研究ベースの利点欠点のある各種要素技術を繋ぎ止めて、プロダクトに落とし込んだ
  • グロースハック室 室長として、PdM/PM性を取り入れ、30人多部門編成の組織を指揮統括して、全体を作り出した
チームプレーヤー
  • システム開発部スペシャリストとして、部長と共同でチームをより良い方向性に持っていき、共同統治していた
  • 全社の教育のために、日報を全社員の事を考えて度々執筆してた
  • グロースハック室 室長、すなわち、参謀長 兼 現場の最高指揮官として、全社を統括・指揮。シリーズBを成功に導いた

文章一覧

その他資料

-学位記, Master of Philosophy, Coventry University, 2004年

社会貢献活動

Mass Media Coverage Map of The East Japan Earthquake

https://docs.google.com/document/d/1JvpLeq_hYKNENQ-hjAGqx1dmbyXdFnLKlfbL8lq-WxM/edit?pli=1

3.11について、マスメディアでどの地域が報道されていて、あるいは、されていなかったかをニュースなどのデー タで可視化するプロジェクト。共同PIとして、プロトタイピングを行った。簡単なアルゴリズムというよりクイックハッ クで結構うまくいった。

主な受賞:Prix Ars Electronica 2013, Honorary Mention in Digital Communities Category, 2013

Hiroshima Archive

http://hiroshima.mapping.jp/

主な受賞:アジアデジタルアート大賞2011,エンターテインメント部門大賞(経済産業大臣賞), 2012

Nagasaki Archive

http://nagasaki.mapping.jp/

二つの原爆の事を伝えるシステムに関わったのは、原爆が人道上の罪であり、国籍は関係ない と思ったからである。原爆は間違いなく、日本の敗戦のきっかけであったと思う。当時、日本の統 治下にあった朝鮮半島からすれば、独立のキーとなることである。ただし、通常の戦争で使われ る兵器でなく、原爆という大量殺戮兵器で一般市民を大量に巻き込んでのことであるから、仮に それが朝鮮半島からすれば、独立のキーとなっても、国籍独立で作るべきであると思った。

言語化はできないが、沖縄アーカイブは頼まれても作成に関わらないと思う。

主な受賞:第14回文化庁メディア芸術祭審査委員会推薦作品