Wantedly Engineering Handbook
  • Wantedly Engineering Handbook
  • まえがき
  • 第一部:開発チームへの案内
    • 技術とアーキテクチャ
    • プロダクト概要(未執筆)
    • 開発チームの構造
    • コミュニケーションの全体
    • ドキュメンテーション(未執筆)
    • カレンダー
    • 障害対応の心構え
    • 効率的な社内知識の調べ方
    • 外部発信(執筆中)
  • 第二部:技術領域への案内
    • Apps
      • アプリを提供するプラットフォーム
      • デザインシステム入門
      • Web アプリのアーキテクチャ
      • プロダクトデザイナーと上手に協働するための心得
      • Web アプリのデザインシステムライブラリ
      • Web アプリ共通ライブラリ "React Shared Component" の紹介
      • モバイルアプリのアーキテクチャ
      • モバイルアプリのデザインシステムライブラリ(未執筆)
    • The System
      • protobuf スキーマと gRPC 通信
      • 実践: gRPC in Ruby
      • 実践: gRPC in Go
      • GraphQL Gateway - アプリ向けに API を公開する
      • Wantedly Visit で BFF GraphQL サーバーを辞めた理由
      • 実践: GraphQL スキーマ設計(未執筆)
      • API での認可処理 (Authorization)
      • マイクロサービス共通ライブラリ "servicex" の紹介
      • 非同期メッセージング処理入門(未執筆)
      • バッチ処理入門(未執筆)
    • Infrastructure
      • Infrastructure Squad
      • プロダクト開発のための Kubernetes 入門
      • インフラ構成概要
      • リリース・デプロイ戦略を支える技術
      • SaaS を活用する:New Relic, Honeybadger, Datadog
    • Data
      • データ基盤入門
      • レコメンデーション
      • Looker 入門
      • 推薦システムの開発に使っているツール
    • 開発プロセス
      • Git の慣習
      • ポストモーテムの取り組み
      • 負債返済日の取り組み
      • プロダクトの課題発見及び解決
      • ソフトウェアデザインの基礎
      • コードレビュー
      • コーディング規約
      • リリース・デプロイ戦略
      • 上長承認が必要な作業
      • アーキテクチャディシジョンレコード(ADR)
      • 作業ログを残す意味
      • 多言語化対応(i18n)
      • メール開発
    • 開発ツール
      • 社内利用している開発ツールの最新状況
      • kube
      • Code Coverage
      • Kubefork
  • おわりに
    • ロードマップ(未執筆)
    • Handbook の書き方
    • コントリビューター
  • 付録
    • 社内用語集
    • 主要な GitHub レポジトリのリスト(未執筆)
    • 今後の挑戦・未解決イシュー(未執筆)
    • プロダクト開発組織のバリュー(未執筆)
    • 採用についての考え方(未執筆)
GitBook提供
このページ内
  • メールを送信する三つの方法
  • 特定電子メール法に関するガイドライン
  • 見るべきドキュメント
  • 推奨開発プロセス (未執筆)

役に立ちましたか?

  1. 第二部:技術領域への案内
  2. 開発プロセス

メール開発

前へ多言語化対応(i18n)次へ開発ツール

最終更新 8 か月前

役に立ちましたか?

ここでは Wantedly サービスを通じて配信されるメールの開発について解説します。 なお、説明は概要にとどめて細かい実装の詳細などは他のドキュメントで補完していくものとします。

メールを送信する三つの方法

本ドキュメントでは 1 および 2 をスコープとします。3 についてはを別途参照してください。

  1. プロダクトコードに実装する

    • プロダクト機能として継続的に配信する場合はこちら

    • 例. 応募通知メール

  2. 使い捨てのバッチスクリプトに実装する

    • 一度しか配信しない場合はこちら

    • 例. 新機能リリースメール

  3. 専用管理画面から送信する

    • 非エンジニアがメールを送信する際はこちら

    • 例. メルマガ

特定電子メール法に関するガイドライン

プロダクト開発の施策として、企業・ユーザーにメール配信することがあります。エンジニアが各々の判断で配信してしまうと、メール配信が乱雑になったり不適切なメール内容になってしまうリスクがあります。ゆえに、Dev Branch ではルールを設けています。次のことを必ず守ってください。

  • Squad 内の施策としてメール配信をする場合

    • Squad Leader の承認を Must とします

  • 一つの Squad に閉じず、プロダクト横断的にメール配信をする場合 (eg. システムメンテナスなど)

    • 各 Tribe の PdM、システム責任者に事前連絡、Dev Branch Leader の承認を Must とします

    • Dev Branch Leader の承認を Must とします

  • 参考

見るべきドキュメント

  • メール送信処理

  • 送信後の集計

推奨開発プロセス (未執筆)

話を聞きに行きたい

もっと知りたい

経由でメール配信をする場合

Slack:

管理画面からメールを送信する方法 (internal)
過去事例 (internal)
過去事例 (internal)
メール配信システム
迷惑メールの概要について
特定電子メールの送信の適正化等に関する法律
受信設定やレイアウトに関する仕様書 (internal)
メール UI 実装 / メーラーの対応方針 (internal)
実装ドキュメント (internal)
QA テストの方法 (internal)
本番送信の方法(internal)
Looker を用いたメールの分析方法 (internal)
#engineering
https://github.com/wantedly/dev/issues/2286
https://github.com/wantedly/dx/issues/456
https://github.com/wantedly/dev/discussions/2288