【アジャイルFAQ 第3回】アップグレード案件の「現行機能保証」にどう向き合う？

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

 判断の積み重ねは、いつしか慣習になります。そして一度慣習になると、誰も疑問を持たなくなります。前例踏襲という「思考停止」の完成です。今回からの3回は、そのひとつ、更改案件の「現行機能保証」を扱います。対処するには3つの視点が必要で、それぞれをサブテーマとして、3回に分けて扱います。

• 第3回（本稿）: 「現行」の実体を見る
• 第4回: 合意できる「全体像」を作る
• 第5回: 検証し、予算を組み、配分する

 この3本のねらいは、「読者の職場に波風を立てる」ことです。「更改案件は〇〇するものだ」「アジャイルは〇〇だ」——さまざまな決まり文句が、私たちの思考を止めています。そろそろそれらに疑問の目を向けて、「ほんとにムリなのか、1回考えてみようよ」というお誘いです。
 また、現実に目を向けると、稟議や契約の席にいる人たちにまでアジャイルの進め方が浸透している、あるいは会社のプロセスがアジャイルを許容している——そんな現場のほうがめずらしいでしょう。この3本は、そうした文脈に合わせてプロセスを仕立て直す一例として読んでいただければと思います。

 うちの部署の仕事は、既存システムの更改・アップグレード案件が中心です。今度の案件を「アジャイルで進める」という方針が出たのですが、正直なところ、メリットがわかりません。
 発注側は「現行機能保証」を当然の前提として話を進めます。でも、現行システムの全機能を把握する手段はありません。頼みのドキュメントも、揃っている保証はなく、揃っていたとしても現物と一致している保証がない。ウォーターフォールでも苦しいのに、アジャイルは「最初に全件を確定しない」進め方のはずです。全件を求める発注側と、全件を確定しないアジャイル——噛み合う気がしなくて、違和感が拭えません。
 「保証しろ、ただし、対象の全貌は不明」という状況に、アジャイルでどう向き合えばいいのでしょうか?

 いいですね、その“違和感”。その違和感や疑問を、まず大事にしてください。

 JUASの「企業IT動向調査2026」でも、IT予算の増加理由に「既存システム・基盤の刷新・更新・増強」が挙げられています——この質問の背景は、業界の実態そのものでもあります。
 そうした案件で「現行機能保証」は、対象の全貌が不明なまま全件の保証だけが約束される“魔法の言葉”ですそ。しかし、その中身は「要件は不明」の言い換えに過ぎません。そして、契約不適合責任（以前の「瑕疵担保」）との合わせ技で、発注側は受注側にリスクを転嫁できるのです。

…ちょっと刺激的すぎますか?

 厄介なのは、この曖昧な文言が判定基準として使われることです。何が「現行通り」かが不明なまま全件を保証する約束は、約束の中身を変えないかぎり、契約の形をどんなに工夫しても、実務上、履行のしようがありません。できないと分かっていることを、片や「できないと困るんです」と押し通し、片や契約欲しさに「できます」と装っているうちは、泥沼が約束されます。

 「できないことはできない」と素直に認めることが、解決のスタートラインです。

 さてそこで、「メリットがわからない」に立ち戻ると…メリットどころか、アップグレード案件は、アジャイルの適地だと、私は考えています。ポイントは、曖昧なものを、管理可能な形に置き換えることです。

 では、「現行」ってなんだろう？ というところから始めていきましょう。

 そもそも「現行通り」とは、何を指すのでしょうか?
 根本の問題は、「現行の仕様」と呼ばれるものが、実際には3つの別物の混合体であることです。

1. 紙に書いてあること（明文化された仕様）
    設計書・仕様書に“ある時点で”記録された内容です。ある時点では現物を反映していたかもしれませんが、最新と一致している保証はありません。この紙を持っているのは、発注側と、受注側の見積担当です。
2. コードがやっていること（実装された挙動）
    実際にコードとして動いている挙動です。仕様書との差分——バグ修正、現場対応の改修、そもそも文書化されなかった機能——も、ここに含まれます。この情報を持っている（あるいはコードを読める）のは、保守を担当してきた開発者です。
3. 人がやっていること（現場の使い方）
    ユーザーがそのシステムをどう使って業務を回しているか、です。マニュアル外の操作手順や、既知のバグを避けるための現場の運用上の工夫を含みます。前回の更改でシステムに取り込まれず、手作業でカバーすることにした業務手順もここに入りますが、コードにも仕様書にも、まず残りません。知っているのは現場の利用者ですが、本人にとっては「仕様」ではなく、ただの日常です。だから、聞かれなければ出てきません。

 「現行機能保証」と言うとき、発注側が本当に守りたいのは**3「人がやっていること」です。しかし、契約や検収の根拠にされるのは1「紙」で、移行の実作業が向き合うのは2「コード」**です。この3つは、リリースした日にはだいたい一致していたはずです。ズレを作るのは、その後の時間です。

• 障害対応の緊急改修で、コードだけが変わる
• 法改正や組織変更には、システム改修の予算が付くまで、現場の運用が先に対応する
• 紙は「次の大きな改修のときにまとめて直す」と後回しになる

 どれも、その場では合理的な判断です。その積み重ねで、年を経るにつれ三者は別物になります。担当者の怠慢や努力不足ではなく、当然の帰結です。そしてこのズレが、更改案件で「テストは全部通ったはずなのに、リリース後に業務が止まった」事故が繰り返される、構造面での理由です。

 三者は一致しない。それなのに、見積と契約の席に置かれるのは紙だけです。発注側には全件を把握する手立てが残っておらず、受注側の上層には材料がなく、材料を持つ末端には声を上げる機会がない。
誰も全件を持っていないのに、全員が全件を約束している
——これが、冒頭で「履行のしようがない」と言った約束の正体です（なぜそうなり続けるのかは、最後に触れます）。

 個々の挙動の粒度で全件を把握できないなら、その粒度では「発見しながら進む」しかありません。これは、アジャイルの中核である経験主義——やってみて、観察して、次を調整する——そのものです。
 この連載の第2回で、「新規開発系」「保守系」と分類しましたが、第3の分類が「更改系」です。更改系には、次の特性があります。

• ドキュメントの完全性に期待できず、未知が多い
• 検証相手として現物があり、答え合わせができる
• いちどきに切り替えて失敗すると、業務が止まる

 どれも「小さく検証を積み重ねる」進め方に向いた特性です。「既存システムがあるのだから機能は全件洗い出せる、だからウォーターフォールのほうが安全だ」と思われがちですが、実際には「洗い出せる気がしている」だけです。その前提自体が、更改系の特性と相容れません。

 「全件が必要」と「全件を確定しないハズ」の対立をどうするか? 曖昧な“全件”を、管理可能な形に置き換えます。

「全件の暗黙保証」を「検証済みリスト＋残リスク」に組み替える
 「全件」を、「最初に把握されているべき、最終的な全体」ではなく、検証によって伸びていくリストとして捉え直しましょう。最初にやるべきは技術的な作業ではなく、何を保証するかの再定義の交渉です。「現行機能保証」を、検証済み機能のリスト（これは保証する）と、未検証・未発見の領域に分けて管理する形に変えてみてはどうでしょう? この際、未検証・未発見の領域はリスクとして共有し、発見し次第対応します。

 ポイントは、後から仕様が発見されることを、「当然起こりうること」とみなし、「洗い出し漏れの責任問題」にしないことです。残ったリスクを最後に誰が引き受けるかは、この組み替えの中で最初に話しておくべき問いです（答えは組織によって違います）。スプリントごとに検証済みリストが伸び、残リスクが減る——進捗がそのまま保証範囲の拡大として見える構図です。
 ただし、この組み替えだけでは、発注側が求めている「全件」には応えられません。検証済みリストは伸びていきますが、どこまで伸びれば終わりなのか——分母がないからです。前述の組み替えが応えているのは、「全件」の裏にある本来の願い、「業務を止めない」のほうです。業務影響の大きいものから検証していけば、止まると困る業務から順に、保証の内側に入っていきます。それでも発注側には、「全体のうち、どこまで済んだのか」を見たいという、もっともな要求が残ります。その分母——全体像をどの粒度で作るか——が、次回の主題です。

見積の内訳を、保証の文言に流し込まない
 「予算の器」（稟議で確保する総額と期限の枠）と「保証の範囲」（契約で「現行通り」と約束する対象）は、別物です。予算が固定であること自体は問題ではなく、問題は、稟議書の「現行機能保証」という文言が、そのまま契約の保証としてスライドすることです。器を作るのに、個々の挙動の粒度での全件洗い出しは要りません（どの粒度なら数えられるのかは第4回で、器の組み方と配分は第5回で扱います）。見積の内訳は「参考」にとどめ、契約の保証文言には流し込まない。この一線を引けるかどうかで、案件の後半の空気が決まります。

発注側の担当者と、社内説明の語彙を共有する
 アジャイルっぽい用語を避け、「検証済みリスト」「残リスク」「業務影響順」という、担当者が上司やステークホルダーに進捗を説明するために使える言葉で会話しましょう。提案書や定例報告をこの語彙で組んでおけば、担当者はそのまま社内に持ち帰れます。元請と下請の間でも同じで、転記されるのが「現行機能保証」の五文字ではなく、検証済みリストと残リスクになります。本稿で挙げた調査も、説得の道具ではなく、同じ机で一緒に読む資料として持ち込むのがお勧めです。

開発者が今日できること——事故を3つに分類してみる
 契約や交渉の席にいない開発者——多重下請けの最下層で、いちばん重い荷を持たされている人ほど——にも、今日できることがあります。直近の「現行通りのはずだったのに違った」を、紙・コード・人のどこの不一致だったか分類してみてください。この分類の言葉を持つだけで、障害報告が「テスト漏れでした」で終わらず「紙・コード・人のズレでした」に変わり、本稿の議論をチームで始める入口になります。

 三者が一致していないことは、現場の人ならうすうす知っています。それでも紙だけが置かれ続けるのは、もっともな事情があるからです（図3）。

 最初に「現行機能保証」という書式や文言を選んだ判断は、合理的で保守的だったはずです——オープン化・ダウンサイジングの波から数えて、およそ30年前のことです。問題は、その時々の臨機応変な判断が、ノウハウとして引き継がれるとは限らないことです。全件保証で乗り切れた案件は「この書式で守れた」という成功体験として稟議の前例に残ります。一方、保証を緩めてうまくいった案件の判断は、書式には残りません。だから選択は毎回少しずつ保守的な側に倒れ、それを見直す機会がないまま、担当者が入れ替わっても書式だけが引き継がれていく。「対象不明の全件保証」を抱えた案件が世代を超えて再生産されるのは、こういう仕組みです。

 思考を止める言葉は、受注側にもあります。質問者も口にしていた「アジャイルは全件を確定しない」です。そして、両側に共通する「確定」という言葉そのものも、疑ってみる価値があります。

 ウォーターフォールも、要件を本当に確定しているわけではありません。要件は変わりえます。ただ、変えれば見積額に響くので、変更管理委員会のような重い意思決定プロセスを通すことになります（少なくともPMBOKの考え方では）。その重さが「変えずに済ませよう」という動機につながり、結果として確定しているように見えるのです。
 だとすれば、本当の問いは「全件を確定できるか、できないか」ではなく、「どこまでを重い手続きに載せ、どこからを手続きなしで変えられる範囲として残すか」です。では、その線をどの粒度で引けば、発注側と「全体像」を合意できるのか。次回、「機能」という言葉の粒度に踏み込みます。

次回: 「更改案件の見積を、全機能を確定せずにどう出す？」