CA MOBILE TECH BLOG

株式会社シーエー・モバイルのエンジニア・デザイナーの活動を綴るブログです

株式会社シーエー・モバイルの技術広報による、
技術に特化したブログです。
エンジニアとデザイナーの活動や思想を綴ってゆきます。

【ジョブチェン!】②メール配信担当からエンジニアに ーYさんのケースー

f:id:cam-engineer:20180724083049p:plain


シーエー・モバイルは、入社後に新たな職種にチャレンジする人も少なくありません。今日は、メール配信担当からサーバサイドエンジニア、後にプロジェクトマネジャに転向したYさんの実体験を、語っていただきました。


スーパー属人化作業時代

実は2回入社しているんです、僕。最初の入社は2003年で、メール広告の配信チームに所属していました。メール広告というと、今ではもはや聞きなれない言葉かもしれませんが、当時はガラケー文化の真っ只中でしたから、ユーザーへのリーチ手段としてメールマガジンは王道だったんです。

主な作業は、そのメールマガジンの配信設定と実行でした。これだけ聞くと「それだけ?」と思う方もいるかもしれませんが、自動化がほとんどされていない自社のシステムを使っていたので、作業的には非常に複雑でミスのリスクが大きくて、いつもプレッシャーに晒されていました。今振り返っても、よくやったなと思うくらい大変でした。

具体的には、広告のターゲットにあわせて、メールの受信者を「男性」「30代」「東京在住」などといったセグメントで切り分けて配信リストを作成して、広告担当から受け取った広告原稿を一件一件コピペして、送るべきリストと紐付け、配信設定をするのですが、それが毎日50パターンくらいありまして、これらを全て手動でやるという、まさに「スーパー属人化作業」です。


f:id:cam-engineer:20180724083033p:plain

手動で1ヶ月あたり1億通ほど配信していましたので、ミスをゼロにするのは至難の業です。配信リストの抽出をミスしてしまったり、原稿を差し替え違ってしまったり。

それでいて失敗すると、上司や周囲から激詰めされるという(笑)。もちろんミスはあってはならないことですが、誰がやったとしても、いつでも起こりうる状況下ではありました。

2〜3年ほどやってると、さすがに疲弊しまして。仕組でミスを減らすことを考えなければ、この先の広がりがない。自社システムだと、改修の工数がいつどのくらい取れるのか読めないため、社外ツールの導入を検討しました。

競合調査の結果、ユミルリンク社が提供する「フォーキャスト(現・Cuenote FC)」というメール配信 ASP サービスを導入することにしました。

結果、作業効率はぐんとあがり、ミスのリスクをかなり低減することができました。配信そのものの安全性が上げられたことで、キャリアの制限をクリアしながら配信通数を増やす施策にチャレンジすることも可能になり、売上貢献することができました。

当時のビジネスモデルでは、メール配信数と売上は正比例していましたから、この結果は高く評価されました。

一方でこのことが、自分の中にもっと新しいことをしたい、もっと色々できるようになりたいという思いを強めてしまうことになり、この後転職するのですが、新しい会社に入ってすぐにイメージ違いに気づいてモヤモヤしてたところに、CAM の元上司から「戻ってきなよ」コールが入り、わずか2週間で CAM に復帰することになりました(笑)。

CAM にはカムバック組、結構いますけど、今でも僕が最速の1人じゃないですかね。



エンジニアとしての第二のキャリア

カムバックして最初の仕事は、広告事業のディレクターで、広告メニューの条件などを設計しつつ進行管理をする、というものでした。

ここでも、入稿が Excel 管理という属人的フローが当たり前になっていたので、仕組化に取りかかりました。

エンジニアと一緒に、入稿から配信までの流れを一括管理できる進行管理ツールを作ったのですが、ディレクターとしては最優先すべき作業でも、エンジニアにはあっさり断られるという経験をし、”本当はできるのに断っているんじゃないか?” と疑ったり、”自分ができたら早いのに!” と思ったり。

先ほどのメール配信ツールの時もそうでしたが、何か仕組を考えたり導入を決めたりしても、実運用できる状態に持っていくためには、エンジニアの力を借りなければなりません。

何かをするたびに ”結局、自分の手で作れなければ、広がりがない” という気持ちが強まっていて、これがジョブチェンする動機の1つになったんだと思います。


f:id:cam-engineer:20180724083027p:plain

2007年くらいですかね、当時のエンジニアのトップに、システムの部署への異動を直談判して、許可されました。そして、自分が作った進行管理ツールを、今度はメンテナンスする側となりました。

それまでの僕には、エンジニアは魔法使いに見えていました。何でもできるすごい人たちだと思っていたので、彼らに何かを依頼をするということは、とてもハードルが高かったんです。

だから、今後は依頼することなく、自分で色々できるようになると思ったら、わくわくして仕方ありませんでした。

それから、1〜2ヶ月の間、新人研修に参加させてもらい、管理画面を作ったり改修するところから始めました。

その後、見よう見まねで公式サイトをいくつか作り、Java でサーブレット組んで、i-mode アプリの恋愛ゲームを作り、技術本を読んでは書いてを繰り返し、広告サイトの保守運用もやり…と、横に広くいろいろやりながら、エンジニアとしての知識や技術を身につけました。

2008年の途中ぐらいに、ゲーム媒体を扱う部署に異動しました。みんクエ(みんな de クエスト)や、ミラくえ(ミラクルくえすと)など、ゲーム会社との協業案件が盛んになりつつあった頃ですが、そのミラくえのシステム担当になりました。

シナリオを追加したり、Flash ゲームの ActionScript とサーバを連携させたり。その後、新規ゲームも、2〜3本作りました。

コナミ(現・コナミデジタルエンタテインメント)と協業して、グラディウスの将棋版のようなサービスサイトを1年がかりで開発し、リリース後3ヶ月で閉じるという憂き目も経験しました。

残念ながら、その後ゲーム事業は徐々にシュリンクしていきました。



試練の連続で経験値を上げる

f:id:cam-engineer:20180724083038p:plain

2010年末、スマホ化の波が押し寄せてきたのを期に、課金事業部に異動しました。

その部署は凄まじい数のガラケーサイトを運用していて、当時ですでに数10サイトはありました。それを、時代に遅れないよう、片っ端からスマホ対応化しまくるという、目の回るような仕事が待っていました。

同時に、自社開発の社内基盤システムの担当に任命されたのですが、運悪く、前任者からの引き継ぎを受けられないまま受け取ることになったため、中身(構成)がさっぱりわからず、手探り状態で、非常に苦労しました。

さらに、その頃に提供が開始された docomo の「 SP モード」に向けて、9つもの新規公式サイトの同時リリースがありまして、もう大わらわです。しかもその中には、相当大規模なサイト移管も含まれていて、これがリリース直後に予期せぬトラブルに見舞われるという。。。

これだけでも十分な地獄絵図ですが、ここで終わらないのが人生というものなのでしょうね。実はそのドタバタのピークに、妻が出産しまして(笑)。あの(色々な意味での)リリースラッシュを、よく切り抜けたなあと、今でも驚きです。



課題解決のために PM へ

その後、プロマネ(プロジェクトマネジメント)グループという小規模な部署に行き、PM(プロジェクトマネージャ)として複数の部署に横断的に入って開発の進行管理をしたり、全社的な仕組の整備や社内ツールの開発を行いました。

例の基盤システムを安定稼働させ、アイドルサイトのメールサービス・システムや、占いのユーザ回遊システムなども作りました。これらは今、それぞれの部署で運用されて、利益貢献に役立っています。

これ以降、今に至るまで、僕は PM という立場で働いています。

僕が PM に転向したきっかけは、すごすぎる「本物の」エンジニアを見たことでした。

2008年から2010年の超繁忙期に、業務委託のエンジニアが大勢入社したのですが、その中に本当に突き抜けた人がいて、その技術力の高さに圧倒されてしまったんです。同じエンジニアと言っても、随分差があるなと驚かされました。

自分は、そこまでエンジニアリングを極められるのだろうか、と自分の気持ちを振り返ったり、社員として求められること、業務委託として求められることの違いを考えたりするようになりました。

結果的に自分は、ある技術に徹底的に強いエンジニアでいるよりも、エンジニアリングを使って何かを作ることができる PM の方に面白みを感じていることがわかりました。

自分1人では実現できないアイディアも、PM としてリソースを確保したりスケジュールを調整したりすることで、形に落としこむことができるなら、その方がいいじゃないかと。

短期的なアサインが難しければ、自分でコードを書いて補助することもできますし、自由度も高い。エンジニア側のことも、ビジネス側のことも知っている自分には、合っているんじゃないかと思ったんです。

それと同時に、昔から感じていた課題感への1つの解になるかもと期待が持てました。

プロジェクトの規模が大きくなればなるほど、1人でできることは限られてきますし、全ての開発案件の規模が、昔に比べてどんどん大きくなっています。

ガラケーサイトなら1人月未満のアサインで済んだことも、多機能化しコンテンツがリッチになったスマホサイトではそうもいきません。

技術者側は分かっていても、ビジネス側がその違いにピンときていない場合もあって、適切でないリソース配分をしてトラブルになるケースをたくさん見てきました。

その都度、ビジネス側の責任者とシステムの現場をつなぐ人がいたら良かったのに、ちゃんとコミュニケーションが取れていれば、この悲劇は起こらなかったのに、と感じていました。

だから(良くない呼び方ですが、あえて社内の通称を使うと)「システムさん」と「運営さん」は、長い間、不毛な対立構造にあったと思います。

僕は双方の立場や気持ちを理解できるから、その間の通訳や橋渡しができると思いました。技術が枯れない程度にビジネスに寄るバランスをとりつつ、コミュニケーションを1番に動いて行けば、みんなが働きやすくなるはずだと。

結果的に、かつて求めていた ”間を繋ぐ” 人に自分がなったということですね。

f:id:cam-engineer:20180724083043p:plain

最後に、ジョブチェンを考える人に、僕の経験から得たことをメッセージとしてお伝えしたいと思います。

社員は組織に課題解決を求めがちですが、黙っていても何かをしてくれるなんてことはありません。自分で動かないと何も変わりません。

”こういう人がいたらいいのに” ”こういう仕組みがあればいいのに” と思ったら、誰かに期待するよりも、”自分がなればいい、自分が作ればいい” と奮い立つことができるマインドを持っていたら、何者にだってなれると思います。

今の仕事に課題を感じていたり、伸び悩んでいるなら、環境を変えるのでもいいし、変えられる立場を目指すのでもいいでしょう。自分の価値(ニーズ)を作るには、まず自分で動く。この考え方が大事だと思いました。


"こんな人がいたら・こんな役割があったらいいのに"と感じられたら、それがチャンスかもしれません 。

自分にとってのニーズは、他の人にとっても同じ。Yさんのように、自分がそれになればいい、と発想するところからジョブチェンが始まります!