ギルドワークスの原則の1つに「 行動指針としての共有(Share)・表明(Assert)・ふりかえり(Reflet) 」があります。
この3つの頭文字を取り「sar」の行動指針と呼んでいます。
行動指針「sar」
- 共有(Share):状況を共有する。学び合う。
- 表明(Assert):自分の意見を言う。状況を相手に伝える。
- ふりかえり(Reflect):自分で、チームでふりかえる。見直す。
今回はこのsarのうち共有(Share)にフォーカスし、情報をうまく共有(Share)するための3つのコツを書いてみます。
共有(Share)とは?
共有は起きた事実を伝えるという行動と考えています。例えば「システム異常を示すアラートが起きている」「◯◯さんから開発の相談があった」などです。
共有の目的は共有された相手が状況の認識を持つためです。その状況に対する解釈や考えは違っているかもしれませんが、それは次の表明に関係してきます。また共有した人が見聞きしていないことまでは当然ながら共有できません。

情報をうまく共有(Share)するための3つのコツ
共有をうまくするためには以下の3つが必要です。
1:情報を集めすぎない。
2:解釈を加えない。
3:事実と推測を混ぜない。
1. 情報を集めすぎない。
起きていることを関係者が知ることで、それに対する解釈ができ、なんらかの表明につながります。ですので、できるだけ早く、関係者が解釈できるように共有することが大事になります。
そのため「まだわからないからもっと情報を集めよう」と共有しないままに行動していると時間が経ってしまい、自分と関係者の間の情報の量の差が広がっていきます。
少し脱線しますが、情報の量の差が広がると共有をうまくするコストも高くなっていきます。
一度にたくさんの情報を伝えるためのまとまった時間が必要ですし、受け取る側としても厚くなっているコンテキストを理解する理解力が求められてきます。
そうなると共有する側がそのための準備(例えばわかりやすいように資料を作るなど)をしたりし始め、共有するタイミングが後ろにずれていきます。
2. 解釈を加えない。
ある情報に対して、意味付けや解釈をしようとすることで、共有するタイミングが遅れることもあります。
自分の意見を表明することは、自分事として考えるきっかけの1つになるので望ましい行動です。
ただ、ここでの共有の目的である「共有された相手が状況の認識を持つ」ことから照らし合わせると、共有した後で解釈を考える方が良い場合もあります。
自分の解釈を付け加えるためには、その情報に対する自分の知識や経験などが必要になります。十分な知識や経験がないと、解釈するためにその情報のことを理解する活動をします。そうなると必然的に共有が遅れることになります。
3. 事実と推測を混ぜない。
起きた事実以外に推測は混じると共有する情報の質が下がります。情報の質が下がるとそれを受けて判断を見誤ること可能性が高くなります。
前述した「解釈を加えない」に似ていますが、共有している本人は自分が推測を混ぜていることに気づいていないこともあります。そのため、共有の受け手がそのことに気づかなければ、事実と推測が混じった共有を受けてしまう状況になる場合があります。
これに共有している本人が気づくのはなかなか難しく、共有を受けた側が「その情報の出処はどこ?どういう状況なの?」などと質問することで推測が混じっていることを発見できる場合もあります。
まとめ:情報をうまく共有(Share)するための3つのコツ。
1:情報を集めすぎない。
2:解釈を加えない。
3:事実と推測を混ぜない。
この記事もどうですか?
-
キャンバス・マップをまとめてみる(後半)
ギルドワークスの佐々木です。 IT業界に出回っている様々な「 キャンバス 」や「 マップ 」をまとめてみたいと思います。 前半の記事 では◯◯キャンバスについてまとめました。今回は後半として◯◯マップをまとめてみたいと思います。 目次 以下…
-
人の思いをコードの一行一行に仕立てていく。
※注意:この記事は2015年7月10日に GuildWorks Blog で公開したエントリをリライトしたものです。 市谷です。 何気なく気づいたのですが、私たちがやっていることは 事業会社様の事業戦略の立案や実施を仮説検証のアプローチでお…
-
事業アイデア応募でよくある10個のアンチパターン
はじめに Photo credit: RUDEWORKS via VisualHunt.com / CC BY 現在 MVPアワード を開催中です。毎年50以上の応募をいただき、ほぼすべての事業アイデア・事業解説に目を通している中で、いくつ…