nDiki : 情報共有

情報共有 (information sharing)

組織における情報共有のメリット

2015年12月9日 (水)

Slack 分報をやってみる

サービス部の部長がエレベーターで「最近見る Slack チャネルが増えて」と言っているのを聞いたり「自分専用のチャネルを作って分報っていって……」とつぶやいていたりしているのを見て、「分報(ふんほう)」というのが一部で話題になっていることを知りました。社内の Slack検索してみると既に何人かトライしている様子。

「今やっていること」や「困っていること」その他雑談も含めてチャットで随時投稿しておくことでお互いに早めにフォローしあえるようになるよという趣旨の活動です。このような勧めはイベントの発表トークの中でもたまに出てきたりしていますが、今までと違うなと思ったのは「個人別にチャネルを作ってやる」というところでした。上の紹介記事では各メンバがそれぞれ個人別に Slack チャネルを使う理由の1つに「所有感」を出すというのを挙げていてなるほどなと思いました。

情報共有の縮退が起きないように注意は必要だなとは思っています。逆に、個人的に声をかけたいけれど Slack のダイレクトメッセージだとクローズド過ぎで嫌だなと感じていたやりとりを分報チャネルでやることで共有範囲を広げられる利点もありそうではあります。

面白そうですしなんでもやってみないとということで、さっそく今日から #times_naney を作ってやってみます。

[ 12月9日全て ]

2015年12月17日 (木)

Year-End Party 2015

昨日の部の忘年会に引き続き、本日は全社全グループの Year-End Party (YEP) です。そういえば去年は「予告状 あいつらが動き出す!」ということで2015年年1月発足の新しい本部の紹介をしたのでした。振り返るとあっという間の1年ですね。

都電荒川線のアレがだだかぶりだったということが判明してショックだったのが今日のハイライトです。来年はさらに情報共有・連携をしていきたいと痛感した YEP でした。

[ 12月17日全て ]

2016年5月23日 (月)

3層 Trello

軽快なカード UI の Trello は、チームの仕事をぱっと見渡すのに便利なサービスです。

ただ「チームのレイヤー」と「チームリーダー陣のレイヤー」と「またその上のレイヤー」とでそれぞれ Trello チームとボードを作って、仕事の見える化をするのはイケてない感じです。 1つの仕事についてそれぞれのレイヤーの Trello ボードに別々にカードが作られてそれぞれのレイヤーでコメントが書かれていくというのは、情報構造的・情報共有的によろしくないです。

Trello ボードの階層化は避ける、あるいは Trello ではないツールを選択するのが良いのかなと。

[ 5月23日全て ]

2016年6月10日 (金)

チケット ID でやりとりする

みんなで大小様々なプロジェクト(企画開発やタスク)を同時に進めている場合は、常に全てを頭で把握しておくことは困難ですしまたナンセンスです。その代わりに各プロジェクトの情報を知りたいと思った時には、あちこち探しまわることなくさっと手に入る状態にしておくべきです。

そのためには、まず前提として必要な事柄が書き出されてオープンに情報共有できている状態にある必要があります。

そしてそれらに簡単にたどりつけるようにするために各プロジェクトやタスクに ID (番号やキー)を発行し、チケット/タスクカードやドキュメント、コミットログなどに明記するのが、現実的に一番取扱いやすいです。

JIRA のようなユニークなチケット ID がチケットに発番され、かつそのチケットに permalink のあるチケット管理ツールを中央に据え、その ID を活用することでぐっと情報が共有しやすくなります。ここで ID 形式がさっと人が読んだり手書き・手入力したりできるものであることが大切です。

そういう点で言うと Trello は permalink しかないのでセンターを取れないなと思っています(Trello アーカイブ性も弱いという点もあります)。

[ 6月10日全て ]

2016年7月15日 (金)

できるだけ共有する組織文化になれば良いと思っている

基本「すべての情報を共有する。情報閲覧者が判断する。」(2006年5月15日)という方針が良いとずっと思っております。責任者だけが知っていれば良いとか、チーム内だけでわかっていれば良いとか、そういうのはちょっとどうかなという派です。

もちろん共有範囲を限定すべきものはすべきとして、それ以外はできるだけ共有する組織文化になれば良いと思っていますのでよろしくお願いいたします。


[ opinion ] [ 情報共有 ]

[ 7月15日全て ]

2016年9月28日 (水)

Qiita:Team をドキュメントシステムとして使うには相当頑張らなければならない

Qiita:Team はドキュメント群を階層構造化する機能を提供しないので、プロジェクトのドキュメントシステムとして使うには書き手・読み手双方が相当頑張らなければなりません。特に1つの Qiita:Team で扱うプロジェクト数が多いと顕著です。

Qiita:Team は今いる人と、今情報共有するためのツール

Qiita:Team は今いる人と、今情報共有するためのツールを志向しています。

投稿した記事はフィードに共有されます。階層構造やカテゴリーなどの面倒な管理は不要です。 — https://teams.qiita.com/features

あとから記事を探しやすい仕組みを用意しています。整理することを考えなくてよいので書くことだけに集中できます。 — https://teams.qiita.com/features

ということで整理しないで使うことを想定したものなんですよね。みんな大好き Markdown 系シンタックスで簡単に書けるので、フロー型の情報共有システムとしてはいいと思います。

プロジェクトのためのドキュメントシステムではない

ただし「後からプロジェクトにかかわることになった人が全体像をさっと把握できる」ように整理されたドキュメントを作れるようにはなっていません。検索できれば大丈夫という話ではないので、整理されたドキュメント群を Qiita:Team 上に置きたければ記事間の関係がわかるような形で頑張ってリンクを書いていく必要があります。

そのあたり理解した上で導入したり使ったりするといいんじゃないかと思います。

今日のさえずり: iA Writer のタスクリスト機能がプチ使えそうだ

2016年09月28日

  • 12:48 朗報 「ディズニーワールドのビッグサンダーマウンテンに数回乗ったら腎結石が3個出てきた」 / “腎臓結石排出にジェットコースターが効果アリ。特に後部車両が効果的との研究結果 - Engadget Japanese” http://engt.co/2dpLeDi
  • 24:49 iA Writer のタスクリスト機能がプチ使えそうだ。
  • 25:13 Qiita:Team はドキュメント群を階層構造化する機能を提供しないので、プロジェクトのドキュメントシステムとして使うには書き手・読み手双方が相当頑張らなければならぬ。
  • 25:18 今いる人と今情報共有するための仕組みだから。
[ 9月28日全て ]

2018年2月19日 (月)

今日のさえずり: 今日は一日中ヘルシェイク矢野のことが頭から離れなくて辛かった

2018年02月19日

[ 2月19日全て ]

2020年8月25日 (火)

重要な情報を共有することで信頼を伝える

先週8月19日(水)に『社員の力で最高のチームをつくる〈新版〉1分間エンパワーメント』を買って読んでいる。

エンパワーメントの「第1の鍵」として

全社員と正確な情報を共有すること。 (Share accurate information with everyone.)

が挙げられている。

情報を制限するということ自体が、いろいろなメッセージを相手に伝えてしまうのです。(中略)裏を返せば、重要な情報を共有することは、相手を信頼していることを伝えるいちばんの方法ということになります。

というくだりでガツンとやられた。「情報の価値」の観点で情報共有することの重要性はずっと意識してきたけれど「信頼を伝える」の観点ではほとんど考えたことが無かった。

折しも「最近上司からの情報共有が増えているな」と感じるのと同時に「以前より信頼されてきているかも」と思っていたところだったので、とても納得だ。

ふりかえってみると今の役職になってから情報共有に用心深くなってしまっている自分に気がついて反省。

あらためて情報共有を意識していこう。

[ 読書ノート ] [ 行動原則 ] [ Naney の行動原則 ]

[ 8月25日全て ]

2021年11月22日 (月)

ワーキングノートを部門の情報共有ツールに書いてみる

公開で作業する」を実現するため、部門で使っている Qiita Team 上にワーキングノートを投稿してみることにした。ドキュメントとして残すのが目的ではなく、コミュニケーションの補完として個人の作業ノートを見えるようにしておくのが目的だ。

次のような運用にするつもり。やってみてアレンジする。

  • 月曜日にワーキングノートを新規作成する。その週はそのノートを更新する。
  • ローカルの Obsidian で元となるノートを新規作成・更新し、1日1度以上目安で Qiita Team の記事を更新する。
  • 以下のような事を書く。
    • Top of Mind
    • 気がついたこと
    • 取り組んでいること
    • その他なんでも
  • 翌々週に削除する。

Google ドライブでの共有はうまくいかなかった

今まで Markdown で書いているノートを Google ドライブで共有する (Markdown ファイルのままだったり Google ドキュメント化してだったり) のを試みたけれど続かなかった。 Google ドライブはオーナーシップと共有範囲のコントロールをできて良いのだが、記事として気軽に見てもらえるような感じではやはりなかった。

ワーキングノートだけに絞る

Obsidian Publish とは違い Qiita Team は記事をローカルファイルと同期できないので、複数のノートを公開・更新していくのは現実的ではない。1つのワーキングノートだけに絞り反映させることにした。

1つのノートを更新していく方法だと変更点が分かりづらいので、だんだん読まれなくなってしまう懸念はあり。

式年遷宮的に運用する

永続的に残ると思うとリンク先の永続性とか気になりだしてしまって更新するのが億劫になる。あくまで作業ノートとして最新のスナップショットだけ共有したい。1つの Qiita Team 記事を更新していくのがシンプルなんだけれど、古い編集履歴を消す機能が無いので1週単位で新しくしてみることにする。

[ 11月22日全て ]

2021年11月26日 (金)

ワーキングノートを部門の情報共有ツールに書いてみた

月曜日に部門の情報共有ツール (Qiita Team) にワーキングノートを新規作成し、その週はそのノートを更新するというのを今週やってみた。

目的に対して

  • コミュニケーションの補完という目的をどれぐらい果たせているかはまだ不明(1人から公開初日に良い取り組みだというフィードバックはいただけた)。
  • ワーキングノートの共有だけだと「公開で作業する」感はちょっと低め。

運用について

  • 毎日1回以上更新は継続できた。
  • ローカルのデイリーノートと今回の共有用ワーキングノートの2本立てで書き分けるのに、フリクションが発生する。
  • 共有期間を終えたあとのローカルでのアーカイブをどうするかまだ見えていない。

これから

共有するかどうかとは別に、そもそもデイリーノートとワーキングノートを分けない方がいいという気持ちになった。知的作業空間としてはデイリーノート一本化に戻す。作業中に共有・非共有の判断にエネルギーを割かないようにする。

コミュニケーションの補完という目的では、雑感記事をデイリーで情報共有ツールに書いていくのが良さそうだ。

結局行き着くところは Web 日記 (社内 Blog)か。

[ 11月26日全て ]

About Me

Naney Naney

Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。

About nDiki

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。

#nNote タグがついている記事は他の記事に比べて、より断片的・未整理・不完全なちょっとしたノートです。まだ結論に至っていない考えなども含まれます。頻繁/大幅に更新したり削除したりすることがあります。

※本サイトの内容は個人的見解であり所属組織とは関係ありません。

最近検索されている記事

Other Notes

ナレッジベースアプリケーション Obsidian で書いているノートの一部を notes.naney.org で 公開しています。

notes.naney.org 新着ノート

月別インデックス
Process Time: 0.059516s / load averages: 0.92, 0.68, 0.75
nDiki by WATANABE Yoshimasa (Naney)
Powered by DiKicker