ユビキタス言語を「みんな」で作ったらプロダクトの理解が深まり、コミュニケーションもしやすくなった話
この記事は、SmartHR Advent Calendar 2023 シリーズ1の12日目です。
こんにちは、SmartHRでUXライターをしている8chariです。今年の7月から届出書類機能を担当しています。その中で、エンジニアやPMと一緒にユビキタス言語を作る機会がありました。
ユビキタス言語とは「ドメインに対して、同じ言葉を使い、同じモノを認識するための定義のこと」です。この記事では、どのようにユビキタス言語を作ったか、その結果どんなことを得られたかを紹介します。
ユビキタス言語づくりの機運の高まり
具体的な取り組みを紹介する前に、社内でユビキタス言語を作るプロダクトが増えてきた背景について少し触れておこうと思います。1年前に比べると、ユビキタス言語づくりに取り組むチームが格段に増えました。UXライターから作成を提案することもありますが、それ以上にPMやエンジニアから「開発を円滑に進めるために必要だから作りたい」という機運が高まっています。
その背景として、SmartHR Design System のコンテンツが充実し、UXライター以外でもUIテキストを考えやすい状態に変化したことが考えられます。エンジニアがガイドラインを参考にしながらライティングする際、残る迷いポイントは、ガイドラインで汎用的に定義されていないプロダクト固有の言葉です。汎用的なガイドラインに加え、プロダクト固有の言葉が定義されれば、より迷いなく早く必要な文言を作りやすくなります。
加えて、社内ドキュメントを通じて、ユビキタス言語づくりのメリットが社内で広く認知されるようになったことも背景にあります。この内容は、aguringoさんのユビキタス言語づくりには、どんなメリットがあるのか で公開されているので、ぜひ読んでみてください。
また、ユビキタス言語づくりを一度経験したエンジニアが成功体験をもとに、次に担当する機能のユビキタス言語づくりを始めるなど、経験者から波及していく動きもよく見かけるようになりました。
届出書類機能チームの課題
前置きが長くなりましたが、ここから届出書類機能を開発しているチームでユビキタス言語を作ることになった経緯をお話していきます。
届出書類機能は、行政手続きに関する書類作成から電子申請送信までの業務を複数名分まとめてできる機能です。機能の説明を聞くと、ユーザーストーリー自体はシンプルで、ユビキタス言語を作成するほどの難しさがあるかを不思議に思う人もいるかもしれません。しかし、エンジニアやPMに実情を聞いてみたり、開発の様子を観察していると、大きく2つの課題があるとわかりました。
言葉の定義を確認しあうコミュニケーションが発生している
開発で頻出する言葉の定義が明文化されていないことで、メンバー間で認識を確認しあうコミュニケーションが頻発しているという声がありました。
例えば、「様式」は、雇用保険被保険者資格喪失届といった書類のフォーマットを指す場合と、行政手続きのために提出する電子申請のフォーマットを指す場合の2種類があります。そのため、Aさんは書類の様式について話しているつもりでも、Bさんは電子申請の様式について話されていると思い、議論が進んでから「あれ、何だか話が合わないな」と気づいて確認するといったコミュニケーションが発生していました。
機能の土台ができあがっており、概念理解を深める機会が少ない
届出書類機能の開発チームは、開発の初期メンバー全員が異動で別のチームに移っています。そのため、現在いるメンバーはプロダクトの構造が一定できている状態、対応書類を増やすフェーズからチームに加わっています。もちろん、PRD（プロダクト要求仕様書）やソースコードからキャッチアップできる情報はありますが、プロダクトの構造や概念モデルをメンバー同士で確認しあう機会は少なかったといえるでしょう。
そのため、メンバー間で概念の理解にギャップがあっても、そのギャップにそもそも気づきづらい環境下にあったと思います。
ユビキタス言語を作るためにやったこと
こういった課題を受け、開発チームにユビキタス言語を作ることを提案しました。作成にあたり、取り組んだことは次の3つです。
作成に向けたキックオフを実施
エンジニアとユビキタス言語のたたきを作成
PMを含むメンバーとモブライティングを実施
作成に向けたキックオフを実施
ユビキタス言語の作成にあたり、ユビキタス言語とは何か、作る目的を説明し、チームで認識を揃えるためのキックオフを実施しました。実は、ユビキタス言語を作る過程で一番大事だと私が思っているのは、このキックオフです。
というのも、ユビキタス言語はユビキタスという名前のとおり「いつでもどこでも誰でも使える」ものである必要があります。UXライターだけでなく、開発に関わるメンバーで考えて作り、使っていかなければ意味がないからです。
また、特定の個人に依存した持ち物になってしまうと、その人がチームを離れた途端に形骸化してしまうというリスクがあります。「ユビキタス言語は、開発に関わるみんなのもの。だから、みんなで作って使っていこう」と認識を合わせることはとても大事です。
エンジニアとユビキタス言語のたたきを作成
次に、ユビキタス言語の作成に立候補してくれたエンジニアと一緒に、定義する言葉の選定から実際の定義のたたきを書くところまで行ないました。
オブジェクトとプロパティ、オブジェクトに対するアクションを洗い出す
オブジェクトごとにセクション分けして論理名と定義のたたきを書く
最初からきちんと書こうと思うと手が止まってしまうため、定義が不要だったものはあとから削ればよいと考え、まずは思いつくものをどんどん洗い出していきました。進める中で言語化が難しい言葉が出てきたら、まずは粗くても定義を書くようにしました。
この時点では、完璧に定義することよりも、定義のたたきを用意することを目指しました。最初から完璧な定義をチームに共有するよりも、「この定義で合っているだろうか」とメンバー間で議論することで理解が深まり、ユビキタス言語が開発に関わる人たち「みんな」のものになると思ったからです。
（当時、「自信ないけど、とにかく書きます！」と言って書き進めてくれたエンジニアykyuki21さんには感謝しかありません）
PMを含むメンバーとモブライティングを実施
ユビキタス言語のたたきを用意できたタイミングで、PMを含む開発メンバーとモブプログラミングのライティング版、モブライティングを週1ペースで実施しました。
UXライター以外にドライバーになってもらい、たたきを見て理解できるか、自分の理解と異なる部分がないかといった意見を出し合いながら、ユビキタス言語をブラッシュアップしました。また、届出書類機能のPMはドメインエキスパートでもあるため、ユーザーの実務に適った論理名になっているかといった観点でもフィードバックをもらいました。
必ずしも形式はモブライティングでなくてもいいかもしれませんが、特定の個人に閉じずに、チームで概念の定義を考える過程があるとよいです。書くときに考えていることを言語化する場面を共有できると、チームで管理していくイメージを持ちやすくなり、作ったユビキタス言語が形骸化してしまう事態が起こりづらくなると思います。
ユビキタス言語を作って得られたこと
ユビキタス言語を作っていく中で、ガイドラインに沿っていない論理名があることや、よりわかりやすい物理名にできることに気づく機会がありました。実際に、この気づきをもとにチーム内で議論し、実装に反映させた箇所が複数あります。
また、ユビキタス言語の作成を進める中で、「届出書類機能に関連するe-Govやマイナポータルの言葉も加えたい」という声があがってきました。届出書類機能の言葉ではありませんが、ユビキタス言語は「ドメインに対して、同じ言葉を使い、同じモノを認識するための定義」なので、開発に関わるメンバーが共通認識を持てるように追加することにしました。理解に不安のあった言葉が解消されていき、メンバーが共通認識を持ちたい言葉に気づきやすくなったことは嬉しい変化でした。
さらに、「機能の画面をそれぞれ何と呼ぶか、整理されていると嬉しい」という声があがり、画面名もあとから定義しました。届出書類機能のリリースノートやヘルプページは、そのほとんどをエンジニアが書いて公開しています。実際に自分たちが書く機会が多いからこそ、ユーザーに伝わる画面の呼び名に日々悩んでいました。また、チャットサポートのメンバーからも「お客様に案内するときに何と呼ぶかを迷う」という声があり、画面名を定義するとPMやエンジニアだけでなく、役立つ影響範囲が大きいという気づきも得られました。
チームのメンバーに感想を聞いてみた
実際に作ってどうだったか、届出書類機能のチームに聞いてみました。
全員から良い影響があったという回答でした。「はい」の理由についても聞いたので、一部紹介します。
ユビキタス言語を作る工程で、チーム内で認識のズレがあったことに気づく場面が多く、プロダクトの理解が深まった。
フワッと理解している概念について明確に言語化されることで、チームで共通の理解が得られるようになったと思います。
理解が怪しい単語が出てきたら、最初にユビキタス言語のページを開くようになった。また、曖昧な言葉をなるべくコミュニケーション上で使わずに、ユビキタス言語として定義されてるものを積極的に使用することで認識のズレが発生しづらくなったように思える。
ユビキタス言語を作ったことで機能の理解が深まったり、コミュニケーションしやすくなっていると言えそうで安心しました！
ユビキタス言語は作って終わりじゃない
ユビキタス言語は「開発に関わるメンバーで考えて作り、使っていかなければ意味がない」と書きました。なので、開発チームのメンバーにこんな質問もしてみました。
「当たり前だ！！！！」と「していけそう！」が半数以上を占めていて、とても心強い結果になりました。一方で、ユビキタス言語の作成に今期はあまり関われなかったメンバーもいるため、「怖いよう！」もあるリアルな結果となっています。
当たり前だ！！！（100%）
活動を始めたばかりですが、Jiraチケットに確認する項目を追加したり、ユビキタス言語のDocBaseにアクセスしやすくなっているので、気づいた時に更新していきたいです。
していけそう！（80％くらい）
初期の作成段階からチーム全員で関わっていたのでナニモワカラナイという状態からのスタートではないからかな…
ユビキタス言語を管理するぞという共通認識をチームで持てているので、気になった言葉が見つかったら安心して打ち上げられる心理的安全がある。100% でないのは、基本的な用語は出し切れたのでニッチな用語に対してどう扱うかの認識が揃えきれてないところがあるため。
ちょっと不安あるけど、いけるやろ〜（60％くらい）
チームで管理するためには全員がメンテナンスする意識を持つ必要がありますが、現在は一部のメンバーのみで管理しているため、60%くらいを選択しました。より多くのメンバーが関われるようになると、もっと自信が持てそうです！
怖いよう！（20%くらい）
修正が必要だ！となって修正したことがなく、どういう風に保守していくものなのかのイメージが掴めてないです。
ユビキタス言語は作って終わりではなく、誰もが参照しやすく更新しやすい状態を作ることが肝になってきます。更新するハードルがあがらないようにする点においては、まだ考える余地がありそうです。届出書類機能チームも、Jiraのチケットのテンプレートにユビキタス言語へのリンクを追加したり、Slackのカスタムレスポンスで簡単にユビキタス言語のドキュメントを呼び出せるようにしたりと、形骸化しないための仕組みを考えて実践しています。
さらに、今は開発チーム中心に使われていますが、チャットサポートやカスタマーサクセスなど、日々ユーザーさんと接しているメンバーも活用できる機会を広げていくことも今後の伸び代と言えそうです。
さいごに
届出書類機能のエンジニアやPMとユビキタス言語をどのように作り、活用しようとしているかが少しでも伝わっていたら嬉しいです。ユビキタス言語は「みんな」のものということを忘れずに、今後もやっていきます！
…ちなみにマイナンバー管理機能でもユビキタス言語を作ったことがあるのですが、そのときのことは記事にしなかったので、当時の開発メンバーから詰められるのではないかと怯えながら、この記事を公開しています（ごめんて）。