CF精算表リファレンスExcel分析と次期実装計画の策定
リファレンスExcelの全19シートを開いて1セルずつ追いかけていたら、現行スクリプトとの設計差が2箇所浮かび上がった。「ズレてるな」と思ったその瞬間から、次に何を作るべきかが一気に見え始めた。今日はそのリファレンス分析のスキル化と、次期実装計画の策定に丸一日を使った。
リファレンスExcelの全体像を整理する
手元のリファレンスExcelは4段階のCF精算表(CFWS)と24の取引パターンで構成されている。19枚のシートにまたがるこの構造を、頭の中だけで把握するのは無理がある。
そこで cfws-reference-all.md というスキルファイルに全体像をまとめた。シート一覧、各CFWSの段階定義、取引パターンの対応表を1ファイルに集約した。さらに、既存の4つのCF関連スキルと cf-content マークダウンに、このリファレンススキルへの参照リンクを追加した。スキル間をジャンプできるようにしておけば、作業中に「このパターンの正解はどこだっけ」と迷子にならない。
設計差を2つ発見する
リファレンスを1セルずつ照合していく中で、現行スクリプトとの設計差が2箇所見つかった。
1. 固定資産売却損益の列分離
リファレンスでは「固定資産売却益」と「固定資産売却損」を2列に分離している。現行スクリプトは「固定資産売却損益」として1列にまとめていた。
1列の方がシンプルだが、リファレンスが2列にしている理由は明確で、益と損では営業外収益と営業外費用にそれぞれ帰属するからだ。CF精算表の調整額の符号が変わる。ここを1列で済ませると、益と損が相殺されて調整の内訳が見えなくなる。
2. 未払費用の営業経費別細分化
リファレンスでは未払費用を営業経費の種類別に細分化していた。現行スクリプトは未払利息のみを分離済みで、他の営業経費は未対応だった。
SUB_ACCOUNT_CHILDREN による補助科目展開の仕組みは既に動いている。インフラは整っているのに、活用していなかった。
固定資産パソコン追加の計画を立てる
設計差の1点目を解消するために、固定資産に「パソコン(備品)」を追加する計画を立てた。
現行は車両運搬具のみで、売却すると利益が出る構造になっている。パソコンを追加すれば、取得原価40万円に対して減価償却が進んだ後の売却で損が出る。車両は益、パソコンは損。この2つが並ぶことで、売却益/損の2列分離が自然に成立する。
計画の骨子は以下の通りだった。
ASSETS_DBにパソコン(備品、耐用年数4年、定額法)を追加- 取引モジュールで取得・減価償却・売却の仕訳を生成
- 年次推移表に備品行を追加
- CFWSの投資活動CFに備品の取得・売却を反映
- 売却損益列を「益」と「損」の2列に分割
営業経費の借入金追加計画を立てる
設計差の2点目については、専門家への顧問料を未払営業経費として追加する計画を立てた。
SUB_ACCOUNT_CHILDREN に未払営業経費のエントリを足せば、既存の補助科目展開ロジックがそのまま動く。新たなインフラ構築は不要で、データ定義の追加だけで済む。
# 既存のインフラをそのまま活用
SUB_ACCOUNT_CHILDREN["未払費用"] = ["未払利息", "未払営業経費"]
Codexレビューで致命的指摘を4点受ける
2つの計画を最初は1つのファイルにまとめていた。Codexに投げたところ、致命的な指摘が4点返ってきた。
1つ目は、計画の分割を求める指摘だった。固定資産の追加と営業経費の追加は依存関係がない。1ファイルにまとめると、片方が遅延したときにもう片方の着手判断が曖昧になる。
2つ目は、売却損益の2列分離でBS・PL・CFWSの3帳票すべてに影響が波及する点を計画に明記すべきという指摘だった。CFWSだけ直しても、PLの表示と整合しなければ意味がない。
3つ目は、パソコンの減価償却で端数処理の方針が未定義だという指摘。定額法で4年償却すると1円未満の端数が毎月発生する。既存の車両運搬具と同じ丸め方針を明記せよ、と。
4つ目は、テストケースの記述が薄いという指摘だった。「既存テストが通ること」だけでなく、新規追加分の検証シナリオを具体的に列挙すべきだと。
どれも見落としていた点で、指摘を受けて手が止まった。特に2つ目のBS・PL波及は、CFWSにばかり目が向いていて完全に抜けていた。
計画を2つに分割する
Codexの指摘を受けて、計画ファイルを2つに分割した。
plan-303-fixed-asset-pc-addition.md--- 固定資産パソコン追加と売却益/損の2列分離plan-301-borrowing-operating-expenses.md--- 営業経費の未払費用追加
それぞれ独立して着手・完了できる粒度になった。plan-301の方はインフラが既に整っているため、データ定義の追加とテストだけで完了する見込みだ。plan-303の方は帳票3つに波及するため、工数が大きい。
分割後、もう一度Codexに再レビューを投げた。resume --last で前回の文脈を引き継ぎ、更新箇所を重点的に見てもらった。致命的指摘はゼロになり、計画がFIXした。
学びメモ
リファレンスExcelを「1セルずつ追いかける」作業は地味だが、スクリプトのコードレビューでは見つからない設計差が浮かび上がった。コードは「今の実装」を映すが、リファレンスは「あるべき姿」を映す。両方を並べたときに初めて、ズレの輪郭が見えた。
Codexレビューについては、「瑣末な指摘はするな、致命的な点だけ指摘しろ」と明示的に伝えることで、ノイズが減って本当に見落としていた点だけが返ってくる。特にBS・PL波及の指摘は、自分の視野がCFWSに狭まっていたことを突きつけられた。
計画の統合と分割の判断は、依存関係の有無で決める。依存がなければ分割する。片方が止まってももう片方は進められる。単純な原則だが、最初にまとめて書いてしまったのは「1回で済ませたい」という怠惰だった。