ラトゥール|『担当者が悪い』の外へ出る
仕事でトラブルが起きると、最初に人へ原因を求めやすくなります。「確認が甘かった」「返信が遅かった」「説明が足りなかった」。もちろん、本当に個人の判断や技能が原因のこともあります。でも、人だけを直して同じ問題が何度も戻ってくるなら、視野を少し広げる必要があります。
たとえば問い合わせへの返信が遅い場面を考えます。担当者は十分注意しているのに、通知が一つの受信箱へ集約されていない。担当変更が画面へ反映されない。返信テンプレートを探すのに時間がかかる。承認が必要なのに、誰へ回すか表示されない。こうした条件が重なると、「もっと気をつける」だけでは改善しにくくなります。
ラトゥール/ANTのレンズは、ここで責任を曖昧にするために使うのではありません。むしろ、責任を実行できる状態を何が支え、何が妨げているかを追います。ラトゥールの仕事では、社会的な結果を既成の大きな構造だけで説明するのではなく、具体的なつながりをたどることが重視されます。Bruno Latour Archive|Reassembling the Social
BASでは「人の問題か、仕組みの問題か」の二択にも持ち込みません。同じ人でも道具が変われば行動が変わり、同じ道具でも運用が変われば結果が変わるからです。最近再発した小さなミスがあれば、担当者の横に画面・文書・通知・権限・場所を五つまで置いてみる。その中に毎回同じ切れ目があれば、そこが改善候補です。
ラトゥール|道具は人の意図をそのまま運ぶだけではない
道具は、人が決めたことを忠実に運ぶだけの箱でしょうか。たとえば「安全のためにドアを閉めておいて」と張り紙をする場合と、自動で閉まるドアクローザーを付ける場合では、人に求める行為が変わります。ラトゥールは技術を論じる時、こうした非人間の要素へ仕事の一部が委ねられることを扱いました。本人のアーカイブに残る「Where Are the Missing Masses?」でも、ドアやヒンジのような技術物が、人が毎回行うはずだった仕事を代わりに担う例が示されています。Bruno Latour Archive|Where Are the Missing Masses?
仕事の画面でも同じことが起きます。必須入力欄は「忘れないでください」とお願いする代わりに、未入力では先へ進めない構造を作る。プルダウンは自由記述を減らし、選べる答えを限定する。テンプレートは、書く順番をあらかじめ提案する。道具は人の意図を運ぶだけでなく、意図を別の行為へ翻訳する媒介になります。
だから「使いにくい人が悪い」「設計した人が全部決めている」というどちらか一方でもありません。実際の行為は、人の目的、画面の選択肢、ルール、時間、周囲の人との関係の中で作られます。道具の効果は、置かれた状況によって変わります。
自社のフォームや管理画面を一つ見て、「この画面は利用者へ何を頼んでいるか」ではなく、何をできるようにし、何をできなくしているかと見ると、普段と違う設計レビューになります。そこに意図しない制約があれば、説明文を足す前に、道具が行為をどう変換しているかを直す余地があります。
ラトゥール|文書・画面・規則が行為の順番を変える
「次に何をするか」は、人が頭の中だけで決めているとは限りません。承認フォームに赤い必須マークがあれば、そこを埋める。通知が来れば次の担当者が動く。テンプレートの一番上に「目的」とあれば、まず目的を書く。道具や文書は、仕事の内容だけでなく行為の順番にも入り込んでいます。
ANTの実務的な使い方では、この順番を結果から逆にたどります。たとえば「見積回答が2日遅れた」という結果があったとします。担当者、顧客、見積表、価格表、承認者、メール、チャット通知、フォルダ権限を並べる。そのうえで「どこで情報が別の形式へ変わったか」「どこで次の人へ渡らなかったか」を見ます。問題が人の記憶に頼っていたのか、文書の場所が分からなかったのか、承認順が長すぎたのかで改善策は変わります。
ここで重要なのは、道具に固定的な力があると考えないことです。同じ通知でも、通知が多すぎれば見逃されます。同じテンプレートでも、新人には助けになり、熟練者には余計な制約になるかもしれません。アクターの作用は単体ではなく、関係の配置で変わります。
小さく観察するなら、最近の業務を一つ選び、矢印で五つ程度つなぎます。人 → 画面 → 文書 → 次の人 → 顧客くらいで十分です。その矢印のどこかで、待ち時間、再入力、誤解、確認漏れが起きていないかを見る。問題が見つかったらネットワークを広げ続けず、まず一つ直して結果を見る。それがBASでANTを使う時の停止条件です。
ラトゥール|Office文書も仕事を作るアクターとして追う
Office文書を使った仕事を、「人がWordやExcelを使っている」とだけ説明すると、見えない参加者がたくさん残ります。たとえば月次報告なら、担当者、Excelのセル、入力規則、共有フォルダ、前月テンプレート、承認者、グラフ、メール通知、アクセス権が関わっています。どれか一つが変われば、同じ人でも仕事の結果が変わるかもしれません。
BASでANTをOfficeへ応用する時は、まず完成物ではなく流れを見ます。誰が数字を集める。どこへ入力する。数式がどう集計する。誰が確認する。どの形式で説明資料へ移す。どこでファイル名が変わる。どこで通知される。この間にあるセルやテンプレートを「背景」として消さず、結果を変えるアクターとして並べます。
前の記事で触れたMicrosoftの強さも、このレンズを使うと少し違って見えます。WordやExcel単体の機能だけでなく、ファイル形式、クラウド保存、共同編集、権限、組織内の慣習がつながって初めて「仕事が続く基盤」になります。ただし、これはラトゥール本人がMicrosoftやOfficeを評価したという意味ではありません。ANTを現代の仕事へ当てたBASの応用です。
自社で「なぜこの作業だけ毎回遅れるのだろう」と思うものがあれば、担当者へ質問する前に、使っている道具を三つだけ書き出してみます。テンプレート・通知・権限のどれかでも構いません。人を責める前にネットワークを見ることで、人が本来やるべき判断と、仕組みに任せた方がよい反復作業を分けやすくなります。書き出した三つの優先順位が決めにくければ、その材料をBASの3人へ持ち込み、どの接続から直すかを一緒に整理できます。




