nDiki : 情報共有
2014年9月19日 (金)
なんで社内 Wiki じゃなくて howm + Markdown ビューアかって?
「(自前の) Markdown ビューアじゃなくて Wiki に……」って言われた。もっとも。できるだけオープンに情報共有された方がハッピーだと常々思っているので、ちょっと耳が痛い。
なぜ Wiki じゃなくて howm + Markdown ビューアなのかの言い訳。 うーん Wiki といいつつ、もはや(ハワイ語的) WikiWiki じゃないからかな。
- Confluence はリッチテキストエディタ中心になってしまったのでもはや wikiwiki じゃない。
- PageName とぱっと考えるの面倒。置く階層を考えなければならないのも面倒。 howm だと日時からファイル名が決まって新規作成なので wikiwiki。
- ブラウザベースだと Emacs でぱっと書けない。コマンドの実行手順とか。tmux でリモートホストで実行した記録をコピーして、そのまま Emacs にペーストしてちょっとメモして完了にしたい。
整理してストックしておくものはきちんと Wiki に書き直すのがもちろんいいんだけれどね……。
2015年1月9日 (金)
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/ より)
2015年5月13日 (水)
レクサー・リサーチ開発同窓会
2月の Developers Summit 2015 で zakwa 氏と再会したのをきっかけに、当時一緒に仕事をしていた気が置けないソフトウェア開発者4人で同窓会をすることになった。セッティングしてくれた zakwa 氏ありがとう!
COGS DINING KAGURAZAKA (コグス ダイニング 神楽坂)
手配してくれたお店は「焼きたてパンとワインのお店」COGS DINING KAGURAZAKA。神楽坂から路地に入ったところにあるお店で、上品な味の料理で満足だった。店内もうるさくなくて話しやすかったし、たばこを吸っている人もいなかったので快適だった。
ソフトウェア開発
現職のまま続けている1人と、別の場所で働くことになった3人だけれどみなそれぞれソフトウェア開発現場に関わっていて、それぞれの開発スタイルなどについて情報交換したり。
大企業だからしっかりした開発をしているとか、スタートアップだからモダンな開発をしているとかでは必ずしも無いよねという話だった。例えばバージョン管理一つにしてもうまくできていない(やっていない)場合も多いとのこと。当時を振り返ってみると小規模かつ独学の状況ながら、今では普通になってきたプラクティスやツールをその時から実践/活用していたなと自画自賛した。
- プロジェクト
- ソフトウェアかんばん
- ITS (影舞・Redmine) の利用
- BTS やコミットメント・リストとして。
- スタンドアップでの朝会
- すごい会議
- 成果物完成毎の記念撮影
- 情報共有
- 開発ツール
- バージョン管理 (CVS・Subversion・Git)
- pLaTeX2e を使ったドキュメンテーション
- その他
- 書けなくなったホワイトボードマーカーはその場で床に投げ捨て
「書けなくなったホワイトボードマーカーはその場で床に投げ捨て」に共感を持ってもらえていたのが、振り返って当時の自分の一番の成果だな。
退職時に使っていた社内 Wiki は Naney 謹製のものだったのでその後どうなったのかなとたまに気になっていたのだけれど、ビル管理会社の人に社内サーバの電源を切られたことによりサーバごと死んで闇に葬られたらしい。R.I.P.
その他
同窓会らしく「あのひとは今」的な話をしたり、当時フィルムカメラで撮っていた業務風景のアルバムを持ってきて盛り上がったり。あとはレーシックやドライアイ治療ひぇー的な話題が出たり。あとは展示会の時のレクサー・リサーチポロシャツ制作秘話とか。
そういえば出席はできなかった2013年2月開催の「LEXER設立20周年記念サロン・パーティ」で会社のるぐるロゴの立体置物が配られたと聞いて、あ、欲しかったなーと。
2015年12月9日 (水)
Slack 分報をやってみる
サービス部の部長がエレベーターで「最近見る Slack チャネルが増えて」と言っているのを聞いたり「自分専用のチャネルを作って分報っていって……」とつぶやいていたりしているのを見て、「分報(ふんほう)」というのが一部で話題になっていることを知りました。社内の Slack を検索してみると既に何人かトライしている様子。
「今やっていること」や「困っていること」その他雑談も含めてチャットで随時投稿しておくことでお互いに早めにフォローしあえるようになるよという趣旨の活動です。このような勧めはイベントの発表トークの中でもたまに出てきたりしていますが、今までと違うなと思ったのは「個人別にチャネルを作ってやる」というところでした。上の紹介記事では各メンバがそれぞれ個人別に Slack チャネルを使う理由の1つに「所有感」を出すというのを挙げていてなるほどなと思いました。
情報共有の縮退が起きないように注意は必要だなとは思っています。逆に、個人的に声をかけたいけれど Slack のダイレクトメッセージだとクローズド過ぎで嫌だなと感じていたやりとりを分報チャネルでやることで共有範囲を広げられる利点もありそうではあります。
面白そうですしなんでもやってみないとということで、さっそく今日から #times_naney を作ってやってみます。
2016年5月23日 (月)
2016年6月10日 (金)
チケット ID でやりとりする
みんなで大小様々なプロジェクト(企画開発やタスク)を同時に進めている場合は、常に全てを頭で把握しておくことは困難ですしまたナンセンスです。その代わりに各プロジェクトの情報を知りたいと思った時には、あちこち探しまわることなくさっと手に入る状態にしておくべきです。
そのためには、まず前提として必要な事柄が書き出されてオープンに情報共有できている状態にある必要があります。
そしてそれらに簡単にたどりつけるようにするために各プロジェクトやタスクに ID (番号やキー)を発行し、チケット/タスクカードやドキュメント、コミットログなどに明記するのが、現実的に一番取扱いやすいです。
JIRA のようなユニークなチケット ID がチケットに発番され、かつそのチケットに permalink のあるチケット管理ツールを中央に据え、その ID を活用することでぐっと情報が共有しやすくなります。ここで ID 形式がさっと人が読んだり手書き・手入力したりできるものであることが大切です。
そういう点で言うと Trello は permalink しかないのでセンターを取れないなと思っています(Trello アーカイブ性も弱いという点もあります)。
2016年7月15日 (金)
できるだけ共有する組織文化になれば良いと思っている
基本「すべての情報を共有する。情報閲覧者が判断する。」(2006年5月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 上に置きたければ記事間の関係がわかるような形で頑張ってリンクを書いていく必要があります。
そのあたり理解した上で導入したり使ったりするといいんじゃないかと思います。
2018年2月19日 (月)
今日のさえずり: 今日は一日中ヘルシェイク矢野のことが頭から離れなくて辛かった
2018年02月19日
- 09:45 「ふりかえりで出したアクションで全てを解決させようと期待しない」確かに。全部一気に解決は無理なことも多いですよね。 / “非スクラムチームに贈る「ふりかえり」の処方箋” http://bit.ly/2sEKOQB
- 17:18 日曜日の朝食にカルディコーヒーファームで買ったパナビの冷凍クロワッサンを焼いたら熱々サクサクで最高だった。また買っておきたい。 http://bit.ly/2FdjHi6
- 17:21 アーバンドック ららぽーと豊洲 PowerShot G9 X Mark II https://t.co/sBnxyY7Spa
- 21:47 はてなでの障害レポートは社内の日記でとのこと。 / “社内障害情報共有のススメ” http://bit.ly/2EDKpDu
- 22:32 今日は一日中ヘルシェイク矢野のことが頭から離れなくて辛かった。 #ヘルシェイク矢野のこと考えてた
- 23:44 晴海で企画開発部合宿をやったの2年前かー。 http://bit.ly/2EOLcAF
About Me
Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。
nDiki は1999年1月に始めたコンピュータ日誌を前身とする Naney の Web 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。
※内容は個人的見解であり所属組織とは関係ありません。
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker