ID:62798さん

# プロジェクト概要 300万MAUのC向けWEBサービスのオーガニック流入増を目的とした、20万MAUのサテライトメディアサイトのSEO対策プロジェクト。 昨今のSEOにおいて重要性が叫ばれているEATとCWVの対策と主とした、情報の質向上と構造整理を含めた開発を行いました。 ## 背景と課題 2021年中旬のGoogle検索アルゴリズムのコアアップデートの影響を受け、弊サービスはGoogle検索の平均順位を大きく落としました。 そこで、本体サイトのSEO対策と並行してサテライトサイトのSEO対策も行う運びとなりました。 ## 担当 - 企画 - PM 行うべきSEO対策をもう１名の企画メンバーとともに洗い出し、要件定義と詳細設計を行い開発担当者へお渡しする業務を担当しました。 ## メンバー 6名 - 企画 兼 PM: 2名(私) - デザインチーム: 2名(アウトソース) - デザイナー 兼 ディレクター: 1名 - フロントマークアップ: 1名 - バックエンドエンジニア: 2名(アウトソース) --- # 使用技術・ツール - 調査・企画 - Google Analytics, Google Search Console, Page Speed Insights, DemandMetrics, Keywordmap, SimilarWeb, Confluence, Figma - プロジェクト管理 - JIRA, GitHub Issues - 開発レビューを行っている技術 - サーバサイド：Java, Struts, Apache Tomcat, JSP, Velocity - フロント：HTML5, CSS3, jQuery - インフラ：Route53, VPC, ALB, EC2 --- # 取り組み 企画、要件定義、詳細設計、開発マネジメントを担当しました。 ## 企画、要件定義、詳細設計 - 別の企画メンバーとともに施策立案。 - ドメイン移行 - EATを主張するためのArticle構造化データマークアップ - パンくずリストの論理構造の変更 - CLSの対策 - その後、要件から詳細設計までまとめました。 - レガシーな環境であることによりテーブルのリレーションを組めないという制約のもと、新たに加えるべき要素のデータ構成を設計。 - レガシーな環境であることによりServletに変更を加えることができないという制約のもと、Viewのみで吸収可能な要件に分解して実装方針を提案。 ## 開発マネジメント - 詳細設計までは社内で行い、コーディングやテストといった開発業務は外注。その進捗管理と技術的な質問の対応を行っていました。 - 早めに効果が表れるようにするために、プロジェクトを5つほどのフェーズに分割し細かくリリースを行う方針で進めました。 - そのうち何度かは見積もった工数から溢れることがあり、リリースを数日遅らせる事態が発生しました。遅れが発覚した時点で企画メンバーおよびステークホルダを招集し状況を共有したことで、運用委託会社や関係各所への影響を未然に防ぐことができました。 --- # 成果 - 全リリースが完了後、3ヶ月連続でオーガニック流入数が30%増。 # 工夫した点 - SEOの効果が早く現れるように、リリースを細かく分割し、サイトマップ送信やクロールリクエスト提出を駆使しました。 - SEOの効果が早く現れるように、レバレッジの効きやすい施策から優先的にリリースを行いました。レバレッジの効きやすさを判断するために、別プロダクトを担当しているSEOスペシャリストへ能動的に相談しに行きました。

# プロジェクト概要 社内のB向け営業担当者が利用する業務ツールを作成しました。 営業対象企業のうち営業商品に興味関心がありそうな企業を捕捉しSlackにリアルタイムで通知することで、営業の確度を向上させることを目的としたツールになります。 ## 背景と課題 1営業担当者1日あたりの架電数を通常時の3～5倍に増やす必要のある案件が発生しました。この目標は現実的に無理があるという意見が現場から挙がっていました。 KPIを分解していくと、実際に目指すべきは架電数ではなく成約数であり、アタックリストの中でもより成約確度の高い企業から攻めていけば成約数の目標は達成できそうだということが見えてきました。 そこで私は自ら手を挙げ、より確度の高い企業を検知して営業担当者に通知するツールを短期で作成することを申し出ました。 ## 担当 - 企画 - 要件定義 - 設計 - コーディング - テスト 企画からリリースまで一気通貫で担当しました。 ## メンバー 1名(私)+営業チーム --- # 使用技術・ツール - スクリプト - Google Apps Script, Treasure Data, Bitly - UI - Spreadsheet, Redash, Slack --- # 取り組み ## 企画、要件定義 - 営業効率を上げるツールが欲しい！というビジネスサイドの大雑把な要求を汲み取り、ソリューションを提案しました。 - 「効率を上げる」を具体的に言語化し、「営業商品に関するDMに反応し、LPにアクセスしてくれた企業を捕捉する」と再定義して要件定義を進めました。 ## 詳細設計、コーディング - Spreadsheetで営業対象アタックリストを管理してもらい、BitlyAPIを用いて検知用URLを生成。そのURLを営業対象企業宛てのDMに記載する。 - そのURLでLPにランディングするとPVイベントをTreasureDataに送信するようにJSを設置。 - アタックリストの内容を定期的または任意のタイミングでTreasureDataにInsertするスクリプトを作成。 - PVイベントデータとアタックリストデータを含むTreasureDataをRedashで集計し、これまでのランディング履歴と直近10分のランディング履歴を可視化。 - 可視化した一時テーブルをもとにRedash Alertをトリガーし、Slackの営業担当者へメンション付きで通知。 --- # 成果 - 最終的にはこれを使って営業目標を達成することができました。この功績は現職社長にも認められ、その月の月間MVPとして表彰をいただきました。 - 汎用性を持たせて作ったため、この営業案件が終了した後もいくつかの場面で活用され続けています。 # 工夫した点 - 既存のツールを組み合わせることで工数を削減し、テストを含めて5日程度に実用可能な営業促進ツールを作成しました。 - 営業担当者が使い慣れているSpreadsheetやSlackをインタフェースとすることで、営業担当者側の導入コストを削減しました。 - 対象企業ごとに営業担当者が決まっているため、その営業担当者へのメンションを含めることで実用性を向上しました。

# プロジェクト概要 300万MAUのレジャーWEBサービスにおいて、レジャー施設のランキング企画と行うためにWEB上でユーザーが施設に投票を行える機能を構築しました。 ## 背景と課題 ランキング企画は毎年開催されます。これを毎度昨年以上に盛り上げることが課題となります。 投票というかたちでランキング根拠にユーザーからの評価を含めることによりユーザー参加型の企画となりつつ、施設側からユーザーに向けてアクションを呼びかけるような動きも生まれ、双方向に盛り上げあうスキームを実現できることから、この年は投票機能を新規で開発する運びとなりました。 ## 担当 - フロントエンド - バックエンド フロントの処理からAPIの開発まで行いました。 ## メンバー 4名 - PM: 1名 - デザイナー 兼 クリエイティブ: 1名 - フロントエンドエンジニア 兼 バックエンドエンジニア: 1名(私) - インフラエンジニア: 1名 --- # 使用技術・ツール - プロジェクト管理 - JIRA, Confluence - フロントエンド - HTML5, CSS3, jQuery, Ajax, JSP, Google Optimize, Google Analytics - バックエンド - Java, Struts, Apache Tomcat, JSP - インフラ - API Gateway, Dynamo DB --- # 取り組み - 全体設計とインフラの構築はインフラエンジニアの方にお任せし、私はフロントエンドとバックエンドの詳細設計およびコーディングをメインで行いました。 - リリース後の改善業務も積極的に行いました。 ## 設計 - レガシーな環境であることによりServletに変更を加えることができないという制約のもと、View(JSP)のみで吸収可能な要件に分解して実装方針を提案。 - AWS SDKの導入が困難であるため、API Gateway経由でDynamoDBに投票データをPutする構成を採用。 - クライアントから直接API Gatewayを叩かれることを避けるため、JSPでAPI GatewayをラップするAPIを作成。 ## フロントエンド - 投票ボタンのクリックイベントをリッスンし、Ajaxを用いてJSP APIを叩く。 - ログイン状態によって、インタラクティブな表現を変更。未ログインであれば、ログインまたは会員登録を勧奨するモーダルを表示、既ログインであればAPI Gatewayを叩きに行き投票完了の旨を表示。 - 投票数の最大化のためのエンハンスを行いやすくするため、Google Optimizeを初導入。 ## バックエンド - JSP上でセッション情報を解析し、ログイン状態を判定。 - HttpClientを用いてAPI Gatewayに投票データをPost。 --- # 成果 - リリース後のエンハンスも含め、ユーザーからの投票数を10万票獲得(目標達成)。また、企画開催期間中の会員登録者数が平常時の2～3倍程度に増加。この功績は現職社長にも認められ、その月の月間MVPとして表彰をいただきました。 # 工夫した点 - botによる不正投票を見越し、リクエスト元IPをハッシュ化し記録するようにしました。案の定、リリース後に同一IPからの不審なリクエストを検知でき、そのリクエスト元が海外IPであることが分かったため、WAFで国外IPからの投票リクエストを遮断する対策を打てました。 - Google Optimizeを用いて、デザイン・CTA・アニメーションのA/Bテストを3回経て、投票ボタンのCTRを2%台から3%台へ向上させることができました。

# プロジェクト概要 300万MAUのWEBサービスにおいて会員の活性化を図るための、コンバージョンを起点にステップメールを送信するシステムの新規開発、およびその後の保守運用。 サーバレスで構築し、保守運用負荷を低減します。 ## 背景と課題 月間300万UUの流入に対し、リピーター、特にコンバージョン後のリピーターが少ないという課題がありました。 コンバージョンから一定期間後にメールによるリテンションを行えないかということで、このプロジェクトが発足しました。 ## 担当 - バッチコーディング - 運用 - 保守 新規開発時には、コンバージョンログの集計バッチのコーディングを担当しました。 その後、たびたび不具合が生じるため、全体のロジックや設定のチューニングなどを行っています。 ## メンバー - インフラエンジニア: 1名 - バックエンドエンジニア: 4名 - うち2名はOJTとしてジョインしていましたが、研修課程の都合により途中で離脱。 - それと入れ替わりで引き継ぐかたちで私がジョインしました。 --- # 使用技術 - プロジェクト管理 - 物理カンバンボード, Confluence - インフラ - Lambda, Step Functions, Cloud Watch, SNS, Chatbot - バッチ(Lambda) - Node.js, Treasure Data API, Cloud9, Lambda Layers, SAM --- # 取り組み - Step Functionsは大きく4種のバッチを組み合わせた構成になっていました。 1. TreasureDataからコンバージョンログを集計するバッチ 1. 集計されたログから送信対象者を抽出し、送信者情報を取得するバッチ 1. 集計されたログからコンバージョンポイントを抽出し、レコメンド内容を作成するバッチ 1. 上記の情報をマージし、CSVを作成して外部のメールシステムにPostするバッチ - 私はこの中で1のバッチのコーディングを担当しました。 ## コーディング - 処理 - TreasureDataに格納されているコンバージョンログのうち、現在からn日前に発行されたものを取得。 - 取得できたJSON文字列をパースし、必要な項目のみを抽出して整形。 - 整形したデータを次のステップのバッチに渡す。 - TreasureData用のモジュールをLambda Layersに切り出し。 - 該当のLambdaをSAM化。 ## 保守運用 - 会員数の増加に伴い、送信者情報の取得やレコメンド内容の生成に時間がかかることが増えてきたため、タイムアウトの調整等を行い失敗の発生を抑えました。 - 予期せぬエラーでバッチが落ちることがあったため、検知を早めるために、エラー発生時にCloudWatchAlarmでSNSトピックをトリガーしてChatbot経由でSlack通知を行うようにしました。 --- # 工夫した点 - TreasureData用のNodeモジュールを生で配置すると、データ容量が大きすぎてAWSコンソール上でLambdaのコードを参照できない事象が発生しました。Cloud9からは参照可能でしたが、無駄な費用がかかる且つ環境の立ち上げが煩わしかったため、Lambda Layersにモジュールを移すことでこれを解決しました。 - Lambda Layersの活用は社内で初めてだったため、知見が無いなかでドキュメントを読み解き導入を進めました。 - 導入後、導入方法のドキュメントを残しつつ、社内のLTで知見を広めました。 - 入社1年目でAWSの知識が浅い状態ではありましたが、積極的にLambdaのコード管理を試みました。 - 先輩方が担当された2～4のバッチはコード管理がなされていない状態でしたが、私の担当した1のバッチについては勉強も兼ねてSAM化しました。 - その後、保守運用ついでに、2～4のバッチもSAM化しコードで管理できるように整えています。