部門をまたぐプロジェクトでどう協力するか：情報の壁と責任の押し付け合いを減らす
部門をまたぐ協力が具体的になるのは、あるチームの成果が別のチームの入力になる場面です。会議を増やす前に、何を渡し、誰が準備し、誰が確認し、どの状態なら使えるかを決めましょう。提供側の作業が終わったことと、受け取る側が着手できることは同じではありません。 まず重要な引き継ぎを一つ選びます。全部門の働き方を変える必要はなく、双方が同じ成果物と条件を理解し、どちらも引き受けていない仕事を見つけられることが大切です。
受け取る側の次の作業から考える
例として、紙の見学ガイドを作るとします。編集担当が文章を用意し、デザイン担当が組版し、運営担当が印刷を手配します。これは仮の例です。「火曜日に原稿を渡す」だけでは、確認済み原稿なのか、未解決のコメントが残る下書きなのか分かりません。
受け取る担当に、着手前に必要なものを聞きます。本文、写真説明、ページ順が必要なら、提供側が約束した時点までに準備できるか確認します。ファイルの場所と使う版を既存のタスクに記します。受け手の要求を並べるだけでなく、双方が実行できる約束にします。
成果物どうしの依存関係を示す
組版は確認済みの文章に、印刷はチェック済みの印刷用ファイルに依存します。それぞれ両側の連絡担当を明記し、変更の影響も確認します。遅れて追加された一段落は、メールを送るだけでなく、版面の再確認を必要とするかもしれません。
Atlassian の Dependency Mapping は、上流と下流への影響、担当、リスク、見直しの方法を整理します。ある部署の締切に別の部署の作業時間が自動的に含まれるわけではありません。調整役だけで決めず、影響を受ける担当に依存関係を確認してもらいます。
役割の間に残る作業を引き受ける
最終的な写真と説明が一致するかを誰が確認するのか、不明なことがあります。「編集とデザインが共同で担当」と書くだけでは空白が残ります。実際に確認する人、情報を補う人、結果を使えると判断する人を具体的にします。担当名は本人が受け入れた責任を表す必要があります。
Atlassian の Roles and Responsibilities は、重なる責任には主担当を定め、引き受け手のない仕事には担当者を探す人と確認日を設けるよう勧めています。小さな作業のたびに新しい役職を作るのではなく、既存の責任に含められるかを先に考えます。無理なら人員や権限の不足を明記します。
受け取り条件を確認できる形にする
必要な条件に絞って、本文がそろっている、写真説明が確認済み、未決事項が別に示されている、といった状態を約束します。受け手は何があり何が欠けているかを説明できます。共有フォルダーを開いたことやお礼の返信を、不完全な成果物の受け入れと扱わないようにします。
Scrum Guide の完成の定義は、Scrum で完成状態を共通理解するためのものです。普通の部門横断プロジェクトで仕組み全体を採用する必要はありません。結果を頼りにする人が完成を理解できるという考え方を参考にします。時間がないから下書きを完成版と呼んだり、受領後に条件を黙って増やしたりしないことも大切です。
変更の影響を役割ごとに確認する
組版後に本文が変わったら、影響するページと再確認が必要な箇所を示します。編集は本文の修正、デザインは組版の調整、調整役は印刷予定への影響を確認します。全員に通知した人が、この三つの仕事をすべて引き受けるわけではありません。
最初の引き継ぎ後、受け手が使える材料を得たか、担当のない作業が残ったか、修正による依存関係を見落としたかを確かめます。まずその約束を改善し、必要なら広げます。各部署の役立つ道具は残し、接続部分を明確にすることで次の作業につなげます。