共有言語
今回は、他職種とのコミュニケーションについて書いてみたい。
開発をしていて、私がコードを書くのと同じくらい時間を割いているのは、何を作るべきかを突き止める作業だ。企画者と要件をやり取りし、デザイナーと画面をすり合わせ、ドメインを知る人に用語が何を指すのかを尋ねる。そして、この過程がずれたときのコストがコードを書き間違えたコストよりはるかに大きいことを、何度か経験してきた。
最近、James Samuelが書いたエンジニアリングリーダーの日常業務という記事を読んだ。著者はリーダーの仕事を六つに分けるのだが、最初に扱っているのが情報収集だった。あらゆる決定と方向と行動が、いま何が起きているのかについての正確な理解に依存するからだという。
私はいつかリーダーの役割を担いたいと考えているが、この箇所を読んで浮かんだのは少し違うことだった。**リーダーが最初に扱う仕事が情報収集なら、実務者にとってその対応物は要件の把握だ。**いま要件を扱っているやり方が、のちに組織の情報を扱うやり方になる。
この記事でリーダーシップの話をしたいわけではない。いま実務者として他職種とコミュニケーションを取るとき、何を間違えていて、何を道具として使えるのかという話だ。結論から言うと、私はこの問題が態度だけの問題ではないと考えるようになった。代わりに使える表現としてubiquitous languageというものがあるので、それが何なのかを見ていこう。
同じ単語、違う意味
Martin FowlerはBounded Contextという記事で電力会社の事例を挙げている。私が経験したずれのかなりの部分は、この形だった。
ここで「meter」という単語は、組織の異なる部分で微妙に違う意味を持っていた。送電網とある場所の接続なのか、送電網とある顧客の接続なのか、それとも物理的な計器そのものなのか。
here the word 'meter' meant subtly different things to different parts of the organization: was it the connection between the grid and a location, the grid and a customer, the physical meter itself
同じ「meter」という単語が、組織の部署ごとに微妙に違うものを指していたということだ。そしてFowlerは、こうした混乱が特定の事例における偶然ではないと付け加える。CustomerやProductのような多義語で同じ混乱が繰り返されるのを見てきた、というのだ。
**これは会議の参加者が会議下手だったから起きたことではない。**組織に異なる文脈があれば同じ単語が分かれていくのは自然であり、それを放置すればコードまで分かれていく。
この話の技術的な背景についてはドメインモデルで一度扱った。あのときはコードの中でモデルをどう表現するかを論じた。この記事では、そのモデルが作られる前の、人と人との対話の段階を扱う。
二つの意味を持つ単語
ではなぜ、こうしたことが構造的に繰り返されるのか。説明は二筋ある。
一つは組織構造の側だ。Mel Conwayが1968年にDatamationへ発表した論文How Do Committees Invent?は、組織が自らのコミュニケーション構造を柔軟に変えられない度合いに応じて、その組織は自分自身のイメージを、生み出すあらゆる設計物へ刻印すると述べている。一般にConwayの法則として引用される一文は、実は著者が後年みずから定式化した表現であり、1968年の本文にあるこの記述のほうが直接的だと感じる。
私がこの文から実務的に読み取ったのは「刻印する」という表現だ。用語が分かれることが対話で終わらず、成果物にそのまま残るという話だからである。先ほどの「meter」がそうだ。「meter」の範囲を互いに違う形で理解したまま各自が作れば、その差は議事録ではなく、テーブル名やAPIレスポンスのフィールドや画面の文言に残る。そしてそこからは、直すコストが会話をもう一度するコストとは比べものにならないほど大きくなる。
ここで実務者にできることとできないことが分かれる。組織のコミュニケーション構造を変えるのは実務者の手を離れている。しかし用語の境界を目に見えるようにすることは、いまの場所からでもできる。この文書で言う単語の意味がどの範囲なのかを書き留め、他のチームが使う単語と違うのなら違うと明示する作業だ。後で見る道具はすべて、その作業を楽にするための装置である。
もう一つは、もう少し根本的だ。認知科学の側から見れば、協働はそもそも共有された背景の上でしか成立しない。Herbert ClarkとSusan Brennanが1991年に書いたGrounding in Communicationは、ピアノのデュエットを例に始まる。二人の演奏者は膨大な量の共有情報、すなわちcommon groundを前提としなければ、内容を合わせることすら始められないというのだ。ここでのcommon groundは相互知識と相互信念、相互の前提を指す。そして著者らは、あらゆる集団行動がcommon groundとその蓄積の上に築かれると明言する。
私がこの二筋を並べて見たあとに得た視点はこうだ。**用語がずれるのは事故ではなく、既定の状態である。**合っている状態のほうが、維持コストを払わなければならない例外なのだ。ではそのコストを誰がどう払うのかが、実務の問いになる。
developerの役割は書き取りではない
これについて私が見つけた最も明確な答えは、Eric Evansのものだった。
Evansは2003年に出したDomain-Driven Designで、ubiquitous languageというパターンを提示する。しばしば「developerとドメインエキスパートが同じ用語を使おう」という程度に要約されるが、原書を読むと処方ははるかに具体的だ。モデルを言語の骨格とし、チーム内のあらゆるコミュニケーションとコードでその言語を粘り強く使うとチームで約束せよと求める。そしてそれに続く文が、私にとって最も重要だった。
ドメインエキスパートは、ドメインの理解を伝えるのに不自然または不十分な用語や構造に異議を唱え、developerは設計を破綻させる曖昧さや非一貫性に目を光らせる。
Domain experts object to terms or structures that are awkward or inadequate to convey domain understanding, while developers watch for ambiguity or inconsistency that will trip up design.
ドメインエキスパートはドメインの理解を伝えるのに不自然だったり不足していたりする用語と構造に異議を唱え、developerは設計を破綻させる曖昧さや非一貫性を監視するということだ。
この文を読んで、私は自分の役割についての理解を修正した。それまで私は、要件定義の会議で自分を受信者だと考えていた。企画が決まればそれを正確に受け取って実装するのが自分の仕事だと思っていた。ところがEvansが規定したdeveloperの役割は受信ではなかった。**曖昧さを見つけて返すことだ。**これは消極的な協力ではなく、積極的な監視である。
（ちなみにFowlerは自身の記事でこの文を「Domain experts should object ... developers should watch」と訳している。原書に助動詞はない。些細な差だが、原書のほうがより断定的に読める。そうするのが望ましいという勧告ではなく、そうすることがこのパターンの定義だという語調だ。）
では曖昧さはどうやって見つけるのか。Evansはここにも答えを与えている。対話で繰り返し使えば用語解釈の差が現れる、というのだ。私はこの文をこう読んだ。曖昧さは文書を精読して見つけるものではない。仕様書をどれだけ丁寧に読んでも、「会員」という単語が三つのものを指すという事実は現れない。その単語を実際の事例に当てて繰り返し使ってみて初めて分かれる。「退会した人も会員ですか？」といった質問が出る瞬間が、その地点だ。
ではなぜ、その会話がうまくいかないのか
ここまでは処方だ。問題は、私がこの処方を知りながら実践できなかった時期があるという点である。なぜ繰り返し尋ねなかったのか。
もう一度ClarkとBrennanの論文に戻ろう。著者らは、語られたことをcommon groundの一部にしていく過程にgroundingという名前を与える。そして人々がこの過程でどう振る舞うかについて、一つの原理を提示する。最小協力努力の原理（the principle of least collaborative effort）だ。人は必要以上に懸命に働くことを好まない、という観察から出てきた原理である。
ここで重要な箇所が出てくる。
最小協力努力の原理によれば、人々は必要なだけの共同努力でgroundingしようとするはずだ。しかし何に努力がかかるのかは、コミュニケーションの媒体によって劇的に変わる。
By the principle of least collaborative effort, people should try to ground with as little combined effort as needed. But what takes effort changes dramatically with the communication medium.
**努力がかかる地点が媒体によって劇的に変わるということだ。**ある媒体で使える確認手法が、別の媒体では端から不可能だったり、可能でもコストがはるかに大きかったりする。著者らは特に、話した瞬間に相手が受け取らない媒体では、他人が誤解を正してくれることを当てにするコストが非常に大きくなるため、話し手がそれを避けようとすると指摘する。
ここで一つ断っておくことがある。この論文は1991年に書かれ、著者らが比較した媒体は対面の会話や電話、手紙、留守番電話といったものだ。**SlackやNotionは扱っていない。**媒体によってgroundingコストが変わるという枠組みは著者らのものであり、それをいまの非同期な業務チャネルに適用するのは私の解釈である。
そう適用して見ると、私がなぜ繰り返し尋ねなかったのかが説明できる。仕様書をテキストで受け取ってテキストで確認する環境では、曖昧な箇所ごとに確認メッセージを送る作業はコストが大きい。答えがいつ来るか分からず、何度も尋ねると理解できていないように見えるのではないかと心配になる。だから人は自然と自分の解釈へ移っていく。
ここで力が二つあるという点を区別しておく必要がある。一つは媒体が確認コストを上げるということで、これはClarkとBrennanの話だ。もう一つは何度も尋ねると無能に見えるのではないかという心配で、これは彼らの原理が予測するものではなく、後で出てくる心理的安全性の側の話である。正確に言えば、最小協力努力の原理が予測するのはより安い確認方法を選ぶであって、確認をやめるではない。確認を畳んで推測に移るのは原理の作動ではなく、groundingの失敗だ。そしてその解釈が間違っていたという事実は、実装が終わったあとに現れる。
どこまで確認すれば十分なのか
では曖昧なものすべてについて尋ねなければならないのだろうか。それは現実的ではないし、私はそうする人を見たこともない。この問いについても論文は基準を提示している。grounding criterionだ。相手が話し手の意図を現在の目的に十分な水準まで理解したと双方が互いに信じている状態を指す。著者らはその前に、完璧な理解はそもそも不可能だという文を添えている。
私にとってこの基準が実用的に感じられた理由は、目標を下げてくれるからだ。要件を完璧に理解する必要はない。**いまやろうとしている作業に十分なだけ互いに信じられればよい。**そして著者らは、目的が変われば基準も変わらなければならないと述べる。
この部分は実務では、確認の強度を調整する基準になる。まだ方向を探っている場で「退会した人も会員ですか」に食い下がると、会話が前に進まない。その段階で必要なのは、何をなぜやろうとしているのかについての合意であって、境界値の確定ではない。逆に実装に入る直前には、その質問が必ず出なければならない。このときは「会員」がどの範囲なのかについて互いに同じものを思い浮かべていると信じられなければならず、そうでなければ誤った前提の上にコードが積み上がる。
だから私は、同じ曖昧さに出会っても**いまがどの段階かによって違う扱いをする。**探索の段階では一覧に書き留めて先へ進み、実装の直前にはその一覧を開いて一つずつ閉じていく。確認を先送りすることと確認を諦めることは別の作業だ。
この地点で併せて使いやすい道具が一つある。Matthew SkeltonとManuel PaisのTeam Topologiesは、チーム間の相互作用を三つのモードに分ける。定められた期間ともに新しいものを発見するcollaboration、一方が提供し一方が消費するX-as-a-Service、一方が他方を助けメンタリングするfacilitationだ。
もともとは組織設計の話だが、私はこれを会議単位に縮めて使うのが実用的だと感じた。**いまこの会話がどのモードなのかを互いに違う形で認識していると、会議はずれる。**企画者はすでに決まったことを伝える場だと思っているのにdeveloperはともに発見する場だと思っていれば、developerの質問は協働ではなく難癖に聞こえる。逆の場合もある。developerが確定した仕様を受け取りに来たのに企画者はまだ探索中だったなら、developerは仕様がないともどかしく感じる。
だから私は最近、会議の序盤にこれを先に確認する。「これはまだ開いているものですか、それとも決まったことを確認する場ですか？」この質問一つが、その後の会話の性格を変える。grounding criterionを目的に合わせて調整する作業と同じ話だ。
解像度が合わないと会話は空回りする
モードを合わせたとしても残る問題がある。私がよく経験したもう一つのずれは、互いに違う解像度で話している状況だった。
企画者が文章で渡してくる要件は、たいてい抽象的すぎる。「ユーザーが予約履歴を手軽に確認できるように」といった文からは、画面が何枚あるのか、どこからどこへ遷移するのかが出てこない。逆にデザイナーが渡してくる案は具体的すぎる。ボタンの色と余白まで決まっているので、肝心の「この流れは正しいのか」を議論しにくい。
BasecampのRyan Singerが書いたShape Upが、この問題を正確に突いている。ワイヤーフレームや具体的な視覚レイアウトから始めると、不要なディテールに囚われて必要なだけ広く探索できなくなる、というのだ。そこでShape Upが提案するものは、その中間の表現である。breadboardingと呼ばれ、電気工学から概念を借りている。ブレッドボードは実機の部品と配線はすべて揃っているが、工業デザインはない試作品だ。だから描くものもちょうど三つだ。遷移できる場所（places）、ユーザーが操作できるもの（affordances）、そしてその操作がユーザーをどこへ連れていくかを示す接続線（connection lines）である。
私がこの技法を良いと思った理由は、developerが作れる成果物だからだ。企画者にもっと詳しく書いてくれと頼んだり、デザイナーの案を待ったりせずに、いま理解した流れをその場で描いて「こう理解しましたが合っていますか」と返せる。Evansの言う監視（曖昧さを返すこと）を実行する具体的な方法というわけだ。そして前節の視点から見れば、これはgroundingコストを下げる装置である。一枚の図が、テキストでやり取りする何度もの確認を代替する。
ところがこの解像度は、思ったより維持するのが難しい。流れを描いていると自然に「ここのボタンは右下に置いたほうがよくないか」といった話へ降りていく。私も何度かそうなった。一度そうやって降りると、その場で議論されていた問い、つまりこの流れは正しいのかが静かに消える。まだ流れが確定していないのにボタンの位置を決めていると、後で流れが変わったときにその議論は丸ごと捨てられる。
だから私はこの段階で、わざと下手な図を保とうとする。四角と矢印と名前だけの図であれば、相手もディテールを指摘しようとせず流れにだけ反応する。図の完成度が低いことが、この道具においては機能なのだ。（きれいに描きたい気持ちを抑えるのが思いのほか難しい）
抽象化のレベルという概念そのものが協働の道具になりうるという点は、抽象化で扱った話ともつながる。あのときはコードの抽象化レベルを論じたが、対話にも同じものがある。
ルールと例と質問を分ける
解像度を合わせるもう一つの方法は、議論そのものを構造化することだ。
Cucumberプロジェクトを率いたMatt Wynneが2015年に紹介したExample Mappingがそれにあたる。彼は多くのチームが要件の議論を苦手とする理由を、構造がないせいで時間がかかり退屈になるからだと診断する。だから定期的にも一貫してもやらなくなる、というわけだ。私もまさにそうだった。要件定義の会議が長引くと次からは短く終わらせようとし、短く終わらせれば曖昧なものがそのまま残る。
Example Mappingは四色のカードで議論を分ける。黄色はいま扱っているストーリー、青はルールあるいは受け入れ基準、緑はそのルールを説明する具体的な例、そして赤は答えの分からない質問だ。
私はこの中で**赤いカードが核心だと考えている。**残りの三つは整理の技法だが、赤いカードは「分からない」を会議の正式な成果物にする装置だ。分からないという事実を口にすることが、会議を遅らせる行動ではなく、会議が生み出すべき結果になる。
これがなぜ重要かは、逆の場合を思い浮かべると明らかになる。赤いカードのない会議で曖昧な箇所に出会うと、選択肢は二つだ。いま食い下がって会議を延ばすか、先へ進んで後で一人で解釈するか。前節で見たとおり、人はたいてい後者を選ぶ。ところがカードが一枚あると、三つ目の選択肢が生まれる。**書き留めて先へ進みつつ、消えないようにすることだ。**会議は進み続け、曖昧さはなくならないまま一覧に残る。
緑のカードも似た役割を果たす。ルールだけを書けば皆が同意するが、そのルールを説明する具体的な例を書こうとした瞬間に解釈が分かれる。Evansの言う「対話で繰り返し使えば差が現れる」を会議の様式へ移し替えたわけだ。ルール一つに例を三つずつ付けてみろと言えば、そのうちの一つでたいてい「あれ、この場合はどうなりますか？」が出てくる。（私の経験上、その質問が出ない会議は皆が理解した会議ではなく、各自が違う形で理解した会議だった）
似た発想でBDDの側で長く使われてきたThree Amigosもある。ビジネスと開発とテストという三つの視点がそれぞれ違う質問を投げるというもので、Agile Allianceの用語集はその質問を、何の問題を解こうとしているのか、その問題を解く解法をどう作るのか、そしてこれはどうか何が起こりうるか、と整理している。三つ目の質問が出ない会議がどうなるかは、あえて説明しなくてもよさそうだ。
分からないことを書く欄を作る
ところで、なぜ私たちは赤いカードをうまく出せないのか。ここで心理的安全性の話をしないわけにはいかない。
Amy Edmondsonが1999年にAdministrative Science Quarterlyへ発表した論文が、チーム心理的安全性という概念を正式に打ち立てた研究だ。（論文自身は1965年のScheinとBennisの研究を源流として明かしている）チーム心理的安全性を、チームが対人関係上のリスクを取っても安全な場所だという共有された信念として定義する。分からないと言うこと、反対意見を出すこと、ミスを認めることがこれに当たる。論文は製造業企業の51チームを調査し、心理的安全性が学習行動と関連し、その学習行動が心理的安全性とチーム成果の間を媒介するという結果を示した。
ところが私がこの論文で最も実用的だと感じた文は、定義ではなくそのすぐ次だった。
たいていの場合、この信念は暗黙的である傾向がある。個人もチーム全体も当然のものとみなし、直接の注意を向けない。
For the most part, this belief tends to be tacit—taken for granted and not given direct attention either by individuals or by the team as a whole.
この信念はたいてい暗黙的であり、個人もチームも直接の注意を向けないということだ。
ここからは私の推測だ。論文が述べたのはこの信念が暗黙的だというところまでであり、だから様式を作ればよいという処方は論文にはない。ただ、暗黙的なものが宣言では変わらないというのは何度も見てきた。「うちのチームは分からないことを聞いてもいいチームです」と言うことでは、なかなか変わらない。だから私は前節の赤いカードが重要だと考えている。分からないという言葉を様式の中の欄にしてしまえば、それを埋める作業は勇気ではなく手続きになる。
もちろん反論は可能だ。安全でないチームでは赤いカードの欄もただ空のままだろう。もっともな指摘であり、この道具が安全性を生み出すと主張するつもりはない。ただ、欄があれば少なくとも**空であるという事実が目に見える。**誰も分からないことがなくて空なのか、言い出しにくくて空なのかを尋ねる場ができる。
同じ発想が実際の文書様式にも入っている。DDDコミュニティが作ったBounded Context Canvasを見ると、一つのコンテキストを設計し記録する協働ツールなのだが、欄の構成が興味深い。名前と目的、戦略的分類、ドメイン上の役割、インバウンドとアウトバウンドのコミュニケーション、そしてUbiquitous Language、ビジネス上の決定、Assumptions、検証指標、Open Questionsだ。
共有言語を書く欄と、前提を書く欄と、開かれた質問を書く欄がそれぞれ別にある。キャンバスの説明は、目的を書くという行為そのものがぼんやりした考えを明確に言語化させ、チーム全体を同じページに置くと述べている。
私はこの発想が、コミュニケーションの問題に対する最も現実的なアプローチだと考えている。人の態度を変えようとする代わりに、言いにくいことに欄を作ってやるのだ。Toss Frontend Fundamentals模擬試験リファクタリング後記を書きながらも似たことを感じたのだが、良い構造は人にうまくやれと要求する代わりに、うまくやりやすくしてくれる。
これが好みの問題ではない理由
ここまで読むと、こういう反応が出るかもしれない。良い話だが、結局はコミュニケーションを頑張ろうということではないか。それは性格の問題ではないか。
私もしばらくはそう考えていた。ところがこの部分にはデータがある。
DORAは組織文化を扱うとき、社会学者Ron Westrumの分類を持ち込む。権力志向のpathological、規則志向のbureaucratic、成果志向のgenerativeの三つだ。そしてDORAの公式文書は、自分たちの研究結果をこう要約している。
高い信頼を持ち、情報の流れを重視する組織文化は、ソフトウェアデリバリーの成果を予測する。
organizational culture that is high-trust and emphasizes information flow is predictive of software delivery performance
信頼が高く情報の流れを重視する組織文化が、ソフトウェアデリバリーの成果を予測するということだ。コミュニケーションがうまくいくチームは気分がよい、という話ではなく、成果と一緒に動く変数だという話である。
ただし、ここで予測するという言葉を因果として読んではいけない。DORAのデータは同じ回答者が文化と成果を一緒に答えた調査であり、組織レベルの相関だ。組織に満足している人が両方とも甘めに答えた可能性が残っているし、組織レベルの関係から個人はこう行動せよという処方がただちに導かれるわけでもない。だからこの資料で言えるのはここまでだ。情報の流れは好みの領域だけにあるのではなく、成果と一緒に動く場所にある。
同じ文書は、Westrumの言う良い情報の三つの性質も整理している。受け手が必要とする問いに答えを与え、時機が適切であり、受け手が効果的に使える形で提示される、というものだ。三つとも基準が受け手にあるという点は注目に値する。たくさん共有することが良い情報の流れではない。
GoogleのProject Aristotleもよく引用される資料だ。reによれば、180チームを調査し数百の変数に35以上の統計モデルを回した結果、チーム効果性に影響を与える五つの要因として心理的安全性、信頼性、構造と明確さ、意味、影響力を提示した。そして結論は、チームに誰がいるかよりも、そのチームがどのように協働したかが重要だった、というものである。
ただ一つ断っておきたい。公式ページは五つの要因を重要度順に並べていると明記しており、心理的安全性を最初に置いている。ところが、この研究を引用した記事によく見られる「圧倒的に一位」といった大きさの表現は、そのページにはない。順序があるということと、残りを圧倒するということは別の話だ。だからこの記事では大きさを主張しない。心理的安全性の重要性を語るなら、前節のEdmondsonの原論文に依るのが正確である。
ふたたびリーダーの話へ
最初に引用した記事に戻ろう。
James Samuelは情報収集を最初に扱いながら、実務者時代のやり方が通用しなくなると述べる。個人コントリビューターのときは自分の仕事の全体像を持っているが、人に対する責任を負うようになると以前のやり方は使えない、というのだ。そこで必要な力として、ノイズを取り除き情報を統合して一貫した現実の像にする能力を挙げる。どんなマネージャーもすべてを処理することはできないからだ。
私はこれが、先に見たWestrumの良い情報の三つの性質と同じ話だと感じた。たくさん集めることではなく、使える形にすることだ。そしてそれは、いま要件を扱いながらやっていることと変わらない。仕様書の文から曖昧な部分を選り分け、breadboardで描き直して確認し、分からないことを赤いカードとして残す作業こそが、ノイズを取り除いて一貫した像を作る練習である。
著者が意思決定について残した言葉も記憶に残る。確実性を待つこともそれ自体が一つの決定であり、コストを伴うということだ。要件が完全に明確になるまで待つことも同じである。だから完璧な理解ではなく現在の目的に十分な水準というgrounding criterionが、実用的な基準になる。
おわりに
まとめるとこうだ。
他職種とのコミュニケーションの失敗は、たいてい態度だけの問題ではない。組織に異なる文脈があれば同じ単語が分かれていくのが既定の状態であり、合っている状態のほうがコストを払って維持しなければならない例外だ。そのコストを払う方法が共有言語であり、その中でdeveloperの役割は要件を書き取ることではなく、曖昧さを監視して返すことである。
ところが返す作業には努力がかかり、人はその努力を最小化しようとする。だから私は意志に頼る代わりに三つを使うことにした。この会話がどのモードなのかを先に確認すること、文章とデザイン案の間の解像度で流れを描いて返すこと、そして分からないことを書く欄を会議の様式の中に作っておくことだ。三つとも態度を直せと要求せず、やりやすくする側である。
私はまだリーダーではないし、この記事に書いたこともその立場で検証したわけではない。チームの規模や組織文化が違えば通用しないものもあるだろう。ただ一つは、いま確信できそうだ。のちに情報を扱うやり方は新しく学ぶものではなく、いま要件を扱っている習慣がそのまま大きくなった形になるだろう。だから私は最近、会議で「それはどういう意味ですか」と尋ねることを、以前ほど恥ずかしがらないようにしている。
この記事を読んでくださっている方も、最近の会議でうなずいたけれど実は確信がなかった単語が一つでも思い浮かぶなら、次はその単語をもう一度使ってみることをお勧めしたい。繰り返し使えば現れる。