第14章導入とプロジェクトハーネス ── 明日から小さく始める

どこから始めるか

導入は、小さく始めます。まず業務フローを1本選び、【たたく】【深める】【広げる】【確かめる】を1周回してみてください。ADRの書き方、検査の掛け方、未決の残し方の勘所は、この1周でつかめます。そこから、関連する業務のまとまりへ、さらにシステム全体へと、視野を広げていきます。サイクルは、小さく回すほど早く学べます。

始めたばかりのころは、成果物どうしの参照がまだ揃っていません。それでも、シミュレーションは回せます。シナリオを歩かせるのに、参照は要らないからです。最初の1周は、シミュレーションから始めてもかまいません。

レンズと観点を、どう鍛えるか

【広げる】のレンズと観点も、回しながら育てます。何を拾えて、何を見落としたかを、定義に戻していきます。

実物があります。改訂した観点の定義の末尾に、前の版で起きた失敗と、それへの手当てが表で残っています。

注目したいのは、表に載らなかったものです。前の版で見つかった問題のうち、想像の混入、引用の精度、判断できないときの扱いは、観点の定義で直すものではないとして、検査の手順と、出力前のセルフレビューの側へ回されました。失敗を数えるだけでなく、それをどこで直すかを振り分ける。観点を鍛えるとは、そういうことです。

【確かめる】には、鍛える観点がありません。検算の問いは、ADRの制約節に書かれているからです。【確かめる】で鍛えるのは、制約節の書き方のほうです。

決定を、環境へ育てる

プロジェクトのルールや執筆ガイド、検査の観点は、いろいろなところから生まれます。組織の標準から持ち込むものもあれば、検査を回した結果や、起きた事故の振り返りから生まれるものもあります。

そのうち、ADRに残した決定から育てる道筋を、本書では発展と呼びます。同じような決定が繰り返されるなら、1件ずつADRに書いて検査し続けるより、一般化してプロジェクトの環境に組み込んだほうが、守りやすくなります。

発展とは

発展しても、ADRは消えません。状態が発展済みになり、そこから育ったルールや観点が、プロジェクトに根づきます。以後、そのルールで足りる決定は、ADRに書かなくて済みます。

ADRに残す決定の多くは、業務ルールに関する決定です。業務ルールの決定は、繰り返され方によって、育つ先が変わります。

実装で機械的に守れるものは、実行可能なテストにも育てられます。業務ルール以外の決定（成果物の書き方など）は、プロジェクトのルールや執筆ガイドへ育てます。どう守らせるかは、開始時に決めておきます。

「横断」のADRが増えてきたときも、発展の候補です。発展させるかどうかは、人が決めます。

発展させるときに守ること

ルールや観点として書いただけでは、発展したことになりません。書いただけで守られる仕組みに入っていないと、1件ずつの検査からは外れるのに、守らせるものがない状態になるからです。

発展したルールや観点は、書き換えられる文書です。決定がそこに取り込まれたあと、編集で中身が少しずつずれても、元のADRは何も言いません。だから、改めるときはADRを起票します。

また、発展させるかを判断する人は、発展させるほど自分の検査の手間が減る立場にいます。だから、判断する人の裁量に任せず、守られる仕組みに入ったかどうかで決めます。

プロジェクトハーネス

こうしてプロジェクトに整っていく環境（ルール、執筆ガイド、検査の観点、索引、それらを実行する道具）を、発展で育ったものも、それ以外から生まれたものも含めて、本書ではプロジェクトハーネスと呼びます。プロジェクトハーネスが厚くなるほど、誰が書いても一定の品質になります。育てるのは、仕様とプロジェクトハーネスの両方です。

業界でハーネスと言うときは、モデルを取り巻く実行の仕組み（使ってよいツール、hook、読ませる文脈のファイルなど）を指します（付録_出典）。プロジェクトハーネスは、それより広く、検査と執筆の環境の全体を指します。

プロジェクトハーネスの中身には、2つの種類があります。

• 強制するもの：参照の照合、【確かめる】の検算、実行の条件の固定。通らなければ、先へ進めません。
• 助言するもの：執筆ガイド、レンズ、検査の観点。読まれなければ、効きません。

業界でも、この2つをはっきり分けておくことが大事だと言われています。

1つの決定が、共通のルールになるまで

ADRの台帳の章で見た例で、発展の一巡をたどってみます。

受注の業務で、「マスタを改定しても、確定済みの伝票は改定前の値のまま表示する」と決め、ADRに残しました。しばらくして、請求の業務でも同じ問題が出ました。請求書を出したあとに単価マスタが変わったら、請求書の金額はどう見えるべきか。決めてみると、答えは受注と同じでした。発注でも出荷でも、同じ議論が起きそうです。

業務ごとにADRを書き続けることもできます。けれども、それでは同じ判断を業務の数だけ繰り返すことになり、どこかで書き忘れれば、その業務だけ違う動きになります。そこで、この決定を「伝票を持つ業務では、確定済みの伝票は、確定したときのマスタの値で表示する」という、プロジェクト共通の業務ルールにまとめました。

まとめただけでは、守られるとは限りません。そこで、【広げる】の観点に「伝票を持つ業務で、マスタの改定が確定済みの伝票に及ばないか」を足し、新しい業務の成果物を書くたびに確かめられるようにしました。ここまで来て、発展が成り立ちます。元のADRは発展済みになり、以後、伝票を持つ業務では、この点を1件ずつADRに書かなくて済みます。

1つの決定が繰り返され、共通のルールにまとまり、守られる仕組みに入る。これが発展の一巡です。

発展を、誰が回し続けるか

発展したルールや観点は、放っておくと古くなります。維持する責任者の置き方には、たとえば次の3つがあります。

メソッド自身は、どう育つか

ここまでは、1つのプロジェクトの中で決定が育つ話でした。発展には、その先にもう一段あります。

上の段へ渡すのは、下の段の発展の記録です。複数のプロジェクトで同じルールが発展していたら、それは組織の標準にする候補です。前の節の共通の業務ルールも、ほかのプロジェクトで同じように育っていれば、組織の標準にする候補になります。本書は、この上の段の受け皿です。