nDiki : 情報共有

社内 Blog アウトプット主義 社内 Wiki メール ソフトウェア ナレッジベース インストール HTML ビジネスメール メモ 革 Word 検索 企業情報ポータル RSS 電子メール 書き出す データベース ガイドライン 意思決定 Web 暗黙知 WikiEngine 日本語 朝会 書評 DiKicker URL URI reStructuredText

■ 会社にも Wiki

社内での情報共有用に Web ページを作ってあったんだけど*1、メンテが面倒でずっとほったらかしだった。 最近 Wiki カブレしているので、これを機に WikiEngine をセットアップし移行。

以前も実験的にプロジェクトで使ってみたけど、その時はあまり活用できなかった。 今回はもうちょっと繁盛させたいところ。

• ケータイ用にプライベート Wiki を設置 (2008-01-07)
• [ WiKicker ] WiKicker へ脚注機能追加 (2004-02-10)
• Wiki考 (2002-09-20)
• 最近の Twitter ステータスを nDiki 「最近のさえずり」ページ... (2007-11-23)
• Wikiの文法の標準化 (2004-02-10)

■ 早朝会議革命 - 元気企業トリンプの「即断即決」経営

トリンプの吉越浩一郎社長による「会議を通したスピード経営」についてを、会議出席や社員へのインタビューを通して著者がまとめあげた1冊。

会議を中心とした内容であるが、「すごい会議」と同様ただ単に会議手法を述べた本ではない。 会議を通した経営についてが述べられている。

同社のMS会議 (Marketing and Sales 会議) は吉越社長が自部門の改革として始め、粘り強く改善・継続して全社的なものになったもので、そう簡単に真似ることができるものではないが、そのエッセンスには学ぶものが多い。

@ 朝開催

• 多くの人間が集まる時間帯。
• 集中できる時間。
• 同日に即行動に移せる。

特に最後のは魅力的。やる気がみなぎっている間に行動に移せる。 しかし、自分はオフピーク通勤が気にいっているからなぁ……。

@ 毎朝開催

当然週1回よりスピードがある。

回数は多いが、きちんと問題について意思決定しコミットメントに落としていくので無駄がない。

@ トップダウン

ただし民主的、フラット。

@ 「決める」会議

• 「誰が、何を、いつまでに」

ここら辺はすごい会議と通じる。

@ デッドライン

• ドイツ系の会社から。
• 厳しく。でないとみんな逃げる。
• 最大限で1週間。それ以上はスケジュール化。
• 稚拙でもいいから速く。

毎朝会議が開催され議論されることで、1週間でまわしていける。

@ プレゼンテーション

• プレゼンテーション自体を目的にしない。無駄に準備に時間をかけない。

@ コミュニケーションの場・情報共有の場

• 「和」を形成。
• 共通認識が広がる。
• 判断・決断までのプロセスを共有。プロセスから参加することに意味がある。
  • 意思決定に変化があっても理解できる。
  • 教育の場
    • 技は盗むもの。「教育なんてほんとはできっこない」。
• オープン、フェアネス。

見習いたい。 どのようにすれば我社で判断・決断プロセスから共有していけるようになるだろうか。

@ 継続

• 継続はトップの責任
• 改善こそ継続の母
• 成功するまでやれば、成功する。p.207

@ 結論から言え

• 言いにくくても、結論から言え。p.207

@ 感想

「決める会議」、「誰が、何を、いつまでに」という方針のメリットを再確認。

• 早朝会議革命 - 元気企業トリンプの「即断即決」経営

[ 書評 ] [ お薦めの本 ]

• 一緒に仕事をしたい人のタイプ (2006-03-17)
• すごい会議の正しい手順 (2005-07-04)
• すごい考え方 (2005-12-10)
• すごくない会議 (2005-06-29)
• トム・デマルコ ゆとりの法則 - 誰も書かなかったプロジェクト管理の誤解 (2004-04-17)

■ メールによる社内コミュニケーションの問題

以前から何度も議題になる(けれども改善されない/しない)問題として、本社/東京オフィス間のコミュニケーション問題がある。 うまく情報共有ができていなかったり、共通認識になっていない背景にもとづいてのコミュニケーションによってうまく意思が伝わっていなかったりするという問題である。 特に電子メールによるコミュニケーションに多発気味のようである。

しかしなにもこれは本社/東京オフィス間だけの問題ではない。 電子メールをその特性を意識せずに使用することによって、コミュニケーションしていると思いながらも「実は一方通行」でしかなかったり、あるいは「その一方通行さえうまくできていな」かったりすることがままあるのである(もちろん自分も含めて)。

そこでまずは電子メールを含むコミュニケーションツールの利用方法について検討し、ガイドラインを決めていこうということになった。 もちろんガイドラインはシンプルかつ効果的なものにしたい。

まずは電子メールについて現状としての雑感を(特に自分の場合について)。

@ メーリングリスト

「ま、返事しなくてもいっか」と思わせるメールの筆頭は、メーリングリスト宛のもの。 以下のものは無視してしまう(あるいは先送りしているうちに忘れてしまう)事が多いタイプ。

• 宛先不明のもの/「○○各位」宛のもの
  • 10人が参加しているメーリングリストでは、送信者から届くパワーは通常のメールの1/10以下である。
• 「ご意見があればお願いします」
  • (誰かが意見するだろう)
• 「ご意見があればお願いします」
  • (メーリングリストに? 個人宛に? まいっか)
• 「どちらが良いと思いますか?」
  • (メールを出した貴方はどう思っているの?)
• 誰か一人(か二人)がメーリングリストに返事した
  • (話が進んでしまっているようだし、出遅れたな。もういっか)

@ 「ご検討ください」

「検討しなければならないなぁ(そのうち)」->「しばらくたっちゃたなぁ」->(リファイル)

@ 「ご意見ください」

「意見を考えなければならないなぁ」->「しばらくたっちゃたなぁ」->(リファイル)

@ 「○○してください」

○○した -> (完了報告なし) -> (リファイル)

@ 「した方が良いと思います」

(そうですね) -> (リファイル)

@ 形式的な不備

• 無関係なメールへの返信によって作成された新規メール
  • (一応読むけど)
• 何を言いたいのかよくわからないメール
  • (ぱっと見るけど)
• typo
  • (人間誤ちがあるからあまり咎めはしないけれど、それに気をとられて本文に対する集中度ダウン)
• (いわゆる)全角文字と半角文字が混在
  • 内容の評価までダウン
• 文章に句読点が無い
  • (日本語?)
  • 適当にメールを送ってきている? ではこっちも。
• 長～～～～い全文引用(の全文引用の全文引用の……)
  • で、本文は2行ですか?

@ 添付資料が MS Word 形式

「○○について問題があればご指摘ください」-> 読めん (Mew が wvHtml で変換して表示してくれるからちょびっとだけ見るけれど)。

@ 添付資料が MS Excel 形式

「○○について問題があればご指摘ください」-> 読めん (Mew が xlhtml で変換して表示してくれるからちょびっとだけ見るけれど)。

@ 予定の日時を間違えている

ヤバ。間違える(自分)。送信前に読み返しても、なぜか気がつかない。

@ 内容がムカつく

まぁそういう場合もあるので、差し引いて読まないといかん。

@ 時候の挨拶つき

いいね! 非常にいい。ほっとする。嬉しい。いい気分。

自分ではほとんど書かないんだけれど。

@ 結局のところ

「誰に」「何を」「いつまでに」「どの品質で」して欲しいのかが不明確というのが問題の大部分を占めていると思う。 会話におけるリクエストでもこれを明確にできていないのだから、メールではなおさらな状態である。

逆に言うとこれらがはっきりしていて約束がかわされたならば、、添付ファイルフォーマットの問題などは些細な問題で(いや、面倒ではあるけれども)、相応に努力してしかるべきアクションをとっていくであろう。

それから、リクエストメールに対してはどうするにせよ「受ける」「断わる」「別の提案をする」というレスポンスをリクエストした者に返すべきだけれど、メールだとこれがないがしろになってしまう事も多い。 これも大きな課題であるな。

まずは、メッセージのタイプ(指示/命令? リクエスト? 情報? ……)を分析して、どのようにすれば効果的なコミュニケーションがなされるようになるか検討してみよう。

• 研究結果「メールの意図が正しく伝わる確率は5割」
• 各種コミュニケーション・ツールの強みと弱み － 1/2 － ＠IT情報マネジメント

[ ビジネスメール ]

• ビジネスメールガイドライン案 (2006-05-05)
• 日本語ファイル名どんとこい (2005-03-07)
• Linux 母艦ノート PC を使わずに仕事ができるかチャレンジ (2007-08-20)
• GnuPG の布教失敗 (2005-02-02)
• [ Java ] Unicode (UCS) -> 別の charset (2003-12-12)

■ ビジネスメールガイドライン案

以前メールによる社内コミュニケーションの問題について書いて以来、いろいろと考えてみている。

そんな中、東洋経済新報社の「Think! SPRING 2006 No.17 超ロジカルシンキング」の中に参考になる記事を発見。 照屋華子氏の「ロジカル・ライティング - 論理的に考え、伝えるための3つの鍵を身につける」という記事だ。

すべてのビジネス・コミュニケーションは「伝え手」「受け手」「テーマ」「答え」「期待する反応」という5つの基本要素で成り立っている。-- Think! SPRING 2006 No.17 p.43

おお、ちょうどこういう切り口を探していたところだったんだ。 電子メールによるコミュニケーションも全く同じ枠組みである。 記事の中ではロジカル・シンキングをコミュニケーションで生かすという話題を中心に展開しているが、十分メールの書き方に通じるものがある。

この記事と、さらにちょっと前に買った「SEの実力を磨く究極仕事術」のメール術の章を参考にガイドライン案のスケルトンを作ってみた。

感情論は今回は置いておいて、情報共有・課題共有・リクエストの明確化・処理促進をポイントに列挙。 それから署名その他、一般的な話もいまのところ省略。

ポイントを列挙しただけなので、他人にもわかる形にはなっていない。

まずは自分自身に適用して、整理していってみることにする。

@ 1. 考える

• 【伝え手】伝え手は誰? (自分)
• 【受け手】受け手は誰?
• 【テーマ】テーマは何? 問いの形で。メールのテーマは1つに絞られているか?
• 【答え】 テーマに対する答え(テーマに対する説明)は何?
• 【期待する反応】受け手に期待する反応は何?
  • 誰に、いつまでに、何をどうして欲しい?
• コミュニケーション手段としてメールは適切?

@ 2. メールを書く

 ○○様へ                     # 受け手

 △△の××(自分)です。       # 伝え手

 テーマ
 ******
 コミュニケーション設定

 ○○の結論                   # 答え (結論)
 ==========
 ...

 (ここまででポイントを言いきる。)

 具体的な内容                 # 答え (詳細)
 ============

 項目1
 -----
 ....

 - リスト項目
 - リスト項目

 項目2
 -----
 ...

 - リスト項目
 - リスト項目

@ サブジェクトを書く

• 見ただけでわかるようにする
  • □ 具体的に書く

@ 導入部を書く

コミュニケーション設定を行う。

• □ 冒頭に宛先【受け手】を明記する。(誰に読んで欲しいのか? 他に誰に送られているのか?)
• □ 次に発信者【伝え手】を明記する。(From: フィールドに頼らず書く → 印刷・コピー用)
• □ 【テーマ】を書く。
• □ (オプション)【テーマ】の経緯・背景を書く。(「なぜこのテーマのメールがくるの?」)
• □ (オプション)なぜこの【伝え手】からなのかを書く。(←「なぜあなたからリクエストされるの?」)
• □ 【期待する反応】を明記する。
  • □ 「誰が」「何を」「いつまでに」「どのような品質で」して欲しいのかを書く? (← 「で何をして欲しいの?」)
  • □ 反応のメリットを書く (←「なぜこの反応をとらなければならないの?」)
  • NG 「ご意見があればお願いします」 → ない場合は?
  • NG 「どちらが良いと思いますか?」 → 意見として? 決定として?
  • NG 「ご検討ください」→ 検討した後どうして欲しいのか?
• □ (オプション)なぜこの【受け手】に読んでもらいたいのかを書く (←「何で自分なの?」)
• □ 特記事項があれば書く
  • □ 答えの情報源など

@ 答え (結論)

結論を書く。

• □ 詳細まで読まなくても済むようにする。
  • NG 「以下のように……」 → 要旨を書く
  • NG 「添付ファイルの通り」 → 要旨を書く

@ 答え (詳細)

根拠・資料などを書く。

• □ 受け手から見て必要十分な情報を書く
  • NG 「添付ファイルの通り」 → 要旨を書く
• □ 受け手が読みやすいように書く
  • □ リスト化する

@ 全般

• □ 具体的に
  • NG 「来週までに……」 → 「×月×日までに……」
  • NG 「先日の……」 → 「×月×日の……」
  • NG 「この間の……」 → 「×月×日の……」
  • 説明は肯定形で書く (否定形だと具体的に何なのかわからない)
• □ 論理的に
  • □ 構造化する
  • □ リスト化する (箇条書き化する)
• □ 受け手が読みやすいように
  • □ フォーマットを工夫する (ソフトウェア技術者間なら reStructuredText がお薦め)

@ 3. 送信する

• □ 送信する前に見直す
  • □ typo チェック
  • □ スペルチェッカ通す

@ A. メールを受信した時

@ まず返信する

どれか

• リクエストを「受ける」 / 返信で処理する (意思決定を返すなど)
• リクエストを「断わる」
• 「別の提案をする」
• 明確化の質問をする

メールでは不適当と思ったらコミュニケーション手段を 直接 / 電話に切り換える。

@ B. 返信する時

@ サブジェクト

• □ テーマが変わったら書き換える

• メールによる社内コミュニケーションの問題 (2006-04-12)
• 定型書式で内容を記述していくのに便利な形式は? (2005-11-21)
• 「プロジェクトマネジメント」はどうやって勉強すれば良いですか? (2006-11-22)
• ソフトウェア技術者御用達のプロジェクトマネジメントツール TaskJuggler (2007-04-23)
• ソフトウェアかんばん「見えない化」 (2006-04-10)

■ すべての情報を共有する。情報閲覧者が判断する。

帰りの東北新幹線で、ウェブ進化論の続きを読む。 興味を持ったのはこれ。

シルバースタインは「こうした情報共有の仕組みをテクノロジーが支える」と語ったが、グーグルの社内情報システムはごく普通のシステムの組み合わせだ。ごく普通のブログや掲示板、社員全員が同じ文章を自由に編集できるウィキ (Wiki) と呼ばれる共同作業用環境、検索エンジンといったものの組み合わせである。-- ウェブ進化論 p.86

社内に Wiki を立てて、周囲を巻き込みつつ情報共有のため基盤と文化を育てようとしている自分にとって「ごく普通のシステムの組み合わせだ。」というのは心強い話である。

本書ではさらに、下記のように続く。

道具自身に革新性があるのではなく、すべての情報を共有することを原則に「情報自身の淘汰に委ねるという思想のほうに革新性があるのだ。 -- ウェブ進化論 p.86

はてなの近藤氏も2005年7月27日の記事で同様のことを述べている。

ここで大事なのは、「その情報を出すべきかどうか」を情報発信者が判断するのではなく、全ての情報を出しておいて、情報閲覧者が「その情報を読むべきかどうか」を判断すればよい、と考えることです。-- CNET Japan Blog - 近藤淳也の新ネットコミュニティ論：情報の私物化を禁止する

効果的にコラボレーションをして成果を上げていくにはメンバが、積極的に情報をアウトプットし共有していくことが重要である。

しかしながら情報のアウトプットというのはなかなか実行されないものである。 理由はなんだろう。

1. 情報共有/活用基盤がない。
2. 情報を共有するという文化がない。
3. 情報をアウトプットするコストが高い / 高いと感じる。
4. 情報をアウトプットするメリットを理解できない / 感じられない。
5. 情報を制限することで権限を維持したいから。

あたりか。

Wiki の次の一手として社内 Blog を立ち上げることにしよう。

[ アウトプット主義 ] [ 書評 ]

• 社内 Blog 開設 (2006-05-16)
• 私が情報発信を勧める理由 (2006-07-26)
• Hyper Estraier で社内 Web コンテンツ検索 (2006-06-01)
• Debian GNU/Linux に Hyper Estraier 1.2... (2006-05-31)
• 新幹線でウェブ進化論を読み終えた (2006-05-25)

■ Google Desktop の web clips で RSS を読む

社内での情報共有を目的に社内 Blog を立ち上げた。次のステップは以下だ。

• スタッフが定期的に社内 Blog をチェックする/したくなるようにもっていく。

読んでもらえなければ Blog を書くメリットがあまりなくなってしまうので、これは重要だ。 逆に良さがわかってくれば、自分も書こうという人が自然ど増えてくるはず。

まわりを見た感じだと、普段から RSS リーダを使っているというという人はほとんどいないようなので、まずは RSS リーダを普及させる必要がありそうだ。

うちのオフィスでの推奨 RSS リーダの条件としては

• Windows で動くこと。
• わざわざソフトを立ち上げてチェックというスタイルだと定着しなさそうなので、常駐型がいいのではないか。
• 特定の Web ブラウザへの組み込み型ではないこと (人によって使っている Web ブラウザが違ったりするので、推奨しにくい)。

あたりかなと。むろん個人で気にいったのがあればそれにこしたことはないのだが、ここでは初めての人に薦められるものをということで。

@ Google デスクトップ 3

まずは Google Desktop を試してみる (Windows をメインに使っていなかったため、今までインストールしたことがなかった)。

ウェブ クリップで RSS/Atom フィードを読むことができる。

感蝕は「まあまあ」。 他の機能も含めて使っている場合はいいかもしれないが、巡回用の RSS リーダとして使うにはそれほど良いというほどでもないな。

フィードの表示順がちょっとわかりにくいのと、フィードの URI を誤認するのがマイナスポイント。

• Debian に RSS リーダ「フレッシュリーダー」をインストール (2006-03-06)
• Google Desktop Linux 版をインストール (2007-07-02)
• 今日のさえずり - 勢いあまって NCSA Mosaic 3.0 for ... (2007-11-08)
• Linux で使えるデスクトップ検索ツール Beagle でローカルファイ... (2006-08-08)
• ホームネットワークカメラ BL-C10 買っちゃった (2005-01-18)

■ Rubric でプライベート SBS を立てるも 0.140 では日本語に不具合

入社してから社内情報共有の一環として

• Wiki (WiKicker)
• ML アーカイブ公開 (MHonArc)
• 検索システム (Hyper Estraier)
• 社内 Blog (DiKicker)

といろいろ手をつけてきた。 次に狙っているのは SBS である。

Wiki や社内 Blog に書くほどではないけれどメモ程度にブックマークしておきたい URL を、気軽に晒せるようにするのが目的。

はてなブックマークのような公開サービスは

• タグ・コメント・傾向などが外に出るのはよろしくない
• あるいは、それを気にして活用されない
• そもそも社内リソースについてはブックマークできない

という点から、今回は利用できない。

ということで社内に SBS を設置したい考えている。

最初は Scuttle にしてみようと思ったのだが、PHP ベースであるのと MySQL を使うというところで気遅れしている。 いや SQLite でもいけそうらしいということで、実は Debian でちょっと試そうとしたのだが、テーブル作成の SQL が MySQL 用で、これを修正するのが面倒なので断念。

次に Perl + SQLite で動く Rubric を試してみることにした。

@ Rubric 0.140

Rubric は CPAN にあがっているので CPAN.pm から install Rubric でインストールできる。 モジュールをインストールしたら、セットアップ。

1. CGI プログラムを動かすディレクトリを決める (以下 $RUBRIC)
2. Rubric tarball の bin/rubric.cgi を $RUBRIC/ にコピーし、必要なら #! を修正する。
3. Rubric tarball の templates ディレクトリを $RUBRIC/ にコピーする。
4. Rubric tarball の style/rubric.css を $RUBRIC/ にコピーする。
5. Rubric tarball の etc/rubric.yml を $RUBRIC/ にコピーして環境に合わせて編集する。
6. データベースを初期化する。0.140 には makedb.pl が同梱されていないので、0.13_01 の bin/makedb.pl を参考に perl -MRubric::DBI::Setup -e 'Rubric::DBI::Setup->setup_tables' で初期化する。ちなみに 0.140 付属の rubric コマンドで rubric db -s してみたが、これはうまく動かなかった。
7. 必要に応じて .htaccess を作成・編集し rubric.cgi を CGI プログラムとして実行できるようにする。またその他アクセスされたくないファイルを deny するようにしておく。

これで OK。

rubric.cgi にアクセスしページが表示されればひとまず成功。 メニューの「register」から、ユーザ登録する。 確認用のメールが届くはずだが、面倒くさいのでこれを待たずに

 rubric user -a ユーザ名

でアクティベートする。

Rubric の HTML フォームからのブックマーキングは成功し、うまく動いているようである。 ただし、日本語の処理はどうもよくない。 title や description が化ける。 惜しい。

基本的には UTF-8 ベースでうまくいきそうなのだが、どこかで化けるようだ。 ちょっと手を入れれば直るかなと思ったが、化けるところと化けないところとがあるので逆に直す場所が多そうなので今日はやめておくことにした。

とりあえず Rubric はおいておいて、他のものも試してみることにするか。

• Debian GNU/Linux に Hyper Estraier 1.2... (2006-05-31)
• Hyper Estraier で社内 Web コンテンツ検索 (2006-06-01)
• DiKicker の出力する HTML コードを小さく (2006-10-05)
• WiKicker に JSON でのページ出力機能を追加 (2007-04-03)
• Linux で使えるデスクトップ検索ツール Beagle でローカルファイ... (2006-08-08)

■ 「他のプロジェクトへの関心が薄い」組織内における情報共有

組織内で情報共有がうまくできていない場合の理由として、「仕組みがない」か「仕組みがあっても周知されていない・使い方がわからない」か「使いにくい/手間、メリットが感じられない」ということが多いと考えてみた。

確認もかねて、「社内で情報共有についてできていないと感じる場合のその理由」について、ミーティングで聞いてみたところ自分が考えていなかった意見として次のようなものが挙がった:

• 他のプロジェクトへの関心が薄い。
• 情報があっても理解できないものがある。

特に前者は気になる点だ。 人数が少ない組織で、自分の関係しているプロジェクトだけで閉じてしまうと質もスキルも向上しにくいからだ。

はたして忙がしいからなのか、人間関係からか、はたまたモチベーションのレベルからか。 いや、それともそれが普通の心理なのか。

• 今日のさえずり - 明日のミーティング資料 Google ドキュメントで書いた (2007-10-31)
• 緊急出荷 (2005-02-28)
• 電線燃えてた (2005-08-23)
• ビビンバ丼をデリバリー (2005-02-23)
• チェックボックスルール拡張 (2005-12-24)

■ ソフトウェア開発プロジェクトで朝会をすることにしてみた

私を含めて3人で進めているソフトウェア開発プロジェクトについて、今日から朝会をしてみることにした。 情報共有の促進や、問題の早期発見・解決、コミュニケーションの緊密化などが主な目的。

しかしまだスタイルが全く確立できていないので、どれぐらいの時間で誰が何をしゃべればいいのか手探り状態。

• ビジネスメールガイドライン案 (2006-05-05)
• メールによる社内コミュニケーションの問題 (2006-04-12)
• ソフトウェア開発プロジェクトにおける朝会をカイゼンする (2007-04-06)
• 早朝会議革命 - 元気企業トリンプの「即断即決」経営 (2005-07-16)
• Joel on Software - 必読書 (2008-08-14)