はじめに
先日、オンラインの飲み会に参加しました。
私は比較的新しく参加した側だったのですが、他の参加者は全員あるコンペに参加していたらしく、会話の大半がそのコンペの話でした。
参加者同士では、
この前のあれが〜
○○さんの発表が〜
最終的にあの構成になって〜
といった会話が自然に成立しています。
一方で、私はそのコンペに参加していません。
最初は、
何の話をしているんだろう？
という状態でした。
そこで飲み会中にコンペの資料や発表資料を検索して確認し、ある程度背景を理解してから会話を聞いていました。
そのとき、
これ、知らない業務システムに途中参加したときとかなり似ているのでは？
と思いました。
コードが読めても業務ドメインが分からない
新しいプロジェクトに参加すると、最初にコードを見ることがあります。
例えば、こんなコードがあったとします。
if (customer.isTarget && contract.isActive) {
await executeReview(customer);
}
TypeScriptとしては難しいコードではありません。
しかし、
-
Targetとは何を意味するのか - なぜ
Activeな契約だけを見るのか -
Reviewとは何を確認する処理なのか - どの業務ルールからこの条件が決まったのか
までは、コードを読んだだけでは分かりません。
文法は理解できても、業務上の意味が分からない。
これは飲み会で、
「あのとき○○方式に変えたじゃないですか」
と言われても、
- ○○方式とは何なのか
- なぜ変更したのか
- 以前はどうだったのか
という背景を知らなければ理解できないのとよく似ています。
身内ノリは「共有されたドメイン知識」でできている
身内ノリは、前提知識を共有する人同士の高コンテキストなコミュニケーションとも言えます。
例えば、
「昨日のあの対応、完全に前回と同じでしたね」
という一言でも、メンバーの頭の中には、
- 前回何が起きたのか
- 誰がどの対応をしたのか
- なぜ面白いのか
- どこが共通しているのか
という情報があります。
そのため説明を省略しても通じます。
これは業務システムでも同じです。
長くそのシステムを担当している人同士なら、
「これは審査側で弾けばいいですよね」
という一言で会話が成立します。
しかし新しく参加した人には、
審査とは何なのか？
から説明が必要です。
ユビキタス言語にも少し似ている
DDD（ドメイン駆動設計）では、開発者とドメインエキスパートが共通して使う言葉として「ユビキタス言語」という考え方があります。
申込、審査、承認のような言葉を、チーム内で共通した意味として扱います。
コンペでも、最終案や前回方式といった言葉が参加者の間で通じるなら、一種の共通言語ができています。共通言語があること自体は問題ではありません。問題になるのは、その言葉を知らない人がいることに気付かず、説明なしで使い続ける場合です。
Bounded Contextの外に出ると突然通じなくなる
この状況は、DDDのBounded Context（境界づけられたコンテキスト）にも少し似ています。
Bounded Contextは、モデルや言葉の意味がコンテキストごとに異なることを扱います。例えば「ユーザー」は、あるシステムでは契約者、別のシステムでは利用者や購入者を指すかもしれません。
飲み会でも、あるコンペの参加者というコンテキストでは、
「あのプレゼン」
だけで対象が特定できます。
しかし、そのコンテキストの外から来た人には何のことか分かりません。
キャッチアップは本人だけに任せない
今回、私は飲み会中にコンペの資料や発表資料を検索しました。新しい案件でも、設計書、チャットの履歴、Gitの履歴、Issue、実際の画面を手掛かりに、会話に出てくる単語の背景を補います。
自分で調べることは重要です。ただし、すべてを新しく参加した人だけに任せると、キャッチアップに時間がかかります。
会話中に「これはあるコンペで、こういうテーマに取り組んだときの話です」と一言補足するだけで理解は変わります。システム開発でも、システムが解決する課題、重要な業務フロー、頻出する言葉を最初に共有した方が、その後のキャッチアップは速くなります。
ドメイン知識はコードの外に大量に存在する
エンジニアをやっていると、
コードを読めば分かる
と思ってしまうことがあります。
しかし実際には、なぜこの仕様になったのか、なぜ例外処理が必要なのか、なぜ似た機能が二つあるのかといった情報は、コードだけでは分からないことが多いです。
長くプロジェクトにいる人はその背景を自然に知っているため、説明を省略してしまいます。新しく入った人に欠けているのは、コードを読む力ではなく背景知識なのかもしれません。
専門的なコミュニティと身内ノリは違う
専門的な話をすること自体が悪いわけではありません。
共通する技術や実践の前提知識があるからこそ、深い議論ができます。
ただし、「前回の懇親会のあれ」や「○○さんが前にやったやつ」のように、長く所属していないと分からない話ばかりになると、新しく参加した人は会話に入りにくくなります。
ドメインのコンテキストが濃いことと、身内のコンテキストが濃いことは別物です。専門的な話は深くても、新しく来た人に必要な背景だけ補足する。そのくらいが、新しい人も入りやすく、既存メンバーも深い話ができるバランスなのかもしれません。
おわりに
今回の飲み会で、
身内ノリと業務ドメインには少し似たところがある
と感じました。
共有された背景知識がある人同士では、少ない言葉でも会話が成立します。しかし、そのコンテキストを知らない人が入ると、理解は急に難しくなります。
新しいシステムに参加した人がコードを読んでも理解できないとき、技術力が足りないとは限りません。そのコードが存在する背景となるドメイン知識を、まだ持っていないだけかもしれません。
長くプロジェクトにいる側も、
この言葉は本当に全員に通じているだろうか？
と、ときどき考えてみるとよいのかもしれません。
飲み会でも、システム開発でも。