ITエンジニアのための勉強会・イベントレポート情報メディア

エンジニアにとってマイナビで働く魅力とは!?『マイナビTech Night #3』開催!
event

エンジニアにとってマイナビで働く魅力とは!?『マイナビTech Night #3』開催!

2019.12.16

 
  • このエントリーをはてなブックマークに追加

マイナビのエンジニアが日々の業務で得た知見や経験を広く共有し、マイナビでエンジニアとして働く魅力を語るイベント「マイナビTech Night」。今回は第3弾として「ライフスタイルメディア」を支えるマイナビのプロダクト開発」をテーマに、11月20日、東京一ツ橋のマイナビ竹橋本社セミナールームで開催されました。

今回の登壇者は3名で、以下の3つのトークが行われました。

(1)「『マイナビニュース』がチーム開発をするためにやってきたこと」(岡部恭平氏)

(2)「『マイナビ学生の窓口』の半内製開発体制の振り返り」(柴垣元明氏)

(3)「ライフメディアにおけるプライベートDMPの取り組み」(小澤紀和氏)

いずれも、今までのイベントで話されてこなかった各チームの詳細な内容に踏み込んだものとなりました。普段利用している開発ツールやコミュニケーションツールでどのような点が課題となるのか。特に、開発体制に合わせた使い方が鍵になることが話されました。

マイナビのエンジニアたちが日常業務の中で、どのような課題感を抱き、どのように解決しているのか、その詳細が語られました。イベントを通してマイナビのエンジニアのリアルな日常に触れることができ、多くのヒントがもらえる内容となりました。

(1)「『マイナビニュース』がチーム開発をするためにやってきたこと」:岡部恭平氏



岡部氏は、2019年1月にマイナビに入社し、Webアプリケーションエンジニアとして『マイナビニュース』の開発をしています。

『マイナビニュース』は「その先を伝える総合情報サイト」をキャッチコピーに、テクノロジーやIT関連のニュースから、ワーク&ライフ、ホビーやエンタメといった幅広い分野の記事を配信しています。

1日平均140本の記事がアップされ、月間PV(ページビュー)は約7630万、月間UU(ユニークユーザー)は2720万人という国内でも有数のサイトです。

『マイナビニュース』を運営するニュースメディア事業部は約120人規模ですが、開発はIT戦略事業部の安齋・岡部氏を軸に、システム統括部のインフラ・マーケティングチームのエンジニア、外部開発ベンダーのエンジニアと協働しながら開発・運用をしています。



現在は、この3チーム体制の開発は、非常に上手く連携しているといいます。しかし、岡部氏が2019年1月に入社したときはそうではなかったそうです。今年1年、チーム体制の改善をしてきた経過について、岡部氏は話しました。



当時は、3つの大きな問題があったといいます。

1)プルリクエストの情報がGitHub上に無い
2)誰が今どの環境でデプロイしているのかがわからない
3)リニューアル時の流れのまま使い続けているGit-flow

現在ではチームで開発をする場合、Gitのホスティングサービスを利用した開発が主流になっています。利点はソースコードのバージョン管理ができるだけでなく、チームにレビューをする文化が根付くことです。変更したソースコードをプッシュし、プルリクエストを作成し、変更内容に問題ないかどうかチームメンバー内でコードレビューをすることができます。

ところが岡部氏は入社早々、開発ベンダー側のエンジニアが変更点をmasterに直接プッシュしているのを目撃したといいます。これではレビューをしないうちに、ソースコードが変更されてしまい、バグの発生につながりかねません。

なぜこのようなことになっているのかを調べてみると、マイナビのGitHub上にプルリクエスト情報が存在しないことがわかりました。さらに調べると開発ベンダー側はエンジニアは自社のGitLabで開発を進めていることがわかりました。

そこで岡部氏は、開発ベンダー側のエンジニアにも、マイナビのGitHubに参加してもらい、開発のすべてがマイナビの GitHubを通じて行われるようにすれば良いと考えました。

そのためにまずはGitのホスティングサービスをマイナビのGitHubに統合するところから始めました。今までは開発ベンダーへ開発依頼をする時は、Redmineで依頼をしていたため、Redmine から移行し、マイナビのGitHubで開発する上でのissueやプルリクエストの使い方についてなど開発フローを再整備しました。

次にCI環境の構築です。マイナビのGitHubを開発ベンダーのエンジニアも使うということはマイナビのCIを使うことになります。しかし他のチームと共用でCircleCIを利用しており、契約コンテナ数が少ない状態で、その状態からCIを利用するエンジニアが増えることになるため、CIの実行待ちが増えることが容易に想像できました。

CircleCIの場合、現在では「PERFORMANCE プラン」に変更すると従量課金制になり、 CIの実行待ちを気にする必要が無くなりますが、当時はすぐに何とかしないといけない課題であったため、マイナビニュースではAWS CodeBuildでCI環境を構築することにしました。



ただ、問題はこれだけではありませんでした。デプロイをした場合、これまでは担当者がSlackで報告をするルールになっていたのですが、手動であるために、当然忘れることもあり、リリースしたのかどうかがよくわからない状況になることがあったといいます。そこで、capistranoのプラグインを導入。これでデプロイしたと同時に自動的にSlackに通知が飛ぶようになりました。



また、リニューアル時から続いているブランチモデルも見直しました。リニューアル時は大規模開発になるので、Git-flowを基にしたmaster・develop・featureの3種類で構成するブランチモデルでしたが、リニューアルが終わると、コードレビューが終わったら随時リリースするようになりました。そのため、毎回複数のfeatureブランチをdevelopブランチにマージしなければなりませんでした。

そこで、よりシンプルなGitHub-flowに変更。ブランチはmaster・featureの2つの構成で、開発フローがシンプルになり、効率的になったといいます。



リニューアルのような大規模な開発体制と、それ以後の改善、機能追加の開発体制では、求められる環境が少しずつ変わっていきます。開発の段階が変わったのに、以前の環境を漫然と使っていたことが問題の核心でした。岡部氏は、これをひとつひとつ丁寧に解消していきました。

その結果、開発環境がシンプルになることでミスが減り、生産性が向上しましたが、最も大きかったのは開発ベンダー側のエンジニアとも同じチームの一員と感じられるようになったことだといいます。チームとしての一体感が増し、くだけたラフなメッセージもやり取りできるようになったそうです。

ただ、岡部氏はまだまだ改善すべきことは沢山あると話し、Developer Experience (開発体験)が向上する改善とマイナビニュースをグロースするプロダクト開発を行っていく決意を語りました。

(2)「『マイナビ学生の窓口』の半内製開発体制の振り返り」:柴垣元明氏



柴垣氏は、『マイナビ学生の窓口』の開発マネジメント、サーバーサイドエンジニアを務めています。

『マイナビ学生の窓口』は、大学生から就活中の大学生、就活が終わり社会人になる準備をしている大学生までを応援するメディアで、「ほっとけない学生芸人グランプリ」「学園祭マスコット総選挙」などユニークなオンラインイベントやオフラインイベントなども手がけています。月間PVは2100万PV、会員数は117万人で、大学生、短大生の3人に1人が利用しているメディアです。



ところが、この『マイナビ学生の窓口』のシステムは、以前は完全外注で、マイナビ社内にはエンジニアがいないという状況でした。このため、開発速度が上がらず、しかも社内にノウハウが残らないという大きな問題があったといいます。



そこで、内製への切り替えが模索されましたが、社内エンジニア不足もあり、協力会社と連携した半内製開発体制をとることになりました。

2018年4月から準備作業が始まり、同年9月にはデプロイ可能な環境整備が完了。その経緯については、『マイナビTech Night #1』において、「マイナビ学生の窓口。半内製化の取り組み」(福間雄基氏)としてプレゼンされています。



その最大の成果は、開発スピードがあがったことです。あまりにも開発が迅速に行われるため、ディレクターの対応が追いつかず、「3時間ごとにディレクターが悲鳴をあげる」という”素晴らしすぎる”状況が生まれたそうです。

現在、マイナビ社内のエンジニアは3人。柴垣氏は、その中でサーバーサイドエンジニ兼マネージャを務めています。あとの二人は、ディレクター兼UI/UXデザイナー、フロントエンドエンジニアという体制となっています。

柴垣氏は、半内製化によるメリット、デメリットを整理して、今後改善すべき課題を洗い出し、以下の4つのメリットがあると結論付けました。

1)アジリティ(即応性)の向上
2)設計、コードの良し悪しの判断の正確さの向上
3)エンジニア文化の醸成
4)知見の共有

改善すべき課題としては、ボトルネックが発生していることです。しかも、そのボトルネックとなっているのは、柴垣氏自身であると自ら話しました。

エンジニア兼マネージャの柴垣氏は、開発業務の他に、コードレビュー、動作確認、企画側との調整をしなければならず、さらにマネージャとして事業計画を作成したり、レポートを出したりしなければならない。つまりは、人的リソースが足りていないのです。

解決策として最も簡単なのは、外部開発会社のリソースを増やしてもらう方法がありますが、これはすぐに断念しました。外部エンジニアの人数が増えれば、社内の開発業務の負担は減少しますが、同時に、ディレクション業務、チケット作成などの業務が比例をして増えていくことになります。社内のリソース不足に対する改善効果は、実はさほど大きくないのです。



では、マイナビ内でリソースを増やせるかというとそれも簡単ではないといいます。マイナビでは新卒採用エンジニアは毎年15-20名ほどで、企業の規模からすれば採用人数は多くありません。そこで、どうしても中途採用市場に頼らざるを得ないのです。

ところが、中途採用市場は完全に売り手市場になっていて、有効求人倍率は7倍にも到達し、エンジニアの給与は高騰しています。さらに、柴垣氏が「キラキラ系ベンチャー」と呼ぶ、いわゆる「イケてるベンチャー企業」には、多くの人が行きたがります。

そこで、柴垣氏が行ったのは、マイナビならではの良さを、中途採用市場に向けて素直に地道に訴えていくことでした。

その最大のポイントが、マイナビの社員ならではの「人の良さ」だといいます。話しかけて嫌な顔をする上長はいない。同僚の間でも意見の言いやすい雰囲気ができている。柴垣氏は「マサカリは飛んできません」と断言しました。マサカリとは、エンジニアの間で使われるスラングで、「過剰に厳しい指摘」のこと。マサカリが飛ぶと、チーム内にはギスギスした空気が流れる。マイナビのエンジニアは、みな、伝え方に気を使える人たちだといいます。

さらに、裁量が大きいところもポイントで、自分で考えて、自分で動ける部分が多いそうです。

柴垣氏もチームとして楽しく仕事をすることで、チーム全体のパフォーマンスに向上につながっていると実感をしているといいます。

その結果、1人の人材を確保することができました。前職は商社で、エンジニアではなかったが、子どもの頃からなりたかったエンジニアにどうしてもなりたくて、転身をするためにマイナビに転職をしてきたという女性です。

プレゼンでは、その女性も紹介されました。マイナビに転職することを決断する決め手になったのは、マイナビ社員の人柄だといいます。「みなさん、とても穏やかなんです。指摘をする場合でも、声を荒げることがありません。マイナビのような穏やかな環境で仕事に集中したいというのが決め手になりました」。



1年かけて取り組んだ半内製化は、人材を得て、さらに完全内製化に向けて進み始めています。

(3)「ライフメディアにおけるプライベートDMPの取り組み」:小澤紀和氏



小澤氏は、マイナビに新卒入社後、BIツール、クラウド型RPAツールの導入実装などを担当し、現在はBPR推進課で、プライベートDMPの運用を担当しています。



BPR推進課は、IT戦略事業部の中に位置をし、SFA、BI、DMP、RPAなどの業務支援系ツールを社内に横断的に提供する役目を担っているといいます。

小澤氏は、まず、耳慣れないDMPとは何かということを説明することから、プレゼンを始めました。

DMPとは「Date Management Platform」の略で、辞書的な解説では「データを蓄積、管理する基盤」となっています。しかし、これではいったいどういうものなのかイメージがわきません。

小澤氏の定義によると、DMPとは「データを蓄積し、活用目的に特化した機能が付随するサービス・基盤のこと」。最も分かりやすい例としては、Google Analyticsがあります。Google Analyticsはサイトへの訪問者の数や、滞在時間などのデータを蓄積しているサービス。ユーザーは、利用目的に合わせて、PV、ユニークユーザー数、平均セッション時間、直帰率、コンバージョンなどが分析できます。分析をする目的は多様で、サイトコンテンツの改善やコンバージョン率などの改善など、目的に合わせて訪問データを分析することができるが特徴です。



2017年には、すでにパブリッシャー向けDMPを導入。マイナビのライフスタイル系メディアで、同じDMPを導入しました。主な利用目的は、タイアップ記事への広告配信のコンバージョンを向上させるためです。



そうする中、さまざまな課題が見えてきました。メディアを運営する各事業部によりデータ活用の目的はさまざまであるのに、導入したDMPは広告配信に特化したもので、MAツール(マーケティングオートメーション)と連携をさせたいという事業部も多いのにそれもできません。そもそも生データに簡単にアクセスできない構造になっているので、ETLツールを使って、データを可視化することも難しい。JavaScriptタグの仕様が公開されていないので、分析前に修正することができず、分析に時間がかかってしまいます。

つまり、実情に合っていないDMPだったのです。

解決策は2つ。ひとつは内製をして、マイナビの活用目的に合ったDMPを開発すること。もうひとつは、要件に合う別のプラットフォームに切り替えることです。社内リソースを考えると、別プラットフォームへの切り替えが適切だと判断。検討の結果、Arm Treasure Data eCDPを導入することになったといいます。

Arm Treasure Data eCDPのメリットは4つありました。

1)ローデータを自分で加工して使うので、自由度が高い
2)GUIでのデータ抽出もできるので、クエリがかけない人でも使える
3)さまざまなツールにコネクタを持っているので、さまざまな目的に対応できる
4)JSタグはSDKとして公開されているので、自由に取得データの設計ができる

特に重要なのが、さまざまなツールにコネクタを持っているという点で、マイナビ全体でArm Treasure Data eCDPを利用するものの、各事業部での活用目的に合わせて、「BI、BA」「MA」「分析」「広告」などの解析ツールを使って、各事業部での目的にあったデータ活用ができるようになりました。これで、マイナビのマーケティング基盤が確立できたと感じているということです。



3名のトーク後は、参加者の方々との懇親会が行われ、個別に多くの質問があり、大変有意義なイベントとなりました。

【関連記事】「マイナビが社外向けエンジニア勉強会『マイナビTech Night #1』を開催!」

※マイナビキャリア採用HPはこちら

エンジニアにとってマイナビで働く魅力とは!?『マイナビTech Night #3』開催!

この記事はどうでしたか?

おすすめの記事

キャリアを考える

BACK TO TOP ∧

FOLLOW