エクセル仕様書との向き合い方

その「設計では苦しい」という違和感は、かなり本質を突いていると思います。整理すると、これは変換の方向性そのものの問題です。

なぜ設計フェーズだけ苦しいのか

コーディング・テストの恩恵は「既に確定した情報を、機械が読みやすい形に変換するだけ」だから成立します。情報の追加や判断は発生しません。

一方、設計フェーズで欲しいのは「これから決めること」を整理・議論する場です。Excelを正としてMDを後追いで作る限り、設計の思考過程はExcel上(セルのコメント、色分け、口頭での補足)に分散したままで、MDには「結果」しか落ちてきません。Excel→MD変換は、本質的に「終わった設計を読み解く」作業であって、「設計を進める」作業ではないんですよね。だから苦しい。

発想を変える:変換方向を逆にする

新規機能・既存機能の変更(continuous developmentの本体)については、こうしてみるのはどうでしょうか。

1. 設計はMDで行う(壁打ち、決定理由、トレードオフも含めて自然言語で書く。ここはClaudeとの対話そのものが設計ログになる)

2. Excelは「設計が確定した後に生成する正式デリバラブル」にする(MD→Excelは、フォーマットを自分で制御できるので、Excel→MDより圧倒的にやりやすい。結合セルの解釈ミスなどの問題がそもそも起きない)

3. 結果として、**新規/変更箇所は「MDが正、Excelは出力物」**という構造になり、コーディング・テストの恩恵を設計フェーズからすでに受けられる

これなら「正式仕様書としてExcelを残す」という制約は守りつつ、設計の苦しさを解消できます。

既存20年分のレガシー仕様書はどうするか

ここは前提が違うので別扱いが必要です。全件を真面目にMD化しようとすると、最初に話した「意図のズレ検証」コストが全部のしかかってきます。これはやらないのが現実的だと思います。

触る部分だけ、触るタイミングでMD化する(JIT変換)。機能改修・バグ修正で該当箇所のExcelを開いたときだけ変換し、検証(前回話した自動検証+リスクベースの人手チェック)をかける

一度変換・検証されたMDはキャッシュして資産化する。何度も触る部分(コア機能)は自然と精度の高いMDが蓄積され、滅多に触らない部分はExcelのまま放置でいい

「全体をMD化するプロジェクト」にしない。プロジェクト化すると終わりが見えない苦行になるが、改修のたびに少しずつ進む副産物にすると負担が分散する

まとめると

table:_

フェーズ 正 副 変換方向

新規/変更設計 MD(設計ログ) Excel(生成) MD→Excel

既存レガシー領域(未改修) Excel なし 変換しない

既存レガシー領域(改修時) Excel(正式) MD(JIT生成・検証付き) Excel→MD(範囲限定)

つまり「Excelを正、MDを副」という単一ルールを全体に適用するのではなく、新規開発とレガシー保守で正のレイヤーを変えるのが、設計の苦しさとレガシー変換の苦しさを両方軽減する落とし所だと思います。

これは技術的には大きな投資が要らないので、まず「次の新規機能1つ」で①の流れを試してみて、Excel生成側のテンプレート(社内SIフォーマットの体裁)が問題なく作れるかを検証するのが、一番リスクの低い始め方かなと思います。