nDiki : コミュニケーション

メール 意思決定 GTD ソフトウェア Life Hacks プレゼンテーション 問題解決 仕事術 開発 Blog 日本語 仕様 ミーティング 会議 Naney 思考法 計画 アウトプット主義 発想法 情報発信 メモ術 リーダーシップ 検索 ノウハウ 電子メール トリンプ アイデア メーリングリスト ソフトウェアプロジェクトマネジメント 研究

■ ソフトウェアかんばん「見えない化」

チームメンバが重なっている2005年度の2つのプロジェクトがほぼ終了したので、事後評価セッションを開催。

興味深いポイントについて:

@ ソフトウェアかんばんが見えない

今回1つのソフトウェアに対してソフトウェアかんばんを適用した。 担当開発者の2人は以前このコンビで別のソフトウェアでかんばんを使用し、コラボレーションが促進したのだが、今回はどうもイマイチであった。

先日のレイアウト変更で、タスクカード/ストーリーカードを貼る(座っている場所から見える)パーティションが無くなってしまったのが敗因と推測されている。

ぐらさん言わく「見えない化」

@ issue tracking

開発中に発生する

• モジュール間のインタフェースの問題点(あるいは不明点・疑問点)などの確認/議論の必要なもの
• ライセンス関連の問題など意思決定を要するもの

などについて誰かが指摘した後、迅速・確実に処理がなされないことが多かったという意見も多かった。

後半「コミットメント・リストチェックを電子上での各自チェックに切り換え」たことにより、皆が頭を突き合わせて真剣に意思決定する場が減ったのが大きなマイナスだったか。 その方式は2月に終了したスタッフが2拠点に分散したプロジェクトで成功した方式で、うまくいったので導入してみたのだが、このチーム向きではなかったようだ。

やはり基本は顔合わせということを実感。

またコミットメントではないけれど、細かい issue を追跡する仕組が必要かなと。 ツールに走って issue tracking system 導入して遊ぶという手もあるが、手段が目的になってしまいそうでもある。

どのようなプロセスがチームに向いているのかも含めて、ここはひとまず紙ベースでいろいろ試行してみようと思う。

できるだけシンプルにして、各自が自分の好みのツールと連動して処理していけるようにするようにしたい。

(というか、自分は自分の GTD プロセスとスムーズにやりとりできるようにしたい。)

@ インタフェースを変更するなら、古いのも deprecated 扱いで残して

複数人開発で途中開発者間にまたがるインタフェースの仕様が何回か変更になった。 改良のために仕様変更はアリだと思うが、コード変更に愛情が足りなかったため実行できないコードが断続的に発生し、確認のための開発待ちが発生した。

通常開発中のコード内でのこのようなインタフェース変更については

1. インタフェースを変更する人が、同時に呼出し側のコードも修正してコミットする
2. しばらくは古いインタフェースを @deprecated で残しつつ、新しいインタフェースを提供する

のどちらかを取りかつ周知をする必要があるが、この辺がうまくできていなかった。 次回はうまくやれるはず。

ちなみに「できるだけ早く仕様を決定するようにする」というアイデアも出たが、これはまず守られない。もちろんみんなそれを望んでいるし、そのように努力しようとするんだけれども、最初の時点で完全な仕様を決定できることはほどんどない。仮にその時点で完全でも、数ヶ月後には状況が変わり仕様がふさわしくなくなってしまっていることもある。 無理に最初の仕様に固執することの方がデメリットが大きいことも多い。

@ 止まらないプログラミング

変に一人で抱えこんで数時間あるいは1日プログラミングを止めてしまうことを無くそうという提案。

• 30分ルール

「30分」のところは15分だったり1時間だったりするかもしれないが、とにかく必要以上に一人で悩んで立ち止まらないようにしようという話。

関係者に確認すれば数分で解決してしまうことも多い。 技術不足とかそういうこととは関係なし。 もしかしたら「そのインタフェース実はまだできてないので結果は適当です」というのを呼び出して結果が合わないと悩んだりしてたりとか。

チームのトータルのスループットを最大にするようにコミュニケーションしよう。

• すごいKPT事後評価セッション (2005-10-07)
• ソフトウェアかんばん (2005-10-28)
• Google ドキュメントでソフトウェアかんばん (2008-03-30)
• WiKicker でソフトウェアかんばん (2007-03-01)
• すごい会議の正しい手順 (2005-07-04)

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

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

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

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

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

@ メーリングリスト

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

• 宛先不明のもの/「○○各位」宛のもの
  • 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)
• リリース版完成後の事後評価 (2004-05-28)
• GnuPG の布教失敗 (2005-02-02)

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

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

そんな中、東洋経済新報社の「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)

■ GTD アクション確保のための時間割

複数の提案書レビューをショートサイクルで繰り返すというスタイルのフローをいま実践中で、そのため最近はスケジュールにミーティング時間がどんどん書き込まれるという状態である。

自分の中でルールを確立していないため、ミーティング時刻の設定はなんとなく。 何も考えずにこのまま続けていくと、スケジュールがミーティングで埋まってしまいそうだ。 しかしそうなるとその他のアクションが実行されず、責任ある仕事ができなくなってしまう。

いい機会なので、GTD にある次の行動リストの項目を実行するための時間帯とミーティング時間帯をある程度分けて決めてみてしまうことにした。 生理的な「はかどる時間帯」等も考慮してタイムテーブルを考えてみた。

• *1 金曜日は GTD 週次レビュー時間
• *2 単調作業 / 事務処理 / 整理等

論理的な仕事に向いている午前中には社内ミーティングを入れずに、頭を使うアクション(計画や提案立案など)を実行したい。

14:00 - 15:00 は眠くなる時間帯のようなので、待つリストをチェックして他の人に状況を確認するなど、コミュニケーション用時間とする。

社内ミーティングは原則 15:00 - 17:00。場合によっては前後 1時間もミーティング設定可。この時間帯にミーティングがない場合は、単調作業があればこなすようにする (貴重な午前中にやらないように)。この時間帯は繰り返し作業などに向いているらしい。

そういえば社内ミーティング 13:30 開始っていうのがあるのだが、これは準備する側の時には楽だけれど、そうではない側の時はその30分が中途半端であまり効率が良くないというのが最近の印象だ (その隙間時間を活用するのが GTD の極意ではあるのだが)。

最後の1時間は日によって無かったりする可能性があるので、バッファ的な時間としておく。in-box もここで処理しておく。

まずはこれでトライ。

[ 時間管理 ]

• なぜか、「仕事がうまくいく人」の習慣 (2007-04-15)
• 2008年夏の GTD 運用ツール (2008-07-23)
• GTD Next Actions リスト用ノートをやめる (2007-07-25)
• 次の行動がたまってきた (2005-08-29)
• GTD 週次レビューが2時間で終わらない (2006-09-29)

■ NICT 知識創成コミュニケーション研究センターへ行ってきた

ミーティングで京都府相楽郡精華町光台にある NICT の 知識創成コミュニケーション研究センターへ行ってきた。 新幹線で京都まで出て、そこから近鉄京都線で新祝園へ。 新祝園を「しんほうその」と読むことを知らなかったので、いつ着くのか車内アナウンスでよくわからなくて、行きはちょっと不安な思いをしてしまった。

@ ほぼ日手帳

ミーティングの休憩時間に、研究員の方が机に置いておいた私のほぼ日手帳を見て「私もほぼ日手帳ですよ」と話してくれた。 ほぼ日手帳はそういった話題提供ツールでもあると思っているので、話が咲くと嬉しい。

ほぼ日手帳の話から GTD や Life Hacks の話、そして「chalow の山下達雄氏とは実は同じ大学院で、山下氏は普段からメモ帳を身につけていましたよ」という話まではずんだ。

日帰りでの移動時間の関係もありそんなに長居はできなかったけれど、いつもと違う会話ができて満足であった。

• 研究畑の会議の苦悩 (2007-03-30)
• 京都日帰り出張、帰りは最終の新幹線で。 (2006-08-01)
• GTD Next Actions リスト用ノートをやめる (2007-07-25)
• 今日のさえずり - 新幹線の静岡駅と浜松駅が酷似している (2008-06-18)
• 方眼手帳と方眼ミーティングメモ (2005-11-27)

■ 「プロジェクトマネジメント」はどうやって勉強すれば良いですか?

会社の後輩から問われた。

答えがあればこちらが知りたい。

プロジェクトマネージャには、そういう事を自力で模索し掴みとる能力が必要なのではないか。プロジェクトマネージャは答えの決まっていない問題の解決をしていかなければならないのだから。

もちろん他の人から学ぶというのも重要なので、質問すること自体は悪くない。 ただもう少し自分で考えてみて「○○と△△というのがあり、○○の方が～～で良さそうだと思うのですがどう思いますか?」などと、やるのが良いかと思う。

ちなみに私がどう試行錯誤しているか、何を読んでどう考えたかはココ (nDiki) に書いているから、後輩君なら(反面教師にせよ)見てくれればいいと思う。

ていうか、何か面白いもの見つけてきてドンドン紹介してクレ。

• 技は盗むもの - 早朝会議革命

@ とはいえ自分なりに列挙してみる

ソフトウェアプロジェクトマネジメントで、必要なキーワードを思いつくままに挙げてみた。

• 問題発見力、問題解決力 (思考法)
• 意思決定力
• リーダーシップ力
• コミュニケーション力
  • コーチング
  • ファシリテーション
• プレゼンテーション力
• (リスク管理力)
• 以下に関する知識
  • 開発ガイドライン
  • ソースコード管理 (リビジョン管理)
  • バグトラッキングシステム
  • ビルド管理
  • リリース管理
  • ドキュメンテーション
  • ソフトウェアテスト
  • ソフトウェア見積もり
  • ソフトウェアライセンス
  • ピアレビュー

• ビジネスメールガイドライン案 (2006-05-05)
• ピアレビューの効果を上げたい (2006-05-19)
• やっぱり聞きやすかった大前研一 (2006-10-25)
• 久しぶりに build.xml を書く (2005-11-14)
• トム・デマルコ ゆとりの法則 - 誰も書かなかったプロジェクト管理の誤解 (2004-04-17)

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

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

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

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

■ Twitter のアカウントを作成して、今何をやっているかを晒す

しばらく前から話題になり始めている Twitter のアカウントを作成してみた。

• http://twitter.com/Naney

以前初めて Twitter のサイトを訪れた時には、何だか知らない人の1行メッセージが並んでいるだけに見えて(実際そうなのだけれども)「ふーん」という感じだった。

知っている仲間が使い始めると、チャットよりはユルく、 AIM や Skype などの1行コメントよりはコいコミュニケーションツールとして面白く使えるのかもしれない。 大学仲間の雰囲気が似合いそうなサービス。

自分の場合は、Blog のエセライブカメラを補完するアクティビティ晒し用として使うのがまずは良さそう。 ということで、nDiki のサイドバーに Badge を貼ってみた。

今していることを変えるたびに入力するのって、ある意味作業記録をつけているようなものだな。 統計とか取れるようになるとと Life Hacks 的には面白いかも。

• オフライン中も Gmail チャット機能は Twitter ステータスを記... (2007-08-20)
• Gmail のチャット機能で Twitter ステータスを記録 (2007-08-16)
• Twitter を使い始めて1年 (2008-04-06)
• 今日のさえずり - データベース設計していて enraku 登場見落としてた (2007-11-13)
• 会社に置き忘れた定期券の所在ををライブカメラで確認 (2006-04-27)

■ なぜか、「仕事がうまくいく人」の習慣

2月に読んだ「スピードハックス 仕事のスピードをいきなり3倍にする技術」(書評) の中で紹介されていた本。興味を持ったので買って読んでみた。

本書によると「仕事がうまくいく人」の習慣とは「すぐにやる!」ことだ。

• すぐにやる!
  • 書類、メールはすぐに処理する。
  • すぐに整理する。
  • すぐに計画する。
  • すぐに正しくやる。
  • すぐに整備する。

あとは

• 機械的に行う作業を決める。
• 歩きまわりコミュニケーション。

など。

GTD で言われていることとかぶる部分も多いので、やはり本書においては「すぐにやる!」というのが一番ポイントであろう。

先送りすればするほど、「問題は大きくなる」し「何度も同じ事を考えたりするはめになる」し「何度も同じメールを読み返すことになったりする」し「他人にせっつかれたりする」し「余分な進捗報告が必要になったりする」しで、達成するまでに余計なコストがかかるようになる。つまり同じ仕事をするのに必要な時間が長くなってしまうというワケ。

一見しんどそうでも結局のところすぐやってしまった方が、効率的にも精神的にも圧倒的にもお得だということ。

これを自分のものにするには

『すぐやる』方式は、長く継続しなければ意味がないという点だ。-- p.35

というのが肝だ。

人間の行動研究で著名なウィリアム・ジェームズによると、何かを毎日やって三十日間続ければ、習慣になるという。-- p.61

そうだ。

私が「すぐにやっていな」かったら「すぐに」指摘してください。> ALL

• なぜか、「仕事がうまくいく人」の習慣 PHP研究所

[ 書評 ]

• GTD アクション確保のための時間割 (2006-09-26)
• メールによる社内コミュニケーションの問題 (2006-04-12)
• 問題とは「あるべき姿」と「現状」の「ギャップ」である (2006-10-13)
• 問題解決プロフェッショナル 「思考と技術」 (2006-08-27)
• NICT 知識創成コミュニケーション研究センターへ行ってきた (2006-11-13)

■ ちょっと複雑なネット用統合アドレス帳 Ripplex

最近話題になり始めた統合アドレス帳 Ripplex をインストールしてみた。

• 誰にどのような情報を開示するかを細かく指定できる。
• リンクを使って友人に情報開示できる。
• 共有カテゴリを使って友人と情報を共有できる。
• PMM 検索によって、友人を検索できる。
• Twitter と連携。following リストを取り込んだり、投稿したりできる。
• Skype と連携。コンタクトリストを取り込んだり、ムードメッセージを設定できたりする。

などが特徴。

相手が情報開示していればリンクや共有カテゴリを使ってその人が使っているネットサービスを知ることができ、それらを使ってコミュニケーションをとることができる。 リンク等を使って共有されなくても、通常のアドレス帳のように手入力することもできるので友人のネットサービス関連のアカウント管理等にももちろん使える。

と機能的にはクールで面白いアプリケーションだ。

もちろん気になる点もいくつかある。

• Windows / Mac OS X 用なので、Linux ユーザである自分は常用できない。
• クライアントアプリケーションなのでネットサービス上にデータを置かなくてよいものの、ローカル PC 上のデータは保護されていない。オフラインモードになるがパスワードなしでローカル PC 上にあるアドレス帳は全て見られる。
• アドレス帳は Windows の場合、c:\Document and Settings\ユーザ名\Application Data\Ripplex で決め打ち(変更できれば TrueCrypt 仮想ドライブボリュームの中に入れておくのだが)。
• Ripplex を使っている友人が少ないと便利さ/面白さが半減する。
• 情報開示設定が柔軟にできる分、使いこなすにはそれなりに学習する必要がある。

ネットサービスではないので Linux で使えないのは自分の場合つらいな。 どれぐらい流行るか様子見。

• http://www.ripplex.com/

• Linux 母艦ノート PC を使わずに仕事ができるかチャレンジ (2007-08-20)
• Flickr::UploadでLinuxから画像アップロード (2005-04-22)
• TrueCrypt で USB メモリに Windows と Linux ... (2006-12-14)
• Twitter への書き込みを自動的に Skype ムードメッセージに設定... (2008-08-05)
• Linux で入力して Windows で参照できるパスワード管理ツール ... (2006-12-31)