担当者が変わっても工場の仕組みが回るように——手順書・権限・マスタの持ち主・外注先との契約を残す

工場の仕組みが「人と一緒に止まる」とはどういう状態か

製造業の現場では、表計算ソフトや小さなシステムで回っている業務がたくさんある。月初に生産計画の表を開いてボタンを押すと、受注の一覧から日程が組まれる。検査記録の表に測定値を入れると、成績書の形に整った一枚が出てくる。設備の点検はタブレットで記録し、月末に保全の担当者が集計する。FAX で届く注文書は、読み取りの設定をした人がいて、毎朝その結果を受注担当が確かめている。

これらは作った人がいる間はよく回る。困るのは、その人が異動したり辞めたりした後である。よく起きるのは次のような場面だ。

• 月初の生産計画のマクロがエラーで止まり、中を開いてもどこを直せばよいか分からない
• 品番が増えたのに、検査記録の表の規格値の欄を誰が足すのか決まっていない
• 設備点検のクラウドサービスの管理者が辞めた人の個人のメールアドレスで、契約の更新通知がどこにも届かない
• 受注の取り込みの設定を外部の会社に頼んだが、連絡先も契約書も前任者のメールの中にしかない
• 棚卸の表に貼ってある数式の意味を、今の担当者は説明できない

どれも「やり方が分からない」というより、誰の持ち物か決まっていないことが根にある。IPA が中小規模の製造業向けにまとめた DX のガイドは、業務の流れを図にし、組織ごとの役割分担を作って業務の流れを見えるようにするところから取り組むべきだとし、見えるようにすることで属人化した業務をなくすことにつながると書いている^[1]。同じガイドは、集めるべきデータの例として、図面・仕様書・操作マニュアルのような設計・技術の情報と並べて、業務フロー・規約やルール・作業手順・ノウハウといった業務の進め方そのものを挙げている^[1]。仕組みを動かすための決まりごとも、残すべき情報の一つということだ。

購買の発注の状況が担当者にしか分からない問題は、発注の状況を担当者しか知らないときの持ち方の記事で扱った。この記事は購買に限らず、受注・生産計画・検査・在庫・設備まで、工場の業務を回している仕組み全体の話として書く。

残すものを 5 つに分けて棚卸しする

「引き継ぎ資料を作る」と言うと、作った人の頭の中を全部書き出そうとして手が止まる。最初にやるのは、仕組みごとに何が残っていないと止まるのかを、決まった区分で並べることである。区分は次の 5 つで足りる。

仕組みの台帳を 1 枚作る

5 つの区分を、仕組みごとに 1 行で持つ台帳にする。列は、仕組みの名前、何の業務に使うか、置き場所、作った人、今の持ち主と副、何を入力にして何を出すか、止まったら困ること、外注先と契約の有無、くらいでよい。表計算 1 枚で始めて構わない。

IPA の中小企業向けの情報セキュリティのガイドラインは、組織で使っている情報機器やソフトウェアを正確に把握し、抜け漏れや管理の属人化を避けるために、ハードウェア・OS・ソフトウェア等の情報を整理するよう求め、拠点ごとのネットワークの構成機器や保守事業者の情報も整理するよう書いている^[2]。また、IT 資産の管理として、何がどこで誰に使われているかの把握と並べて、ライセンスや契約の期限の管理を挙げている^[2]。工場の仕組みの台帳は、この資産の管理の延長に置くと、情報システムの担当と現場の担当が別々に一覧を作らずに済む。

行を埋める順番は、止まったときに困る順でよい。出荷や請求に響く受注・計画・成績書の仕組みを先に、月に一度しか使わない集計を後にする。全部を一度に埋めようとすると、棚卸しそのものが担当者一人の仕事になり、また属人化する。

運用ルールは「誰が・いつ・何をするか」を業務の暦で書く

仕組みが止まる原因で多いのは、動かし方ではなく、動かす時期と担当が決まっていないことである。前任者は自分の予定表の中で月初・月末・年度末の作業をこなしていたので、それが紙に書かれていない。

運用ルールは、業務の暦に沿って書くと抜けにくい。

• 毎日：FAX で取り込んだ注文の確認、検査記録の入力漏れの確認、設備の日常点検の記録
• 毎週：生産計画の見直し、取り込みの失敗の一覧の確認
• 毎月：在庫の締め、検査の不良件数の集計、設備の稼働の集計
• 毎年：クラウドサービスやソフトウェアの契約の更新、規格値や標準時間の見直し、アカウントの棚卸し
• 起きたとき：品番の追加、設備の入れ替え、取引先からの様式の変更、担当者の交代

それぞれに、担当の役割（人の名前ではなく「生産管理の主担当」のような書き方）と副、終わったことをどこで確かめるかを書く。人の名前は台帳の側に置き、ルールには役割だけを書いておくと、人が替わったときに直すのは台帳の 1 か所で済む。

外部の会社に作ってもらった仕組みでは、運用の決まりを作るのが後回しになりやすい。IPA のモデル契約は、要件を決める段階から開発に移るときに、利用者のための運用の手順をどう決めるか、運用マニュアルをどう作るかを取り決める必要があるとし、特にバックアップについては範囲・手順・世代の管理まで配慮するよう書いている^[3]。作ってもらう側から見ると、運用ルールは納品の後に自分たちで考えるものではなく、作ってもらう間に一緒に決めておくものである。

手順書は「押すボタン」ではなく「何を確かめるか」を書く

手順書というと、画面の写しを並べて「ここを押す」と書いたものを思い浮かべる。それも要るが、人が替わったときに本当に困るのは、うまくいったかどうかを見分ける方法と、止まったときの戻し方が書いていないことである。仕組みの手順書には、次の項目を入れる。

• 目的：この作業で何を作るのか（例：翌月の工程別の日程表）
• 前提：始める前にそろっていなければならないもの（例：月末までの受注の取り込みが終わっていること）
• 手順：画面や操作の順番
• 確かめる値：結果が正しいかを見分ける数字（例：日程表の数量の合計が受注残の合計と合う）
• よくある止まり方と戻し方：エラーの表示ごとに、どこを見てどう直すか、直せないときに誰に連絡するか
• 更新の記録：最後に直した日と直した人

「確かめる値」を書いておくと、手順の途中で画面が少し変わっても、結果が正しいかどうかは判断できる。逆にこれが無いと、マクロが黙って間違った結果を出していても誰も気づかない。

技能の継承の調査から分かること

現場の技能の継承についての調査だが、文書にしておくことの差がはっきり出ている数字がある。労働政策研究・研修機構（JILPT）が 2018 年 11 月に製造業の従業員 30 人以上の企業 2 万社に送った調査では、回答した 5,867 社のうち、技能の継承を進めるために「継承すべき技能の見える化（テキスト化・マニュアル化・IT 化）を図る」と答えた企業は 49.9% で、高年齢の従業員に勤め続けてもらう（69.4%）に次いで多かった（複数回答）^[4]。さらに、技能の継承を「重要」と考える企業だけで比べると、継承がうまくいっている企業では 57.8% がこの見える化に取り組んでいたのに対し、うまくいっていない企業では 26.7% だった^[4]。

この数字は加工や組立の技能についてのもので、仕組みの手順書の効き目を測ったものではない。また、取り組んでいるからうまくいくのか、うまくいく会社だから取り組めるのかも、この比べ方だけでは分からない。それでも、人が替わる前提で文書にしておく会社とそうでない会社に差がある、という傾向は、仕組みを残すときにも当てはまる。技能の段階と教育の計画の持ち方は、製造業のスキルマップの作り方の記事にまとめた。

手順書が古くなるきっかけを決めておく

手順書は書いた日から古くなる。更新を「気づいたら直す」にすると、誰も直さない。設備の入れ替え、品番や様式の追加、表計算ソフトの版の変更、外注先による改修、担当の交代を、手順書を見直すきっかけとして運用ルールに書いておく。見直しは、副担当が手順書だけを見て作業をやってみて、つまずいたところを直すのが一番早い。

権限とアカウントは「管理者を一人にしない」から始める

工場の仕組みで人と一緒に消えやすいのが、管理者の権限とパスワードである。よくあるのは次の形だ。

• クラウドサービスの管理者が、導入した人の 1 アカウントだけで、しかも個人のメールアドレスで登録されている
• ライン横の端末や検査機につながるパソコンに、全員が同じ ID でログインしている
• 表計算のシートの保護やマクロの中身に、作った人しか知らないパスワードがかかっている
• サービスの料金が担当者の個人のカードや、辞めた人の名前の請求先で払われている

ID の発行から削除までの手続、共有 ID を避けること、異動や退職のときの権限の見直しと回収については、IPA のガイドラインも同じ趣旨を求めている^[2]。手続の組み立て方は購買システムのアカウント管理の記事で詳しく扱ったので、ここでは工場の仕組みで特に抜けやすい点に絞る。

工場で実際に決めることに置き換えると、次の 4 つになる。

• 管理者の権限は 2 名以上に持たせ、会社のメールアドレスで登録する
• 共有のログインが外せない端末は、使った人と時刻を紙か台帳に残す
• 表計算の保護やマクロのパスワードは、作った人だけが知る状態にせず、会社として決めた場所に保管する
• 契約の名義・請求先・更新通知の宛先は、個人ではなく部署にする

購買システムのアカウント管理と違うのは、ライン端末や設備につながる機械のように、人ではなく場所に付いたアカウントが混ざることである。こうしたアカウントは、人の入社や退職を合図にしても動かないので、台帳に「どの場所の端末か」と「管理する役割」を書き、年に一度の棚卸しで見る。

マスタは中身に責任を持つ部署を持ち主にする

仕組みが回り続けるかどうかは、マスタ（品目・部品表・工程・設備・規格値など、ほかのデータの元になる一覧）を誰が直すかで決まる。作った人がそのままマスタも直していると、その人が抜けたときに、誰も直さないか、誰もが勝手に直すかのどちらかになる。

持ち主は、そのデータの中身に責任を持つ部署にするのが筋がよい。ここで言う持ち主は、中身が正しいかを確かめて変更を申請する側のことで、台帳に登録・変更する操作と、その変更の承認は、持ち主とは別の人にする。

• 品目と部品表：設計または生産技術（図面と構成を決める部署）
• 工程と標準時間：生産技術
• 設備台帳と点検の項目：保全
• 検査の規格値と検査の項目：品質保証
• 取引先と購入単価：購買（申請する側。登録・変更の操作は購買以外が行う）
• 保管場所と在庫の単位：倉庫または製造

決めておくのは、持ち主の申請と承認を通した変更だけを台帳に入れる、登録の操作をする人を持ち主と分ける、直したら「いつ・誰が・何を・なぜ」を残す、の 3 つである。特に取引先マスタは、購買が申請し、登録・変更は購買以外（経理やマスタの管理担当）が行う。発注する人が自分で取引先を登録できると、実在しない相手に発注を出せてしまうからである。申請と承認を分ける理由と割り振りの例は、発注する人と検収する人を分ける記事とマスタの棚卸しの回し方の記事に書いた。IPA の DX のガイドは、業務の流れと並べて組織ごとの役割分担を作るよう勧めている^[1]。データの持ち主も、その役割分担の中で決めておくとよい。どのファイルが正なのか分からなくなる問題の止め方は、最新の購買ファイルが分からない問題の記事で購買の表を例に書いた。

属人化した表計算とマクロは、残す・書き直す・置き換えるを決める

工場には、担当者が自分で作った表計算とマクロがたくさんある。全部をシステムに置き換える必要はないし、全部をそのまま残すのも危ない。1 本ずつ、次の 3 つのどれにするかを決める。

• 残す：使う人が 1〜2 人、止まっても数日待てる、中身が短い。手順書を書き、副担当が一度動かせればよい
• 書き直す：中身が長く誰も説明できないが、業務としては要る。作った本人がいるうちに、本人と一緒に整理する
• 置き換える：複数人が同時に更新する、取引先や他部署とデータをやりとりする、記録を残す義務がある、止まると出荷が止まる。仕組みとして作り直す

判断の材料として、1 本ごとに、作った人、中身の説明があるか、他のファイルを参照していないか、外部から取り込んでいないか、どの版の表計算ソフトで動いているか、を台帳に書いておく。他のファイルの場所を決め打ちで参照しているマクロは、フォルダを整理しただけで止まる。置き換える仕組みが多いときに、どれから手を付けるかは、工場で最初にデジタル化する業務の選び方の記事で扱う。

社員が作ったマクロと、外部の人が作ったマクロは扱いが違う

社員が仕事として作ったマクロや表計算のプログラムは、著作権法で、法人の発意に基づいて業務に従事する者が職務上作成するプログラムの著作物は、作成の時の契約や勤務規則などに別段の定めがない限り、法人等が著作者になるとされている^[5]。辞めた社員が作ったマクロを会社が直して使い続けることは、通常この規定の範囲で考えればよい。

一方、個人事業主や外部の会社に頼んで作ってもらったものは、この規定が当てはまらない。著作権は契約で譲渡できるが、譲渡の契約で翻案の権利（著作権法第 27 条）と二次的著作物の利用の権利（第 28 条）が譲渡の目的として特掲されていないときは、譲渡した側に残っていると推定される^[5]。「著作権は当社に帰属する」と一行書いてあるだけでは、後で別の会社に改修を頼むときに足りない場合がある。次の節の契約の確かめ方で、ここを見る。

外注先との契約は、人が替わっても読める形で残す

受注の取り込みの設定、生産管理の追加の画面、設備のデータの収集など、外部の会社に頼んだ仕組みは、契約と納品物がそろっていないと、担当者が替わった後に直すことも乗り換えることもできない。残すものは次のとおり。

• 契約書と、個別の業務ごとの合意の書面（何を、どこまで、いくらで頼んだか）
• 納品物の一覧と、その実物（設計書、テストの記録、運用マニュアル、利用者向けのマニュアル、ソースコード）
• 構築や設定の作業で、実際にどう設定したかの報告
• 保守の窓口、連絡の方法、費用、更新日
• 権利の取り決め（誰が著作権を持ち、こちらは何をしてよいか）

IPA が経済産業省とまとめたモデル契約のうち、パッケージや SaaS を使う中小企業等の取引を想定した版では、個別の業務の内容を説明する書面に、利用者側と開発会社側の双方について、プロジェクトの管理に責任を持つ「責任者」と連絡窓口の「主任担当者」を明記する形にしている^[3]。納品物の書き方の例には、システム設計書、テストの仕様書と報告書、運用マニュアル、ユーザマニュアル、オブジェクトとソースコードを含むドキュメント一式が挙がっている^[3]。構築や設定の作業では、仕様書と実際の作業がずれた場合に備えて、実際の設定内容を報告書に書き、利用者が承認する形をとっている^[3]。担当者が替わったときに読むのは、まさにこの報告である。

著作権がどちらにあり、こちらが何をしてよいか

パッケージや SaaS を使う取引向けの版（追補版）は、カスタマイズで新しく作ったソフトウェアの著作権を、原則として開発会社に帰属させる考え方をとっている。その代わり、利用者が自分で使うための複製や翻案ができると定め、利用者の機密情報の保護は著作権を取らなくても秘密保持の条項で対応できるとしている^[3]。当事者が合意すれば、利用者に帰属させる案や共有の案を採ることもできる^[3]。一から作ってもらう受託開発の版は、著作権をすべて開発会社に帰属させる案、汎用的に使える部分は開発会社に、それ以外は利用者に帰属させる案、汎用的に使える部分は開発会社に、それ以外は共有とする案の 3 つから選ぶ形にしている^[7]。どれを選ぶかは費用とも関わるが、人が替わる前提で大事なのは、契約書のどの条で何が決まっているかを、契約した担当者でなくても読める状態にしておくことである。

確かめる点は 3 つある。著作権がどちらにあるか。こちらが自社で使うために直してよい範囲はどこまでか。別の会社に改修や保守を頼むときに、ソースコードや設計書を渡してよいか。この 3 つが分からないまま担当者が替わると、保守の会社を替えたくても替えられない。

クラウドサービスの場合は、モデル契約が選ぶときの確認項目として、サービスが廃止された場合の継続の手段（代わりのソフトの提供、ソースコードの開示等）や、データが保全されるかを挙げている^[3]。やめるときに困らないために契約の前に確かめることは、クラウド購買システムの出口対策の記事に書いた。

取適法が掛かる取引かどうかも見ておく

システムやプログラムを外部に作らせる取引は、取適法（中小受託取引適正化法）の情報成果物作成委託に当たることがある。ただし、自社で使うプログラムを頼む場合に当たるのは、自社で使う情報成果物の作成を業として行っている場合、たとえば社内に部門を設けて社内で使う会計用ソフトウェアを作っているような場合で、社内にシステム部門や詳しい社員がいても、頼んだものと同じ種類のソフトウェアを作っていなければ当たらないと、公正取引委員会のテキストは説明している^[6]。資本金や従業員の要件もあわせて満たすかを見る。

当たる場合は、作らせた成果物の知的財産権を譲り受けたり利用の許諾を受けたりすることまで含めて頼むなら、その範囲を発注の内容として明示し、その対価を代金に含める必要がある^[6]。作成の目的たる使用の範囲を超えて知的財産権を無償で譲渡・許諾させることは、不当な経済上の利益の提供要請に当たるとされている^[6]。「後で困らないように権利は全部もらっておく」は、取引によっては、それ自体が問題になる。

外注先の担当や会社が替わる場合

人が替わるのはこちらだけではない。外注先の担当者が替わったり、会社が廃業したりすることもある。IPA のガイドラインは、取引先との契約内容やセキュリティの要件が現在の状況に合っているか、問題が起きたときに誰に何を確認すべきかを明確にするよう求め^[2]、取引先との契約が終わるときには、機密性の高い情報やアクセス権を、責任者と期限を決めて回収または破棄するよう書いている^[2]。外注先に渡している管理者の権限や遠隔での接続の手段は、契約の終了や担当の交代のたびに見直す項目として台帳に入れておく。

担当者が替わると決まったら、やる順番

異動や退職が決まってから慌てないように、順番を決めておく。前任者がいるうちに済ませることを先に置いている。

1. 仕組みの台帳から、その人が持ち主・副・作成者になっている行を全部引き出す
2. 管理者の権限、契約の名義、更新通知の宛先を、副担当か部署に移す
3. 副担当が手順書だけを見て、前任者の前で一度作業を動かす。つまずいた所で手順書を直す
4. 前任者が作った表計算とマクロを、残す・書き直す・置き換えるに振り分ける
5. マスタの持ち主を、人の名前から部署の役割に付け替える
6. 外注先に担当の交代を知らせ、契約上の連絡窓口を書き換える
7. 個人のフォルダとメールにしかない契約書・納品物・やりとりを、決めた置き場所に移す
8. 退職の日にアカウントを止め、機器や鍵を回収する
9. 次の月次の締めと年次の更新が回ったかを、1 か月後と更新月に確かめる

購買の担当が替わるときは、取引先との約束や交渉の途中まで引き継ぐ必要がある。そちらは購買担当の引き継ぎで抜けるものの記事で扱った。

新しい仕組みを入れるときに、最初から組み込む

ここまでの話は、すでに属人化した仕組みを立て直す手順である。これから仕組みを入れるなら、最初から「人が替わっても回る」ことを条件にしておくほうがずっと楽になる。試験的に入れた仕組みを本番の業務に移すときに、運用ルール・手順書・管理者・マスタの持ち主・契約の窓口の 5 つが決まっているかを、続けるかどうかの判断の条件に入れておく。試験の導入を本番につなげる進め方は工場での試験導入を本番につなげる記事で、入れたツールが現場で使われなくなる理由は工場のツールが現場で使われない理由の記事で扱う。外部の会社に頼む場合は、頼む前に範囲を絞り、納品物と運用の決まりを依頼の中に入れておく。その頼み方はシステム会社に頼む前に範囲を絞る記事にまとめる。

よくある質問

作った本人がもう辞めていて、誰も中身を説明できないマクロがあります

まず、入力と出力だけを記録する。何を入れると何が出てくるかを、何回か実際に動かして残し、出てきた結果を手計算や別の方法で確かめる。結果が正しいと確かめられるなら、当面は残して手順書を書き、確かめる値を決める。結果が確かめられない、または中身を直す必要があるなら、書き直すか置き換える候補にする。社員が仕事として作ったものであれば、会社が直して使うことは通常問題にならない^[5]。

小さな工場で、仕組みを分かる人が一人しかいません

副担当を立てられなくても、管理者の権限を別の 1 人（社長など）にも持たせることはできる。それもできなければ、会社用の管理者アカウントを 1 つ作り、そのパスワードを封をして決めた場所に保管し、使ったら日時と使った人を記録し、使った後にパスワードを変える。普段の操作はそれぞれの人のアカウントで行い、この会社用のアカウントは共有のログインとして使わない。契約の名義と通知の宛先を個人から外すことも、一人でもできる。手順書は、社長や別の部署の人が読んで動かせるかで確かめる。一人しかいない会社ほど、休んだ日に止まる影響が大きい。

手順書を書く時間がありません

全部を書こうとしない。台帳で「止まったら出荷や請求に響く」とした仕組みだけ、目的・前提・確かめる値・止まったときの連絡先の 4 つを先に書く。画面の手順は、副担当が動かしながら書き足すほうが早い。

外注先の会社が廃業しそうです

契約書と納品物の一覧を出し、設計書・設定の報告・ソースコードを受け取っているかを確かめる。契約上の納品物に含まれているのに受け取っていないものがあれば、取引が続いているうちに引き渡しを求める。ソースコードなどが契約上の納品物に入っていなければ、当然には受け取れないので、対価を払って引き渡しと利用の範囲を取り決める。取適法が掛かる取引なら、その範囲と対価を発注の内容として明示する（前の「取適法が掛かる取引かどうかも見ておく」の節）。著作権が外注先にある場合は、こちらが自社で使うために直してよい範囲を契約で確かめる^[3][5]。クラウドサービスなら、データを書き出せるうちに書き出しておく。

まとめ

工場の仕組みが担当者と一緒に止まるのは、持ち主が人になっているからである。仕組みを運用ルール・手順書・権限とアカウント・マスタ・外注先との契約の 5 つに分けて台帳にし、それぞれの持ち主を部署の役割で決めて副を置く。運用ルールは業務の暦で書き、手順書には確かめる値と戻し方を書く。管理者は 2 名以上にして会社のアドレスで持ち、マスタは中身に責任を持つ部署が変更を申請し、登録の操作と承認は持ち主とは別の人（マスタの管理担当など。承認と登録は同じ人でよい）が行う。属人化した表計算とマクロは、残す・書き直す・置き換えるに振り分ける。外注先が作ったものは、著作権の帰属とこちらが直してよい範囲、納品物と設定の報告がそろっているかを確かめる。そして担当者がいるうちに、副担当が手順書だけで一度動かす。

出典・参考資料

1. 中小規模製造業者の製造分野におけるデジタルトランスフォーメーション（DX）推進のためのガイド　製造分野 DX の目指す姿への推進 ～製造分野 DX 度チェック利用の手引き～（独立行政法人情報処理推進機構 社会基盤センター）
2. 中小企業の情報セキュリティ対策ガイドライン 第 4.0 版（独立行政法人情報処理推進機構／2026 年 3 月）
3. 情報システム・モデル取引・契約書（パッケージ、SaaS/ASP 活用、保守・運用）〈第二版 追補版〉（独立行政法人情報処理推進機構・経済産業省／2020 年 12 月・2025 年 4 月更新）
4. 調査シリーズ No.194「ものづくり産業における技能継承の現状と課題に関する調査結果」（労働政策研究・研修機構）
5. 著作権法（昭和四十五年法律第四十八号）（e-Gov 法令検索（デジタル庁））
6. 中小受託取引適正化法テキスト「下請法」から「取適法」へ（公正取引委員会・中小企業庁／令和 7 年 11 月）
7. 情報システム・モデル取引・契約書（受託開発（一部企画を含む）、保守運用）〈第二版〉（独立行政法人情報処理推進機構・経済産業省／2020 年 12 月・2025 年 4 月更新）

WHITE PAPER

この記事の理解を深める
無料ホワイトペーパーをプレゼント

製造業の現場で使える実務資料（PDF）を無料でお届けします。"こんな資料が届きます" ↓ 下のボタンからどうぞ。

🔒 全文は無料ダウンロードで