ユビキタス言語が定着しないのと同じ理由で、PRのWhyも形骸化する

多くの組織が、DDD(ドメイン駆動設計)を導入するとき、まず「社内全体の共通用語集を作ろう」とする。だが実際の業務では、部門ごとに同じ言葉が違う意味で使われている。shotaro_tsuji氏の指摘によれば、これを無理に一つの定義へ統一すると、かえって業務理解そのものが失われるという(出典)。

用語集を作れば作るほど、現場の理解から遠ざかる。奇妙な話に聞こえるが、理由ははっきりしている。

名前だけを切り出すと、文脈が抜け落ちる

ユビキタス言語は、単なる名前の集まりではない。氏の指摘では、言葉が指す対象の説明だけでなく、エンティティの状態遷移や業務ルールと一体になっている。それを名前だけ切り出して辞書化すると、名前という器は残るが、その名前が指していた業務の文脈は器から漏れる。

だから、部門を横断した「統一用語集プロジェクト」は、たいてい同じ失敗をたどる。営業部の「契約」と経理部の「契約」が違う状態遷移を指しているのに、一つの定義に押し込めば、どちらか一方の業務理解が切り捨てられる。用語は統一されても、その用語が本来運んでいたはずの判断は運ばれない。

エンティティのきれいさを追うと、ワークフローを見失う

氏はもう一つ、強い警告を書いている。本当に重要なのは業務のワークフローであって、エンティティのライフサイクルではない、と。

集約ごとに独立したマイクロサービスへ切り出すと、設計としては一見きれいに見える。だが、単一プロセスなら数日で済む変更が、サービス分離後は1ヶ月かかることがザラだという。エンティティという構造の美しさを追った結果、その構造がもともと支えていたはずの業務の流れを見失う。構造は正しく分割されているのに、なぜその分割が必要だったかという理由のほうが、実装から抜け落ちてしまう。

ドメインは発見するものであり、辞書に固定するものではない

ここから氏の主張は核心に入る。ドメインは最初から存在するものではなく、業務観察と実装を通じて理解を深めることで発見していくものだ、という。初期のドキュメントは叩き台に過ぎず、実装し、間違いに気付き、モデルを修正するという反復を短い間隔で繰り返すことが、DDDの本質だという。

一度作って終わる辞書ではなく、作っては書き直し続ける途中経過。ここまで読むと、この話がどこかで聞いた話に見えてくる。

PRのWhy欄も、同じ運命をたどる

PRのWhy欄やテンプレートを、多くの組織は「一度整えれば運用が回る成果物」として扱う。だが、なぜこの変更が必要だったかという理由は、ユビキタス言語と同じように、そのときどきの業務文脈と一体になっている。テンプレートという名前の欄だけを固定しても、その欄が本来指すはずだった判断の中身は、変更のたびに違う形をしている。

PRレビューでも、diffという構造だけを追いかけて、その変更が生まれた業務のワークフローを見失うことがある。コードの差分はきれいに分割されていても、なぜこの分割になったかという理由が、レビューの視界から抜け落ちる。エンティティのきれいさを追ってワークフローを見失うのと、diffのきれいさを追って判断の理由を見失うのは、同じ失敗の別の現れだ。

PRレビューツールParryが、Why(なぜこの変更か)、Risk(影響範囲)、Confidence(自信度)、Context(背景)という4項目を毎回のPRで埋めさせているのは、この欄を一度作って終わる辞書にしないためでもある。ドメインが実装のたびに発見し直されるものであるように、Whyもまた、テンプレートに一度書いて済ませるものではなく、そのPRのたびに書き直され続けなければならない。

そう考えると、Parryの四軸も、放っておけば同じ罠に落ちる。書式だけが残って、書式が本来運ぶはずだった判断が抜け落ちる未来は、ユビキタス言語の辞書が教えてくれたとおり、十分にありうる。