デザインの最終稿を、外注デザイナーに渡す。ファイル形式は正しい。解像度も指定通り。届いたファイルを開けば、何も問題はない。
問題は、そのファイルが「なぜこの形になったか」を運んでこないことだ。
社内では、ファイルは一人では届かない
社内で誰かに「あのファイル使って」と言うとき、実際にはファイル以上のものが渡っている。
先週の打ち合わせで方向が変わったこと。前のバージョンでクライアントから出た指摘。なぜ角を丸くしないことになったか。これらは、ファイルそのものには書かれていない。ファイルを受け取る人が、その場に居合わせたか、廊下で誰かから聞いたか、チャットのログを覚えているかで、自然と一緒に届いている。
ファイルは、周りの記憶に支えられて意味を持っている。ファイル単体で完結しているわけではない。
境界を越えると、記憶ごと切り離される
外部の人にファイルを渡すとき、この「周りの記憶」は一緒に渡らない。
外注デザイナーは、先週の打ち合わせにいない。前のバージョンへの指摘も知らない。角を丸くしなかった理由も知らない。届くのは、ファイルという結果だけだ。
結果だけを受け取った人は、そこに至った判断を再現できない。次の修正で、既に却下された案をもう一度提案してしまう。一度決まったはずの仕様を、知らずに変えてしまう。これは能力の問題ではない。渡された情報が、そもそも足りていない。
「共有した」は、「伝わった」の意味ではない
ファイルを送ると、送った側は「共有した」という感覚になる。データは確かに相手のところにある。
しかし、共有とは本来、意味も一緒に渡ることのはずだ。ファイルだけが届いて、それに至った経緯が届いていないなら、それは共有の半分でしかない。
この半分だけの共有が問題になるのは、修正が発生したときだ。「ここ、前も同じ指摘をしませんでしたか」「いえ、初めて伺いました」。この噛み合わなさは、相手の記憶力のせいではなく、渡した情報が最初から半分だったせいで起きている。
ファイルを、経緯が張り付いた状態で渡す
対応の方向は、ファイルを単体で渡さないことだ。
ファイルを、それが生まれたやり取りの中に置いたまま渡す。「このファイルは、このタスクの、この会話から生まれた」という経緯が、ファイルにくっついている状態を作る。ファイルだけを別のフォルダやチャットの添付として切り離さない。
外部の人がそのファイルを開いたとき、隣に「なぜこうなったか」が見える。前のバージョンへの指摘も、角を丸くしなかった理由も、遡って確認できる。ファイルを受け取った瞬間に、社内の人が自然に持っている記憶と同じものが、記録として手に入る。
記憶に頼るのをやめる
社内での「あのファイル」が機能するのは、記憶という不安定な土台の上でだ。担当者が異動すれば、その記憶は組織から消える。外部の人に頼るときは、この不安定さがそのまま表面化する。
越境チームで働くとは、記憶に頼れない前提で仕事の受け渡しを設計するということだ。ファイルを渡す瞬間に、経緯も一緒に渡っているか。それを確認する習慣が、越境した仕事の手戻りを減らす。
Paqutでは、ファイルは会話の外に置かれません。タスクに添付されたファイルは、そのタスクのやり取りと一緒に残り続けます。外部の人がファイルを開けば、そこに至った経緯もそのまま見られます。
関連記事
「参加は簡単」について:「参加は簡単です」と言うとき、簡単なのは誰にとってか
「念のため」の連絡について:「念のため」のCCが、外部の協力者との仕事を渋滞させている
創業のきっかけ:タスク機能はあった。それでも、仕事は流れて消えた。
評価とフィードバックについて:外部の人に届く評価は、「また頼むか」の一言しかない
不在と疑いについて:何かが失敗したとき、その場にいない人から疑われる
全体像が渡されない問題について:外部の人は、完成形を知らないまま「部品」を作らされることがある