Content last updated 2024-06-27

コミュニケーションのヒント

Support Engineeringチームのための一般的なコミュニケーションのヒントを提供します

このページは、GitLab Support部門のための一般的なコミュニケーションのヒントを 提供することを目的としています。この部門にとって有用な コミュニケーション関連の事柄であれば何でもここで歓迎されます。 これは GitLab Communicationハンドブックページ の 拡張として位置づけられています。

例:

  1. Support Engineerは、Slack、Zoom、メールを介して他のSupport Engineerと どうすれば効率的に話せるか?
  2. Support Engineerは、サポートのSlack チャンネルで投稿する チームメンバーとのやり取りからどうすれば最大限の効果を得られるか?

Slack リアクション

GitLab におけるコミュニケーションの一般ガイドラインSlack ワークフロー で 言及されている :white_check_mark: 絵文字に加えて、 SupportのSlack チャンネル内では以下の絵文字も活用することを検討してください。

  1. :idontknow: - 別のSupport Engineerが質問しているが、その答えを あなたが知らないとき
  2. :red_circle: - 別のSupport Engineerが何かを依頼しているが、 競合や時間的制約のためあなたがそれを行えないとき。たとえば、 シフト時間中に対応できないため、別の人のオンコールシフトをカバーできない場合などです。 注: 優先度の高いリクエスト(緊急時、お客様エスカレーション、STAR)に対応する際は、この絵文字の使用を避けるべきです。
  3. :eyes: - リクエストを調査中であることを示すため。 誰かがリクエストに対応していることの目印となり、 作業の重複を防ぎます。リクエストに答えられなかった場合は、 :eyes: を削除して、リクエストがまだ処理されていないことが他の人にわかるようにしてください。

支援できないことを示すかもしれないにせよ、 何らかのシグナルを送ることは、送信されたメッセージを無視するよりも望ましいことに注意してください。 これは、スレッドを開始した人が、誰かが入ってくるという希望にしがみつくのを防ぎ、 別の場所で助けを探すことに集中するのに役立ちます。

もちろん、可能な限り、自分の頭の中にあるアイデアは、 些細なものと考えられるものでも共有してください。なぜなら、それが他の誰かを正しい方向に導くことになるかもしれないからです。


チケット

Slack 上でチケットに関するディスカッションが行われた場合は、 そのディスカッションへのリンクをチケットの社内コメントとして追加することを忘れないでください。 すべての Slack 投稿は90日後に削除されるため、その社内コメントで Slack のディスカッションを 要約するか、長すぎないなら単に貼り付けてください。 これらのアクションにより、他の人がディスカッションの情報を使って チケットへの貢献に役立てたり、単にそこから学べるようになります。