はじめに
今日は少し 現場寄り の話をします。
DXが進み、AIも普及し、
「非エンジニアが自分の業務を自動化する」 そんな場面が増えてきました。
- Excelマクロ
- Power Automate
- Google Apps Script
- ノーコードアプリ
- ChatGPTが生成したPythonスクリプト
- 共有フォルダに置きっぱなしの謎ツール
便利ですよね。
私自身、“現場でできる工夫” はとても肯定派です。むしろ担当者が自ら自動化出来れば最強だと思っています、
でも最近（ここ１年）、ある相談が妙に増えてきて、ちょっと思うことがありました。
「担当者が辞めて、中身が誰もわからないツールが残ってしまった」
「開発した会社ごと無くなっていて、直せない」
「プロジェクトもコードも何も残っていないのに業務が依存している」
──これ、すべて “小さな市民開発ツールがレガシー化” している状態です。
今回は、現場で感じた “静かに増えている新種のレガシー問題” についてまとめつつ、最後に 「レガシー化を防ぐための最低限テンプレート」 を作成してみました。
1. DXが進むほど、“影のシステム”は増える
DXはレガシーを減らすはず──ですが、実際には 「管理されない小さな仕組み」が急増しています。
理由はシンプル。
✔ 非エンジニアでもアプリが作れる
✔ AIでコード生成もできる
✔ そのまま業務に組み込まれる
✔ でも誰も全体を把握しない
こうして、“誰が作ったか分からない謎ツール“ が、気づけば重要業務の中心に鎮座してしまう。
私はこれを “小さな影のシステム（Shadow IT）” と呼んでいます。
2. 小さいけれど危険な「レガシー予備軍」
この１年間にあった実際の会話でも、こんな典型的なケースが挙がりました。
- 開発した会社がもう無い
- 担当者が異動・退職
- 実行方法が分からない
- 何を参照しているのか分からない
- 仕様書もプロジェクトも残っていない
- でも止めると業務が止まる
つまり、
小さいのに、止まると致命的なアプリ
これが一番危険です。
レガシーは、巨大システムだけではありません。「ドキュメント0の Excel マクロ」が将来のレガシーを生むこともある。
3. 解決の本質は、“作らせないこと”ではない
市民開発を禁止すれば安全…
ではありません。
そんなことをしたら現場の改善力が死んでしまう。
結局のところ大事なのは、
非エンジニアが作ったツールでも“引き継げる形”にしておくこと
これだけです。
難しい設計書は不要です。
1枚でいい。
むしろ 1枚の方が続く。
今回の会話を整理して、
どんな小さなアプリにも共通する 最低限のドキュメント項目 を作ってみました。
4 レガシー化を防ぐための「最低限ドキュメント」
Excelマクロでも、PowerAutomateでも、AI生成スクリプトでも使えるよう、完全汎用で、必要最小限 にまとめました。
1. 作成者情報
【記載例】
- 作成者：山田太郎
- 所属：営業管理部
- 作成日：2024/01/15
- 最終更新日：2024/11/20
なぜ必要
作った人が誰かわからないと、引き継ぎの手がかりすらつかめません。責任追及ではなく「どんな業務の文脈で作られたか」を理解するための情報です。
2. アプリの目的
【記載例】
- 毎朝の売上データ集計（手作業だと2時間）を自動化
- 複数店舗のExcelを統合してレポート作成
なぜ必要
「何を解決しようとしたか」がわからないと、修正や改良の判断ができません。1～2行でいいので、置き換えた手作業の内容も書いておきましょう。
3. 入力（IN）
【記載例】
- 種類：Excel（.xlsx）
- 置き場所：\server\sales\daily\
- フォーマット：A列=日付、B列=売上、C列=店舗名
- 実行トリガー：毎朝9時（タスクスケジューラ）
なぜ必要
データがどこから来るかわからないと、エラーの原因究明すらできません。特にファイルパスやフォルダ構成は変わりやすいので要注意。
4. 出力（OUT）
【記載例】
- 保存先：\server\report\monthly\
- 出力形式：CSV（UTF-8）
- 使う人・部署：経理部・月次決算処理
- この結果に依存している業務：請求書発行システム
なぜ必要
出力結果に依存している業務や人を把握しておかないと、うっかり止めて大問題になることがあります。
5. 動作の流れ（1行でOK）
【記載例】
売上Excel読込 → 店舗別集計 → 異常値チェック → CSV出力 → 完了メール送信
なぜ必要
複雑な処理でも、大まかな流れがわかれば問題の切り分けができます。詳細不要、矢印でつなぐだけでOK。
6. 依存物（壊れやすさの源）
【記載例】
- 共有フォルダ：\server\master\（店舗マスタ）
- 外部ツール：7-Zip（圧縮処理で使用）
- Excelバージョン：2016以降必須（TEXTJOIN関数使用）
- 他のマクロ：Common.xlsm（共通関数）
なぜ必要
ここが一番重要かも。外部環境が変わると動かなくなる要因を全て書いておきます。
7. 実行方法
【記載例】
- 「売上集計.xlsm」を開く
- 「データ更新」ボタンをクリック
- 処理完了まで約5分（途中で閉じない）
- 注意：月初は処理が重いので10分程度かかる
なぜ必要
「どうやって動かすの？」が分からないと、テストすらできません。初めて触る人でも動かせるレベルで書きます。
8. よくあるエラーとその対処
【記載例】
- 「ファイルが見つかりません」→ 共有フォルダの接続確認
- 「型が一致しません」→ 日付列に文字が混入している可能性
- 処理が終わらない → Excelの自動計算をOFFにしてから実行
なぜ必要
エラーが出た時、過去の経験がないとお手上げになります。よくある問題と解決方法を残しておけば、誰でも対処できます。
9. 変更履歴（1行でよい）
【記載例】
- 2024/03/01：田中が出力先フォルダを変更
- 2024/07/15：鈴木が新店舗コード追加対応
- 2024/11/20：山田がエラー処理を追加
なぜ必要
いつ、誰が、何を変えたかがわかると、不具合の原因特定が早くなります。GitHubは不要、1行メモで十分。
5 未来のレガシーは「小さなツール」から生まれる
DXは便利になりました。
非エンジニアが自分の手で業務を改善できるのは本当に良いこと。
しかしその裏で、
今日つくられた “小さな仕組み” が、10年後のレガシー予備軍になっている
という現象も確実に起きています。
だから必要なのは、
禁止ではなく、未来の誰かが困らないための小さな習慣。
それが、上で紹介した “1ページのメモ” だけです。
6 おまけ - テンプレート
■ 1ページ版（Markdown）
## 小さな業務アプリ 最低限ドキュメント（1ページ）
### 作成者情報
- 作成者：
- 所属：
- 作成日：
- 最終更新日：
### アプリの目的
-
### 入力（IN）
- 種類：
- 置き場所：
- フォーマット：
- トリガー：
### 出力（OUT）
- 保存先：
- 形式：
- 利用者・依存業務：
### 動作の流れ
-
### 依存しているもの
-
### 実行方法
-
### よくあるエラー
-
### 変更履歴
-
おわりに ── 小さなアプリにも、小さな未来設計を
「自分だけが使うつもりで作ったツール」が、いつの間にか部署全体で使われている──そんな光景、きっと今からどんどん増えてくると思います。
AI時代になり、アプリを作るのはもうエンジニアだけの特権ではなくなりました。AIにお願いすれば、誰でも業務改善ツールが作れる。
どんなに小さなアプリでも、それが誰かの役に立つなら、未来の誰かが引き継げる形にしておく。
あなたが今日作る小さな改善が、10年後も誰かの業務を支えているかもしれない。その時、レガシーではなく「財産」として残っているように──。