外資系グローバルIT企業のPM -仕組み、場、リスク、先読み- | 金輝俊、Hwi Jun KIM

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

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

• 金輝俊 / Hwi Jun KIM

目次

• PMになった

• ボイスカンファレンス。まだ、コロナ時代ではない

• リーダーとPMの役割

• リーダーの役割変更と英語の公用語化

• リスク分析を始める

• チームが回り始めた

• カットオーバー

• 二つ目のプロジェクト。規模が大きくなる

• ノリノリで始めたものの

• 早朝会議とホテルからの出勤

• タクシー出社の日々

• 夏休みが終わったら、いきなりインフラを組む事に

• おかしい、チームが回らない。何か間違ってない？

• 何とかシステム開発終了とオフラインクライアントプレゼン

• 残るはデータ移行、UI改善とパフォーマンス最適化

• こんなのアジャイルじゃない。Country Managerの発言

• プロジェクトを外れる。的外れなシニアマネージャーの指示

• ファッションテックベンチャーでPMとPdMの特性を入れた、室長として成功

• 著者略歴

PMになった

日本は現場は強い。開発もハードウェアはかなりいい。世界トップレベル。ソフトウェアは多少、まともになった。でも、管理と戦略が弱い。筆者はソフトウェアも強いが、管理と戦略もまあまあ強い。PMは後の室長としての基礎にもなっている。戦略は独学。では、どこで、管理を身に付けたのであろうか？答えは、外資ITである。

以下、筆者のPM時代の話である。

外資系グローバル企業であるCI&Tのの東京支社に転職した。肩書きはSystems Architect。シニアアーキテクトで実装はしない。設計とProject Manager(PM)に対する助言が主なロール。

PMとは何であろうか？世の中には色々なPMの本があり、筆者が3 - 4冊読んだ限りでは、どれも言っている事が違う。筆者なりの解答は、仕組み、場、リスク、先読みである。それ以上でもそれ以下でもない。WBSがどうとか、ロードマップがどう、とかは本質ではないと思っている。

この企業はグローバルで1500人。売り上げ高800億円くらい。すごいと思う？ASPAC、つまり、アジア太平洋地域だけだと全部で80人くらい。ASPACは東京、中国の地方、オーストラリアからなる。オーストラリアはhead of operationが1人いるだけ。ASPACで一番偉い人。東京はPMO、つまり、Project Management OfficeでPM級以上しかいない。主に管理と設計の一部だけする。あと、もちろん、Country Managerも。つまり、東京支社長。中国支社は設計の一部と開発を担当。いわゆるオフショアってやつだ。

入社1週間くらいで、中国出張が決まった。2週間。もちろん、飛行機代、ホテル代は社費。ビジネスVISAを取って、いざ、中国へ。大陸中国は初めて、ご飯は美味しいのかな？

羽田発のANAに乗って、上海へ。空港に降り立って、しばらく歩いたら、プラカードが。Hwi Jun KIMと書いてある。CI&T Chinaが雇った、運転手の人。専用のレンタカーと運転手付きで上海の衛星都市にあるCI&T Chinaまで。時間にして5時間。アウトバーンをぶっ飛ばした。

CI&T Chinaは30階くらいあるの高層ビルで20Fくらいに入っている。結構、いい環境。周りには高級外車も結構走っている。

中国支社では最初挨拶回りで、リーダー級とランチに5-6回行った。最終日近くに、あるプロジェクトのカットオーバーの夕食会に呼ばれた。イギリスの大学院留学時代で中国人は慣れているので、違和感はない。やはり、本場の中華は美味しい。フレンチもパリと東京でちょっと違うんだよね。多分、日本用にカスタマイズされているというのが、筆者の見解。

2週間で皆んなに馴染んだ。じゃあね、プロジェクトで会おう。中国を後にした。

この会社は基本的にオフショアの会社。ビジネスアジャイルを標榜していて、毎日、クライアント会議をする。もちろん、Webと同じでクライアント側にProduct Owner(PO)を置いてもらう。会議はコロナ以前としては珍しい、ボイスカンファレンスで。

ちなみに、この会社の標準ツールはGoogle Drive、GMail、Skype/Google Hangoutである。バージョン管理はgitでASPACは基本、LAMPスタックでPHP。開発しているのはECやCMS。フレームワークにDrupalを使う。Drupalは確かにいいフレームワークかもしれないが、微妙に概念が普通のものと違って、分かりづらい。とりあえず、速攻でDrupalの本を買った。SIと言えばSIだが、微妙にWebっぽい。業務は多少ある。別に大規模じゃないけどね。

あるクライアントのボイスカンファレンスにPMロールのシニアマネージャーと一緒にSystems Architectとして、毎日参加。なるほど、こうやって仕事を進めるのか。中国側にもSoftware Architectがいて、その人はジュニアアーキテクトで現場での設計と開発の指示を行う。

今から考えれば、シニアアーキテクトとして、PMに積極的に助言したり、中国のSoftware Architectにもっと積極的に助言すればよかったが、当時は入りたてでちゃんと分かってなかった。能力的にはできたけどね。ただし、後になって、ここの経験は生きて、室長 兼 スペシャリストへの道へ繋がった。

何故、スペシャリストとして、部長と対をなして、助言をできたり、室長として、全社を統括できたのか？答えは、マネージメントを解ったから。ということはよく考えたら、PMを一年やって、二年目にSystems Architectに戻っても良かったんじゃないかな。そしたら、ワークしたはず。よく考えたら、Systems Architectって管理職としてのアーキテクト出し。当時はリーダーシップは分かってたけど、マネージメントが分かってなかった。ただ、PMを二回（最初はPL。すでにPMに近かった）をやって、分かった。

ある時、Country Managerから新規事業のPLやってみない？と言われた。いいね。良い経験になるからやってみようかな。やってみると分かるが、これはPLというより、事実上のPMだった。入りだから、PLという手前上にして、軽くしようという目算だったのかも。とういうことでPL 兼 Systems Architectになった。

さっきサラッと書いているように、やってみると、PLはリーダーというより、マネージャーだった。初めてのダブルポジションとマネージメント。リーダーはやったことあったけどね。

ボイスカンファレンス。まだ、コロナ時代ではない

ちょっと、会議室で話そうよ。普通はオフィス内で口頭で話して、会議室に行って始まる。スケジューラーで会議室の予約はもちろんする。

ちょっとボイスカンファレンスしようよ。最初、ちょっと違和感があった。正直、ボイスカンファレンスは慣れないとやりずらい、中国との回線が細いので、ビデオカンファレンスにできない。声色だけで判断するのは色々難しい。表情も場の空気感も伝わらない。

この会社の現場リーダーは大抵、日本語を喋れるものの、他のメンバーは中国語と英語だけなので、英語で話す時もある。最初は英語が公用語ではなかった。発音は悪いとは言わないが、良くもない。まあ、98%くらい分かるので、英語でも問題はないが、微妙に面倒い。いちいち、有線のインカムをMacに挿すのも面倒いし。

毎日のようにクライアントとボイスカンファレンスをやるし、チーム内でもしょっちゅうやる。何百回、ボイスカンファレンスをやったか覚えてない。コロナで、zoomなどのネットカンファレンスシステムは当たり前になった。今思うと、当時、苦労して慣れてよかったと思う。

高校時代の自転車競技部も最初は大したことなかった。結局、3年でインターハイ出場権獲得まで行った。研究も学類4年でPrincipal Investigator(PI)として、指導なしでやってみたが、軽く失敗し、先生に助け舟を出してもらった。80%くらいしか、自分自身ではできなかった。大学院ではPIとして、成功し、M.Philを取得した。

筆者は大抵、最初どうかなー、くらいか失敗ぶっこいて、2 - 4回目で成功する。そういう人。今回もそうだった。

リーダーとPMの役割

PMって何だろう？リーダーって何だろう？ここでは一般論でなく、この会社や筆者が作ったチームでの話を書きたいと思う。

リーダーはどちらかと言えば、現場で状況を見ている。PMは引いてみている。オフショアでPMとリーダーが違う国にいるから、特にそうなる。

PM？タスク管理でしょ？それはメンバー自身の仕事。たまにリーダーも関わる。進捗管理があるからね。リーダーはどちらかと言えば、タスク管理のスーパーバイズをして、PMに日々報告する。そして、PMはさらに高次元の事を考える。

別にタスクの執行がどうなっているか見るだけなら、ITS(Issue Tracking System)、この会社ならJiraを使えばPMも把握できるが、議論が必要なので、リーダーに報告してもらって、議論したり話し合ったりする。

そこに、PMはCheck and Adaptというプラクティスでチームをカラーチャートを使って、評価にかける。例えば、チームメンバーに問題はないか、とかね。

そして、一番重要なのは、blockerとリスク。両者は似ているが、blockerは現場に落ちている障害物でリーダーがidentifyして、取り除く方法を考え、さらにPMに報告する。リスクはマクロで引いて見える何らなの問題の一種で主にPMがidentifyし、リスクのmitigation(緩和)方法などを考え、執行し、プロジェクトのリスクを減らしていく。リスク対策のstrategyとしてのtransferとacceptは筆者は滅多に使わない。

リスクは発生確率を0 - 3の間で評価し、インパクトを0 - 3の間で評価する。なので、両者の掛け算のrisk exposureは発生確率 * インパクトで0 - 9の間になる。数字が多いほど、ヤバくなる。筆者の経験上、全てのリスクの平均が4以下。最大が6未満になれば、プロジェクトは結構上手く回る。リスクを平均で0にするのは経験上、無理と分かっているので、目指さない。

リーダーの役割変更と英語の公用語化

クライアントとのデイリーコミュニケーションは日本語で筆者がやっていた。中国側のアーキテクトとは筆者は英語で。リーダーとは日本語で行っていた。リーダーは中日英トリリンガルである。英語は後で分かったんだけどね。

何かおかしい。シニアマネージャーも複数プロジェクトを掛け持ちしていて、中国側リーダーがクライアントと直接メッセやメールをしているのを見かけた。ちょっと待てよ、うちのリーダー、日本語できるし。そもそも、アーキテクトと筆者は英語でやりとりしてるし、チーム内は全部英語にして、クライアントだけ日本語にしよう。そして、クライアントはリーダーに直接日本語でやってもらう。

リーダーと話し合う。OK。シニアマネージャーもOK。リーダーにTOEFLの点数を持っているか聞いたが、受けた事がないとのこと。ライティングのサンプルをもらったが、結構綺麗なので、以外。最初はリーダーもクライアントと直接日本語でメールのやりとりをするのは緊張するので、筆者が日本語と技術的な事をチェックする事にした。ただし、リーダーが直接日本のクライアントに日本語でメールを出して野良う。

日常のクライアントコミュニケーションはリーダーが行い、見積もりやビジネス状の話など、高レベルなクライアントコミュニケーションは筆者が行う事にした。英文をメールを書き、東京側、中国側の偉い人にも送り、正式にこの方式が承認された。

チームが自動回転始めるまで、あとちょっとだった。

リスク分析を始める

リスク分析。入社時のボーディングセッションでも、PMなりたてにシニアマネージャーから言及はなかったもの、PMを始めて、数日でサンプルを見せられたので、記憶の片隅にはあった。ちょっとプロジェクト回すのが楽になったので、このプロジェクトのリスク分析管理ファイルを見てみる事にする。

中国側リーダーが何か書いている。もちろん、英語。一生懸命書いてあるのは分かるが、ちょっとまとハズレかな。ちょっと考えてみよう。そもそも、本来はPMとかSystems Architectの仕事のはずだし。

考えてみると、リスクは結構思いつく。それがいいのか、悪いのか分からないけど。mitigation、つまり、緩和策は頭をちょっと捻らないとでない。でも、思いつくと言えば、思いつく。その他の数値もまあ、思いつく。これは、例えば、リスク発生確率で逃げたら、負けだな、と思った。PMが意図的に確率を低めに書いて、言い訳できるかもしれないが、後で、プロジェクトに問題が出るはず。真剣に検討した。

チームが回り始めた

どうやら、チームが自動回転し出したようだ。思い出した。マネージャーは雑用係、暇ぶっこいているマネージャーがいいマネージャー。忙しがっているマネージャーはダメマネージャー。マネージャーはチェスを指す。結構前から、この文言は知っているが、いまいち腹落ちしてなかった。

ここから、マネージャーはギアのカムにちょいちょい、オイルを足して、あとはバターピーを食べて寝てればいいことに気づく。

相次ぐ仕様変更

仕様変更が多すぎる。筆者がプログラマーをしていればついていけるレベルだが、普通は無理っぽい。やはり、中国側から不満が出た。PLとしても手こずる。あらかじめ、先読みして、クライアントと素材の入稿など納期など細かくお願いしたりした。実は素材は海外で写真撮影をしていて、時差の問題やクオリティに対する納得感もあるだろうし、難しかった。

実は、クライアントは博報堂子会社の博報堂プロダクツである。ここと、博報堂本体とそのクライアントがも関係があり、本体とクライアントが海外に行っていた。

最初は単純なサイトとCMSだし、楽勝じゃん、と思ったけど、そうでもなくてこずった。

だが、リスク分析に集中し、先読みできるところはして、事後でもリスクmitigationをしていくと、ギリギリ何とかプロジェクトが回った。

カットオーバー

そうこうしていくうちに、何とか開発をカットオーバーして、デプロイした。予定時間より3分遅れ、まあまあ。クライアントから携帯に電話がかかってきて、動画に音楽も入っていて、かっこいいから、是非見てくださいと言われた。博報堂プロダクトの人は年上で、単純に嬉しかった。ついでに、クライアントの最終報告会、一緒に行かない？と言われたが、そこは流石に丁重に辞退した。

Country Managerから、3分デプロイ遅れは甘い、と言われた。まあ、しょうがない。次に生かそう。

中国側に会社経費で飯に行ってもらった。自身も私費で寿司に行った。

二つ目のプロジェクト。規模が大きくなる

今度は明確にPM。どうやら、ASPAC中から私に対する評価がかかって、PMになる承認が降りたみたいだ。

メンバー構成は以下の通り。合計12人編成。いきなり規模が大きくなった。まあ、何とかなるだろう。

東京オフィス

• Project Manager 兼 Systems Architect(私)

• ITコンサルタント

• Program Manager

中国オフィス

• リーダー(ブリッジSE。日常のクライアントコミュニケーションの一部などを担当)*1

• リーダー補佐*1

• Software Architect(インフラ、及びシステム設計担当)*1

• サーバーサイドエンジニア*2

• フロントエンジニア*1

• テスター*2

• ホライゾンタルリーダー*1(中国側の全リーダーのアドバイザリー的な存在)

相変わらず、公用語は英語にした。

ジングルを鳴らした。以下、会社内の関係者に送ったキックオフのメール。

Hi all,

This is Hwi Jun KIM, a Project Manager of this new project from Tokyo office.

Let me introduce myself. I am South Korean but I was born and grown up at Tokyo, Japan. For my post graduate study, I had been at Coventry, UK. There are many Chinese persons including our research laboratory. I am familiar with Chinese.

My role is PM. In this project, as this email, common language is English. All the email, skype/hangout message and documents expect documents for client will be written by English. That is because of fact that it is better to share almost all document both in all members of Tokyo and China office.

Our client is Shimadzu whose head quarter is Kyoto, Japan. Its topline is close to that of major TV station in Tokyo, Japan. Also, they has a nobel prize in the field of physics. They are really high-tech company.

Sometimes, their news would be broadcasted by TV and massive PV will be taken and server would be down if its application and infrastructure is not good.

We should make better application and infrastructure which is robust and good for client which would be never down.

As a project manager, I welcome any discussion. Don't hesitate to disucess with me even I am PM and being at Tokyo office. However, final decision will be done by me.

From now on, this project is started.

BR,

Hwi Jun KIM

ノリノリで始めたものの

プロジェクト組成の資料をGoogle Slideで作り、京都の島津本社でキックオフミーティング。前回のプロジェクトで回し方は分かった。私自信もSystems Architect (シニアアーキテクト)兼任ではあるが、中国側にSoftware Architect (ジュニアアーキテクト)とマエストロがつくことになった。

最初は良かった、徐々におかしさに気づく。でも、何故か、プロジェクトがうまく回らなくなっていく。ちょっとづつね。

早朝会議とホテルからの出勤

前回のプロジェクトは会議は確か週2-3で10:30くらいから。大体30分くらい。今回は朝9:30からとなった。当時、筆者は早朝は苦手で、マジ無理。本気で1回目のボイスカンファレンスに遅刻し、Country Managerから叱責された。それはそうだ。もちろん、謝る。クライアントは笑って、許してくれた。

1、2回、朝8:30からの会議を組まれた。今なら、ハイブリッドワークやリモートワークは主流になっているので、家でボイスカンファレンスをやって、その後出社だが、それはたまにしかシニアマネージャーには許されない。なので、会社近くのホテルを押さえて、しかも、タクシーで出勤した。プロジェクトを成功させるにはこれくらいする。むしろ、それで成功するなら、それくらいのキャッシュを切る。

私費だった。よくよく考えたら、プロジェクト経費でも良かったかもしれない。PMは毎月一定額、シニアマネージャー決済なしで、自分自身の決済で経費を使える。たまに、中国の開発メンバーに経費で飯に行ってもらった。これで、ビジネスクレジットカードがあれば完璧だったけど、leaderじゃ流石にないかな。

タクシー出社の日々

8:30のミーティングならホテルとタクシーかもしれないけど、毎日の通勤もタクシーにした。何故か？当日朝9:30のミーティングの内容を頭の中で組み立てるため。電車に乗りながらじゃ無理。前日夜に考える手もあるが、中国と時差があって、リアルタイムの報告にならないし、そういう習慣にした。たった1時間の時差でも問題になるもんだと分かった。

夏休みが終わったら、いきなりインフラを組む事に

あらかじめ、開発ストーリーはプリセールスチームが組んでいた。インフラも当然、ストーリーの一つにあるが、それは終盤戦、ほぼほぼシステム開発が終わってからにしようと思っていた。何故か？アプリケーション層のパフォーマンスによって、要求されるAWSのインスタンスサイズが変わるはずだからである。

夏休みを取れる事になった。シニアマネージャーに代役をやってもらう事に。9連休。それでは。

帰ってきたら、何故か、インフラを来月くらいから組む事になっていた？何故？先方の予算の問題。それにしても...。まあ、言っていてもしょうがない。何とかしよう。SIの洗礼をまた浴びた。

おかしい、チームが回らない。何か間違ってない？

何故か、クライアントへのメールを自分が出している。何故か、クライアントへのQAを自分がまとめている。社内メッセージングシステムがSkype、Hangout、GMailと諸々あって、統一されてない。今なら全部、Slackに通知して一発だが、通知がバラバラ。

時間がクライアント周りに取られ、本来のPM活動に時間をさけない。本来、リスク分析に集中しよう。そうプロジェクト開始前は思っていた。

問題はリーダーの日本語力と気づいた。エスカレーション用の資料を作り、シニアマネージャーに投げたが、それは違う。と言われた。よく考えたら、そこで諦めず、Country Managerに投げるか、オーストラリアのhead of operationにメールしても良かったかもしれない。

ただ、この時の知見は後のファッションテック企業でのコミュニケーション設計に生かされている。これはこれでいい経験だったと思う。

何とかシステム開発終了とオフラインクライアントプレゼン

システム開発自体は何とかデッドラインまでに終わった。ほとんど、spread sheet上の客観的なリスク分析なしでである。ある程度の先読みとガッツで何とかなった。東京オフィスと中国の現場双方のね。

京都の島津本社でこれまでの成果をプレゼン。まあまあの手応え。プレゼン終了後の非公式の関係者同士の話でも、海外のシステムのCI&T開発のものへの載せ替えの話が出た。これは、成功かな。良かった。新幹線で帰ろう。

CMSと言えど、全体に対する売り上げのインパクトもあるし、いいんじゃないかな。

残るはデータ移行、UI改善とパフォーマンス最適化

データ移行は一番、問題になるとプロジェクト開始直後から思っていたので、マエストロにプロトタイピングをプロジェクト開始当初から指示を出していた。マエストロは個人的な事情でプロジェクトを抜けたが、ジュニアアーキテクトが普通にデータ移行を回している。よし、これはこれでOKっぽい。中国にあとは任せよう。現場にできる事は現場で。それがPMだと思う。

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

こんなのアジャイルじゃない。Country Managerの発言

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

余談：では、何故後のフェーズになって、DBのクエリの問題が分かったのであろうか？答えは、多分、開発環境ではMySQLがローカルのループバックインターフェースで繋がっていて、一見、妥当なパフォーマンスに見えたからだろう。解決策はサーバーの種類を定番のProduction、Staging、ローカルVMに古き良きDevサーバーを加えて、MySQLをネットワーク的に遠くすることだろう。ネットワーク的に遠くするのはオンプレだとちょっと難しいかな。AWSなら簡単だろう。Dev環境でマルチAZにすればいいと思う。

そこで、諦めずにCountry Managerと粘り強く話せば良かったかもしれない。上のような件も含めてね。

ファッションテックベンチャーでPMとPdMの特性を入れた、室長として成功

シニアマネージャーはしょうもないタスクを振ってくる。それ、PMの仕事じゃないんだけど。しかも、一々、細かい。そこじゃない。的外れな事が多すぎる。無視する事にした。

システム開発は終わり、あとはインフラのパフォーマンス、UI、データ移行で中国マターで東京オフィスはあまりやる事がないので、ある時、2-3日有給を取る事にした。Country Managerの了承が取れた。

PMはあまりにも疲れる。クライアントの方を向かない的外れなシニアマネージャーも相手にしたくない。CI&Tをやめて、どこかに業務委託で週3日の世界に行こう。これなら、結構休めるし。職種はプログラマーに戻して、相変わらずの短時間勤務に持ち込もう。

有給が終わって、出社したら、Country Managerにもっと休みなさい、と口頭で言われる。その通りにして2 - 3日くらい休んだ。

休んでいたら、Country ManagerからPMの解任のメールをもらう。何で？意味が分からない。まあ、いいや、もう、転職の準備始めてるし。そこは素振りも見せず、交渉して、パッケをもらった。業務委託で3ヶ月、軽い仕事をして、時間が余る中で月額ベースで報酬を受け取る。月額報酬は変わらず。これで、せいせいした。専門職の世界へ戻る。

結論から言うと、ファッションテックベンチャーでグロースハック室 室長 兼 システム開発部 スペシャリストとして、成功した。室長？そう上級管理職である。部長と執行役員の中間体かな。室長はPM、PdM、MBAの合わせ技。もうPMをやる気はなかったけど、PMは実はできるのでは？と参戦してから数ヶ月で思い直して、室長として仕事を遂行したら、案外上手く行った。

結局、CI&Tで2つ目のプロジェクトが一勝じゃなくて、一分なのは、たった一つだけあげると、チーム編成の問題だと思った。リーダーとサブリーダーをスイッチして終わりだったかもしれない。サブリーダーは一つ目のプロジェクトで一緒になったリーダーで中日英トリリンガル。こっちのプロジェクトのリーダーは一応日本語はできるものの、クライアントのコミュケーションを取るのはダメ。筆者がクライアントコミュニケーションに時間を取られすぎた、そこが問題で、例えば、リスク管理に集中できず、問題が出た。それでも、何とかシステム開発終了まで持ち込めたけど。ガッツだけで終わらせるのは外資PMっぽくない。やっぱ、分析ベースでクールにやらないと。

もし、CI&Tに二年目以降も残って、Systems Architectとして勤務したら、1 - 2年でobservedでmanagerなんじゃないかな（managerは課長と部長の間。CI&T在職時、筆者はleaderだった。係長と課長の間くらい）。PMなら3年でobservedかな。

のだめの日本の学部卒業の時じゃないけど、あの時の経験が後になって効いてくる。これで、良かったんじゃないかな、と思っている。

CI&Tグローバル本社はこの数年後、NYSEに上場した。

著者略歴

金輝俊 / 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/

以上