nDiki : 情報共有

今日のさえずり: 紙兎ロペの背景に自宅警備保障って看板がかかってた

2014年07月23日

• 06:52 紙兎ロペの背景に自宅警備保障って看板がかかってた。
• 06:52 ということで、ラジオ体操からの戻り。
• 10:07 「どうせクソコードになるのであれば、とにかく今の理解で出来るかぎり良い物を作る努力をして次に活かした方が良い。」 / “オブジェクト指向やデザインパターンはどんどんやるべき - しーもすと” http://bit.ly/1txv6wj
• 12:23 ミキプルーン。 / “冨田秀雄の設計日記 | 三基商事ビル” http://bit.ly/1wYyVLa
• 13:08 RT @naoya_ito: 情報共有してて、情報が多すぎて全部読めない、みたいな話になったときには、Twitter とか、最初みんなそういってたけど読み飛ばして使うっていうユースケースに人間側が最適化したじゃないですかって話をする。情報がたくさんあること自体は、健全なことであって抑制すべきことではない
• 17:53 本日の定例の議題。 / “CEDEC 2014 AI CHALLENGE” http://bit.ly/1rAdQZF
• 23:45 (global-auto-revert-mode t) にした。

なんで社内 Wiki じゃなくて howm + Markdown ビューアかって?

「(自前の) Markdown ビューアじゃなくて Wiki に……」って言われた。もっとも。できるだけオープンに情報共有された方がハッピーだと常々思っているので、ちょっと耳が痛い。

なぜ Wiki じゃなくて howm + Markdown ビューアなのかの言い訳。 うーん Wiki といいつつ、もはや(ハワイ語的) WikiWiki じゃないからかな。

• Confluence はリッチテキストエディタ中心になってしまったのでもはや wikiwiki じゃない。
• PageName とぱっと考えるの面倒。置く階層を考えなければならないのも面倒。 howm だと日時からファイル名が決まって新規作成なので wikiwiki。
• ブラウザベースだと Emacs でぱっと書けない。コマンドの実行手順とか。tmux でリモートホストで実行した記録をコピーして、そのまま Emacs にペーストしてちょっとメモして完了にしたい。

整理してストックしておくものはきちんと Wiki に書き直すのがもちろんいいんだけれどね……。

Trello をチーム内のちょっとしたタスク共有に導入

遅ればせながら Trello を使ってみた。なるほど Trello はサクサク感があって心地よくていいね。そういえば個人で Remember The Milk を使っていた時も「心地よさ」がとても好きだった*1。

巻き込みやすさ

サインアップからの流れが簡単だし、さくっと organization 作ってさくっとメンバを追加できるのも良い。っていうか Username 空間は1つなのね。 organization にメンバを追加するにはてっきりメールアドレスベースで招待とかしなければならないのかなと思っていたのだけれど、普通に Username でグローバルに検索してさくっと追加できてしまった。

サインアップしてもらって同じ organization・board に参加してもらうまでの敷居が低いので、巻き込みやすいのが良いね。

あとシンプル・直観的で、利用ルールを決めて周知としなくてもホワイトボードとしてすぐ使えるというのも良いところ。変にいろいろ機能があるとこれどうする的な議論になってしまうのだけれどそういうのが不要なのが良い。

個人向けタスク管理ツールにもコラボレーション機能があったりするのだけれど、このあたり各人で好みのツールや使い方があると思うと、押し付けになりそうだし長続きしないんじゃないかと思って使う気にならない。 Trello はそういう点で「ちょっと使ってみようよ」と言える雰囲気がある。

ホワイトボードに徹する

ナレッジベースにはならなさそうなので刹那的なタスク共有・情報共有として使うのが良さそう。ちょっとしたもの以外のプロジェクトのタスク管理は別途 JIRA などの ITS などでチケットを切った方が中期的に良い気がする。そういったものも Trello 上で見える化したければ、Trello のカードからリンクするようにすると良さそう。

Slack との連携

あと Slack なんかでのちょっとしたリクエスト(ちょっとした頼み事)って気軽なのだけれど、双方で個別にトラッキングするのとか脳に負担なので、そういうのを Trello にカードにしておくのが良さそげ。

Trello のアクティビティを Slack に流す連携が簡単にできるので、 Slack 上で「○○お願いします。」っていうより、Trello で「○○をやる」というカードを作ってお願いしたい人をカードに指定した後、その通知が Slack に流れたところで「お願いしますねー。」的な一言いっておくのがスマートそう。

あとは誰かに拾ってほしいタスクなんかもカードとして追加しておいて、とりあえず Slack で自動的に周知しておくというのもできる。

個人で使うのはどうなんだろ

好みの問題ではあるけれど、1人で使うならもっと使いやすいタスク管理ツールいっぱいあると思う。自分の場合 Trello に500個レベルでタスク入力して管理するのとか想像できない。

ということで

Trello 使い始めてみるという話。でToodledo を中心とする「Naney の GTD な1日」というチーム内 LT を今週したらメンバの1人が「Trello 使ってみることにしました。」と言うので自分も試してみたというのが発端。来週あたりからぼちぼちタスクを入れてみる予定。

• https://trello.com/

(画像は https://trello.com/ より)

レクサー・リサーチ開発同窓会

2月の Developers Summit 2015 で zakwa 氏と再会したのをきっかけに、当時一緒に仕事をしていた気が置けないソフトウェア開発者4人で同窓会をすることになった。セッティングしてくれた zakwa 氏ありがとう!

COGS DINING KAGURAZAKA (コグス ダイニング 神楽坂)

手配してくれたお店は「焼きたてパンとワインのお店」COGS DINING KAGURAZAKA。神楽坂から路地に入ったところにあるお店で、上品な味の料理で満足だった。店内もうるさくなくて話しやすかったし、たばこを吸っている人もいなかったので快適だった。

• http://www.cogsdining.com/

ソフトウェア開発

現職のまま続けている1人と、別の場所で働くことになった3人だけれどみなそれぞれソフトウェア開発現場に関わっていて、それぞれの開発スタイルなどについて情報交換したり。

大企業だからしっかりした開発をしているとか、スタートアップだからモダンな開発をしているとかでは必ずしも無いよねという話だった。例えばバージョン管理一つにしてもうまくできていない(やっていない)場合も多いとのこと。当時を振り返ってみると小規模かつ独学の状況ながら、今では普通になってきたプラクティスやツールをその時から実践/活用していたなと自画自賛した。

• プロジェクト
  • ソフトウェアかんばん
  • ITS (影舞・Redmine) の利用
    • BTS やコミットメント・リストとして。
  • スタンドアップでの朝会
  • すごい会議
  • 成果物完成毎の記念撮影
• 情報共有
  • 社内 Wiki
    • 2002年3月初設置。
  • 社内 Blog
    • 2006年あたり(記事)
• 開発ツール
  • バージョン管理 (CVS・Subversion・Git)
  • pLaTeX2e を使ったドキュメンテーション
• その他
  • 書けなくなったホワイトボードマーカーはその場で床に投げ捨て

「書けなくなったホワイトボードマーカーはその場で床に投げ捨て」に共感を持ってもらえていたのが、振り返って当時の自分の一番の成果だな。

退職時に使っていた社内 Wiki は Naney 謹製のものだったのでその後どうなったのかなとたまに気になっていたのだけれど、ビル管理会社の人に社内サーバの電源を切られたことによりサーバごと死んで闇に葬られたらしい。R.I.P.

その他

同窓会らしく「あのひとは今」的な話をしたり、当時フィルムカメラで撮っていた業務風景のアルバムを持ってきて盛り上がったり。あとはレーシックやドライアイ治療ひぇー的な話題が出たり。あとは展示会の時のレクサー・リサーチポロシャツ制作秘話とか。

そういえば出席はできなかった2013年2月開催の「LEXER設立20周年記念サロン・パーティ」で会社のるぐるロゴの立体置物が配られたと聞いて、あ、欲しかったなーと。

Slack 分報をやってみる

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

• 2015年11月11日 Slackで簡単に「日報」ならぬ「分報」をチームで実現する3ステップ 〜 Problemが10分で解決するチャットを作ろう

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

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

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

Year-End Party 2015

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

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

3層 Trello

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

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

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

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

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

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

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

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

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

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

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

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

• mixi日記: すべての情報を共有する。情報閲覧者が判断する。 (2016年7月14日)

---

[ opinion ] [ 情報共有 ]

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 今いる人と今情報共有するための仕組みだから。