この記事を読んでいただきありがとうございます。アジャイルグループに所属する、藤井智弘です。  判断の積み重ねは、いつしか慣習になります。そして一度慣習になると、誰も疑問を持たなくなります。前例踏襲という「思考停止」の完成です。今回からの3回は、そのひとつ、更改案件の「現行機能保証」を扱います。対処するには3つの視点が必要で、それぞれをサブテーマとして、3回に分けて扱います。 第3回（本稿）: 「現行」の実体を見る 第4回: 合意できる「全体像」を作る 第5回: 検証し、予算を組み、配分する  この3本のねらいは、「読者の職場に波風を立てる」ことです。「更改案件は〇〇するものだ」「アジャイルは〇〇だ」——さまざまな決まり文句が、私たちの思考を止めています。そろそろそれらに疑問の目を向けて、「ほんとにムリなのか、1回考えてみようよ」というお誘いです。  また、現実に目を向けると、稟議や契約の席にいる人たちにまでアジャイルの進め方が浸透している、あるいは会社のプロセスがアジャイルを許容している——そんな現場のほうがめずらしいでしょう。この3本は、そうした文脈に合わせてプロセスを仕立て直す一例として読んでいただければと思います。 質問 #  うちの部署の仕事は、既存システムの更改・アップグレード案件が中心です。今度の案件を「アジャイルで進める」という方針が出たのですが、正直なところ、メリットがわかりません。  発注側は「現行機能保証」を当然の前提として話を進めます。でも、現行システムの全機能を把握する手段はありません。頼みのドキュメントも、揃っている保証はなく、揃っていたとしても現物と一致している保証がない。ウォーターフォールでも苦しいのに、アジャイルは「最初に全件を確定しない」進め方のはずです。全件を求める発注側と、全件を確定しないアジャイル——噛み合う気がしなくて、違和感が拭えません。  「保証しろ、ただし、対象の全貌は不明」という状況に、アジャイルでどう向き合えばいいのでしょうか? 回答 #  いいですね、その“違和感”。その違和感や疑問を、まず大事にしてください。  JUASの「 企業IT動向調査2026 」でも、IT予算の増加理由に「既存システム・基盤の刷新・更新・増強」が挙げられています——この質問の背景は、業界の実態そのものでもあります。  そうした案件で「現行機能保証」は、対象の全貌が不明なまま全件の保証だけが約束される“魔法の言葉”ですそ。しかし、その中身は「要件は不明」の言い換えに過ぎません。そして、契約不適合責任（以前の「瑕疵担保」）との合わせ技で、発注側は受注側にリスクを転嫁できるのです。 …ちょっと刺激的すぎますか?  厄介なのは、この曖昧な文言が判定基準として使われることです。何が「現行通り」かが不明なまま全件を保証する約束は、 約束の中身を変えないかぎり、契約の形をどんなに工夫しても、実務上、履行のしようがありません 。できないと分かっていることを、片や「できないと困るんです」と押し通し、片や契約欲しさに「できます」と装っているうちは、泥沼が約束されます。  「できないことはできない」と素直に認めることが、解決のスタートラインです。  さてそこで、「メリットがわからない」に立ち戻ると…メリットどころか、 アップグレード案件は、アジャイルの適地だ と、私は考えています。ポイントは、 曖昧なものを、管理可能な形に置き換える ことです。  では、「現行」ってなんだろう？ というところから始めていきましょう。 「現行通り」の正体——仕様は1つではなく3つある #  そもそも「現行通り」とは、何を指すのでしょうか?  根本の問題は、「現行の仕様」と呼ばれるものが、実際には3つの別物の混合体であることです。 紙に書いてあること（明文化された仕様）  設計書・仕様書に“ある時点で”記録された内容です。 ある時点 では現物を反映していた かも しれませんが、最新と一致している保証はありません。この紙を持っているのは、発注側と、受注側の見積担当です。 コードがやっていること（実装された挙動）  実際にコードとして動いている挙動です。仕様書との差分——バグ修正、現場対応の改修、そもそも文書化されなかった機能——も、ここに含まれます。この情報を持っている（あるいはコードを読める）のは、保守を担当してきた開発者です。 人がやっていること（現場の使い方）  ユーザーがそのシステムをどう使って業務を回しているか、です。マニュアル外の操作手順や、既知のバグを避けるための現場の運用上の工夫を含みます。前回の更改でシステムに取り込まれず、手作業でカバーすることにした業務手順もここに入りますが、コードにも仕様書にも、まず残りません。知っているのは現場の利用者ですが、本人にとっては「仕様」ではなく、ただの日常です。だから、聞かれなければ出てきません。  「現行機能保証」と言うとき、発注側が本当に守りたいのは**3「人がやっていること」 です。しかし、契約や検収の根拠にされるのは 1「紙」 で、移行の実作業が向き合うのは 2「コード」**です。この3つは、リリースした日にはだいたい一致していたはずです。ズレを作るのは、その後の時間です。 障害対応の緊急改修で、コードだけが変わる 法改正や組織変更には、システム改修の予算が付くまで、現場の運用が先に対応する 紙は「次の大きな改修のときにまとめて直す」と後回しになる  どれも、その場では合理的な判断です。その積み重ねで、年を経るにつれ三者は別物になります。担当者の怠慢や努力不足ではなく、当然の帰結です。そしてこのズレが、更改案件で「テストは全部通ったはずなのに、リリース後に業務が止まった」事故が繰り返される、構造面での理由です。  三者は一致しない。それなのに、見積と契約の席に置かれるのは紙だけです。発注側には全件を把握する手立てが残っておらず、受注側の上層には材料がなく、材料を持つ末端には声を上げる機会がない。 誰も全件を持っていないのに、全員が全件を約束している ——これが、冒頭で「履行のしようがない」と言った約束の正体です（なぜそうなり続けるのかは、最後に触れます）。 それでもアジャイルが効く理由 #  個々の挙動の粒度で全件を把握できないなら、 その粒度では 「発見しながら進む」しかありません。これは、アジャイルの中核である経験主義——やってみて、観察して、次を調整する——そのものです。  この連載の第2回で、「新規開発系」「保守系」と分類しましたが、第3の分類が「更改系」です。更改系には、次の特性があります。 ドキュメントの完全性に期待できず、未知が多い 検証相手として現物があり、答え合わせができる いちどきに切り替えて失敗すると、業務が止まる  どれも「小さく検証を積み重ねる」進め方に向いた特性です。「既存システムがあるのだから機能は全件洗い出せる、だからウォーターフォールのほうが安全だ」と思われがちですが、実際には「洗い出せる気がしている」だけです。その前提自体が、更改系の特性と相容れません。 処方——保証を組み替える #  「全件が必要」と「全件を確定しないハズ」の対立をどうするか? 曖昧な“全件”を、管理可能な形に置き換えます。 「全件の暗黙保証」を「検証済みリスト＋残リスク」に組み替える  「全件」を、「最初に把握されているべき、最終的な全体」ではなく、検証によって伸びていくリストとして捉え直しましょう。最初にやるべきは技術的な作業ではなく、何を保証するかの再定義の交渉です。「現行機能保証」を、検証済み機能のリスト（これは保証する）と、未検証・未発見の領域に分けて管理する形に変えてみてはどうでしょう? この際、未検証・未発見の領域はリスクとして共有し、発見し次第対応します。  ポイントは、後から仕様が発見されることを、「当然起こりうること」とみなし、「洗い出し漏れの責任問題」にしないことです。残ったリスクを最後に誰が引き受けるかは、この組み替えの中で最初に話しておくべき問いです（答えは組織によって違います）。スプリントごとに検証済みリストが伸び、残リスクが減る——進捗がそのまま保証範囲の拡大として見える構図です。  ただし、この組み替えだけでは、発注側が求めている「全件」には応えられません。検証済みリストは伸びていきますが、どこまで伸びれば終わりなのか——分母がないからです。前述の組み替えが応えているのは、「全件」の裏にある本来の願い、「業務を止めない」のほうです。業務影響の大きいものから検証していけば、止まると困る業務から順に、保証の内側に入っていきます。それでも発注側には、「全体のうち、どこまで済んだのか」を見たいという、もっともな要求が残ります。その分母——全体像をどの粒度で作るか——が、次回の主題です。 見積の内訳を、保証の文言に流し込まない  「予算の器」（稟議で確保する総額と期限の枠）と「保証の範囲」（契約で「現行通り」と約束する対象）は、別物です。予算が固定であること自体は問題ではなく、問題は、稟議書の「現行機能保証」という文言が、そのまま契約の保証としてスライドすることです。器を作るのに、個々の挙動の粒度での全件洗い出しは要りません（どの粒度なら数えられるのかは第4回で、器の組み方と配分は第5回で扱います）。見積の内訳は「参考」にとどめ、契約の保証文言には流し込まない。この一線を引けるかどうかで、案件の後半の空気が決まります。 発注側の担当者と、社内説明の語彙を共有する  アジャイルっぽい用語を避け、「検証済みリスト」「残リスク」「業務影響順」という、担当者が上司やステークホルダーに進捗を説明するために使える言葉で会話しましょう。提案書や定例報告をこの語彙で組んでおけば、担当者はそのまま社内に持ち帰れます。元請と下請の間でも同じで、転記されるのが「現行機能保証」の五文字ではなく、検証済みリストと残リスクになります。本稿で挙げた調査も、説得の道具ではなく、同じ机で一緒に読む資料として持ち込むのがお勧めです。 開発者が今日できること——事故を3つに分類してみる  契約や交渉の席にいない開発者——多重下請けの最下層で、いちばん重い荷を持たされている人ほど——にも、今日できることがあります。直近の「現行通りのはずだったのに違った」を、紙・コード・人のどこの不一致だったか分類してみてください。この分類の言葉を持つだけで、障害報告が「テスト漏れでした」で終わらず「紙・コード・人のズレでした」に変わり、本稿の議論をチームで始める入口になります。 なぜこの質問は30年繰り返されるのか #  三者が一致していないことは、現場の人ならうすうす知っています。それでも紙だけが置かれ続けるのは、もっともな事情があるからです（図3）。  最初に「現行機能保証」という書式や文言を選んだ判断は、合理的で保守的だったはずです——オープン化・ダウンサイジングの波から数えて、およそ30年前のことです。問題は、その時々の臨機応変な判断が、ノウハウとして引き継がれるとは限らないことです。全件保証で乗り切れた案件は「この書式で守れた」という成功体験として稟議の前例に残ります。一方、保証を緩めてうまくいった案件の判断は、書式には残りません。だから選択は毎回少しずつ保守的な側に倒れ、それを見直す機会がないまま、担当者が入れ替わっても書式だけが引き継がれていく。「対象不明の全件保証」を抱えた案件が世代を超えて再生産されるのは、こういう仕組みです。  一度見直してみても、バチは当たらないと思うのですが、いかがですか? #  思考を止める言葉は、受注側にもあります。質問者も口にしていた「アジャイルは全件を確定しない」です。そして、両側に共通する「確定」という言葉そのものも、疑ってみる価値があります。  ウォーターフォールも、要件を本当に確定しているわけではありません。要件は変わりえます。ただ、変えれば見積額に響くので、変更管理委員会のような重い意思決定プロセスを通すことになります（少なくともPMBOKの考え方では）。その重さが「変えずに済ませよう」という動機につながり、結果として確定しているように見えるのです。  だとすれば、本当の問いは「全件を確定できるか、できないか」ではなく、「どこまでを重い手続きに載せ、どこからを手続きなしで変えられる範囲として残すか」です。では、その線をどの粒度で引けば、発注側と「全体像」を合意できるのか。次回、「機能」という言葉の粒度に踏み込みます。 次回: 「更改案件の見積を、全機能を確定せずにどう出す？」

 この記事を読んでいただきありがとうございます。アジャイルグループに所属する、藤井智弘です。  更改案件の「現行機能保証」を3つのサブテーマに分けて扱う、その2回目です。前回（第3回）は、「現行」と呼ばれるものの実体が3つあることを見て、最後に「確定」という前提を疑いました。本稿では、発注側と合意できる「全体像」の作り方を考えます。 質問 #  既存システムの更改案件で、アジャイルで進める提案をしたところ、発注側から「見積の根拠として機能一覧を出してほしい」と言われました。「アジャイルは最初に全件を確定しない進め方です」と説明すると、「では何にいくら払うのか」と返され、そこで話が止まりました。  全機能を確定せずに、稟議に通る見積と、契約で交わせる約束は、どう作ればいいのでしょうか？ 回答 #  見積の根拠として全体像を求められたら…出せます。鍵は、どの粒度で出すか、です。粒度を選べば、発注側が慣れた形の一覧と、そこからの規模感が出せます。ただしそれは、開発する中身がすべて最初に固定されることを意味しません。  第3回の最後に、問いを「確定できるか、できないか」から「 どこまでを重い手続きに載せ、どこからを手続きなしで変えられる範囲として残すか 」へ置き換えました。提出した機能一覧は、おそらく確定として扱われる——重い手続きの側に置かれます。ならば、その側に置いても守れる粒度を選び、柔軟性はその内側に残せばよい。  全体像を出すことと、柔軟さを残すことは、粒度を選べば両立します。 「全体像を見たい」は当たり前の要求——ただし、言葉の粒度が発注側と受注側で違う #  現場の支援でよく感じるのは、発注側と受注側は、同じ「機能」という言葉を使いながら、思い浮かべている粒度が違うのではないか？ ということです。受注側のアジャイルチームが思い浮かべるのは「ストーリー」——研修で、スプリント（1〜2週間）でテストまで終えるんだぞと習ったアレです。一方、発注側の頭にあるのは、予算獲得の根拠になった機能一覧——画面や帳票の単位で書かれた、ストーリーよりかなり大きな粒度です。この粒度の違いが議論の俎上に載ることは、ほとんどありません。だから、予算やスケジュールの都合で「ある機能の開発をやめる」となったとき、失うものの大きさの受け止め方が、発注側と受注側で食い違うことも珍しくありません。  粒度の認識の違いに加えて、研修で「更改系の文脈」を教わる機会がほとんどないことも、問題を難しくしています。  アジャイルの教科書や事例の多くは、新規開発系——とくにネットサービスのように、何が受け入れられるかは出してみないと分からない世界——を舞台にしています。「全件を確定しない」は、その文脈では合理的な判断です。  では、更改系はどうでしょう？ 業務はすでに回っていて、新システムの価値は、まず網羅性——抜けがあれば業務が止まる——にあり、ゴールも最初から決まっています。段階的に組み立てるには、全体を俯瞰して「今回はどこまでやるか」を選ぶ必要がある。発注側が「全体像を見せてほしい」と言うのは、「これで業務が回るのかを確かめたい」からで、当たり前の要求です。そこへネットサービスの文脈の論理——「全件を確定しない」——をそのまま持ち込めば、会話がすれ違うのも当然です。 なぜユースケースか——粒度の構造が、最初から決まっている #  「アジャイルといえばストーリー」というイメージが定着していますが、アジャイルの世界にも粒度を整理する仕組みはあります。エピックやフィーチャーといったタイプを加え、大きな括りから小さな単位へと粒度を変え、それぞれの粒度で何を見るか——事業の狙いか、利用者の使い方か——という視点まで整理する仕組みです。ただ、このタイプの扱いは手法によって異なり、粒度の設計をチームが自分で決める部分が多いため、経験の浅いチームには大きな負担になります。  そこで本稿では、粒度の構造があらかじめ定義されている ユースケース を紹介します（あくまで「選択肢を提示する」という本連載の趣旨に沿って、ひとつの選択肢として）。参考にするのは、Ivar Jacobsonらの「 Use-Case 3.0 」（Jacobson, Spence, de Mendonca, 2024年）——ユースケースを、アジャイル開発を駆動する軽い実践として整理し直したガイドで、ユーザーストーリーとの併用を前提にしています。  具体的な使い方は、のちほどサンプルでお見せします。その前に、基礎を確認しておきましょう。  ユースケースとは、「ある特定の利用者の目的を達成するための、システムの使い方のすべて」と定義できます。構成要素は3つです。 アクター （誰が） ユースケース （何のために、何ができればいいか） フロー （どうやって）—— 基本フロー （目的に至る最も単純な道筋）と、そこから枝分かれする 代替フロー （別の道筋、例外、失敗時の扱い）の束           図１：ユースケース図 。  図1は、アクターとユースケースの関係を表すユースケース図です。誰が何のためにシステムを使うのか、全体を俯瞰できます。  一つひとつのユースケースの中では、利用者が実際にシステムを操作します。その大まかな手順がフローです。  基本フローと代替フローの関係は、後述のサンプル（図2）で具体的に見ます。  このように、ユースケースには、全体を俯瞰する段（アクターとユースケース）と、個々の中身を見る段（フロー）が、道具として組み込まれています。これが「構造があらかじめ定義されている」の意味です。  ここまでを足がかりに、実際の例をみて理解を深めましょう。 請求業務で組んでみる——4つの手順と、そこで使う概念 #  ここからは、請求業務を例に、ユースケースで更改案件を組む手順を4つに分けてなぞり、各手順で使う概念をその場で定義していきます。例はあくまで一例で、手順と概念は業務を選びません。エピック／フィーチャー／ストーリーで組みたい方は、ユースケースを、お使いの手法でいちばん近い段（エピックかフィーチャー）に、スライスをストーリーの束に読み替えてください。 （1）一覧を作る——画面ではなく、目的で数える  材料は、既存の仕様書や存在するシステムから得た現行の画面一覧・帳票一覧・インタフェース一覧です。それぞれを「誰の、どの目的のためにあるか」という観点で整理してみましょう。  請求業務なら、次のような表になります。 ユースケース（アクター＋目的） 対応する現行の画面・帳票・IF 経理担当が、請求書を発行する 請求書発行画面、請求一覧画面、請求書PDF、月次一括発行バッチ、請求取消画面 営業担当が、担当顧客の請求状況を確認する 請求一覧画面 経理担当が、入金を請求と突き合わせる 入金照合画面、銀行入金IF 経理責任者が、月次の請求を締める 月次締め処理画面 経理担当が、仕訳を会計システムへ連携する 会計連携IF（夜間バッチ）  表を見ると、2つのことに気づきます。請求取消画面には、独立した目的がありません。「請求書を発行する」という大きな目的の中での処理の一つであり、ユースケースでは代替フロー（発行済みを取り消す）として組み入れられます。逆に請求一覧画面は、経理担当と営業担当が別の目的で使うので、2本のユースケースにまたがります。手動起動のバッチのように、現物から見えにくいものはヒアリングで補います。  画面ではなく目的で数えるのは、 業務が回るかどうかは、目的の集合が業務をカバーするかどうかで決まる からです。情報は現行の画面単位で集めますが、やりたいことは画面を再現することではありません。新しいシステムでは画面を一からデザインし直すことも珍しくなく、画面の数や並びは変わりえます。変わらないのは、誰が何のためにそれを使うか——目的のほうです。  こうして採った5本を、アクターとの関係で1枚に描いたものがユースケース図（前出の図1）です。誰が、何のためにこのシステムを使うのかを俯瞰でき、この時点で抽象度の高い全体像がつかめます。業務領域ごとに同じ作業をすれば、案件全体の一覧になります。この一覧が全体像の骨組みです。見積の根拠にするには、次の（2）（3）までを、移行対象のユースケースすべてについて済ませておきます。 （2）ユースケースごとに、1枚のアウトラインを書く——今把握できている範囲を明示する  次に、移行対象のユースケースごとに1枚ずつ、アウトラインを書きます。基本フローを箇条書きにし、そこから枝分かれする主な代替フローを、いま分かっている分だけ並べます。書くのは箇条書きまでで、画面項目や処理の詳細には踏み込みません。「請求書を発行する」なら、こうなります。 ユースケース: 請求書を発行する アクター: 経理担当　目的: 締め済みの取引に対して請求書を発行し、送付する 基本フロー: 1. 締め済み取引を一覧表示する → 2. 請求先を選ぶ → 3. 請求内容を確認する → 4. 請求書を発行する → 5. 送付する 代替フロー: A1 複数取引を合算して1枚にする／A2 月初に一括発行する／A3 発行済みを取り消す／A4 請求先の与信が止まっている／A5 送付先が未登録     図２：ユースケース記述（ユーザによる操作フローとバリエーション）  この1枚が、その目的のためにシステムがどう使われるかの 全体 です。A1〜A5は、いま分かっている代替フローです。この先に未発見の道筋があること、その位置が「A5の次」だと言えることが、この1枚の値打ちです。ユースケースなら、 分かっている範囲と分かっていない範囲を同じ1枚の上で言える 。全体感とは、全部を知っていることではなく、知らない部分の位置が分かっていることです。Use-Case 3.0も、ユースケースの大きさと複雑さを把握するには、この程度のアウトラインが必要だとしています。範囲外と判断したユースケースは、一覧に名前を残すだけで構いません。 （3）最小集合を決める——業務が止まらない線を引く  基本フローが通れば、業務は止まりません。ただし代替フローの中にも、削ると業務が止まるものがあります。「請求書を発行する」なら、A2（月初に一括発行する）は、月初の請求業務が手作業では回らないなら必須です。A4（与信停止）も、与信管理が法令や社内規程で定められていれば落とせません。経理部門と話して、たとえば「基本フロー＋A2＋A4」と決めます。  この「基本フロー＋必須の代替フロー」が、各ユースケースの 最小集合 で、これが受入条件になります。残りのA1・A3・A5は、後で見る「深さ」で調整する側に回ります。最小集合を業務部門と定義しておかないと、「業務が回ると言ったのに回らない」問題が起きます。最小集合も、移行対象のユースケースごとに、見積の前に決めておきます。 （4）スライスを切る——スプリントで仕上げる単位  ここからは、あるスプリントで開発に着手するユースケースだけを対象とする作業です。開発の単位は、この1枚から切り出す スライス ——ユースケースの始点から終点までを通る道筋を1本以上、テストケースごと切り出したもの——で、1スプリントで検証まで終えられる大きさに切ります。「請求書を発行する」なら、最初のスライスは「通常の請求を1件、基本フローで発行する」——テストケースは、締め済み取引1件から請求書PDFが出るまで。次に「A2 月初に一括発行する」、その次に「A4・A5 発行できない場合の扱い」をまとめて1つ、という具合に、最小集合から順に切り出します。A1とA3は未着手のまま1枚の上に残しておき、深さを上げる判断が出たときに切ればよいのです。  チームがストーリーを使っているなら、スライスを数枚のストーリーに割ってスプリントに載せます（最初のスライスなら「一覧を表示する」「請求先を選ぶ」…）。スライスは、そのスプリントのゴールとして働きます。              図３： 粒度の3段——何を「1件」と数えるか  4つの手順を通すと、粒度は3段になります。 業務領域 : 「請求業務」「在庫管理」のような括り ユースケース （発注側の「機能」に相当）: アクターと目的の組。一覧に載せ、全体像として合意し、見積る単位 スライス （スプリントゴールに相当）: バックログに載る単位。チームがストーリーを使うなら、スライスを数枚のストーリーに割って実装する              図４：  第3回で保留した「何を1件と数えるか」の答えが、これです。全件が把握できないのはスライスの粒度の話で、ユースケース（フローを含む）の粒度なら全件は現物から取れます。またこれは、画面を起点として会話を進めることで、発注側がこれまで慣れてきた粒度で全体像を議論できるようになります。そして、「その時点で把握できないもの」は、スライス以下で扱われます。「アジャイルは全件を確定しない」は、更改系に限って言えば「スライスの粒度では確定しない」です。一覧と最小集合なら、現物が有限なので、確定として扱われても——重い手続きの側に置いても——守れます。深さとスライスはその内側で、手続きなしで動かせる側に残し、内訳として約束の文言にも入れません（第3回で引いた一線です）。  ユースケースの一覧は、いわば地図として働きます。業務影響の大きいものから現物を動かして検証し、見つかった道筋を代替フローとして足していくことで、地図ができあがっていくのです。 処方——全体像を、見積と合意の道具にする # 何を約束し、何を調整するか  粒度を分けると、約束と調整を別々の段に割り当てられます。契約での「全件」の約束は、ユースケース粒度で結びます——一覧に全件を載せ、移行すると判断したユースケースは最小集合まで必ず仕上げる。調整弁は本数ではなく、各ユースケースの検証の 深さ ——最小集合まで（L1）か、主な代替フローまで（L2）か、採取済みの全フローまで（L3）か——です。スライスの入替や優先順位づけは、プロダクトオーナー（PO）と開発チームが日常的に行い、承認手続きの対象にはしない（ただし記録は残す）。ユースケース単位の取捨（利用実績のないものは「移行しない」と判断して外す、など）は、確定したものの変更として、発注側が明示的に判断します。誰がどの粒度で決めるかを最初に決めておくと、「勝手に変えた」も「全部やると言ったはずだ」も起きにくくなります。検証済みリストを「ユースケース×深さ」の表にしておくと、進捗と残リスクが発注側にもそのまま読めます。              図5：  深さを浅くしたとき、つまり最小集合の外にある代替フローを削ったときに変わるのは、その業務を「どれだけ楽に、どれだけ広い状況で」回せるかです。削った分は業務手順（手作業）で担うことになり、負担は業務部門側に移るので、代替手順の合意は削る判断とセットで行います。第3回の「仕様は3つある」に戻れば、代替フローを削るとは、意識的に「人がやっていること」を作ることです。いま人が手作業で担っていることの多くは、前回の更改で誰かが暗黙に削った代替フローの痕跡で、今回の違いは、判断の記録を残して削ることです。 稟議に載せる見積——本数×規模  稟議の時点でユースケースに書くのは、手順（1）〜（3）で作ったもの——アクターと目的の一文、基本フローと主な代替フローの箇条書き、最小集合——に、主な入出力と連携先を添える程度で十分です。画面項目定義や処理ロジック、例外の全列挙といった、ウォーターフォールなら基本設計で固める中身は、代替フローの発見と検証に委ねます。  量は、 本数×規模 で出します。本数は一覧の件数で、「ユースケース×画面」の対応表を添えれば画面一覧にも読み替えられます。規模は各ユースケースの相対サイズで、画面の項目数ではなく、代替フローが何本ぶら下がっているかという塊の厚み——「請求書を発行する」は厚く、「担当者マスタを保守する」は薄い——をポイントにします（S＝1、M＝3、L＝8など）。これに 深さの初期設定 （L1〜L3）が重なり、L1にとどめるものが多ければ総量は小さく、L3まで上げるものが多ければ大きくなります。優先度と深さの初期値の根拠には、 現行の利用実績 （利用件数・利用部署数）を使います。  見た目は「機能一覧×規模」というウォーターフォールの見積と似た形式なので、稟議の書式にそのまま載ります。ただし、ここまでは量であって、工数でも金額でもありません。量を期間と金額に換えるのはチームの実測で、その段取りは次回にまとめます。 決めておくべき問い  最小集合をどこまで細かく書くか。深さの変更手続きをどうするか。検証しても残ったリスクを誰が引き受けるか。検収の根拠に、紙に代わる何を置くか。ここから先は案件と組織で答えが違うので、本稿では決めません。大事なのは、これらの問いを同じ机で話し始めることです。稟議に載る見積を用意するのも、承認の要らない調整の範囲を先に決めておくのも、教科書どおりのスクラムではありません。いまの会社のプロセスの上で回る形に、仕立て直しています。 注意——ユースケースが「紙」に戻る瞬間  警戒すべきは、「アウトラインを超えて、ユースケース記述を全ユースケースぶん、着手前に書き込む」という誘惑です。それをやると、第3回で見た、紙だけが全件の代わりに席に置かれる構造に戻ります。紙になるか発見の道具になるかは、書式ではなく、いつ・どこまで書くかの判断の問題です。 なぜこの質問は30年繰り返されるのか #  開発標準も、契約テンプレートも、アジャイルの教科書も、「機能」を一語で語ってきました。粒度のズレが言葉に隠れている限り、どちらの側も相手が約束を破ったように感じ、その感覚が世代を超えて引き継がれます。  本稿の3段の粒度は「解」ではなく、止まっていた対話を再開するためのきっかけとなる道具です。「全件は確定できない」で終わっていた話を、「どの粒度で線を引くか」という具体的な問いに変える。「アジャイルならストーリー」も「うちは機能分解だからアジャイルは無理」も、道具と運び方を混同した思考停止です。標準の言葉ではなく、実プロジェクトの粒度で話す。それだけで、30年止まっていた会話の形は変えられるのではないでしょうか。  残るのは、スライス粒度の未知をどう発見して検証済みに変えていくか、その発見を受け止める予算をどう組み、どう配分するかです。次回、別の質問として扱います。  筆者もこれまで各種の媒体で記事を書いてきましたが、この3連作ほど、「自分はいま地雷の上に両足で乗っている」と実感したことはありません。次回は、この地雷の上で「何を仕様にして検証するのか」まで踏み込み、3本を着地させましょう。 次回: 「ドキュメントが信用できない現行システム、何を『仕様』にして検証する？」

はじめに こんにちは！セーフィー株式会社の金原です。 先日（9月5日土曜日）、Agile459（アジャイル四国）と TOKUSHIMA Cyber Security Meetup が主催するイベント「Agile Japan 2025 サテライト 徳島」にお招きいただき、徳島で脅威モデリングワークショップを実施しました。 脅威モデリングは、システムの設計段階でリスクに気づくための強力なアプローチです。また、うまく活用できればセキュリティ文化醸成やセキュリティ組織能力を上げることもできます。一方で、「覚えることが多い」「どこから始めればいいかわからない」「やってみたけどうまくいかなかっ