Slide 1

Slide 1 text

© 2024 Wantedly, Inc. ユビキタス言語は バックエンドエンジニアから始めよう Wantedly x Qiita Meetup #2 Rubyを用いたプロダクト開発 Mar 1 - Sora Ichigo

Slide 2

Slide 2 text

© 2024 Wantedly, Inc. 自己紹介 名前 市古 空 (Sora Ichigo) 所属 ● ウォンテッドリー株式会社 ● 新規プロダクト開発チーム ● DevOps 推進チームリード SNS ● X: @igsr5_ ● GitHub: @igsr5

Slide 3

Slide 3 text

© 2024 Wantedly, Inc. 目次 1. はじめに 2. プロダクトを正しく作るとは 3. モデリングという役割 4. 正しく使われるモデリング 5. 業務ロジックのモレ・ダブリ 6. エッジケースの存在 7. おわりに Table of Contents

Slide 4

Slide 4 text

© 2024 Wantedly, Inc. 本発表の狙い はじめに

Slide 5

Slide 5 text

© 2024 Wantedly, Inc. 概要 話すこと ソフトウェアモデリングを通じてチームと協働する考え方 想定読者 新しくプロダクト開発に参加したバックエンドエンジニア 本スライドの使い方 バックエンドエンジニアのオンボーディング チームメンバーにバックエンドエンジニアの頭の中を知ってもらう

Slide 6

Slide 6 text

© 2024 Wantedly, Inc. 今日の発表を一言で ユビキタス言語作りは バックエンドエンジニアから始めよう

Slide 7

Slide 7 text

© 2024 Wantedly, Inc. ユビキタス言語 ユビキタス言語に関する取り組みはフロントエンドエンジニアやデザイナーが プロダクト上の UI 表記揺れやコミュニケーション改善のために行われることが多いです。 しかし本発表では、モデリングという役割を持つバックエンドエンジニアこそ、 開発段階からユビキタス言語作りを主導すべきという話をします。

Slide 8

Slide 8 text

© 2024 Wantedly, Inc. プロダクトを正しく作る 前提

Slide 9

Slide 9 text

© 2024 Wantedly, Inc. プロダクト開発の全体像 ウォンテッドリーの Visit Growth Squad の場合 ざっくり ver プロダクトマネージャー (PM) デザイナー バックエンドエンジニア フロントエンドエンジニア 要求考える アプリ作る システム作る UI/UX考える

Slide 10

Slide 10 text

© 2024 Wantedly, Inc. プロダクトを正しく作る 開発者の仕事 (良いものを) 正しく作ってユーザーに届けること 正しく作るとは 要求を、チームの認識ズレなく、最適な方法で達成すること 👉 特に認識ズレがないかは重要

Slide 11

Slide 11 text

© 2024 Wantedly, Inc. 正しく作れている状態 それぞれの関心事が共通認識を元に解決されている👍

Slide 12

Slide 12 text

© 2024 Wantedly, Inc. 正しく作れていない状態 それぞれの関心事が異なる認識を元に解決されている 󰢃

Slide 13

Slide 13 text

© 2024 Wantedly, Inc. つまり 正しく作るには 共通認識を作って、みんなで共通認識を使うことが重要 共通認識 = いわゆるユビキタス言語

Slide 14

Slide 14 text

© 2024 Wantedly, Inc. ウォンテッドリーの場合 ユビキタス言語のおかげでコミュニケーションが改善した事例 アクションリストは3つの要素から成り立つ。 ● アクションリストプライマリー ● アクションリストカンパニーリクエスト ● アクションリストセカンダリー

Slide 15

Slide 15 text

© 2024 Wantedly, Inc. 共通認識を得るためには何が必要か バックエンドエンジニアの役割

Slide 16

Slide 16 text

© 2024 Wantedly, Inc. バックエンドのモデリングという役割 結論 バックエンドエンジニアがモデリング段階から ユビキタス言語作りを意識する なぜか モデリングが機能開発の起点になるため。初めからやった方が費 用対効果が高い。

Slide 17

Slide 17 text

© 2024 Wantedly, Inc. モデリングにおいて大事なこと 1. 正しく使われるモデリングを行う 2. 業務ロジックの漏れ・ダフリを防ぐ 3. 難しい議論を同じ目線で行う

Slide 18

Slide 18 text

© 2024 Wantedly, Inc. 正しく使われるモデリングを目指す 作るだけじゃなくて使えることが大事

Slide 19

Slide 19 text

© 2024 Wantedly, Inc. モデリング バックエンドエンジニアの仕事の一つ 前提 モデリングとは「この機能に必要な要素は何?」に答える作業 xx や oo の部分

Slide 20

Slide 20 text

© 2024 Wantedly, Inc. いつか必ず共通認識になる 意図せずとも、一度行ったモデリングは必ず共通認識になる ● フロントエンドはあなたの決めたデータ構造・命名を受け取る ● 新規に施策を行う際はあなたの行ったモデリングをベースに実現手段を考える 時が来るまで "共通" 認識ではないかもしれない ● しかし、開発が続く限りいつかはやってくる

Slide 21

Slide 21 text

© 2024 Wantedly, Inc. 正しく使えるか 誰もが正しく使える共通認識か ● みんなが意図を理解できず、間違った使い方をしてしまうことはよくある ● 間違った使い方こそ認識ズレになる 使われる未来を想定したモデリングを行おう ● 共通認識は作る時ではなく、使われる際に価値を問われる どう使われるか?は話さないと分からない ● あなたの認識を言語化し、積極的に認識合わせしに行きましょう

Slide 22

Slide 22 text

© 2024 Wantedly, Inc. 業務ロジックのモレ・ダブリを防ぐ 業務知識のレベルをあげよう

Slide 23

Slide 23 text

© 2024 Wantedly, Inc. 誤った機能になるリスク ほとんどの場合 あなたはそのドメイン領域に最も詳しい人ではない 開発者の業務知識が足りぬまま行われたモデリングは的外れになり、 誤った機能を作ってしまうリスクを生む

Slide 24

Slide 24 text

© 2024 Wantedly, Inc. 業務知識のレベルをあげよう 業務知識のレベルを上げるためには チーム、特にドメインエキスパートと念入りに 共通認識を合わせよう 余談) ウォンテッドリーの場合はPMがドメインエキスパートであることが多い

Slide 25

Slide 25 text

© 2024 Wantedly, Inc. 難しい議論を同じ目線で行う 誰も理解できないエッジケースを作らない

Slide 26

Slide 26 text

© 2024 Wantedly, Inc. 難しい議論 難しい議論とは 例えばエッジケースについて議論するとき ● バックエンドは目に見えない ● そのため、自分から積極的に理解を促さないとチーム内の認識がズレやすい 結果、あなたしか理解のできないエッジケースが誕生する

Slide 27

Slide 27 text

© 2024 Wantedly, Inc. 「なぜその状態があり得るのか?」の不理解 エッジケースの対応についてチームで議論したいとき 「なぜその状態があり得るのか?」が理解されないと大変 ● 問題の理解に時間がかかる ● 問題を誤解されて妥当な結論に辿り着けない

Slide 28

Slide 28 text

© 2024 Wantedly, Inc. 対応 共通認識を起点にコミュニケーションを展開する 「この機能は xx と OO という概念で実現されている」 「xx と OO の状態の組み合わせ的にこのエッジケースが存在するんだよね、、」 👆みたいにコミュニケーションができると問題を理解してもらいやすい 前提を揃え続ける

Slide 29

Slide 29 text

© 2024 Wantedly, Inc. おわりに いざ実践

Slide 30

Slide 30 text

© 2024 Wantedly, Inc. 言うは易し行うは難し 考え方を理解しても、実際には上手くいかないことだらけ ● 「要求の認識欠けてた...」 「中々認識が揃わない...」 ● 不確実性を前提に、try&errorを繰り返すことが大事 1人ではできない ● モデリングは協働が必須、チームに協力してもらおう ○ 自分の場合、デザイナーや PM に壁打ち相手になってもらうことが多い ● バックエンドエンジニアの考えていることを他の人に理解してもらうことも重要 ○ このスライドの内容をあなたが理解したら、他の人にもスライドを見せてみよう

Slide 31

Slide 31 text

© 2024 Wantedly, Inc. ウォンテッドリー社内の工夫 ● ユビキタス言語を使う機会を増やす ○ 例. 毎週金曜日にみんなでステージング環境のお触り会をする ○ 例. モデリングのレビューを PM やデザイナー、フロントエンドエンジニアにしてもらう ● ユビキタス言語をシステム上で表現する際はモデルに実装する ○ UI や Controller に実装すると同じ概念の実装が重複しがちで一貫性に不安が生じる ○ 例. モデルクラスは部品、サービスクラスは部品を組み立てる場所、という意識でコードを 書く ● ユビキタス言語一覧をみんなが見れる場所に置く ○ 例. 専用スプレッドシート

Slide 32

Slide 32 text

© 2024 Wantedly, Inc. もっと知りたい 今日の話をもっと詳しく知りたかったら以下を調べてね ● ドメイン駆動開発 ● ユビキタス言語 ● UMLモデリング

Slide 33

Slide 33 text

© 2024 Wantedly, Inc. 宣伝 ウォンテッドリー、採用拡大中です