要件定義 / Requirements Definition

Today is the Japan localization review. We're three weeks from design freeze, so anything we don't resolve today becomes a change request later — and change requests cost three times as much. Lena, set us up.

今日は日本の現地要件レビューです。設計凍結まで3週間なので、今日解決しない事項は後で仕様変更になります。仕様変更は3倍のコストがかかります。Lena、状況の説明をお願いします。

Thanks. Across all Wave 1 countries we've logged one hundred and twelve requirements. Ninety-four are a fit — standard, out of the box. Eighteen are gaps. Of those eighteen, thirteen come from Japan.

ありがとうございます。Wave 1の全対象国で112件の要件を登録しました。94件はFit、つまり標準機能で対応可能です。18件がGapです。その18件のうち13件が日本からです。

Ken, help me understand. Japan raised forty-seven requirements and thirteen of them can't be met by a system that runs in thirty-eight other countries. What's going on there?

Ken、教えてください。日本から47件の要件が挙がり、そのうち13件が、他の38カ国で動いているシステムで対応できない。何が起きているんですか。

It's a fair question, and I want to answer it properly rather than defensively. Of the forty-seven, thirty-four are already fit — we just documented them in detail because our auditors require traceability. Of the thirteen gaps, I'd argue six are genuinely mandatory and seven are negotiable.

妥当な質問ですし、身構えるのではなくきちんとお答えしたいです。47件のうち34件はすでにFitです。監査法人がトレーサビリティを求めるため詳細に文書化しただけです。13件のGapのうち、6件は本当に必須で、7件は交渉可能だと考えています。

Okay, that's a much more useful framing. Walk me through the six.

なるほど、そのほうがずっと分かりやすい枠組みです。その6件を説明してください。

Number one, the qualified invoice system. Since twenty twenty-three, a Japanese invoice must carry the seller's registration number and a tax breakdown by rate. If our invoice doesn't have it, our customer cannot claim the tax deduction. They will simply refuse the invoice.

1つ目、適格請求書（インボイス）制度です。2023年以降、日本の請求書には売主の登録番号と税率別の税額内訳が必須です。それがなければ、顧客は仕入税額控除を受けられません。顧客は単純に請求書を受け取り拒否します。

That one I accept. The tax registration field exists in standard; the rate breakdown on the invoice layout is a form change, not a code change. That's two days of effort, not two weeks.

それは受け入れます。税登録番号の項目は標準に存在します。請求書レイアウト上の税率別内訳は帳票変更で、プログラム変更ではありません。2週間ではなく2人日の作業です。

That's good news. Number two is the acceptance certificate. In Japan, for project-based sales, the customer signs an acceptance certificate confirming delivery, and we cannot legally recognise revenue or issue an invoice until we have it.

それは良い知らせです。2つ目は検収書です。日本ではプロジェクト型の取引の場合、顧客が納品を確認する検収書に署名し、それを受領するまで売上計上も請求書発行も法的にできません。

Hold on — that's not just a Japan thing. Singapore has something similar for government contracts. If we're building it, build it as a global capability, not a Japan add-on.

待ってください。それは日本だけの話ではありません。シンガポールも政府案件で似た仕組みがあります。作るなら日本向けアドオンではなく、グローバル機能として作るべきです。

That changes my assessment. If two countries need it, it belongs in the template. Grace, can you send me your requirement in writing by Wednesday so I can merge them?

それは評価が変わります。2カ国が必要とするなら、テンプレートに入るべきです。Grace、水曜までに要件を文書で送ってもらえますか。統合したいので。

Will do.

了解です。

Number three, month-end closing by customer. Our distributors have different closing dates — the tenth, the fifteenth, end of month — and the invoice has to be cut on their cycle, not ours.

3つ目、顧客ごとの締め日です。当社の卸売業者は締め日がそれぞれ異なります。10日、15日、月末など。請求書は当社の周期ではなく相手の周期で発行しなければなりません。

Standard supports customer-specific billing cycles. That's a configuration, not a gap. Whoever logged it as a gap was being cautious.

標準は顧客別の請求サイクルに対応しています。それはGapではなく設定です。Gapとして登録した人は慎重に振っただけでしょう。

Good — then we're down to five. Number four is the one I expect to be difficult. Fax and paper orders. Two of our largest distributors send orders by fax. Together they're eighteen percent of Japan revenue.

よかった、では5件になります。4つ目が難航すると予想している項目です。FAXと紙の注文です。当社最大の卸2社がFAXで注文を送ってきます。合わせて日本売上の18%です。

And we can't ask them to change. I remember. What are the options?

そして相手に変えてもらうことはできない、と。覚えています。選択肢は何ですか。

Three, as promised. One: manual entry by a service team — no build cost, but ongoing headcount and error risk. Two: an OCR service with human verification — moderate cost, and it scales. Three: fund the distributors to move to EDI — highest cost, best long-term outcome, and completely outside our control.

約束通り3案です。1つ目、サービスチームによる手入力。開発費ゼロですが、継続的な人員コストと入力誤りのリスクがあります。2つ目、人による確認付きのOCRサービス。中程度のコストで、拡張性があります。3つ目、卸のEDI移行費用を当社が負担する。最もコストが高く、長期的には最善で、そして完全に当社のコントロール外です。

I don't want option three on the critical path of this programme. Let's take option two for go-live and treat option three as a separate commercial conversation with those accounts. Ken, does that work for you?

選択肢3をこのプログラムのクリティカルパスに乗せたくありません。稼働時点では選択肢2を採用し、選択肢3はその取引先との別の商談として扱いましょう。Ken、それで問題ありませんか。

It does, with one condition. If the OCR accuracy is below ninety-five percent in testing, I need a fallback of manual entry during hypercare. I don't want to discover the problem on day one of go-live.

問題ありません、一つ条件付きで。テストでOCRの精度が95%を下回る場合、ハイパーケア期間中の手入力によるバックアップ手段が必要です。稼働初日に問題を発見するのは避けたいです。

That's a sensible guard rail. I'm capturing it as an assumption with an owner. Lena owns the accuracy test, Ken owns the fallback plan.

それは妥当な安全策です。責任者付きの前提条件として記録します。精度テストの責任者はLena、代替手段の計画はKenが担当。

Numbers five and six are the two I will not compromise on. Consumption tax rounding — Japan requires rounding at the invoice line level, not the invoice total. And withholding tax on certain service revenue, which has to be calculated at the point of billing.

5つ目と6つ目は、私が譲らない2件です。消費税の端数処理。日本では請求書合計ではなく明細行単位での端数処理が求められます。そして特定のサービス売上に対する源泉徴収で、請求時点で計算する必要があります。

The rounding one is genuinely hard. Our tax engine calculates at header level by design. Changing it means touching core logic, and core changes are what break us at upgrade time.

端数処理は本当に難しいです。当社の税計算エンジンは設計上ヘッダ単位で計算します。それを変えるのはコアロジックに手を入れることで、コア変更はバージョンアップ時に問題を起こします。

I understand the concern about upgradeability. But this is not a preference — it's how the tax authority requires it to be calculated. If we get it wrong, we're not talking about user complaints. We're talking about a tax filing that's incorrect.

バージョンアップの懸念は理解します。ですがこれは好みの問題ではなく、税務当局が求める計算方法です。間違えれば、ユーザーからの苦情という話ではありません。誤った税務申告になるという話です。

That settles it for me. Grace, back me up here — is that your reading too?

私にはそれで決着です。Grace、確認したい。あなたの見解も同じですか。

It is. Incorrect tax calculation is a compliance exposure. We don't trade that against upgrade convenience.

同じです。誤った税額計算はコンプライアンスリスクです。バージョンアップの利便性とは天秤にかけません。

Then I'll design it properly rather than argue it. I'd propose an enhancement in a defined extension point, not a modification to core, so it survives upgrades. It's more effort up front — around fifteen days — but it doesn't create technical debt.

ではこれ以上議論せず、きちんと設計します。コアの改変ではなく、定義された拡張ポイントでのアドオンとして提案します。そうすればバージョンアップに耐えます。初期工数は増えますが、約15人日程度で、技術的負債を作りません。

That's exactly the trade-off I want people making. Approved.

それがまさに、皆にしてほしい判断です。承認します。

So where are we? Of thirteen gaps: two are actually configuration, one becomes a global capability shared with Singapore, one is solved by a service rather than a build, and two are approved enhancements. What about the remaining seven — the negotiable ones?

現在地はどこでしょうか。13件のGapのうち、2件は実は設定、1件はシンガポールと共通のグローバル機能に昇格、1件は開発ではなくサービスで解決、2件はアドオンとして承認。残る7件、交渉可能な分はどうしますか。

I'd de-scope all seven to Wave 2. They're process improvements, not blockers. My team can live with the standard process for a year — but I want them formally logged, not quietly dropped.

7件すべてWave 2に落としたいです。業務改善であって障害要因ではありません。私のチームは1年間、標準プロセスで対応できます。ただし正式に記録してほしい。黙って無かったことにされるのは避けたいです。

Logged in the Wave 2 backlog with your name against them. Nothing gets quietly dropped on my programme.

あなたの名前付きでWave 2のバックログに登録します。私のプログラムで黙って落とされるものはありません。

Ken, one more thing. You came in with forty-seven items and walked out with two enhancements. That's the best-prepared localization review I've sat in. Whatever your team did to get here, tell the other countries how you did it.

Ken、もう一点。47件を持ってきて、アドオン2件で出ていく。私が同席した中で最も準備の良い現地要件レビューでした。ここまで来るのにチームがやったことを、他の国にも共有してください。

Actions. Grace sends her acceptance-certificate requirement to Lena by Wednesday. Lena reissues the gap list with the revised classifications and confirms the OCR accuracy test plan. Ken drafts the manual fallback procedure. Design freeze stays on the twelfth — nothing new enters after that without a CR. Thank you, everyone.

アクションです。Graceは水曜までに検収書の要件をLenaへ送付。LenaはGap一覧を分類変更して再発行し、OCR精度テスト計画を確定。Kenは手入力の代替手順を作成。設計凍結は12日のまま。それ以降は仕様変更申請なしに新規要件は入りません。皆さん、ありがとうございました。