チームとスカウティングを共有する：読み取り専用対戦相手データベースのコーチガイド

ジュニアフェンシングでよくあるパターン：同じクラブの3人のチームメイトが同じ地域大会に出場し、ほぼ同じ相手を見て、メモを共有しない。

悪意からではない。共有可能な形で書き留められていないメモを共有する摩擦があるからだ。フェンサーAが32回戦で対戦したフリックを持つ左利きのフルーレ選手？フェンサーBも彼女についてのメモを持っておらず、フェンサーAがBに印象を伝える簡単な方法がなく——Bが次のイベントで彼女と対戦する前に実際に引き出せる形で。

この記事は、誰もが他の人のメモを編集しなくてもよい——そのワークフローについてのものだ。

編集可能な共有データベースの問題点

「スカウティングを共有する」問題に直面したとき、最初の本能はチームの全員が編集できる共有データベースを構築することだ。

これは3つの形で壊れる。

所有権の曖昧さ。 誰のメモが誰のものか？全員が同じ対戦相手レコードを編集すれば、矛盾する印象が互いに上書きする。フェンサーAが「速いカウンターアタック」と書いた。フェンサーBが「遅いカウンターアタック」と上書きする。その不一致には有用な情報が含まれている；マージはそれを破壊する。

信頼の低下。 信頼している人が書いたメモは、まだ判断を測っている人が書いたメモとは違う。共有編集モデルはメモの出所を消す。*「手を渡すな」*がヘッドコーチから来たのか新しいクラブメンバーから来たのかがわからなくなる。

編集疲れ。 共有データベースは調整を必要とする。調整は会議やルールを必要とする。ほとんどのクラブはどちらも持っていない。

読み取り専用モデル

よりクリーンなアプローチは読み取り専用共有だ。

各フェンサーは自分のスカウトデータベースを所有する。自分のデータベースは自分が思うことの情報源だ。チームメイトと共有したいとき、データベース全体を読み取り専用ビューとして共有する。チームメイトはその中のすべての対戦相手、すべてのメモ、すべての評価を見ることができる——しかし何も編集できない。

チームメイトはその後、特定の対戦相手を自分のデータベースにコピーするという選択肢を持ち、そこで編集・追加できる新しいレコードになる。コピーはスナップショットであり、同期ではない；元のデータは独立して変化し続ける。

これは3つの問題すべてを解決する。所有権は明確なまま（あなたは自分のデータベースを所有し、私は自分のを所有し、どちらも相手のを変更できない）。信頼は保たれる（共有するとき、あなたのメモがあなたのものだとわかり、それに応じて重みをつける）。編集疲れは消える（調整がない——あなたはノートをつけ、私はノートをつけ、時々互いのを読む）。

またクラブの社会的現実も捉えている：コーチや一部のフェンサーのスカウティングは他よりも正確で、健全なチームはそれをごまかすよりも理解する。

Piste IQ がこれをどう実装しているか

読み取り専用モデルは Piste IQ のデフォルト共有モードだ。2種類の共有タイプがある。

データベースレベルの共有。 スカウトデータベース全体をチームメイトに送る。チームメイトはその中のすべてを継続的に見ることができる——後で追加した対戦相手も含めて。編集はできない；コピーはできる。

プロフィールレベルの共有。 単一の対戦相手プロフィールをチームメイトに1回限りのコピーとして送る。受取人はそれを自分のデータベースに受け入れ、そこで独立して存在する。元のプロフィールへの更新は流れない。

データベースレベルの共有は継続的なチーム調整に適したパターンだ（「全員がヘッドコーチと共有し、コーチは全員の情報の合算を持つ」）。プロフィールレベルの共有は1回限りのスカウティングの引き渡しに適している（「先月私が対戦した相手とシードが当たっている、私の知っていることを共有する」）。

実際に使われるワークフロー

共有パターンは維持するのに労力が必要なときに廃れる。忙しいシーズンを乗り越えられるくらい軽量なワークフローを紹介する。

クラブで一度、クロス共有を設定する。 チームの全フェンサーがデータベースをヘッドコーチと読み取り専用で共有する。ヘッドコーチは今や全員のスカウティングの合算ビューを持ち、自動的に更新される。

トーナメント前に、コーチはオンデマンドでスカウティングを配布できる。 フェンサーBがフェンサーAがメモを持っている相手と対戦するなら、コーチはAのメモを引き出してBに価値のあることを伝える——またはAのその相手のプロフィールをBのデータベースに直接共有して後でBが読めるようにする。

トーナメント後、全員が自分のデータベースを更新する。 振り返りは個別に行われる。共有編集の競合なし。各フェンサーのデータベースは独自に成長し続ける。

シーズンに一度、整理する。 二度と対戦しない古い年齢カテゴリーの相手はアーカイブまたは削除できる。最も多く対戦したライバルが最も注目される。データベースはノイズに膨らむのではなく使いやすいままだ。

保護者との共有

特筆すべき具体的なケース：競技フェンサーの保護者はしばしばスカウティングを子供と一緒に追いたいが、試合をしているのは子供であり、一次データを持つのも子供だ。

ここでのクリーンなパターンはコーチのパターンとまったく同じだ。フェンサーがデータベースを管理し、保護者と読み取り専用で共有する。保護者はこれで子供が誰と対戦してきて何を学んだかを見ることができる——子供のメモを編集する能力なしに。ほとんどの家族コーチング関係ではそれが適切な境界線だ。

Piste IQ のコーチモードは、保護者としてのコーチとチームコーチとしてのコーチの両方を同じ構成要素でサポートするように設定されている。

読み取り専用ルールを破るべきとき

読み取り専用共有では不十分な少数のケースがある。

最も一般的なもの：戦術計画のための単一のチームスカウトブックを望むヘッドコーチ。この場合、コーチは自分でマスターデータベースを管理すべきだ——フェンサーは個別のスカウティングをコーチに共有でき、コーチはマスターを管理する。

Piste IQ の現在のモデルではこれは次のように実装されている：全フェンサーがコーチに共有し、コーチは自分のデータベースをマスターとして使い、フェンサーの共有ビューから情報を引き出すときに、関連するプロフィールをメモに帰属付きでマスターにコピーする。それは共同ドキュメントではなく一方通行のパイプラインであり、それが実際に戦術コーチングにとって正しい構造だ。

より深いポイント

スカウティングは情報だ。情報には所有者がいる。最もクリーンなチームスカウティングモデルは、チーム全体での共有を容易にしながら誰が何を言ったかを保持する。

読み取り専用共有——自分のデータベースにコピーするオプション付きで——が実際にそれがどう見えるかだ。機能しうる唯一のモデルではないが、競技シーズンの現実を乗り越えるモデルだ。