本文へスキップ
スキルアップカレッジ

作った仕組みを止めないために

レッスン7：作った仕組みを止めないために

このレッスンで学ぶこと

  • ノーコードが向かない場面を、具体的なサインで見分けられる
  • 属人化がなぜ起こるのか、そのメカニズムを理解する
  • 属人化させないための最低限のルール（作った理由を残す・引き継ぎ・棚卸し）を実践できる
  • 権限とデータの扱いにおける基本的な注意点を理解する
  • 手に負えなくなったサインを見極め、技術者に判断を渡す基準を持つ

前のレッスンでは、サイトビルダー型のツールを使ってWeb サイトやページを組み立てる発想を学びました。レッスン1から6までは、一貫して「どう作るか」を扱ってきました。このレッスンからは視点を切り替えます。せっかく作った仕組みも、使い続けられなければ意味がありません。ここで扱うのは「どう使い続けるか」、つまり作った仕組みを止めないための考え方です。

レッスン1で示した本コースの背骨には、次の2つのメッセージがありました。「自分だけが使える仕組みは、自分が動いた瞬間に止まります」「手に負えなくなったと感じたら、それは技術者に渡す合図です」。このレッスンは、この2つを具体的な行動に落とし込むための時間です。

ノーコードが向かない場面を、もう一段掘り下げる

レッスン1では、ノーコードが向かない業務の特徴として、大量データの高速処理、複雑な条件の組み合わせ、厳格な権限管理と監査記録、既存システムとの深い連携の4つを挙げました。ここで注意したいのは、これらの多くが「最初から向かない」というより、「使っているうちに、じわじわと向かなくなっていく」という形で現れる点です。

小さく作って使い始めた仕組みが評判になり、扱う件数が増え、関わる人が増え、要望が積み重なる。この成長のプロセス自体は、レッスン1の中核メッセージにあった「小さく作って、使いながら直す」の望ましい結果です。ですが、育ち方によっては、いつのまにか向かない領域に踏み込んでいることがあります。次の表は、その兆候を整理したものです。

向かない領域 育つ過程で見えるサイン
複雑な条件の組み合わせ 「この場合は」という例外の条件分岐が、追加するたびに増え続けている
大量データの処理 データの件数が増えるにつれて、一覧の表示や集計に待たされる時間が目立つようになった
厳格な権限管理 「誰が何を見られるか」を細かく分けたい要望が、ツールの設定だけでは追いつかなくなってきた
既存システムとの連携 ほかの基幹システムのデータと、手作業での突き合わせが常態化している

💡 ポイント 1つのサインが出ただけで、すぐに作り直しを考える必要はありません。大切なのは、こうしたサインが複数重なっていないかを、意識して確認する習慣を持つことです。気づかないまま放置すると、無理な回避策を重ねることになり、あとになるほど手放しにくくなります。

属人化とは何か、なぜ起こるか

「属人化」とは、ある仕組みの内容や動かし方を、特定の1人（またはごく少数）しか把握していない状態を指します。ノーコードは、属人化と特に相性の悪い作り方です。理由は単純で、作るのが手軽だからこそ、設計の意図を言葉に残さないまま完成してしまいやすいためです。

プロコードの開発では、複数人で分担して作る前提があるため、仕様書やコードの説明を残す文化が根付いています。一方、ノーコードでは、1人の担当者が思いつくままに設定を積み重ねていっても、それなりに動く仕組みが仕上がってしまいます。その手軽さが長所であると同時に、「なぜこの設定にしたのか」が、作った本人の頭の中にしか残らない原因にもなります。

属人化が進んだ仕組みは、次のような形で表面化します。

  • 担当者が休んだだけで、簡単な設定変更さえ誰もできなくなる
  • 担当者が異動・退職した瞬間に、仕組みの中身を誰も説明できなくなる
  • 「なぜこの条件になっているのか分からない」という状態のまま、誰も手を入れられず放置される

これが、レッスン1の中核メッセージ「自分だけが使える仕組みは、自分が動いた瞬間に止まります」が指している状態です。仕組み自体は正しく動いていても、担当者という1点に依存している限り、いつ止まってもおかしくありません。

属人化させないための最低限のルール

属人化を防ぐために、分厚いマニュアルを整備する必要はありません。むしろ、ノーコードの手軽さを損なわない範囲で、最低限のルールを習慣にすることのほうが、長く続きます。ここでは3つのルールを紹介します。

1. 作った理由を残す

仕組みを作ったら、「何のために、どういう考えでこう設計したか」を、短い文章で残しておきます。テーブルをこう分けた理由、条件分岐をこの順番にした理由、通知をこの相手に絞った理由といった、判断の背景です。完成した仕組みの見た目だけを見ても、こうした判断の理由は読み取れません。

書く分量は、1つの仕組みにつき数行から1ページ程度で十分です。目的は、完璧な設計書を作ることではなく、あとから引き継いだ人が「なぜこうなっているのか」で迷わないようにすることです。

2. 引き継ぎを前提にした手順を作る

「自分がいなくても、ほかの人が最低限の対応をできるか」を基準に、引き継ぎの手順を整えます。最低限含めておきたい内容は、次の3つです。

  • 管理画面へのたどり着き方（どこにログインし、どこを見れば設定が確認できるか）
  • 今動いているトリガーとアクションの一覧（何をきっかけに、何が実行されているか）
  • 困ったときに、誰に連絡すればよいか

理想は、実際に別の担当者にこの手順だけを渡して、一度操作してもらうことです。文章ではわかったつもりでも、実際にやってもらうと、抜けている情報に気づけます。

3. 定期的に棚卸しをする

「棚卸し」とは、今動いている仕組みを一覧に洗い出し、それぞれがまだ必要か、正しく動いているかを確認する作業のことです。使われなくなった申請フォームが動いたままになっている、担当者が変わったのに通知先が更新されていない、といった状態は、棚卸しをして初めて見つかります。

棚卸しの頻度に決まった正解はありませんが、「思い出したときにやる」では確実に忘れられます。半年に1回、年度の節目になど、ほかの定例業務と同じタイミングに組み込んでおくと、忘れにくくなります。

🔰 初学者の方へ 3つのルールに共通しているのは、「完璧を目指さない」という姿勢です。理由を残す・引き継ぐ・棚卸しをする、のいずれも、完璧にやろうとすると重くなり、結局続きません。まずは短くてもよいので、始めることを優先しましょう。

権限とデータの扱い

仕組みが育ち、扱うデータや関わる人が増えると、「誰が何を見られるか」「誰が何を変更できるか」という権限の設計が重要になります。

基本の考え方は、必要な人に、必要な範囲だけを見せる・触らせるという「最小権限」の発想です。全員に全項目を見せる、全員に編集の権限を与えるといった作り方は、始めるときは楽ですが、個人情報や金額といった扱いに注意が必要な情報が混ざり始めると、思わぬところから情報が漏れる原因になります。

ノーコードツールは、権限の設定そのものは比較的簡単に行えるものが多くあります。問題は、設定できることと、実際に設計されていることは別だという点です。仕組みを作った時点では関係者が少なく、権限を細かく分ける必要を感じないことも多いのですが、利用者が増えるたびに、「この人には、この項目は見せなくてよいのではないか」を見直す機会を持つ必要があります。

⚠️ 注意 情報システム部門が把握しないまま、現場の判断だけでノーコードツールが次々と使われ始め、誰がどのデータを扱っているか会社として把握できない状態になることがあります。この状態は「シャドーIT」と呼ばれ、セキュリティ上の見えないリスクを生みます。新しい仕組みを作ったら、関係する部署に一声かけておく習慣が、この状態を防ぐ第一歩です。

データの扱いについても、レッスン4で扱った「削除ではなく状態の更新で記録を残す」という考え方が、ここでも重要になります。誰が、いつ、何を変更したかが追える状態を保っておくことは、権限管理と表裏一体の取り組みです。

技術者に渡す判断

ここまでの工夫を尽くしても、仕組みが育つ過程で「これはノーコードの範囲を超えた」と感じる瞬間が訪れます。その瞬間を先送りにせず、技術者に判断を渡すことも、止まらない仕組みを保つための重要な選択です。

判断の目安となるサインを、次の図に整理しました。

flowchart TD
  A[運用中の仕組みを定期的に見直す] --> B{条件分岐が増え続けているか}
  A --> C{データ量や利用者が急増しているか}
  A --> D{個人情報や機密情報の扱いが増えたか}
  B -->|複数該当| E[技術者に相談する]
  C -->|複数該当| E
  D -->|複数該当| E
  B -->|該当なし| F[現状のまま運用を続ける]
  C -->|該当なし| F
  D -->|該当なし| F

この図が示すように、判断は1つのサインだけで決めるのではなく、複数の兆候を定期的に見直しながら下します。技術者に相談すること自体は、ノーコードでの取り組みが失敗したことを意味しません。むしろ、レッスン1の中核メッセージにあるとおり、「手に負えなくなったと感じたら、それは技術者に渡す合図」であり、適切なタイミングでの判断そのものが、仕組みを止めない工夫の一部です。

技術者に渡すときに役立つのが、本コースを通じて学んできた共通言語です。「このトリガーで、このアクションが動き、この条件で分岐する」「データはこのテーブル構成で持っている」と伝えられれば、技術者は、ノーコードの画面を1から確認しなくても、仕組みの全体像を短時間でつかめます。ツールの操作方法ではなく、トリガー・アクション・条件分岐・データモデルという設計の言語で伝えることが、引き継ぎの質を大きく左右します。

なお、決まった操作を人の代わりに大量かつ高速に繰り返す必要が出てきた場合は、レッスン5で触れたRPAと呼ばれる別の領域が候補になることもあります。ノーコードのワークフロー自動化とは目的も設計の考え方も異なるため、この切り分けも、技術者に相談する場面の1つです。

講師の現場メモ②：40件以上作って、3件を止めてしまった話

私（岩井）は、業務改革部門で9年の間に、部門をまたいで40件以上の申請・台帳・集計の仕組みを作ってきました。その多くは、いまも問題なく動いています。ですが、すべてがうまくいったわけではありません。正直に振り返ると、そのうち3件は、担当者の異動をきっかけに止まってしまいました。

1件目は、ある部署の在庫管理の仕組みでした。作った当初は私が中心となって運用しており、細かい調整もその都度自分で行っていました。異動が決まったとき、後任者に一通りの操作は説明したつもりでしたが、「なぜこの条件で通知を分けているのか」という設計の理由までは、十分に言葉にして残していませんでした。半年後、通知の設定がうまく動かなくなったとき、後任者は原因を調べる手がかりがなく、結局その仕組みは使われなくなりました。

2件目と3件目も、根っこの原因は同じでした。作った本人が異動したあと、引き継ぎの手順は一応あったものの、「困ったときに誰に聞けばよいか」という連絡先までは残していませんでした。ちょっとした不具合が起きるたびに現場の判断で手作業に戻し、いつのまにか仕組み自体が使われなくなっていました。

この3件の経験から学んだのは、「作る力」と「止めない工夫」は、まったく別の技術だということです。作ることには夢中になれても、自分がいなくなったあとのことまで考えて手を止めるのは、地味で後回しにされやすい作業です。ですが、この地味な作業を怠ったときに失われるのは、それまでにかけた時間そのものです。いまの私が新しい仕組みを作るとき、真っ先に確認するのは「これは、私がいなくなっても止まらないか」という問いです。

まとめ

このレッスンでは、以下のことを学びました。

  • ノーコードが向かない領域は、最初からではなく、仕組みが育つ過程で少しずつ現れることが多い
  • 属人化は、作る手軽さゆえに設計の理由が言葉として残らないことから起こる
  • 属人化を防ぐ最低限のルールは、作った理由を残す・引き継ぎの手順を作る・定期的に棚卸しをするの3つである
  • 権限は最小権限の発想で設計し、把握されないまま仕組みが広がる状態（シャドーIT）を防ぐ
  • 複数のサインが重なったら、トリガー・アクション・条件分岐・データモデルの言葉で技術者に判断を渡す

次のレッスンでは、最初の1件をどう選び、どう周囲を巻き込みながら仕組みを広げていくかという、導入の進め方を扱います。生成AIがノーコードにもたらした変化にも触れ、本コースのまとめに入ります。

確認クイズ

このレッスンの理解度をチェックしましょう。