SaaS開発へのユビキタス言語の導入で開発プロセスを改善しサービスの質を上げる
この記事は、NAVITIME JAPAN Advent Calendar 2022の2日目の記事です。
https://adventar.org/calendars/7390
こんにちは、ちょくにゃんです。
ナビタイムジャパンで、法人向け店舗データ管理・発信クラウドサービス『NAVITIME Location Cloud』の開発・運用を担当しています。
私の所属するチームでは、提供ツールの質の向上や開発プロセスの改善を目的に、ユビキタス言語の導入を行っています。この記事では、導入の際のポイントや、効果・気づきについて書いていきたいと思います。
ユビキタス言語とは
「ユビキタス言語」とは、チーム内の共通言語のことです。ドメイン駆動設計（DDD）の文脈で用いられることが多く、ドメインモデルと一致する用語をメンバー間のコミュニケーションや開発物の設計で用いることで、コミュニケーションの円滑化や開発の効率化を図ることができます。
今回は特に、そのまま店舗データ管理ツールのUI上で使用できる用語ということを意識したものになっています。
ユビキタス言語の導入に取り組んだ背景
今回、ユビキタス言語の導入を提案したのにはいくつか理由があります。
サービス上の表記揺れを防ぎたい
サービス上に表記揺れがあると、ユーザーが機能を誤解したり操作に迷ったりすることに繋がってしまいます。現状のサービスには表記揺れがあり、課題に感じていました。
そこで、表記揺れが起きないようUIや概念について共通の用語を定めることで、サービスの質を上げたいと思っていました。
社内でのコミュニケーションロスを防ぎたい
UIや概念の名前が統一されていないことによってコミュニケーションロスが発生しているという課題もあります。私たちが提供しているサービスは一度リニューアルを行っており、その後も多くの機能が追加されているため、機能や概念の呼び名が変わっていたり新たに加わっていたりするところがあります。
そういったことにより、開発者同士ではもちろん、お客様とやりとりをする営業担当やカスタマーサクセス担当のメンバーとの間でも用語にずれが起きていることがあり、円滑なコミュニケーションの妨げになっていると感じています。用語を統一することで、共通認識を作り、コミュニケーションを改善したいと思っていました。
仕様をはっきりさせて開発速度を上げたい
特に新しい機能や概念に関わる開発の際に、仕様書の段階で表記揺れが発生してしまっている場合があります。デザイン資料と仕様書を正として検証を行うことになるため、ここに揺れがあるとその確認に時間を使ってしまい、開発速度も低下してしまいます。
ここも共通の用語を定めることで、手戻りを減らし開発速度を上げられるポイントになると考えました。
導入方法
用語の整理にはスプレッドシートを用いました。一覧性が高く、メンバーが誰でも閲覧と話し合いながらの編集ができるからです。統一した用語と、その用語の意味と表記揺れを書いた一覧表を作成しました。
既にある機能の拡張や新しい機能の検討をする際に、統一する用語の候補となりうる用語を書いていき、定期的に行われている仕様検討の場で議論して1つに定めていきました。別途専用の場を設けることはせず、必要に応じて議論したことで、負荷を大きく増やすことなく取り組むことができています。
また、誤解が生まれないよう、その用語の意味について詳しく記述するようにしています。
デザインの作成やUIの開発、検証の準備のタイミングでこの用語集を確認することで、表記揺れや認識齟齬を減らし、開発を効率化することができます。
現状40個ほどの用語について検討されており、手を入れていく箇所に応じて今後も増えていく予定です。
導入時のポイント
ここでは、導入時に重要であると感じた点について書いていきます。
一般的な用語は他サービスの意味と合わせる
サービスの画面上に現れてくる用語には、一般的なものとサービスで特有のものがあります。例えば、「登録」や「キャンセル」といった用語は他の多くのサービスでも一般的に使われているものです。こういった用語の使い方については、他の多くのサービスで使われている意味と異なった意味にならないように用途を決めていきました。
そういったなかでも、表記揺れについては注意深く判断していきました。例えば、新たにスポットを1つ増やす操作については「登録」と定め、「作成」や「追加」といった語は表記揺れとしてUI上で用いないようにしました。一方で、既に登録されたスポットの登録内容を変更する場合は、変更を開始する操作には「編集」を、変更を確定させる操作には「更新」を用いるようにするなど、場面によって使い分けることも可能にし、こだわって決めていきました。
サービス特有の用語は概念の整理から
サービス特有の用語に関しては、用語の変更を恐れず概念の整理から行いました。
例えば、データ管理している1つ1つの店舗についてサービス上では「スポット」と表記しています。お客様によっては、学習塾の教室や銀行のATM、一般ユーザーが来るのを想定していない本社や工場など、「店舗」と呼ぶには相応しくない場所を登録している場合があります。そのため、「店舗」「施設」「拠点」といった意味合いを全て含むものとして「スポット」という用語を用いることにしています。
また、こういったサービス特有の用語についてはビジネスサイドとの意見のすり合わせも大事になります。開発者の中で合意が取れていても、サービス全体として見たときに相応しくなかったり、サービス概要や使い方をお客様に説明する立場のメンバーが違和感を持っていたりする場合があります。
検討のタイミングではサービスの責任者にも意見を求めたほか、開発者以外のメンバーも参加するミーティングの場で実際にUIを操作してもらい、表現に違和感が無いか確認してもらうことでユビキタス言語としての精度を上げていきました。
サービス上に現れてこない用語も検討する
ここまではサービス上に現れる用語の統一についてでしたが、表に現れないものについても共通認識を作ることは大事です。むしろ「ユビキタス言語」というとこちらを指す場合が多いのかなと思います。
開発者同士のコミュニケーションでは、例えば開発しているツールの裏で用いているAPIについての用語が飛び交ったり、まだサービスで実装されていない新しい概念についてのやりとりが多く行われたりします。また、UIの話であっても、「サイドバー」がどの部分を指すのか、「ダイアログ」なのか「モーダル」なのかなど、ちょっとしたことで認識齟齬が生まれがちです。
少し揺れがあったとしても推し量ってコミュニケーションを取ることは十分可能ですが、そのコストは無いに越したことはありません。できれば統一しておきたいところです。
誤解の起きにくい表現を意識する
用語が統一されていたとしても、それが語弊がある表現だとチーム内のメンバーやユーザーに優しいとは言えません。
例えば、「キャンセル」という語はよく出てくる一般的な用語ですが、日本語にしてみると「中止」「中断」「解約」「取り消し」「破棄」といった感じで、現在の操作内容に応じて若干ニュアンスの異なる語に言い換えることができます。こういった用語に関しては、UI上やコミュニケーション上で誤解が起きにくい表現を選ぶようにしています。
「キャンセル」の例で言うと、登録画面で操作を取りやめる操作には「中止」（一時保存されないニュアンス）を、サービス反映待ち（仮登録・仮更新・仮削除）の状態を取りやめる操作には「破棄」（元に戻せないニュアンス）を用いるようにしました。
効果と気づき
ここからは、実際にユビキタス言語の導入を進めてみて感じた良かったことや、もっとこうすると良さそうといった気づきについて書いていきます。
正とする用語がはっきりした
これまでデザイン資料と開発物の表記に揺れがあった場合に、何が正解かわからない状態になっていました。今回ユビキタス言語を定めたことで正とする用語がはっきりしたため、デザイン資料の誤りなのか開発物の誤りなのかがわかるようになり、検証の際にもNGとすべき基準がより明確になりました。また、使うべき用語がある程度まとまっているため、デザイン作成の段階で仕様や開発物との差分が出にくくなっています。
用語への意識が高まった
用語の整理をする時間を設けたことで、メンバーの用語への意識は高まったと感じています。以前はなんとなく人や話す場によって言い方が変わっていた概念について、統一した用語を使って話せるようになってきました。もちろん以前の呼び名を使ったり言い直したりすることも多いですが、実際にユビキタス言語を使った開発物が増えていくことで徐々にコミュニケーションにおいても統一していければと思っています。
見直しをするタイミングは必要
導入方法のところでも書きましたが、ユビキタス言語は実際の開発物を触ってもらった際のフィードバックから見直しをすることも大切だと感じました。いくら概念を深く整理して用語を決めても、実際にサービス上に出たときに違和感があっては意味がないので、そのタイミングで改めてその用語が相応しいのか再検討することは必要だと思います。
コード上の用語の統一までしたい
今回のユビキタス言語の導入では、コミュニケーション中やサービス上で用いる用語についての統一までしか行えていません。開発物の設計まで踏み込んだ用語の統一というところでいうと、コード上での用語についても統一されているべきで、むしろこの部分こそユビキタス言語の本領発揮ポイントかなと思っています。
例えば、今回は「作成」や「追加」は用いず「登録」を用いることにしましたが、コード上で「create」「add」「register」と揺れが起きていてはあまり意味がありません。プルリクエストでの指摘・修正の手間を考えると最初から統一できていることが理想かなと考えています。
チーム全体への浸透は難しい
今回はビジネスサイドの意見も取り入れてはいるものの、開発チームでの用語の統一がメインになりました。元々の開発チーム以外のメンバーとのコミュニケーションロスという課題を考えると、チーム全体へユビキタス言語の使用を浸透させていく必要があります。ここはまだ働きかけができていないため、今後やっていきたいことになっています。
言い間違いを指摘しやすい空気にしたい
用語の統一を行っても浸透には時間がかかり、しばらくは気づかないうちに言い間違えていることも多くあると思います。そういった際にユビキタス言語に誘導できるようなチームの空気というのも導入する上で大事だと思いました。コミュニケーションの改善がチームの動きやすさにも繋がってくると思っています。
終わりに
というわけで、所属するチームで行ったSaaS開発へのユビキタス言語の導入方法と、それによる気づきについて書いてきました。SaaSに限らずサービス開発では有効な手法だと思いますので、参考になれば幸いです。
最後までお読みいただきありがとうございました。