4月15日に行われたジーニーの2022年上半期キックオフ（キックオフについてはこちら参照ください。）にてMVM（Most Valuable Manager）を受賞された中釜由起子さんにマネジメントへの思いと今後の展望についてインタビューを行いました。

中釜由起子
新聞社で記者・編集者・多数の新規事業を経験した後、2019年12月にジーニーに入社。2020年1月よりマーケティングテクノロジー事業本部マーケティング・インサイドセールスグループマネージャー。2020年4月より経営企画室広報・ブランディンググループマネージャーを兼務。2020年12月よりBSTマーケティング部部長。2022年4月よりコーポレート本部ブランドデザイン部部長代理、BST事業開発本部長。中3、小6男児の母。

複数の部門、チーム、プロジェクトをマネジメントするのは大変ではないか

最近、この質問をされることが増えました。
ジーニー2部門、BST、職種もマーケティング、広報、デザイン、事業開発など多岐に渡るので携わる組織やプロジェクトが多いのは確かです。
「多くはありますけど、楽しいですよ」
と答えることが多いのですが、楽しく仕事をし、ある程度成果が出せるようになるには数々の失敗と試行錯誤がありました。

組織運営の方針と進むべき方向を示す

2020年にマーテクのマーケ部門のマネージャーに着任した当初は、うまく成果が出せませんでした。オフライン・オンラインマーケティングともにほぼゼロから仕組みを作り結果が出るようになるまで時間がかかったこと、事業部内の部門責任者にマーケティングの方針や見込みを説明し、合意を得られるようになるまで時間がかかったためです。
そもそもマネジメントで実現すべきは、メンバーが成果を上げられるような手法や仕組みを考え、組織を管理すること。私はビジョンを示し、メンバーの話を「聴く」ことを最も大切にしています。
組織運営の方針として「仕事は楽しく、強みを生かしてチームでやりましょう」と伝えています。「一人ひとりが成長に向けてチャレンジできる」「お客様に喜んでもらえた実感を得る」ことで仕事の楽しさは感じられると思っており、あるべき姿について全員が共通認識をもつことは最も重要だと考えています。細かい指示は極力控え、理想や進むべき方向を示すことを心がけています。
とはいえ、最初は細かい施策までコメントすることが多かったのですが、メンバーが徐々に増え、インサイドセールス部門の組織化や数値目標の上昇（前年比200%程度）など難易度が上がるにつれ、マネジメントの方法を見直し、昨年4月頃から「チームを信頼し、任せる」「仕組みを作る」ことに注力し始めました。

メンバー一人ひとりの強みを生かし、主体的に働く環境を整える

「チームを信頼し、任せる」ために意識的に行うようにしているのは、
・中計など、目標設定の背景と短期・長期のゴールを示す（優先順位と期限を伝える。細かい指示はしない）
・マネージャーやリーダーに改善の方針を具体的に伝え、メンバーとのコミュニケーションや連携をしてもらう
・メンバーとは1on1を通じて月次の成長や改善すべきことを個別にフィードバックし、信頼関係を築く
この3点です。
マーケティング業務は特に、期（ジーニーでは四半期に分かれています）、月次のKPI（リード）、KGI（商談数）の目標値の他に、セミナー集客数、WebサイトCVR、メール開封率、イベント名刺獲得数、リードto商談転換率など、様々な達成すべき中間成功指標（KSF=Key Success Factor）があり、タスクも膨大です。裁量を持って働けるように、部長、Mgr、リーダー、メンバーの役割を定義しました。「データ分析、仮説に基づいた施策であればどんどんチャレンジしてください。PDCAを回しましょう」「困ったら相談してください」というメッセージを伝えました。
「自律的に仕事をする」スタイルが定着するのには3カ月ほどかかったと思います。細かい質問に直接回答することをやめ、Mgrやリーダーから報告を受けるようにしました。これによって、それぞれの役割や裁量の範囲の理解が進んだと思います。

「仕組み化」をする

その代わり、私自身は「仕組み化」と「部門間の交通整理」に徹しました。
・タスク管理→プロジェクト管理ツール「backlog」の導入
・インサイドセールス業務の定義、プロセス可視化
・目標管理の粒度とKPI・KGIがGAPした時の打ち手（GAPfill）の進め方の標準化
・着任者用の研修マニュアル整備
・部内問題提起用チャンネルの開設（slackで長期的な事業・業務課題を提起するチャンネル作成）などです。仕組み化に必要な問題提起のみ行い、プロジェクトごとに推進責任者を決めて同時並行で進めていきました。そのメンバーと認識合わせや進捗確認を行い、運用プランまで考えてもらうようにしています。その過程で出てくる困りごとや調整に徹しています。

人材を育成し、新規プロジェクトに挑戦する

今後は、より今進みつつあるリーダーやマネジメント層の育成により力を入れ、ジーニーの未来を担える方を増やしていければと思っています。また、4月に新設されたブランドデザイン部で、全社のブランディングや事業拡大の礎や道筋をつくっていきたいと思います。

■ジーニーについて
ジーニーは、「誰もがマーケティングで成功できる世界を創る」「日本発の世界的なテクノロジー企業となり、日本とアジアに貢献する」というパーパス（企業の存在意義）のもと、企業の収益拡大・生産性向上など様々な課題解決につながるソリューションを開発・提供するマーケティングテクノロジーカンパニーです。

4月15日に行われたジーニーの2022年上半期キックオフ（キックオフについてはこちら参照ください。）にてMVM（Most Valuable Manager）を受賞された井古田光晴さんにマネジメントへの思いと今後の展望についてインタビューを行いました。

井古田光晴
GENIEE SFA/CRM事業本部 プロダクト開発部 部長
2021年4月に入社、R&D本部 マーケティングテクノロジー開発部 ちきゅうグループ マネージャー代理に就任。ちきゅう開発チーム3 マネージャー代理、ちきゅうグループ マネージャー、ちきゅうグループ 部長代理を経て、2022年4月GENIEE SFA/CRM事業本部 プロダクト開発部 部長に昇格。

現在の業務について

現SFA/CRMのマネジメントと、去年12月から再始動したSFA/ CRMの新基盤プロジェクトのほかに、今年の3月頃からALSVID（アルスヴィズ：エンジニア組織の課題解決）を進めています。
ALSVIDではエンジニアが抱える不満についてアンケートを取り、モニターやツールの不便さ、インセンティブ、ドキュメント管理までさまざまな意見が集まりました。チーム内だけでは解決が難しい問題を全社で解決するため、工藤さんと推進担当の鈴木さん、12名の有志メンバーでエンジニアの働き方改善に取り組んでいます。

体制を見直し見通しがよい組織へ

SFA/CRMの新基盤プロジェクト推進では、OKRに沿って各々が役割を持ち主体的に業務を進められる組織体制に変更し、目的・役割ごとに、新基盤開発、プロダクト価値向上、顧客要望対応、不具合やCS対応の4チームに分け、新しくUI/UXのチームも加えました。
役割を分けることで割り込み業務による計画のずれを解消し、リーダー一人当たりの担当メンバーを少なくしてフォローが行き届くようにしました。

ーー組織変更時に気を付けたことはあるか

認識の齟齬が生じないように図解などでわかりやすく伝えることを意識し、事業における優先度を説明した上でチーム編成や役割について共有することで納得して組織体制変更を受け入れてもらえたと思っています。
また、週1度のリーダー会でメンバーのモチベーションや業務の進め方に問題がないかを把握するようにしました。リーダーにはメンバーとの1on1を徹底するように伝え、コミュニケーションを取るとともにメンバーのタスク状況を確認してもらいます。組織変更の負荷がないよう移行期間を3週間〜1カ月程度設け、不具合が多い場合には変更自体を中止する判断もしました。

育成と業務委譲を進め組織の基盤を固める

現SFA/CRMでは中西さんやリーダーたちが主体となってタスクを巻き取り、スクラム開発でも自走してくれています。私のマネジメントのミッションの一つである育成を進めることで業務委譲が進み組織基盤も固まります。これまで手が回らなかった幅広い領域のマネジメントができるようになりました。

ーー業務推進で難しい部分はどこか？

開発側とビジネス側で共通認識を持つことです。開発の難しさはビジネス側に伝わりにくい点もあります。例えば工数見積の依頼などで、不明確な部分について開発側が「半年くらいかかるんじゃないか」と伝えたところ、ビジネス側で「半年でできる」とニュアンスが異なって伝わることがあります。ビジネス側からのリクエストに対して応えられる範囲を適宜判断し、情報共有と認識合わせを行い、両者の橋渡しをしながら共に事業を創っていけるように心がけています。

開発ならではの方法で組織改善を進める

優れた機能開発や大規模リニューアルを短期間で行うことが難しいように、組織全体も一朝一夕では変えられません。規模が大きく関わる人が増えるほど改善は難しくなります。大きな課題を解決するためには、自分やチームに合った難易度で課題を再定義し、着手しやすいように分解した上で一つずつ改善を進めることです。開発がいくつもの小さなプログラムを積み上げてシステムを作っていくように、組織も一つのチームの役割や動きを改善して横に連携することができます。そうしたエンジニアならではの方法で組織改善を進めています。

エンジニア組織の改善に向けて

エンジニアの領域は、この4、5年で開発から分析・検証などにまで広がり、コロナ禍で進むDX化への貢献もしやすくなっています。設計能力や抽象的な課題を具体化する力を使い組織のDX化や改善につなげられるエンジニアを増やしたいです。今後は、SFA/CRMの新基盤プロジェクトの例をもとに全社課題の改善とALSVID推進に向けたアウトプットや勉強会の実施を考えています。

■ジーニーについて
ジーニーは、「誰もがマーケティングで成功できる世界を創る」「日本発の世界的なテクノロジー企業となり、日本とアジアに貢献する」というパーパス（企業の存在意義）のもと、企業の収益拡大・生産性向上など様々な課題解決につながるソリューションを開発・提供するマーケティングテクノロジーカンパニーです。

今期、全社の営業利益達成を牽引したサプライ事業本部の中村亮太さんに、組織力向上に向けた取り組みについて伺いました。

中村 亮太／サプライサイド事業本部 メディアリクルーティング部 トップコンサルタントグループ マネージャー

（略歴）
2017年11月からのインターンを経て2018年4月入社。サプライサイド事業本部に配属。2019年4月よりDOOH事業部を兼務。

ーー現在どのような業務を担当していますか？

サプライサイド事業本部の利益増進が私の主なミッションです。
既存顧客の維持と新規顧客の獲得を行うチームがあるのですが、自分は新規獲得チームを中心に見ています。そのほかにも新卒や中途社員向けの研修、中長期の事業成長に向けた製品・バリューチェーンの検証、事業計画の作成など、業務は多岐にわたります。

ーー事業を推進する上で大変なことはなんですか？

事業推進で難しいことは、個人の意識をいかに数字に向かせるか、です。特に大きなGAPが出ている時にメンバーの意識を統一することが最も難しいです。GAPが大きすぎて、どう足掻いても達成が難しい状況に陥ってしまったときに早々に諦めるチームではなく、1%でも達成の可能性に賭けて全力を尽くせるチームは、やはり集団としての地力が違います。

常に貪欲に数字にコミットメントする雰囲気を醸成するために、日ごろから、強くKGIを意識するようなコミュニケーションを心がけています。一人ひとりの現状を細かく把握し、GAPに対して必要なアポ数、売上などについて個々の具体的なタスクや数値に落とし込む。こうしたマネジメントによって、単に「頑張る」ではなく、メンバーそれぞれが自分で考え、動けるチームになると考えています。

全員で目標をクリア！一皮剥けた常勝軍団に

以前は大型の案件がたまたま取れたり、スター的な営業担当が強引に数字を作ることで目標を達成していました。今のチームはメンバー全員が安定的に高い達成率を維持し続けていて、それまでの「たまたま達成するチーム」から、手堅く数字を作ることができる常勝軍団へと一皮剥けることができました。前半期は全員が目標を達成してくれたんです。組織のレベルが向上していると実感でき、とてもやりがいを感じます。

率先した読書と先人の知恵に学ぶマネジメント姿勢

入社2年目にリーダーになりメンバーを見る立場になった当初、独学のマネジメントで部下に厳しく接し、辛い目にあわせてしまったことを反省しています。それ以来、先人の知恵に学ぼうと本を読んで勉強するようになりました。一般論的な70〜75点の正解までは本に載っています。あとの25点は自分で考え、ジーニーの文化に合わせチューニングしながら100点の正解を模索しています。

また、上司が勉強しないと部下も勉強しません。まずは自分ができるだけ本を読んで、メンバーとの1on1で現状とあるべき姿を話し合い、課題や関心事に応じて本を薦めるようにしています。

社会人1年目の方によくおすすめしている本が『苦しかったときの話をしようか』（著者：森岡 毅　ダイヤモンド社）です。仕事に向かう姿勢やチームにおける役割意識が書かれています。

ーーメンバーと自身が成長するために大切にしている価値観はなんですか？

失敗に対する捉え方や対処には特に気をつけています。失敗は「うまくいかなかった結果」であると同時に、「次回以降うまくいくための貴重な機会」です。失敗を失敗で終わらせず、学びの機会にできるかどうかで個人やチームの成長角度が大きく変わってくると思います。

失敗の要因がスキル的にできなかった「can’t」か、惰性でやらなかった「don’t」なのかをしっかりと見極めます。メンバーが全力を尽くした上での「can’t」は100％マネージャーの責任です。メンバーには次にどうしたら成功できるかをアドバイスするようにしています。

一方で、できるにも関わらずやらなかった「don’t」の失敗は、人間の弱さに起因するので、ドラスティックに価値観に訴え是正するためしっかりと注意します。

これはパワーを使いますし、メンバーから嫌われるリスクも孕みます。可能なら放置してやり過ごしたい気持ちもありますが、我々はもういい大人です。自分が、部下にとって本気で叱ってくれる最後の人かもしれない、と考えると適当な対応はできません。自身と部下の成長のために、失敗の要因を分析し、真摯に対処するよう心がけています。

ーー今後チャレンジしたいことはなんですか？

より管掌範囲を広げて、より大きな組織を率いて、より全社に対して大きなインパクトを与えたいです。たくさんのチームメンバーと一緒にチャレンジしながら困難を乗り越えていきたいです。

Contents

１　「bootcamp」とは？

２　【対談】新卒から見たbootcamp2021

３　【対談】運営から見たbootcamp2021

４　【対談】来年度に向けて

１　「bootcamp」とは？

ジーニーでは、新卒エンジニアに向けて、「bootcamp」と呼ばれる技術的な研修を行います。ここでは、1ヶ月半ほどかけて様々な技術に触れながら、業務に入るまでの準備を行います。

多種多様なバックグラウンドを持った新卒が、技術力を底上げできることがbootcampの特徴です。

２　【対談】新卒から見たbootcamp2021

 ―― まずは、bootcamp2021を受講した感想を聞かせてください。

21卒 筒井：昨今の情勢を踏まえて、リモート形式と対面形式が併用されていたのですが、その中でもスムーズに運営を進めてくださったのが良かったです。
リモート環境だとどうしても会話がしづらくなりますが、少人数のグループに分けて課題に取り組むなどの工夫があり、新卒同士でコミュニケーションが取りやすかったですね。

21卒 渡邉：自分は単純に楽しかったですね。大学での研究のように一つを極めるのではなく、新しい知識をどんどん取り入れていくというのが、とても新鮮でした。
自分が興味のある分野だけではなく、網羅的に知識を得られたのも良かったです。

21卒 筒井：自分は大学時代にWeb開発の知識をあまり学んでこなかったので、bootcampで足りない知識を補えました。研修で学んだ知識をそのまま業務で活かすことができているので、とても有意義な時間だったと思います。

―― 特に、どんな知識を得られましたか？

21卒 筒井：開発の経験が少なかったため、ほぼ全てが真新しい内容でした。UNIXコマンドやGitの使い方など基礎的なところから、Dockerやクラウドなど実践的なところまで知ることができました。

21卒 渡邉：同感です。自分はUNIXコマンドなど基礎的な分野で分からないことが多かったのですが、質問できる先輩や同期が多くいたので、基礎固めに役立ちました。
大学での研究とは違い、みんなが揃って同じ課題に取り組んでいたので、質問しやすいというのも良かったです。

―― bootcampで、特に実業務に役立っている内容などはありますか？

21卒 筒井：UNIXコマンドやGitの知識が特に役立っていると思います。
今まではGUIに頼りきっていたのですが、コマンド操作に慣れることで作業の効率化に繋がりました。

また、Gitのbranchを切る、という基礎的な知識がとても助かっていますね。今まで個人での開発は`git push origin main`しかしてこなかったので（笑）。
今ではしっかりとbranchを切って、レビューを受けて、修正をして……という過程を経ることで、安心して自分のコードをマージすることができています。

21卒 渡邉：自分はDockerとGo言語の知識が役立っていますね。配属されたプロダクトでまさに使用している技術ですので、日々業務に活かしています。

20卒 東：役立っているのは嬉しいですね。bootcampの目的の一つとして “実際にプロダクトで使われている技術を教える” ということがあり、その目的が達成されていることを知れてよかったです。

20卒 牛丸：基礎的なところをしっかり学ぶことで、何も知らない状態では起こってしまうようなミスを一定防ぐことができていると感じています。研修が全体の最低限の技術レベルの引き上げになっていると嬉しいですね。

 ―― では、bootcampで特に面白かった講義はなんですか？

21卒 筒井：サーバ作成研修です。Redisのプロトコルに沿ったサーバを作成するという研修でしたが、作成したサーバの速度を同期間で競い合ったのが面白かったです。

21卒 渡邉：LEMP研修が面白かったです。ブログを作成するという課題で、フロントエンドやバックエンドも含めて作成したため、これまでのbootcampの集大成という感じがしました。
個人的にデザインにも興味があり、こだわれたのも楽しかったです。最後に成果物のプレゼンをする際も、発表資料にかなりこだわってしまいました（笑）

20卒 東：渡邉さんの発表は特に良かったことを記憶していますね。全体としてデザインが統一されていました。

―― bootcampの内容で改善すべきと感じたところを教えてください。

21卒 筒井：講義によってレベル感が違う点が少し気になりました。全員が課題を午前中に終えられる講義がある一方で、2、3人程度しか基礎課題を終えられない講義もありました。

21卒 渡邉：自分は、個人ではなくチームで1つの開発を進めるような研修があれば良かったと感じました。

20卒 牛丸：チームで行う研修をカリキュラムに盛り込む予定もありましたが、諸事情で実施できませんでした。ただ、次年度に向けて、今年度よりも一段進んだ研修ができるよう、画策しています。

３　【対談】運営から見たbootcamp2021

 ―― 続いて、bootcampの運営をされた皆さんにお聞きします。全体を通してどのような感想をお持ちですか？

20卒 東：研修の計画段階に携わりましたが、なぜ研修を行うかという目的設定や、社内調整など、学びになる部分が多かったです。

20卒 牛丸：そうですね。研修の講師は社内から選出しているのですが、講義レベルに合わせて高い技術力を持つ方に担当いただく必要があり、各チームの状況を確認しながら社内調整をする必要がありました。
その際、社内でどういう決め方がなされて、どのように意思決定されるか、という過程を知ることができました。

―― 運営を行う中で特に気を付けたことや、心がけたことを教えてください。

20卒 東：今年度はリモートで講義を行なうことがあったので、コミュニケーションの促進を心がけました。
具体的には、受講者向けのアンケートでコミュニケーション量に関する設問を用意したり、チームに分かれての作業では少人数に分けてコミュニケーションをとりやすくしたりしました。また、講師の方にもコミュニケーションを促すように依頼しました。

21卒 筒井：確かに、アンケート項目としてコミュニケーションがどの程度取れたか確認する設問があったので、同期と会話をするきっかけになりましたね。

21卒 渡邉：講義では3、4人のチームに分かれて作業をすることが多かったのですが、このチームはどのような基準で分けていたのですか？

20卒 東：アンケートで、次回の講義内容に関する事前知識の有無を回答してもらっていたのですが、その結果を元に、事前知識のない方が偏らないようにチーム分けをしました。

 ―― 大変だったことや、反省点はありますか？

20卒 東：反省点としては運営陣だけで何もかもやろうとし過ぎたことですね。
例えば、対面で研修を行う時に、講師の声が聞こえづらいという問題に気づきました。そのため、講師へ必ずマイクを使うように依頼していたのですが、そういった問題は本来、毎回講義を受ける受講者が一番気付きやすい立場にいるはずです。受講者側から要望の発信が自発的に行われるような環境づくりにより注力すべきだったと考えています。

20卒 牛丸：新卒も既に会社の一員ですので、いろいろと任せてしまった方がよかったですね。事前に起こり得る問題を想定して対応するのは難しいですし。
これは先ほどのアンケートの話にも繋がると思っていて、”アンケートの設問に、その設問を用意した意図を付記しておく” ことも必要だったと感じています。

21卒 筒井：確かに、まだ会社の一員という意識が薄く、受け身になるところが多かったです。

20卒 東：もちろん、新卒の方が意見を言える雰囲気作りは、運営がする必要があると思っています。

20卒 牛丸：業務経験が既にあるインターンの方に雰囲気作りを任せるのも良いかもしれないですね。誰かが初めに積極的に意見を出せば、意見の出しやすい雰囲気が作れますからね。

４　【対談】来年度に向けて

 ―― 来年度のbootcampに思うこと/意気込みなどをお聞かせください。

21卒 筒井：人に教えられる力量があるかは自信がありませんが、bootcampが始まるまでにより多くの知識を会得していきたいと思います。

21卒 渡邉：自分もまだまだ未熟なので、先ほど話にあった ”誰かに頼る” ということを大事にしたいですね。

20卒 東：昨年よりも今年、今年よりも来年と、より良いものにしていきたいですね。その上で、運営を評価する定量的な指標を得られないか考えています。定量的であれば、各組織との合意を取りやすいですからね。

20卒 牛丸：今年度の研修運営では無駄が多かったように感じます。反省をしっかり活かして、研修の改善を進めていきたいです。

一緒に働く仲間募集中！

【ジーニーのリクルートサイトはこちら】
https://geniee.co.jp/recruit/

2021年度上半期の優秀社員表彰（※）で、VP（valuable player）を受賞した入社2年目の大屋勝義さん。大屋さんは、デマンドサイド事業本部で丁寧かつ迅速な対応でお客様との良好な関係値を構築して、アプリセグメントで大きな成果をあげたことが評価されてVPに選ばれました。
デマンド営業として活躍する大屋さんに、仕事への向き合い方や成長機会、成果に対する思いを伺いました。

大屋 勝義 ／ デマンドサイド事業本部 デマンドセールス部 アフィリエイトセールスグループ アフィリエイトセールス2チーム

（略歴）
2019年4月に入社、マーケティングテクノロジー事業本部に配属。コマーシャル営業部、マーケティング部 を経て2020年10月よりデマンドサイド事業本部 デマンドセールス部 アフィリエイトセールスグループに所属。

仕事と競技の両立に苦しんだ1年目

「人より早く成長したい」という思いが強く、最新のマーケティングを実践しているジーニーに入社しました。マーテク（マーケティングテクノロジー事業本部）に配属され、毎日がむしゃらに働いていました。学生時代はベンチプレスやボクシングの選手として毎日ジムでトレーニングしていましたが、あまりの忙しさに平日は全くジムに行けなくて。入社当時は新人賞を狙っていたのに成果を出せず、競技と仕事をうまく両立できず、「自分は会社員には向いていないのではないか」と悩み、苦しい時期を過ごしました。

上長や人事の方に相談に乗っていただき7月中旬にマーケティング部へ、10月には、営業としてより成長したいという思いからデマンド部へと異動することになりました。周囲の方の理解と配慮あっての異動でしたが、短いスパンで部署を移ることが心苦しく、不安ともどかしさでいっぱいでした。

「自分の食いぶちは自分で稼ぐ」

デマンドに異動する際に、先輩から「自分の意思で異動したんだから自分の食いぶちくらいは自分で稼げるようにならなあかんで」と言われたんです。ネガティブ思考のループに囚われていたのが「早く自分の給料分くらいは数字を作らなくては！」という気持ちに変わっていきました。
異動して間もない頃は、上長の真似をすることから始めました。僕の見積や提案に厳しいフィードバックをもらいながらも、食らいつこうと必死でした。

お客様のリクエストにいかに丁寧に、速く応えるか

日々提案を繰り返すうちに担当顧客も増えていき、売上目標も持たせてもらえるようになりました。意識していたのは「継続的なコミュニケーション」と「丁寧で迅速な顧客対応」の2つです。

「継続的なコミュニケーション」では、担当顧客と毎月の打ち合わせに加えて、ほぼ毎日メッセンジャーや電話で進捗確認や増額提案を行っていました。毎日の継続的な折衝や顧客対応のおかげで強固な関係を築くことができ、2年目の上期、元々は小口だった案件を成長させ大型案件としてまとめることができました。自分を信頼してお客様とのやり取りを任せていただき、自分の強みを生かしてコミュニケーションを積み重ねていけたことがVP受賞につながったと思います。

「丁寧で迅速な顧客対応」では、お客様からのリクエストにタスクの優先順位を考え効率的に応えるため、マーケティング部時代に学んだタスク管理ツールを活用しました。また、顧客の依頼に対しては期限よりも早く、且つ分かりやすくアウトプットすることを上長から学び、実践しています。業務量が多くてもできる限り集中して定時までに終わらせることで、ジムに通う時間が持てるようになりました。今年初めて出場したボディービル競技では、10カ月で28キロの減量をしながら、仕事で100%以上のパフォーマンスを発揮するよう努めました。その日の仕事を完璧にこなす、タスク期限までに提案書を出す、などの徹底した積み重ねで仕事の成長も実感でき、充実した毎日につながっています。

デマンドのマッチョなエースを目指す！

今後はアプリチーム、そしてデマンド事業本部を引っ張っていけるエースになりたいです。MVT（most valuable team）を獲得して、ジーニーの中で「アプリチームすごいぞ」という存在にできればと思っています。

私生活ではもっとマッチョになって、パワーリフティングで世界チャンピオンを目指したい。毎日楽しく筋トレも続けたいです。

※ジーニーの表彰制度について
ジーニーグループでは、全社員を対象として半期ごとに社員の表彰を行っています。その期に活躍した個人が「VP（valuable player）」「MVP（most valuable player）」、団体が「VT（valuable team）」「MVT（most valuable team）」として選ばれるほか、通年に一度、「年間MVM（most valuable manager）」や社員投票で選ばれる「ベストジーニスト」、「新人賞」などがあります。

今回は、前年比324％の成長を達成したマーケティングテクノロジー事業本部でカスタマーサクセス（以下CS）を担当する新卒2年目の若手社員2名にインタビューを実施しました。仕事のやりがいや課題への向き合い方など、業務のリアルな部分も詳しく話を聞きました。

山田 俊幸（右）／慶応義塾大学 法学部 政治学科卒業。大学時代は体育会レスリング部に所属しスポーツに打ち込む。2020年1月から新卒内定者インターンとして入社。マーケティングテクノロジー事業本部カスタマーサクセス部配属。2021年7月同部チームリーダーに就任。既存大型顧客に対しプロダクトの活用方法や新規サービス/機能提案を担当。

小宮由佳（左）／上智大学 総合人間科学部 心理学科卒業。大学時代はフリーペーパーの作成活動に打ち込む。2019年12月新卒内定者インターンとして入社。マーケティングテクノロジー事業本部カスタマーサクセス部所属。新規顧客のツール導入サポート、既存顧客の問い合わせ対応等を担当。

1.大きなビジョンと顧客への提供価値が入社の決め手

ーーまず、ジーニーの入社理由を教えてください！

山田：今入らないと一番後悔する会社だと思ったからです。私は規模や業界を問わずさまざまな企業を対象に就活をしていました。その中でもジーニーの「日本発の世界的なテクノロジー企業を創る」という創業の志や、M＆Aを行い業務領域を急拡大しているという話を聞き、組織全体のビジョンの大きさや成長性に対して直感的にわくわくして入社を決めました。

小宮：ものづくりに自らが積極的に関わることができ、お客様に価値提供できるという点が入社の決め手でした。私は就職活動では一貫してものづくりに携わりたいと考えており、当初はイベント業界や出版系の会社を目指していました。ジーニーに出会い、プロダクトを自社開発している点や、M&Aでどんどん事業を拡大している点から、ビジネス職として主体的にものづくりに関わっていけそうだと思い興味を持ちました。また、若手が活発に意見発信できる風土があり、目の前のお客様に直接新しい価値を提供できそうだなと感じたことも大きいですね。実際に今のCS部は過渡期で、組織体制の構築やお客様に届けるコンテンツ作成など、いろいろなことを任せてもらっています。さまざまな観点からものづくりに携わることができ面白いです。

2.徹底的にお客様と同じ目線に立つ

ーー業務ではどんな役割が求められますか。

小宮：CS部の役割は、お客様にツールを導入していただいて終わりではなく、営業組織やマーケティング活動の改善など、お客様の目標に対して結果を出せるところまで並走することです。CS部の業務は多岐に渡りますが、私は主に、弊社ツールを契約いただいているお客様からのご質問への回答や、トラブル対応を担当しています。お客様と自社を結ぶ窓口として、お客様が何でも話してくださるような関係値を作ることが私たちの最も大きな役割だと思います。良いことだけでなく、不満や疑問などネガティブ面も率直に話してもらえるような信頼関係を築くことが必要です。SaaS事業は、お客様の継続的なご利用で成り立つビジネスです。そのため、お客様の満足度を常に高く保つCSの役割は非常に重要でやりがいを感じます。

山田：私は主に、サービスの活用度合いが特に高いお客様に追加機能や別サービスを提案するアップセル活動（営業）を担当しています。例えば、お客様の活用状況に応じて、プロダクトの新機能活用を私たちから能動的に提案したり、課題がありそうな場合にはお客様とのミーティングを設定して課題解決の方法を一緒に考えたりしています。そのような業務の中で私に求められる役割は、お客様から既にいただいている要望だけでなく、潜在的な課題を先回りして解決することだと考えています。そのために、お客様の営業組織やビジネスモデルを把握し、改善の点を自分ごととして考えご提案していくことを大切にしています。

ーーお客様と信頼関係を築くために心がけていることは？

山田：私はお客様にとってプラスになる提案を持っていくことを一番に心がけています。以前上司に言われ印象に残っている言葉に「お客様の時間を奪うことは、お客様が寿命を自分に捧げていることと同じ。それに見合う価値をきちんと還元しなさい」というものがあります。自分に時間を捧げてくれているお客様のためにも、ミーティングでは単なる質問対応では終わらず、プロダクトの活用方法の新提案や業界のトレンドなど、お客様にとって価値のある情報を準備して持っていくようにしています。

小宮：お客様の要望に対して、実現が難しいことでも「できません」で終わらせずにプラスαの代替案をお出しするようにしています。疑問や不安、要望があるお客様に対して、期待してくださる以上の対応を行うことでお客様に安心していただき、頼りにしていただけるコミュニケーションの取り方を心がけています。

ーーCSとして働き、どんなスキルが身につきましたか？

山田：まだまだ力をつけている途中ではありますが、論理的思考力とアウトプット力は日々鍛えられていると思います。お客様とミーティングをする際には、お客様の営業組織の状態や課題を構造的に把握し、新たな改善施策を迅速に提案していく必要があります。また、CSはお客様の課題を解決するため事業開発やプロダクト企画、エンジニア等社内の様々な部署に協力を仰ぐことも多い職種です。社内外との交渉を進める中で、論理的思考力や質の良いアウトプットを行う力が養われていると感じます。

3.お客様に本質的な価値を提供するために走り続ける

ーーどんなCSをめざしていますか？

山田：「山田さんの提案力がすごいからサービスを使い続けたい」と言ってもらえるような存在になりたいです。もちろんお客様は、弊社のサービスに期待してご契約くださっていますが、ジーニーが提供する価値はサービスそのものだけでなく、活用方法の提案やコンサルティングも含まれていると考えています。そこで、サービスそのものの価値に加えて、僕自身という「人」に期待や価値を感じていただけるような人材になりたいと思っています。また今後はリーダーとして、組織作りや体制作りにも携わっていきたいです。私たちはまだ若いチームです。小さな疑問や不具合に対しても、まだまだ個人のマンパワー任せで、ナレッジ共有や生産性の改善点もたくさんあります。今後は、お客様自身の力で問題を解決できるコンテンツを充実させることで、お客様のより本質的な課題解決にCSがしっかり時間を割いてコミットできる組織体制を作っていきたいです。

小宮：お客様と自社を結ぶ窓口としてお客様の声を社内に反映させ続けられる存在になりたいです。そのためには山田君が話していた通り、論理的思考力や伝える力、高いコンサルティング力を身に着けて、お客様により良い情報や価値を提供できるようにしていきたいです。そのためにも営業部や事業開発部など部署間の連携強化の仕組みを、お客様の声を一番近い立場で聞いている私たちCS部が主導となって進めていきたいと考えています。

ーー最後に、このブログを読んでいる方にメッセージをお願いいたします！

小宮：CSは初期導入時のコンサルティングやアップセル等の提案からメルマガ等のコンテンツ作成まで様々な業務があります。目の前の業務に真摯に取り組みながら興味のあることに挑戦できる環境がありますので、いろいろなことに取り組みたい好奇心旺盛な方は楽しんで働ける環境です。この記事を読んで、CSの働き方に興味を持っていただけたら嬉しいです！

山田：ジーニーは良い意味で目標達成に貪欲で、そこに向かって全部署が一丸となって取り組んでいる会社です。特にCS部があるマーケティング事業本部は若い事業でもあるので、社内の組織や体制作りに若手が裁量を持って携われることも大きなやりがいです。お客様と近い位置での価値貢献に興味がある方はもちろん、新しい組織作りに興味がある人がいましたら、ぜひ一緒に働きたいです！

GENIEE SSP開発チームの齋藤です。ジーニーには2019年に新卒入社して、今年度で3年目になります。

SSP開発チームではスクラムを取り入れた開発を始めておよそ一年経ちました。チームでスクラムをどのように取り入れたか、スクラムを取り入れてから何が改善されたか、という点を書いていこうと思います。

齋藤洋平 / 宮城大学(事業構想学部)卒業後、2019年に入社。R&D本部アド・プラットフォーム開発部 SSP開発チーム リーダー。

Contents

1. SSP開発チームの業務と抱えていた課題

2. そもそもスクラムとは

3. スクラムの課題に立ち向かう

4. スクラムを取り入れて改善されたこと

5. まとめ

1. SSP開発チームの業務と抱えていた課題

SSP開発チームでは広告収益を最大化するためのアドプラットフォームであるSSP(Supply Side Platform)の運用や改修、その他収益の全般的な最適化ツールを開発します。

■主な業務

普段はざっくり次のような業務があります。

■スクラムを取り入れる前のSSP開発チームの課題

スクラムを取り入れる前は、エンジニアの属人化が問題になっていました。いわゆるバックエンド、フロントエンド、というような区切りで開発の担当者が決められ、PMと担当者間で仕様が決まるという体制です。開発を担当した者しか詳細を把握してない場合が多く、問題が起きた時に担当者が既にチームにいない場合は、誰かが一から仕様を調査する必要がありました。

PMと担当者という体制の場合、要件の認識が合っていないことによって開発の遅延が起きることがありました。また、エンジニアの経験や能力次第で開発が遅れてしまうということもしばしばありました。特に最近はほとんどのエンジニアがリモートで勤務しているためコミュニケーションの機会も減りました。これも情報共有においては障害になることがあり、開発の遅れの原因の一つでした。

 2. そもそもスクラムとは

2020年版のスクラムガイドでは、スクラムの定義について次のように述べられています。

> スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、人々、チーム、組織が価値を生み出すための軽量級フレームワークである。

> スクラムのルールは詳細な指示を提供するものではなく、実践者の関係性や相互作用をガイドするものである。

2020-Scrum-Guide-Japanese.pdf スクラムガイド 2020年11月

…このように、抽象的な定義です。

定期的にスクラムガイドは更新されますが、2017年版と比べて2020年版では、スクラムを最小限かつ十分なフレームワークに戻すことを目的とし指示的な表現を減らしてあるようです。「スクラムとは〇〇であるべき」みたいな型に合わせるものではなく、開発チームの体制や業務に合わせて、チームの課題を解決するためにスクラムを取り入れました。

■スクラムを取り入れる

これまでSSP開発チームで抱えていた属人化の課題の解消や、開発の遅延を防ぐ・検知する、コミュニケーションの機会を増やす、といったことを目的にスクラムを取り入れました。機能をどれだけ開発できているか可視化する目的もありました。

■スクラムチーム

スクラムを取り入れてチームの編成が変わりました。PMの要望にチームで応えられるよう、それぞれに得意な領域を持ったメンバーの機能横断型チームとしてスクラムチームを構成しています。

■具体的な運用

AtlassianのJiraというツールを使っています。2週間を1スプリントとし、開始と終了にスプリントプランニング、スプリントレビューを行います。毎日15分から30分程度のデイリースクラムでコミュニケーションをとり、進捗や問題を明らかにしています。

ツールの運用の工夫として、スプリント中の差し込みタスクを記録するためのバックログを事前に作っている点が少し変わっていますが、これは後述します。基本的にはスクラムガイドに従ったフローです。

3. スクラムの課題に立ち向かう

ガイドラインに従って一般的と思われる形でスクラムを取り入れましたが、スクラムのフレームワークで解決できない課題があります。例えば差し込みタスクは事前のプランニングの外にあるので、こちらへの対応が課題になりました。また、広告フォーマットの仮説検証など、通常の開発とは違う取り組みにも対応が必要でした。

■差し込みタスクへの対応の難しさ

差し込みタスクはスクラムチームの進捗を妨げる障害になるので、基本的には引き受けないようにしますが、どうしても改修や調査をやらねばならない時があります。

差し込みタスクのような予定していない作業が増えると、スプリントで完了させることのできるタスクの量が安定しづらくなり、機能のリリースで価値をもたらすまでの時間が増えてしまいます。

■スプリントごとの差し込みタスクの量を調べてバッファを持つ

スプリントで実行する作業計画を立てる際に、その期間で発生する差し込みタスク分のバックログを作り、差し込みが発生するたびに追加しています。このようにしてスプリント内の差し込みタスクがどの程度あったか記録しておくことで、次回以降のスプリントにバッファを持たせるようにしています。

(差し込みタスクは誰がどれくらい時間を取られたか記録し後から把握できるようにしている)

■遊撃部隊的な動きで対応する

SSP開発チームでは、広告フォーマットの開発やフォーマットのABテストなどの仮説検証を行うこともあります。このような開発は状況に合わせて試行錯誤する作業になるため、どれくらいの開発が必要か事前に予測がしづらいです。

そこで、プランニング時にアサインするタスクを少なめにした遊撃部隊のような要員も含めています。このメンバーはプランニング時点でアサインするタスクをかっちり決めないことで、事前に予測できないタスクに対応します。

このような取り組みで差し込みタスクや仮説検証のタスクに対応可能にし、スクラムの課題に立ち向かう工夫をしています。

4. スクラムを取り入れて改善されたこと

スクラムを取り入れて体制がいくつか改善されました。エンジニア個人の能力の幅を広げる意識と、チームで知識を共有して属人化を防ぐ意識が定着しています。

■チャレンジしやすい環境になった

> スクラムチームは機能横断型で、各スプリントで価値を生み出すために必要なすべてのスキルを備えている。また、自己管理型であり、誰が何を、いつ、どのように行うかをスクラムチーム内で決定する。

2020-Scrum-Guide-Japanese.pdf スクラムガイド 2020年11月

スクラムガイドに従い、機能横断で自己管理型であることを目指しています。

機能横断型のチームになるためには、それぞれ得意な領域を持った他のメンバーとの連携やコミュニケーションが必要です。また、スクラムのメンバーは自己管理型を意識し、作成したバックログの中から自分たちでタスクを選んでいくようにしています。

タスクはリファインメント時に可能な限り分割されています。必要であればペアプログラミングも行いながら開発することで、経験が少ない領域にも小さなタスクから挑戦しやすくなりました。

■属人化の解消をチームで意識するようになった

スクラムを取り入れる前は、いわゆるフロントエンド・バックエンド、といった領域によっておおよその担当者が決まっており、担当者とPMとの間で仕様が決められるという体制でした。これは属人化の原因になっており、ある領域で優秀な一人のエンジニアにばかり任せるという状態が見られました。

スクラムを取り入れてからは、PMからの要望をチームで理解し、バックログに分割しています。スプリントで目標にしたバックログの完了はチームの責任として考え、チーム全体が仕様を理解するための意識が生まれ、属人化の解消に繋がっています。

5. まとめ

僕の所属するSSP開発チームでは、チームや組織・プロダクトの実情に合わせてスクラムを取り入れて運用しています。スクラムを取り入れて改善された点は、エンジニア個人の能力を広げる挑戦がしやすくなったことと、チームで理解して属人化を防ぐ意識ができたことです。開発する機能の遅れにも気が付きやすくなりました。

どうしても発生する差し込みタスクに対しては、一定量の受け入れる準備をしていることや、遊撃要員はある程度自由に動けるようにするような工夫をしています。それ以外はほとんどスクラムガイドに従うようにしており、従来の開発体制と比べて開発フローが改善したと感じています。

スクラムは組織が価値を生み出すためのフレームワークです。チームや開発項目で抱えている問題に向き合い、スプリントごとの振り返りで開発の体制を継続して改善することが重要でしょう。

ここまでが、GENIEE SSP開発チームでスクラムを取り入れた際の工夫や改善された点の紹介でした。スクラムを取り入れた開発の一例として参考になればと思います。

参考

2020-Scrum-Guide-Japanese.pdf スクラムガイド 2020年11月

一緒に働く仲間募集中！

【ジーニーのリクルートサイトはこちら】

https://geniee.co.jp/recruit/

今回は、前年比324％の成長を達成したマーケティングテクノロジー事業部で営業を担当する社員にインタビューしました。仕事のやりがいや課題への向き合い方など、営業のリアルに切り込んでお話を伺います！（聞き手：人事部　鈴木万里・岡本遼介）

1.「世界を目指す」が入社の決め手

ーーまず、ジーニーの入社理由と自己紹介をお願いします！

入社の決め手は「日本発の世界的なテクノロジー企業を創る」というジーニー創業の志と、全く新しい分野で挑戦する姿勢に惹かれたことです。

私が学生だった当時、ジーニーはマーケティングオートメーション「MAJIN」の提供を開始して既存のアドテクノロジー事業を伸ばしながらもマーケティング事業という新たな分野に挑戦し始めた段階でした。

そんな中で、面接を担当していた社員や社長自身が本気で世界へのビジョンを語っているのを見て「本当にこの会社はビジョンを実現できそうだな」と将来性を感じました。

私は広告や出版業界を志望しており、アドテクノロジーやマーケティングについての知識は全くなかったのですが、「自分がまだ知らない領域でどのように世界一を目指していくのだろう？」と、とてもわくわくし入社を決めました。

ーー3年目にマーケティングプロダクトの営業に異動したきっかけを聞かせてください。

マーケティングの様々な分野に携わりたいと思ったからです。

私が入社したときは、マーケティング関連のプロダクトは「MAJIN」だけでしたが、異動時にはSFA/CRM（営業管理ツール）「ちきゅう」やチャット型Web接客プラットフォーム「Chamo」が合流してどんどん事業を拡大していました。

そんな中で顧客企業のマーケティングを幅広く支援したいと考え、当時マーケティング事業（現マーケティングSaaS事業）の立ち上げを行っていた社員に誘われて、ジョインしました。

2.長期視点で顧客価値を生み出す

ーー現在の業務を教えてください。

「MAJIN」と「ちきゅう」の営業担当をしています。お客様は、主に企業の営業担当者で、営業部長など営業組織の体制を決定する方が多いです。中小規模の企業では社長に直接ご提案することもあります。

オフラインの展示会などに出展することもありますが、最近はオンラインが主流となり、アポイントから契約まで全てオンラインで完結することもあります。

ーー営業するにあたって難しい部分はありますか？

私が営業するプロダクトは、お客様と年単位で使用契約を結び、月額使用料をいただくSaaSというビジネスモデルです。お客様にとっても長期間使う重要なサービスだからこそ慎重に導入をご検討いただくので、その分、営業の難易度は高いですね。

特に難しいのは、MAやSFAの概要や利便性をまだ認識していないお客様へのご提案です。例えば、歴史ある企業だと、長年の得意先との取り引きだけである程度安定した売上を出せており「無理してツールを導入する必要ないのでは？」と考える方も多いです。しかし、そのようなお客様であっても、社会全体がデジタル化していく中で今と同じやり方をしていると、変化に対応できずに売上が伸び悩んでしまう恐れがあります。

そのため、私達は顕在化している課題だけでなく、潜在的な課題も解決できるご提案をする必要があります。お客様の営業組織が目指す方向性や、それに対する課題感について徹底的にヒアリングを行い、未来の成長のためにできることを一緒に考えるように心がけています。

ーーどんな時にやりがいを感じますか？

まだ課題感を感じていないお客様にもお話をするので、一件一件がすごく深い提案になり、そこが難しくも面白い部分ですね。

お客さん自身が言語化できていなかった課題を一緒に見つけ、それを弊社ツールの導入で解決できたとき、お客さんに「まさにこれがやりたかったことでした」と仰っていただけたときは本当に嬉しいです。

お客様の中には、契約締結後に新しい相談を私宛てにくださる方もいらっしゃいます。導入コストがかかるものを真剣にご提案する分、信頼関係が生まれ、お客様の課題解決に寄り添い続けることができるのは、SaaS営業の醍醐味だと思います。

また、「ちきゅう」を導入されているお客様が「MAJIN」もあわせてご利用くださるなど、お客様の様々なニーズに柔軟に応えられることもプロダクトの幅が広いジーニーの営業ならではのやりがいだと考えています。

３．営業担当として、マーケティングテクノロジーの明日を切り開く

ーーマーケティングテクノロジー事業本部の将来をどのように考えていますか？

将来的には、「マーケティングや企業の経営課題を、ジーニーに相談すれば全て解決できる」マーケティングの総合プラットフォームを目指しています。そのために現在、「ちきゅう」「MAJIN」「Chamo」を統合して一つのプラットフォームとしていくことを計画しています。

お客様が長くサービスを使用することになるので、現在の機能面だけでなくプロダクトの長期的なビジョンをお客様にお伝えすることも多くあります。プロダクトの将来性に共感いただき契約してくださるお客様もいて嬉しく思います。

ーー伊勢さん自身は今後どんな営業担当を目指したいですか？

ジーニーはプロダクトや技術が強みの会社ですが、それだけに依存しない営業であり続けたいと思っています。お客様の本質的な課題解決のためには、SFAやMAツールをただ契約して導入してもらうだけでなく、お客様の考え方そのものを変えていく必要があると考えています。お客様と最初に接点をもつ立場だからこそ、ただ売るのではなく、コンサルティングスキルを持った営業になっていきたいですね。

そのために、仕事の中で「なぜツールを導入する必要があるのか」「ツール導入後にお客様の営業組織やマーケティング組織はどう変わっていくべきか」といった根本的な部分をお客様と一緒に考え抜くことを大事にしています。

お客様ととことん向き合って、営業組織やマーケティング組織のあり方そのものを変えていける、そんなかっこいい営業になりたいなと思っています。

ーー最後に、このブログを読んでいる方にメッセージをお願いいたします！

ジーニーのマーケティングテクノロジー事業本部は、お客様に新しい価値を提供するためにどんどん高い目標を立てて、猛スピードでPDCAを回している事業部です。

どんどんプロダクトも事業も進化している部門なので、興味を持ってくださる方がいましたらぜひ一緒に事業の未来を創っていきましょう！

こんにちは、アド・プラットフォーム開発部マネージャーの杉野です。

2014年に新卒でエンジニアとして入社してキャリアを積み、現在はDOOH（屋外広告）チームでシステム設計やメンバーのタスク管理等を行っています。

今回はGENIEEで運営しているサービスに関する話題として、システム上重要な位置を占める電子メールについて書かせていただきます。

Contents

１　システムからメールを送信するということの難しさ

２　SPFとDKIM

３　設定のうっかりミス防止のために

１　システムからメールを送信するということの難しさ

カジュアル・プライベートなコミュニケーションではLINEやWeChat、Messengerなどのチャットツールが主流になってきているとはいえ、業務分野のコミュニケーションではまだまだ電子メールが駆逐されるには時間がかかりそうな昨今、GENIEEのシステムでも電子メールは大変多くの領域で使用されています。具体的に挙げてみますと、マーケティング領域のプロダクトではエンドユーザーさんに送信する種々のお知らせはまだまだメールが主体となっていますし、私が現在所属しているDOOH部門では、広告枠の購入通知やコンテンツ審査の結果など重要な内容がシステムからメールで届くようになっています。

このように業務システム上とても重要なメール送信機能ですが、同時にとても厄介な側面を有しています。皆さんご存知のスパムメール問題です。大手のメールサービス（Gmail、Outlook等）やキャリアメールは、様々な基準でスパムとみなしたメールを容赦なく叩き落とす（迷惑メールボックスにすら入らない）のですが、この判定にひっかかってしまうと、送信側から見ると送信処理自体は成功しているのになぜか送信先にメールが届いていない、という状況に陥ります。

エンドユーザーさんに送られるべきマーケティングメールや、システム利用者様へシステムからの重要な通知メールが届かないとなれば、それは重大なインシデントなので絶対に避けなければなりません。これを避けるためにメール送信部分のプログラムにも確認の必要な箇所はいくつかありますが、特に見落しやすい部分として、DNSでの設定があります。

２　SPFとDKIM

メールの送信元が詐称されていないかを確認するためのDNSの仕組みとして、SPFおよびDKIMがあります。

SPFは、メールの送信元サーバのIPアドレスがどうあるべきかを規定します。例えばDOOHシステムにおけるSPFの設定は以下のようになっています（ドメイン名およびIPアドレスはダミー）。

dooh-geniee.jp. TXT v=spf1 ip4:123.45.67.89 -all

これは、「送信元ドメインがdooh-geniee.jpであるメールアドレスは、送信元のIPアドレスが123.45.67.89であれば受信し、それ以外は全て受信を拒否して欲しい」という設定です。このように設定しておくことで、送信先であるメールサービスに対し、dooh-geniee.jpは（送信元のIPアドレスが123.45.67.89であれば）送信元として信頼できるということを伝えることができます。

DKIMは、メール送信時にメールのヘッダに電子署名を施し、その署名を検証するための公開鍵をDNSのレコードに公開しておくことで、送信先であるメールサービスに対し「電子署名の検証が通ったならば、それは確かに我々が送信したものだ」ということを伝える仕組みです。性質上鍵ペアを事前に作成しておく必要があります。具体的なDNSの設定値は公開鍵をBase64化したものであるので省略しますが、こちらも正しく設定し、メール送信時に対となる署名鍵で署名を施す設定をしておけば、送信元としての信頼性が向上します。

これらの設定は、メール送信自体を外部サービス（Amazon SESやSendGrid等）に委任していても必要となります。外部サービスに委任している場合は、設定が必要なレコードの値や、DKIMのための鍵ペアなどはサービスの方で用意してくれるため、その設定を正しく管理下のDNSに登録すればOKです。

３　設定のうっかり防止のために

これらの設定について問題となってくるのは、特にシステム移行時です。メールを送信するサーバのIPアドレスが変更となった、サービスブランドの刷新のためにドメイン名を変更した等のタイミングで、DNSに登録した情報と実際の状態が乖離を起こすと、それまで送信されていたメールが届かなくなってしまうことになります。このようなことを防止するためにも、「メールが関わるシステムにおいては、ドメイン名やIPアドレスの変更が入る場合は、SPFやDKIMまわりのレコードも確認する」という管理体制を作る必要があるでしょう。

昨今はインフラまわりの設定はクラウドに投げてしまうことも多いですが、今一度、システムの円滑な稼働に必要なインフラ設定をしっかり整理しておくのも、障害を未然に防ぐ観点では大切な仕事です。

正直な話、メール（SMTP）に代わるメッセージプロトコルが早く標準化して欲しいですね。

一緒に働く仲間募集中！

【ジーニーのリクルートサイトはこちら】

こんにちは、R＆D本部2019年卒エンジニアの浅井です。
マーケティングテクノロジー開発部MAJINグループでエンジニアをしています。
今回は、オンプレ上にあるHadoop環境をAWSに移行した話をしようと思います。

浅井迅馬／京都大学工学部卒業後、2019年にジーニーに入社
R&D本部マーケティングテクノロジー開発部・MAJIN開発チーム所属

Contents

1　オンプレ上の旧クラスタについて
2　AWS上の新規クラスタについて
3　おわりに　改善できた点・できなかった点

1　 オンプレ上の旧クラスタについて

私の開発しているMAJIN(マーケティングオートメーションツール)というプロダクトでは、2016年からオンプレ環境にて構成されたHadoopクラスタを用いて、エンドユーザー行動ログの集計を行っています。
旧クラスタの構成は以下です。

■ハードウェア

クラスタはCloudera Managerを用いて管理されており、Cloudera Managerだけが立っているサーバー(cloudera)が1台あります。
Hadoopクラスタに対する問い合わせを行えるようなGatewayとなるサーバー(client)が2台、コアノードと呼ばれるようなサーバー(core)が19台、マスターノードと呼ばれるようなサーバー(master)が2台の全24台で構成されています。

■アプリケーション

・CDM/CDH
・HBase
・HDFS/YARN
・Zookeeper
・Spark2
・Java
・Scala
・Digdag

MAJINではHDFS及びHBaseをデータレイクとして扱っており、MapReduceやSparkでそれらの集計を行っています。ジョブのスケジューラーとしてはcronとDigdagが使われています。

■アーキテクチャ

旧クラスタの概略を図示すると、以下のようになっています。

td-agentからHBase/HDFSにエンドユーザーの行動ログが流れてきます。そして、clientサーバーにてDigdag/cronを契機にそれらを集計するMapReduce/Sparkが走ります。
この旧クラスタで行われる集計は約30のMAJINの機能に関わっており、約60個のジョブが動いています。

さて、旧クラスタでは以下のような問題を抱えていました。

複雑化したclientサーバー
・Hadoopクラスタへの問い合わせが行えるということで、clientサーバーは様々な用途に使われてきました。
・MapReduceやSparkジョブのサブミット
・ジョブのスケジューラーが動いている
・cron及びDigdag
・ジョブのタスクランナーが動いている
・cronで定期実行される自社製タスクランナー
・Hadoopクラスタへのアドホックな問い合わせ
・MapReduceやSparkジョブのビルド
・Hadoopと関係のない謎のデーモン
clientサーバーは数年間「便利」に使われてきており、このサーバーが停止したらどうなるのかとを想定することすら難しい複雑な環境になっていました。

自社製タスクランナー
このクラスタを立ち上げた時から、cronと自社製のタスクランナーを合わせたジョブワークフローを利用しています。このタスクランナーはPerlで書かれており、さらにPython2系に依存しています。現在MAJINチームではPerlを読み書きできる人間がおらず、またPython2系はEOLを迎えていることから、この自社製タスクランナーのメンテナンス性が問題視されていました。

無駄の多いクラスター
前述の通り、このクラスター上では HDFSやHBaseといったデータレイクからYarnで管理されたジョブまで様々なHadoop周りのコンポーネントが動いています。
すべてが1つのクラスターで動いていることから、負荷が重なるとお互いにリソースを奪い合ってしまう可能性があります。もちろんYarnが完全にHDFSやHBaseのリソースを奪うということはなく、考えられる負荷の上限に合わせたクラスタ構成になっていますが、その分無駄も多くなってしまっています。

こうした問題がある中、2021年7月にクラスタを構成している大部分のサーバーの保守が切れるという事態が発生しました。
そこで、まず移行先として既存のオンプレ継続・IDCF・GCP・AWSと4つの選択肢が挙げられました。そして、移行の要件としては、既存の機能をそのまま移せること、移行自体のコストが小さいこと、移行後の保守コストが既存よりも下がることなどが求められていました。
それゆえに、可能な限りミドルウェア等の管理が不要でかつ既存のMapReduce・Sparkの資産が活かせる環境としてGCP・AWSが残り、最終的に既存のアプリケーションがAWS上で動作していることからAWSを選定しました。またAWSでデータの集計基盤を作るとしても様々な案が考えられますが、今回は移行自体のコストを下げるということで、Athenaなどは使わずAmazon EMRクラスタへ移行する計画が練られ、実行されました。

2　AWS上の新規クラスタについて

新規アーキテクチャの概略図は以下になっています。

大きな変更点としては、1つのクラスタ上で行われていたことを分離しました。
HDFSをS3に、HBaseをEMRクラスタに、MapReduceやSparkを実行するクラスタはSpot Fleetを用いて必要なときに必要な分のEMRクラスタを起動するように変更しました。
またclientサーバーはGatewayの役割だけをもつサーバーとタスクを実行するサーバーに分離しました。それに伴い、自社製タスクランナーを廃止しDigdagに統合しました。

この移行はまずtd-agentからのログをAWSへも転送させるところから着手しました。td-agentからKinesisへはfluent-plugin-kinesisを、HBaseへは既存の自社製pluginを使用しました。
続いてcronからDigdagへの移行に移りました。これによってタスクランナーとスケジューラーが別れて管理されていた問題が解消されました。また自社製タスクランナーにはなかった並行処理の機能や管理画面など、実行速度や運用面においても改善されました。
最終的な切り替えにあたっては処理を冪等に修正し、万が一誤ったデータを書き込んだとしても差し戻せばすぐに修正できる状態にすることで、無停止での移行を実現しました。

しかし、移行もスムーズに行えたわけではありませんでした。例えばDigdagのemrオペレーターはステージングディレクトリにusリージョン以外のS3バケットを指定できないというGitHub上のIssueに気づかず、バケットをusリージョン以外に作ってしまったため作り直しを行いました。他にもDigdagのemr-fleetオペレーターが存在しますが、今回利用にあたってステップの並行実行数やAllocation Strategyの設定ができなかったことから、必要なオプションを設定できるようにしました。

3　 おわりに

この移行によって様々なメリットを得ることができました。
■Digdagによる集計アーキテクチャの一本化ができました。
■タスク実行クラスタの自由なプロビジョニングができるようになりました。
■継続して管理が必要なクラスタはHBaseのみになりました。

しかし、まだまだ課題が残っています。
■Digdagのタスクを実行しているサーバーは1台しかなくSPOFになっています。
・Ansibleによる構成管理を行っているため、すぐに復旧可能な状態ではありますが、今後はDigdagで可能なHA構成にする予定です。
■インフラの構成管理ができていません。
・本番環境は手動で作ってしまいました。
・ステージング環境からCloudFormationでの管理を行っています。

移行にあたって協力してくださったAWSソリューションアーキテクトの方々に、心から感謝申し上げます。
今後オンプレHadoopクラスタをAWSなどのクラウドサービスへ移行することを考えている方々の参考になれば幸いです。

一緒に働く仲間募集中！
【ジーニーのリクルートサイトはこちら】
https://geniee.co.jp/recruit/