Mackerelチームの「ユビキタス言語を決める会」(通称:ユビ会)の活動について紹介します

こんにちは。サーバー監視SaaS・Mackerel の CRE(Customer Reliability Engineer)をやっています、id:a-know です。テクニカルサポート、カスタマーサクセス、プロダクトオーナーシップの発揮、などが最近の主な仕事です。どうぞよろしくお願いします。
今日は、私も参加しているMackerelチームの「ユビキタス言語を決める会」(通称:ユビ会)の活動について紹介します。
(この記事ははてなエンジニア Advent Calendar 2019の16日目の記事です。)

ちなみに「ユビキタス言語」そのものの説明についてはここでは割愛していますので、ご存知ない場合には事前に軽く検索などしておいていただくと、この記事の内容も楽しんでいただけるかと思います。:)

発足・参加のきっかけ:用語に対する認識の差に課題感があった

Mackerelチームでは、「"タスクフォース"を組んで課題に取り組んでいこう!」というムーブメントが、今年の前半あたりでありました。タスクフォースとは、各メンバーの本来業務の他に、注力したいタスクやテーマに対して同じ課題感を持つメンバー数人が集まって継続的に取り組む、というものです(当然、就業時間内の活動です)。このユビ会も、いくつか立ち上がったタスクフォースのひとつ、という位置付けです。

ユビ会構成員に限らず、チーム内において、以下のような課題感については以前より何度となく話題になることがありました。

  • 同じ機能や画面を指しているのに、人によって呼び方が異なっている・認識に差が出やすい用語がある
    • 「Mackerel にログインすることで表示できる画面」のことが「管理画面」と呼ばれていたり「Webコンソール」と呼ばれていたりする
  • 開発メンバーとセールスメンバー間で、用いる用語に対してゆらぎがある
    • 「無料プラン」と言ったときに、「Mackerelが提供している Free プラン」のことなのか、「協業プランとして提供しているものも含めたもの」なのか、などが曖昧だった
    • 開発メンバーとセールスメンバーとで日々メンテナンスをしているものが異なっている(プログラムコードだったり、プレゼンテーション資料だったり)というのも、用語に対する認識の差を生みやすいところなのかもしれません
  • Mackerel を利用いただいているお客さまに対しても正確な言葉で接したいが、そのための拠り所が欲しい。用語に対するチーム内での認識を揃えたい

こうしたところでの行き違いは、日々の会話においてだけでなく、機能アップデートをお知らせする公式ブログヘルプページの作成・更新をおこなう際にも、気にかけるべき点として目に見えにくい負担になっていました。

CREである私は、公式ブログやヘルプページの執筆もおこないますし、セールスメンバーに帯同してお客さまと直接会話をすることも多々あります。そんなこともあり、こうした言葉のゆらぎについては強い課題感を抱いていましたし、またタスクフォースへの参加も奨励されていたことから、ユビ会への参加に立候補しました。
Mackerel チームのメンバー全員で「この概念に対するユビキタス言語はなんだろうか?」と話し合うことができればそれが理想ではあるのですが、それではコストがかかりすぎるので、私を含めた4人のメンバーで定期的に活動していくことになりました。

ユビ会の開催状況について

ユビ会の主な活動拠点は Scrapbox です。隔週でユビ会メンバーが Google ハングアウトに接続し、チームの Scrapbox 内の「#ユビ会審議中」タグが付けられた用語について順番に議論していきます(「#ユビ会審議中」タグが付けられた用語は、ユビ会のキックオフのタイミングである程度洗い出したのと、ユビキタス言語を決めてほしいと思ったらどんどんこのタグを付けて登録しておいてね、とチーム内広報もしています)。

f:id:a-know:20191203130348p:plain
ユビキタス言語の定義テンプレートです

「確かにこれ、曖昧だよね!」という用語が話題に上がると、なぜか私はテンションが上がってしまいます。「こういうケースがあることを考慮しても、その名前を付けてしまって大丈夫ですかね?」「内部的にこう表現したくなるのはわかるけど、利用する側から考えると......」などと、できるだけ多角的にその用語が指している概念について考えて、本質的な名前が付けられるように頭を振り絞っています。一回の開催は1時間の枠で、だいたい毎回3〜4個はユビキタス言語化できているのですが、いつも会が終わるとヘトヘトになってしまっています(でも楽しいです!)。

定常的な参加メンバーは、上述のとおり4名なのですが、ときどき「おもしろそうですね」と飛び入り参加してくれるメンバーがいたりしてくれるのがとても嬉しかったりします。

ユビキタス言語を決定していくことによる効果

ユビ会による活動がおこなわれ始めて半年ほどになるのですが、正直なところ、上述の課題感が解消されつつあるか?というと、まだ完全な形ではそこまでに至っていないようには思います。それでも、先程の「Webコンソール」などはチーム内でも定着されはじめてきており、徐々にコミュニケーションしやすくなっていることを体感できつつもあります。

また、ユビ会の活動により決定したユビキタス言語に従ってヘルプドキュメントを修正できた、という目に見える成果も、すでに上がっています。

github.com

機能実装時のレビューの際にも、「ユビキタス言語ではこのようになっているので、この実装でも合わせましょう」という指摘の根拠としても活用されるようになってきています。そしてセールスメンバーの一部にも、ユビキタス言語の存在が意識されはじめてもきました。

ユビ会のゴールについて

ユビ会のキックオフのときに、「どういう状態になったらユビ会の活動を終えられるか」についても話し合ったのですが、その結論が「ユビキタス言語を決めなければ、という雰囲気がチームに生まれていて、そのための動きが自然に取られるようになったら」、ですね、という話になりました。
その観点では、「この機能の開発をする前に、ユビキタス言語を考えたほうがいいかも」という会話がだんだんと自発的になされるようになってきていることを観測しており、ユビ会の地道な活動が実を結び始めていることを実感しています。scrapbox の更新内容を slack に流していることも、良いのかもしれません。

f:id:a-know:20191203130906p:plain
Slackに通知が流れている様子。

もう少し活動を続けて、もう少しユビキタス言語の数が増えたら、そのタイミングで一度チーム内に対して代表的な用語についての認識合わせとユビキタス言語を定める重要性について喚起してみてもいいかもしれない、と考えています。

おわりに

これは個人的な感想ではありますが、ユビキタス言語を定める活動は、プロダクトの歴史を紐解き、それを踏まえた上で、今後の方向性に対しとても大きな影響を与えることになる活動だと感じています。対象のシステム・サービスを深く・広く把握していればいるほど、楽しく感じられる活動だと思いますので、みなさんが同じ課題をお持ちの場合は、ぜひ取り組んでみてもらえたらと思います。