ID:62798さん

# プロジェクト概要 400万MAUのC向けWEBサービスの利用者拡大と購買データの蓄積およびCRMを目的とした、事前決済機能の新規構築と、その後の保守運用およびエンハンス。 企画から開発の上流～下流までリーダーとして携わり、C向けB向けの両方の課題解決のために開発を行いました。 ## 背景と課題 弊サービスではもともとクーポン機能を提供していましたが、利用数は現地スタッフによる手動カウント＆報告ベースで計測しており、正しくコンバージョンを追跡できない状態でした。また、ちょうど同時期に、競合サービスが事前決済機能で事業拡大をしていました。 データ蓄積と活用、競合サービスへの対抗策として、事前決済機能の導入を企画面から提案していきました。 ## 担当 - 企画 - PM - 開発TL ## メンバー 10名 - 企画 兼 PM: 2名(私) - デザインチーム: 2名(アウトソース) - デザイナー 兼 ディレクター: 1名 - フロントマークアップ: 1名 - エンジニア: 3～5名(アウトソース) - 営業 兼 カスタマーサクセス: 2名 --- # 使用技術・ツール - 調査・企画 - Google Analytics, Google Search Console, DemandMetrics, Keywordmap, Confluence, Figma - プロジェクト管理 - JIRA, GitHub Projects - 開発 - バックエンド：Java, Spring Boot, Spring Security, Struts, Apache, Tomcat, Node.js - フロントエンド：Thymeleaf, JSP, Velocity, EJS, HTML5, SCSS, jQuery - インフラ：AWS(Route53, VPC, ALB, ECR, ECS, Aurora MySQL, S3, Lambda, API Gateway, Kinesis, CloudFront, CloudWatch, 他) - データ： Treasure Data, Sentry(Self-host), Redash --- # 取り組み 企画、要件定義、基本設計、詳細設計、開発マネジメント、実装、データ分析を担当しました。 ## 企画、要件定義 - 別の企画メンバーとともに施策立案。 - SWOT分析 - STP分析 - 損益分岐点試算 - 経営層提案/交渉 - 要件定義 - 複数の決済代行サービスを比較検討し選定。 - 競合サービスを分析し、C向けのUXとワイヤーの提案。 - 営業・CSと相談し、B向け管理画面に必要な機能の洗い出し・優先順位付け。 - 経理処理と運用フローを整理。 - 法務確認や利用規約の改定。 ## 基本設計、詳細設計 ### 初期リリース - 機能概要：店舗ごとに複数のeチケットを販売でき、購入したeチケットはマイページから利用・キャンセルできる機能 - バックエンド：トークン認証、クリーンアーキテクチャ、決済代行システムとの連携、レガシーシステムとの連携、伝票検索 - フロントエンド - C向け：店舗一覧・詳細、eチケット一覧・詳細、購入画面、購入完了画面、マイページ（未利用・利用済み・キャンセル済み・期限切れ） - Ｂ向け：eチケット登録画面・編集画面、eチケット一覧・詳細、売上ダッシュボード、伝票検索 - インフラ：決済管理DBスキーマ、トランザクション、デプロイパイプライン、エラー監視・通知 ### エンハンス：ASP機能 - 機能概要：店舗公式サイトからのみ遷移できる店舗専用販売ページを提供 - バックエンド：販売手数料の振り分け - フロントエンド：導線設計、eチケット一覧・詳細、購入画面、購入完了画面 ### エンハンス：予約機能 - 機能概要：特定の日付に対して在庫数を決めてeチケットを販売し、購入したeチケットはマイページから利用・キャンセルできる - バックエンド：在庫管理、前日売り止め、キャンセルポリシー設定 - フロントエンド - C向け：日付指定予約画面（FullCalendar） - B向け：在庫登録・編集・削除画面、営業時間・休業日設定画面 - バッチ：予約日リマインダーメール、臨時休業時の一括キャンセル ### エンハンス：外部サイト連携 - 機能概要：大手検索エンジンやニュースサイト向けに、データフィードを提供 - バッチ：ETL設計、導線設計、運用設計 ### エンハンス：買取販売機能 - 機能概要：店舗からeチケットをバルクで買い取り、弊サービス側で販売する機能 - バックエンド：有効在庫・実在庫管理、決済の向き先の振り分け - フロントエンド：買取商品管理画面、買取ロット登録画面、買取商品eチケット紐づけモーダル - インフラ：買取商品DBスキーマ ### エンハンス：ギフト機能 - 機能概要：ユーザーが購入したeチケットを別のユーザーにプレゼントできる機能 - バックエンド：受取りURL生成、受取り中のロック - フロントエンド：受取り画面、受取り完了画面 - インフラ：持ち主管理DBスキーマ、受取り管理DBスキーマ ### エンハンス：QR入場機能 - 機能概要：スタッフによる手動もぎりではなく、店舗端末で自動もぎりできる機能 - バックエンド：店舗端末用API（トークン認証、ロック、商品引き当て） - フロントエンド：QRコード生成 ## 開発マネジメント 詳細設計までは社内で行い、コーディングやテストといった開発業務は外注。 進捗管理、技術的な質問の対応、コードレビュー、ドキュメントレビューを行いました。 ## 実装、テスト 初期リリース、ASP機能、外部サイト連携など、外注側の遅延があった部分は自ら実装を行いました。 ### データ分析 購買データをプロダクトDBからS3→Treasure Dateへインポートし、Redashでダッシュボードを作成してマーケチームに提供しました。 私自身もデータ分析を行い、売上と利益の推移やユーザー属性ごとの購買行動の傾向を整理し、次の施策の提案を行いました。 --- # 成果 - 月あたり3～5万件の購入・利用、これによる売上貢献。 - 購買データの蓄積と活用し、次の大型施策の検討具体化に貢献。 # 工夫した点 - 企画・開発・営業・経営層・決済代行サービス担当者(外部)、店舗端末担当者(外部)と関係者が多いため、SlackチャンネルとConfluenceドキュメントを整備して、情報非対称性が無いように進めました。 - 各方面からやりたいことが無数に発生するため、目的と効果予測に立ち返りながら、優先順位とスコープを調整しながら進めました。 - 決済に関わる機能のため、既存のセキュリティリスクを解消しながら、進めました。 - 設計の段階で上長と認識を密に合わせながら進めることで、手戻りを極限まで減らしました。 - 実装についてバックエンドとフロントエンドを並行して進められるよう、モックデータを用意しながら進めました。 - 営業チームと協力して正式ローンチ前に検証店舗を3店舗用意し、懸念点や考慮漏れを解消できる期間を設けました。

# プロジェクト概要 CtoCで投げ銭を行える新規サービスの立ち上げ。 ファンがインフルエンサーに対して投げ銭付きの投稿を行えるWEBアプリケーションを開発します。 現在進行形のプロジェクトです。 ## 背景と課題 未リリースのため詳しいことは書けませんが、投げ銭市場が拡大していることを受け、そこに新たな切り口で参入していこうということでサービスを立ち上げる運びとなりました。 知り合いから声をかけていただいたため、副業として参画することにしました。 ## 担当 - バックエンド おもにバックエンドの要件定義、詳細設計、コーディング、テストを担当しています。 データ設計やフロントエンドとの繋ぎこみなど、企画・デザイン・フロントマークアップ以外のすべてをカバーしています。 ## メンバー 2名 - PO 兼 PM 兼 デザイン 兼 フロントマークアップ: 1名 - バックエンドエンジニア: 1名(私) --- # 使用技術・ツール - プロジェクト管理 - Trello, Slack, GitHub Issues - バックエンド - Java, Spring Boot, Spring Security, JPA, Spring Batch, Stripe API, Twitter API, OAuth1.0, Rest API, JWT - フロントエンド - HTML5, CSS3, Sass, BEM, thymeleaf, Vue.js, Vanilla JS, Axios, imgix - インフラ - Heroku, Cloudflare, SES - 分析 - Google Analytics, Microsoft Clarity, OWASP ZAP, Papertrail --- # 取り組み ## 要件定義、技術選定、詳細設計 - ビジネスサイド担当者から実現したいことをヒアリングし要件に落とし込み、それを最低限のリスクとコストで実現するための設計を提案していきました。 - インフラ構築を低コストでショートカットするためにIaaSであるHerokuを採用しました。Herokuはスケーリングやアドオン適用も容易なので、低コストで走り始めるには最適だと判断しました。 - 決済サービスにはStripeを採用しています。今回実現したいマネタイズモデルを実現可能そうであること、C向けの知名度の高さとドキュメントの豊富さから採用を決定しました。 - その他、imgixやCloudflareなど、低コストでパフォーマンス向上を狙えるSaaSを導入しています。 ## バックエンド開発 - SpringのRestTemplateを用いてTwitterAPIでOAuth認証を行い、SpringSecurityのPre-Authenticationに認証情報を渡すことで、TwitterアカウントでのSSOログインを実現。 - ユーザーごとにファン権限、インフルエンサー権限、管理者権限を付与し、投げ銭を受けられるかを制御。権限はSpringSequrityで管理。 - StripeConnectとStripeElementを用い、ファンがカード情報の入力だけでインフルエンサーに投げ銭を行えるフォームを実装。 - imgixと連携し、投稿内容を踏襲したOGPを動的に生成。 - SpringBatchを用いて、毎月末にStripeConnectからインフルエンサーの銀行口座へ送金。 - 投稿や送金でSpringEventを発火し、SMTPでSESをトリガーして通知メールを送信。 - Heroku Pipelineで検証環境と本番環境へのCDを実現。 - Papertrailを用いてログ監視。 ## フロントエンド開発 - もう1名に組んでもらったマークアップにthymeleafとVue.jsで処理を加え、要素の出し分けやインタラクティブな表現を実現。 --- # 工夫している点 - 車輪の再発明を行わないようにしています。IaaSやSaaSなど使えるものは積極的に使い、これによりローンチまでの期間とコストを削減しています。 - Herokuは日本リージョンを持っていないためTTFBが長くなりがち。静的コンテンツをCDN経由で配信することで高速化を図っています。 - メールサービスは、SendGrid, MailerToGo, CloudMailIn, Mailgun, Amazon SESから、想定送信数において最もコスパの良いSESを採用しています。 - エンジニアが一人かつ副業なので馬力に不安がありましたが、価値検証のために必要な箇所を洗い出して仕様をシャープにすることで、検証までのリードタイムを数ヶ月ほど縮めました。

# プロジェクト概要 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化しコードで管理できるように整えています。