コラボレーターのオンボーディング：完全ガイド

オンボーディングドキュメントが重要な理由

多くの人は、同じ方法で共同作業者をオンボーディングしています。通話でワークスペースを案内し、質問があればその都度答え、残りはなんとかなるだろうと考えます。その結果、多くの質問によって自分の作業が中断され、誰もルールを確信していないために不整合が忍び込み、新しい共同作業者はどこに何があるべきか、その理由が分からず不安を感じることになります。

少量のドキュメントを用意するだけで、この問題のほとんどは解決します。マニュアルのようなものではなく、新しく入った人がそれを読み、ワークスペースの目的を理解し、どこに何があるか、不明な点があれば誰に聞けばよいかが分かる程度のもので十分です。これが整えば、オンボーディングはほぼセルフサービスになり、あなたにとっても新しく加わる人にとっても、より良い環境になります。

このガイドは、すでに構造化されたワークスペースがあることを前提としています。まだセットアップしていない場合は、まず共同ワークスペースガイドをご覧ください。

ステップ1：目的と構造をドキュメント化する

新しい共同作業者が最初に理解する必要があるのは、ワークスペースの目的と主要なエリアが何であるかです。これは当たり前のことのように思えますが、書き留めている人はほとんどいません。そのため、新しい人は皆、構造から推測するか、誰かに尋ねる必要があります。

オンボーディングとサポートドキュメントのための専用セクションを、目につきやすく、はっきりとラベルが貼られた場所に作成します。ワークスペース全体に散らばらせるのではなく、すべてを1つの場所にまとめてください。右も左も分からない状態でドキュメントを探させるのは、最悪の第一印象を与える最も手っ取り早い方法です。

このセクションの中に、まずは「このワークスペースについて」というノートから始めましょう。ワークスペースの目的、どのようなものがそこに含まれ、どのようなものが含まれないのかを説明する短い段落です。他のものを見る前に、2分未満で読めて、その目的を明確にイメージできるものである必要があります。

その下に、各主要エリアについて、何が含まれているか、何に使われているか、誰が担当しているかを説明します。エリアごとに数文で十分です。目標は、共同作業者が何かに触れる前に、これを読んでワークスペースの全体像を即座に理解できるようにすることです。

ステップ2：主要なプロセスを説明する

構造は「何が存在するか」を表します。プロセスは「何が起こるか」を表します。構造は理解していてもプロセスを理解していない新しい共同作業者は、それらに直面したときにどう扱えばよいか、やはり戸惑うことになります。

すべての例外的なケースをドキュメント化する必要はありません。メインのフローに集中してください。新しいリクエストはどのようにシステムに入ってくるのか？ 作業はどのようにして次の段階に移行するのか？ エリア間の引き継ぎは誰が担当するのか？ 主な作業タイプにおける「完了」とはどのような状態を指すのか？

各プロセスを、明確な一連の手順として記述します。かんばんスタイルのワークフローを使用している場合は、何がアイテムをカラム間で移動させるのか、そして誰がそれを移動させるのかを記述します。インボックスから完了までのフローを使用している場合は、アイテムがどのように進行し、各段階で誰が責任を持つかを記述します。

最も明確にすべき重要な点は、誰が引き継ぎを担当するかです。作業が1人の担当者やエリアから別の場所に移動するとき、誰が移動させるのかが曖昧だと、物事がうやむやになってしまいます。「デザインが完了したら、デザイナーはアイテムを『レビュー』に移動します。クライアントがそれを『修正』または『完了』に移動する責任を負います」のように明確に記載してください。

プッシュ型ワークフローとプル型ワークフローを採用しているチームでは、どちらのシステムを使用しているかをドキュメント化することで、「誰か他の人が移動してくれるだろう」というデフォルトの思い込みが蔓延するのを防ぐことができます。

ステップ3：質問とフィードバックの場所を作る

優れたドキュメントがあっても、新しい共同作業者は質問を抱き、ギャップに気づき、時には仕組みの改善を提案したいと思うことがあります。適切なチャンネルを自分たちで探させるのではなく、そのための構造化された場所を提供しましょう。

サポートドキュメント内の「ディスカッション」セクションが効果的です。いくつかのサブセクションに分けることで、整理された状態を保てます。

質問。 ワークスペースの仕組みや、特定の状況での対応について、不明な点がある場合に使用します。

提案。 構造やプロセスの改善に関するアイデア。ワークスペースを毎日使っているメンバーは、あなたには見えないことに気づくため、非常に重要です。彼らの提案をキャプチャしておくことで、一度言及されて忘れられるのではなく、実際に改善を実装できるようになります。

問題。 既存のドキュメントの不具合、不整合、不鮮明な点を指摘する場合に使用します。

このセクションは、もう1つの有用な副次的効果ももたらします。それは、オンボーディング中にどこでつまずいたかの記録になるため、次の人のためにドキュメントのどこを改善すればよいかが分かるということです。

ステップ4：推敲して順序を整える

ドキュメントを新しい共同作業者と共有する前に、論理的な順序で読めるようになっているか確認してください。セクションに番号を振るか、明確にラベルを貼り、最初に何を読むべきかを分かりやすくします。「ここからスタート → このワークスペースについて → 各エリアの仕組み → 主要なプロセス → 質問をする場所」というシンプルな流れが、ほとんどのセットアップでうまく機能します。

自分が新メンバーになったつもりで読み返してみてください。目的のセクションは、実際にワークスペースについて明確に説明していますか？それとも、あなたがすでに持っている知識を前提としていませんか？プロセスの説明は、それに従って進められるほど具体的ですか？それとも、解釈が必要なほど曖昧ですか？これを読んだ後、すぐに自分の作業を開始できそうですか？それとも、まだいくつかの質問をする必要がありますか？

Fabricで作業している場合は、新しい共同作業者がワークスペースに追加される前にアクセスできるURLとしてオンボーディングドキュメントを公開できます。これにより、他のものを見る前に構造やプロセスを読み通すことができるため、実際のアクセス時に圧倒されることが少なくなります。

簡単なオンボーディング通話でカバーすべきこと

非同期の優れたドキュメントがあっても、短い通話やウォークスルーを行うことは大きな価値をもたらします。長くする必要はありません。通常、15分もあれば以下のことができます。

ドキュメントをどこで見つけられるか分かるように、一緒に見て回ります。明示的に案内されない限り、ほとんどの人はドキュメントを読みません。

一般的なアイテムがワークフローをどのように移動するのか、実際の例を1つか2つ見せます。一度実際の動きを見ることは、説明を3回読む以上の価値があります。

質問ができる場所を知っていること、また、質問することは想定内であり、歓迎されることであることを確認します。新しい共同作業者は、質問するのをためらって静かにしていることが多く、その結果、問題が表面化するまでに時間がかかってしまいます。

彼らの質問に答える時間を残しておきます。ワークスペースを初めて見た直後に生じる質問は、ドキュメントに何が欠けているかを知るための最も有用なシグナルであることがよくあります。

共有とアクセス権限

ワークスペースに誰かを追加する準備ができたら、その人が実際に何にアクセスする必要があるかを慎重に考えてください。Fabricでは、特定のフォルダやスペースを、その人の役割に応じた適切な権限レベルで共有できます。表示するだけで編集する必要のない資料には「閲覧者」、積極的に貢献するエリアには「編集者」を設定します。

デフォルトですべての人にすべてへのアクセス権を与えないようにしてください。認知的な過負荷を招き（必要以上のナビゲーションが必要になる）、機密資料がそれを見る必要のない人にまで見えてしまうことになります。必要なものを正確に共有することは、アクセス管理が考慮されていることを示し、制限的というよりも安心感を与える傾向があります。

ワークスペースへの完全なアクセスを必要としない外部の共同作業者（クライアント、請負業者、たまに参加する協力者）に対しては、公開ページを使用することで、アカウント作成やログインを要求することなく、特定の資料をURLで共有できます。これは、チームのメンバーではないものの、プロジェクトに参加している人々と、成果物、リソースライブラリ、参照資料などを共有するのに便利です。

チームの成長に合わせて

3人のときにうまく機能していたオンボーディングドキュメントも、10人になったときには更新が必要になる場合があります。何度も繰り返される質問に注意を払ってください。複数の人が同じことを尋ねる場合、それはドキュメントにギャップがあることを意味します。

数ヶ月ごとにチームでドキュメントを見直してください。すべてが依然として正確ですか？変更されたにもかかわらず、ドキュメントで更新されていないプロセスはありますか？サポートセクションは質問のために使われており、それらの質問は解決されてドキュメントにフィードバックされていますか？

最も優れた共同ワークスペースのドキュメントは、書かれた日に正しいと思われたものを固定しておくのではなく、実際の使用に基づいて時間の経過とともに少しずつ改善されていきます。

繰り返し発生する作業タイプ（新しいクライアントのオンボーディング、週次レビュー、プロジェクトのキックオフなど）のテンプレートを用意しておくと、作業の構造がテンプレートに組み込まれているため、ルールを覚えておく必要がなくなり、頭に留めておくべきプロセス知識の量を減らすことができます。

よくある質問

ドキュメントはどのくらいの量があれば十分ですか？

基本的な質問をすることなく作業を開始できる程度に十分で、読むのに1時間もかからない程度に収めるのが適切です。ほとんどのワークスペースで必要なのは、目的の記述（1段落）、エリアの説明（それぞれ数文）、2〜3の主要なプロセスフロー、そして質問用の場所です。数ページ以上書いている場合は、実際に誰かが質問するまで待てるような例外的なケースまでドキュメント化してしまっている可能性があります。

ワークスペースが頻繁に変更される場合はどうすればよいですか？

ドキュメントを検索しやすい1つの場所に保管し、変更があったときに更新します。プロセスが急速に進化している場合は、読んだ内容と実際の状況が一致しなくても混乱しないよう、その旨をドキュメントに記載しておきます。「このワークスペースは現在活発に改善されています。不整合と思われる点がある場合は、ディスカッションセクションでお知らせいただくのが最適です」といったメモを残しておくことで、適切な期待値を持たせることができます。オンボーディングは非同期で行うべきですか、それとも通話で行うべきですか？

ほとんどの場合、その両方です。非同期のドキュメントがあれば、彼らはあなたのスケジュールに左右されず、後で参照するものを持つことができます。短い通話を行えば、主要なポイントが実際に吸収され、質問する機会を得ることができます。ドキュメントがメインであり、通話はそれを補強するものです。

共同作業者がドキュメントを読まない場合はどうすればよいですか？

アクセス権を共有する際に明示的にドキュメントを案内し、質問が出た際にはそれを参照するように促します（「それは『仕組み』のセクションでカバーされています」など）。ほとんどの人は、存在を明示的に知らされていないドキュメントを読みません。最初に目にするものとして、明確にラベルを貼り、10分で読み終えられる長さにしておくことで、読読率は大幅に向上します。

合意されたプロセスを無視する共同作業者にはどう対処すればよいですか？

通常、それはプロセスが十分に明確でなかったか、ドキュメントが読まれていなかったか、あるいはそのプロセスが実際の業務の進め方に合っていないことを意味します。その人に非があると決めつける前に、ドキュメントにプロセスが明確に記載されているか、またプロセス自体が機能しているかを確認してください。ここではディスカッションセクションが役立ちます。プロセスが一貫して無視されている場合、単にルールに従わせようとするのではなく、変更が必要な可能性のあるテーマとしてレビューの俎上に載せる価値があります。

関連ガイド：共同ワークスペースのセットアップ、クライアントとの協業、テンプレートライブラリの構築、ミーティングノート。