こんにちは、ProgateのLearningExperienceチームでテックリードをしている森田です。 主にサーバーサイド開発をしています。 今回はProgateで行っているユビキタス言語策定活動について紹介したいと思います。
※ 本記事は Progate Advent Calendar 8日目の記事です。
ユビキタス言語が必要になった経緯
発端となった課題感は、大雑把にいうと「定義が曖昧な単語を使うと、余計なコミュニケーションコストがかかる」です。 この課題感が現れるパターンとしては、主に以下の3つでした。
- 同じものを指しているのに人によって違う単語を使っている
- 同じ単語を使っていても人によって微妙に違うものを指している
- 単語が一般的な意味とずれた意味で使われている
上記のパターンで所々混乱が生じ、コミュニケーションコストがかかっている状況にありました。
課題にどうアプローチしていくか
この課題を解決するために、ユビキタス言語を策定しています。 ただし、プロダクトの全ての機能について細かい言葉の定義をするのは大変な時間がかかります。 そこで、まずはプロダクトのもっとも大事なコアドメインに絞ってユビキタス言語を作ることにしています。 弊社が提供している初心者向けプログラミング学習サービスProgateでは、環境構築せずにコードを書いて実行できる演習画面がサービスの強みであり、この演習画面の周辺領域をコアドメインとして位置付けています。 なので、この領域を担当するLearningExperienceチームがこの領域に限定してユビキタス言語を作っています。
ユビキタス言語策定活動の成果物として、以下の2つを作っています。
- ユビキタス辞書
- ドメインモデル図
成果物1: ユビキタス辞書
ユビキタス言語に現れる単語は「ユビキタス辞書」という名前のスプレッドシートにまとめています。 単語の定義がわからないときのリファレンスとなっていて、また、作ることによって単語の定義の認識あわせを強制される、という側面もあります。
辞書には以下のようなカラムを設けています。
| カラム名 | 役割 |
|---|---|
| status | 確定状態。To Discuss, In Discussion, Confirmed の3つの状態をとりうる |
| en | 英語名 |
| ja | 日本語名 |
| not recommended | 非推奨名称。複数の単語が同じものを指して使われていた場合は、使われくなった単語をここに記載する |
| meaning | 単語の意味 |
| links | 参考になるドキュメントなどへのリンク |
成果物2: ドメインモデル図の作成
ユビキタス言語策定活動が始まった初期は、しばらく辞書だけで運用していました。 ただ、運用していく中で辞書だけでは概念同士の関係性や全体像がわかりにくいということがわかりました。 そこで、ドメインモデル図を作成することになりました。
v1作成
巷で見るドメインモデル図では、
- オブジェクト名
- プロパティ
- その他ビジネスルール
が書かれていることが多いですが、いきなりそこまで持っていくのはハードルが高いと感じました。そのため、まずは既存のプロダクトにある概念を洗い出し、オブジェクト名だけでドメインモデル図に追加していきました。そうして出来たのが、こちらのドメインモデル図v1です。
ツールはfigmaを使っています。 灰色になっているオブジェクトは、実装都合で存在しているが、うまくモデリングできていないオブジェクトです。 ある程度歴史が長いプロジェクトで、今までモデリングを意識せずに開発されていると、どうしてもこういうものは発生してしまうのですが、これらを図に載せないと全体像が理解できないと考えて、色を区別して載せることにしています。 今後うまくモデリングできた際には、リファクタリングしたいと考えています。
v2作成
v1の状態でしばらく運用しましたが、概念の定義や名前について細かい話をするときに、具体的なプロパティについても認識が合わないと、議論が噛み合わないことがしばしば発生しました。 そこで、プロパティも追加したドメインモデル図v2を作りました。
現在はこちらの状態で運用しています。
運用
絶えず変化しているプロダクトにおいて、ユビキタス言語は一度作ったから終わりではなく、プロダクトの変化とともに更新し続ける必要があります。 Progateでは、週一のMTGを開催して、
- 既存のユビキタス辞書・ドメインモデル図に対する問題提起
- 改善案の議論
- 新機能のモデリング・名前決め
などをやっています。 メンバーは、Learning Experienceチームの各職種の代表者（チームリード、コンテンツプランナー、デザイナー、エンジニア）と、英語名を考えるためにi18nチームのチームリードの計5人です。挙がる議題によっては、議題に関連する別のメンバーに参加していただくこともあります。 名前に関する認識のずれは職種間で一番発生しやすいため、職種が偏らないように各職種の代表が参加しています。
基本的なフローはこんな感じです。
- 話したい議題がある場合は自由にユビキタス言語用のasana boardに積む
- 週一のMTGで議題について結論を出す
- チーム全体に結論を共有（Slackまたはチーム定例）し、意見や改善案があれば再び議論する
- 実装の修正が必要な場合はチームの開発タスクを管理するasana boardにタスクを積み、チームリード判断でリソースを割り当てる
- 実装が完了し次第、辞書やドメインモデル図に修正を加え、再びチーム全体に共有
ただ、このように綺麗に進まない場合もあります。
- 議論を通して結論が出たものの、近い将来に大きく手が入る可能性が高く、その時に実装を修正した方が効率的と考えられるケース
- → asana boardの
to fixカラムに積んでおき、効率よく修正できるタイミングを待つ
- → asana boardの
- 現状の名前に問題があることは認識しているが、議論をしてもなかなか結論が出ない且つ優先度が低いものや、直近で仕様が変わりそうなので今議論しても無駄になりそうなケース
- → asana boardの
いつかやるカラムに積んでおき、問題の存在は記録に残しつつ後回しにする
- → asana boardの
ユビキタス言語をより浸透させたい、混乱をうむ単語をなくしたい、という思いがいくら強くても、無限のリソースがあるわけではありません。上述のように、問題を認識しつつ敢えて解決は後回しにすることもものによっては必要だというスタンスで運用しています。
成果
ユビキタス言語を作り始めてから、いくつか実感できる成果（客観的・定量的ではありませんが）が見え始めています。
- 会話・ドキュメント・コードで単語やその定義について迷わなくなった
- あらかじめモデリングと名前決めが済んでいる場合は、実装に入る際に「この概念はこの名前が正しいのか？」「この概念が指す範囲はどこまで？」みたいに迷うことが減りました。
- 新メンバーの理解の助けとなっている
- 中規模以上のプロダクトだと、新メンバーが全体像、登場人物を理解するまでは時間を要するものですが、嬉しいことに「ユビキタス言語のおかげで理解が進みました！」という声を頂きました。
- 新機能の仕様について認識を合わせやすくなった
- 新機能を実装する際には新しい単語がミーティングやドキュメントにて飛び交いますが、これらの単語の統一的な名称が決まっていなかったり、定義が曖昧な場合は、細かい仕様について認識を合わせにくくなります。ユビキタス言語を作るようになってから実装が始まった（LearningExperienceチーム担当の）新機能は、実装に着手する前にドメインエキスパートを巻き込んでモデリングと名前決めをしています。これによって、（もちろんゼロにはなりませんが）認識のずれや考慮漏れが発生しにくくなっています。
- 直感的じゃない名前を修正し、口語、コード、ドキュメントがよりわかりやすくなった
今後の課題
ユビキタス言語の辞書やドメインモデル図がある程度形になって、運用のフローも定まりましたが、まだまだ足りない部分もあります。
- 既存のうまくモデリングできていない、かつ、影響範囲が大きい部分に関してはまだ改善できていない
- 新機能は最初からモデリングして名前を決めることができたのでいいが、既存の機能に修正を加えるとなると、影響範囲は大きいものもあります。
- そして、モデルのプロパティ名がDBのカラムと密結合していたり、静的型付け言語のように一括置換でコードの名前を書き換えることもできないことも多少弊害になっていると感じています。
- 長期的にユビキタス言語を運用し続け、今後タイミングを見て変更を加えていきたいと思っています。
- ユビキタス言語の浸透
- ユビキタス言語の辞書を作り、ドメインモデル図を作っても、まだスタートラインに立ったばかりです。今後、運用し続けることによって、文化として根付かせていく必要があります。
最後に
いかがでしたでしょうか。自分の会社でもユビキタス言語を作って運用したい、と思う方に少しでも参考になれば幸いです。 また、Progate では絶賛採用活動中です。カジュアル面談もやっているので、興味があれば是非お話しましょう！
