NISHIO Hirokazu[Translate]
思考の結節点2024-09-12
サムネイル用



ブロードリスニングの「あの図」勉強会で、初めて複数組織とブロードリスニングの絵を描いて、何か生まれそうな気がしている

会社の内部リソース
今回の話に関係あるかどうかわからないが、以前書こうとして書いてないままになってたトピックを思い出した
「会社には内部リソースがある」ということ
会社に所属したことがない人は観測したことがない
所属しても理解するまでに時間が掛かるかも?
会社はなんらかの内部リソースを持つことによって、市場で不特定の人々による分業が行われるよりも効率良い生産ができるので、競争優位を保ち、存続することができる

自分が情報のハブになって嬉しいことと嬉しくないことがある
情報が集まる
コミュニケーションコストの支払いが増える
キャパシティが溢れると、まあまず「見てもいい」が捨てられる
次に「見てほしい」通知に対するリアクションが省コストになる
Slackのスタンプでリアクションする運用はその一例

両方とも自分が情報のハブ
INとOUTを区別して描くべきかも
これはINだけ描いた



で、出力のコストが10であるときに、2箇所でそれをやって20になる(1)よりは、公開の場に10で出して、それぞれに1で移転する(2)の方が楽
と公開が合理的であるかのように書いたが、そのロジックはおかしいな
これにならない理由が別途必要
たとえば
10の出力が音声のような移転しにくい形式だと後でBに移転できない
Aの中に出力したものが社内文書などの扱いになるとBに移転できない/するときに許諾を取ったりするコストがかかる
(2)と(3)の書かれているコストは同じでも、公開の場に情報を置いておくことによって予期しないリターンがある
たとえば
KJ法勉強会@ロフトワークの時、資料を公開していいかを事前に確認した
ChatGPT記事@情報処理の時、原稿をScrapboxに置いていいか事前に確認した
社内向けのTTTC活用に関して、そのノウハウは公開の場に書こうと思っている

複数組織とブロードリスニングでの「INとOUTを区別して描くべきかも」という気づきを生かすべき
抽象化して流通させる」はINしたものを許諾を取らないでOUTする方法
僕は割と明示的に「これ公開していいですか」「こういう書き方ならどうですか」ってやってる
Meetup with Thomas Hardjonoとか、書いたうちの一部をカットして公開してる



"Engineer's way of creating knowledge" the English version of my book is now available on [Engineer's way of creating knowledge]

(C)NISHIO Hirokazu / Converted from [Scrapbox] at [Edit]