無印吉澤（※新エントリはhatenablogに掲載中）

■[P2P][VoIP]College of William and MaryによるP2P SIPのドラフト

以前に取り上げようとしたものの、その後すっかり忘れてしまっていたインターネットドラフト"A P2P Approach to SIP Registration"(draft-bryan-sipping-p2p-00)の所感がnoritsunaさんのサイトで公開されていました。

P2P-SIP（なんとなく実験）
http://www.noritsuna.com/archives/2005/03/p2psip.html

初版の割にかなり長いドラフト（39ページ）なので、こういう要約があると助かります。

■[P2P][VoIP]P2P SIPのメリットって何？

で、今更ですが、「P2P SIP」という単語はP2Pネットワーク上でSIPメッセージを転送することでVoIPを実現する技術（手法？）の総称として使われています。

このP2P SIPに関する議論が最近になって活発になった理由は、明らかにSkypeの成功によるものです。そのため、P2P SIPが掲げるメリットはSkypeのデメリットを裏返したものになっています。例を挙げると、以下のような感じです。

• P2P SIPはオープンなSIPプロトコルに基づく
  ←Skypeはプロプライエタリなプロトコル
• P2P SIPは既存のSIP端末を利用できる
  ←Skypeを利用するには独自端末が必要
• P2P SIPは中央集中サーバが不要
  ←Skypeは認証などのための管理サーバ（Network Management Server）を必要とする

ただ、いろいろ調べてみても、このあたりのメリットがどうも僕には納得できません。

まず1つ目のメリットについては、オープンなプロトコルであれば別にSIPでなくてもいいわけで、それこそJXTAのようなオープンなP2Pプロトコルでも良さそうです。

次の2つ目のメリットは、この中で一番納得できそうです。ただ、これはSkypeのような独自プロトコルでも、ピアにSIP端末とのゲートウェイ機能を持たせれば同じことになるのではないでしょうか（ちなみに、ブートストラップ問題はP2P SIPでも独自プロトコルでも同じ）。現に上記のP2P SIPに関するドラフトでも、「Adopter Node」という、P2P SIPをサポートしないSIP端末を接続するためのゲートウェイ機能を持つピアを用意しています。

最後の3つ目のメリットは確かにその通りだと思いますけど、サーバを用意しないと、セキュリティの問題による制約を受けて拡張性が随分下がってしまう気がします（例：証明書管理の手間など）。通話対象が限られるVoIPプロトコルなんて僕はあまり使い道がないと思うのですが、どんなものなんでしょうか……？

■[P2P][VoIP]P2P SIPに対するJ. Rosenberg氏のコメント

前回の日記を書くにあたって、個人的に参考になった文章を紹介しておきます。

IETFには、SIPの拡張について議論するSIPPING（Session Initiation Proposal Investigation）というワーキンググループがあります。そこのメーリングリストで、今年の1月末から2月にかけて

[Sipping] SIP P2P draft
http://www1.ietf.org/mail-archive/web/sipping/current/msg07401.html

To: sipping <sipping at ietf.org>
Subject: [Sipping] SIP P2P draft
From: Cullen Jennings <fluffy at cisco.com>
Date: Thu, 20 Jan 2005 21:51:22 -1000


David Bryan and I have submitted an draft of some early ideas on P2P with
SIP. Until it shows up in the repository, you can find it at

http://p2psip.org/

Cullen

というメール*1を発端にしたP2P SIPの要求に関する議論があったのですが、その議論に思いっきり冷や水を浴びせかけたJ. Rosenberg氏のコメントがそれです。この人は元dynamicsoftで今はCiscoに居る*2のですが、SIPやそれに関連したNAT越え関係のRFC、Internet Draftを数多く執筆しているパワフルなおじさんです。

そのメールの内容を訳してみた（かなり意訳含む）ので、以下に紹介しておきます。

Re: [Sipping] SIP P2P draft
http://www1.ietf.org/mail-archive/web/sipping/current/msg07440.html

To: Robert Sparks <rjsparks at nostrum.com>
Subject: Re: [Sipping] SIP P2P draft
From: Jonathan Rosenberg <jdrosen at cisco.com>
Date: Thu, 27 Jan 2005 19:00:13 -0500


I also appreciate this work, and think it is worth continuing discussion
on documentation on the subject.

私もこの仕事を高く評価するし、このテーマに関する文書について議論を続けるの
は価値あることだと考える。

Robert lists potential requirements below. However, I don't see them as
requirements per se; mostly they seemed like questions around how a
particular problem is addressed when building a p2p network.

Robertは潜在的な要求を下のメールで列挙している。しかし、私にはこれらが本質
的な要求には見えない――そのほとんどは、P2Pネットワークを構築する際に特有
の問題をどのように解決するか、についての質問のように見える。

The real requirements question is whether our aim is to build p2p just for
sip, or to build a generic p2p protocol (i.e., an implementation of chord
and bootstrapping techniques) that provide a generic p2p service. In
particular, one might imagine a protocol that effectively exposes an API
on participating hosts which, given a resource name, a hashing mechanism,
and a p2p system ID (i.e., which p2p network), it returns the IP address
of the place where that resource can be found. Such a generic protocol
would support joins, leaves, and so on. From my brief reading on p2p
literature it seems like this decomposition is common.

要求に関する本当の論点は、我々の目的がSIPだけのためのP2Pを構築することなの
か、それとも一般的なP2Pプロトコル（すなわち、Chordの実装と、ブートストラッ
プのテクニック）を構築することなのか、である。特に、後者なら参加ホストへ効
果的にAPIを公開するプロトコルを想像できる。ここで言うAPIとは特に、リソース
名、ハッシュのメカニズムそしてP2PシステムID（すなわちP2Pネットワーク）を与
えられると、そのリソースの存在する場所のIPアドレスを返すようなものである。
そのような汎用プロトコルは参加や離脱などをサポートするだろう。私がP2Pに関
する文献を簡単に読んだ限り、この分析は一般的であるように思える。

In essence, is the goal to build a generic, standardized p2p toolkit ontop
of which we can build lots of p2p applications, or is it just to make sip
p2p and do it in a sip specific way?

本質において、多くのP2Pアプリケーションの土台として利用できる汎用的で標準
化されたP2Pツールキットを作ることが目的なのか、それともSIP P2Pを作ってそれ
をSIP特有の方法で利用することが目的なのか？

I will note that, even once you have developed such a toolkit, serious
questions remain about how it could be used by SIP for the purposes of
building a p2p network. The primary issue is security, of course. SIP
specifies its behaviors logically speaking; a proxy is just a role, and it
runs on a host at a specific IP address. Same with registrars, presence
servers, etc. If you envision that the p2p protocol effectively provides
an alternative to DNS - a way to find my proxy, or find my presence server
- then we could make SIP p2p by just replacing rfc3263 with that
mechanism.

そのようなツールキットを一旦開発しさえすれば、「P2Pネットワークを構築する
ためにそれをSIPでどう利用するか」という深刻な問題だけが残る、ということに
注意すること。当然、第一の問題はセキュリティだ。SIPはその振る舞いを明確に
している。プロクシは単なる機能で、特定のIPアドレスを持つホスト上で動作する。
レジストラや、プレゼンスサーバなども同様である。P2Pプロトコルが（プロクシ
やプレゼンスサーバを見つけるための方法である）DNSの代替を効果的に提供する
とすれば、我々はRFC3263をそのメカニズムで置き換えるだけでSIP P2Pを作ること
ができるだろう。

But it wouldn't work, of course. The reason is entirely security. SIP
assumes a trust relationship that has proxies and presence servers as
privileged systems - ones that users implicitly trust. p2p breaks
that. Thus, the challenge is entirely how to adapt sip to trust models
whereby the provider is an untrusted element by the user. Such an
"extension" to address doing that might even be useful in systems where
the server is still centrally located via DNS - for example a sip proxy
run by a coffee shop I happen to step into. Why should I trust them?

しかし、それはもちろん動作しないだろう。原因は全てセキュリティだ。SIPは特
権システムとしてのプロクシやプレゼンスサーバが持つ信頼関係を前提にしている。
そして、ユーザはそれらのサーバを無条件に信頼しているが、P2Pはその前提を破
壊してしまう。従って、課題はもっぱら、ユーザによる信頼できない要素が提供者
となる信頼モデルに対してどのようにSIPを適用するかということになる。そのよ
うな「拡張」は、サーバがまだ集中的に（DNSによって）配置されているシステム
――例えば、私がたまたま立ち寄ったコーヒーショップで動作するSIPプロクシ―
―でさえ使えるかもしれない。何故、私はそれらを信頼すべきなのだ？

A fair question to ask is whether certain features we want (like dialing
911 or protecting presence data from prying eyes) can ever reasonably be
accomplished in the differing trust models provided by p2p systems.

尋ねるべきもっともな質問とは、我々が求める特定の機能（緊急通報、またはプレ
ゼンスデータをのぞき見から守ること）はP2Pシステムによって提供されるものと
は異なる信頼モデルの上でしか成し遂げられないのか？ということである。

One of the big technical issues is NAT traversal. I think that is actually
not so hard. We have all of the tools already - ICE in particular is a p2p
traversal technique. ICE relies on STUN and TURN. Currently, it assumes
that the STUN and TURN servers are centralized. But, they need not
be. Instead, we could have them as peer components, and we use the p2p
network to locate those too. There, finding them is interesting. The
requirement is that you can be a TURN or STUN server if you are on the
public Internet. Thus, its not really a search for a single resource by
name, but rather a search for any resource with a particular property. Not
sure how that could be done in chord, worth considering some more.

大きな技術課題の1つはNAT越えである。私は、これは実際のところそれほど難しく
ないと考える。我々は既に全てのツールを持っている――特にICEはP2PのNAT越え
技術である。ICEはSTUNとTURNに依存する。現在のところ、STUNとTURNは集中化さ
れたサーバを前提としているが、必ずしもその必要はない。代わりにそれらをピア
のコンポーネントとして備え、我々はそれらを見つけるためにP2Pネットワークを
利用することもできる。つまり要求は、名前によって単一のリソースを探すこと
ではなく、むしろ特定の特性（STUNやTURNサーバとしての機能）を持つリソースを
探すことになる。それがChordによってどのように実現できるかは定かでないが、
もう少し考える価値がある。

（後略）

[文中で触れているRobert氏のメールはRe: [Sipping] SIP P2P draftを参照]

そして、（長いので省略しましたけど）Rosenberg氏は最後に、グローバルIPアドレスを持たないピアがChordに参加するためには、TURNサーバからグローバルIPアドレスとポートの組を取得して、Chordの識別子として用いることができるだろう……と述べています。

要するに「P2P SIPなんて言ってないで、リアルタイムコミュニケーション向けのP2Pプロトコル/ツールキットを作ればいいじゃねえかよ。まぁ、どっちにしろセキュリティが問題だけど」という話で、僕もこれに同意するんですけど、一方で「SIPを旗頭にすればとりあえず注目が集まるよ（今更P2Pフレームワークも無いだろ）」という現実も確かにあるわけで……。

■[P2P][VoIP]P2P SIP用組み込みソフトウェアNimX

Nimcat Networks Inc.
http://www.nimcatnetworks.com/

世の中には既にこんなものがあって、このソフトウェアを組み込んだ電話機がつい最近発売になったそうです。

Nimcat Networks Inc. - PRESS RELEASES
http://www.nimcatnetworks.com/Reading.aspx?fid=46&ftype=1

TORONTO (March 14, 2005) - Aastra Technologies Limited (TSX: AAH), a leader in enterprise communication access products, extended its industry leadership today with the launch of VentureIP(TM) the first enterprise-class, P2P (peer-to-peer) IP-based phone system. Powered by Nimcat Networks’ nimX software, the system enables small to-medium business (SMBs) to install, operate and manage a full-featured phone system by simply plugging the VentureIP 480i telephone into their local area network (LAN). The system scales on a phone by phone basis and can be connected to the local PSTN via the VentureIP Gateway.

中小企業向けにP2P SIPによるIP電話を実現し、従来のPSTNにはIPセントレックス方式で通話を実現するサービスを提供しています（参考：PEER TELEPHONY EXCHANGE (PTX)）。どこまでSIPを標準的に使っているのかまだよくわからないですが、ここの社員が書いているInternet Draftがあったのでそのうち読んでみます。

Industrial-Strength P2P SIP
http://www.ietf.org/internet-drafts/draft-matthews-sipping-p2p-industrial-strength-00.txt

（2005/08/21追記）
後日詳しく調べてみたところ、これはP2P技術を用いたVoIPミドルウェアがSIPにも対応しているだけのようです。P2P SIPと呼んでしまったのは早とちりでした。申し訳ありません。

NimXについては、詳細が分かり次第またここで取り上げます。

■[書評]「超」MBA式ロジカル問題解決

「超」MBA式ロジカル問題解決(津田 久資)

職場の先輩から借りた、MBA*1教育の現場で学ぶ論理的思考に関する本です。タイトルからして、うちのサイトの主な話題とは完全にかけ離れた内容の本なのですが……割と面白い内容だったので久しぶりに書評を書いてみます。

まあ、たまにはこんなのも良いかなぁと。

----

元IBM会長ルイス・ガートナー氏の発言によると、MBA教育の目的とは

「状況がはっきりしないまま、限られた情報と限られた時間の中で、いかに事態を分析し、判断を下すか」

を学ぶことだそうです。

実際のビジネススクールでは膨大なケーススタディを積むことでそのことを十分に学びますが、一般のビジネスマンが独学でMBAの本を読んだりしても、なかなかそのエッセンスは掴めません。そこで本書は、そのエッセンスを「マインド」「ツール」「情報」というキーワードでまとめることで、本による独学や企業等での研修内容を実際のビジネスで活用できる力にすることを目指しています。

■ 論理的思考の最終目的は問題解決

論理的思考（ロジカルシンキング）の最終目的は、その人が抱える問題の解決です。そして、良い問題解決とは、良い解決策を作り出すことである、と本書では位置づけています。

本書で挙げている「良い解決策の4つの条件」は以下の通り。

1. 解決策がスピーディーに出てくること
   （競合より早く解決策を策定する。オリジナリティは「あったらいい(nice to have)」程度）
2. 一義的なアクションがとれるまで、その解決策が具体的であること
   （表現が曖昧でない。マニュアルのように明確）
3. 解決策の実施によって問題点が解決するという「すじみち」があること
   （その解決策で問題が解決する理由を、順序立てて説明できる）
4. その解決策が最も良いといえる「すじみち」があること
   （十分多くの解決策を挙げて、その中から最も良いものを選ぶ）

そして、このような良い解決策を作り出すために必要なものの1つが「結論志向のマインド」です。

■ マインドと情報

日本人は完全主義の人が多く、その結果、欧米人と比較すると前述のような「限られた情報・時間の中で、いかに事態を分析し、判断を下すか」というマインドが足りない、と筆者は主張します。「今手にしている情報の中で、ベストの解決策は何か」と考え、その答えを出す。そのようなマインドのことを本書では「結論志向」と呼んでいます。

結論志向とは、不完全な情報しかなくても常にその時点でベストの結論を導き出し、

1. その結論を検証するためには、どんな情報が重要かを特定する
2. そして、特定された情報や予期せぬ重要情報が得られたら、即座にそれらの情報を組み込んだ結論に変えていく

というサイクルを繰り返していくものです。このサイクルの中では、結論をより正確にするために、何度も情報収集を行います。

しかし情報収集にはコストがかかるため、優先度を付けて、重要なものだけ行う必要があります。ここで、情報収集は、（一時的な）結論を出すのに使った仮説を検証するための作業ですので、その優先度は

• 結論に与える影響の度合い
• 情報の事実と仮説の予想誤差の大きさ

に応じて付けていきます。つまり、結論への影響が大きくても、その仮説が事実とそれほどズレていないと考えられるなら情報収集の優先度は低くなり、その逆もあるわけです。

以上のように、情報収集を行う際に「結論志向」というマインドを持つことで、意志決定のスピードは格段に向上するというのが筆者の主張です。

■ ツール

また、上記のような思考のサイクルを回す際には、知識や経験に縛られずに考える「ゼロベース思考」が重要になります。

しかし普通の人間は、すぐに自分の経験・知識・性向を持ち込んでしまうため、ゼロベース思考を実践するのは難しいです。そこで、結論（ビジネス上の問題の原因、解決策）の可能性を漏れなく考えるために「チェックリスト」の役割を果たすものが必要になります。

本文中で、チェックリストの効用を短くまとめた部分を以下に引用します。

第一に、広く網羅的にアイデア（仮説）が出るようになる
第二に、創造的発想（＝ひらめき・思いつき）の幅が狭まるので、アイデア（＝仮説）がよりピンポイント（＝具体的）になる

そして、ビジネス書でよく取り上げられている代表的なツールである

• MECE（Mutually Exclusive Collectively Exhaustive）*2のルール
• 5W1H

• フレームワーク

  • マーケティングの4P
  • 戦略策定の3C（または4C）
  • AIDMA

• などなど

は、実は「ゼロベース思考」助けるためのチェックリストであり、MECEなどがこのような目的で作られていることを意識することで、既存のツールを自分の問題に合わせて応用できるようになる……というのが筆者の後半部での主張になります。

■ 感想

個人的に感じたこの本のキモは、とにかく「結論志向」に尽きます。「やってみなきゃわからない、聞いてみなきゃわからない、なんて甘く考えていると、実際にやったり聞いたりしても大した実入りがない。だから、自分の持っている知識の範囲で十分に仮説を立ててから挑め」という筆者の主張は、ビジネスの現場に限らずに広く適用できるのではないかなぁ……と感じました。

で、本書の残りの部分では、ケーススタディや、先生と生徒の会話形式のストーリーを通して、上記の内容が具体的に説明されていきます。この手の本は（当たり前ですが）基本的に理屈っぽすぎてイヤになるものが多いんですが、この本は割とすんなり読める部類なのではないでしょうか。論理的思考に興味があるという方にはおすすめできる本です。

■[SBM][SNS]Rojo / ソーシャルブックマークとソーシャルネットワークの微妙な関係

（今回の日記は、cedさんとのMSNメッセンジャーでの会話を元にしています。）

■ Rojoはダメダメでした。でも、どこがダメ？

Rojo
http://www.rojo.com/

今までは誰かに招待してもらわないと使えなかったRSSリーダの「Rojo」が、ユーザ登録さえすれば誰でも使えるようになりました。

SNSとRSSリーダーを組み合わせた「Rojo」が公開ベータテスト
http://internet.watch.impress.co.jp/cda/news/2005/04/21/7377.html

で、以前から気になっていたので、僕も早速ユーザ登録して使ってみたのですけど……実際に触ってみると何だか微妙でした。かなり期待していただけに、正直ショックです。

まず単純に、単体のRSSリーダとしてダメです。具体的にダメな点を挙げると、動作が重くて（やや過剰なデザインのせい？）、インタフェイスが分かりづらくて、既読/未読の管理が出来ない*1などがあって、日常的に使うにはちょっと、という感じの出来になっています。

それと、Rojoはサイトの保存やタギングなどの機能や、Contactsに追加した友達の間でサイトを共有する機能を備えているのですが、これもいまいち微妙です。前者はソーシャルブックマークと呼ばれるサービスに、後者はソーシャルネットワークサービスに似ているのですが、どうもちぐはぐというか、それぞれ単体のサービスのような楽しさが感じられませんでした。

機能的には十分楽しそうなのに、なにか楽しめない。そんなRojoのダメな理由について、今回は考察してみました。

■ ソーシャルブックマークの本質

そもそも、ソーシャルブックマークとは何なのでしょう？

del.icio.usやはてなブックマーク*2のようなソーシャルブックマーク（以下、SBMと略）が登場する以前から、SBMに似たようなサービスとしては、MyClipなどのクリッピングサービスが存在していました。その両者の違いは、簡単に説明すると次のようになります。

• クリッピング：インターネットから有用なサイトを拾い上げ＆分類＆公開する
• ソーシャルブックマーク（SBM）：クリッピング＋ユーザ-サイト-タグ間リンクで広がりを与える

つまり、クリッピングはユーザが情報収集した結果のアウトプットでしかありませんが、SBMはそのアウトプットが更なる情報収集に適したネットワークの形成に繋がっていて、それがSBM独自の魅力に繋がっています。更に言うと、以下のようなことです。

• SBMが魅力的なのは、WWWよりも情報収集に適した形でサイト間をリンクしているから*3
  →WWWのオーバレイネットワーク*4＝SBMのネットワーク

従って、ネットワークから能動的に情報収集するにしても、インターネットよりもSBMのネットワーク上でリンクを辿っていった方が効率的ですし、ネットワークから受動的に情報収集するにしても、インターネット全体よりもSBMのネットワークを対象とした方が効率的になるわけです。それぞれのネットワークに対する受動的な情報収集の例を、それぞれ以下に挙げます。

• インターネット全体を対象：特定のキーワードにマッチするRSSフィードの受信（例：Google Alert、サーチエンジンの検索結果をRSS配信）
• SBMのネットワークを対象：特定のタグやユーザにマッチするRSSフィードの受信（例：del.icio.usのinbox機能、はてなブックマークのお気に入り機能）

こうしてみると、インターネットとSBMのネットワークで、情報のフィルタに使える軸が意味を持ったものに変わっているのが分かると思います。

■ Rojoとソーシャルブックマークの比較

一方、Rojoもユーザ-サイト-タグのリンクを備えていて、パッと見ではSBMと同様の機能を備えているように見えます。

ただ実際のところ、Rojoでは「誰が/何人がそのサイトをクリップしたか」という情報が隠蔽されているために、情報の分類に使われる軸が一般のSBMよりも少なくなっていて、それがRojoのネットワークを狭く感じさせる原因になっています*5。これは、Rojoはかなりソーシャルネットワークサービス（以下、SNSと略）を意識した作りになっているので、「ユーザの情報はその友達にしか見せない」というポリシを適用しているのでしょう。恐らく。

で、そのSNSの特性を使って、Rojoはサイト共有機能（Sharedの画面で表示される）というものを提供しているのですが、これは「自分から1ホップ以内の友人が共有したサイトを閲覧できる」というだけの機能で、本質的には友達同士でクリッピングを共有しているのとあまり変わりません。

要するに、RojoはSNS的な特性を取り入れるのに失敗して、SMBの良さを殺してしまっている。そんな気がします。

■ SBMのネットワークとSNSのネットワーク

で、ここまで考えて思ったのが、RojoはSNS的な特性の取り入れに失敗してますけど……SNS＋SBMという発想自体はどうなんでしょう。SNSとSBMをうまく組み合わせると、どういうサービスが生まれるんでしょうか？

ここで、以前読んだ面白い本の知識をちょっと引っ張り出してみます。

ネットワーク分析の知見から優れた人間関係の作り方について論じた『人脈づくりの科学』（著：安田雪）では、情報交換のネットワークには分散的で多様性のあるネットワークが適しており、同質的な集団によるネットワークの中では閉鎖的な情報交換しか行えない、ということが述べられています。

これは単なる僕の推測で何のデータも無いのですが、ある程度親しい人同士の繋がりで作られるSNSのネットワークは同質的で集中的なネットワークであり、興味のあるサイトを介した弱い繋がりで作られるSBMのネットワークは分散的で多様的なネットワークと言えるのではないでしょうか？

そう考えると、SBMのネットワークが情報収集に適している（楽しい）のは頷ける話ですし、SBMのネットワーク形成にSNS的な特性を利用するのはどうも逆効果になりそうです。

ただ、「友達が注目するサイトは自分にとっても注目する価値がある」というRojoのアイディア自体はそれほど間違っているとも思えません。そこで、SBMのネットワーク形成にSNS的な要素を使うのではなく、SBMのネットワークに対して、mixiのような既に存在するSNSのネットワークを重ね合わせてみたらどうでしょうか。具体的な方法はいろいろあると思いますが、単純な例として思い浮かぶのは以下のような重ね合わせ方です。

• SBMのネットワーク上で、SNS内の友達がリンクしているサイトを優先表示する

このようにして優先表示されたサイトのリストは、結局、人間関係に基づいて作られた同質的なSNSのネットワークの特徴を反映したものになりそうです。ただ、そのようにリストを作る事で、「仲間内での話題についていくために見るべきサイト」の取りこぼしがなくなるという効果はあるので、今後、インターネット上の情報量がますます増えていくにつれて、このようなSBMとSNSの連携が重要になっていくことは十分考えられます。

ただ、そういうSBMとSNSの連携による面白さは、SBM自体の魅力には叶わないような気がします。個人的にはSBM、というかWWWのオーバレイネットワークを形成する技術の発展に、今後は期待したいところです。