Upgrade to Pro — share decks privately, control downloads, hide ads and more …

ユビキタス言語はバックエンドエンジニアから始めよう

sora_ichigo
March 01, 2024
1.4k

 ユビキタス言語はバックエンドエンジニアから始めよう

https://increments.connpass.com/event/310090/
2024/03/01「Wantedly x Qiita Meetup #2 Rubyを用いたプロダクト開発」の資料です。

本発表では、モデリングという役割を持つバックエンドエンジニアこそ、
開発段階からユビキタス言語作りを主導すべきという話をします。

sora_ichigo

March 01, 2024
Tweet

More Decks by sora_ichigo

Transcript

  1. © 2024 Wantedly, Inc. 自己紹介 名前 市古 空 (Sora Ichigo)

    所属 • ウォンテッドリー株式会社 • 新規プロダクト開発チーム • DevOps 推進チームリード SNS • X: @igsr5_ • GitHub: @igsr5
  2. © 2024 Wantedly, Inc. 目次 1. はじめに 2. プロダクトを正しく作るとは 3.

    モデリングという役割 4. 正しく使われるモデリング 5. 業務ロジックのモレ・ダブリ 6. エッジケースの存在 7. おわりに Table of Contents
  3. © 2024 Wantedly, Inc. プロダクト開発の全体像 ウォンテッドリーの Visit Growth Squad の場合

    ざっくり ver プロダクトマネージャー (PM) デザイナー バックエンドエンジニア フロントエンドエンジニア 要求考える アプリ作る システム作る UI/UX考える
  4. © 2024 Wantedly, Inc. 正しく使えるか 誰もが正しく使える共通認識か • みんなが意図を理解できず、間違った使い方をしてしまうことはよくある • 間違った使い方こそ認識ズレになる

    使われる未来を想定したモデリングを行おう • 共通認識は作る時ではなく、使われる際に価値を問われる どう使われるか?は話さないと分からない • あなたの認識を言語化し、積極的に認識合わせしに行きましょう
  5. © 2024 Wantedly, Inc. 難しい議論 難しい議論とは 例えばエッジケースについて議論するとき • バックエンドは目に見えない •

    そのため、自分から積極的に理解を促さないとチーム内の認識がズレやすい 結果、あなたしか理解のできないエッジケースが誕生する
  6. © 2024 Wantedly, Inc. 対応 共通認識を起点にコミュニケーションを展開する 「この機能は xx と OO

    という概念で実現されている」 「xx と OO の状態の組み合わせ的にこのエッジケースが存在するんだよね、、」 👆みたいにコミュニケーションができると問題を理解してもらいやすい 前提を揃え続ける
  7. © 2024 Wantedly, Inc. 言うは易し行うは難し 考え方を理解しても、実際には上手くいかないことだらけ • 「要求の認識欠けてた...」 「中々認識が揃わない...」 •

    不確実性を前提に、try&errorを繰り返すことが大事 1人ではできない • モデリングは協働が必須、チームに協力してもらおう ◦ 自分の場合、デザイナーや PM に壁打ち相手になってもらうことが多い • バックエンドエンジニアの考えていることを他の人に理解してもらうことも重要 ◦ このスライドの内容をあなたが理解したら、他の人にもスライドを見せてみよう
  8. © 2024 Wantedly, Inc. ウォンテッドリー社内の工夫 • ユビキタス言語を使う機会を増やす ◦ 例. 毎週金曜日にみんなでステージング環境のお触り会をする

    ◦ 例. モデリングのレビューを PM やデザイナー、フロントエンドエンジニアにしてもらう • ユビキタス言語をシステム上で表現する際はモデルに実装する ◦ UI や Controller に実装すると同じ概念の実装が重複しがちで一貫性に不安が生じる ◦ 例. モデルクラスは部品、サービスクラスは部品を組み立てる場所、という意識でコードを 書く • ユビキタス言語一覧をみんなが見れる場所に置く ◦ 例. 専用スプレッドシート