担当者ではなくプロジェクトに残すメールボックス

ほとんどのメールプロバイダーが人数に応じて料金を決めるため、多くの企業も人数を基準にメールを整理しています。従業員ごとにアドレスを用意し、プロジェクト、物件、顧客、案件番号などをそこへ詰め込み、後からフォルダー、フィルター、記憶を頼りに整理します。

プロジェクトごとのメールボックスは、その考えを逆転させます。アドレスが担当者ではなく仕事に属します。小さな管理上の違いに見えますが、スレッドを管理していた人が退職したとき、二人が同じ履歴を必要としたとき、顧客が三月の合意内容を尋ねたときに意味が表れます。ここでは採用する価値がある場合、席単位で課金されない場合の費用、問題が起きる場面を説明します。

プロジェクトごとのメールボックスの形

仕組みは単純です。すべてを人経由で処理する代わりに、仕事の単位そのものにアドレスを作り、関係者が読めるようにします。

同じ方法でも業種によって形は変わります。建設会社なら案件番号ごと、賃貸管理会社なら物件ごと、代理店なら顧客ごとに作り、三人のアカウントマネージャーが交代しても保持します。製造業なら生産ロットごとです。どの場合も、通信は関連する対象に結び付き、担当者が変わっても残ります。

プロジェクトごとのメールボックスが実用的かどうかは、二百番目のアドレスに費用がかかるかで決まります。席単位の料金では最初と同じ費用になるため、Google WorkspaceやMicrosoft 365でこの運用をする例は多くありません。Googleの料金ページにあるBusiness Starterの7ドル料金なら、五百個のプロジェクト用メールボックスは年額42,000ドルとなり、予算会議で見送られがちです。

実現可能にする計算

記載されたプランでは、メールボックスごとの課金ではなく、階層ごとに件数上限があります。Proはドメインごとに300個を100ドメインで利用でき、共有ストレージ50 GBです。Agencyは1,000ドメインについてドメインごとに1,000個、共有ストレージ200 GBで、月額29ドルまたは年額279ドルです。

そのため、Agencyで五百個のプロジェクト用メールボックスを使うと、年額279ドルであり42,000ドルではありませんです。制約は料金から容量へ移ります。200 GBを500個で共有すると一つあたり約410 MBとなり、通常の通信には余裕がありますが、すべてのスレッドに図面や写真が付く場合は厳しくなります。この上限が問題なら、Driveアドオンは記載価格で月額3.20ドルから利用でき、メールボックス数の計算を変えずに容量を増やせます。

これが実際のトレードオフです。プロジェクトごとのメールボックスはライセンス費用が安い代わりに容量計画が必要です。新しい仕事を得るたびに増える席単位の請求より、通常は管理しやすい問題です。

フォルダーとフィルターより適する理由

フォルダーで解決できるという反論は自然です。しかし完全には解決できず、その理由を具体的に確認する価値があります。

フォルダーは一人のメールボックス内にあります。その人が不在なら履歴も利用できません。あらかじめ委任を設定し、テストしている場合は別です。プロジェクトアドレスは例外措置ではなく、適切な権限を持つ全員がアクセスする前提で作られます。

フィルターは内容ではなく受信者に対して動きます。個人宛てでプロジェクトに関するメールは、ルールで分類する必要があります。顧客が件名を変えたり別のアドレスから返信したりすると、ルールが機能しないことがあります。プロジェクト宛てのメールにはこの分類が不要です。

引き継ぎがメンバー変更になります。担当者の入れ替わり時、プロジェクトごとのメールボックスなら、権限の更新後に新しい人が完全な履歴へアクセスできます。転送もエクスポートも不要で、IT部門へ返却されたノートPCのPSTファイルだけに履歴が残ることもありません。

もちろんフィルターも役立ちます。記載されたプランではStarterではなくProから提供されるため、見落としに注意が必要です。ただし、プロジェクトごとのメールボックスとは別の問題を解決します。

実務で機能させる方法

長く続く構成と、一四半期で放棄される構成を分けるポイントがいくつかあります。

予測できる名前にします。案件番号、物件参照、顧客コードなど、規則から導ける必要があります。アドレスを毎回調べる必要があるなら、すでにうまく機能していません。

一括で作成します。二百個のメールボックスを手作業で作るべきではありません。一括作成と設定招待により、一度の操作でアドレスを用意し、必要な人が自分のパスワードを設定できます。認証情報を回覧する必要はありません。詳しくはメールボックスの一括作成をご覧ください。

開始前に誰が何を読むか決めます。適切な人が参加して初めて、プロジェクトごとのメールボックスが役立ちます。実際のメンバーシップと適切な権限を持つ共有メールボックスがその仕組みで、転送とは異なります。共有メールボックスの仕組みで詳しく説明しています。

終了を計画します。プロジェクトは完了します。終了したプロジェクトのメールボックスをアーカイブするか、休止状態で残すか、削除するかを事前に決めます。この方法の失敗要因は蓄積だからです。

プロジェクトごとのメールボックスが適さない場合

一部の仕事には合いません。三百個のアドレスを設定する前に理解しておくべきです。

プロジェクトが非常に多く小さい場合、たとえば週に数十件あり各案件のメールが二通だけなら、アドレスの作成と廃止の手間が利点を上回ります。適切なフィルターを備えた共有受信トレイの方が向きます。多くの営業関係のように通信が本当に個人的なら、相手もそれを期待するため、アドレスは人に結び付けるべきです。他人のスレッドを見る必要が一度もないなら、存在しない問題を解決することになります。

仕事が担当者より長く続き、複数人が同じ履歴を必要とし、いつ何に合意したかを後から確認する場面で、この方法は価値を発揮します。代理店、賃貸、建設、専門サービス、製造業にはよく当てはまりますが、二人だけのコンサルティング会社にはほとんど当てはまりません。

誰が何を読むか

プロジェクトごとのメールボックスは、アクセスを意図的に設計して初めて有効です。結果の異なる三つの方法があります。

メンバーシップ付き共有メールボックスが通常は適切です。複数人が同じメールボックスを開き、権限に応じて同僚の返信を含む完全な履歴を確認します。人の追加や削除は認証情報の引き継ぎではなく、メンバー変更です。送信メールも個人の送信済みフォルダーへ分散せずプロジェクトに残り、この点が引き継ぎを実用的にします。

個人メールボックスへの転送は簡単に見えますが、利点が失われます。各人がコピーを受け取り、返信は個人アドレスから送られ、プロジェクトには会話の完全な記録がありません。追加手順を使って元の問題を作り直すことになります。

認証情報を共有するメールボックスは避けるべきです。誰が何をしたか判断できず、退職時には全員が知るパスワードを変更する必要があり、二要素認証も適切に管理できません。

記載されたプランでは、共有メールボックスはStarterから利用でき、ドメインごとに五個、Proでは十五個、Agencyでは三十個です。導入前に、ドメインごとの上限とプロジェクト件数を比較してください。

二年後

本当のテストは、時間とともに運用が悪化するかどうかです。早い段階で一つの判断をしなければ、実際に悪化します。

完了したプロジェクトは蓄積します。二年後には数百個のメールボックスがあり、そのほとんどが休止中でも少しずつ容量を使い、一覧を煩雑にします。長く満足できるチームは、プロジェクト終了時の扱いを最初に決めています。

現実的な選択肢は、メールをアーカイブしてメールボックスを削除し、枠を解放しながら保持ルールに従って履歴を残すこと、枠を使う代わりにアクセスできる休止状態で残すこと、または誰も監視しない通常のメールボックスへ戻すことです。何を選ぶかより、選ぶこと自体が重要です。

関連する判断はアドレス自体の扱いです。案件番号のアドレスが受信を止めると、請求書、保証請求、古いアドレスを使う仕入先からの問い合わせなど、後から届く通信が返送されます。メールボックスを廃止してもcatch-allの宛先でアドレスを維持すれば対応できます。記載されたモデルでは追加のアドレス費用はかかりませんが、正しいルーティングと監視が必要です。