文章で説得する — 設計文書とRFCが通る構造

はじめに — 3週間かけた文書にコメントが二つ

3週間かけて調査し、ベンチマークを回し、12ページの設計文書を書きます。共有すると、コメントが二つ付きます。一つは誤字の指摘、もう一つは「読みました」です。そして2か月後、何の決定もされないまま、その文書は検索でしか見つからない状態になります。

この経験をすると、たいてい「うちの組織は文書を読まない」という結論にたどり着きます。部分的には正しいのです。人は文書を読みません。ただしそれは組織固有の問題ではなく、あらゆる組織の基本条件であり、読まれないという前提の上で書かれた文書とそうでない文書とでは、通過率が違います。

この記事は、設計文書、RFC、提案書、障害後のフォローアップ勧告のような、承認が必要な文章を書く人のためのものです。説得の構造と反論の扱い方を扱った前の二つの記事が会話の状況を扱っていたとすれば、この記事は書き手がその場にいない状況を扱います。

決定を先に — 経緯ではなく決定を一番前に

エンジニアが書く文書の圧倒的多数は、自分が問題を解いた順序どおりに書かれています。背景、現状調査、比較実験、そして最後に結論。これは自分が理解に至った経路であって、読み手に必要な経路ではありません。

なぜこれが繰り返されるのかについての説明としては、知識の呪縛(curse of knowledge)がよく当てはまります。コリン・カメラー、ジョージ・ローウェンスタイン、マーティン・ウェーバーが1989年の論文で名付けた概念で、すでに知っている人は知らない状態を想像できず、知らないふりをすることが自分の利益になる場面でさえ、その情報を取り除けません。

この概念の大衆的な事例としていつも引用されるのが、エリザベス・ニュートンの1990年のタッピング実験です。ある人が馴染みのある曲のリズムを指で叩き、別の人が曲を当てる課題で、叩く側は半分くらいは当ててもらえると予測しましたが、実際の正解率は2.5パーセント前後だったという話です。ただし、これは正直に言っておいた方がよいでしょう。この研究は博士論文であり、大衆書を通じて広まったもので、繰り返し検証された結果とは言いにくいものです。 数字を引用するより比喩として使う方が安全です。概念そのもの、つまり知っている人が知らない人の状態を体系的に過大評価するということは、複数の領域で観測されている方です。

実務上の処方は単純です。第一段落に三つを入れます。何を決めてほしいのか、いつまでに必要なのか、その決定で何が変わるのか。タイトルもテーマではなく決定として書きます。「キャッシュ戦略の検討」ではなく「読み取りパスへのキャッシュ層導入提案 — 8月15日までに承認要請」です。通知一覧の中で開くべき理由がタイトルの中になければなりません。

この構成を組織レベルで強制した事例がアマゾンです。2004年に役員会議でスライドを禁止し、6ページの記述式メモを求め、会議は20から30分間、全員で黙って読むことから始まります。当時説明された理由は、記述式の文章はスライドが隠してしまう論理の隙間を露わにするから、というものでした。箇条書きで書くと、項目同士の関係と相対的な重要度が消えます。文章で書くと「したがって」や「ところが」を使わなければならず、その瞬間、論証に穴があれば自分の目にまず見えてしまいます。

却下した代替案を見せることが提案書と広告を分ける

選択肢が一つしか載っていない文書は、提案書ではなく広告です。読み手の立場からすれば、そういう文書は承認の依頼ではなく宿題です。他にどんな選択肢があったのかを自分で探し出さなければならないからです。

これを形式で強制するのがアーキテクチャ決定記録(ADR)です。文脈、決定、状態、結果の四つの欄でできており、結果の欄には良いことだけでなく、この決定によって引き受けることになるものも書くようになっています。RFCテンプレートの代替案の節も同じ目的です。

前の記事で引用したオキーフの1999年のメタ分析は、ここでもそのまま当てはまります。反対論拠を出して答えまで付けたメッセージは一面的なメッセージより信頼度も説得力も高く(42件、d = 0.16)、反対論拠を出すだけで答えなかったメッセージはむしろ悪い結果でした(65件、d = -0.10)。代替案の節を形式的に埋めるだけでは損をするということです。

代替案を一つきちんと書く形式は三行です。これが何であるかを一行、どんな条件であればこれが正解になるのかを一行、私たちの条件ではなぜそうではないのかを一行。二行目が核心です。それなしに三行目だけを書くと、藁人形を立てて叩くことになり、その事実はたいてい読み手に見えてしまいます。

例えばこうです。

外部認証サービスの導入。チーム規模が小さく監査要件が標準的であれば、この選択がほぼ常に優れています。私たちの場合は、社内の監査ログがユーザー単位ではなくセッション単位の生ログ保存を要求しており、検討した3社ともこの形式をサポートしていませんでした。

さらにもう一節を勧めます。「この提案が間違っているとすれば、その理由は」。ここに自分が答えられなかった反論を書きます。信頼を削るように見えて実際には逆であり、何より、承認後にその反論が障害として戻ってくるのを防ぎます。

何もしなかったときのコストを数字で

たいていの提案書は「これをやれば良くなります」を論証します。ところが決定者が実際に比較している対象は、他の提案ではなく現状維持です。そして現状維持側のコストは誰も書きません。だからデフォルトが勝ちます。

現状維持バイアスそのものは、サミュエルソンとゼックハウザーの1988年の研究以降、複数の領域で繰り返し観測されてきました。ただし、これを損失回避に自動的に結び付けるよくある説明には、最近かなりの反論が付いています。デビッド・ガルとデレク・ラッカーは2018年の論文で、損失が利得より一般的に強く作用するという証拠は現時点では十分でなく、文脈によって変わると整理し、これに対する再反論も続いています。ですから、「人間は損失を二倍強く感じるので損失フレームで書け」という助言は、今引用するにはリスクがあります。代わりに、ずっと単純な事実だけを書けば十分です。比較対象が文書になければ、比較は起きません。

何もしないことのコストは三つの数字で書きます。

第一に、今まさに毎週漏れ出しているもの。待ち時間、オンコール呼び出し回数、手作業の時間、ロールバック件数のような、すでに測定されているか、ログから引き出せるもので十分です。第二に、その数値の推移。半年前の値と今の値を並べるだけで、それ自体が論証になります。第三に、先延ばしにするほど後で高くつく度合い。移行対象が毎月何パーセントずつ増えているなら、その数字がそのまま遅延の利率です。

ここでよくある失敗を一つ警告しておきます。数字が作れないときに作り出してしまうことです。根拠のない投資収益率の推定が一つ入ると、文書全体の信頼性がその数字とともに下がります。そういうときは、こう書く方がずっと良いのです。

このコストは現在測定されていません。2週間あれば計測を組み込むことができ、それがこの提案の第一段階です。計測結果が週あたり5時間未満であれば、残りの段階には進みません。

流し読みする人のために書く

文書が通らない理由のかなりの部分は、読まれないからです。ニールセン・ノーマン・グループの視線追跡研究は、ユーザーが1ページで平均して全単語の20から28パーセントしか読まないと報告しており、2006年に初めて記述されたF字スキャンパターンは20年近く繰り返し観測されています。ウェブコンテンツの研究ではありますが、会議の5分前に文書を開く決定者の読み方が、これより誠実である理由はありません。

だから承認が必要な文書は、事実上二つの文書でなければなりません。30秒用と30分用です。そして30秒用は要約の節一つに収めるのではなく、文書全体に分散させておく必要があります。

具体的な手は四つです。

小見出しを名詞ではなく文章で書きます。「性能分析」ではなく「読み取り遅延の78パーセントは単一クエリから来ている」です。目次だけ読んでも論旨が伝わるなら、その文書は流し読みする人にも機能します。

段落の最初の文に結論を置きます。F字パターンが観測される理由は、人が各段落の前半だけを読んで先に進むからです。段落を根拠から始めて結論で終えると、その結論は読まれません。

表は比較にだけ使います。表は視線を引き付ける強い要素なので、比較でない内容を表にすると、読み手の注意を重要でない場所で消耗させてしまいます。

太字は節あたり一つに制限します。三か所太字にすると、太字がないのと同じになります。そして論証は箇条書きで書きません。箇条書きは項目が並列のときにだけ誠実であり、根拠同士に因果や条件の関係があると、その関係を消してしまいます。アマゾンがスライドを禁止した理由とまったく同じことです。

自分がいない部屋で伝わる段落

実務で最も重要なのに、ほとんど誰も訓練しないのがこれです。あなたの文書は、あなたがいない会議で引用されます。 上長がその上の会議に持ち込んだり、他チームの人が自分のチャンネルにコピーして貼り付けたり、半年後に誰かが検索で見つけたりします。そのとき生き残るのは文書全体ではなく、段落一つです。

その段落が備えるべき条件は四つです。

前の文脈なしで成立しなければなりません。「上で述べた方式」「この問題」「該当のコンポーネント」といった表現が入ると、切り出した瞬間に意味を失います。固有名詞と具体的な対象名を使います。

数字と日付が段落の中になければなりません。引用する人が改めて探しに行く必要がないようにします。

要求がその中に入っていなければなりません。状況説明だけが残ると、引用された場所で何も起きません。

長さは二、三文でなければなりません。コピーして貼り付けられる大きさを超えると、引用されずに要約されます。要約された瞬間、統制力を失います。

ここにもう一つ付け加えられます。同じ文を同じ形で繰り返すことです。繰り返し提示された言明がより真実らしく評価される現象は、説得の文献の中でも比較的よく持ちこたえてきた結果に属します。デシェーヌの研究チームによる2010年のメタ分析は51件を統合してd = 0.39から0.50程度を報告し、最近の大規模な再統合でも、小規模研究のバイアスを補正した後にg = 0.37が残りました。実務的な含意は、文書を書くたびに表現を新しく整え直すな、ということです。毎回違う書き方をすると繰り返しの利得が消え、組織の中には互いに少しずつ異なる複数のバージョンが漂うことになります。

限界も併せて記しておきます。この効果は文の真偽を区別しません。だから繰り返しは技法ではなく責任です。自分が検証した文だけを繰り返すべきで、後で間違っていたと判明したら、同じ強さで訂正を繰り返さなければなりません。

弱い提案の段落を書き直す

実際によく見かける形の第一段落です。

現在、弊社の認証モジュールには様々な問題があります。レガシーコードが多く、テストカバレッジも低く、最近は保守の難易度も上がり続けています。チーム内でも改善が必要だという共感はある程度形成されている状況です。これを踏まえ、認証モジュール全体のリファクタリングを提案いたします。詳細は以下で説明します。

文法的には問題なく、誠実に見え、何も起こしません。ないものを数えるとこうなります。求める決定がありません。「提案いたします」は決定の要求ではありません。数字が一つもありません。「問題が多い」は反論できませんが、同時に何の情報も与えません。何もしなかったときのコストがありません。検討した代替案がありません。期限がありません。そして文脈なしに切り出すと、どの会社のどの文書から切り出したのか分かりません。

同じ内容を書き直します。

認証モジュールのトークン検証パスを、8月第3週から3週間かけて置き換えることの承認をお願いします。過去6か月の障害12件のうち5件がこのパスから発生しており、この5件の平均復旧時間は47分で、他ドメインの平均の2倍です。今手を付けなければ、9月のソーシャルログイン作業が同じコードに再び触れることになり、その時点では元に戻す対象が2倍になります。全面書き換えと外部認証サービスの導入も検討しましたが、前者は4か月以上が必要で、後者は社内監査ログのセッション単位での生ログ保存要件を満たせませんでした。失敗基準は明確です。3週間以内に既存の統合テストが全て通過しなければ、元に戻し、9月の作業は現行コードの上で進めます。

一段落に六つが入っています。求める決定と期限、最も強い根拠である実測値、何もしなかったときのコスト、却下した代替案二つとその理由、そして失敗基準。どの会議にコピーして貼り付けても、それ自体で判断が可能です。

長さは伸びました。この交換はおおむね割に合う取引です。短い文書は読まれ、完結した段落は決定されます。会議で同じ内容を口頭で説得しなければならない状況なら、システム設計面接の準備の回で扱った口頭説明の構造が参考になります。

文書で実際に効く手

八つのうちどれも文才を要求しません。すべて配置と項目の問題です。文章で説得する能力の大半は、文章力ではなく何をどこに置くかについての判断です。

おわりに — 承認が撤回より安くなるように

文書で説得するということは、読み手の心を変えることではありません。承認する側のリスクが承認しない側のリスクより小さく見えるように、提案そのものを設計することです。 失敗基準を提案者が先に書き、元に戻す方法を記し、答えられなかった反論を露わにすることが、すべてその方向に働きます。

次に書く文書で、二つだけ変えてみてください。第一段落を求める決定から始めること、そして文脈なしでも成立する段落を一つ作っておくこと。残りは、その二つが定まった後に付け足しても遅くありません。