#1703: Take Control 著者が死去、Google の Find My Device がプライバシー水準を向上、Helper Helper によるボランティア管理、ホテルで AirPlay、Apple が中古部品の使用を許容、海底ケーブルの維持管理

これは私にはとても生々しすぎる。今朝、MacAdmins Slack 上の Rich Trouton のDer Flounder ブログ、そして Tom Bridge のサイトで、我々の友人で Take Control の著者でもある Charles Edge が 19 April 2024 に突然亡くなったというニュースが広まり始めた。彼は 40 代後半で、そして、はい、下記の彼の典型的なバイオ写真からは彼のユーモアと太々しさの感触が感じられるであろう。

私が Charles に会ったのは 2012 年に New York で開催された MacTech イベントで あったが、彼がシステム管理の話題に関する何冊もの技術書と何千というKrypted ブログ記事を書いたことはすでに知っていた。私たちは、彼が Take Control の本を書く可能性について何回かの電子メールを交換したが、Take Control of OS X Server の考えに辿り着いたのは 2014 年初頭になってからであった。

Charles の頭の中の情報量は驚くべきもので、私が彼の下書きを読んでいた時、彼は調べなど必要とせず、頭の中から全体をただ放り出しているという印象を受けた。私はそれが必ずしも正しくはないとは思っているが、Charles は一緒に仕事をしていて楽しい人間で、質問には非常に敏感で、良い編集には何時も感謝していた。彼のコンテンツを一時も早く共有するため、出版の実験の一つとして、TidBITS 会員のために彼の本全体を章毎にストリーミングした (""Take Control of OS X Server" を TidBITS でストリーミング" 12 May 2014 参照)。彼を追悼して、私はこれらの章を誰もが利用できるようにした。

Charles は Winnie-the-Pooh (クマのプーさん) の意味で正真正銘の Tiggerであり、プロジェクトからプロジェクトへと精力的に飛び回っていた。Take Control of OS X Server の執筆の終わりに向けて、彼は全国展開の Apple コンサルト会社 318 の Chief Technology Officer から、Jamf Software での Jamf Nowの開発を管理へと転職し、そこに数年間いた後、より研究開発的な役割へと移った。

彼は 2020 年に Jamf を去り、最近では、Apple の Keychain に量子攻撃耐性機能を追加することを目的としたパスワードマネージャーである Secret Chestに取り組んでいた。今、私は "iMessage の新しい PQ3 暗号化プロトコルがポスト量子攻撃に対する保護を提供" (23 February 2024) に書いた新しい Apple 技術について彼に尋ねることが出来たらいいのにと思っている。Secret Chest のブログには彼の投稿が満載で、彼が亡くなった日のステガノグラフィー (データハイディング技術) に関する投稿や、パスワード管理の過去と未来の優れた記事などが含まれる。Charlesはまた、ベンチャーキャピタル企業 Bootstrappers.mn の CTO、Minnesota に拠点を置くコミュニティ技術組織 Minnestar の取締役、 Mac Admins Podcast と The History of Computing Podcast の活発なポッドキャスターでもあった。

コンピューティングの歴史は、特に Charles の心に近く、大切なものであった。彼は７年間もそれに関する一冊の本に取り組んでいたが、このプロジェクトは４巻と 2000 ページ以上に膨れ上がった。一週間前の彼の最後の Facebook の投稿は、彼がどの様にその契約に署名したばかりかについてであった。私は、彼が一緒に働いていた出版者がその原稿に興味を持ち続けることを願っている。なぜならば、Charles はその編集者が完成させてそれが日の目を見ることが出来る事を願っていると私は確信しているからである。私は間違いなく Charles の思い出の品としても一冊欲しい。

最後に、私は Apple の世界の他の多くの人々ほど Charles と親しくはなかったが、彼は、いつも話す時間を取ってくれ、出来るものはどんな質問でも手伝ってくれ、そして出来ない時にはあなたを他の人に紹介することをとても楽しんだ。以下の Facebook の投稿からも分かるように、彼は親切で、魅力的で、いつも他人のことを考えていた。彼の死は、彼の多くの友人や同僚、そして Apple の世界全体にとって大きな損失である。

討論に参加

Google は、May 2024 に待望の Find My Device ネットワークサービスを開始し、プライバシー保護とストーカー防止機能のための取り組みを強化する。Apple のほぼ同じ名前の Find My ネットワークと同様に、Google の Find My Deviceネットワークは、対応する Android 携帯電話やタブレットを介して暗号化された ID信号を中継することで、デバイスの場所をクラウドソース (不特定多数の人に業務を委託) する。この検索大手の Find My Device ネットワークは Android デバイスと、Chipolo や Pebblebee などの企業の小型追跡機にも対応する。Googleには、Apple の Find My ネットワーク方式にはない - 今の所は - ３つの明確に異なるプライバシー改善がある。

紛失物追跡の背景

簡単におさらいすると、クラウドソース位置追跡は、GPS、セルラー、そして Wi-Fi位置情報からそれ等がどこにいるかを知るネットワークに接続された機器 (Android或いは iOS/iPadOS) を利用する。ネットワーク接続のないアイテムは - AirTagの様な小型追跡機、或いは一時的にオフラインの Mac、Apple Watch、Android スマートフォン等を含む - 登録された所有者で識別された暗号化されたペイロード(データ本体) を含む匿名化された Bluetooth 信号をブロードキャストする。

このネットワークに接続された機器は、信号を発している機器からの Bluetooth信号を、それは暗号化されている、データを検査することなく Apple や Googleが走らせる中央サーバーに中継する。登録された機器やアイテムの所有者のみがソフトウェアを使え - Apple 機器用の Find My と Android ギア用の Find My Device - それがこれらの中央サーバーで位置情報を照会させてくれる。一旦ペイロードが紛失したアイテムの所有者によって取得されると、それはその所有者のデバイス上でローカルに復号化される。

暗号化のため、自らの機器が位置データを中継している Apple ユーザーも Androidユーザーも、紛失したアイテムの所有者や、どのアイテムがブロードキャストしているかすらをも特定することは出来ない；同様に、追跡されている機器を所有する人は誰であっても、信号が中継された機器について知ることは全く出来ない。(アイテムは Bluetooth 識別子を、一日を通してある間隔で新しい繰り返すことのない値に更新して、誰かがその追跡器を追跡するデータベースを構築するのを防ぐ。)

それは全て良さそうに聞こえるし、このやり方は Apple の最初の３年間の AirTagと Find My ネットワークで、実際にびっくりする程うまく機能してきた。危険は小型追跡機が認知や承諾なしに人々を追跡するのに使われ得る方法にあり、窃盗やストーカー行為のために AirTag 追跡を悪用する人達がいる。

AirTag は、当初家庭内暴力被害者の擁護者やプライバシーの専門家が必要だと信じていたよりも少ない保護を提供していた。Apple は徐々に AirTag の警告とアラート音を改訂した ("Apple、AirTag プライバシー問題への対処の方法を説明" 12 February 2022 参照)。変更履歴を無視して言うと、現在のストーカー対策のフィードバックには２つのやり方がある。AirTag があなたと一緒に移動していて、所有者が近くにいない場合は、近くの iPhone や iPad 上に警告がポップアップ表示される。同じ位大事なことだが、AirTag は静止しているが、所有者が 8 から 24時間の間に無作為に選択された期間の間その近くにいなかった場合、それは顕著な音を数秒間発し、そしてその先は無作為な間隔でそれを繰り返す。

これらの警告は、AirTag のような追跡器を作る企業の参加を得て、Apple とGoogle が共同開発した業界標準の基礎を形成した。("AirTag がニュースに： NYPD の推奨と Apple と Google による追跡への業界規格提唱" 8 May 2023 参照。)Find My ネットワークと互換性のある追跡器は全て、すでに一定間隔でビープ音を鳴らす。クロスプラットフォーム機器ベースの警告は、2024 年に Android、iOS、そして iPadOS で展開されるはずである。

Google のプライバシー追加分

Google は、その Find My Device ネットワークをストーカーや他の犯罪者が自らの目的のためにクラウドソースされた位置追跡を妨害する方法を阻止する追加の選択を行うことで特色を出した。

まず、Google の Find My Device ネットワークのアルゴリズムは、近くに複数のAndroid デバイスがない限り、ブロードキャストするアイテムに関する位置情報を中継しない。その考えは、自宅や他の私的な場所にいる誰かは、位置報告を発するのに十分なだけの Android 機器を周りに持っている可能性は低いであろうということである。Google は、"我々の調査によると、Find My Device ネットワークは、近くに多くの機器がある可能性の高いカフェや空港等の公共の場で最も価値があることが分かった" と言っている。追跡データは Bluetooth 経由で送信されるため、Android (そして Apple) のハードウェアは信号強度を使って近さを判断出来る。従って、Android 携帯電話でいっぱいのアパートに居ても、Google が呼ぶ "集約しきい値" を自動的に越えることはないであろう - それ等の機器も十分に近いところにいる必要がある。(Google は - おそらく意図的に - そのしきい値に達するには何台必要かを言っていない。)

第二に、Android 機器は、あなたが家にいて Google アカウントに自宅の住所を指定している場合、検出したブロードキャストからクラウドソースされた位置データを中継しない。これは追跡に関してのプライバシー先行であり、自分のハードウェアがリレーポイントとなる状態で意図せずに位置を明らかにしないようにするが、一方では、自宅の住所を Google に渡し位置追跡を有効にする必要があることを意味する。Google は、広告を配信したり他の儲かるターゲティングを提供するために位置データを必死で望んだあまり、同社はある時点で、ユーザーが表面上は Google アプリからログアウトしていた場合でもユーザーを追跡した。その行為は、昨年 40 の州と $392 million で和解する結果となった。

Apple は Find My に別の在宅保護形態を採用している。Apple は、Contacts の Meカードに自宅の住所を定義させてくれるが、その情報を Apple 自身には送信しない。Apple はまた Significant Locations と呼ぶものを追跡する。それはあなたの旅行から推測し、機器上にのみ保存、そしてあなたの機器間で同期する時にもエンドツーエンドで暗号化する。自宅または重要な場所に未知の AirTag またはFind My アイテムを持って到着すると、以前に警告を発した場合でも、Find Myは警告を発する。しかしながら、私が知る限りそして Apple が開示した限りで言うと、Find My ネットワークのクラウドソースはあなたが自宅にいる時でも引き続き働き続ける。

第三に、Google の Find My Device ネットワークは、誤用を防ぐために２つの異なる絞り弁を採用している：Android デバイスが近くでブロードキャストされたアイテムの場所を中継する頻度と、 加えて そのアイテムの所有者がその場所を照会できる頻度である。Google によれば、殆どの紛失したアイテムは静的な場所にあると言うが、このやり方だと、盗まれたり忘れ物になったりして移動中の車両 (バス、地下鉄、電車など) にあるアイテムを追跡するのが難しくなる可能性があると思われる。しかし、そのような場合、近くの人々は不要な追跡について通知されるべきであり、潜在的にあなたのものを見つけるのに役立つであろう。それはトレードオフで、そして Google はフェンスのこちら側に立つ論理的な論証をしている；Apple は同様の制限があるかどうかを開示していないので、反対側に立っているように見える。

これら３つの要素は示唆に富んでいる。それぞれが等しい重要性や価値を持っているかどうかは私には分からないし、私のプライバシーを保護するために Googleに私の居場所に関する情報をより多く提供することは心配でもある。しかし、特に安全性が懸念される市場でのプライバシーをめぐる競争を見るのは良いことであり、私は Apple が Google の例から学ぶのを期待したい。

討論に参加

ここ数年間のうちに私は Finger Lakes Runners Club (FLRC) との関わりが深くなり、競技会の運営もするようになってきたが、私にとって最も厄介な問題の一つはボランティアの求人、調整、およびコミュニケーションの仕事だった。FLRC のイベントのいくつかはかなり大規模なもので、今月初めに私が運営を任された Skunk Cabbage Classic 10K and Half Marathon 競技会もそのようなイベントの一つだった。今年はこの競技会に 725 名のランナーが参加したので、それほど多くの人たちを一つの場所に集めるには、いやむしろ、土地の道路を 6.55 マイル (10 km) 走る前と後のそれぞれに一つの場所に集めるには、77 名ものボランティアたちの助力が必要だった。

ボランティアの力を得て運営されるイベントを誰もが担当する訳ではないが、読者の皆さんの多くもいずれはその種の経験をすることになるのだろうと思う。ほんの数人のボランティアたちしか参加しない小規模なイベントなら、頭の中で覚えていることも可能だろう。でも、十人程度を超えた人数が必要になった途端、きちんとしたコーディネーターはスプレッドシートですべてを追跡する作業を始めることだろう。なぜなら、表形式のスプレッドシートがリストの管理に適しているからだ。数年前の私もそこから出発して、公開の Google Sheets スプレッドシートを作り、誰もが自分の手で情報を適切な場所に書き込めるようにした。(私はセルフサービスシステムの信奉者だ。) それは確かに機能したが... あまり理想的とは言えなかった。スプレッドシートの中に自由な形式でデータ入力をせよと言われても、おじけづいてしまう人たちが多く、代わりに私が手作業で入力することはできたけれども、大成功というには程遠かった。また、公開されたスプレッドシートに連絡先の情報を書き込むのを嫌がる人たちも多かったので、グループ宛に電子メールを送りたい場合には私が手作業で一つ一つコピー＆ペーストしなければならなかった。

2022 年の後半になって、私はフル機能のボランティア管理システムを探す作業に乗り出した。調べてみるとそこには驚くほど多種多様な候補があったが、毎年何千ドルもかかるようなものや、無料だけれどもボランティアのコミュニケーションのありとあらゆる所にくだらない広告を撒き散らすもの (ええっと、SignupGenius かな) はすぐに候補から外した。また、インターフェイスの出来が悪いものも多くあった。最終的に、私は CEO と電話で話した後で決断したのだが、Helper Helper という名前のクラウドベースのシステムを選んだ。寄付金管理、身元調査、トレーニングモジュールといった不必要なアドオンを提供したりせず、ボランティアのみに集中している。Helper Helper の年額料金はその団体の種類や具体的な機能によって大きく変わるが、私たちに見積もりとして示された金額はいつも使っているウェブサービスのために用意している予算の範囲内にあった。一年間使ってみて私たちは Helper Helper を気に入っているし、十分費用に見合ったものが得られていると思っている。

Helper Helper のセットアップ

Helper Helper は 4 つの主たるデータタイプを扱う。ボランティア、チーム、団体、そして仕事内容だ。4 つのそれぞれがインターフェイス上でトップレベルのタブとして示される。

ボランティア (Volunteers)

Helper Helper では個々のボランティアがそれぞれ自分の項目を持つ。ユーザーはまずサインアップしてから、氏名、電子メールアドレス、および電話番号 (電話番号は自由記入だが、テキストや音声でユーザーに直接連絡できて便利) などのメタデータを管理する。管理者が手作業で、ボランティア項目を作成したり、ボランティアを管理者に格上げしたり、アンケートをセットアップして T-シャツのサイズなど追加情報を集めたり、既存のユーザーのためにあらゆる情報を編集したりすることも可能だ。Helper Helper は個々のユーザーごとに過去と未来の責任分担を追跡する。

上のスクリーンショットの例でもお分かりのように、自分でサインアップできない人やそうさせるべきでない人、例えばレースの給水所でガールスカウトたちに大人の監督の下でボランティアの働きをしてもらうような場合に使うために、プレースホルダーのボランティアを作成しておくこともできる。そのような場合でもイベントのコーディネーターは十分なボランティアの人手があるかどうかを知り、その人たちが働いた時間を追跡する必要もあるのだが、プレースホルダーを使うことによって個人情報を保存する必要なしにその目的を達成することができる。

チーム (Teams)

ボランティアたちを集めてチームを作ることができ、これは二つの意味で役に立つ。まず、こちらが私たちの状況では最も重要なことだが、管理者がチームのメンバーたちをユニットとしてメッセージを送ることができる。例えば FLRC では、個々のレースごとにチームを作っておけば、去年そのレースにボランティアとなってくれた人に対して今年もしてくれないかと頼むことができて便利だ。(Tonya が強調する通り、それは礼儀正しいやり方でもある。もう一度ボランティアしてくれないかと招待しなければ、去年やったことを評価してもらえなかったのかと受け取られてしまいかねないからだ。) 次に、管理者は特定のチームの中でボランティアの仕事を制限することができる。それにより、例えば特定の仕事を適切なトレーニングを受けた人たちだけに依頼できるようになる。

どうやらこれは普通でない使い方らしいのだが、私たちはボランティアがそれぞれ複数のチームに属することができるようにしている。私たちのボランティアには複数のレースで働いてくれる人たちが多いので、ボランティアの人は皆、それぞれのチームに時間が割り当てられている。でも大多数の Helper Helper サイトでは基本的に排他的なチーム分けが使われていて、そのお陰でチーム活動の正確なレポートやチーム間の比較ができているようだ。

団体 (Organizations)

私が理解するところでは、Helper Helper は一般的に、例えば大学の体育部で外部の団体のために働くボランティアを割り振ったりする活動に使われることが多いようだ。(そのような場合のチームでは、例えば陸上競技チームとフットボールチームのどちらがより多くのボランティア活動をしているかを比較するような目的を想定しているらしい。) けれども FLRC では外部の団体のためにボランティア活動をすることはほとんどない。それでも Helper Helper ではあらゆる仕事がそれぞれ何らかの団体に割り当てられている必要があるので、私たちは個々のレースごとにそれぞれ別々の団体をセットアップしている。

実際的なことを言えば、私たちにとってこの団体設定の主たる使い道はレポート作成にある。Helper Helper は個々の団体ごとにどれだけのボランティア通算時間が割り当てられたかを示してくれるからだ。

仕事内容 (Opportunities)

仕事内容 (Opportunities) こそが Helper Helper の核心だ。ここで、それぞれの人に割り当てられる実際の仕事が示される。仕事内容 (Opportunities) には多くのメタデータが含まれる。仕事のタイトル、説明、日付と時刻、場所、コーディネーター情報、どのチームが見られるかといったメタデータがある。

最も重要なこととして、一つの仕事内容が複数個のタイムスロット（割り当て時間）を持つことができる。個々のタイムスロットごとにそれぞれ独自の日付、時刻、タイトル、説明、およびボランティアの最大人数を指定できるので、タイムスロットは一つの仕事の中で複数の作業を定義できる効率的な方法となる。

(個々の作業ごとに別々の仕事内容を作成することも可能だが、そのやり方ではサインアップしたい人たちに多数の作業を並べた一つの長いリストが示されてしまう。それよりも、そのレースに属する作業を階層的にまとめるやり方の方が扱いやすい。その上、このタイムスロットのやり方を使うことでサインアップしたボランティアたちのみに宛てて一つの場所からコミュニケーションをすることが可能になる。)

ボランティアの最大人数を指定できる点は非常に重要だ。こうすることで、作業のどれかが定員一杯になれば、それ以外の作業にサインアップするよう人々を促すことができる。このレースでは計時係主任を 1 人しか必要としないが、それに加えて計時係助手が 3 人欲しい、といった具合だ。人気が集まると思われる作業には順番待ちリストを作っておくこともできる。そうすれば、やりたい作業の順番待ちに登録しておいて、そこにサインアップしていた人がキャンセルした場合に自動的に自分が受け持てるようになる。

登録とキャンセルの締め切りが設定できたり、タイムスロットの一部分にだけサインアップできたりという柔軟性はありがたいと思うが、メリットより手間の方が大きい気もする。ボランティアの人数が十分でない場合には、人々にそれぞれ好きなものに登録してもらい、間際になって誰かが登録をキャンセルすれば、私としてはただイライラするだけのことだ。それにまた、タイムスロットを細かく分割するのは面倒だ。誰かがタイムスロットの一部分のみにしか参加できないのなら、そもそもその人はサインアップするべきでない。なぜなら、1 人でできることのために 2 人の人の仕事をシフトしなければならず、私の負担がさらに増すだけだからだ。2 人分をシフトするくらいなら、タイムスロットを分割しておいてから人々がそれと知って登録できるようにしたい。

一つの仕事内容が保存されれば、それがすべてのボランティアたちから見えるようになる。人々が自分でそれと気付くと期待すべきではないので、FLRC では公開のサインアップリンクを作成しておいて、個々の仕事内容ごとに私たちのウェブサイト上にそのサインアップリンクを提供するとともに、レースの発表にもそれを含めている。ユーザーがリンクをクリックすれば、作業のリストが開く。

以上が Helper Helper の設定方法の簡単な概観だ。では、実際のユーザー体験はどんなものだろうか？

Helper Helper で仕事内容にサインアップする

Helper Helper は iOS アプリ と Android アプリを無料で提供し、iPhone 上の Safari でそれとほとんど同じに動作する反応性の良いモバイルサイトを提供している。アプリとモバイルサイトのいずれでも、ユーザーが新しい仕事内容を見つけたり、自分の責任分担を一覧したり、自分のボランティアとしての統計情報を見たりできる。

アプリとモバイルサイトの主な違いは、デバイス上の push 通知に対応しているか否かだ。デフォルトで、Helper Helper はすべてのボランティアに対して責任分担を 2 日前に通知し、2 時間前にもう一度通知する。これらの通知は電子メールと push 通知で送られるが、どちらのチャンネルを使うかを管理者が設定できる。Helper Helper では SMS テキストメッセージングによる通知を送ることも可能だが、そのために追加料金がかかるので、私たちは使っていない。私たちのボランティアの大多数は十分上の年齢なので、電子メールを読んでくれると信頼できる。

FLRC のレースで幅広い層のユーザーにボランティアとして使ってもらった経験から言えば、わざわざアプリをダウンロードするユーザーは多くなくて、多くの人たちはウェブサイトと電子メールを通じて Helper Helper とやり取りしている。なので、アプリがあるのはありがたいことだけれども、push 通知があることは保証されない。モバイルウェブサイト自体はうまく働いているので、その点は大きな損失となっていない。

作業にサインアップするのは Sign Up ボタンをタップしてからその選択を確認するだけの単純なことだが、新規ユーザーは最初にアカウントに登録しなければならず、しばらく離れていて戻ってきたユーザーはログインしなければならない。これはよくあるインターネット上のアカウントとのやり取りなので、テクノロジーに疎くてログインに困難を感じた人たちはほんの少数だった。

高度なオプションを使えば責任分担の表示をプライベートに設定することができ、そう設定しておけばコーディネーター以外の人から見えなくなる。設定しなければ、例えば 1 of 2 と書かれている横の人のシルエットのように見えるところをタップすれば誰がサインアップしているのかが分かる。また、サインアップの際にコーディネーターにメッセージを送ることもできる。実際、この機能を効果的に使っている人たちも何人かいた。

ほとんどのユーザーにとってはそれで全部だ。ここでは意図的にシンプルな手順にしてある。サインアップを済ませた後に、考えが変わって自分の責任分担を削除したければアプリやウェブサイトを使って削除できる。するとそのスポットが即座に解放されて他の人がサインアップできるようになる。実際そういうことは時々起こっているし、もちろん私はボランティアを失いたくはないけれども、しばらくの間自分がイベントから離れていても、その間に私の知らないところで人々が来たり去ったりしても私には別にどうということではない。

Helper Helper でイベントを管理する

ボランティアたちが仕事内容にサインアップするにつれて、Opportunity 画面の一番上にある Opportunity Times セクションがそれぞれの作業がどの程度埋まっているかを示し、Opportunity 画面の一番下にある Commitments セクションが個々のボランティアを示す。

ボランティアたちがログインすることに対して私のサポートを必要とするような問題が起こることはほとんどなかったが、私が Add Users ボタンをクリックして手作業で人を追加したり望みのユーザーを探したりする必要があることも時々あった。例えば、お金を払ってイベントに参加してもらった写真家を追加して、その人もイベント前の情報を全部見られるようにしたこともあった。同じように、特定の人を特定のスポットに置いておきたいと思うことも時々あって、そういう場合には直ちに手作業でその人を追加して、他の人にそのスポットを取られないようにするのが賢明なやり方だ。デフォルトでは、イベント前にそのように手作業で追加された人には電子メールで通知が届くようになっているので、あらかじめその旨をその人に知らせておくのがよい。(サインアップせず直接援助を申し出てくれる人がいれば、イベント後にその人を追加するようにすればその人に通知は送られない。)

手作業で人を追加するのが役に立つもう一つの状況として、コーディネーターが人々の割り当てを変更したい場合がある。例えば、計時係助手のうち 1 人にこのレースに限って計時係主任を務めてもらいたいとしよう。その場合、私が自分で計時係主任のスロットを削除してから追加し直すことができる。Helper Helper は責任分担を拒否することも削除することもできる。その違いは、拒否した事実がアカウントの中でその後も維持されることだ。これまでの経験で、私は何の知らせもなく欠席したボランティアについては責任分担を拒否するようにしてきた。いずれの場合もコーディネーターはそのボランティアに電子メールを送ることが可能だが、私が誰かを削除した場合にはほとんどいつも、その人から別途知らせが届いていたので、そういう状況ではわざわざ新たなメッセージを送らずに既存の会話の中で話を終わらせる方が簡単だ。

Helper Helper はすべてのボランティアに対して責任分担を 2 日前に通知し、2 時間前にもう一度通知するけれども、それらは必要最小限のリマインダーに過ぎず、時刻と場所を知らせるだけのものだ。だから、すべてのボランティアに宛ててあらかじめ何か一言添えた電子メールを送っておくのがよく、そうすればその人たちも自分がちゃんと参加している気持ちになれるだろう。Helper Helper はそのために Opportunity 画面の一番下に Message Attendees ボタンを設けている。このボタンで Message Center が開き、そこでコーディネーターはメッセージを書くことができる。送られるのはプレインテキストのみの電子メールであってスタイルを付けたりグラフィックスを添付したりはできないが、ちゃんと役には立つ。

Message Center の一番上のところには非常にありがたいポップアップメニューがあって、これを使って特定のタイムスロットのみに宛先を絞ることができる。私たちはたいていの場合これを使っていないが、非常に規模の大きなレースでは目的ごとに、例えばビブスを集めるボランティア、救護所ボランティア、コースマーシャルに分けてそれぞれ別々のメッセージを送る必要がある。残念ながらこれはポップアップメニューなので、いろいろ違った場所を担当するコースマーシャルに分けて同じメッセージを 17 回も送る必要があって手間が大変だ。

Helper Helper は個々のメッセージとそれがいつ送られたかをアーカイブ保存しているので、どのコミュニケーションをしたかが簡単に追跡できる。Message カラムに見える行をどれでもクリックすればそのメッセージ全文が開くので、何を言ったかを見直したり、あとで再利用したりできる。

Opportunity 画面の一番下にはあと 2 つボタンがあって、これらにも知っておくべき価値がある：

• 出席者をダウンロード はサインアップをしたすべてのボランティアを含めたフォーマット済みの Excel スプレッドシートを作成する。これを印刷してイベントに持って行けば、誰が何をしているか思い出せるし、イベント前に共有しておくべき連絡先情報を取り出すためにも使えて便利だ。
• すべてのタイムスロットを認証 を使ってコーディネーターはボランティアに参加すると言っていた人たちが実際に出席していることを一挙に認証できる。個々のボランティアごとの認証もできるし、これまでの経験で誰かが欠席したことも数回あったがそういう場合にもすぐに手作業でその人の責任分担を拒否してからそれ以外の全員を認証できた。理想的な世界においてはボランティア自身が自分で認証すべきところだが、Helper Helper はイベント後にまだ認証していない人に向けてリマインダーを送るようになっている。でも私の経験では、そのリマインダーに応答してくれる人は半分以下だ。私としてもその人たちを悩ませたいとは思わないので、この“すべてのタイムスロットを認証”機能を使えばすぐにことが済む。.

最後にもう一つ、Helper Helper には詳細なレポート機能があって、下に示した Overview 画面にある通りだ。他のタブではそれぞれチーム、個々のボランティア、特定の仕事内容、および団体に関する統計情報に踏み込むことができる。日付の範囲を指定できるほか、団体やカテゴリーでフィルターして統計に含めたり除外したりできる。(下に示したのは Race 対 Non-Race の円グラフだ。他の団体の場合は、もっと具体的な仕事内容にカテゴリー分けして表示させたいと思うかもしれない。)

FLRC にとっては、これらのレポートは単なる統計数字に過ぎない。私が思いつく限り、その利用方法は高レベルの概観を他の人たちと共有して「こんなことを一緒にやり遂げたぞ！」と言い合うことくらいだ。それでも、きっと他の団体ではボランティアの仕事内容の与える影響を数値化して評価することがとても重要になることもあるに違いない。

Helper Helper の良い点と望む点

全体的に、Helper Helper は私たち FLRC にとってとても有益な存在で、年額料金に十分見合う価値があると思う。具体的には：

• ボランティアを集めるのが楽になる： パンデミックの影響が収まるにつれて、ボランティアを集めることが次第に難しくなってきたと思う。たとえ屋外の活動であっても、多人数が集まることを警戒する気持ちが抜けない人たちがいるからだ。でも、個々のレースごとに Volunteer ボタンが表示されてそれをクリックするだけでボランティアを求めるメッセージに応じてサインアップできるようになったことで、ボランティアを集めやすくなったと私たちは感じている。サインアップしようと思って見てみたのに既にスロットが全部一杯になっていてがっかりしたという声が聞こえてきたことさえ何度かあった。
• サインアップ方法が一貫していて分かりやすい： Helper Helper を使い始めるより前には、個々のレースディレクターとチームリーダーがそれぞれ独立にボランティアを追跡管理する必要があったし、それがどの程度一貫した手続きかにも大きなばらつきがあった。後日に感謝を示すためにボランティア全員のリストを入手することさえなかなか困難であった。
• より良いボランティアとのコミュニケーション： コミュニケーションのプロとして、私はこの点をとても重要視している (多くのレースで実際にコミュニケーションしている) が、レースの前と後にボランディア全員と連絡できるようになったことがこの上なくありがたいと思えた。レース当日の異常気象で突然レースを中止しなければならない場合などは特にそれを実感できる。
• 出席の信頼性が上がる： あらかじめ出席状況を知る方法はないが、私の感じでは Helper Helper のリマインダーとレース前のコミュニケーションのお陰で遅刻したり欠席したりするボランティアの数が減ったと思う。
• レースディレクターのストレスが減る： すべてのレースディレクターを代弁することはできないけれども、私は Helper Helper のお陰で 10 個もの別々のイベントを運営していて、全作業を把握して誰がどこにサインアップしたかを目で見ることができて大いに助かっている。たとえどこかのスロットが空いていたとしても、一目でそれと分かるのがとてもありがたい。
• 将来はさらにもっと楽になる： 2023 年に、私はかなりの労力を費やして個々のレースのための仕事項目を作成した。そのためにはレースディレクターたちと話をして、どんな作業が必要か、それぞれ何時から何時まで作業すべきか、作業の内容をどう説明すべきかを打ち合わせる必要があった。でも今年は、昨年の仕事項目のすべてをコピーして、日付を新しいものに替え、細かな手直しをするだけでよかった。

けれども、だからと言って Helper Helper が完璧だという訳ではない。これはごく小さな会社が作っていて、彼らは技術サポートの質問やバグ報告にも反応が早いけれども、もっとここを変えたり改善したりしてくれれば私たちの使い方に良い結果が生まれるのにと思う点がいくつかある：

• コーディネーターへのアクティビティ通知： Helper Helper は新しい人たちが初めてサインアップした際に Institution Admins (最高位の管理者) に対して電子メールで通知してくれるけれども、ボランティアがどれかの作業に加わったり作業への登録を取り消したりした際に Team Admins (チーム管理者) や Opportunity Coordinators (仕事内容コーディネーター) に対する通知はしてくれない。なので、私はレースの何週間も前から多大な時間を費やして責任分担リストに日々目を配っていなければならず、せめてボランティアたちが登録したり取り消したりした際にそれと分かればありがたいのにといつも思っている。聞くところによれば機能追加予定リストにそのような機能が載っているとのことなので、実現されるのを待ちたい。
• 管理者の混乱状態： 管理者資格の与えられたアカウントではより多くの機能へのアクセスが許されるが、私が最近になってようやく気付いたのは Institution、Organization、および Team という 3 つの異なるレベルの管理者資格があることだった。現時点では、FLRC のレースディレクターたちがそれぞれ必要なことができるために、彼らすべてに最高位の管理者資格を与えなければならず、それぞれのレースのみに制限した管理者資格を与えることができないでいる。現状は次の通りだ：
  • Institution 管理者 はすべてのことができ、仕事項目を作成したり編集したり、一つの仕事項目の中の特定の責任分担についてボランティアを追加したり削除したりもできる。
  • Organization 管理者 は仕事項目の作成と編集はできるが、ボランティアの追加や削除はできない。私の想像では、多くの場合団体 (Organization) の管理者は外部にいる存在だからなのだろう。また、Organization 管理者を定義するやり方が他の 2 つのタイプと違っているのも奇妙だ。他の 2 つのタイプでは、ボランティアを編集している最中にポップアップメニューから選ぶことができるのに。もしも Organization 管理者がボランディアを追加したり削除したりできるようになれば、FLRC にとってはありがたいことだろう。
  • Team 管理者 は、その管理者のチームだけに制限された仕事項目に対してのみ、仕事項目やボランティアの管理ができる。それ以外の仕事項目については、自分のチームに属するボランティアの追加と削除はできるが、それ以外のことは何もできない。FLRC にとってはこれでは困る。FLRC のレースディレクターたちは、仕事内容の編集をしたり、自分のチームにまだ属するに至っていない人たちの管理をしたりする必要があるからだ。
• 編集モードでタイムスロットのタイトルが見えない： Helper Helper は私の要望に応えて Opportunity 画面にタイムスロットのタイトルを追加してくれた。けれども、仕事内容の編集中に異なるタイムスロットを見分ける方法が、ツールチップを使うやり方しかない。確かに機能はするけれども、似たようなタイムスパンの中に 17 個の異なるコースマーシャルを配置しなければならない場合、特定のコースマーシャルを見分けるために苦労してマウスをあちこち動き回らせなければならない。
  
• 一目で分かる色分けが欲しい： 上の左側のスクリーンショットでご覧の通り、Helper Helper は個々のスロットがどのように埋まっているかを数字で示す。つまり 1 of 1とか 0 of 4 とかいう具合だ。でも大規模なイベントで非常に多数のスロットがある場合、全部埋まったスロットは緑、一部埋まったスロットは黄、空のスロットは赤といった風に色分けして表示されればとてもありがたいと思うのだが。
• 電子メールのスタイル付きテキストや画像： 私自身はプレインテキストの電子メールが大好きではあるけれども、通知の電子メールではテキストにスタイルが付いたり画像が挿入されたりした HTML メールの方が役に立つはずだ。(例えばコースマーシャルが行くべき場所を示した地図など。)
• タイムスロットのメッセージ用のチェックボックスインターフェイス： 個々のタイムスロットごとにポップアップメニューを使ってメッセージを送れるのはとても役に立つ。ただ、このポップアップメニューにチェックボックスのインターフェイスを組み合わせて、複数のタイムスロットを選択して特定のメッセージを送れるようになれば、似たような多数のタイムスロットに電子メールを送る際の繰り返しの手間が省けることだろう。
• サインインの頻度を減らす： これはマイナーな要望だが、Helper Helper では毎日サインインする必要がある。対照的に、1Password ではその手間が大幅に軽減されている。私の場合、もっとずっと機密性を要するシステムでもっとずっと長い期間サインイン状態を記憶してくれるものをたくさん使っている。
• チームの自動割り当て： 私たちが Helper Helper を使うやり方が普通でないのかもしれないが、私としては特定の仕事内容にサインアップしたボランティアが自動的にその仕事内容のチームに割り当てられるようになればよいのにと思う。現状では、私が全部をチェックして個々の新しいボランティアをそれぞれチームに割り当てなければならない。私の推察ではたいていの Helper Helper サイトが基本的に排他的なチーム分けを使っていて、一人で複数のチームに属することが多い FLRC の状況とは違うからなのだろう。私たちの場合は仕事内容を制限するのがチームを使う目的ではなくて、主としてメッセージングの便宜のためにチームを使っているのだから。
• 写真の通知がない： Helper Helper アプリはボランティアたちに対して責任分担に写真を添付することを推奨しているけれども、そうやって送られた写真は Institution 管理者に対してホーム画面上に表示されるのみで、システムがコーディネーターに写真の到着を通知することはない。加えて、私がホーム画面を見ることなど滅多にない。つい最近になって、私は昨年一年間でボランティアたちが全部で 42 枚の写真を投稿してくれていたことに気付いた。現在私はそれらの写真を共有するためにダウンロードしているところだが、もっと早くこれらの写真のことを知らせてくれればよかったのにと思う。

これらの問題点が解決されれば私たちが Helper Helper を使う体験がもっと良いものになるだろうとは思うけれども、これらは決して交渉決裂要因ではない。端的に言えば、Helper Helper は私たちがボランティアを集めてコミュニケーションするやり方を根本から変革してくれた。もしあなたがかなりの規模のボランティア管理を必要とする何らかの団体に属しているなら、ぜひ Helper Helper を試してみられるとよい。

討論に参加