記事を書く話だったり、アウトプットをする事にさんざん言及してきたんですが、アウトプットから得たインプットを返すアウトプット（Qiitaコメントなど）は言及してきませんでした。
我ながらこれはおかしいな、と感じたので「上手なコミュニケーションと言えるコメントの仕方とはなにか」を考えてみます。
やること
- SNSやメディアでのコメント
- コメントを受けた時のリアクション
やらないこと
- ソースコードのコメント
コメントをする目的を考える
たとえば、SNSでリプライを発信する場合などが分かりやすいでしょうか。
他にも、社内チャットなどのコミュニケーションツールでの返信も考慮します。
コメントを発信するからには何らかの目的があったはずです。
とりあえず脊髄反射でコメント出しときますね、というノリもありますが、大体の場合「見てますよ」というアピールのためです。
投稿にスタンプを押すのも、これに似ていますね。
次に確認の意図があります。
発信者がある事象にAと説明したところ、分かりにくかったのでコメント者がBという認識で合っているか？と質問するようなケースです。
これも業務上、ありがちなケースですね。
この結果、修正を要望する場合などがあります。
この段階までくると、業務の推進が目的になっていきます。
若干、先述の内容に触れますが指示もツールを介して行われる事があります。
エンジニア向けに発信する場合は、細部にも目を向ける必要がある場合も多いので、タスクチケットを切ってアサインするケースもあります。
この辺りは、企業やチームの文化もありますので断言はできませんが、私の経験上（ソースなし）だと、概ね上記のような運用をされている事が多かったです。
まずはコメントの内容ではなく、コメントの目的を考えていきました。
ここからは、それぞれのケースに合わせてどのようなコメントをしていくか考えていきます。
コメントをする技術
コメントの内容に触れる前に、メールの時にやっている事を思い返してみます。
- 宛先（役職・宛名）を本文に含める（一番上に書く）
- 名乗る
- 冒頭の挨拶
- 内容
- 末文の挨拶
- 署名
のような構成になっていると思います。
一番大事：内容
基本的にチャットツールは、関係者全員が一覧できるように最初の投稿（メッセージ）は特に指名がない限りは全員に宛てている事を想定している事が多いようです。
が、コメントが散発的であったり、内容が限定的である場合に「自分は関係ない」という心理が働いてしまいがちです。
この場合「分からない話だけど、自分の事じゃないからいいや」と思って積極的に動こうとはなりにくい傾向があります。
そのため、発信者は「誰が担当かわからないので、とりあえず全員に投げてみよう」と思っても、誰も対応しないなんて事もあってしまいます。
こういったケースを防ぐために、指名なしの投稿は暗黙的に「誰に対しても言っていない」とならないように、たとえばslackなどでは@channelとか@hereとかにして、関係者にリプライの通知がされるようにしておく等の工夫がされています。
それでも自分ごとではないと思ってしまう事も考えられるため、確実に誰かに何らかのアクションをしてほしい場合は、コメント内に何をしてほしいのか明記するようにしておくのも一手です。
もうひとつの方法として、タスクチケットで運用している場合は「質問」というカテゴリーを作って、タスクを発行したら自動的にチャットに投稿する仕組みを作るという手もあります。
この場合、ある程度のテンプレートに沿って記入するように促せるため、質問者側も品質の高い質問ができます。
どうしてもチャットツールなどはフリーフォーマットである事が多いため、質問の品質が一定ではないのが悩みです。
が、こういった定型句を入れられると、起票スピードも質問時の想定漏れや言葉足らずをある程度防いでいく事ができます。
距離感
目的：不問
ただし、内容問わず注意が必要なシーンが考えられる
あまり良い文化だとは思わないのですが、たまーに不躾な方がいます。
メールではないので、挨拶や名乗りも署名も要らないんですが、初対面（はじめてのコミュニケーション）で要件だけ投げてくる方です。
顔が見えないコミュニケーションなので、画面の向こうをBOTかなんかだと思いがちです。
これは実務だとしても、メッセージを介して相手の顔や表情をイメージできていますか？というお話です。
気を使う必要はない、と考えるかどうかは相手との距離感もありますので、自分が良くても相手はどうか、一度見直してみたほうが良いかもしれません。
反論・指摘への不快感
目的：相手の結論を考え直してもらう
行動：相手の考えを尊重しよう
これは文字ならでは、の問題の気がします。
要するに、言い方の問題です。
対面で話す際は、多少なりとも言い方を工夫すると思います。
たとえば「アレはダメ、こうしなさい」というような注意の際も「○○を△△になるように修正してほしいのですが、可能でしょうか」のような言い換えをする等があります。
「○○が△△になってないからやり直し」と言葉の意味や意図は同じですが、テキストで見た時にどう感じるか。
同様に、修正をお願いしたがもうちょっと頑張ってほしい際の頼み方もとても気を使うポイントです。
特にコードレビューに多いのですが、「このやり方でも良いと思いますが、○○だともっと良くなります。なぜなら（＋理由）」のように書けていると、レビュイー（レビューを受けた側）としても、納得して修正対応に励みやすいです。
ただ納得させるだけではなく、類似した問題を自主的に解決してくれる可能性が高まります。
「ダメと言われたから修正する」から「何がダメだから修正する」と意識を変える事で、モチベーションを下げすぎる事を防いでくれます。
教えを請う
目的：自分が分からない事を解説していただく
行動：自分が分かる部分を伝えて、欲しい回答をしやすいように問題を絞っていく
また別のケースで、書いてある内容がよく分からなかった場合のお話です。
メールでもよく使われるシーンなので、上記と比べると簡単かもしれません。
シンプルに「○○について、△△だと思うのですが、私の認識は間違っていないでしょうか？」で良いです。
新卒研修でも質問についてはしっかり指導された事があると思います。
ここで「○○について分かりません」だけだと、何がどう分かっていないのか、回答者が混乱するので、自分の理解した内容を話しながら質問をするのが効果的です。
ただし、一番最初に質問だと相手に伝えないと、結局何が言いたいのか意図を汲み取って、もう一度全文を初めから聞く事になりやすいです。
チャットだとテキストに全て書いてあるはずなので、改めて読み直せば何を言っているかは理解できるようになりますが、なるべくなら回答者の手間にならないようなうまい質問を心がけたいものですね。
メールの形式で不要なもの
要るものだけに絞ると、
- 宛先
- 内容
だけで良いでしょう。
宛先を指名して、誰に見てほしいのかを明示します。
その上で、本来の内容を書いていけば良いと思います。
ただし「親しき仲にも礼儀あり」で、質問に答えてもらって当たり前の感覚だとか、そもそもコメントが無味乾燥な文章になっていないかは確認しておいた方が良いでしょう。
相手がこのメッセージを読んだ時にどう考えるのか？を気にしていって、実際に送った後のリアクションなどを見ていけば難しくはありません。
まずは手始めにいつも読んでいるQiitaユーザーからコメントを残していく方法を試してみましょう。