部署ごとに作ったノーコードアプリが増えて、作った人が辞めたら誰も直せない…情シス兼任の担当者が最初にやる「棚卸し」と引き継ぎの6ステップ

2026年10月12日2026年10月21日

部署ごとに「こんなアプリを作ってみた」が増えていくのは、現場が前向きに動いている証拠でもあります。一方で、ある日「作った本人が異動・退職する」と聞いたとき、情シス兼任の担当者に「このアプリ、誰が直せるのか」という問いが回ってきます。

「社内でノーコードで作ったアプリが増えて、作った人が辞めたら誰も直せない…」

先に結論をお伝えします。まず必要なのは、アプリを直せる人を探すことではなく、「何がいくつあり、誰のもので、止まると何が困るのか」を一覧にすること（棚卸し）です。すべてを守る必要はありません。止まると困るものだけを選び、「管理者の複数化」「1枚の引き継ぎシート」「開発会社に頼む範囲の決定」の3点を押さえれば、属人化のリスクは現実的な手間で下げられます。

この記事では、ノーコードアプリ（＝プログラムを書かず、画面操作で作る業務アプリ）が属人化する理由と、棚卸しから引き継ぎまでの6ステップを、そのまま使えるチェックリストと開発会社への質問例とあわせて解説します。

作った人が辞めると誰も直せなくなる3つの理由

ノーコードは「誰でも作れる」ことが強みですが、その手軽さが、そのまま属人化の原因にもなります。責められるべき人はおらず、仕組みとして起きやすいことです。

理由1：作る手間は小さいが、「作り方の記録」は残らない

プログラムのコードと違い、ノーコードの設定は画面上の選択や入力の積み重ねです。作った本人は「あの項目はこういう理由で足した」と覚えていますが、その理由はどこにも書かれていません。

理由2：アプリが、作った人の個人アカウントや権限に紐づいている

多くのサービスでは、アプリの「所有者」が作成者個人に設定されます。作成者が退職してアカウントが無効になると、アプリを編集できなくなったり、連携していた自動処理が止まったりすることがあります。この点は、サービスごとに仕様が異なるため、利用中のサービスの公式ヘルプで確認が必要です。

理由3：会社として「何があるか」を把握する担当がいない

部署ごとに自由に作れる運用だと、全体を見る人がいません。その結果、同じ目的のアプリが重複したり、使われていないのに残り続けたりします。

AIで業務ツールを作る人が増えている現在は、同じ構造がさらに起きやすくなっています。個人のアカウントで動くAI製ツールの扱いは、社員がAIで作った業務ツールが個人のアカウントで動いている…会社の管理に移す6ステップでも整理しています。

情報資産の一覧は、公的なガイドラインでも勧められている

「何があるかを一覧にする」ことは、情報セキュリティの基本とされています。IPAの中小企業向けガイドラインにも、資産管理台帳のサンプルが付録として用意されています。

📰 出典：IPA「中小企業の情報セキュリティ対策ガイドライン」（第4.0版・2026年3月公開）

このページで確認できるのは付録のタイトルまでなので、台帳の項目の細かい内容は、実際のサンプルファイルをご覧ください。社内のアプリの一覧づくりは、この考え方を応用する形で始められます。

棚卸しから引き継ぎまでの6ステップ

ステップ1：まず「アプリの一覧」を作る（所要の目安は1〜2時間）

各部署に声をかけ、次の項目をスプレッドシートに書き出してもらいます。精度は後から上げればよいので、最初は「分かる範囲」で十分です。

項目	例
アプリの名前と用途	見積の進捗管理、備品の貸出台帳
使っているサービス	利用しているノーコードのサービス名
作った人・今の管理者	作成者名、現在の編集権限を持つ人
使う人と頻度	営業5人が毎日、経理が月末だけ
連携先	メール、会計ソフト、他のアプリなど
入っているデータ	顧客情報を含む／含まない

ステップ2：「止まると困る度合い」で3段階に分ける

すべてのアプリを同じ熱量で守る必要はありません。次のように分けると、優先順位が決まります。

A（止まると業務が止まる）：請求・受発注・顧客対応など。最優先で守る
B（止まると不便）：進捗管理や集計など。代替手段（Excel等）がある
C（使われていない・個人用）：整理や停止を検討する

ステップ3：Aのアプリは「管理者を2人以上」にする

作成者1人だけが編集できる状態を解消します。権限の追加は、多くのサービスで管理画面から数分でできます。できれば、作成者とは別の部署の人を1人加えると、異動・退職への備えとして効果的です。

ステップ4：「引き継ぎシート」を1枚だけ作る

分厚い設計書は不要です。次の項目をA4用紙1枚にまとめます。

何のためのアプリか（目的）
誰が、いつ、どう使うか
連携している外部サービスと、その認証情報の管理場所
月次・年次で必要な作業（例：月末の締め処理）
困ったときの連絡先（社内の窓口、サービスのサポート）

作成者本人が元気なうちに書いてもらうことが最大のコツです。

ステップ5：作成者の退職・異動時のルールを決める

退職・異動のフローに「作成したアプリの引き継ぎ確認」を1行足すだけでも、効果があります。アカウントを無効にする前に、所有者の移管を済ませる順番にします。

ステップ6：直せない・拡張できないものは、開発会社に診断を頼む

次のような場合は、社内で抱え込まず、開発会社に診断を依頼する選択肢があります。

利用者が増えて動作が遅い、または料金が想定を超えた
基幹システムなど、他のシステムとの連携が増えてきた
権限の細かい制御や監査ログなど、サービスの標準機能で足りない要件が出た

「作り直す」ことを前提にせず、まず現状を見てもらい、そのまま使い続ける／整える／置き換えるのどれが合うかを聞くのが現実的です。内製と外注の線引きの考え方は、システムの内製化と外注どっちがいい？も参考にしてください。

「ノーコードで作ったものでも、現状を見せていただければ、続けるか置き換えるかを一緒に整理できます。まずは画面と利用状況を見せてください」

属人化対策でやりがちな失敗

全部を禁止する：現場の改善意欲が下がり、見えないところで勝手に作られる「シャドーIT」が増えがちです。禁止より「一覧に登録すれば使ってよい」とするほうが続きます
担当者を1人決めて任せきりにする：その担当者が異動すると、同じ問題が起きます。役割を2人にし、一覧は共有の場所に置きましょう
引き継ぎ資料を完璧にしようとする：重い資料は更新されなくなります。1枚で、必要な項目だけで十分です
認証情報を作成者のメールやメモに置いたままにする：連携のパスワードやAPIキーは、会社で管理する場所に移します

アプリを引き継ぐ際の考え方は、バイブコーディングで作ったアプリは開発会社に引き継げる？とも共通します。