本記事はシリーズ「J-SIX：Japanese SI Transformation」の実践編（全6回）の第2回です。第1回：Plugin を入れて、最初のプロジェクトを立ち上げるの続きです。

今回やること

前回、Plugin を入れて品質ゲートの設定を置きました。今回から実際の開発に入ります。

要件はこの一言です。

請求書に振込先口座を印字したい。

これだけです。実務でも、要望はこのくらいの粒度で降ってきます。この一言を、AI が実装できて、後から検証できる Spec にするまでが今回の範囲です。

結論を先に書きます。この工程で人間がやるべき仕事は、文章を書くことではありません。決めるべきことを決めることです。 AI に丸投げすると、業務上の判断が勝手に確定します。しかも、それらしく実装されるので気づきにくい。

1. AI は「それらしく」実装できてしまう

「請求書に振込先口座を印字したい」と CC に伝えれば、おそらく動くものは出てきます。しかしその過程で、少なくとも次の5つが暗黙に決まります。

口座は自社に1つなのか、取引先ごとに違うのか
口座が登録されていない取引先があったら、締め処理はどうなるのか
締めた後に口座情報を変更したら、発行済みの請求書の記載は変わるのか
確定した請求の口座は変更できるのか
会計連携ファイルにも口座を出すのか

どれも業務の判断です。技術的にはどちらでも実装できます。だからこそ AI は迷わず、訓練データで最も一般的なパターンを選びます。それがこの案件で正しいとは限りません。

2. Skill を起動する

J-SIX では、Spec の作成に spec-create Skill を使います。

この Skill は、テンプレート（要求 Spec の雛形）と既存の Spec を読んでから、決まっていないことを質問します。いきなり書き始めません。

注目してほしいのは最後の一文です。

3 については、既存の設計で交付先名称を「締め時点のスナップショット」として保存しています（帳票編集定義）。同じ扱いに揃えるのが自然に見えます。

既存の設計書（帳票編集定義）を読んだうえで、既存の方針との整合を提案しています。これは、設計書が実装から逆生成されていて、かつ最新であることの効用です。設計書が古いと、この提案は成立しません。

3. 人間が決める

5つの論点に答えます。今回の判断は次の通りです。

#	論点	決定	理由
1	誰の口座か	取引先ごとに指定	入金元を取引先ごとに分けている運用があるため
2	未登録のとき	印字を省いて警告	既存の売上取込が「1行の不備で全体を止めない」方針。締めも揃える
3	締め時点で固定するか	スナップショット	交付先名称と同じ扱い。発行済み請求書の記載が後から変わらないように
4	確定後の変更	不可	既存の REQ-007（確定済みの請求は変更不可）と整合
5	会計連携	含めない	現行の列構成を維持する。仕訳に口座は不要

5つのうち4つは「既存の方針に揃える」という判断です。 新しいことを決めたのは1番だけでした。

これは偶然ではありません。既存の Spec・ADR・設計書が揃っていれば、新しい要件の判断の多くは「既存とどう揃えるか」に還元されます。逆に、既存の方針が文書化されていないプロジェクトでは、毎回ゼロから考えることになり、しかも人によって答えが変わります。

2番は特に議論が必要な論点でした。 「口座が未登録なら締めを止める」ほうが安全に見えます。しかし、月末の締め処理が1社の設定漏れで止まると、経理の業務全体が止まります。今回は「止めない。ただし気づけるようにする」を選びました。この判断が後で監査記録の設計に効いてきます。

4. 決めたことを REQ として書く

判断が決まったら、業務ルール（REQ）として Spec に書きます。

実際に追記された3行がこれです。

| REQ-011 | 振込先口座は取引先ごとに登録する | 金融機関名・支店名・預金種別・口座番号・口座名義を持つ。請求書に印字する |
| REQ-012 | 振込先は締め時点の内容を請求に保存する | 交付先名称と同じ扱い。締め後にマスタを変更しても、作成済みの請求の記載は変わらない |
| REQ-013 | 振込先が未登録でも締めは止めない | 請求は作成し、請求書には「振込先未登録」と表示する。その締めは監査記録に警告として残す |

1つの要望が3つの REQ になりました。 「印字する」という機能の話は REQ-011 だけで、残りの2つは「いつの情報を使うか」「異常時にどうするか」です。実務でバグや仕様のもめごとになるのは、たいてい後者のほうです。

要件に ID を振るのは、単なる整理のためではありません。この ID が、後の工程で機械的な検証の鍵になります。 品質ゲートは「REQ-011 に対応するテストが存在するか」を正規表現で走査して判定します。ID が無ければ、この検証は成立しません。

5. 受入条件から「性質」を導く

J-SIX には、REQ とは別に PROP（Property） という概念があります。

REQ は個別の例で書かれます。「10万円の申請は2段承認になる」のような書き方です。例だけを検証面にすると、その例だけを通す実装が成立してしまいます。そこで、入力空間全体で成り立つべき性質を取り出します。

今回追加した性質は2つです。

| PROP-007 | REQ-012 | 任意の請求について、保存された振込先は締め時点の取引先の振込先と
|          |         | 一致し、その後のマスタ変更では変化しない |
| PROP-008 | REQ-013 | 任意の取引先集合について、振込先の登録有無は作成される請求の件数と
|          |         | 金額に影響しない |

書式は「任意の〈前提〉について〈性質〉が成り立つ」で統一します。

この2つは、第4回で性質テスト（Property-Based Testing）に変換されます。「A 社の口座を変えたら B 社の請求書が変わってしまった」のような事故は、例ベースのテストでは見落とされがちですが、性質として書けば入力空間を自動で探索してくれます。

PROP-008 の「件数と金額に影響しない」は、一見すると当たり前に思えます。しかし「未登録のときに締めを止める」実装をしてしまうと、この性質は破れます。性質は、間違った実装を排除する形で書くのがコツです。

6. hold-out 受入テストの対象を決める

要求 Spec には、もう1つ書く欄があります。hold-out 受入テストの対象です。

| 5 | UC-002, UC-004 | 振込先が請求書に印字され、締め後のマスタ変更で記載が変わらないこと。
|   |                | 未登録の取引先があっても締めが成功すること |

hold-out 受入テストは、実装担当と分けて作り、その担当へ共有しないテストです。別の担当（J-SIX では別のサブエージェント）が、Spec の受入条件だけを見て書きます。現行の Plugin Hook は対象ツールの直接操作を拒否しますが、全経路からの不可視性は保証しません。

なぜそんな面倒なことをするのか。実装する側がテストを見られると、「そのテストを通すための実装」に寄ってしまうからです。人間でも起きますが、AI ではもっと顕著に起きます。詳しくは4層品質ゲートの記事に書きました。

ここでは「何を検証してほしいか」を Spec の側に書いておくだけです。テストそのものは第4回で作ります。

7. 非機能要件は6大項目で書く

機能の話に集中していると抜けるのが非機能要件です。J-SIX では、IPA の非機能要求グレードの6大項目で分類します。今回のサンプルでは、こう書いています（抜粋）。

大項目	要件	レベル／目標値	根拠
可用性	運用スケジュール	平日業務時間帯。締め処理は月1回	経理の月次業務
運用・保守性	処理の追跡	全締め処理・確定操作を監査ログに記録	内部統制
移行性	過去の請求データ	移行しない。現行は Excel の手作業で移行元システムが無いため	現行業務
システム環境・エコロジー	—	対象外（本番化の際に設置環境と合わせて合意する）	—

ポイントは3つです。

合意した重要項目だけを書く。 グレードには238のメトリクスがありますが、全部を埋める必要はありません
対象外の大項目も、行を消さずに「対象外（理由）」と書く。 消すと、検討したのか忘れたのかが分からなくなります
テストのカバレッジや mutation score は、ここには書きません。 非機能要求グレードはシステム基盤の要求を扱うもので、テストの品質は対象外です。品質ゲートの閾値は別表に書きます

今回の要件は、この表を変えませんでした。しかし確認はしました。「振込先を印字する」機能は、可用性にも性能にも影響しないと判断できたからです。

8. どこまで合意できたかを測る

最後に、Spec の承認欄を見ます。J-SIX では、IPA の合意成熟度の3段階をゲートの到達基準にしています。

レベル	定義
仕掛レベル	発注者が「言い切った」、開発者が「聞き切った」
充実レベル	図表に書いてレビューを繰り返し、合意内容が充実した
完成レベル	合意内容が管理され、発注者・開発者の双方が確認できた

Phase 1 のゲートを通すには、要求 Spec（ユースケース・業務ルール・受入条件・非機能要件）が完成レベルに達している必要があります。

重要なのは、仕掛レベルのまま残っている項目があってもよいことです。ただし条件があります。「未確定」と明記し、いつ・誰が確定させるかを決めることです。これを決めずに先へ進むと、実装の途中で判断を求められ、そこで誰かが勝手に決めることになります。

ここまでのまとめ

「請求書に振込先口座を印字したい」という一言は、最終的にこうなりました。

成果物	追加したもの
業務ルール	REQ-011・REQ-012・REQ-013
性質	PROP-007・PROP-008
hold-out 受入テストの対象	1行（UC-002 / UC-004）
非機能要件	変更なし（影響しないことを確認）

この工程で人間がやったことは、5つの質問に答えることだけです。文章は AI が書きました。しかし、その5つの答えがこの案件の仕様そのものです。

そして、5つのうち4つは「既存の方針に揃える」で決まりました。設計書が最新であることは、新しい要件を決めるコストを下げます。 これは、設計書を実装から逆生成する仕組みの、あまり語られない効用だと思います。

次回は、決めた判断を ADR（設計判断の記録） に残し、実装可能なタスクに分解します。J-SIX では、タスクに「変更してよいファイルの範囲」を書いて、人間が先に承認します。なぜそんなことをするのかも含めて説明します。

本連載で使っているサンプル・テンプレート・Plugin は GitHub で公開しています。

今回の要求 Spec の実物: