Tbpgr Blog

Employee Experience Engineer tbpgr(てぃーびー) のブログ

「情報共有してくれない人の思い」をTOCの現状問題構造ツリーと未来構造ツリーで分析してみる

f:id:tbpg:20151213230338j:plain

id:luccafort さんが、私とのTwitterのやりとりをきっかけに素晴らしいエントリを書いてくれました。

luccafort.hatenablog.com

情報共有に後ろ向きな仲間に「なぜ情報共有をしてくれないか?」を直球で質問できて、
しかもアウトプットできる関係を築いているということは
きっと信頼関係が構築されたチームなのだろうな、と思います。

さて、せっかく私の発言に反応する形で良エントリを書いてもらったので、こちらも深掘りしてみたいと思います。

前提

  • この記事を読む前に id:luccafort さんの記事を読んでおく必要があります
  • TOCの現状問題構造ツリーと未来構造ツリーを使います。
    • 現状問題構造ツリー
      • 今抱えている問題を原因と結果の連鎖でツリー化し、そのボトルネックをつきとめます
      • 今回の場合、 id:luccafort さんの記事中の回答内容を元により深めていきます
    • 未来構造ツリー
      • 現状問題構造ツリーの問題点を解決した、改善された状態のツリー
  • id:luccafort さんに追加で質問して情報を得ました。
  • 共有しすぎ問題とかもあると思いますが、その話はややこしくなりそうなので「すればメリットがあるはずだが、
    されていない情報共有」を対象として考えます。
  • id:luccafort さんのケースを元に、私が個人的な経験などをもとに推測で書いた内容なので、
    他の方にはマッチしない部分も多くあると思います。
    情報共有は特に各自が所属する組織のコンテキストに強く依存すると思いますので。

TOC, 現状問題構造ツリー, 未来構造ツリーについてはWebや書籍で色々と情報があるので
詳細を知りたい方はネットの海へ!

現状問題構造ツリー

一般的な情報共有において大事な点として共感・信頼関係などがあるのと思うのですが、
id:luccafort さんのチームはこの点は問題なし、ということで除外して考えます。

f:id:tbpg:20151213230605p:plain

個別の内容については、未来構造ツリーと対比したいので後述します。

未来構造ツリー

f:id:tbpg:20151213230400p:plain

情報共有のコスト

f:id:tbpg:20151213230409j:plain

単純にコストだけを考えると、今まで共有していなかった情報を共有するため割高感がありますが、
あくまで費用対効果として利益(長期的なコスト削減)の部分も加味して考える必要があります。

もしその点を共有できていないなら共有するとよさそうです。
ただ、情報共有の数値的な価値は説明しにくい部分があるので具体例などをベースに
「確かにそれは細かな数値はわからないけど、やったほうがとくだね」
というプラスかマイナスか、というレベルで伝わればいいかな、と思います。

そして情報共有の際の情報の書き方自体を共有、支援するというのもよさそうです。(メタな感じ)
導入者が率先して共有を行うことでフォロワーが真似をしてノウハウを吸収するケースもあるでしょう。

ハードルの高さ

f:id:tbpg:20151213230414j:plain

ハードルが高くて気が引けている、というケースに対しては
WIPの思想、許しの心をもつチームにする、もしくは実はもともとそういった思想のチームである、
ということを認識してもらうことがよさそうです。

※WIPについては esa の赤塚さんが第2回情報会議でLTしたスライドが分かりやすいです。

モチベーション

f:id:tbpg:20151213230419j:plain

情報を残す手間に対して、その効果が曖昧だったり待遇面などの報酬がないことが影響していそうです。

  • 組織の人事評価に情報を共有することを含める
    • 難しいと思いますが可能なら
  • 役だった結果が分かりやすいようにする
    • KPTなどの振り返りで実際に役に立ったか評価する
    • 役に立ったことを知らせる
      • いいね・スター・Thanks!、コメント、対面のお礼など
  • 情報の共有がうまい事自体が市場価値を持っていることを共有する

お礼などについては、普段ネットで助けてもらってるブログ記事やQiitaの記事などもそうですよね。
今の時代インターネットで情報を調べないで開発しているソフトウェア開発者はほとんどいないと思います。
その際に自分を助けてくれた情報に感謝の気持ちを伝えているでしょうか?
感謝を言われる側はかなり嬉しいものです。次のアウトプットの動機にもつながるでしょう。

本来の用法とは違うと思いますが、私は業務中に助けてもらった記事には「はてなブックマーク・スター・Qiitaのストック・ツイッターでの拡散」
など、書き手に感謝が伝わるだろうというリアクションをとるようにしています。

情報の価値

f:id:tbpg:20151213230424j:plain

どの情報が共有する価値があるのか分からないケース。
導入者などがペアプロや雑談時に出た話題のうち共有した方が良い情報がでてきたら、それを伝える。
またそういったことを伝えた事自体を伝える。(ねずみ講的に思想を広げる)

自分の過去の経験や外部から仕入れたエピソードなどでどんな情報が役立つのかを共有する。

まとめ

以上のような個別の要素に共通する根本的な原因(ボトルネック)は何か?というのを考えてみたところ

情報共有の効果と必要なスキルセットが不明確

ということではないか?という結論になりました。
賛否あるとは思いますが。

そして、この点を深掘りして一つ一つ整理しているのが 情報会議 でもあります。
2015/12/13現在3回の情報会議が開催されていますが、開催日以外にも日々継続して
情報共有に関する

  • 事例の共有
  • 事例に関する意見交換
  • 情報共有のスキルまとめ
  • 情報共有のパターンまとめ

など様々な活動が行われています。
これらがある程度まとまってきたら、これらの問題に対する大きな助力となりそうに感じています。

また、情報会議はIncrementsさんのオフィスで開催されていて、第2回にはesaの中の方も参加されていることから
情報共有に関する課題、悩み、ノウハウが共有されるとともにそのツールにも好影響を与えることが想像できます。
第4回の開催日はまだ未定ですが、引き続きその動向に注目です。

外部資料