はじめに

現役の高校教員（数学）です。エンジニアではありません。

Claude Codeで成績処理システムをExcelで作りました。3バージョン作って、3つとも捨てました。

最終的に採用したのは、職場の別の部署が前から使っていたExcelファイルです。

この記事は「作らない判断」の話です。AIを使うと作るコストが劇的に下がるので、作れてしまうがゆえに作りすぎるという新しい失敗があると思っています。その記録です。

生徒の個人情報・成績データは一切含みません。設計の話だけです。

作って捨てた3つ

#	作ったもの	捨てた理由
v1	多科目統合システム（15シート）	1ファイルに全科目を詰め込んだ結果、誰も全体を把握できなくなった
v2	単科目テンプレート（汎用）	方針は正しかったが、下記の理想ファイルに機能で負けた
v3	数学専用タイプ（単元テスト・提出物の積み上げ対応）	同上

v1から v2 への作り直しは、自分の設計判断の誤りでした。ここは普通の失敗です。

問題は v2・v3 の方です。**完成して、検算まで通っていました。**動くものができていた。それを捨てました。

1. なぜ「動くもの」を捨てたか

作り終えたあとで、教務が作った既存のExcelファイルの中身をちゃんと見ました。そうしたら、自分の自作より機能が上でした。

比較するとこうです。

	自作 v2/v3	既存ファイル
評点の計算	対応	対応
観点別のA/B/C判定	対応	対応
3学期分の管理	単一学期のみ	3学期＋学年総合まで
全校生徒の名簿マスター	無し	有り（IDで各シートから参照）
校務システムへの提出形式	手作業でコピー	専用の貼り付けブロックが用意されている

決定打は最後の行でした。

成績は最終的に校務システムに取り込まれます。既存ファイルにはそのまま貼れる形に整形された領域が用意されていました。自作の方は、そこを手作業でやる前提だった。

つまり自作は、業務の最後の一手間を解決していませんでした。

2. 何を見落としていたか

振り返ると、私は「自分が面倒なところ」だけを見て設計していました。

点数を入れたら評点が出る ← ここは作った
観点別のABCが自動で出る ← ここも作った
そのデータを最終的にどこへ渡すのか ← 見ていなかった

業務の入口から出口までではなく、真ん中だけを作っていたわけです。

そして既存ファイルは、実際に運用されてきたぶん、出口まで設計されていました。当たり前です。現場で使われた年数の差がそのまま機能の差になっていました。

3. AIがあると「作る」に寄りすぎる

ここが今回いちばん学んだところです。

Claude Codeを使うと、Excelの構造を作るのが本当に速いです。数式もマクロも書いてもらえる。だから調べるより作る方が早く感じます。

実際、私は既存ファイルの中身をちゃんと見る前に作り始めていました。「どうせ古いやつだろう」と思っていたからです。見ていませんでした。

作るコストが下がると、「まず既存のものを調べる」という手順が飛ばされやすくなる。これは道具の副作用だと思います。以前なら、Excelで3つもシステムを作る体力がそもそも無かったので、先に既存ファイルを探したはずです。

教訓としてはこうなります。

作るのが速くなったぶん、「作る前に探す」を意識的にやる必要がある。

4. 捨てるときに何を残したか

とはいえ、3つ作った時間が完全に無駄だったかというと、そうでもありませんでした。既存ファイルを読めるようになっていたからです。

自分で一度作っていたので、既存ファイルを開いたときに

どの列が入力で、どの列が計算結果か
評点をどういう式で出しているか
どこを変えると何が壊れるか

が読めました。自作していなければ、あの巨大なファイルはただの読めない他人のファイルでした。

既存ファイルの評点ロジックは、こういう構造でした。

評点 = 授業評価の合計 / 授業評価の満点 × (観点の配点 − 考査の配点)
     + 考査の得点   / 考査の満点     × 考査の配点

満点で割って配点を掛けるという形にしているので、テストの満点が何点でも、回数が何回でも吸収できます。自作では「満点100点」を前提に書いていた箇所があり、ここは明確に既存ファイルの方が汎用的でした。

自分で作った経験が、他人の設計の良さを評価する目になった、というのが正直な収穫です。

5. 乗り換えでやったこと

やったのは「作る」ではなく「きれいにする」でした。

既存ファイルをコピーする
点数が入っているセルだけを空にする（数式・満点・名簿・判定ロジックは一切触らない）
自分の科目に合わせて、項目名と満点だけを設定する

2番が地味に神経を使う作業でした。数式の入ったセルを消すと壊れるので、入力セルと計算セルを区別して、入力セルだけをクリアする必要があります。ここはClaude Codeにスクリプトを書いてもらって処理しました。目視で消していたら、絶対にどこか壊していたと思います。

結果、中身は既存ファイルのまま、白紙のテンプレートができました。自分が書いたコードはほぼゼロです。

6. 学んだこと

学び	中身
業務システムは入口と出口を見る	真ん中（計算）だけ作っても運用は楽にならない
既存のものを先に読む	AIで作るのが速いほど、この手順が飛ばされやすい
作った経験は捨てても残る	他人の設計を読めるようになる
捨てる判断は早い方がいい	使い始めてからでは移行コストが跳ね上がる
「きれいにする」もAIの仕事	入力セルだけクリアする、みたいな作業は人間がやると壊す

7. 「作る前」に自分へ聞く4つの質問

同じ失敗を繰り返さないために、今は何かをAIと一緒に作り始める前、自分にこの4つを聞くようにしています。成績処理システムに限らず、業務ツール全般に使える形にしてあります。

これと同じようなもの、社内・職場に既にないか？ 探す前に手を動かし始めていないか
自分が面倒な部分だけでなく、業務の入口から出口まで洗い出したか？ 「作ったデータを最終的にどこへ渡すのか」まで見えているか
完成の基準は「動くこと」か、「今の運用にそのまま接続できること」か？ 動くだけでは、業務の最後の一手間が残っていることがある
もし後で捨てるとしたら、いつ判断するか？ 使い始める前に決めておくと、乗り換えのコストが跳ね上がる前に動ける

4つとも、今回失敗してから気づいたことです。逆に言えば、先に自分に問うておけば、3回も作り直さずに済んだはずでした。

おわりに

3つ作って3つ捨てた、と書くと失敗談に見えますが、実感としてはそうでもありません。捨てる判断ができたのは、使い始める前だったからです。1年運用してから気づいていたら、乗り換えられなかったと思います。

AIを使うと手が速くなります。速くなったぶん、試して捨てるのが現実的な選択肢になった、というのが一番大きな変化かもしれません。捨てる前提で作るのは、以前の自分には無かった発想でした。

ただし、それでも一番効率がいいのは「既に良いものがあるなら、それを使う」です。当たり前のことを、3周してから学びました。

次は、Claude Code内でモデルを使い分けている話を書く予定です。