非エンジニアがPythonツールの保守を任されたら最初にやること【チェックリスト付き】

Pythonで作られたスクリプトやツールの保守を任された——そんな状況になった方が読んでいるのではないでしょうか。

「前任者が辞めて、気づいたら自分がツールの担当になっていた」「上司に頼まれたけど、Pythonなんてほとんど触ったことがない」。こういうケースは、製造業や総務部門でかなり起きています。

ただ、ここで「まずPythonを勉強しよう」と考えるのは、一旦止めた方がいいです。

保守の目的は「コードを書けるようになること」ではなく、「今動いているツールを壊さずに維持すること」なのです。目標が違えば、やることも変わります。

この記事では、Pythonの知識がほぼない状態から保守担当になった方向けに、以下の3点を整理します。

  • 引き継いだ直後に確認すること（チェックリスト）
  • よくあるエラーと、コピペで使える対処法
  • 自分でやる場合とエンジニアに頼む場合の判断基準

読み終えると、「何も知らない自分がどう動けばいいか」の見通しが立ちます。

まず「自分の守備範囲」を決める

保守を任されると、全部自分でやらなければいけないような気がします。ただ、Pythonツールの保守には「非エンジニアでも対応できる範囲」と「エンジニアに頼むべき範囲」があります。

この線引きを最初にしておかないと、無理に触って壊してしまうか、逆に全部エンジニアに投げて何も前に進まない、という状況になりがちです。

非エンジニアでも対応できる範囲

以下は、Pythonがわからなくても対応できることがほとんどです。

  • ファイルパスの変更: フォルダを移動したことでエラーが出た場合
  • ライブラリの再インストール: pip install コマンドで解決できるエラー
  • 設定値の変更: コード内の数字や文字列（ファイル名・シート名など）の変更
  • 実行環境の確認: PythonのバージョンやOSの確認
  • バックアップの管理: 修正前のファイルを保存しておく作業

エンジニアに頼むべき範囲

以下は、無理に自分で対応しようとするとリスクが高い領域です。

  • 処理の流れそのものを変える改修
  • 新しい機能の追加
  • データベース（SQLite・PostgreSQLなど）が絡む修正
  • 外部APIや社内システムとの連携箇所の変更
  • ログイン・権限などのセキュリティ関連

「エラーが出た原因は分かったが、コードのロジックそのものを変えないと解決しない」という場合は、エンジニアに頼む方が安全です。

引き継いだ直後にやること【チェックリスト】

ツールを引き継いだ当日〜最初の1週間でやっておくことを整理しました。焦って触り始めるより、まず「現状を把握する」ことが最優先です。

① スクリプトファイルの場所と構成を確認する

まず「どこに何のファイルがあるか」を把握します。確認すべきポイントは以下です。

  • メインのスクリプトファイルはどれか（.py という拡張子のファイル）
  • 設定ファイル（.json・.ini・.env など）はあるか
  • 読み込んでいるCSVやExcelファイルはどこにあるか
  • README.md や手順書はあるか

ファイル名から処理内容を推測できることが多いです。例えば nippo_shuukei.py（日報集計）や zaiko_check.py（在庫チェック）のように、業務名がそのまま入っていることがほとんどです。

② 実行方法を確認する

  • バッチファイル（.bat）をダブルクリックで実行するタイプか
  • コマンドプロンプトからコマンドを打つタイプか
  • スケジューラ（タスクスケジューラなど）で自動実行されているか

前任者から引き継ぎドキュメントをもらえれば一番ですが、ない場合は周囲に「このツール、どうやって動かしていましたか？」と聞いてみることをすすめます。

③ バックアップを取る（これが一番重要）

スクリプトを触る前に、必ずバックアップを取ります。

例：ファイルをコピーしてリネームする

zaiko_check.py  →  zaiko_check_backup_20260513.py

日付をファイル名に入れておくと、「いつの状態か」がわかります。これだけで、万が一壊してしまっても元に戻せます。

④ Pythonの実行環境を確認する

コマンドプロンプトを開いて、以下を実行してみてください。

python --version

Python 3.x.x という表示が出れば、インストール済みです。表示されない場合は「Python インストール」で検索して、公式サイトからダウンロードしてください。

また、仮想環境（venv）を使っているケースがあります。フォルダの中に venv または .venv というフォルダがあれば仮想環境が使われています。このフォルダがない場合は気にしなくて大丈夫です。 ある場合のみ、仮想環境を有効化してから実行する必要があります。

（仮想環境の扱いで詰まった場合は、後述の判断基準に従い、エンジニアへ相談するのも一手です。）

⑤ ドキュメントとコメントを探す

コード内にコメント（# で始まる行）があれば、処理の意味が書かれていることがあります。ない場合は、変数名や関数名から推測するしかありません。

# 在庫数が10以下の品目をリストアップする
low_stock = df[df['在庫数'] < 10]

このようにコメントがあれば理解しやすいですが、ない場合でも変数名 low_stock（在庫が少ない）からある程度の推測はできます。

よくあるエラーと対処法【コピペOK】

引き継いだ後に遭遇しやすいエラーを5パターンまとめました。エラーメッセージをそのままコピーしてGoogle検索するのも有効ですが、よく出るパターンは以下です。

① FileNotFoundError（ファイルが見つからない）

FileNotFoundError: [Errno 2] No such file or directory: 'C:/Users/tanaka/data/nippo.csv'

原因: スクリプトが参照しているファイルのパスが変わった（フォルダを移動した、PCを変えたなど）

対処法:

  1. エラーメッセージの中のパス（'C:/Users/tanaka/data/nippo.csv' の部分）を確認する
  2. 実際にそのファイルがどこにあるかを探す
  3. スクリプト内の該当箇所を見つけ、正しいパスに書き換える
# 修正前（前任者のPCのパス）
file_path = 'C:/Users/tanaka/data/nippo.csv'

# 修正後（自分のPCに合わせたパス）
file_path = 'C:/Users/yamamoto/data/nippo.csv'

パスの部分だけ書き換えれば動くことがほとんどです。

② ModuleNotFoundError（ライブラリが入っていない）

ModuleNotFoundError: No module named 'pandas'

原因: 必要なライブラリがインストールされていない（新しいPCに移行した場合など）

対処法: コマンドプロンプトで以下を実行する

pip install pandas

pandas の部分をエラーに出てきたモジュール名に変えれば他のライブラリも同様に対処できます。よく出るのは openpyxl・requests・matplotlib などです。

③ PermissionError（権限エラー）

PermissionError: [Errno 13] Permission denied: 'C:/Users/shared/data.xlsx'

原因: 対象ファイルが別のアプリで開かれている（Excelで開いたまま実行するなど）

対処法: 対象のExcelやCSVファイルを閉じてから再実行する。これで解決することが多い。解決しない場合は、ファイルへのアクセス権限の問題が考えられるため、システム担当者やエンジニアへ相談する。

④ SyntaxError（構文エラー）

SyntaxError: invalid syntax

原因: コードの文法が壊れている。修正を加えた際に誤って消してしまった場合に起きやすい。

対処法: バックアップから元のファイルを復元する。これが、バックアップを取っておく最大の理由です。修正前のファイルがあれば、迷わず戻せます。自分で変更を加えていない場合は、Pythonのバージョン更新が原因のことも多く、その場合はエンジニアへ相談が一番早い対処です。

⑤ エラーはないが結果がおかしい

エラーメッセージは出ないのに、出力されたデータや集計値がおかしい——という場合があります。この場合は「何か変えたか」を思い返してください。設定値（ファイルパス・シート名・列名）を変更した直後に起きていることがほとんどです。変更前の状態に戻して、一つずつ確認していくのが一番安全な手順です。

コードを「読む」ための最低限の知識

製造業の生産管理現場でPythonツールを引き継いだ経験から、ここで紹介する内容を整理しています。覚えるためではなく、「触る前に確認する」ための知識として読んでください。

Pythonを書けなくても、「ここが何をしているか」をなんとなく読めると保守の幅が広がります。以下の3点を押さえるだけで、多くの場面に対応できます。

変数名・ファイル名から処理を推測する

Pythonは変数名や関数名に日本語ローマ字や英語を使うことが多く、処理内容のヒントになります。

変数名推測できる処理
dfデータフレーム（表のデータ）
file_pathファイルの場所
output / result出力・結果データ
sheet_nameExcelのシート名
target_date対象の日付

触ってよい箇所と触ってはいけない箇所

触ってよい箇所（設定値）:

  • ファイルパスの文字列（'C:/data/...' のような部分）
  • シート名や列名（'Sheet1'・'品目名' など）
  • 数値の閾値（< 10・>= 100 のような比較値）

触ってはいけない箇所:

  • def で始まる関数の定義
  • import で始まるライブラリの読み込み
  • for や if など制御構造の内側のロジック

設定値を変えるだけなら問題が起きにくいですが、ロジックを変えると意図しない挙動につながります。

修正するときはコメントで記録を残す

修正した箇所には、日付と理由をコメントで残すことをすすめます。

# file_path = 'C:/Users/tanaka/data/nippo.csv'  # 前任者のパス
file_path = 'C:/Users/yamamoto/data/nippo.csv'   # 2026-05-13 yamamoto修正

これがあるだけで、次に誰かが引き継いだときに助かります。私自身も、前任者がコメントを残してくれていたおかげで、原因究明に1日かかるところが30分で終わった経験があります。

保守を続けるための運用ルール

引き継ぎ直後だけでなく、継続的に保守を続けるために整えておくと楽になることがあります。

修正記録を残す

Excelやメモ帳でいいので、「いつ・何を・なぜ変えたか」を記録します。

日付変更箇所変更内容理由
2026-05-13file_pathパスを自PCに変更前任者退職のため
2026-05-20sheet_name'Sheet1'→'日報' に変更Excelのシート名変更に合わせて

これが後々の引き継ぎにも使えます。

エンジニアに頼むときのメモ

エンジニアへ相談するとき、状況をうまく伝えられないと時間がかかります。以下の情報をまとめてから相談すると、スムーズです。

  1. どのスクリプト（ファイル名）で起きているか
  2. エラーメッセージの全文（コピペ）
  3. 最後に変更を加えた日・内容
  4. 「このエラーの前は動いていた」か否か

この4点があれば、エンジニア側でも状況の把握が格段に速くなります。「何が起きているかわからない」という状態で相談するより、解決までの時間が体感で大きく変わります。

まとめ

非エンジニアがPythonツールの保守担当になったとき、「Pythonを覚えなければ」という方向に進みがちです。ただ、保守の目的は「コードを書けるようになること」ではなく、「今のツールを壊さずに動かし続けること」なのです。

そのために必要なのは、以下の3つです。

  • 引き継いだ直後: ファイル構成・実行方法・バックアップの確認
  • エラーが出たとき: パターン別の対処と、自分でやる/エンジニアに頼む判断
  • 継続運用: 修正記録とエンジニアへの適切な相談

「コードを書けない自分でも、何とかできる場面とできない場面がある」——この線引きができると、保守担当としてかなり安定します。

社内にPythonツールを作った経緯や、どんな業務に活用できるかについては、以下の記事も参考になります。

→ 社内の非エンジニアにPythonツールを展開する方法（ツールを渡した側の設計を知ると、保守時の理解が深まります）

→ 製造業でPythonを導入するとどう変わるか（社内にそのツールが生まれた背景を理解するのに役立ちます）

→ 製造業でPythonで自動化できる業務5選（あなたが引き継いだツールがどんな業務のためにあるか、整理できます）

引き継ぎ直後にやることのチェックシートと、よくある修正パターンはNoteにまとめる予定です。公開した際はブログでご案内します。

スポンサーリンク