テキストコミュニケーションスキル – コンテキストの明示
キーワード:TechBlog , システム開発 , テキストコミュニケーション , リモートワーク
テキストコミュニケーションにおけるコンテキストの明示について。
経緯
前回、下記のようなエントリを書きました。
テキストで伝える力
その中で個別のテキストコミュニケーションスキルについて軽めに触れましたが
今回はコンテキストの明示に絞って深掘りしています。
コンテキストとは?
文脈や背景。
より親しい人、連想力の高い人などを相手にしていると
この文脈や背景を省略しても話が通じたりします。
各ツールごとのコンテキスト
こういうのが代表的かな?という例を書いています。
他にも色々あるかな?
かんばんツールのカードにおけるコンテキスト
仕様を記述する際にストーリー形式で書くことはある種のコンテキスト共有ですね。
例えば
<ユーザー>として
<目的>をしたい
なぜなら<理由>だからだ
のようなフォーマットで。
欲しい機能の背景にはどのようなストーリーがあるのか?
それが伝わることで、単に機能を書き連ねた要件定義と比べて本当に必要なものが伝わったり、
より良い工夫を生み出す可能性があがります。
BTSのIssue報告時のコンテキスト
バグが発生した際の前提条件などが詳しく書いてあると問題解決の時間が早まったり、
その情報がないと解決できなかったりします。
例えば ユーザー登録画面で”予期せぬエラー”という表示がされている。
これだけの情報で解決できるバグの場合もありますが、
再現困難な複雑なケースの場合、
- テストアカウントの情報
- 発生環境
- 詳細なテストデータ
など、バグが発生した際の細かな情報が必要になります。
情報共有ツールにおけるコンテキストの明示
- 技術的な記事
OSやバージョン情報などが必要になる場合は記載しておく。
記事中で他のツールやライブラリを利用している場合は、それに関する注釈や外部資料へのリンクなどを
付けておいたほうが良い。
何か前提となる概念がある場合は、その概念の説明や外部資料へのリンクなどを
付けておいたほうが良い。
- 情報を探す側へ配慮したコンテキスト
タイトルから内容を類推できるようになっているか?
検索しやすいキーワードを含めているか?
チャットツールにおけるコンテキストの明示
何の話題か明確に伝える。これ、チャットだとわりと省略されがち。
IssueなどはIDがあるので分かりやすいですね。 Issue233 とか。
複数の話題が同一チャンネルで並行して走っている時、
話題が分断されたら再開場所で再度話題を明示した方が分かりやすくなります。
話題を明示することはあとで検索するときの検索しやすさも向上させます。
コンテキストを共有してもらうには?
- コンテキストの必要性を伝える
- 概念として伝える
- コンテキストが無くて困ったとき、コンテキストがあって助かったとき。具体例が出た時に実例として伝える
- 自然とコンテキストを記載することになるようなフォーマットのテンプレートを提供する
注意点
コンテキスト過多
コンテキストの明示ですが、それ自体コストにもなります。
そのため余分なことを書かなくても伝わるメンバーのみで構成されている場合は最小限の記述でも良いでしょう。
コンテキスト不足
職種が違った際などは、特定の職種内にしか伝わらない用語への注釈や資料へのリンクをつけるなど補足が必要になるでしょう。
この際は普段よりも気をつけて記載する必要があります。
感情
Emoji,わざとエモーショナルに書いた文章などでテキストに感情というコンテキストをのせる。
テキストコミュニケーションは表情や声のトーンが伝わらないので場合によっては冷たく伝わりがち。
多めにEmojiなどを利用することで、「怒ってないよ」「批判してるんじゃないよ」「嬉しいよ」などを伝えやすくなります。
結果として無駄な誤解や軋轢を生みにくくなります。
テキストコミュニケーションだけ?
コンテキストの大切さはテキストコミュニケーションだけではなくて、対面のコミュニケーションでも大切ですね。
ただ、テキストコミュニケーションは「追加で情報を引き出す」コストが対面のそれより大きいので、より慎重にコンテキストを把握しておく
必要があるのかな?と思ったりします。