「 リモート開発におけるチームワークの向上 」を読んで思った。私は社内SNSがコミュニケーションを促進っていうのは、もはや素で1:1のコミュニケーションを全員と行うのが難しいような規模になって初めて出てくる側面かなと思って、あまり注目してなかったのね。いまのところ、うちの会社には必要ないかな、と。でも、リモート環境っていうのが確かにあるよなー。それに、新入社員に対して、在職者の顔が見えやすくていいなーと。
私はアナログ人間だし、お昼に音楽話をしたりお菓子を買ってきたりというのを重視するから、リモートでの業務を推奨はしたくないけれど、でもローカル/リモートを問わず、SNSを中心に据えることによる士気の向上はあるに違いない。と、ようやく理解した。
で、以下のように社内インフラ次期整備案を考えてみた。
整備案
SNSを構築
情報をSNSに集約
- コミットログ
- 継続ビルドサーバーのレポート
- バグトラッキングシステムと結合できるとうれしいんだが。
SNSへのフロントエンドは自由とする。
- GmailでもLivedoor ReaderでもMSN Messengerでも伺かでも携帯電話でも好きな端末を使えば良い
- HTML/HTTP, RSS/HTTP, IMAP4(?)、NNTP(?), SSTP(?),... 好きなやりかたでアクセスして良い
- Plaggerサーバーを立てて基本的な選択肢はサポートしておく
メーリングリスト + Wiki + RSS Feeds + Blog + バージョン管理システム + バグトラッキングシステム + 継続的ビルド + Taggingみたいな。もう、何でもありだね。
OpenPNEとかTracとかqwikWebとかPlaggerとか、部分部分を実現してくれるものはあるけれど、全部を叶えてくれるものは知らないなぁ。しかも、それぞれが微妙に重なってたりして。しかも、全部実装言語が違ったりして。
バグ/日記/トピック/共有文書を区別せずに単なる項目として扱うならまさに「それPla(ry 」なんだけど、これらは役割が別だしなぁ。
アクセス方法についてはPlaggerがかなり吸収してくれる上、その他、プロトコル変換ラッパーはいくらでもあるし、RSSがAtomをベースにすれば結構なんとかなるか。バージョン管理システムはSubversionで。
プロジェクトごとのメーリングリストっていうのが従来型の階層的、博物学的管理法だとしたら、タグ付けに基づくメール共有システムがあってしかるべきなんだよなー。はてなブックマークみたいなタグ表記法を用いてlocal partに書けばいいのか。そういうメーリングリストシステムはあるかな。無かったら書くか。
製品をどう組み合わせて、間を埋めるかが問題か。TracにqwikWebを移植はいずれするつもりだったけれど、計画修正が必要かな。Railsを使ったSNSツールを漁って、良さそうなやつにメールベースのインターフェースとチケット管理機能を付けるのがお手軽かなぁ。週末1回でできそうだが、今はちょっと、先にやっちゃいたい秘密の開発があったりして。
追記
ちょっと待て。「バグ/日記/トピック/共有文書を区別」っていうのは随分博物学的な、強迫的分類思想じゃないのか。どうせ、システムの種類を越える時点でこれらのログの性質はある程度均質化する。表示する時点では何か一種類の形式にせざるを得ない訳だ。あくまでも人間が識別できて、それから、バックグラウンドに各々固有の性質を持った本体が存在できれば良い。
じゃあ、それぞれの対象物は各々、既存の専用システムに管理を任せて、システム間のやりとりはPlaggerに集約して、あとはタグで区別すればいいじゃないか。日記/トピック管理はSNSに任せるとして、バグや共有文書の変更をリストする時点では単に[バグ]タグや[共有文書変更]タグが付いていて、あとはBTSの該当ページへリンクしてればいいよね。これなら、それPla(ry
そうすると、あとは必要なのは、
- タグと、それに関連するメンバー、システムを管理するディレクトリサービス
ディレクトリに基づいて、メールやMSN Messengerのような個人に属するメディアへ情報をDispatchするフィルター
スケーラビリティを考えると、メーリングリストのTagging版に相当するもの(仮称: Tagged ML)を作った方が良いのかも。つーか、これはこれで欲しいから、探す。無かったら作る。
でも、それはパフォーマンス上の最適化の問題であって、本質的にはメーリングリストとはPlaggerのサブセットに過ぎないのだなぁ。
