こんにちは。サービス開発部/プロダクト開発部門/従業員サーベイチームのエンジニアリングマネージャー、中川優です。

弊社では、ミキワメ適性検査・ミキワメウェルビーイングサーベイ・ミキワメマネジメントなど複数のプロダクトを展開しており、これらプロダクトごとに様々なタイミングでユーザーへの通知が届きます。

2025年初頭、Slack連携機能を追加するための開発が決定し、同年春のリリースを目指して、メールに加えて複数の通知チャネルを安全かつ簡潔に扱う仕組みづくりが課題となりました。

このプロジェクトは無事に2025年春にリリースを迎え、現在では多くのお客様にSlack通知機能をご活用いただいています。 リリースから半年以上が経過した現在のタイミングで、当時の設計思想を振り返ってみたいと思います。

プレスリリース:ミキワメ適性検査、Slack連携機能をリリース

※用語メモ:

• 「受検」は適性検査の受検依頼
• 「サーベイ」はウェルビーイングサーベイにて配信されるアンケート

本記事では、複数プロダクトで統一的なメール・Slack通知を実現するために設計した通知基盤について解説します。

複数プロダクトでの通知チャネル追加の複雑さ​

着手時の状況​

主要プロダクトのそれぞれで、複数の通知機能が存在しています。

• 適性検査: 受検依頼、受検リマインド、受検結果完了通知、など
• サーベイ: 回答依頼、回答リマインド、集計完了通知、など

これらは全てメール通知として実装されており、各プロダクトのコードベースに散在していました。

新たな要件​

Slack連携機能の追加により、以下の要件が発生しました。

• メール通知は従来通り、通知先アカウントに対して必須である
• Slack通知は、企業がSlack連携済みの場合のみに限る

設計上の課題​

単純に、既存の通知実装にSlack送信の処理を追加する案も考えましたが、以下の問題が発生することを容易に想像できてしまい、正直に言うとかなり気が重かったです。

• 通知の実装箇所ごとにSlack連携有無判定チェックが重複（DRYじゃない）
• Slack API周辺のロジックが各プロダクトに散らばり、「どこで何が送られているのか」が分からなくなるカオス
• 送信順序や失敗時の処理が分散され、デバッグ時の確認箇所を増やす羽目になる

解決策：単一の呼び出し口としてのクラスを基盤とする設計​

設計上の課題を解決するため、以下の通知基盤を実装しました。

• 単一の呼び出し口：呼び出し側は1つメソッドを呼ぶだけで、メール・Slack両方の通知に対応できる
• チャネルの透過性：呼び出し側はメールとSlackの技術的詳細の違いを意識する必要がない
• Slack未連携企業でも、メール通知は確実に届くことを担保する

処理フロー​

通知基盤の各メソッドは、以下の流れで処理を行います:

1. メール送信（必須）
2. Slack連携チェック
3. 送信対象のフィルタリング
4. Slack通知本文のメッセージ生成
5. Slack API実行用非同期Job投入

この順序により、Slack送信の成否に関わらずメール通知は確実に送信させることができます。

通知基盤の実装​

※本記事のコード例は説明のため一部簡略化・抽象化しています。

コード構造​

適性検査の受検依頼用のメソッドを例に説明します。

class MultiChannelNotifier
  def send_examination_notification(company_id, recruitment, template, user_ids)
    # 1. メール送信(必須)
    MailService.call(company_id:, recruitment:, template:, user_ids:)

    # 2. 企業のSlack連携設定状況のチェック(オプショナル)
    slack_connection = SlackConnection.find_by(company_id:)
    return unless can_slack_send?(
      slack_connection,
      required: -> { recruitment.target_type.employee? }
    )

    # 3. 送信対象取得
    targets = recruitment.employees.where(id: user_ids)

    # 4-5. メッセージ生成 & 非同期送信
    slack_bulk_send_process(slack_connection, targets) do |employee|
      content = SlackMessageBuilder.call(company_id:, recruitment:, employee:)

      { user_email: employee.email, content: }
    end
  end

  private

  def can_slack_send?(slack_connection, required: nil)
    slack_connection.present? && (required.nil? || required.call)
  end

  def slack_bulk_send_process(slack_connection, targets)
    direct_messages = targets.map do |target|
      message_data = yield(target)
      SlackDirectMessage.new(
        recipient_email: message_data[:user_email],
        content: message_data[:content]
      )
    end

    SlackBulkSendJob.perform_async(
      slack_connection.id,
      direct_messages.map(&:to_h)
    )
  end
end

条件分岐の設計​

can_slack_send? メソッドがチェックする条件は下記の通り。

通知機能固有条件の例:

前述したコード例の recruitment.target_type.employee? の部分が固有条件に相当します。これは、適性検査の受検依頼をする対象者のアカウント種別が自社社員かどうか？を確認していることを表しています。

※ミキワメでは、自社社員の他、新卒候補者や中途候補者などのアカウント種別が存在します。

この設計により、通知機能ごとの細かい条件分岐を柔軟に実装できるようになりました。

Slack通知基盤の詳細​

Slack通知は以下のレイヤー構成で実装しています（名称は簡略化しています）:

MultiChannelNotifier(呼び出し口)
    ↓
SlackSendJob / SlackBulkSendJob(非同期処理)
    ↓
SlackSingleSender / SlackBulkSender(サービス層)
    ↓
SlackApiChat / SlackUsersApi(APIラッパー)
    ↓
Slack::Web::Client(slack-ruby-client gem)

「後から見たときに、どこを直せばいいか分かる構造にしたい」という思いで、責務が明確になるようレイヤーを分離しました。これにより、テストもしやすく保守性の高い設計になったと感じています。

slack-ruby-client gemの選定理由

https://github.com/slack-ruby/slack-ruby-client

• Slack API仕様に準拠したインターフェース
  • chat.postMessageやusers.lookupByEmailなどの要件上必要なメソッドが提供済み
  • TooManyRequestsErrorにretry_after属性が含まれるなど、Slack特有のエラー処理が組み込まれている
• 定期的なメンテナンスが入っており、Star数も1.3k超（2025年12月時点）
• READMEが充実しておりトラブルシューティングがしやすい

slack-ruby-clientを介さず、Faradayで直接実装することも検討しましたが、エンドポイントのパス管理、パラメータの組み立て、エラーレスポンスの解釈などを全て自前で実装・保守する必要があり、保守コストが相対的に高いと判断しました。

※slack-ruby-clientは内部的にFaradayを使用しているため、HTTPクライアントとしてのFaradayの利点は享受しつつ、Slack API特有の処理を抽象化できています。

主要なクラス（名称は簡略化しています）

単発送信 vs 一括送信

Slack APIの呼び出し回数を最適化し、送信対象の人数に応じて2つの方式を使い分けています:

一括送信では、事前にusers.listで全ユーザーを取得し、メールアドレスでマッチングすることで、users.lookupByEmailの呼び出し数を削減しています。

リトライ処理とレートリミット対策​

Slack APIを使用したユーザーへのメッセージ送信には、chat.postMessage というエンドポイントを使用する必要があります。

このエンドポイントのリクエスト制限に至る上限値は公開されていないため、いつ制限に至るか読むことが困難です。そのため、あらかじめレートリミット時のエラーハンドリングを適切に行う必要がありました。リトライ処理を共通化した基底クラスを用意し、ここでリトライ処理を実装しています。

対応するエラー

実装コード例（簡略化しています）

※実運用では、リトライ上限の設定やデッドレターキュー（DLQ）への退避など、ジョブが長時間滞留しないための仕組みも併せて検討することをおすすめします。

class SlackApiBase
  def initialize(credentials:)
    @credentials = credentials
  end

  private

  attr_reader :credentials

  def client
    @client ||= Slack::Web::Client.new(token: credentials)
  end

  def with_retry(method_name:, max_retries:)
    begin
      yield
    rescue Slack::Web::Api::Errors::TooManyRequestsError => e
      # レートリミット: Slackが指定した秒数だけ待機して再試行
      ...
    rescue Slack::Web::Api::Errors::TimeoutError => e
      # タイムアウト: 指数バックオフで再試行
      ...
    end
  end
end

# chat.postMessageへのリクエストを実行する継承クラスでwith_retryを使用するようにしている
class SlackChatApi < SlackApiBase
  def post_message(channel:, text:)
    with_retry(method_name: 'post_message') do
      client.chat_postMessage(channel:, text:)
    end
  end
end

設計のポイント

• レートリミット対応:Slack APIはretry_afterヘッダーで待機時間を指定するため、それに従うことで確実にリトライできます
• タイムアウト対応:一時的なネットワーク障害に対応するため、指数バックオフで再試行します

一括送信時の処理

一括送信では、レートリミットを考慮しつつ効率的に送信するため、以下の方針で実装しています:

• 一定件数ごとにバッチ処理
• 複数スレッドで並列にAPIコール
• 各APIコールはwith_retryでラップされており、エラー時は自動リトライ

この設計により、大量のユーザーへの通知でもレートリミットに引っかかることなく、送信処理を維持することができます。

メッセージ生成の設計​

各プロダクトで、通知種別ごとにメッセージ本文の文字列を戻り値とするSlackMessageクラス（PORO）を配置しています。

各クラスは単一責務の原則を守り、1つの通知種別のみを担当するようにしています。

# モジュラーモノリス構成のイメージ（実際の構成とは異なります）
packs/
├── product_a/app/services/
│   ├── user/slack_message/
│   │   ├── notification_type_1.rb    # ユーザー向け通知
│   │   └── ...
│   └── admin/slack_message/
│       ├── notification_type_2.rb    # 管理者向け通知
│       └── ...
├── product_b/app/services/
│   ├── user/slack_message/
│   │   ├── notification_type_3.rb
│   │   └── ...
│   └── ...
└── ...

この設計で得られたメリット​

1. 呼び出し側のシンプルさ​

新しい通知を追加する際、MultiChannelNotifierにメソッドを1つ追加するだけで、メール・Slack両方に対応できます。

2. 技術的詳細とビジネスロジックの分離​

• 通知基盤クラス:「いつ、誰に通知するか」というビジネスロジックを担当
• Slack送信サービス:「どうやってSlackに送信するか」という技術的詳細を担当

この分離により、Slack APIの仕様変更があっても、通知基盤側の変更は不要です。

今後の課題と改善点​

大規模企業での送信速度と、将来的な新チャネル追加を見据えた拡張性が主な検討ポイントです。

1. エンプラ企業向けの高速化​

現在の実装では、レートリミットを考慮して並列数を抑えて送信していますが、実装時の計測時は100通弱程度から制限がかかることが多かったです。したがってエンプラ規模の企業では通知完了までにかかる時間が増大してしまう可能性が残っています。

今後の改善案として、並列処理のスレッドごとにSlack Appを割り当てるなど、インフラ側でのスケーリング前提の対応なども検討する必要があります。

2. 通知基盤クラス自体のリファクタ​

現在はメールとSlackのみですが、今後Microsoft TeamsやLINE WORKSなど、他のチャネルへの対応も考えられます。

その際は、以下のような設計変更を検討する必要があると考えています。

• チャネルごとのStrategyパターンの導入
• 通知設定の柔軟な管理(企業ごとに有効なチャネルを選択可能に)

まとめ​

本記事では、複数プロダクトで統一的にメール・Slack通知を実現する通知基盤について解説しました。

この設計により、以下を実現できました:

• 呼び出し側のシンプルさを保ちながら、複数チャネルへの通知を実現
• slack-ruby-clientを活用した安定的なSlack API連携
• Slack APIの技術的詳細を隠蔽し、保守性を向上
• Slack未連携企業への影響なし

正直なところ、レートリミットの挙動が読めない中での実装は特にきつさを感じました...！公式ドキュメントには上限値が書かれていないため、「100通目くらいで制限がかかるな」「並列数はどの程度なら安定するか」といった感覚を、実際に送信テストを繰り返しながら掴んでいく必要がありました。この試行錯誤の部分が、特に苦労したポイントです。

抽象化を目的としたクラスを設けたことで、各プロダクトのビジネスロジックとSlack APIの技術的詳細の直接的な依存を避けることができました。この設計判断により変更容易性が大きく向上し、リリース後も新しい通知種別の追加がスムーズに行えています。

今後も、ユーザー体験を向上させるため、通知基盤の改善を続けていきます！

初めまして、中川優(すぐる)と申します！サービス開発部/プロダクト開発部門/従業員サーベイチームのプロダクトエンジニアです！

仕事で使用している主な言語はRuby・TypeScriptです。個人的にGolangあたりを最近触ったりしています。趣味はヘヴィメタルです。

今回は、当社プロダクトの一つであるミキワメウェルビーイングサーベイが過去に直面した、閲覧範囲制御機能のパフォーマンス上の課題、および改善に至るまでの事例をご紹介いたします。

ミキワメウェルビーイングサーベイとは？​

心理学・行動科学の知見に基づき従業員のウェルビーイング（幸福度）を測定・分析する、実名性の”パルスサーベイ”ツールです。

• 短時間の回答(3分間)によって、即座に回答結果・アドバイスを確認できる
• 個人の性格に基づいた、ウェルビーイング向上のためのアドバイスを提供
• 組織全体の回答結果を可視化し、組織単位でのアドバイスも受けることができる

詳しくは下記もご覧ください。

『ミキワメ ウェルビーイングサーベイ』とは？社員の幸福度を高め離職・休職を防ぐ｜ミキワメラボ

閲覧範囲制御機能とは？​

ミキワメでは大きく分けて2つの画面を提供しています。

1. 従業員向け画面：従業員が自身の回答結果を閲覧するためのページ
2. 企業向け管理画面：企業担当者が組織・各従業員の回答結果を閲覧するためのページ

閲覧範囲制御は、この内の企業向け管理画面における新機能として、2024年5月30日にリリースされたアップデートです。

アップデート前​

企業向け管理画面のログインユーザーでは複数の権限が存在し、その中に”マネージャー”という権限があります。マネージャーは、特定の部署・および部署に所属する従業員のサーベイ回答結果のみを閲覧することができます。 しかし、そのマネージャーが現実でその役職に任命以前の結果まで閲覧できてしまう状態でした。

• 2024年6月1日にサービス開発部のマネージャーに任命されたAさんは、任命されるより以前のサービス開発部のサーベイ回答結果も閲覧できてしまう

ミキワメウェルビーイングサーベイでは、従業員が自由記述できるコメント機能、企業担当者が従業員に対する打ち手を記録するサポート履歴機能などもあります。 その為、誰かに見られては困る内容を、その誰かが閲覧できてしまうリスクがありました。

アップデート後​

マネージャーが特定の部署のみ回答結果を閲覧することができるという条件に加え、その部署を閲覧権限を付与した以前の結果は、閲覧不可とする制御ができるようになりました。

• 2024年6月1日にサービス開発部のマネージャーに任命されたAさんは、任命されるより以前のサービス開発部のサーベイの回答結果は閲覧することができない

これによって、アップデート前のリスクを防止することができ、より安心して利用できる仕様にすることはできました。

ところが、このアップデートのリリース直後、とある問題が起きてしまいます・・・

画面の表示速度がめっちゃ遅くなっている！！！​

それは、サービス開発部で毎月末に実施している、各チームの進捗報告などの定例の中での話でした（確かその初回だったと記憶）。

EM「サーベイで画面表示速度が遅くなっているらしいので、従業員サーベイチームは調査に入ってください」

わたし「！！？」

企業向け管理画面では、全社・部署単位で組織のサーベイ回答結果を閲覧できるページがあり、ミキワメウェルビーイングサーベイにおけるコア機能の一つなのですが、このページにおいて著しいパフォーマンス低下が発覚。

例：数千人分の回答結果を持つページの場合

• 初期表示までに10~20秒、あるいはそれ以上かかってしまう
• サーベイに回答した社員一覧データを取得するための非同期処理に1~3分以上かかってしまう

当時はエンタープライズ企業への導入が活発化し始めていた状況だったのですが、その矢先にこのような事態に見舞われてしまったのです・・・！！

ボトルネックを探し、仮説を立てる​

この事態を受け、従業員サーベイチームではリードエンジニアの力を借りながら、とにかくやれることをやっていくこととしました。

• 不足しているeager loadingの追加
• メモ化できていない所のメモ化
• 画面表示の都度発生していた計算処理を、DBから参照する形に修正
• さらに非同期取得してよさそうな所があれば非同期化
• etc

このあたりは一定改善があったのですが、元の速度に戻るまでには至らず。そして気づけば1ヶ月経過・・・。別の観点でも調査を継続していくこととなりました。

遅くなっている画面でrack-mini-profilerを用いたクエリ発行数の調査をしていく中で、多くのクエリが発行している箇所を確認しました。この箇所では、サーベイの回答結果が閲覧できるかどうかを以下のように制御しており、これが速度低下に影響しているのではないか？という仮説を立てることとしました。

• 回答者がサーベイに回答した日時の時点で所属していた部署が、マネージャーの閲覧可能な部署である

一人一人回答タイミングは異なることから、配信対象になった社員全員分を対象をループさせ、回答者ごとに都度閲覧可能かを判定する必要があります。

# コードはイメージ。実際のものは異なります。

# cq_recruitment_examinees: サーベイ配信対象者になった社員
# supervisor: 企業向け管理画面のログインユーザー。ここではマネージャーを想定
# division: 部署

cq_recruitment_examinees.select do |cq_recruitment_examinee|
  # 社員がサーベイに回答した日を取得するメソッド
  deadline = cq_recruitment_examinee.completed_time
  
  # 部署IDと回答日を渡してマネージャーが閲覧可能かを判定
  # 内部で閲覧可否判定用のデータを取得するクエリの発行をしている
  supervisor.survey_permission?(deadline, division.id)
end

• ループごとにクエリが発行されN+1が発生
• 社員が多いほど処理時間が線型に増加する

上記のコード例は説明のために簡略化させていますが、もう少し色々処理が伴っていたり、類似した処理が複数箇所で実装されていたりします。これらが速度低下のボトルネックなのでは！？という話になったのです。

解決に向けたアプローチ​

一定ボトルネックが明確になったので、下記の改善案を考案する形になりました。

• 配信されたサーベイの配信終了日の時点で回答者が所属していた部署が、マネージャーの閲覧可能な部署である

これにより、全社員に対して同一の時点で閲覧可否を判断することができます。

# コードはイメージ。実際のものとは異なります。

# cq_recruitment: 配信されたサーベイ。cq_recruitment->cq_recruitment_examineesで1対多のリレーション。
# サーベイが終了した日付を取得するメソッド
deadline = cq_recruitment.deadline
CqRecruitmentExaminee.none if supervisor.survey_permission?(deadline, division.id)
 
cq_recruitment_examinees

ボトルネックとなっていたループ処理が不要になり、回答者人数に依存することなく制御できるようになりました。 ただし元々の仕様自体を変えることになるので、PdM・カスタマーサクセスのメンバーとの合意を得る必要がありましたが、一定議論を重ね、パフォーマンス以外のUX改善も盛り込む形で上記の対策を取る方針で合意することができました！

まとめ​

閲覧範囲制御の実装範囲は広く、実装自体にも約2ヶ月弱かかりましたが、概ね狙い通りにパフォーマンスを改善！

これで、エンタープライズ企業への導入の障壁を大きく下げることができました。

このアップデートのリリース時点で2024年9月半ば。3ヶ月半の長い道のりで、この間メンバーの入れ替わりなどもありましたが、無事にここまでやり遂げられたことは今でも貴重な経験だったなと思っております。特に下記は教訓となりました。

• 大規模データを想定して、アップデート前後で速度の低下が発生していないかを検証した上で実装すること。非機能要件の重要性を再認識した。
• 時にはビジネスロジックの再考も話し合える姿勢を持つこと。役割を超えてより良い開発をする機会となった。

ネクストアクション​

非同期処理の中には、まだ社員がサーベイに回答した日起点で閲覧可否を制御せざるを得ないパターンがあり、10〜15秒程度かかる場合があります。 こちらも更に速度が出るように改善し、より快適なサービスにしていきたいです。

そして、実は今回の取り上げた事例以外にも表示速度が遅いページが残っています・・・！同じく企業向け管理画面にある、企業上に作成された部署の一覧表示するページです。これもエンタープライズ企業にて顕在化した課題であり、同様にパフォーマンスチューニングが必要な状況です。こちらにも積極的に関わっていきたいなと思っております。

以上です。最後までご覧いただきありがとうございました！

初めまして、サービス開発部プロダクトエンジニアの篠倉と申します。

2024年12月、弊社プロダクト『ミキワメ』で新機能をリリースしました。

この機能の開発では、20テーブル以上のデータベース設計を行う必要がありました。大規模なER図を効率的に作成し、レビューをスムーズに進めるために試行錯誤した手法と得られた知見を共有します。

直面した課題​

今回のER図設計では、以下の3つの要件を満たすことが課題となりました。

1. テーブル名やリレーションを明確に表現する
2. カラム情報（型、NULL可否、外部キー等）を適切に記載する
3. 効果的なレビューを実現し、スムーズにフィードバックを受けられる環境を整備する

検討過程と採用した方法​

最初にNotionとMermaidの組み合わせを検討しましたが、以下の2つの理由で採用を見送りました。

※Mermaidとはマークダウンに近い書き方でフローチャート、シーケンス図、ER図を書ける記法です

• コメントがコード上にしか書けず、レビューが非効率になる

• リレーションを詳細に記載すると文字が小さくなり、視認性が低下する

検討を重ねた結果、PlantUMLを用い以下の方法を採用しました

※PlantUMLとはオープンソースのツールです。Mermaidと同様フローチャート、シーケンス図、ER図を書くことができます。

1. PlantUMLを使用してER図を作成
2. 作成したER図をMiroに添付
3. Miro上でチームメンバーがコメントを付与

この方法により、大規模なER図に対する効果的なチームレビューが可能になりました。

感じた利点と課題​

• 利点
  • テーブル名、リレーション、カラム情報を一元管理できる
  • Miro上で拡大縮小ができ、全体像と詳細の両方を確認しやすい
  • ER図上に直接コメントを残せるため、レビューがスムーズになる
• 課題
  • 大規模なER図では複雑になり、視認性が低下する
  • 図を修正するとコメントが消えるため、やり取りのログが残らない

今回のER図作成を振り返ってみて​

今回は上記の「直面した課題」の解決を実現するため、PlantUMLとMiroを用いた方法を使ってER図の作成とレビューでテーブル設計を行いました。課題はありつつも一定解決できたと感じました。

しかし、仮にまた同様のER図作成を行う場合は以下の方法を試したいと考えています。

1. Notion + Mermaidで全体のER図を作成し、シンプルにリレーションを表現する
2. 機能ごとに詳細なER図とテーブルの説明をNotionにまとめる

このような記載方法のメリットとしては全体像と詳細を分けて表現できる点です。全体ER図で構造を把握しやすくし、機能別の詳細ページで深い理解が可能になります。

まとめ​

大規模なデータベース設計では、ER図の作成とレビューの方法が開発のスムーズさを左右します。今回採用したPlantUML + Miroの手法は、一定の成果を得られましたが、より柔軟な管理を実現するための改善点も見つかりました。

同様にER図の作成とレビューの方法についての課題に直面している方は、自社の開発環境に応じて最適な手法を検討してみてください。

こんにちは。リーディングマークのミキワメ適性検査開発チーム、エンジニアリングマネージャーの梶原です。
本稿では、2023年末から2024年初頭にかけて実施した「受検者データ分離プロジェクト」について解説します。このプロジェクトは、リーディングマークが提供しているミキワメ適性検査とミキワメウェルビーイングサーベイ（以下、「適性検査」「サーベイ」）のデータ構造を改善し、開発スピードの向上とシステムのスケーラビリティを実現することを目的としていました。

「受検者データ分離プロジェクト」は、2023年末に起案され、2024年1月から3月の約3ヶ月かけて開発が行われました。このプロジェクトの背景には、ミキワメ適性検査における課題がありました。従来、新卒・中途・社員の受検データを単一のテーブルで管理していましたが、事業拡大と新サービスの追加に伴い、このデータ構造が開発スピードの制約要因となっていました。
そこで、80万件を超えるデータを分割し、よりスケーラブルなシステムを構築することを目指しました。具体的には、単一のテーブルで管理していた新卒・中途・社員の3区分のデータを、3つの独立したテーブルに分割することが主な目的でした。
開発チームは、テックリード1名、適性検査開発チームから1名、サーベイ開発チームから1名の計3名で構成されました。私は主に適性検査の範囲を担当しました。
プロジェクト実施時点で、バックエンドにはRuby on Rails（バージョン6.1）を使用していました。 この記事では、このプロジェクトの設計方針、技術選定、移行プロセス、直面した課題とその解決策について詳しく解説していきます。

プロダクトの課題とプロジェクト背景

前提として、弊社プロダクトのうち、適性検査・サーベイは同一のデータベースを参照しています。
ミキワメ適性検査の受検者データは、単一の examinees テーブルで管理され、新卒・中途・社員の3種類のユーザーを区別するために examinee_type カラムを使用していました。
このデータ設計では、企業に属する社員の情報を取得する際に、適性検査の受検データを経由する必要がありました。（図1）

[図1]

この構造では、サーベイ機能を独立させる際に不要な依存関係が生じるため、受検者のテーブルをstudents、workers、employees に分離することで直接企業と紐付けられるようにしました。受検者と紐づいている受検データにはリレーションを張っていたのですが、ポリモーフィック関連を用いて擬似的にリレーションを張ることにより、データの相関を実現する形となっています。（図2）

[図2]

先の図1で示したプロジェクト開始前のデータ構造では、ユーザーは適性検査の受検を通じて初めて企業に属することがわかるかと思います。
この構造の問題点は、社員がサーベイに回答するには、事前に適性検査を受検して企業に属している必要があったことです。当初は運用上大きな問題にはなりませんでしたが、企業が社員に適性検査とサーベイを同時に依頼する機能を実装する際、データ上企業に属していない社員へのサーベイ発行が課題となりました。
一時的な対応も可能でしたが、将来的に社員向けサービスを展開する上で、この問題が繰り返し障害になることが予想されました。結果として、このデータ構造がプロダクト全体の拡張性を制限し、開発の難易度を高めていました。
既存の構造では、企業に属する社員の情報を取得するために、適性検査の受検依頼を介する必要があり、これは無駄に複雑な構造でした。

プロジェクトを進行するにあたっての課題

プロダクトの課題を改善できる理想状態を定義できたものの、プロジェクト進行上の課題も多く存在しました。

プロジェクトの主な課題:

1. データ構造の大規模変更
   受検データはプロダクトのコアであり、影響範囲が広い
2. ビッグバンリリースの回避
   他プロジェクトと並行して進めるため、段階的な移行が必要
3. データ同期の複雑性
   旧テーブルと新テーブルの間で一貫性を保つ必要がある
4. トランザクション管理
   エラー時のロールバックや同期処理の信頼性が求められる(図3)

[図3]

これらの複雑かつ大規模な課題に対して、システムの安定性を維持しながら慎重に対応することが求められました。
それ考慮した上でどのような戦略を立て、どのような手順を踏んでプロジェクトを進めていったのかを説明していきます。

プロジェクト進行の戦略と手順

図4の手順に従ってプロジェクトを進行しました。

[図4]

これら手順を具体的に解説していきます。

前準備​

• 受検者区分ごとに必要なカラムの精査
• 受検者情報を置き換える必要があるアプリケーションのリソースの洗い出し
• 新受検者テーブル、およびそれらの関連テーブル(サインイン情報を持つテーブルなど)の作成

新テーブル作成と既存周辺テーブルの関連付け​

• 各区分の受検者テーブルへ旧受検者テーブルの情報を関連付けするためのカラム設定
• 旧受検者テーブルに対する外部キーを保持しているテーブル(受検データなど)へ、新受検者テーブルの情報をポリモーフィックで保持するためのカラムの追加、または社員のみのリレーションで十分なテーブルも存在していたため、その場合は社員テーブルに対する外部キーのカラム追加

旧受検者データを新受検者データへ複製​

約80万人(2024年1月1日時点)存在していた受検者のデータをstudents, workers, employeesそれぞれのテーブルへ移管する必要がありました。
問題点として、プロダクトリリース当初のバリデーションが十分に記述されていなかった時代に保存された受検者のデータが存在しており、それらを検知するためにいつ終わるかわからない分量のデータを移行するバッチを走らせて確認していました。
具体的には以下のような不整合のパターンが存在しました。

• employees テーブルでは現在、セイメイ(仮名姓名)の保存が必須だが、過去にはブランクが許容されていた
• 新しい受検者のテーブルには、メールアドレスのフォーマットに制約があるが、以前のデータには全角英数が許容されていたりと、制約が不十分であった
  このような過去データを新しい制約のあるテーブルへ複製する際、バッチ処理を実行して初めて問題に気付き、その対応に苦労しました。
  最終的には、目的が「複製すること」だったので、セイメイ(姓名)のnot NULL制約などDBレベルで制約がかかっているものに関しては仮の値を、メールアドレスのフォーマットなどアプリケーションレベルで制約がかかっているものに関しては一時的にアプリケーションの制約を外して対応することになりました。

新旧テーブル間データ同期の設定​

• 旧受検者テーブルのデータに変更が加わった時に、新受検者テーブルの対応するデータも変更するための処理
• またその逆の、新受検者テーブルのデータに変更が加わった時に、旧受検者テーブルの対応するデータも変更するための処理
  これらは更新・作成・削除のそれぞれで行う必要があり、モデルにコールバックを記述することで対応しました。それぞれafter_update, after_create , after_destroy を用い、同期対象となるテーブルのデータを操作する形としました。
  以下のコードは、ExamineeモデルとStudentモデルにおけるコールバックの処理の記述を表したものです。(Employeeモデル, Workerモデル, update, destroyに関しては省略します。)

class Examinee < ApplicationRecord
  after_update :update_student

  private

  def update_student
    self.student.update!(**{some_attributes})
  end
end

class Student < ApplicationRecord
  after_update :update_examinee

  private

  def update_examinee
    self.examinee.update!(**{some_attributes})
  end
end

コールバック内でデータを操作する処理の中で仮にエラーが発生した場合、トランザクションはどうなるのかという問題がありましたが、最初に操作を受けたテーブルのデータの処理からコールバック内で発火したデータ操作の処理は、同一トランザクションで囲まれる形となっているため、特段気にすることなくコールバックの記述をすることができました。
しかしながらここには一点問題があり、例えばExamineeの更新がコールバックでStudentの更新を呼んだ時、Studentの更新もコールバックでExamineeの更新を呼んで、さらにまた、、、という無限ループが発生してしまいます。
この無限ループ問題に対して、他社事例も参考にしながらの対処を行いました。
まず、両方のモデルでattr_accessorを使用して、一時的なインスタンス変数skip_double_writeを定義します。このようにすることで、インスタンスのライフサイクルの中でしか存在しないskip_double_write がそれぞれのActiveRecordインスタンスのカラムのように振る舞います。
このキーを、Examineeクラスのコールバックで呼ばれるプライベートメソッド内でtrueとしてStudentインスタンスに受け渡し、Studentクラスのコールバックの発火条件として利用することで、「ExamineeクラスのコールバックでStudentインスタンスが更新された場合、StudentクラスでExamineeインスタンスの更新を行うコールバックを発火しない」という、更新が再帰的に発生しないような挙動の実現が可能となります。
一部簡略化していますが、具体的なコードとしては以下です。

class Examinee < ApplicationRecord
  attr_accessor :skip_double_write

  after_update :update_student, unless: :skip_double_write

  private

  def update_student
    self.student.update!(**{some_attributes}, skip_double_write: true)
  end
end

class Student < ApplicationRecord
  attr_accessor :skip_double_write

  after_update :update_examinee, unless: :skip_double_write

  private

  def update_examinee
    self.examinee.update!(**{some_attributes}, skip_double_write: true)
  end
end

これらの設定を行うことにより、無事同期的にデータの整合性を保つ仕組みを整えることができました。もちろんここにはパフォーマンス観点で問題がありましたが、ここに関しては一定許容していただきつつ運用することとなりました。

アプリケーションが参照しているテーブルを旧テーブルから新テーブルへ全て移行​

ここでは前述したように、段階的に既存処理の移行を図りました。
当時、30以上の機能が旧受検者を参照している形であったため、その全てを新受検者のテーブルへ移管する必要がありました。
ここに関しては特に何かを工夫したわけではありませんでしたが、一つ一つドメインを把握している必要があり、入社2年弱であった私もキャッチアップから入る箇所もあったため、正直一番大変な作業でした。
ただ移行作業をするだけでなく、一部大きく処理を変えなければならない箇所も出てきました。
例えば受検データの検索においては、受検者のメールアドレスなどで検索することができるUIが存在していて、その場合関連テーブルとしてexaminees単体の検索で良かったものが、students, workers, employeesそれぞれを跨いだ検索ができるような機能に修正する必要がありました。
そのほかにも煩雑なコードやロジックが残されている箇所に関しては、そのまま移行するのではなく、全体的なリファクタリングを行った上で移行作業をしていったり、そもそも機能をほぼ作り直したような箇所もあったため、思ったようにタスクが消化できない時もありましたが、最終的には無事に移行作業を完了することができました。

対応漏れログの抽出用の設定​

移行作業は完了したものの、間髪入れずにexamineeクラスを削除するのはリスクが高かったため、実際にexamineeが呼ばれている箇所がないかをログとして抽出できるように、examineeクラスに以下のような記述をしました。

  after_initialize do |_examinee|
    backtrace = caller.grep(/#{Regexp.escape(Rails.root.to_s)}/)
    Rails.logger.info "Examinee initialize. #{backtrace}"
  end

  after_find do |_examinee|
    backtrace = caller.grep(/#{Regexp.escape(Rails.root.to_s)}/)
    Rails.logger.info "Examinee find. #{backtrace}"
  end

after_initializeでexamineeインスタンスが初期化された後、また、after_find でexamineeモデルを介してデータベースに検索をかけにいった際に、ログを残すような仕組みを残しました。
こうすることで、一定期間ユーザーがサービスを実際に利用する中で本当にexamineesテーブルに対する取得や操作は行われていないのかを確認することができます。
このおかげで、レガシーとなったexamineeモデルを安心して削除できるような状態を実現できています。

旧受検者モデルの削除​

対応漏れの確認と検証を十分に行った上で、アプリケーションから旧受検者であるexamineeの概念を取り除きます。
アクセスがされないモデルが残ってしまうため、モデルとそれらに関連するファイルを削除しました。
移行先の新テーブルにデータは残っていますが、念の為旧テーブルのデータ自体の削除は一定期間行わない方針です。

プロジェクトを振り返って

このプロジェクトを通じて、データ構造のシンプル化と、プロダクトの拡張性向上を実現しました。
特に、段階的な移行戦略やデータ同期の仕組み、トランザクション管理の工夫は、同様の課題を抱えるエンジニアにとって参考になるポイントかと思います。
今後も、システムの進化に合わせて最適なデータ設計を模索しながら、継続的に改善を進めていきます。

こんにちは。サービス開発部プロダクトエンジニアの山本です。

今回は16タイプマッピングという機能開発において、バックエンドを介さずフロントエンドのみでPDF生成を実装した経験についてお話しします。

PDFを生成する場合、一般的にバックエンドを介して処理を行いますが、今回の開発ではバックエンドを使わずフロントエンドのみで実装する必要がありました。

既存のReactコンポーネントをそのままPDF化したかったためです。本記事では、html2canvasとjsPDFを活用し、フロントエンドのみでPDF生成を実装した事例について紹介します。

背景​

ミキワメ適性検査では16タイプマッピングという機能を提供しています。

上記のようにミキワメの性格検査の結果から16にタイプ分類をして、会社全体や部署ごとに性格特性の分布図を作成することが可能です。

チームビルディングなどに活用され好評を博している機能なのですが、ここにPDFダウンロード機能を追加しました。

課題​

ミキワメ適性検査のフロントエンドはRailsのテンプレートエンジンであるhamlからReactへ移行中のため、その2つが混在している状況です。（2025/01 時点）

hamlからのPDF生成はすでに実装していましたが、Reactで作成された画面を直接PDF化した実績はありませんでした。

Reactで書かれたコンポーネントをPDF生成用にhamlで再作成し、従来通りバックエンドを介して実装することも検討しましたが工数がかかること、せっかくReactに移行したのにまたhaml書くんかいという気持ちがあり、もっと手軽にPDF生成する手段を模索することになりました。

技術選定​

以下の条件で選定を進めました。

• 導入コストが低い
• 実装し易い
• 主流ブラウザで動作可能
• React Emotionが期待通り動作する

バックエンドを介さずPDF生成をしたいという需要は一定あると思うのですが、意外と選択肢が少なく、結論としてはhtml2canvasとjsPDFを組み合わせて採用することになりました。

html2canvasはHTML要素をキャプチャし画像化することが出来、jsPDFは画像からPDF生成が可能で、いずれもJavaScriptライブラリです。

react-pdfはJSXで直接レイアウトを記述できる点が魅力的でしたが、React v17までの対応に留まっており、ミキワメ適性検査が採用しているReact v18では動作しませんでした。また、Emotionの互換性もないため、今回の要件には適合しませんでした。

直面した課題​

• 一部のスタイルが反映されない
• ブラウザ上でレンダリングが必要なため、表示の工夫が必要
• 既存機能と一貫性のあるダウンロード操作を実装する必要がある

解決策​

• スタイルの問題は、デザイナーと相談し、許容範囲を判断
• 一旦非表示エリアにPDF生成用コンポーネントを表示し、見えない形でPDFを生成
• 既存のダウンロードフローと統一し、ユーザーのUXを維持

デモで使用した実装​

シンプルですが以下でブラウザに表示させたPDF生成用コンポーネントをユーザが視認できないよう調整しました。

1. ダウンロードボタン押下をトリガーにPDF生成用コンポーネントをブラウザに表示
2. PDF生成、ダウンロード処理
3. 完了後非表示にする

最終的な実装ではベースレイアウト外でPDF生成用コンポーネントを表示させ、視認のリスクを軽減させています。

export const PdfDownloadButton = ({ className }: Props) => {
  const [showPDF, setShowPDF] = useState(false); // PDF生成用コンポーネントを表示する状態管理

  // ボタンクリック時にPDF生成用コンポーネントを表示
  const handleClick = () => {
    setShowPDF(true);
  };

  // showPDF が true になったら PDF を生成し、完了後に元の状態に戻す
  useEffect(() => {
    if (showPDF) {
      PdfDownload(); // PDF生成処理を実行
      setShowPDF(false); // PDF生成が終わったら状態を元に戻す
    }
  }, [showPDF]);

  return (
    <div>
      {/* PDFダウンロードボタン */}
      <Button onClick={handleClick} className={className}>
        PDFダウンロード
      </Button>
      {/* PDF生成用コンポーネント（表示されるとPDFを作成） */}
      {showPDF && <PdfTargetComponent />}
    </div>
  );
};

// PDFを生成する関数
const PdfDownload = () => {
  const target = document.getElementById('pdf-target'); // PDF対象の要素を取得
  if (target === null) return;
  
  // 取得した要素をPDFとして生成
  generatePdf(target);
};

まとめ​

フロントエンドのみでPDF生成を行う方法として、html2canvas + jsPDFは有力な選択肢のひとつです。特に、既存のバックエンドを改修せずにPDFを導入したい場合や、Reactで作成されたコンポーネントをそのままPDF化したい場合に有効です。一方で、スタイルの反映やブラウザレンダリングの工夫が必要になるため、導入前に許容範囲を整理することが重要です。

こんにちは。サービス開発部技術基盤部門のSREエンジニアの片所です。

今回は、私が実施したAWSのコストカット施策について紹介したいと思います。 リーディングマークでは、サービスの成長とともにAWSの利用料が増大していました。特に、Amazon Inspectorの利用料が想定以上に高く、ECRのスキャン回数が大きな要因となっていました。 本記事では、ECRのスキャン回数を最適化し、Inspectorのコストを75%削減した具体的な方法を共有します。

AWSにおけるコスト面の課題について​

弊社のプロダクトは、日々多くのユーザーの皆様にご利用いただき、着実に成長を続けています。この成長に応えるべく、開発チームは常にスピード感を持って新機能の開発や既存機能の改善に取り組んでいます。

しかし、サービスの拡大と開発の加速に伴い、私たちはある課題に直面しました。それは、AWSの利用料の慢性的な増加です。特に以下の要因が大きく影響していました。

1. トラフィックの増加に伴うリソース使用量の増大
2. 新機能開発や検証のための環境の増設・リソースの増加

1の要因については利用企業の増加（2024年5月時点で約3000社、2025年1月時点で約4000社に増加）に伴うものであるということやインフラ構成の大幅な見直しが必要な可能性があるため、より迅速にコストを最適化するために2の要因に対して優先的に取り組むことにしました。

そのためにまず、AWS利用料の詳細な分析を行いました。その結果、RDSやECSといった主要サービスの次に、Amazon Inspector（以下、Inspector）の利用料が大きな割合を占めていました。Inspectorは弊社のプロダクトに対するセキュリティ面での重要な役割を果たしていますが、その利用料が予想以上に高額であることが判明しました。 そこで、セキュリティレベルを維持しながら、いかにInspectorのコストを最適化できるかという課題に取り組むことにしました。

Amazon Inspectorとは何か​

Inspectorは、Amazon EC2、AWS Lambda関数、Amazon ECRの脆弱性を検出するためのセキュリティサービスです。 弊社では、主にECRの脆弱性スキャンに利用していました。しかし、スキャン頻度と対象リソース数によって利用料が大きく変動するため、最適化の余地がありました。

コストが増大してしまった原因​

ECRにタグなしの古いイメージ（中には１年以上前のものも）が多数残っており、これらが自動で定期的にスキャンされていたため、Inspectorのコストが大幅に増加していました。 主な原因としては、開発初期にイメージのローテーションを実装していなかったことが挙げられます。

今回実施したコストカット方法について​

そこで今回私はコスト削減のために、開発チームと協議のうえ、不要なイメージを削除するライフサイクルポリシーを導入することにしました。 具体的には、ECRのリポジトリ上の「pushから7日以上経過し、タグが付いていないイメージ」を自動削除する設定を行いました。

手順について​

ECRのライフサイクルポリシーを利用し、タグなしのイメージを7日後に自動削除する設定を行いました。 具体的な設定手順については、AWS公式ドキュメントも参考にしてください。https://docs.aws.amazon.com/ja_jp/AmazonECR/latest/userguide/LifecyclePolicies.html

*実際に行った設定

実装した結果​

この方法を実施した結果、Inspectorの月間利用料を75%削減することに成功しました。また、ECRの利用料も84%削減され、大幅なコスト最適化を実現しました！

まとめ​

今回はECRのライフサイクルポリシーを活用し、不要なイメージの削除を自動化することで、InspectorとECRのコストを大幅に削減しました。

Inspectorは強力なセキュリティツールですが、運用方法によってはコストが増大してしまうリスクがあります。セキュリティレベルを維持しつつコストを抑えた運用を行いたい場合は、スキャン回数の最適化をどのように実現するかが重要になります。 もし同様の課題を抱えている方がいれば、一度スキャン頻度やECRの管理方法を見直してみることをおすすめします！

こんにちは。山田です。

今回は、AWS Copilot CLI を使って SPA をデプロイする方法を紹介したいと思います。

AWS Copilot CLI は、コンテナベースのアプリケーションや SPA を簡単にデプロイできるツールで、
ほぼコーディングなしでアプリケーションに必要なインフラを構築してデプロイできるので個人的にとても好きなツールです。

今回は SPA をデプロイする方法について紹介したいと思います。

事前準備​

まずは AWS Copilot CLI をインストールします。

$ brew install aws/tap/copilot-cli

インストールが完了したら、copilot コマンドが使えるようになります。

$ copilot --version
copilot version: v1.34.0

次に SPA のプロジェクトを作成していきます。

SPA は Remix で作ろうと思うので、公式の SPA テンプレートを使ってプロジェクトを作成します。

$ mkdir spa
$ cd spa
$ npx create-remix@latest --template remix-run/remix/templates/spa

プロジェクト作成後のディレクトリはこんな感じになっていると思います。

$ tree -a -L1
.
├── .eslintrc.cjs
├── .gitignore
├── README.md
├── app
├── node_modules
├── package-lock.json
├── package.json
├── postcss.config.js
├── public
├── tailwind.config.ts
├── tsconfig.json
└── vite.config.ts

4 directories, 9 files

AWS Copilot CLI のコンセプト​

後はデプロイするだけなんですが、デプロイ前にいくつか手順があるので概念の説明もしておこうと思います。

まず、Copilot には「Application」、「Environment」、「Service」の 3 つの概念があります。（Job と Pipeline も含めると 5 つ）

名前の通りではあるのですが、Application はそのアプリケーション全体を指し、Environment はアプリケーションをデプロイする環境（本番、検証など）、
Service はアプリケーションの中で動くサービス（API、フロントエンドなど）のことを指しています。

イメージ図

なので AWS Copilot CLI で環境を構築する際は、まず Application を作成して、その中に Environment を作成し、さらにその中に Service を作成していくというイメージを持つといいと思います。

Application と Environment の作成​

$ copilot app init

作成するアプリケーションの名前を聞かれるので入力します。
実行が完了するとディレクトリ内に copilot というディレクトリが作成され、.workspace というファイルが作成されます。
このファイルにはアプリケーション名が記載されています。
また、裏側では CloudFormation が動いていて、アプリケーション内で共通で利用される IAM ロールが作成されます。

次に Environment を作成します。

$ copilot env init

ここでは環境名、利用する AWS アカウントのクレデンシャル名、VPC などの設定を聞かれるので入力します。
実行が完了すると copilot ディレクトリ内に environment の構成ファイル manifest.yml が保存されます。
また、この時裏側では CloudFormation によって、S3 バケットや KMS キーなどが作成されます。

この時作成される設定ファイルは以下のようになっています。
コマンド実行した時に聞かれる質問で network 設定をデフォルトにしているためコメントアウトされていますが、項目に設定を追加することで既存の VPC 上に環境を作成することも可能です。

# The manifest for the "staging" environment.
# Read the full specification for the "Environment" type at:
#  https://aws.github.io/copilot-cli/docs/manifest/environment/

# Your environment name will be used in naming your resources like VPC, cluster, etc.
name: staging
type: Environment

# Import your own VPC and subnets or configure how they should be created.
# network:
#   vpc:
#     id:

# Configure the load balancers in your environment, once created.
# http:
#   public:
#   private:

# Configure observability for your environment resources.
observability:
  container_insights: false

ちょっと混乱するかもですが、app 以外のcopilot xxxx initは基本的に構成ファイルを作成するためのコマンドなので init とは別に deploy コマンドを使って構成を反映させる必要があります。

$ copilot env deploy

実行すると、manifest ファイルに記載された構成が反映されて VPC などのリソースが作成されます。
CloudFormation のスタックを見ると deploy 実行後にリソースが追加されていることが確認できると思います。

Service（SPA）のデプロイ​

それでは準備が整ったので SPA をデプロイしていきます。
まず Remix のビルドを行います。

$ npm run build

ビルドが完了すると、build/client ディレクトリにビルドされたファイルが出力されます。

次に Service を作成します。

$ copilot svc init

Load Balanced Web Service などデプロイ構成の選択肢が出てくるので、Static Site を選択します。
次にサービス名を聞かれるので適当な名前を入力します。今回は remix とします。
次にビルドした静的ファイルのディレクトリを聞かれるので build/client を入力します。

実行が完了すると copilot ディレクトリ内に service の構成ファイル manifest.yml が保存されます。

# The manifest for the "remix" service.
# Read the full specification for the "Static Site" type at:
# https://aws.github.io/copilot-cli/docs/manifest/static-site/

# Your service name will be used in naming your resources like S3 buckets, etc.
name: remix
type: Static Site
files:
  - source: build/client
    recursive: true
# You can override any of the values defined above by environment.
# environments:
#   test:
#     files:
#       - source: './blob'
#         recursive: true
#         destination: 'assets'
#         exclude: '*'
#         reinclude:
#           - '*.txt'
#           - '*.png'

それではデプロイコマンドを実行します。

$ copilot svc deploy

実行すると、environment deploy で作成された staging 環境に remix サービスがデプロイされます。
裏側では CloudFormation によって S3 や CloudFront といったリソースが作成され、ビルドした静的ファイルが S3 にアップロードされます。

デプロイが完了すると CloudFront の URL がコンソールに表示されるので、ブラウザでアクセスすると Remix にアクセスできます。

以上、AWS Copilot CLI を使って SPA をデプロイする方法について紹介しました。
ちょっと長くなってしまいましたがイメージさえ掴めれば使い心地は非常に良いので、とてもおすすめです。

ご覧いただきありがとうございました！

余談​

実は AWS Copilot CLI の最終リリースが 6 月 27 日となっていて、しばらく更新がありません 😭
メンテナンスモードに移行したという噂もあり今後の動きが気になるところです。

参考​

• AWS Copilot CLI
• AWS Copilot CLI GitHub
• Remix SPA Mode

森田です。

早いものでこの記事で私が執筆したものが 10 記事目となります。 普段は技術的なお話を書いていますが、今回はテックブログを書いている中で感じたことなど書いていこうと思います。

なぜテックブログを書いていたのか​

自分自身の学びを深めるためというのが大きかったですね。新しい技術に触れるたびにメモを残しておきたい気持ちはあるものの、ただ自分用のメモにしておくのももったいないと感じていました。どうせなら自分が得た知識をまとめて共有しよう、という気持ちがありましたし、そうすることで他のメンバーにも役立つかもしれない。何より、知識を文章にすることで自分の理解もよりしっかりとしたものになると感じていたので、テックブログを書くことには自然とやりがいを見出していました。

テックブログを書く中で感じたこと。​

正直な感想を言ってしまうと、めちゃめちゃ大変でした。大変でもあり、楽しくもありました。

そもそもの話になるのですが、私文章を書くのがものすごく苦手です。なのでどのように文章にしたら読み手にわかりやすく伝わるのかというところにかなり時間をかけた記憶があります。 言い回しの修正などには結構 GPT を活用したりしました。

また、技術的な内容ですと普通の一般的なブログとは異なり、ブログを書き始める前に実際にコードを書いて動くものを作ったりする必要があります。 なので記事の執筆以前に準備にものすごい時間がかかりました。どれだけのプロジェクトを作成したことか...。特に action cable で同時編集を実装する記事では react と rails 両方の環境構築をして色々設定したりしていたので一番時間がかかりました。

とは言ってもそれ以上に楽しく記事を書いていたと思います。これは私の性格的なところもあると思うのですが、やはりエンジニアとして新しい技術に触れたり未知の問題に挑戦することが好きなんですよね。 プロダクトの開発の中で新しく使った技術や解決した問題を一般化して記事として残すというのは、自分自身の考えをまとめることができ、さらに他の人にも役立つ知見を共有できる良い機会でした。

また、社内外かなり多くの方に読んでいただいたようで、さまざまなフィードバックをいただけていました。「参考になった」と言われた時はやはり一番やりがいをを感じましたし、普通に嬉しかったですね。

新卒エンジニアに向けて​

新卒エンジニアでも記事書きましょう！ということを言いたいです。

理由としましては、テックブログを書くということは自分の知見を世界中の人に共有できるということももちろんあるのですが、自分の技術力を見せつけることができるという側面もあります。 自分が取り組んできたプロジェクトやそこで学んだ技術や知見を発信することで、他のエンジニアや採用担当から「この人はこんな技術を使えるんだ」と認知してもらえる場になります。 さらに書いた記事を自分のポートフォリオの一部として活用することもできます。 ペース的には半年に 1 本くらいでいいと思うので自分の実績を記事として記録に残しておくと良いと思います。

今後​

これからも引き続き技術について学んだことや感じたことを発信していきたいと思います。記事を書くことで自分の理解が深まり、他の人の役に立てることがわかりましたし、それがやりがいにも繋がっています。新しい技術や取り組みに触れながら、今後も記事を通じて成長の過程を記録し、共有できればと思っています。

最後に​

これまで私の記事を読んでくださった皆様、ありがとうございました。ちゃんとテックブログを書くのは初めての経験だったのでなかなか苦戦することもありましたが、得られた物も多かったと思います。 開発の技術的な面でも記事の執筆的な面でも、自分の成長をひしひしと感じました。今後も引き続き技術を深掘りし共有できればとお思っていますので、引き続きご愛読賜ればと思います。

では。

森田です。

普段は何かしらの機能の実装の話をしてますが、今回は毛色の異なるお話をしようかと思います。

では早速こちらのコードをご覧ください。

import { useEffect, useState } from "react";

type Address = {
  address1: string;
  address2: string;
  address3: string;
  kana1: string;
  kana2: string;
  kana3: string;
  prefcode: string;
  zipcode: string;
};

export const App = () => {
  const [address, setAddress] = useState<Address>();
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    const fetchData = async () => {
      const response = await fetch("https://zipcloud.ibsnet.co.jp/api/search?zipcode=7830060"); //fetchでデータを取得
      const data = await response.json();

      setAddress(data.results[0]); //data.results[0]をaddressにセット
      setLoading(false); //fetchが終わったらloadingをfalseにする
    };

    fetchData();
  }, []);

  if (loading) {
    return <div>loading...</div>;
  } else {
    return <div></div>;
  }
};

やっていることとしてページをロードした際に指定した郵便番号からどこの住所のものなのかを取得しているだけです。

fetch中はloading...と表示し、終わったら取得した内容を表示するといったページです。

では問題です。addressの型は何でしょうか。

　 〜シンキングタイム〜 　

正解は...

Address | undifnedです！正解できましたかね？

そうなんです、useStateで初期値を設定していないのでundefinedがくっついてしまうんです。

なのでaddressの値を表示させようとすると{address?.address1}とオプショナルプロパティをつけて書かないといけなくなってしまうのです。これはよろしくないですね。

これをtypescriptの良さを活かして解決してみましょう！

解決方法としてはaddressを定義する際にその型を(Address & { loading: false }) | { loading: true }とし、その初期値を{ loading: true }とするというものです。

つまり

const [address, setAddress] = useState<(Address & { loading: false }) | { loading: true }>({ loading: true });

とするということです。

で、fetchしたデータをaddressに代入する際にloadingの値をfalseにします。

こうすることによってaddress値はundefinedにならなくなり、さらに別でloadingの値を設定する必要がなくなるのです。

文面だけだと何言ってるか少しよくわからないですね。

最初のコードを実際に編集してみましょう。

import { useEffect, useState } from "react";

type Address = {
  address1: string;
  address2: string;
  address3: string;
  kana1: string;
  kana2: string;
  kana3: string;
  prefcode: string;
  zipcode: string;
};

export const App = () => {
  const [address, setAddress] = useState<(Address & { loading: false }) | { loading: true }>({ loading: true });

  useEffect(() => {
    const fetchData = async () => {
      const response = await fetch("https://zipcloud.ibsnet.co.jp/api/search?zipcode=7830060"); //fetchでデータを取得
      const data = await response.json();
      setAddress({ ...data.results[0], loading: false }); //data.results[0]とloading:falseをセット 
    };

    fetchData();
  }, []);

  if (address.loading) {
    return <div>loading...</div>;
  } else {
    return <div>{address.address1}</div>;
  }
};

このようにaddress.loading === falseになっている時だけaddressの値を表示するようにすると通常通り{address.address1}と表示できるようになるというわけです！

めちゃめちゃtypescriptの良さを活かしたtypescriptだからこそできる手法ではないでしょうか。

ちなみにこちらはチームのメンバーさんが見つけてくださったうひょさんの記事を参考にしています。 https://qiita.com/uhyo/items/d74af1d8c109af43849e

実際に社内のプロダクトでもこの手法を取り入れて開発をしています。

もしよかったら参考にしてみてください！

では。

森田です。

前回の記事で blocknote と yjs と liveblocks を用いた共同編集の実装を紹介しました。

とても簡単に実装できるというは大きな利点なのですが、これは Nextjs ありきの実装となっており、react ではどう実装するのという話になってしまいます。

なので今回は React + Rails の構成で yjs と ActionCable を用いたコンフリクトフリーな共同編集を実装してみましょう！

実装​

Rails​

まずActionCableを使うにあたって必要なgemをインポートしておきます。

require "action_cable/engine"

続いて開発環境のみでどのオリジンからもActionCableに接続できるようにしておきます。 該当する行のコメントアウトを外すだけです。

config.action_cable.disable_request_forgery_protection = true

では実際にActionCableを作成してみましょう。

ストリーム先を自由に選択できるようにしたいので、idによって変化するようにします。

class SyncChannel < ApplicationCable::Channel
  def subscribed
    document_id = params[:id]
    stream_from("document-#{document_id}")
  end

  def receive(message)
    document_id = params[:id]
    ActionCable.server.broadcast("document-#{document_id}", message)
  end
end

React​

続いてフロント側の実装をしていきます。

まず必要なライブラリをインポートしていきます。

npm i @rails/actioncable @types/rails_actioncable @y-rb/actioncable   

おやおや？

何やら怪しいライブラリが含まれていますね...

y-rb/acioncableとはなんぞや？と思われたそこのあなた。鋭いですねぇ

今回も前回と同様にyjsというフレームワークを用いてコンフリクトフリーな共同編集を実装します。 ところがyjsはjsと付いているようにjavascriptを前提に作られているフレームワークです。 なのでrailsで扱うには少し不都合なのです。

そこで登場するのがこのy-rb/actioncableです。 公式の説明を簡単に翻訳すると、「yjsクライアントとRailsのActionCableチャネルを使用してWebSocket接続を設定するために必要なJavaScriptとRubyの依存関係を提供してくれる」とのことです。

詳しくはこちら↓

https://github.com/y-crdt/yrb-actioncable

こんな便利なものがあるなら使わない手はないということでしっかり組み込んでフロントを実装していきましょう。

BlockNote関連の部分は前回の記事を参照ください。

import { WebsocketProvider } from "@y-rb/actioncable";
import { createConsumer } from "@rails/actioncable";
import * as Y from "yjs";
import { useEffect, useState } from "react";
import { BlockNoteEditor } from "@blocknote/core";
import { useCreateBlockNote } from "@blocknote/react";
import { BlockNoteView } from "@blocknote/mantine";
import "@blocknote/core/fonts/inter.css";
import "@blocknote/mantine/style.css";

export const App = () => {
  const [doc, setDoc] = useState<Y.Doc>();
  const [provider, setProvider] = useState<any>();

  useEffect(() => {
    const consumer = createConsumer("ws://localhost:5000/cable");
    const yDoc = new Y.Doc();
    const yProvider = new WebsocketProvider(yDoc, consumer, "SyncChannel", { id: "1" });
    setDoc(yDoc);
    setProvider(yProvider);

    return () => {
      yDoc?.destroy();
      yProvider?.destroy();
    };
  }, []);

  if (!doc || !provider) {
    return null;
  }

  return <BlockNote doc={doc} provider={provider} />;
};

type EditorProps = {
  doc: Y.Doc;
  provider: any;
};

function BlockNote({ doc, provider }: EditorProps) {
  const editor: BlockNoteEditor = useCreateBlockNote({
    collaboration: {
      provider,
      fragment: doc.getXmlFragment("document-store"),
      user: {
        name: "User",
        color: "#ff0000",
      },
    },
  });

  return <BlockNoteView editor={editor} />;
}

実装はほとんど前回と一緒ですね。

const consumer = createConsumer("ws://localhost:5000/cable");

@rails/actioncable"を用いてcosumerを設定しています。今回Railsを5000ポートで立ち上げているのため上記のようになっているので、ここはそれぞれの環境に合わせて書き換えてください。

const yProvider = new WebsocketProvider(yDoc, consumer, "SyncChannel", { id: "1" });

そして@y-rb/actioncableを用いてproviderを設定しているという感じですね。ここのidを変更することによってストリーム先を変更することができるので、必要に応じて変数にしたりしてみてください。

というわけで実装はここまで。

フロントとバックエンドそれぞれを立ち上げてみると...

完成！🎉

課題​

とりあえず共同編集はできるようにはなったのですが、この実装ではリロードすると記入内容が消えてしまいます。本来であれば、ActionCable側が接続されたことを感知してdbに保存されている内容を参照して送り返すという処理を挟むべきなのですが、yjsを使っているため従来のやり方ではできないのです。 今色々と試している段階なので、何か良い解決策が見つかったらまた記事にしてお届けしたいと思います。

終わり​

というわけでyjsとActionCableを用いた共同編集の実装を紹介しました。ちゃんと動く状態になるまで試行錯誤してかなり時間がかかった記憶があるのですが、コードで見てみると結構簡単に実装できますね。 かなり拡張性のあるものだと思うので、ぜひ色々いじってみてくださ。何か面白いことができたりしたら逆に教えて欲しいです。

ではまた。