アウトカムBlog | アシストAIテラス

ルールが形だけになる組織に足りないもの

作成者: Yuki Nakao|2026/08/16 23:00:00

「ルールは作った」の後に訪れる静かな迂回

 

推進担当の画面には、整備されたワークスペースのページが開いています。

 

フォルダ構成も、運用ルールをまとめたドキュメントも崩れていません。アクセス権も全員に付与済みです。

でも、同じフロアの少し離れた席に座っている営業担当者の画面を横から見ると、ブラウザの端でチャットのDMが開いています。

 

「これ、前回の案件でどうやって処理しましたっけ?」と打っている。

 

共有ドキュメントに載っていないのか聞くと、担当者はマウスをカチカチ動かしながら答えます。

 

「探せばあるのかもしれませんけど、どこにあるかわからないんですよね。検索しても2年前のファイルが引っかかるし。チャットで〇〇さんに聞いたほうが1分で終わるので」

 

管理画面の数字やドキュメントのページ数と、現場の手元で起きている動作は噛み合っていません。ルールはあっても、実際の作業はそこを踏まずに流れていきます。

 

15分かかるフォームと、1分のチャット

 

使われないルールがあると、「現場の意識が足りない」「周知が甘い」と片付けられがちです。

 

ですが、現場の人間は怠けてルールを無視しているわけではなく、今日のタスクを終わらせるために、一番処理時間が短い方法を選んでいます。

 

たとえば、問い合わせ対応のナレッジを共有データベースに残す運用があります。次に似た質問が来たときに誰でも回答できるようにする。目的自体には誰も反対しません。

 

ただ、登録画面を開くと入力欄が8個並んでいる。

「発生日」「適用範囲」「関連プロダクト」「想定リスク」「影響度(高・中・低)」……。どこまで細かく書けばいいのか判断できず、真面目に入力すると15分かかります。

 

一方で、隣の席の有識者に聞けば1分で返ってくる。もらった回答を自分のPCのメモ帳に貼り付けておけば、次回からは検索すら不要です。

 

15分のフォーム入力と、1分のチャット。作業の処理時間を天秤にかけた結果として、フォームが選ばれていない。ただそれだけのことです。

 

例外が出たときに、管理側がどう動いたか

 

ルールを作るとき、最初は誰でもきれいに組み上げようとします。

業務の切り出し、必須項目の指定、承認ボタンの配置、週1回の確認会。ここまでは順調に進みます。

問題は、実際の案件が動いてからです。

 

運用の初日に、想定していなかった例外が飛んできます。

 

「この案件、選択肢の3つのどれにも当てはまらない」「相手先から至急で回答を求められていて、承認を待っていたら打ち合わせに間に合わない」

 

このときに問われるのは、現場がルール通りに動けるかだけではなく、ルールを作った側が、その例外を受けて運用を直せるかです。 

 

その場で出た引っかかりを拾って、「影響度」の選択項目を削除する。承認待ちで止まるなら、チャットのスタンプ1つで事後共有に変える。現場が迷った理由を聞いて、翌週の手順書を修正する。こういう修正が動けば、ルールは少しずつ現場の作業に組み込まれていきます。

 

逆に、「決まった手順通りに入力してください」と押し返すと、現場は表面上だけ「わかりました」と言って、裏で自分用のExcelを作り始めます。会議では「順調です」と報告されながら、本番システムの更新は止まるのです。

 

制度を定着させるうえで足りないのは、ルールを守らせる力ではなく、現場の迂回を見て、ルールを直し続ける力です。

 

「数字を埋める作業」に変わる瞬間

 

制度が機能していない現場でも、集計シートの数字はきれいに揃うものです。

 

今月の登録数、45件。研修の履修率、90%。定例会の出席率、100%。

 

集計資料は完成していますが、「この数字を見て、先週から何を変えましたか?」と聞くと、答えが出てきません。

集計すること自体が目的になると、現場は数字を埋めるための入力作業を始めます。

 

ナレッジ共有の画面に「本日〇〇社訪問。次回提案予定」といった、後から誰も読み返さない1行が投げ込まれる。入力している本人も、そのデータが誰の判断にも使われていないことをわかっています。

提出期限の直前に最低限の文字だけが打ち込まれ、会議が終われば誰の画面にも表示されなくなる。

 

数字は増えていても、業務の進め方は1年前と変わっていません。

 

AITが支援で注目するのは「ルール」ではなく「修正の履歴」

 

アシストAIテラス(AIT)の支援現場でも、同じような状況に直面します。

 

AI活用のルールを作成し、プロンプトの置き場所を用意し、週1回の共有会を設定する。ここまでは形にしやすいですが、配置しただけでは現場の動きは変わりません。

私たちが支援で注目するのは、ルールがどれだけ厳格に守られているかではなく、現場の動作です。

入力フォームのどの項目で、担当者の手が止まっているのか。

 

個人がローカルで使っているメモ用スプレッドシートのほうが扱いやすいなら、そのフォーマットを公式シートに移植できないか。

チャットのやり取りで済ませている確認があるなら、なぜフォームではなくチャットが選ばれているのか。

残るルールは、最初から完成していたものではありません。

 

使ってみて、現場が詰まった場所を削る。使いにくい必須項目は消す。現場で勝手に作られた裏ルートの中で、筋が良いものは正式な手順に取り込む。

 

案件の性質が変わり、顧客からの要求スピードも変わっているのに、手順書だけが半年前の形式で残っていれば、使われなくなるのは自然なことです。

 

制度が定着するかどうかは、最初の設計図では決まらないものです。

現場の動きとズレが出たとき、その理由を見て、ルール側を何回書き換えられたか。

 

確認するポイントはルールそのものではなく、運用のなかで重ねられた修正の履歴です。