本記事はシリーズ「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 の実物: