Slackの会話がそのままPRに—Copilot導入前の権限設計
実践ガイド 12
SlackかChatworkか、安さより社外メンバーの参加で決まる
社内5人と社外2人で制作案件を進める想定なら、GitHubの更新を開発側の議論につなげたいチームにはSlack、社外への修正依頼をチャット内のタスクで受け渡したいチームにはChatworkが合う。先に決めたいのは、社外の2人がどの会話に参加し、過去の承認を自分で読み返す必要があるかだ。
同じ7人でも、全員を自社の有料利用者として扱う場合と、社外の2人が参加範囲を限ったり自分のアカウントを使ったりする場合では費用が変わる。安い単価を選んでも、必要な会話が見えず、依頼や決定を別の場所へ伝え直すなら案件は進めにくい。以下の金額は利用結果ではなく、人数が変わらないと仮定した試算である。
社外の協力者を同じ会話に入れられるか
Slackでは、社外の請負業者などを自社ワークスペースのゲストとして招待できる。Slackのゲスト利用条件によると、有料プランのシングルチャンネルゲストは無料で、アクセスできるのは1チャンネル。有料のアクティブメンバー1人につき5人まで招待でき、複数チャンネルに参加するゲストには通常のメンバー料金がかかる。
社外のデザイナーとライターが共通の案件チャンネルだけで依頼を受けられるなら、社内5人を有料メンバー、社外2人をシングルチャンネルゲストとする設計が成り立つ。デザインと原稿を別々のチャンネルで管理し、同じ協力者が両方を見る必要があるなら、参加範囲と請求対象を見直さなければならない。社内だけの検討を分けることはできるが、そこで決めた修正内容を共有チャンネルへ戻す役割も必要になる。
Chatworkでは、社外の相手が自分のアカウントで案件のグループチャットに参加する形を考えられる。この場合、社外の利用者を自社の有料席として数える前提にはならない。ただし、相手が使うプランによって過去のメッセージを読める範囲が異なる。制作が長期に及び、以前の承認を協力者自身に確認してもらうなら、参加できることと履歴をたどれることを分けて考えたい。
年間費用は参加方法をそろえて計算する
Slackの日本向け料金表は、Proを1ユーザー月925円、Business+を月1,920円と表示する。Proには無制限のメッセージ履歴があり、無料プランで閲覧できる履歴は90日間だ。GitHub通知と案件の会話を残すという想定では、まずProを費用計算の基準にできる。
Chatworkの料金表では、スタンダードは年間契約で1ユーザー月700円、月間契約では月840円で、いずれも税抜。スタンダードのメッセージ閲覧は無制限だが、フリーで閲覧できるのは直近40日以内だ。同じ料金表には、フリーでもチャットとタスク管理を使えること、組織内の一部ユーザーだけを有料化できないことも記されている。
表示単価が12カ月変わらず、全員を有料利用者にする単純計算では、Slack Proは7人で年77,700円、Chatworkスタンダードは年58,800円となる。一方、Slackで社内5人を有料メンバー、社外2人を無料のシングルチャンネルゲストにできれば、同じ計算は年55,500円になる。Chatworkで自社組織の5人だけがスタンダードを契約し、社外2人がそれぞれ別のフリーアカウントで参加するなら、自社の試算額は年42,000円だ。
後者の2案は社外の人が利用できる範囲も、費用を負担する主体も同一ではない。とくにChatworkのフリー利用者には履歴制限が残る。また、Chatworkの表示価格は税抜で、Slackの参照した料金表示には税区分が明記されていない。これらは請求総額の確定値ではなく、同じ参加条件を置いたときの比較材料である。
修正依頼をどこでタスクにするか
社外との制作では、修正依頼を送った事実より、誰が引き受けて完了したかが重要になる。Chatworkは会話の中で担当者を指定し、タスクの追加と完了を扱える。原稿の差し替えを依頼した人と作業する人が同じグループチャットにいれば、依頼の文脈と作業の状態を近い場所に置ける。
テック比較ジャーナルの実務シナリオ比較は、外部ツール連携を重視する場合はSlack、ITに詳しくない人や社外取引先にも日々使ってもらう場合はChatworkが向くと評価している。これは利用者の定着率を測定した数値ではなく、操作を教える際の違いとして捉えられる。Slackではチャンネル、スレッド、通知の使い分けが中心になり、Chatworkでは依頼を受けるグループチャットとタスクの担当・完了をそろえる説明が中心になる。
Slackにもリストやワークフローはあるため、タスクを扱えないわけではない。ただ、チームがSlackのリストとGitHubのIssueを併用するなら、どちらを作業状態の正本とするか決める必要がある。同じ修正を両方へ登録すると、片方だけ完了になったときに社外の協力者へ伝えるべき状態が曖昧になる。開発担当がGitHubで作業を管理し、社外には完成物への確認だけを頼むなら、依頼の入口と作業記録を分ける運用も自然だ。
GitHub通知を社外の会話へ流すか
開発を含む案件では、SlackへGitHubの更新を取り込める点が具体的な差になる。GitHubのSlack連携案内には、管理者がアプリを導入した後、リポジトリをチャンネルに登録してIssueやPull Requestの更新通知を受ける方法が示されている。通知はチャンネル内で関連する議論へつなげられる。
もっとも、リポジトリの更新をすべて社外の協力者がいる場所へ流すと、原稿やデザインの確認依頼が埋もれやすい。開発側のチャンネルで変更を追い、社外に判断を求めるときだけ、対象の制作物と必要な返答を案件の共有会話へ出すほうが役割を区別できる。GitHub上のイベント名をそのまま伝えるより、「どの画面を確認するか」「誰の承認を待つか」を書いたほうが、開発を担当しない参加者にも行動が明確になる。
Chatworkを選んでも開発担当がGitHubを使うことはできる。その場合は、更新通知を集める便利さより、開発側の変更を誰が社外向けの依頼に言い換えるかが問題になる。開発の記録と制作上の承認をそれぞれ別の場所に置くなら、公開判断に必要な情報だけは案件のグループチャットに残しておきたい。
後から探す承認は、参加者が見える場所へ
有料プランで長い履歴を閲覧できても、決定が参加者に見えない場所へ散らばれば検索しにくい。Slackで原稿の承認が個別メッセージ、デザインの修正が別のスレッドに残る場合も、Chatworkで依頼がグループチャット、承認が個別チャットに残る場合も、後から案件全体の経緯を追う人には負担になる。社外の協力者が必要とする決定は、その人が参加する案件の会話へ記録するという運用が要る。
この想定でSlackを選びやすいのは、社外の協力者が共有チャンネルの範囲で仕事を進められ、社内ではGitHubの通知を継続して扱う場合だ。Chatworkを選びやすいのは、社外を含むグループチャットで修正依頼を担当者に渡し、完了まで追うことを優先する場合である。社外の人に過去の承認まで読んでもらう必要があるなら、その人の参加範囲とプランを確かめてから費用を比べるのが筋だ。
関連記事：
関連記事
ニュースレターを購読
Web3、AI、暗号資産の最新ニュースを受信箱にお届けします。
0