Claude Codeで作るシステムが、会社の稟議に乗らなくなってきた話

マーケティングの部署での仕事が終わり、元の部署に戻った。

マーケティングの部署では、現場に座って、その部署でしか使わないシステムをClaude Codeで作ってきた。この進め方は、Blitz Engineeringという名前で前に書いた。

最初は、頼まれた物を速く作って返していた。いまはその先に進んでいる。マーケティングの部署がそもそも考えつかなかった、業務に役立つシステムを、自分のほうから作り始めた。

こういうシステムは、作る前の稟議に乗らない。

■ 効果を聞かれる裏には、会計のルールがある

前の会社では、システムを作る前にこう聞かれた。

「君がそのシステムを1ヶ月かけてつくってくれるのはいいが、それをペイできるのか」

稟議に書くのも同じことだ。このシステムで、売上がいくら増えるのか、費用がいくら減るのか。

会社がシステムを作るのに払ったお金は、帳簿の上で資産か費用のどちらかになる。資産にすると、払ったお金を何年かに分けて、少しずつ費用にできる。費用にすると、払った年に全部が費用になる。

たとえば500万円で作ったシステムを5年に分けるなら、1年あたりの費用は100万円だ。分けられなければ、その年に500万円がまるごと費用になる。

資産にできるのは、そのシステムで売上が増える、または費用が減ることが確実な場合だけだ。確実と言えない場合と、分からない場合は、その年の費用になる。

確実だと示す証拠の例として、会計の実務指針に挙がっているのが、予算が承認された稟議書だ。稟議書は、予算の承認であり、払ったお金を資産にしてよい証拠でもある。

■ 考えつかなかった物は、効果を言い切る人がいない

会社でシステムを作る審議の入口は、業務部門の要望と、情報システム部門の計画だ。業務部門は、「この作業をシステムにしたい」と要望を出し、使う側として効果を言う。情報システム部門が出すのは、セキュリティの強化や、古くなったシステムの入れ替えだ。こちらは、やらないとシステムが止まる、危ない、という必要性を言う。

現場に入り込んで作っていると、使う側が思いつく前に、作り手のほうが「これはシステムにした方がいい」と気づく改善が出てくる。

使う側は、まだ欲しいと思っていない。だから、効果を言い切る人がいない。作って見せるまで、効果を示せない。どちらの入口にも乗らない。

■ これからは、作った後に決める

全社で使うシステムは、今までどおり作る前に審議する。基幹に触る物、他のシステムと繋がる物、社外にデータが出る物だ。

部署の中だけで使う小さなシステムは、Claude Codeで作って、使いながら確かめられる。効果は、使われ方を見れば分かる。作る前に効果が確実とは言えないので、かかったお金は資産にならず、その年の費用で終わる。

作った物には、使い続ける限り、保守と運用のお金が毎年出ていく。日本情報システム・ユーザー協会が2024年度に941社から集めた回答では、IT予算の76.2%が今の事業の維持と運営に使われていた。

だから、残すか捨てるかは、使われているかで決める。使われなくなった物は、やめる。

使われている物も、同じコードをずっと保守し続けなくていい。元のプログラムなどの資材があれば、必要になった時に作り直せば済む。

作り直す時に固定しておくのは、数字の出し方だ。売上に返品を含めるのか。税込みか、税抜きか。月の締めを何日にするのか。そこが決まっていれば、画面や作り方が何度変わっても、同じ数字にそろえやすい。

これからは会社のお金のルールも、作った後に決める形に合わせていくべきだ。

--

会社でのClaude Codeを使った試行錯誤を読みたいかたはこちら。