J-SOXでの彼の本領
前編では、彼との出会いと、彼が経理課で作り上げたシステムの話。そして彼が内部監査室にやってきた経緯を書いた。
内部監査室での仕事は、通常の内部監査に加えて。J-SOX対応という重い柱があった。財務報告に係る内部統制の評価と監査——上場企業として法律で義務付けられたこの業務は。本社だけでなくグループ全社を巻き込む規模で動く。各社・各部門にヒアリングして、業務フローを紐解いて。文書化3点セット(業務フロー図・業務記述書・リスクコントロールマトリクス)を整備して。評価して、監査法人のチェックを受ける。それを期末に向けて回し続ける。めちゃくちゃ忙しかった。
まず、その激務の中で、彼の本領が最もはっきり見えた。

J-SOXの文書化で最も難しいのは、業務プロセスの「本質」を掴むことだ。現場の担当者に話を聞いても、日々の作業を説明してもらえるだけで。「その業務にどんなリスクがあって。それをどんな方法でコントロールしているか」という視点の整理は。こちらがやらなければならありません。
彼はそれが異様に速かった。
システム業務連携のリスク嗅覚
次に、現場担当者の説明を聞きながら、彼はほとんど口を挟まない。しかし、ヒアリングが終わった後でまとめを書かせると、核心だけが残っていた。「このフローのここに承認の抜け穴があります」「この業務はシステムが自動処理しているため実質的にコントロールが効いていません」——そういう指摘が。淀みなく出てきた。
経理業務のシステムを自分で作り上げた経験が、ここで生きていた。
業務とシステムの接点に潜むリスクを嗅ぎ取る能力は。実際に業務を担いながらシステムを設計した人間にしか持てない感覚だと思う。彼はその感覚を、J-SOXという全く異なるフィールドで使いこなしていた。
一方で、一緒に仕事をする中で、私は何度かこう思った。この人がいる部署は、本当に強い。そして同時に、こうも思っていた。この人が去ったら、どうなるのだろう、と。
内部監査室での彼の仕事ぶりと揺るがぬ軸
内部監査室での1年間を振り返ると。彼との仕事は私にとってかなり刺激的な経験だった。
与えられたタスクに対して、まず全体像を静かに把握する。解くべき問いを自分の中で整理する。必要なものだけを使って、過不足なくアウトプットを出す。無駄がない。説明するときも、聞き手が理解しやすい順序で情報を並べる。
そのため、経理での「出来すぎゆえの孤立」を見てきた私には。内部監査室という環境が彼に合っていると感じた。ここでは、精緻に分析して正確に指摘することが求められる。感情的な配慮より論理の正確さが優先される場面も多い。彼のスタンスが、仕事の性質と噛み合っていた。
ただ、それでも彼が組織に完全になじんでいたかというと、そうでもなかった。
どんな場所に行っても、彼は彼だった。自分のスタンダードを下げることなく、求められた以上のものを静かに出し続けていた。それは能力の問題ではなく、性質の問題だったと思う。どんな環境に置かれても、自分の軸から外れない人間がいる。彼はそういう人だった。

優秀な人材の離職とAccessの呪縛
しかし、異動から1年が過ぎたころ、彼は転職することになった。
報告を受けたとき、驚きはあったが、「あぁ、やはりか」という感覚もあった。
これほどの実力がある人間が、一つの会社。一つのグループに留まり続けるとは限らない。むしろ外の世界で力を試したいと思うのが自然だ。優秀な人ほど早く外に出ていくというのは、どこの会社でも繰り返されていることです。
さらに、私は彼の決断を、心から応援したと思う。
ただ、彼が去った後に残されるものが何であるかを、私は知っていた。
あの、誰も触れられないAccessのシステムが、そのまま残る。
Accessシステム、保守不能の末路
まず、彼が転職した後、事業子会社の入金消込システムはどうなったか。
まず、動き続けた。しばらくは誰も触らなければ動き続けるのが、出来上がったシステムというものだ。BtoBとBtoCが混在する大量の入金データを取り込んで、消込処理を回して。レポートを出す。その動作自体は、彼がいなくても続けられた。
問題が起きたのは、何かを変えなければならなくなったときです。
次に、経理の業務は止まらない。税制の変更、社内ルールの変更。銀行のデータフォーマット変更——何らかの理由でシステムを修正しなければならない場面は。必ずやってくる。
そういうとき、システムの中身を理解してコードを直せる人間が。社内に一人もいなかった。
Accessファイルを開いてVBAのエディタを立ち上げることはできる。しかし、BtoBとBtoCが混在する複雑な消込ロジックを。端数処理や分割入金の突き合わせまで含めて読み解き。適切な箇所を適切に修正するとなると、誰もできなかった。
ここで一度立ち止まって考えてみてください
Pythonや自動化スキルを体系的に習得して、ITエンジニアとしてのキャリアを切り開きたい方には「Enjoy Tech!(エンジョイテック)」が選択肢のひとつです。
莫大な解析費、Accessシステム廃棄の決断
一方で、「なんとかそのまま使い続けよう」という時期がしばらく続いたらしい。しかし限界が来た。
最終的に、会社はシステム会社に解析を依頼した。「このAccessシステムが何をしているのかを調べて。ドキュメントにまとめてくれ」という依頼です。
その費用は、後から耳にした限りでは「莫大」という表現が使われていた。具体的な金額は知らない。ただ、その一言に込められた重さは十分に伝わってきた。
そのため、そして、解析が完了した後、会社が下した決断は想像と違うものだった。
解析したシステムを使い続けるのではなく、市販の入金消込パッケージソフトを購入して。Accessシステムは廃棄する——。
莫大な費用をかけて解析した結果として出た答えが、そのシステムをやめることだった。
しかし、誰も保守できないシステムを抱え続けることへの恐怖と。解析費用を払ってでも出口を探したいという気持ち。どちらの判断も、現場を知っていればわかる。こうして、一人の天才が独力で作り上げたAccessシステムは、静かに消えた。
見えない属人化:システムを動かす設計思想
この話から私が考えるのは、「属人化」という言葉の本当の意味についてです。
属人化といえば「その人しか知らない業務プロセス」をイメージしがちだ。誰かが退職したら引き継ぎが大変。あの人しかやり方を知らない——そういう話として語られることが多い。
さらに、しかし彼のケースは、もう一段深い。
彼が作ったAccessシステムは、コードとして物理的に存在していた。Windowsのフォルダを開けばそこにある。誰でも開いて中身を見ることはできた。それでも、誰も「触れなかった」。
システムは存在していたが、そのシステムを動かしていた本当の力は。コードではなく彼の頭の中にあった。「なぜこの処理がここに入っているのか」「このロジックはBtoCの端数処理をどう想定しているのか」「この変数の命名にはどういう意図があるのか」——そういうすべての設計思想が。彼の記憶の中にしか存在しなかった。
属人化システムの終焉
まず、会社はシステムという「物」を得たつもりでいたが。実際には彼の頭を長期間借りていただけだった。彼が去った瞬間、そのシステムは「物」としては残ったが。「動かし続けられるもの」としては実質的に死んです。
これは彼が悪かったのではない。日々の経理業務をこなしながらシステムを一人で開発・維持していた人間に。完全なドキュメントを書き続ける余力があったとは考えにくい。
問題は組織側にある。「この人がいれば動く」という状態を長期にわたって放置した構造だ。天才が去った後に初めて、会社はその重さに気づく。いつもそのパターンが繰り返される。
AIが変えるコード解析、ドキュメント化の鍵
次に、この話を今書いているのは2025年だ。あの出来事から5年ほどが経つ。
生成AIが当たり前になった今。2020年当時の「莫大な費用をかけてシステム会社に解析を依頼する」というプロセスが。どれほど非効率に見えるかを、私は想像する。
あのAccessのVBAコードを。今ならClaudeやChatGPTに貼り付けるだけでいい。「このコードが何をしているかを説明してください」と聞けば。数分で処理内容の解説が返ってくる。「BtoCの端数処理のロジックはどこで処理されていますか」と聞けば。該当箇所をピンポイントで教えてくれる。「このシステムをPythonで書き直してください」と頼めば、移植案が出てくる。
一方で、無料で。数分で。

当時、莫大な費用をかけてシステム会社が行った解析作業の多くが。今なら誰でもほぼゼロコストで再現できる。あの費用は何だったのか、という感覚を私は正直に持っている。
ただ、一つ付け加えたい。
属人化を防ぐAIドキュメント術
そのため、生成AIがあっても、「ドキュメントを書く習慣がない」という根本問題は消えない。コードが存在してAIが解析できる状態ならまだいい。しかし設計の「なぜそうしたのか」という意図はコードに残らないことが多い。「なぜBtoCの端数はここで丸めているのか」「なぜこの条件式にこの例外処理が入っているのか」——そういう文脈は。作った人間の頭の中にしかありません。
だから今の時代に私が思うのは。生成AIをドキュメント化の「速度ブースター」として使うことだ。コードを書くたびに「このコードの処理概要と注意点をMarkdownで書いて」とAIに頼む。作りながら、その場でドキュメントを量産する。
属人化は、最後まで誰も問題にしないことが問題だ。困るのは常に、その人がいなくなった後だから。
しかし、—
最後に、私自身の話を少しだけ。
彼が転職してからほどなく、私も内部監査室を離れた。グループ親会社の本社から、自分がもともと所属していた事業子会社へ戻る。出戻りです。
さらに、天才は外の世界へ飛び出し、私は元の場所へ戻った。内部監査室に残ったのは、私たちが去った後に引き続く仕事と。誰もいなくなったことの静けさだけだった。
あのAccessのシステムと、少しだけ似ている気がした。
関連リンクとチェックリスト
著者はこうして解決の糸口を見つけた
著者も同じ境遇から始まりました。独学でここまで自動化した道のりを参考にしてみてください。
学習サービスとアンケート
このスキルを活かしてさらに前へ進むなら
Pythonや自動化スキルを体系的に習得して、ITエンジニアとしてのキャリアを切り開きたい方には「Enjoy Tech!(エンジョイテック)」が選択肢のひとつです。

