皆さんごきげんよう。ういこうと申します。
これまで日本マイクロソフト株式会社で Azure のフロントエンド領域を中心としたサービスの Product Marketing Manager をしておりましたが、6/30 日をもって退職することとなりました。
きっと Microsoft 界隈以外では、あなたどなた？という感じだと思いますので、少し自己紹介と、退職エントリ（のようなもの）を書くことにした理由を紹介させてください。ちょっと、いや...かな～り長いので、おやつでも食べながら読むものがないなーというときや、今エンジニアなんだけど、マーケティングなど、テクニカル ロール外の職種に転換しようと思ってる、あるいは迷っている人などのご参考になると嬉しいです。
ちなみに先日は Microsoft 本社のイベント Build でお話させていただいたりしていました（最後の仕事になりました）。
自己紹介・なんでこんなエントリを書くことにしたのか
私をご存じの方は、ここ 6 年ほどのマーケの活動をご覧になっている方がほとんどだと思いますが、実はこれまでのキャリアの大半をエンジニアとして過ごしてきました。マイクロソフトでも、16 年サポート エンジニアをしていました。マーケに転身する前日まで、カーネル ダンプを WinDBG で解析したり、Visual Studio でサンプル コードを作って動かして検証したりなどしていたくらい、エンジニア一筋のキャリアでした。異動するまでは。
MS エンジニア時代も、後述するプロジェクト「ILM 一家」があり、ちょいちょいデベロッパーコミュニティイベントなどで話したりしていたので、エンジニアとして知っていたよ、という方もいらっしゃるかもしれません。
なぜ、このエントリを書くことにしたかですが、まず社内で退職を告知するメールをスパムよろしくどーんと出したところ、エンジニア系の方から以下のようなご質問と、1on1 Meeting 依頼をちょっとびっくりするくらいの数頂いたこと（また linkedIn や Facebook 経由で社外の方からも複数お問い合わせいただきました。時間が合わずお受けできなかった方申し訳ございません）、こうした反響から、みんなキャリアや先々に悩んでるんだな…と思うと同時に、迷っている人には共通の特徴があることに気づいたことがきっかけです。
・「マーケに興味があるが、どうしたらそういうキャリアにシフトできるか」
・「どんなことをしていたか」
・「エンジニアからマーケの転換のさい、どんな苦労をしたか。そしてどんな手段でそれを克服したか」
...などなど。
この「特徴」については後述します。
また、もう一つは、これは外部の方にこれまでもちょいちょい聞かれたんですが、私のかつての身体的特性に基づくちょっとした事情などもあり、ここまでの道のりが結構大変だったのですが、そうした事情を知っていただくことで、同様の事情を抱えた人の参考になるかもという点もあります。これも後述します。
日本マイクロソフトを辞める理由
退職を周りに Open にしたとき、ちょっとした（でも自分史上としては結構な）反響がありました。Facebook では知人の範囲のみであったのですが 680 件以上のリアクション、LinkedIn でも 600 件以上、社内メールも 100 件以上の返信と、想定外のリアクションをいただきました。なんでそんなに反応あるの！？と自分史上最大のバズりを記録して、えぇ…なんか怖い…とちょっと震えたくらいです。21 年もの長い間マイクロソフトに在籍していたということが、それだけのインパクトを生み出したのかもしれません。
そんなわけで、これが一番よく聞かれるのですが、私が辞める理由は「一つの目標をやり切ったから」です。
私がマイクロソフトに入社したきっかけは今は亡き Visual J++ という製品のサポート エンジニアとしてでした。
これがまたかわいそうな製品でして、Wikipedia の記載を見ていただくと「あぁ…」という声が漏れる気持ちになっていただけると思うのですが、まあこれの事実上のクロージングを担当することになったのです。
このように、Visual Studio 関連の製品をきっかけに入社したこともあり、マーケに異動した際に自分の中で立てた目標は「Visual Studio 系製品のローンチをする！」ということでした。それを今年 2 月に事実上のローカルローンチイベントに相当するイベントが出来、自分の中で一つの区切りがついたことで、次のチャレンジを考えることにした次第です。
なおこのイベントは社員だけでなく、Microsoft MVP (Most Valuable Professional) のみなさんにもご協力いただきました。ありがとうございました。
これまでのキャリアについて (1) : 高校、大学～新卒の会社
さて、自分の記事を探すときなどにたまに自分の名前で検索することがあるのですが、一時検索エンジンの Suggestion に「横井羽衣子 学歴」「横井羽衣子 大学」と出たりしてて、何でまた学歴が気になる人もいるんだろうかと不思議に思ったこともありましたが、よくよく考えてみるとそうかもしれません。なぜなら私、ちょいちょいイベントに出してる bio でふれてたりしますが理系ではなくて文系大学の文学部哲学科出身なんですよね。なので、何でマイクロソフトでエンジニアやってて、マーケティングやってんだ？と思われるのかもしれませんね。
ローマ哲学とかラテン語で読んだりしてました。大学 4 年の 10 月まで、今はわかりませんが、少なくとも当時は哲学科には大学院がなかったので、他校の大学院に進学して、一生ローマ哲学やるんだって思っていました。
ちなみになんで国学院大学？というところですが、中学時代に漢詩に出会い、漢文学をやるんだ！と決意して、後述の事情はあったのですが大学受験したくないなーと思って漢文学が強い国学院大学の付属に入って、なぜか哲学に移行したという…。（野球やラグビーなどが強い国学院大学久我山高校というところです）
小学校・中学校に行けなかったけど、何とか高校へ
この記事の最初のほうに「私のかつての身体的特性に基づくちょっとした事情などもあり、ここまでの道のりが結構大変だった」と記載したのですが、そこについて触れさせてください。そのひとつが、小児喘息（推定）です。
実は私は小学校、中学校とほとんど通うことができませんでした。保育園時代から三か月から半年おきに入院を繰り返して肺炎に至る状況で、当時母子家庭だった私は家でじっと寝ているか、あるいは入院して動けない日々を送ることしかできませんでした。この状態は中学 3 年まで続きました。ですから、言っても嘘みたいに思われるのですが、大事な九九や、日本地図などを覚えるタイミングを逸しており、大変恥ずかしい話ですが九九も正直怪しいくらいです。
小学校時代、半年くらい入院して復帰した後、いきなり７の段を当てられてもちろん暗唱できず、みんなの前で恥ずかしい思いをして、私は数にかかわることが大嫌いになりました。それから数学まで、ずっと学力不足に悩まされることになります。
そんなわけで、もちろん成績は学年最下位で、先生もここまでひどいともう面倒くさがってフォローしてくれないのが常でした。（たまたま、そういう先生たちに当たったのだと信じていますが。）塾には在籍していたので、塾の講師（今思うとアルバイトの大学生なんですよね…）がわざわざお見舞いがてら資料をもってきてくれたりして、何となく今学校でどんなことが学ばれているかを想像することができました。途中からは、病院の中にある「院内学級」に所属を移しました。具合が悪いときもプリントに名前を書くだけで出席にしてくれたおかげで、出席日数的なモノは何とかなるようなところでした。院内学級は病院や療養所によっては今もあるかもしれません。
まあそんなわけですから、周囲からは早い段階で高校進学は絶望的だと思われていました。中 2 の時に、当時の担任が家にプリントをもってきて、「お嬢さんは高校に行けないので、専門学校にいって手に職をつけるのはどうか」といわれました。それを聞いた母は大激怒し、私はそのあと数時間説教をされたものです…。でも、勉強をどうしたらいいかわからない。そもそも「勉強の仕方」がわからないのですから大層戸惑いました（いまだにわかりません）。後年息子氏が小学校に通うようになって、小学校では意識せずとも学び方を学ぶものなんだなと義務教育の重要性を痛感しました。
話を戻しますと、中 3 で、自分のこの先は高校に行けなければ、かなりの選択肢を失うことに気づいた私は、なんとか 10 月退院してから頑張って高校に行こうと決めました。この時点で偏差値が 43 でした。数学はほぼ白紙で 0 点ばかりだったので、偏差値は最下位だったと思います。受験まであと半年もありません。そこで毎晩過去問をかたっぱしから答えを見ながらなぜそうなるんだろう？と逆算する方式を取って解きまくりました。この「答えを見ながらなぜそうなるか」を考えるやり方はとても役に立ったと思います。知らないことをいくら考えても時間が過ぎるだけですが、解き方、考え方を学べば応用もできるメリットもあります。後日、わたしが大学生になってから家庭教師をしていたのですが、数学系が苦手な子もこの方法をとることで大幅に理系科目をリカバリーすることができました。みんながみんな向いている方法ではないかもしれませんが、数学が苦手なお子さんをお持ちの方はお試しいただいてもいいかもしれません。
そして英語。「なんで a と an があるんだろう？」というところからやる必要がありました。そこで文章を何度も読んで、「母音だ！」と気づいたところがきっかけとなり、何となく問題集をたくさん解きたくなってがんばるようになりました。国語は入院中ひたすら本と新聞を読んでいたので、勉強しなくて済みました。新聞と本を読むと、たいていのことはできるようになります。でも、書き順は習わなかったからいまだにわかりません。たまに恥ずかしい思いをしますが、仕方ないです。
残りの理科と社会はすっぱりあきらめ、内申点なし一発受験ができるところに絞りました。当時担任はどうせどこを受けてもダメだから、と好きに受験をさせてくれました。このころ、漢文をやりたいという目標で国学院大学に入りたいと決めていたので、がんばれました。何とか入れてくださった母校には、感謝しかありません。
小児喘息は高校に入ったら嘘のようにおさまりました。だったらもっと早くおさまってほしかったな。
文学部哲学科に入って、家出 ～ IT 業界に手を染めるまで
ここから怪しげな内容になってきますが、母親ととにかくうまが合わなくていつか破滅的な事態になるんじゃないか、と思う日々がずっと続いていました。そんな中ある決定的な出来事が起こり、親に出てけといわれてしまいました。これが 20 歳の時です。
それまでは何となくそうした状況で、明らかに母が問題あるだろうと思ってもお話しにならないのであきらめて自分が折れるということを繰り返していたのですが、ふと家出してみてもいいかも。20 歳超えたし。という気分になり、本当に家出。母親がいない間に引越センターのその場で梱包してくれるサービスを駆使し、全部家から持ち出すという、今思うと母には申し訳ないことしたなあと 5% くらい思う暴挙に出て、一人で暮らすことになりました。
まあそんなことすりゃあたりまえではあるんですが、大激怒した母親は家の鍵を変更。家に入れなくなりました。それで何が困ったかというと、私は体があまり丈夫ではなかったので、保険証が使えなくなったことでした。大学 4 年のころ謎の発熱に悩まされ、これは病院行かないと死ぬなと思い、10 月過ぎていましたが大学の就職課にふらふらといきました。この頃は市販薬は全く効かなくなっていて、どうしても保険証をゲットする必要があったのです。
この後、病院で治療を受けたり、仕事が決まったことで安心したのか一年ほどで熱に悩まされることが減っていきました。親との関係や、将来への不安などがストレスになっていたのかもしれません。ただ、今でもたまにストレスがかかるとよく熱を出します…。
しかし時は 1998 年の就職氷河期。ほとんどの就職票のファイルは空っぽでした。というか、大学 4 年の 10 月で初めて就職課に来るってバカなの？ナメてるの？と言われましたが、大学院行きたかったんで…と（家出以外の）事情を話し、何とか探してもらったところ、以下の二つが奇跡的に女子でも受けられる枠として残っているよと言われました。（まだ男子の枠は結構あるんだけど…と申し訳なさそうに言われました。そんな時代だったんですね）
- 某消費者金融の事務
- システムエンジニア（SE）
SE って何？というありさまでしたが、当時のクラスの友達（女子）で、まだ決まっていない子が SE の就職相談会と試験を明日受けるというので、私も行くことにしました。そこで友人共々内定をいただき、この IT 業界に手を染めることになったのです。
※今でもここでお世話になった上司の皆様には感謝しております。育ててくださってありがとうございます。
何が一体きっかけになるかわからないもんだなと今でも思います。なお、哲学科で学んだことは社会人になって今のところは 1bit も使ったことありません。残念です。
それにしてもこの時消費者金融の道に進んでいたら今頃なにやってたんだろう。
最初の会社で Y2K (2000 年対応) をやる。LOGON TSS で COBOL から。
最初の会社では、富士通の FACOM MSP と XSP 上で動作する COBOL プログラムと JCL (JOB CONTROL LANGUAGE) に指定されている 6 ケタの年月日（例 : 98/10/11）を 8 ケタにする 2000 年対応から始めました。
この時、ものすごく昔のプログラムの年月日だけを変えていくだけでなく、実際に一から作ってみたいなと思い始めました。そのあと、偶々 Java 1.0 にかかわるプロジェクトがあり、そこに入れてほしいとお願いしたところ入れてもらえて、Java 系エンジニアの道を進むことになりました。
ちなみに九九ができない、数学がわからない問題は、ツールによって何とかなりました。
テクノロジーは人の可能性を広げてくれるといいますが、一昔前なら私のような人間は満足な職業に就くことはできなかったでしょう。しかし今は、Excel がある。IDE (統合開発環境）がある。なんなら AI だってつかえる。IT と、ツールがあることで私の人生は救われました。
このあたりから、流されるようにエンジニアという職業についた自分が、技術は何のためにあるべきか、技術を通して何ができるかを考え始めました。
二社めはベンチャー
そのうち、もっと何か大きなものをイチから作りたいなぁと思い、Java ベースのアプリケーション サーバーを提供しているベンチャー企業に入ることを決めました。この企業は 1 年足らずで経営的に厳しい状況になったこともありましたが（その後買収）、この会社にいたエンジニアさんはみなすごい技術力の持ち主で、自分がいかにできていなかったかを思い知らされ、かなり胃が痛い日々を過ごしましたが、その一方で皆さんの技術力を見様見真似しながら、少しずつ自分もできることが増えていく実感があった、とても大事な時代でした。20 年以上も前ですが、ベンチャー企業のスピード感はすごくて、その後のマイクロソフトへの転職に役立ったと思います。
ちなみにこの時代は Mac（七色時代）を家に 7 台置いていて、Windows は Mac のパクリみたいでいやだし、DOS ってなんだよ！と毛嫌いしていました。周りもみんな Linux か Mac で、当時秋葉原のぷらっとホームに行って、Intel 版 Solaris とか買って動かないわ！！と悩んだり叫んだりしていました。
これまでのキャリアについて (2) : マイクロソフトでサポートエンジニアになる
マイクロソフトにそっと入り込む
ベンチャーで毎日楽しい日々を過ごしていたものの、給料は前職から大幅ダウンの 300 万 / Year と安くなっていたのですが、それでもいいと思うくらいに技術的に課題を解決して何かを作る日々は楽しかったのです。楽しかったんだけど、残念ながら会社の財政がよくなくなってしまいました。
そこで、人事の人が辞めたときに あっこれはまずいかも…、と思ってざわざわしていたところ、転職エージェント経由でたまたま Microsoft から Java のエンジニアを探しているという話を受けました。その時はマイクロソフトが大嫌いで、Windows もいいけど、Linux と Mac が主だからな～という状態だったのと、既にそのころは Windows 2000 も出ていて、マイクロソフトは大手だったので、自分のようなキャリアではどうせ受かるまいと思っていたこともあり、正直冷やかしで受けに行くことにしました。
どうせ受かるわけないし、とはっきり言って相当なめてかかってたのですが、皆さん相当に頭の回転が速く、かなりキャリアでできていると思ったことも細かく突っ込まれてびっくりした覚えがあります。しかしなぜか OK をいただきました。ちなみに OS は何を使ってるかみたいなのは聞かれなさ過ぎて、あの～ Windows ほとんど今は使ってないんですけど～と言ったら、「Windows はしってる人はたくさんいるけど、Mac や Linux や汎用機を知ってる人はいないので面白い」と返されたことが強烈に頭に残っています。意外かもしれませんが、うちの会社はそういう懐の深さは割とあって面白い人がそろっていました。
そこから Visual J++ のサポートエンジニアとしてのキャリアがスタートしました。
サポート エンジニア時代
なぜサポート エンジニアになることにしたのか。
偶々そういうオファーが来たから、というのはありますが、一番の魅力は「ソースコードが読めること」でした。日本に居ながら、製品のソースコードが読める。サポートは R&D のエンジニアのキャリアパスの一つです。当時 Windows は使いづらいなぁと思っていて、さぞかし変なソースコードなんじゃないかと失礼なことを思っていたのですが、いずれソースを読むことができるなら面白いなと入社を決めました。これは本当に良い選択だったと今でも思っています。
Windows およびマイクロソフトのプロダクトのソースコードは、何だこりゃ？！というものもありましたが、中にはこんな短いコードでこんな技術革新を実現したのか！！と感動するような美しい、素晴らしいコードもたくさんありました。サポートでは、バグかどうかを調査して、バグであれば「こういう変更はどうか」という Suggestion を R&D に送ることができます（当時は GitHub や Azure DevOps などは使っていませんでしたので）。そうしたやり取りを通じて、リクルートされるエンジニアもいるのです。事実、私の Windows Media サポート時代の初期チームは私とあと 2 名だったのですが、この 2 名はどちらも Corp R&D に転籍され、いまでも本社でご活躍されています。こうしたキャリア的な面白さもありましたが、何より毎日様々な問題が寄せられ、どうにか解決を考える。これがとてもやりがいがありました。ただ、クレームを寄せられたり、お客様からセクハラまがいのことを延々言われることもありましたが…。そういえば、男性エンジニアに変えろと言われることは、2010 年代に入ってピタッと無くなった気がします。ただ、あくまでも個人の主観ですが、もめていても、男性エンジニアに代わると同じ内容を言ってもなぜか収束することもあり、悔しい思いをすることはその後もたまにありました…。
同じ部署でのキャリアをどうするか？ ～一つを掘り下げるか、横を広げるか～
Visual J++ からはじめたサポート エンジニアは、結局足掛け 16 年続けました。これは製品の中が面白かったことと、こどもを産んだので時間の制約が出てきたからです。サポートウインドウが決まっているサポートはうってつけだったと思っていました。…今思うと自分の裁量で決められるロールのほうが自由度高いかもと思いますが。ただ、サポート部門は基本チームプレイなので、任せられる安心感は大きかったです。
そんなわけでなんだかんだと 16 年もの間にわたり在籍していましたが、自分の中で一つのルールを持っていました。それは「3 - 5 年で担当技術を変えること」でした。同じことをやっていると自分の場合楽になり、慢心してしまう。これがわかっていたので、あえて厳しい状態に置かないと私は絶対成長しない。だから無理やり担当技術を変えることにしていたのでした。
製品が変わると、客層が変わります。
知らないことを聞かれます。
そうした中でも、対応をし、お客様にとって必要なことを提示する。日々の忙しい中で新たな技術をキャッチアップするにはどうしたらいいかを必死に考えなくてはいけない。そういうことを繰り返していきました。ちなみに実際の流れはこんな感じです。
Visual Studio Team
2001 - 2005
Visual J++
MSJVM Support
Visual SourceSafe
.NET Framework
Windows Multimedia / DirectX Support Team
2005 - 2007
Windows Media Server
Windows Media Encoder
Windows Media Player
DirectX
Windows Media Foundation
MTP Device / WIA
Microsoft Identity Product / ADSI / WMI / Scripting Support Team
2007 - 2011
Microsoft Identity Integration Manager
Microsoft Identity Lifecycle Manager 2007
Forefront Identity Manager 2010
Active Directory
WMI
SQL Server Support Team
2011 - 2016
Developer - SQL Server Data Access (ADO / ADO.NET / MSXML / JDBC)
Windows Azure SQL Database
この「横移動」を選択した理由はもう一つあります。
私はエンジニアには向いていなかった（と思っていた）からです。正しく言えば、「特定技術を掘り下げることが苦手だった」。
かねてから私はエンジニアとしては三流だと思ってずっとコンプレックスを抱いていました。
周りにすごい人たちがいて、自分は本当に一つをしっかり理解することができない。何をやっても中途半端というのがなかなか克服できない。こうした中自分が何とかバリューを出すにはどうしたらいいか？ということを考えたときに思いついたのが、複数を知るということでした。
当時の部署では、一つの製品あるいはその周辺サービスを極めていく人が多く、上記のように複数の技術を横に渡り歩く人はあまりいませんでした。そこに目を付けて、ジェネラリスト的なことができれば、漠然とですが将来の幅が広がるのではないかと想像しました。
しかし、この横移動は想像以上に厳しかったです。特に、この流れを見ていただけるとお分かりになると思いますが、「次の技術」は全く違う分野で、とっかかりがないところばかりでした。そのためゼロベースで一から学びながら日々の業務をこなさなくてはならない。キャッチアップしながらなんとか自転車操業で進める日々でもがいてばかりでした。
しかもこのころは子育てをしていて、子供もやらかす系の子で毎週学校から呼び出される日々だったので時間も厳しい。どうしたものか…。
その転機になったのが、2007 年からの「ILM 一家」プロジェクトでした。
このブログ タイトル考えたのは当時の上司です。私ではありません…。市原悦子の「家政婦は見た！」をもじったそうです（彼が何でそこに考えが行ったのか、その理由は謎）。
ILM 一家プロジェクトを立ち上げる
2007 年、Identity Lifecycle Manager (ILM) および、Active Directory サービス インターフェイス (ADSI) と WMI（Windows Management Instrumentation）のサポートが小ユニット化されました。私と前任 1 名 + 新任 1 名のたった 3 人です。しかも当時、ILM は癖がある製品ということもあり、サポートでの KPI となるお問い合わせの満足度が見たことがないくらいひどい状態でした。この時点の私が考えていた課題は、以下のとおりでした。
- これだけひどい問い合わせ顧客満足度が短期間にどれだけ上がりうるのか（単年でどうすれば大幅に満足度を上げるのか？） ★これが至上命題
- そもそも癖があるプロダクトをどうやって学んでいくのか？
- 一つ一つのお問い合わせの調査時間が長すぎる（コストが高い）
これらの課題すべてを同時に解決する必要がありました。そこでこう考えました。
- コストが高い、つまり問い合わせの調査時間が長いということは、お客様の時間もいただいており、お客様の社内でのこの問題にかかわる時間も長いということ（調査期間の長さと満足度は反比例する。これは人的コスト、つまり担当者の負担が MS だけでなく、顧客にもかかっているためと仮説）。したがって、初期ヒアリング対応、調査担当、回答文書作成とそれぞれの得意分野でその時の負荷も加味して分業することで作業量を分散し、出来る限り調査時間を短くできるようにする。
- バグなど、既存の問題で Corp の技術情報として公開されていないものについて知らずに問い合わせてきて満足度を下げている件を抑止すると、お問い合わせ数を減らして一件当たりのお客様に向き合う時間がねん出できるようになるだろう。
- 何となく知ってる人に対しては悪いことは書きづらくなる心理があるのを応用して、親密度を最初からあげておくとよさそうだ。
- 問い合わせを見ていると、製品の情報も英語が多いし、基本的な考えや使い方がわかっていないお客様も多い。それであれば自分が学んだ過程を提示していくことで顧客層の技術理解の促進もはかれるのではないか。
しかし、私たちにはこうした試みをしたくても、外部に委託できるような予算がありません。コストセンターだからです。
注 : 当時、Microsoft では、サポート部門はコストセンターとして分類されていました。他社でのサポート部門の位置づけとは違うかもしれませんし、今後 Microsoft でどういうカテゴライズがされるかはわかりません。2007 年時点の情報として記載しています。
であれば今の自分たちの手札をみて、出来ることを考えてみればよいわけです。そこからひとつ出てきた手段。それが「ブログ」でした。今はなくなってしまいましたが、当時は公式ブログを作ることができた（msdn と technet）ので、これを使うことにしました。当時の上司に相談したところ、責任はだれが取るのか、と言われたので何か問題があれば自分が辞めますとお伝えして始めることにしました。当時、牧さんというすごいエスカレーション エンジニア以外でサポート部門でブログをやっているチームはありませんでした。
ここで始めたときに立てた目標は以下の通りです。
- 月間ページビュー 10,000 を一年で超える。（マイナープロダクトだからそのくらいのペースを想定）
- 最初の半年は、記事を毎週必ず 1 本はあげる。
- 技術的にしっかりした内容を砕けた内容で書く。
- キャッチアップした初心者向けの内容を出していく。ライブラリの英訳も上げていく（当時の MSDN ライブラリ、今の docs のようなものは英語しかなく、機械翻訳もなかった）
- バグ情報も積極的に出す
- トラブルシュートのための情報取得の手順などを優先して公開し、回答メール内で引用していく
- 閑話休題でどうでもいいパーソナルな話題も出す。身近に感じてもらうため。
- マーケと連携し、記事を拡散してもらったり、逆にイベント告知などを行っていくことで双方の情報拡散効果を狙っていく
まあ、そんな感じでやったおかげで「チーズケーキの作り方」やら「息子に Windows Home Server を読み聞かせ」などの記事が生まれ、結果的に狂気のブログといわれる羽目になったのですが。
※この Mayuki さんのブックマークコメント「ういこさんおもしろすぎてファンになったのでいつか ILM つかってみたい」を見たとき、方向性は間違ってなかった！と確信できました。Mayuki さんありがとうございます。
ちなみに、このブログのトピックは、闇雲に書いていたと思われることも多かったのですが、実のところはかなり綿密に書く記事のテーマと内容を決めていました。ブログ開設後一か月くらいでアナリティクスの存在を知り、さっそくセットして毎日検索ワードや、流入元の内容などのデータを参考に方針をセットしていました。ただ、あまりにそれがあざとく見えないよう、出来る限り自然な流れになるように気を遣っていました。
一方で、当時あまり情報がなかった WinDBG シリーズなど、既存データからの判断ではなく、予想と日々その PV の内容によって書くことを決めた記事もまぜていました。WinDBG シリーズは当初全く PV は稼げなかったものの、いずれ必要になると思ってシリーズ化して書いていましたが、予想通りじわじわ PV があがっていき、手応えを感じました。
そしてここが一番大事なのですが、狂気といわれるくらい砕けた文章を書くならば、技術的に正しいことを書かないと駄目だと思ったので、かなりしっかり綿密に調べて書いていました。その過程で得た学びは、日々の業務で生かし、業務で生かした結果得たことは、ブログに書き直すことでまた理解が深まる。そうしたアウトプットを作り出すうまいループを作ることができました。やっぱり触って、アウトプットするのは大事ですね。
おまけ : ダンプ解析関連で何で勉強した？という質問を頂いたので。もう 32bit 時代なんで所々アップデートしながら読まないとだめですが、Dmitry Vostokov 氏の "Memory Dump Analysis Anthology, Volume 1" を Vol3 くらいまで買って読んでました。特にスタックが壊れて、~k コマンドで追跡できなくなったときの ebp のアドレスの探し方などが参考になった覚えがあります。もう 10 年以上前なんで、あやふやですし、64bit になってダンプに（32bit 環境と比べて）情報がほとんど残らなくなったので、参考にならないかもですけど。
彼の HP にだいたい乗っているんですが、当時は本で読みたくて買いました。彼の Software Diagnostics Institute ページは今見ても滅茶苦茶面白いのでお勧めです。
結果からいうと、一年でお問い合わせ満足度 100% をたたき出し、当時 technet トップだった安納さんの次くらいの PV を稼ぐところまで達成しました。多分、年間でお問い合わせ満足度 100% を全件で達成したのはなかなかないと思います。ちなみにお問い合わせの取り下げが当時できましたが、それもしないで、対象外の問い合わせをもらっても必ず何かを持ちかえってもらうことにして達成したので、今でもこれはチームみんなで作りあげていった、胸を張れる評価だと思っています。
ただここで思いもよらぬことが起きました。
そう、問い合わせが来なくなってしまったのです。なんてこった。
今となれば、お問い合わせが来なくなったこととブログの PV の相関を出してアピールもできますが、当時は近くのチームのマネージャーに問い合わせが来なくなったので、人を割く必要がないよね、じゃあチーム解散で異動。という横やりをかわすことができませんでした。そこで私は、初めて自分の意志でなく、人の意思で思ってもない製品の担当チームに異動することになります。コストセンターだからねぇ…今思うとねぇ…。まあ仕方ないなと思うんですが、当時は正直ものすごく納得できませんでした。今は難しい問題だなぁと理解できてますが。
でもこのおかげでマーケのキャリアにつながっていくのですから、人生塞翁が馬とはよくいったものだとつくづく思います。
SQL サポート チームに転籍になる。社内アピールをしたりしてみる。
そんなわけで、唐突に SQL Server チームの一員になりました。
SQL Server は ILM のバックエンドで動いているので、ちょいちょい相談に乗ってもらっていましたが全く知らない世界でした。SQL の話になったら、あちらのチームにお願いすればいいやと思っていたので…。
ですので、一から学びつつ、短期間で自分のバリューをいかに出すかというところに直面しました。ここで使ったのもブログでした。当時 SQL Server サポートチームもブログを持っていましたが、PV が月間 3,000 以下で 1,000 以下ということもありました。でも、SQL Server は ILM と比較したらユーザー数は比べ物にならないくらいの超メジャープロダクトです。もっと PV を取れるポテンシャルはあるはず。だから、ここを半年で PV を 30,000 にすると決めました。(データ分析を駆使しつつ、チームみんなで頑張って記事を定期的に量産した結果半年で達成しました。10,000 PV/month までは、3 か月くらいで達成できました)
ブログは好調だったのですが、当時 SQL Database のタイムアウトに関連して設計が合わないアプリ実装から起因した問題が多発しており、これをプリセールスの方に伝えることでもっと問題を抑止し、Azure を使ってもらうことに貢献できるのではないかということを考え、全社にお問い合わせの傾向をまとめた社内ニュースレターをだすようにしてみることにしました。今思うとブログのノリでニュースレターを送るのはどうかしてたなとおもうのですが、割と反響もあり、営業の方から相談をいただくことも増えてきました。
なぜニュースレターを送ることを思いついたのか、もう一つ理由があります。それは私たちのプレゼンスをどう社内で出していくか考えたときに、コストセンターの私たちが唯一持っているリソースが「お客様から直接の生々しいインサイト」だったからです。
ただし、単純にこういう問い合わせがありました、だけではなんの意味もありません。相手がどんな情報を、なんのために欲しいのかを理解して、それにあわせて情報を加工しなければ、相手に受け取ってもらい、さらにこちらを「使える人間（あるいは組織）だ」と思ってもらうことはできません。
この頃はライセンス売り切り型から、営業スタイルはコンサンプションビジネスへの転換期でしたから、きっと営業のみなさんは、アップセルのためにつぎの purpose や、ニーズを知りたいだろうと想像して、どんな業界のどんな職制の人からどんな問い合わせがきて、そこに提示した私たちのソリューションの結果次にどんな課題あるいは要望が上がったかなどや、今後問題になりそうなアーキテクチャ上のハマりポイントなどをまとめて提示していきました。
今思えば、無意識に試行錯誤の中で結果的にマーケティングのまねごとみたいなことをしていたのかもしれません。
マーケティングのポジション、どう？と聞かれる
そんなある日、当時の上司経由で SQL Server のマーケティング（プロダクトマーケティングマネージャー）のポジションが空いたけど、受けてみる？と言われました。マイクロソフトの異動は、事実上「転職」です。外部の方と履歴書以外は全く同じ条件で面接を受け、落ちることも多々あります。それまでに私も何度も他部署を受けて、そのたびに玉砕したりしていました。
今思うと本当に生意気で、間違っていたなと思うのですが、プロダクトマーケティングマネージャーは各営業部門の本部長クラスとともに、GTM（Go-to-Market）の戦略立案をして遂行していくと聞いて、これまでのエンジニアのキャリアしかない私が受かるわけがないと思っていたけれど、SQL Database にまつわる課題と対処をそのクラスの人たちに伝える機会はないと思ってチャレンジします、と伝えました。ところが受かってしまった。びっくりしました。
当時の上司に聞いたら「技術はあるけどマーケの知識がない人にマーケを教えたらできるんじゃないかと思って」とのことでした。一方で、サポート時代はマイナス評価だった「ブログをやって、問い合わせがなくなったこと」「ニュースレターで他部門の人が知りたいことを調べて、その形にして出していくこと」について評価していただいたというお言葉をいただきました。
どれもこれも、それまでの世界と真逆の価値観です。びっくりしました。コストをかけずに（手間暇かかってるので厳密にはコストがないとは言えませんが）大きな成果を収めるために何ができるかを考えて取り組む姿勢がマーケティングに生かせるという言葉をいただき、そういうものなのか、と思いましたが、経験がない私にできるんだろうか。不安になりました。さらにこの時点で 40 歳になっていて、40 を超えて今更すべてのキャリアを捨てていちから違う業種で働くようなもの。できるんだろうか…。
正直に言えば、当時周りからは、どうせビジネスグループ（プロダクトマーケティングマネージャーの組織）にいってもついていけるはずないから、ダメなら戻っておいで、とも言われることもありました。だけど、悩んだ末やってみることにしました。ここでもし、一からキャリアを作り直すことを回避したら、二度とチャレンジできない気がしましたし、ここまでの人生、どうせだめと言われることをひっくり返し続けてここまで来たのだから、今回もだめでもともと、やってみようと決めました。
これが、マーケに異動することになったきっかけです。
これまでのキャリアについて (3) : マーケの世界に戸惑う
マーケに異動したものの、違う世界過ぎていきなり取り残されました。まず視点が違う。違いすぎる。何をやってるか全くわからない。
セールスチームとともに、如何にして予算を生かして売り上げを達成することができるかを考える。毎日違った数字との勝負です。何がわからないかもわからなくて、考えられないようなミスを繰り返す。最初は親切に教えてくださった方もあきれていらしたでしょう。迷惑もたくさんたくさんかけました。あの時ご指導してくださった当時の同僚や、上司の皆様にはいくらお詫びしてもしきれません。
やがて、身体をおかしくして病院に通うところまで行きました。たった一枚、されど一枚の PPT を埋めることすらできないまま深夜になるような日々(その資料が誰のために、どんなときにどういう目的でどういう視点でまとめればよいかが全くわからなかった)。本当に精神的にも限界で、毎日毎日物理的に大泣きしていました。
明日首になるかもしれない。
ミーティングで話を振られても何も答えられない。
パワポ一つも満足に書けない。
Excel の Pivot も満足にできない。
ロッカーのものをすべて持ち帰り、PC の周辺機器だけ残して、明日にでもすぐ辞められるようにしました。
そして、ビジネススクールに行くことにしました。
この時点の状況はまるで「ルールのわからないスポーツにいきなり投げ込まれた状態」。何も手を打たなければ、サバイブできるわけがないと切実に思ったからです。
行先はオンラインで通える外国の大学院もありましたが、英語もできませんし、日本語でしっかり理解したいし、近くに知り合いができるといいなと考えて、MBA を取るつもりはなく、マーケの基本的なところを知りたかったのでグロービス経営大学院の単科生になり、クリティカル・シンキングと、マーケティング・経営戦略基礎を受けました。
結果、単科だと取れない授業があったので、MBA コースを受験して結局卒業しました。グロービスの回し者ではないですが、少なくともクリティカル・シンキングだけは、どんな人にも、特にエンジニアの皆さんにお勧めしたいです。
当たり前のことと思われるかもしれないのですが、日々私たちはだれもがロジカルな思考だけでなく、伝えるところにも実は相手に対する配慮や、その伝えた結果からこちらが得られるインパクトなども考える必要があります。しかし、この「相手が何が欲しいのか」「自分がこれを伝える / アクションすることによって 相手が何を得て、その結果私は何が得られ、総合してどんな効果が生まれるのか」というところまでは、実はあまり考えていないことに気づかされます。
その相手が経営層であれば、経営者の目線で課題をとらえなおし、アウトプットを調整する必要があります。この「目線合わせ」のポイントはなかなか得難いものがあります。実際の実例（ケース）などを通じてロールプレイ的に分析し、自分ならどう考えるか、人はどう考えているかをディスカッションで理解して整理しなおすことで、実体験できなくとも想定ができるようになったなと実感しています。
※どや顔のように見えますが書いてあることが悲惨すぎて…。我ながらほんとだめだったなぁと（涙）
「キャリアに迷う人の共通の特徴」※意見には個人差がありますが
そんな感じでマーケに転身して 6 年が経ちました。
当時何一つできなかった、レスポンスすることもできなかった私も、中堅クラスみたいに言われることも出てきました。
その過程で、だんだんとエンジニア系の人からどうやったらマーケに行けるのか？マーケティングはどんなことをするのか、移行のためにはどんな準備をすると良いのかといった質問をいただくことが増えてきて、会話を重ねることで気づいたことがあります。あくまでも主観ですが。
- 「でも」「そのうち」という人は動かないし、変わらない（可能性がある）
- 自分の視点で物を考えがち（視点が低い）
特に前者は顕著です。変わりたい、変わってみたいというけれど、「でも経験がないから」「時間がないからそのうち」という人で、その後ポジションが変わった人は今のところいません。上にいくことや、横移動されていることはありますが。
学校(ビジネススクール)についてもよく話を聞かれますが同様で、子育てに忙しいから、今仕事が大変だからという人でやってみている人は今のところ誰もいません。
子育ても、いま息子は 20 歳になりましたが 19 歳くらいまで大変でした。忙しいのはいつだって忙しいもんですから、そうそう変わらないです。要はやるかやらないかではないかなと。
そして、後者は結構根深いです。
たとえば、「なぜ、このプログラムが変わったのか」という質問をしたとき、単一視点からの回答、例えば「お客様が～だから」で終わってしまっているようなことはないでしょうか。
色々ステップアップしている人を見ていると、「お客様の利点」だけでなく「会社から見てのベネフィット」と双方を出してくれます。ちなみに私はスクールに行くまでやれてると思ってるくらいでしたが、この双方の視点で考えるということが全くできていないことに、ケースにとりくむ過程で気付かされました。
ただ、スクールに行かなくてもそうした視点をもち、解像度を変えることが当たり前のようにできている人は大勢いらっしゃいます。でも、誰もがそういう視点を経験せずに得られるわけではありません。私の場合は変わりたかったけど我流では限界があったので、遅かれ早かれいずれは学校で学ぶしかなかったなと思います。
そしてもう一つ、会社がどう回っているかを知らない（想像できない）ということが要因となって、視点が広がりにくくなっている方も多くいらっしゃるように見受けられます（少なくとも私は確実にそうでした）。
私はサポート時代は、サポートという業務を通じてしかお客様も、会社も見えていませんでした。会社がどうやって利益を出していくのか、その流れをどんな部門の人がどのようなアクティビティを通じて作っていくのかを理解していませんでした。だからサポートで見えることだけで「ああやればいいのに」「こうやればいいのに」と不満ばかり考えていた気がします。でも、限りある予算のなかでリターンを最大限得るために、企業が利益を得るためにはすべてを実現することはできません。やらないことを決めることこそが重要だからです。すべてが大事なことだと分かっている中で、どれをやらないことにするか。この判断をどうつけるべきか、そして実行して責任を取っていくべきか。そうしたことは考えたこともありませんでした。部署を大胆に移動するということがなければ、きっとずっとこうしたことを理解することはできなかったですし、また学校にいってケースメソッドで自分が経営者だったらどんな打ち手に決めるか、どれをやらないことにするかといった視点を学ばなければ、やみくもに場当たり的な模索を続けて、疲弊して現状を変えることもせず、今見えている狭い範囲だけで境遇について不満ばかりを言っていたことだろうと思います。
ただしだれもがこうした大きな異動をすべきということではありません。しかし、他部署の人が何を欲しがっているか、それはなぜなのか。それを知るところから、違った見方をすることで自分のプレゼンスの出し方も変えることができるのではないかな、と考えています。
さて、そんなわけで長々と続けてきたこのお話もそろそろおしまいにしようと思います。
最初は適当な気持ちで成り行きで入った IT 業界。自分のダメなところを助けてくれたツールのおかげでここまで来れました。
そして、これまた成り行きではいった Microsoft も、今では本当に大好きな会社になりました。
マイクロソフトのカンパニーミッションは "Our mission is to empower every person and every organization on the planet to achieve more." です。社員証の裏にも印刷されています。何度もこれを見るたびに、最初病気でビハインドから始まった自分の人生が変わったことを実感し、ツールの力を確信できます。
かつて悪の帝国といわれていたマイクロソフトも、最近は劇的に変わってきています。
それでも嫌いな方もいらっしゃるかもしれません。だけど、社員はみんなこのカンパニーミッションのもと頑張ろうとしています。
私はそんなマイクロソフトが大好きです。
これからは一ファンとして、マイクロソフトの外から応援していければと考えています。
これまでイベントに参加してくださった皆さん。マイクロソフトの製品をご利用くださった皆さん。
本当にこれまでありがとうございました。
それではみなさん、ごきげんよう！