From d91673e77d9afeed15004d4989dcf47a89b92d9f Mon Sep 17 00:00:00 2001 From: Junki Mano Date: Tue, 10 Dec 2024 10:24:59 +0900 Subject: [PATCH] =?UTF-8?q?Slack=E3=82=AC=E3=82=A4=E3=83=89=E3=83=A9?= =?UTF-8?q?=E3=82=A4=E3=83=B3=20(#180)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- documents/forSlack/README.md | 380 +++++++++++++++++++++++++++++++++++ package.json | 3 +- 2 files changed, 382 insertions(+), 1 deletion(-) create mode 100644 documents/forSlack/README.md diff --git a/documents/forSlack/README.md b/documents/forSlack/README.md new file mode 100644 index 00000000..a9d32fe3 --- /dev/null +++ b/documents/forSlack/README.md @@ -0,0 +1,380 @@ +--- +sidebarDepth: 4 +author: フューチャー株式会社 +home: true +heroText: Slack利用ガイドライン +tagline: Future Enterprise Slack usage guidelines +pageClass: lang-home +footer: ©2015 - 2024 Future Enterprise Coding Standards - Future Corporation +--- + +# はじめに + +リモートワーク／ハイブリッドワーク前提の業務において、チャットなどの非同期コミュニケーションを円滑に進めることは、業務効率を向上させるだけではなく、従業員全員の満足度を向上させ、より良い職場づくりに繋げることができる。 + +また、ユーザーの様々な要望に応えるため、現代のチャットサービスは豊富な機能が提供されている。しかし、各ユーザーの考え方／利用者の感覚が千差万別であるため、ある人によって問題ないとされる行動が、別の人にとっては良くない受け取り方をされることも多い。例えば次のような対立が考えられる。 + +* 必要最低限の簡潔なメッセージを送る方が効率的だ／文面が冷たくならないように絵文字や感嘆符（！）を使うべきだ +* チーム全員に確認して欲しい場合、`@here` `@channel` を用いるべき／必要性が低い場合は利用しない方が良い +* ファイル添付を利用すべき／予期せぬ共有をしないように控えるべき +* 質問はDMで行うべき／チャンネルで行うべき +* 依頼事項の返信は、絵文字のリアクションだけで済ませてよい／コメントを投稿すべき +* 発信数が多過ぎてチャンネルが埋もれるのでスレッドを使うべき／見逃すのでチャンネルへ投稿すべき +* times（分報）チャンネルを活用すべき／ノイズなので個人のメモに閉じるべき +* 業務時間外（例えば17時を過ぎたら）にメンションを飛ばすべきではない／予約投稿にすべき／受け取り側がミュート設定を入れれば良い + +これら運用方法は利用者の所属する部署やチームごとに自然と決めていくことが多いが、複数のチャンネルで異なった運用方針である場合に混乱をきたすことがしばしばである。また、トレードオフを理解せずに、メールのコミュニケーションモデルを引きずった方針を取ってしまうこともある。異なる文化圏のチームから移籍した時に、ハレーションが起きるケースも多い。 + +本ガイドラインはSlackを対象に利用方針についてのベースとなる規約を設け、Slackを用いてより良いコミュニケーションを促進することを目的とする。 + +# 適用範囲 + +* 「はじめに」章で述べた、一般ユーザー視点での利活用を中心とする +* 次のような特に管理者が関心を持つ事項については対象外とする +* パスワードポリシー／多要素認証の強制 +* 社外メンバー招待／ゲストレベルの調整 +* 監査 + +# 免責事項 + +::: warning 有志で作成したドキュメントである + +* フューチャーアーキテクトには多様なプロジェクトが存在し、プロジェクトごとに異なる運営方針が存在する。本規約はフューチャーアーキテクトの全ての部署／プロジェクトで利用されているわけではなく、有志が観点を持ち寄って新たに整理したものである。相容れない部分があればその領域を書き換えて利用することを想定している +* 自社のセキュリティポリシーや外部サービス利用ポリシーがある場合は、そちらを優先すること +* Slack Enterprise Grid／Google Workspaceを利用しているため、それらの機能を前提にしている記述がある + +::: + +# 管理者向け推奨設定 + +## Workspace Access + +チーム、プロジェクトでの利用の場合は リクエスト制（`By Request`） もしくは招待性（ `Invite Only`）の設定を推奨する。 + +## デフォルトチャンネル + +通常ワークスペースにメンバーを追加した際には `#general` へ自動参加するが、他にもメンバー全員に参加して欲しいチャンネルがある場合にはデフォルトチャンネルを追加する。 + +::: tip +ユーザグループに対してもデフォルトチャンネルを設定できるため、用途に応じて使い分けると良い。 +::: + +## 表示名ガイドライン + +ワークスペースごとにガイドラインを設定することを推奨する。後述の表示名設定や、その他チームコミュニケーションにおけるルールを設定する。表示名のガイドラインを設定する権限があるのは、ワークスペースのオーナーだけなので注意する。 + +## ワークスペースの管理者 + +ワークスペース内に複数のチームが混在する場合、それぞれのチームごとに管理者権限保持者を設定すること。 + +理由: + +* 管理者権限を持った人しか実行できないオペレーションがあった際、チーム内で解決できる状態を作っておくことが望ましいため + +# ユーザ向け推奨設定 + +## アカウントアイコンを設定する + +デフォルトのアイコン利用は極力避け、アカウント登録時に各自のアイコン画像を積極的に登録する + +理由: + +* チャットコミュニケーションにおいて、個人識別におけるアイコン画像の有用性が高いため + +また、GitHub/GitLab、Google Workspace、その他利用サービスも同様のアイコンを利用することで、個人を識別しやすくなる。 + +### 検索性の高い氏名（Full name）を設定する + +表示名（Display name） もしくは氏名（Full name） にて、ローマ字及び漢字（無ければカタカナ）でのフルネームを登録すること。表示名はチームごとに記載文化や書き方が異なるケースが多いので、本ガイドラインでは氏名に記載することを推奨する。例えば「未来 太郎」の場合、「Taro Mirai (未来 太郎)」という記載を推奨する。 + +理由: + +* Slackではアカウント名のインクリメンタルサーチが強力である。その際、ローマ字でも漢字でもサジェストされる状態にすることでユーザビリティの向上が期待できるため。 + +## ユーザーグループの推奨 + +ユーザーグループの利用を推奨する。ゲストユーザーは追加できないため、もしチャンネルに該当するメンバーが在籍する場合は、その旨をメンバー全員が理解しコミュニケーションから除外してしまわないように注意すること。 + +::: tip +ユーザーグループを作成できない状態（メンバーがワークスペース間にまたがっている場合等）の時、メンション先の対象者全員が個別に自分のSlack設定\>Notification\>My Keywordsに「＠○○チーム」と予約語を登録することで、擬似的にグループメンションが可能 +::: + +# チャンネル命名規則 + +## 外部組織メンバーが在籍するチャンネルの命名 + +Slack コネクト等でチャンネル内に社外のメンバーが含まれる場合には、チャンネル名の先頭に `---ext` をつける + +理由: + +* 全社的に統一的なプレフィックスを定義することで、外部とのコミュニケーションにて予期しないミスが発生してしまうことを防ぐ目的がある。例えば、内部の進行について相談する発言を、取引先メンバーが在籍するチャンネルに誤投稿してしまう事態を避けるため +* チャンネルはセクションという単位でグルーピング可能となり、従来のように、用途や組織を表現するプレフィックスで並び順を制御する必然性が薄れた + +# 投稿内容ポリシー + +## 敬称は不要 + +敬称は省略して、 `@mano メッセージ内容` といった形式でコメントすること。もし、どうしても敬称を付けて欲しい場合、表示名をさん付けにするハックも存在するため、受信者側で調整する。 + +理由: + +* コミュニケーションを迅速・シンプルにし、不要なマナーの自然発生を予防するため + +## 広め通知は使い所に注意する + +### `@channel` + +緊急時を除き、原則利用を禁止する。 + +理由: + +* `@channel` はSlackを見ていないユーザにも通知が飛ぶため、休暇中のメンバー等にも影響がある。受取側で制御すべきという考えもあるが、システム障害対応など優先度の高い問い合わせのために、あえてOFFにしていないメンバーも存在することを考えると、なるべく利用を避けた方が無難である + +利用して良い場合: + +* システム障害時など、重大かつ緊急度が高い場合は `@channel` を使っても良い + +### `@here` + +メールのCCに似た意図で `@here` を使うことは禁止とする。 + +推奨ケース + +```txt +@真野 @村田 ○○の件ですが\~ +``` + +NG（メールのCC的な形で `@here` を追加） + +```txt +@真野 @村田 @here ○○の件ですが +``` + +理由: + +* メールのCC的な参考情報であれば、`@here` を付けずに、チャンネルの未読通知で後で見ることができるため +* 真に必要ではないときに通知が飛ぶことが常態化すると、`@here` の緊急性やアクションを求める意味合いが弱まり、真に必要なときに読み飛ばされてしまう可能性が上がるため（「狼少年」現象） + +利用して良い場合: + +* 全員にアクションを促す連絡事項を行う場合。例えば、チーム全体イベントへの出欠可否を確認する連絡など + +## 絵文字や感嘆符を活用する + +積極的に活用することを推奨する。テキストコミュニケーションは、画像や音声が伝わらない分、冷たく捉えられがちである。特にリーダーなど上位のポジションにいる場合は、メンバーに威圧的に捉えられないように配慮するのが好ましい。 + +「では、Aの方針でよろしくお願いします！」「では、Aの方針でよろしくお願いします:ganbatte:」 など付けることで、不機嫌でないことがわかり、心理的安全性が保たれる。 + +積極的にカスタム絵文字を追加することを推奨する。チーム内でしか通用しない（例えば内輪ネタのような）カスタム絵文字であっても気軽に追加して良い。 + +理由: + +* より良いコミュニケーション手段を模索すること自体が、コミュニケーションを活性化させ、価値を向上させるため + +注意: + +* なお、当然ながら他人の名誉を毀損するなど、社会人／プロフェッショナルとしてふさわしくない内容は登録しないこと + +## 機密情報の流出に注意する + +営業情報、個人情報、人事情報など機密情報は、「最小権限の原則」に従い、なるべく宛先を狭めるべきである。センシティブなやり取りを行う場合は、参加者を絞ったプライベートチャンネル／DMグループの活用を推奨する。 + +:::tip メッセージ通知にも気をつける +画面投影やWebミーティングでの画面共有時、意図しないメッセージ通知が見えてしまう事がある。Slackの通知設定にて次に示す設定を施すことで防ぐことが可能なので活用すると良い。 + +* 通知自体をOFFにする +* 通知はOFFにしないが、メッセージ内容は非表示にする +::: + +## ファイルの共有に注意する + +Slackのファイル共有は便利であるが、ファイルのオーナー（作成者）とチャンネルにメンバー追加できる担当者が必ずしも1:1ではない。そのため次の運用が望ましい。 + +推奨する運用: + +* Google Driveなどにファイルをアップロードする +* Google Drive側で適切な権限に絞り込む + +理由: + +* Google Drive側で権限設定が可能 +* Slack上にアップロードされたファイルが、別のチャンネルに再アップロードされて収集がつかなくなるといったケースを防ぎ、統制を図るため + +該当しないケース: + +* 社外勉強会の登壇資料など、一般に「公開済み／公開予定 」のファイルはアップロードして良い + +Google DriveのURL共有時プレビュー表示について: + +* 表紙がプレビューされるが、次の理由により問題ないという立場を取る。 + * プレビュー表示されるのは1枚目（1シート目）であり、通常は表紙ページが見られるのみ + * ファイルが存在すること自体は知られて良い（チャンネルに投稿しているため）と考えられる + * なにか問題があれば、プレビュー表示を行わない操作がSlack上で可能である + +## メンション範囲は適切に + +### 過剰なメンションの抑制 + +原則、レビュー依頼や確認依頼など、行動してほしい時にメンションを付けるものとする。「@mirai ありがとうございます！」「@mirai 承知しました！」等の挨拶にメンションを付けると、通知が来てノイズになるため非推奨とする。メンションを付けず「ありがとうございます！」とすると良い。 + +::: tip 情報提供依頼系など善意やり取りはきちんとフィードバックする +情報提供依頼はSlackと親和性が良いタスクである。この際、情報提供の依頼者は、回答してもらった人に対して、:+1: 絵文字だけのリアクションを取る場合があるが、フィードバック付きでコメントを返すことが望ましい。情報提供者としても、その情報が役立ったのか、またそうでないかの関心は強いためである。 +もし、フィードバックが難しい場合や、スレッド投稿数をなるべく減らしたいなどの意図がある場合は、複数のリアクションを返し感謝の意を強調すると良い。 👍️🎉☺\[神\] のようなイメージである。 +::: + +### メンションの宛先をできる限り絞り込む + +単なる周知目的ではなく行動を促したい相手に絞ること。お見合いになってボールが浮いてしまう可能性がある。「@mirai @mano @murata @ozawa @tanimura AWSの設定で確認したいのですが～」などと広すぎる場合は、宛先メンバーは自分よりもっと詳しい人がいるかも知れないので、回答すべきかどうか逡巡してしまう。できれば1、2名に宛先を絞り、宛先メンバーから別の有識者メンバーにディスパッチしてもらう運用を考えると良い。 + +## プライベートチャンネルの投稿に対する引用 + +プライベートチャンネルの投稿コメントを、別のチャンネルにURL引用で投稿すると、該当チャンネルの権限を有していないユーザーにも参照権限を与えてしまう。引用時にはセンシティブな内容が含まれていないか確認するよう注意する。 + +## DMはなるべく避ける + +基本的には、DMよりチャンネルでのやり取りを推奨する。チャンネルであっても、より参加人数が多い（よりオープンな）チャンネルでのやり取りを推奨する。 + +理由： + +* 重複した質問を防ぐため +* 質問事項がチーム／組織に共有されることで、全体の効率が上がるため +* 後から類似の困りごとを持ったメンバーが、キーワード検索で見つけやすくするため + +DMの利用を推奨するケース: + +* 人事相談、機密事項を含む場合 +* 限られたメンバーのみに、ファイル共有をしたい場合 +* 後から検索させる意味がないやり取り（「最近元気？」と同期に投げる場合など） + +## timesの推奨 + +timesとは、分報や作業スレッドとも呼ばれ、今取り組んでいることや困っていることを投稿することを指す。 +本規約の推奨は次のとおり: + +* timesの利用を推奨する +* メンバーごとのtimesチャンネルではなく、スレッドでの利用を推奨する +* timesスレッドは、他のメンバーは参照しても参照しなくてもどちらでも良い + +理由: + +* スレッド単位であれば、本チャンネル側のノイズになることはない。参加メンバーが多い場合は、times専用のチャンネルを作成すれば良い +* メンバーごとの times チャンネルは、チャンネルが必要以上に増えるので推奨しない +* 必要に応じて、作業状況を本人に確認（ポーリング）しなくても把握することができる +* ハマったことや調べたことが、後々キーワード検索で見つかり、新規参画者の助けになることも多い + +timesスレッド作成者の注意事項: + +* times内とはいえ、他の人が不快になるような発言や不適切な利用は避ける（チームメンバーが閲覧可能であることを忘れない） + +timesスレッド内のメンション: + +* timesスレッドのコメント数は100以上になることもあり、途中で他メンバーに相談事などでメンションを飛ばすと、呼ばれたメンバーには「該当のスレッドの全コメントをチェックしたほうが良いのか」といった迷いが生じる。そのため、times内ではなく相談は別メッセージに切り出して行うことを推奨する +* なお、timesの投稿を読んで欲しいときは、timesスレッドでメンションしても良い +* timesのメンションを受けたユーザーが、その後の投稿の通知を受け取りたくない場合は、そのスレッドの通知を切ることで対応する + +timesスレッドでメンションを飛ばすと、その後の投稿によってメンション先のユーザーに通知が飛んでしまうのではないか？という懸念への考え方: + +* 該当スレッドのフォローを外せば良いので、上記観点でメンションを行う／行わないの判断は行わなくても良い。前述の通り、timesのコメントを（全て）読んで欲しい否かで決める + +## メッセージ（スレッドのトップ）は具体的に書く + +チャンネルのメッセージ（スレッド先頭の投稿）では、話題を端的に表現する。ただし、返信スレッドの中を確認しないと内容が分からないようなメッセージ（タイトル）は非推奨とする。 + +| | メッセージ（スレッド先頭の投稿） | +| :---- | :---- | +| ✅推奨例 | @mirai チケット \#4191 foo bar failed のビルドエラーの解消についての相談です。スタックトレースはスレッド内に記載します | +| ❌非推奨例 | レビュー依頼 | + +なお、メンションはメッセージ（スレッド先頭）に付けるか、返信スレッド内に付けるかは任意とする。 + +参考: + +* [Slackで要件を書かずに「質問があります。詳細はスレッドに記載」をやめたほうがいい理由 \- CARTA TECH BLOG](https://techblog.cartaholdings.co.jp/entry/better_slack_communication) +* [リモートワーク時代を生き抜くAI・機械学習チームの働き方 \- エムスリーテックブログ](https://www.m3tech.blog/entry/2024/12/07/110000) + +## Also send to channelは乱発しない + +Also send to channel を利用することで、スレッド内の投稿をチャンネルのタイムライン側に重複投稿ができる。 + +本規約の推奨は以下の通り: + +* 過去のスレッドでやり取りを再開した場合に、チャンネルに在籍するメンバーに通知する目的で用いる +* スレッド内で重要な決定事項に至った場合は、メンバーに周知する目的で用いる +* スレッド内のやり取りを細かくAlso send to channelすると、スレッドを用いる意味が薄れるので、利用頻度は抑えるように意識する + +## 予約投稿を活用する + +特にリーダーからメンバーに対して、深夜（22:00-6:00など）や休日など業務時間外の投稿は原則禁止とし、予約投稿を推奨する。 + +理由: + +* 仕事とプライベートにメリハリを持たせることで、成果の向上を期待できるため +* （システム障害等）緊急時の依頼と混同してしまうため。次回出勤時の対応で良いものと区別すること +* Slackのアップデートにより、チャンネル投稿に閉じずスレッド投稿へも予約投稿が可能となった + +::: tip 受け取り側で制御する方針 +システム障害時などの緊急時は電話連絡とし、メンションに対する即対応を求めない取り決めを行うのであれば、受け取り側で通知時間を設定し、送る側は送信時間に気を遣わない運用も可とする。ただし、時間外に通知を受け翌営業日に対応しようと考えたが翌営業日には忘れているような場合、受け取り側で通知を受けた時点でリマインダーを仕込んだり、アクティビティ \> @メンション を定期的に確認するような工夫をする。 +::: + +## 絵文字リアクションによる積極応答 + +非同期のコミュニケーションにおいて発信者が気になる点として、「投稿内容を見てくれたのかどうか」がある。見ているのであればOKで、回答は急がないケースは想像以上に多い。 +こういった場面では、絵文字リアクションを付けることで解決するため、積極的に活用する。 + +また、参加者が多いチャンネルでの発信は勇気がいることなので、コミュニケーションを活性化させるためにも絵文字リアクションを積極的に行い推奨／礼賛することが望ましい。 + +## 不在の表明 + +表示名に不在情報を記載（例：`@sato_11/8休`）しておくことを推奨する。受信側が不在時に緊急性の低い通知を防げたり、送信側が即レスを期待しなくて済む。不在情報がGoogleカレンダーなど別のスケジュールアプリで管理されていたとしても、Slackでの依頼時に気付けるため。 + +::: tip ステータス機能で「休暇中🏝️」にすればよいのではないか +ステータス機能でもチームメンバーに不在であるという状態を表明できる。しかし、次の観点で表示名での表明を推奨する。 + +* いつから、いつまで休暇なのかステータスでは不明である + * 期間が分かれば、予約投稿で休暇明けに投稿するなどのアクションがすぐ取れる +* 休暇だけでなく出張中などの情報も提示できる + * 例えば、海外出張なので時差があることが分かれば、チームメンバーにどれくらいでレスポンスが来そうか予想ができるようになる +* ステータス変更に気が付きにくい + * メンションを付けて投稿する時に常時表示されるわけではないので、ステータスは見過ごされる可能性が高い +::: + +## メッセージのURLを活用する + +Slackは本来、フロー情報向けのツールである。しかしこれをWikiなどのストック情報向けツールに転記する労力は高く、運用が形骸化しがちである。そのため、例えばあるスレッドで設計方針について議論したのであれば、そのスレッドのURLをコピーして、作業チケットやWikiなどに記載し、トレース可能にすることを推奨する。 + +なお、決定事項の経緯や議論内容を数年経過したのちに確認することもしばしば発生する。こうしたユースケースがあるため、議論はスレッドを利用し、かつ同一スレッドで複数の議論を混ぜないことが望ましい。関連議論がいくつかのスレッドに分かれる場合、相互に関連スレッドのURLを投稿しておく。 + +::: tip Slackにおける情報ストック機能 +Canvas、ブックマーク、ピン留め機能を活用することで、Slack内にてストック情報を取り扱うことも可能である。PJで利用している課題管理サービスのURLを共有したい場合にはブックマーク、PJメンバーに都度参照して欲しい特定のメッセージがある場合にはピン留め、情報量が多く章立てて整理をしたい場合にはCanvas、などといった形でユースケースに合わせて使い分ける。 +::: + +## 可読性を上げるための書式設定 + +箇条書き、太字、引用などの装飾は、積極的に活用する。文章を構造化することで、読み手にとっての負荷が軽減されるため。Slackの書式以外にも、【すみかっこ】等の記号を使うことでセクションを表現することも同時に推奨する。 + +## エラーメッセージの画像添付非推奨、テキストスニペットの推奨 + +有識者にスタックトレースなどのエラー内容を画像添付して問い合わせることは原則として非推奨とし、テキストで共有することを推奨する。また、共有内容が長文の場合にはテキストスニペット使用が好ましい。 + +理由: + +* 相談相手も裏取りとしてスタックトレースの内容を検索することが多々あるため +* 後から同様の困り事を持った人が、キーワード検索で見つけにくくなるため +* 長いログをそのまま貼り付けるとスレッドを広く埋め尽くしてしまうが、テキストスニペットを使えば1投稿あたりのデフォルト表示域を制限できる + +次の場合は、スクリーンショットなどの画像で共有しても良い。 + +* コピーできないエラー表示など、テキストでの情報提供が難しい場合 +* （相談相手が、コピー範囲などを独自判断で狭められることを防ぐなどの理由で）スクリーンショットでの共有を希望する場合 + +::: tip テキストスニペット利用時は、タイトル（ファイル名）に拡張子をつける +Slackはテキストスニペットに設定されたタイトルをそのままファイル名としてダウンロードするよう動作する。この際拡張子が設定されていないとSlack内でそのままファイルを開くことができなくなってしまう。 +::: + +# さいごに + +本ガイドラインの策定にあたっては、すでにインターネットに公開されているSlack利用ガイドラインや記事等も参照させていただきました。本ガイドラインが皆様のSlack活用をより快適にする一助となれば幸いです。 + +参考： + +* [メルカリ社内Slack利用ガイドラインを一挙公開しました〜！！\#メルカリな日々 | mercan (メルカン)](https://careers.mercari.com/mercan/articles/23325/) [mercari-Slack-guidelines/Slack\_Guidelines\_Ja.md at master](https://github.com/mercari/mercari-slack-guidelines/blob/master/Slack_Guidelines_Ja.md) diff --git a/package.json b/package.json index fcddc534..df7c593e 100644 --- a/package.json +++ b/package.json @@ -24,7 +24,8 @@ "pandoc:gitbranch-html": "pandoc ./documents/forGitBranch/git_branch_standards.md -s --self-contained --number-sections --toc -t html5 -F mermaid-filter.cmd -c ./documents/common/pandoc_styles/css/style.css -o ./documents/forGitBranch/Gitブランチフロー.html", "pandoc:gitbranch-word": "pandoc ./documents/forGitBranch/git_branch_standards.md --toc --reference-doc=./documents/common/pandoc_styles/スタイル.docx -F mermaid-filter.cmd -s -o ./documents/forGitBranch/Gitブランチフロー.docx", "pandoc:markdown-html": "pandoc ./documents/forMarkdown/README.md -s --self-contained --number-sections --toc -t html5 -F mermaid-filter.cmd -c ./documents/common/pandoc_styles/css/style.css -o ./documents/forMarkdown/Markdown設計ドキュメント規約.html", - "pandoc:markdown-word": "pandoc ./documents/forMarkdown/README.md --toc --reference-doc=./documents/common/pandoc_styles/スタイル.docx -F mermaid-filter.cmd -s -o ./documents/forMarkdown/Markdown設計ドキュメント規約.docx" + "pandoc:markdown-word": "pandoc ./documents/forMarkdown/README.md --toc --reference-doc=./documents/common/pandoc_styles/スタイル.docx -F mermaid-filter.cmd -s -o ./documents/forMarkdown/Markdown設計ドキュメント規約.docx", + "pandoc:slack-html": "pandoc ./documents/forSlack/README.md -s --self-contained --number-sections --toc -t html5 -F mermaid-filter.cmd -c ./documents/common/pandoc_styles/css/style.css -o ./documents/forSlack/slack_usage_guidelines.html" }, "repository": { "type": "git ",