【アジャイルFAQ 第4回】更改案件の見積を、全機能を確定せずにどう出す？

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

 更改案件の「現行機能保証」を3つのサブテーマに分けて扱う、その2回目です。前回（第3回）は、「現行」と呼ばれるものの実体が3つあることを見て、最後に「確定」という前提を疑いました。本稿では、発注側と合意できる「全体像」の作り方を考えます。

 既存システムの更改案件で、アジャイルで進める提案をしたところ、発注側から「見積の根拠として機能一覧を出してほしい」と言われました。「アジャイルは最初に全件を確定しない進め方です」と説明すると、「では何にいくら払うのか」と返され、そこで話が止まりました。
 全機能を確定せずに、稟議に通る見積と、契約で交わせる約束は、どう作ればいいのでしょうか？

 見積の根拠として全体像を求められたら…出せます。鍵は、どの粒度で出すか、です。粒度を選べば、発注側が慣れた形の一覧と、そこからの規模感が出せます。ただしそれは、開発する中身がすべて最初に固定されることを意味しません。
 第3回の最後に、問いを「確定できるか、できないか」から「どこまでを重い手続きに載せ、どこからを手続きなしで変えられる範囲として残すか」へ置き換えました。提出した機能一覧は、おそらく確定として扱われる——重い手続きの側に置かれます。ならば、その側に置いても守れる粒度を選び、柔軟性はその内側に残せばよい。
 全体像を出すことと、柔軟さを残すことは、粒度を選べば両立します。

 現場の支援でよく感じるのは、発注側と受注側は、同じ「機能」という言葉を使いながら、思い浮かべている粒度が違うのではないか？ ということです。受注側のアジャイルチームが思い浮かべるのは「ストーリー」——研修で、スプリント（1〜2週間）でテストまで終えるんだぞと習ったアレです。一方、発注側の頭にあるのは、予算獲得の根拠になった機能一覧——画面や帳票の単位で書かれた、ストーリーよりかなり大きな粒度です。この粒度の違いが議論の俎上に載ることは、ほとんどありません。だから、予算やスケジュールの都合で「ある機能の開発をやめる」となったとき、失うものの大きさの受け止め方が、発注側と受注側で食い違うことも珍しくありません。

 粒度の認識の違いに加えて、研修で「更改系の文脈」を教わる機会がほとんどないことも、問題を難しくしています。
 アジャイルの教科書や事例の多くは、新規開発系——とくにネットサービスのように、何が受け入れられるかは出してみないと分からない世界——を舞台にしています。「全件を確定しない」は、その文脈では合理的な判断です。
 では、更改系はどうでしょう？ 業務はすでに回っていて、新システムの価値は、まず網羅性——抜けがあれば業務が止まる——にあり、ゴールも最初から決まっています。段階的に組み立てるには、全体を俯瞰して「今回はどこまでやるか」を選ぶ必要がある。発注側が「全体像を見せてほしい」と言うのは、「これで業務が回るのかを確かめたい」からで、当たり前の要求です。そこへネットサービスの文脈の論理——「全件を確定しない」——をそのまま持ち込めば、会話がすれ違うのも当然です。

 「アジャイルといえばストーリー」というイメージが定着していますが、アジャイルの世界にも粒度を整理する仕組みはあります。エピックやフィーチャーといったタイプを加え、大きな括りから小さな単位へと粒度を変え、それぞれの粒度で何を見るか——事業の狙いか、利用者の使い方か——という視点まで整理する仕組みです。ただ、このタイプの扱いは手法によって異なり、粒度の設計をチームが自分で決める部分が多いため、経験の浅いチームには大きな負担になります。
 そこで本稿では、粒度の構造があらかじめ定義されているユースケースを紹介します（あくまで「選択肢を提示する」という本連載の趣旨に沿って、ひとつの選択肢として）。参考にするのは、Ivar Jacobsonらの「Use-Case 3.0」（Jacobson, Spence, de Mendonca, 2024年）——ユースケースを、アジャイル開発を駆動する軽い実践として整理し直したガイドで、ユーザーストーリーとの併用を前提にしています。

 具体的な使い方は、のちほどサンプルでお見せします。その前に、基礎を確認しておきましょう。

 ユースケースとは、「ある特定の利用者の目的を達成するための、システムの使い方のすべて」と定義できます。構成要素は3つです。

• アクター（誰が）
• ユースケース（何のために、何ができればいいか）
• フロー（どうやって）——基本フロー（目的に至る最も単純な道筋）と、そこから枝分かれする代替フロー（別の道筋、例外、失敗時の扱い）の束

          図１：ユースケース図
。

 図1は、アクターとユースケースの関係を表すユースケース図です。誰が何のためにシステムを使うのか、全体を俯瞰できます。
 一つひとつのユースケースの中では、利用者が実際にシステムを操作します。その大まかな手順がフローです。
 基本フローと代替フローの関係は、後述のサンプル（図2）で具体的に見ます。

 このように、ユースケースには、全体を俯瞰する段（アクターとユースケース）と、個々の中身を見る段（フロー）が、道具として組み込まれています。これが「構造があらかじめ定義されている」の意味です。

 ここまでを足がかりに、実際の例をみて理解を深めましょう。

 ここからは、請求業務を例に、ユースケースで更改案件を組む手順を4つに分けてなぞり、各手順で使う概念をその場で定義していきます。例はあくまで一例で、手順と概念は業務を選びません。エピック／フィーチャー／ストーリーで組みたい方は、ユースケースを、お使いの手法でいちばん近い段（エピックかフィーチャー）に、スライスをストーリーの束に読み替えてください。

（1）一覧を作る——画面ではなく、目的で数える
 材料は、既存の仕様書や存在するシステムから得た現行の画面一覧・帳票一覧・インタフェース一覧です。それぞれを「誰の、どの目的のためにあるか」という観点で整理してみましょう。
 請求業務なら、次のような表になります。

 表を見ると、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回で見た、紙だけが全件の代わりに席に置かれる構造に戻ります。紙になるか発見の道具になるかは、書式ではなく、いつ・どこまで書くかの判断の問題です。

 開発標準も、契約テンプレートも、アジャイルの教科書も、「機能」を一語で語ってきました。粒度のズレが言葉に隠れている限り、どちらの側も相手が約束を破ったように感じ、その感覚が世代を超えて引き継がれます。

 本稿の3段の粒度は「解」ではなく、止まっていた対話を再開するためのきっかけとなる道具です。「全件は確定できない」で終わっていた話を、「どの粒度で線を引くか」という具体的な問いに変える。「アジャイルならストーリー」も「うちは機能分解だからアジャイルは無理」も、道具と運び方を混同した思考停止です。標準の言葉ではなく、実プロジェクトの粒度で話す。それだけで、30年止まっていた会話の形は変えられるのではないでしょうか。

 残るのは、スライス粒度の未知をどう発見して検証済みに変えていくか、その発見を受け止める予算をどう組み、どう配分するかです。次回、別の質問として扱います。

 筆者もこれまで各種の媒体で記事を書いてきましたが、この3連作ほど、「自分はいま地雷の上に両足で乗っている」と実感したことはありません。次回は、この地雷の上で「何を仕様にして検証するのか」まで踏み込み、3本を着地させましょう。

次回: 「ドキュメントが信用できない現行システム、何を『仕様』にして検証する？」