【アジャイルFAQ 第5回】ドキュメントが信用できない現行システム、何を『仕様』にして検証する？

 この記事を読んでいただきありがとうございます。アジャイルグループに所属する、藤井智弘です。

 更改案件の「現行機能保証」を3つのサブテーマに分けて扱う3連作、その3回目（最終回）です。第3回で「現行」の実体を見て、第4回で合意できる「全体像」を作りました。今回のサブテーマは「検証し、予算を組み、配分する」です。

 更改案件で現行システムの仕様書を開いたら、最終更新は10年前でした。コードと一致している保証はなく、現場の人に聞くと「マニュアルにはないけど、実際はこうやっている」が次々に出てきます。何を「仕様」として検証すればいいのでしょうか？ 全部を人手で突き合わせる時間はありません。しかも、想定外が見つかるたびに追加予算の話になりそうで、正直なところ、発見するのが怖いくらいです。

 第4回で、ユースケースの粒度なら全体像を合意できる一方、その中身（スライス）は現物を動かさないと分からないことを見ました。本稿は、その「分からない中身」をどう発見して検証済みに変えていくか、そして発見を受け止める予算をどう組み、どう配分するかの話です。

 結論を先に言えば、ドキュメントを信用できないなら、いちばん信用できるもの——動いている現物——を仕様にし、未知の仕様は、リリース後の事故として見つかるのを待たずに、開発中に小さく動かして見つけにいくことです。更改案件でアジャイルの型が効くのは、この「発見の手段」としてです。「ドキュメントが揃っていないから検証できない」は、「現行機能保証」「アジャイルは全件を確定しない」に続く、3つ目の思考を止める言葉です。そこで止まる前に、検証の相手を現物に替えられないか、一度考えてみましょう。

 第3回で採り上げた「仕様の3つの実体」には、それぞれ別の検証手段が要ります。

• 紙は当てにしない——ただし捨てもせず、現物との差分を探す手がかりに使う。
• コードがやっていることは、特性化テストで固定する。
• 人がやっていることは、早期の部分稼働と現場のヒアリングでしか見つからない。

      図1：3つの実装は、各々異なる検証手段で。

 以下の処方は、おおむねこの順に並べ、続けて、見つかったものの扱いをプロダクトオーナー（PO）がまとめて判断する仕組みを置いています。

実際の利用データで「本当の現行機能」を測る
 第4回で、「利用実績のない機能は移行しない」と書いたように、まずは現行システムの操作ログ、帳票の出力実績、画面のアクセス記録などの情報を集め、実際に使われている機能を特定します。この測定結果をユースケースごとに書き込みます。
 ただし年次決算、税制改正対応、災害時の代替手順のように、利用頻度は低くても法令や年次業務に必須の機能は、ログでは「未使用」に見えるかもしれません。これらは利用実績からではなく、業務カレンダーと法令要件から別途拾ってください。

特性化テストで「現物」を仕様として固定する
 特性化テスト（characterization test）は、マイケル・フェザーズが著書『レガシーコード改善ガイド』で紹介した技法で、現行システムの実際の挙動を——それが正しいかどうかを問わず——テストとして記録するものです。「この入力にはこう応答する」を現物から採取して回帰検証の網をかけ、移行後の挙動が現行と一致するかを機械的に検証します。最初の1本は、業務影響が大きく、業務部門が頻繁に使う画面の正常系から——帳票やバッチなら、現行の出力との更改版の出力の突き合わせから——始めるのが定石です。仕様書との突き合わせでは漏れがちな「コードがやっていること」を発見する、最も現実的な手段です。
 第4回で紹介したUse-Caseも、テストケースをユースケース記述の最重要部分と位置づけています。第4回の「深さ」のレベルは、実務的にはこの特性化テストをどのパターンまで採取するかで決まります——L1は最小集合のフローを通るテストが揃った状態、L2は主な代替フローまで、L3は採取できたパターン全部です。後半で扱う実測スプリントで「進んだ」と数えるのも、特性化テストで裏付けられた分だけです。

一斉切替ではなく、部分的に動かして差分を発見する
 新旧を並行稼働させて出力を突き合わせる、業務の一部領域から段階的に切り替える、シャドー運用（本番データを更改系にも流すが、結果は業務に使わず比較だけに使う運用）を行う…手段は案件によりますが、共通する考え方は「差分の発見を、リリース後から開発中に前倒しする」ことです。1回の部分稼働をどこまでにするかは、ユースケースの目的を明確にすれば（たとえば「経理担当が月初の通常請求を新系で発行できる」）、おのずと決まります。ゴールが業務の言葉で書けていれば、シャドー運用で何と何を突き合わせればよいかも決まり、発注側の担当者はそのまま社内に報告できます。
 特性化テストで守れるのは「コードがやっていること」まで。「人がやっていること」を発見できるのは、この部分稼働と現場のヒアリングだけです。昨今注目される「生成AIによるレガシー分析」も、読めるのは紙とコードまでです。その結果を「現行仕様」と信じて進めれば、第3回で見た事故の構図はそのまま残ります。発見された差分は、失敗ではなく、うれしい収穫です。第4回で、ユースケースの一覧を地図に見立てました。差分が見つかるたびに、その地図に道筋が書き足され、検証済みリストが伸びていきます。

発見された「謎の挙動」の判断はPOに集約する
 検証を進めると必ず「この挙動、仕様なのかバグなのか分からない」が出てきます。これを開発者が個別に判断すると、後で「勝手に変えた」と問題になります。謎の挙動は一覧化し、「踏襲する／直す／捨てる」の判断を発注側・POに委ねる運用を最初に合意しておきましょう。第3回で、材料を持つ末端には声を上げる機会がない、と書きました。謎の挙動の一覧は、末端の発見を発注側まで逆向きに届ける、おそらく唯一の仕組みです。

     図2：「謎の挙動」はPOにゆだねる

 決めておくべきは、次の3つです。

• 誰が判断するか
• いつまでに判断するか
• 判断が来なかったらどうするか

 決めないまま始めると、検証の途中で判断待ちが積み上がります。発見の責任は問わず、扱いを決める役割は発注側にある——この分担だけは、どの現場でも共通です。判断の記録は、次回更改のための資産になります。

残リスクは、保守運用に引き継がれる
 第3回・第4回で言及した「残リスクを、最後に誰が引き受けるか」。答えは組織によって違いますが、残リスクは案件の終了とともに消えず、第2回で見た保守運用チームに引き継がれます。だからこの問いは、引き継ぐ側も交えて最初に話しておくべきです。

 第2回で、バックログが「項目が後から流れ込むことを前提にしたリスト」であることを見ました。更改案件では、この性質がスコープ管理の意味を変えます。

 第4回の粒度を当てはめると、ユースケースの一覧は、確定として扱われる——重い手続きの側に置かれる——ほぼ閉じたリストです（足し引きは、確定したものの変更として発注側が判断します）。その下のスライスは、開いたリストです。重い手続きは一覧の層だけに残し、スライスの層は開けておく。前節の処方で発見された挙動は、代替フローとして粛々と追加していきます。第4回で「スライスの入替は承認手続きの対象にはしない（ただし記録は残す）」と書いたのは、この意味です。承認は要らなくても、追加も入替もバックログの履歴に残るので、後から追えます。そして追加を責任問題にしないこと（第3回の「洗い出し漏れの責任問題にしない」と同じ布石です）。責任追及が始まれば発見は隠され、発見のためのプロセスが止まります。

 ただし、「バックログは開いている」は、開発チームには当たり前でも、稟議や契約を管理する部門にとっては当たり前ではありません。承認なしに追加や入替が起きるプロセスは、会社の手続きから見れば例外です。ここで「アジャイルへの理解を深めましょう」と正論で押しても、相手には「べき論の押し付け」と映り、かえってブレーキになります。
 一覧の層には重い手続きを残し、スライスの層だけを開ける——この線の引き方は、過渡期の組織で回るように仕立てた折衷案です。

 バックログが開いていても、財布が閉じていれば発見は受け止められません。第4回は、全体像から量（本数×規模、それに深さの初期設定）を出すところまででした。ここでは、その量を金額に換えて器を組み、開発を進めながら器の中を配分していく話をします。稟議の制度は組織ごとに違うので、以下は答えではなく、自組織で検討するときの素材として読んでください。

稟議と契約は、別の場面
 稟議は、発注側の社内で予算の器（上限枠）を確保する場面。契約は、発注側と受注側の間で、何を約束し、何を調整の対象にし、どう支払うかを合意する場面です。契約金額は器の枠内で決まりますが、器と一致する必要はありません。稟議に出した内訳を契約の保証文言に転記しない——第3回で引いた一線は、この境界線のことです。以下は稟議の側の話です。

量を期間と金額に換える——実測を先に置く
 第4回で出した量を期間と金額に換える根拠となるのは、チームの実測値です。最初の2〜3ユースケースを実際に移行・検証してみて、1スプリントで何ポイント進むか——ユースケースの粒度で測ったベロシティ——を測ります。ストーリーで測るいつものベロシティと違うのは、数える対象がユースケースであることと、特性化テストで指定の深さまで検証済みになった分だけを「進んだ」と数えることです。深さを量にどう反映するか——L1ならその塊の何割と見るか——も、机上で決めずにここで確かめます。
 総ポイントをベロシティで割れば期間、期間にチームの月額を掛ければ金額です（例：総量120ポイント、ベロシティが1スプリント6ポイントなら20スプリント、2週間スプリントで約10か月）。実測にはばらつきがあるので、稟議に器として出すのは上限側の値にします。この換算は受注側（内製ならチーム）が提案として出し、発注側はそれを根拠に器を組みます。器が先に決まっているなら、器に収まる範囲と深さを逆算します（実測を幅で見る話と、換算した数字を何に使ってよいかの話は、今後の回で改めて採り上げます）。
 稟議の締切が実測を待てないなら、過去案件の実績を初期値にしてかまいません。ただし仮置きとし、最初の数スプリントで実測に置き換えることを、あらかじめ決めておきます。標準工数を前提にしないのは、機能ごとの工数を確定値として置くと、その内訳がそのまま契約に流れ込むからです。ここで置く初期値は、総量をまとめて期間に換えるためのベロシティです。
 この換算は、ベロシティの初期値が置けること（実測も過去実績も類推もない組織では成り立ちません）が前提です。出てくる数字は稟議のための器の上限であって、契約金額でも最終支払でもありません。以降の予算管理は、上限から検証済みの分を差し引いていく形になり、予算が余ることもあります。それは失敗ではありません。

器は固定したまま、配分の決め方を変える
 ここで前提を整理しておきます。すべての要件を予見できない以上、器全体を積み上げで見積もることはできません。とはいえ、全部が見通せないわけでもありません。移行対象のユースケースを最小集合まで仕上げる分は、第4回で見たとおり現物から数えられ、積み上げで見積もれます。積み上げられないのは、最小集合の外にある代替フローまで仕上げる分（第4回の深さL2・L3）と、検証で見つかる未知への対応分です。だから器は、積み上げる部分と、総枠から引き算で管理する部分の2層にします。
 稟議の側には、もう一つ壁が残っています。積み上げ式の稟議は、根拠の内訳がそのまま予算の使途になります。「全件リスト×単価」で通した瞬間、金額だけでなく「何に使うか」まで確定し、検証で見つかったものに応じて配分を変える余地が、制度上なくなる。発見のたびに想定外の追加稟議を上げていたのでは、本稿の処方は回りません（避けたいのは「想定外の」追加稟議であり、大枠を取って段階的に行使する稟議はそれとは別物です）。
 根本から解くなら、予算制度そのものを変える道があります。年次予算による統制をやめ、ローリング予測と動的な資源配分に置き換える **「脱予算経営（Beyond Budgeting）」**は、その代表です。ただ、積み上げ式の稟議で回っている組織が、いきなりそこへ切り替えるのは敷居が高いでしょう。そこで、いまの制度の上で踏み出せる一歩として、器は固定したまま、器の中の配分の決め方だけを変える折衷案を3つ挙げます。

 第一に、器の内訳を **「約束枠」**と 「発見枠」に分けて稟議に書きます。約束枠は、移行対象のユースケースすべてについて、最小集合（第4回のL1）まで仕上げる分。発見枠は、最小集合の外の代替フローまで仕上げる分と、検証で見つかる未知への対応分で、総額の2〜3割。従来の予備費と違うのは、発見枠の使い方の規則を稟議の中に書くことです——「検証済みリストで最小集合が達成されたユースケースのうち、業務影響の大きいものから順に、最小集合の外の代替フローまで広げる。配分は担当者が定例で決め、総額・期限を超える場合のみ再稟議」。根拠は第4回の本数×規模と前項の実測で示せるので、書式は従来のまま。加わるのは、決裁権限の一部を担当者に委ねる条項だけです。
 器を1枚のままにしないのは、以下の3つの理由からです。

• 発見への対応が、業務を止めないための最小集合の予算を食わないこと。
• 担当者に委ねる範囲を発見枠に限れば、委譲の条項が稟議を通りやすくなること。
• 予算が足りなくなったとき、見積の甘さ（約束枠の超過）と未知の多さ（発見枠の消化）を見分けられること。後者は想定内の事象なので、第3回で書いたとおり、責任問題にはしません。発見が発見枠の中に収まれば追加稟議は要らず、収まらない場合も、枠の消化状況から早い段階で見えてきます。

 第二に、稟議を2段にして、実測を先に置きます。第1段は「実測スプリント」まで——数本のユースケースを実際に移行・検証する、小額・短期の準委任。第2段は、実測でベロシティが出た後に本体の器を申請する。これは「要件定義フェーズを先に発注する」という既存の慣行と同じ形なので、積み上げ式の組織でも通ります。違うのは、第1段の成果物が要件定義書ではなく、検証済みリストの最初の数行と、実測したベロシティであること。前項の実測も、特性化テストの最初の1本も、この第1段で行います。

 第三に、年度の器は動かさず、案件の「予実＋見通し」を四半期ごとに更新します。検証済みリストの伸びとゴールの達成で見通しを更新し、発見枠の消化見込みを——余りそうなら、その見込みも——早めに示す。多くの組織が既にやっている四半期見直しの書式に、「移行対象のユースケースのうち、どこまで検証済みになったか」（第4回の「ユースケース×深さ」の表の集計）の行を足すだけです。余った予算は、代替フローをさらに仕上げるのに使うか返すかを、最後に判断します。年度の器の中で見通しを回し続けるこのやり方は、脱予算経営のローリング予測を、案件の単位で小さく試すことでもあります。

 固定するのは総額・期限・約束枠、動かすのは発見枠の配分と見通し。それを可能にするのは、配分の権限委譲を稟議に書くことと、実測の分を先に小さく稟議にかけることの2つで、どちらも新しい制度ではなく、いまの書式への一行の追記です。制度を変える前に、制度の中で試せることがある、ということです。バックログが開いているだけでは足りない。財布も、同じだけ開いている必要があります。

 更改のたびに「ドキュメントがない」と嘆かれ、更改が終わるとまたドキュメントは更新されなくなる。この連鎖には理由があります。更改の終盤は、期限に追われて「動くこと」が最優先になり、判断の記録を残す余力が真っ先に削られる。そして次の更改では、前回の判断が「なぜこうなっているのか分からない挙動」として発見され、また調査から始まる。第4回で、いま人が手作業で担っていることの多くは、前回の更改で誰かが暗黙に削った代替フローの痕跡だ、と書きました。その正体は、記録されずに削られた判断の、30年分の堆積です。

 この連鎖を断つ最初の一歩は、「嘆くこと」ではなく、今回の案件で「検証済みリスト」と「判断の記録」を残すことです。特性化テストは、検証済みリスト（第4回の「ユースケース×深さ」の表）の各マスを裏付け、現物の挙動を機械が読める形で固定し続けるドキュメントです。謎の挙動の判断一覧は、「なぜこうなっているのか」への、初めて書かれる答えです。第3回の冒頭で、判断はいつしか慣習になり、誰も疑問を持たなくなると書きました。判断一覧は、慣習になる前の判断を、理由ごと次の世代に渡します。どちらも設計書一式を書き直すより手間は小さく、次の更改を担う人は、あなたがいま抱えている「全貌が不明」という状況の、少なくとも一歩外から始められます。第4回で残した「検収の根拠に、紙に代わる何を置くか」という問いへの私の答えも、この二つです。紙を書き足すのではなく、現物から採ったものを残す。それが、何よりのドキュメントです。

 第3回の冒頭で、更改案件を扱う3本は波風を立てるつもりだと書きました。この3本で示した3つの視点——「現行」の実体を見る、合意できる全体像を作る、検証し、予算を組み、配分する——は、一つの見立てであって、正解ではありません。スクラムの型をそのまま当てたものでもなく、稟議と契約と多重下請けという日本の現場の文脈に合わせて、プロセスを仕立て直した一例です。「うちの現場では成り立たない」「稟議はそんなに単純ではない」「特性化テストの工数は誰が払うのか」…そういう異論こそ、この3本が引き出したかったものです。ぜひ職場で議論してみてください。

 これで、地雷の上から、無事に着地できたでしょうか？

次回: 「デイリースクラムが進捗報告会になっています」