nDiki : 情報共有

情報共有 (information sharing)

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

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 ドライブはオーナーシップと共有範囲のコントロールをできて良いのだが、記事として気軽に見てもらえるような感じではやはりなかった。

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

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

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

式年遷宮的に運用する

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

[ 組織内公開ワーキングノート ] [ 公開で作業する ] [ Top of Mind ノート ]

[ 11月22日全て ]

2021年11月26日 (金)

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

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

目的に対して

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

運用について

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

これから

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

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

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

[ 組織内公開ワーキングノート ] [ 公開で作業する ]

[ 11月26日全て ]

2022年10月13日 (木)

今日のさえずり: おお! ついに Obsidian 1.0 だ!

[ 10月13日全て ]

2022年11月15日 (火)

個人の組織内公開ワーキングノートサイト上で参照資料となったノート

組織内で「公開で作業する」というコンセプトで2月から MkDocs + GitHub Enterprise Server の GitHub Pages で組織内公開ワーキングノートサイトを作って使っている。

Markdown 形式で書いている作業中のノートを気軽に共有できるようになったのはやはり良かったかな。

一方9カ月続ける中で他から何度も参照されるような寿命の長いノートが出てきて、ノートへのたどり着きにくさが課題になってきている気はする。過去にシェアした URL を見つけ出して再閲覧するために記憶に頼るところが大きすぎるなと。

参照資料になったノートはきちんと組織の情報共有ツールの方に移しておくべきというのが正論でありつつ、ほとんどそのままにしちゃうんだよね。

[ 11月15日全て ]

About

Naney Naneymx

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

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

Process Time: 0.025625s / load averages: 0.23, 0.29, 0.31