WaterMind PC Blog

PCとネットワークに関するニュースコラム.

FaceBook: 日本での成功の鍵はゲーム?

2011-01-21 05:35:56 | ネットワークサービス
世界最大規模のSNS FaceBook において,ゲームアプリは非常に重要な役割を果たしている.

 FaceBook のゲームは,登録された友人間のコミュニケーション量を増やし,その結びつきを強めるのと同時に,知人以外の新たな友人を発見しやすくする.

  FaceBookゲームにおける FaceBookポイントや各会社のポイントなどの有料サービスは,問題も多いが,ビジネスモデルとしては成功しやすい.

  FaceBookゲームは,基本的に無料である.そのためそのゲーム内容は,一般的なゲーム専用機のソフトに比べて,薄くなっている.

  しかし逆に FaceBook ゲームの薄さ・軽さは,そのゲーム内容や成果うんぬんよりも,そのゲーム上での人付き合いの楽しさを際立たせることになった.

  しかも一般的なゲーム機のソフトと異なり,FaceBook ゲームでは,複数のゲームを次々と簡単に切り替えながらプレイすることができる.

  FaceBook ゲームは,無料でプレイでき,なおかつ,複数のゲームプレイ切り替えが簡単であることから,ゲームユーザーの多くが複数のゲームを同時にプレイしている可能性が高い.

 FaceBook ゲームは

  1. 低予算で短期開発でき(薄くてもかまわないゲーム内容,Flash開発)
  2. ビジネスモデルとして堅実(無料で勧誘,有料サービスで課金)
  3. 他のゲームとユーザー獲得を争うことも少ない(ゲームの同時使用)

と言う特徴を持つ.

  したがってゲーム不況にあえぐゲーム開発会社にとって,#FaceBook ゲームはビジネスチャンスとなりえる.

  FaceBook のユーザー数が日本では伸び悩んでいるという噂をよく聞くが, FaceBook ゲームの日本語化が進んでいないことも,大きく影響しているのではないか?

  FaceBook の日本における成功は,意外にも,このゲームが鍵を握っているのかもしれない.


モダンなインターネットサービス仕様

2011-01-12 14:33:44 | ネットワークサービス

たたき台です.今後,加筆・修正していく予定です.

★クライアントについて

  • サービスのクライアントは,複数のハードウエア・ソフトウエアをサポートする
  • サービスの主要なクライアントハードウエアは
    • PC
    • ガラケー
    • スレート端末
    • スマートフォン(Android, iPhone)
    • TV
  • サービスの主要なクライアントアプリは
    • PC Webブラウザ(Javascriptあり,マウス操作)
    • ガラケーWebブラウザ(iMode,Javascriptなし,テンキー操作)
    • スレート/スマートフォン Webブラウザ(Android, iPhone,iPad,タッチ操作)
    • TV Webブラウザ(リモコン操作)
    • それぞれのハードウエア別・OS別の専用アプリや連携アプリ
  • サービスは,最低限,Webブラウザをサポートする
  • サービス-クライアント間で使用するプロトコルは,HTTPとHTTPS のみに限定
  • クライアントは,マルチアカウントをサポートする(単一クライアントにおけるアカウントの切替,オプション)
★ユーザー認証について(オプション)
  • サービスは,複数ハードウエアや複数アプリからの,単一アカウントによる同時ログインをサポートする
  • サービスは,自社提供アカウントだけではなく,他社サービスのアカウントでも認証できるようにする(オプション,認証サービスの活用)
  • サービスは,最低限,そのサービス独自のアカウントを取得可能なWebページと,そのアカウントでログイン可能なWebページを持つ
★APIについて
  • サービスは,APIをその仕様と共に公開する
  • サービスは,APIを使用するクライアントやサービスは事前登録制とし,登録状態をWebで公開する(オプション)
  • サービスは,自APIを使用するクライアントやサービスについて,認証チェックを行う(オプション)
  • その認証チェックは,OAuthのようにワンクリックで認証でき,なおかつ,サードパーティにアカウントを保存しない方法が望ましい
  • APIには,サーバ負荷を軽減するために単位時間あたりの使用回数制限を設ける(オプション)
★サポートについて
  • サービスは,そのサービスに関するヘルプ,連携アプリ・サービス,技術文書等を提供する公式サイトを公開する
  • サービスは,そのサービスに関するディスカッションが可能な公式BBSや公式wikiを公開し,管理する
  • サービスは,個別ユーザーサポートのために,専用の問い合わせフォーム,メールアドレス,Twitterアカウントを公開する

モダンなインターネットサービスは,Webブラウザに依存しない

2011-01-12 12:27:36 | ネットワークサービス

モダンなインターネットサービスは,Webブラウザに依存しない.

モダンなインターネットサービスでは,HTML, Javascript, CSS, AJAX, HTTP を内部的に使用するため,Webブラウザとの親和性は高いが,Webブラウザは必須ではない.

モダンなインターネットサービスは,その機能を API として公開する.これによりサービスは,表示端末やユーザーインターフェースから自由になることができた.

SaaS 等の流行により,再びサーバ・セントリックな時代が訪れているが,それは TSS 時代のメインフレームとダム端末の関係とは異なる.

クライアント側には,PC,スマートフォン,スレート端末などのさまざまハードが存在し,その中で mashup アプリやWebブラウザを含む様々なソフトが動いている.しかも同じユーザーアカウントで複数ハード・ソフトを同時に稼働させている.




Skypeの全世界的不具合 - エピローグ

2011-01-05 04:43:17 | ネットワークサービス

昨年12月23日午前1時頃からほぼ24時間にわたって続いたSkypeの全世界的不具合.このようなSkypeの全世界的不具合は,2007年8月にも発生しており,その時にSkypeはその信頼性に深い傷を負った.特にビジネスでSkypeを使用していたユーザーは,Skype使用の断念を検討したはずだ.

しかしその後Skypeは安定的な運用が続き,信頼性はほぼ回復されていたと言ってよかった.不具合を体験した多くのSkypeユーザーは,同社が大規模不具合から得られたデータを元に,何らかの対策をシステムに対して行ったものと考えていたことだろう.ところが…

一般ユーザーのSkype需要が高まるであろうクリスマスイブの前日に,悪夢は再びよみがえった.

その時,ご存じのように,TwitterはSkype不具合のツイートに埋め尽くされ,サーバは過負荷状態となり,一時的にはクジラ状態(過負荷によるシステムダウン)に陥る場面もあった.Skype側が不具合の状況について,Twitterを使って報告を行ったことも,この過負荷状態の一因だったかもしれない.いずれにしてもSkypeは他のサービスをも巻き込みながら復旧にもがき苦しんだ.そして発生から20時間後,ようやくこの未曾有の全世界的不具合は終息を迎えることになった.

昨年12月29日SkypeのCIOである Lars Rabbe が,そのブログ上に「今回の不具合に関するお詫びと今後の対策」を発表した.そこには,今回の不具合の発生過程が書かれていた.それによると

  1. 22日:オフラインのインスタント・メッセージをサポートするサーバクラスターが過負荷状態に陥った
  2. Skype側は過負荷状態のサーバを使用不能(注:日本語訳では「機能不全」となっているが,原文では「disabled」)にしたり,あるいはサーバからクライアント要求を取り除くことで対処
  3. Skypeクライアントに対する上記サーバからの反応が遅延(上記対策が間に合わなかったため)
  4. Skype for Windowsクライアントのバージョン5.0.0152(注:全スーパーノードの25%~30%を含む)にはバグがあり,この反応遅延を処理できずにハング
  5. 多くのユーザーが上記クライアントを一斉に再起動
  6. 上記のサインイン処理のために,生き残っているスーパーノードネットワークに通常の100倍のトラフィックが発生
  7. この負荷に対して耐えきれないスーパーノードは,自己防衛システムを発動(注:おそらく他のノードからの接続拒否)
  8. 処理できない負荷は,生き残っている他のスーパーノードに転送され,同じくそのスーパーノードも過負荷状態になり,やはり自己防衛システム発動.
  9. 以下スーパーノードネットワークはデス・スパイラルに陥り(注:日本語訳は「肯定的なフィードバック」となっているが,原文は「positive feedback loop」であり,「正のフィードバック」が訳としては正しいと思われる),SkypeのP2Pネットワークにカタストロフィが訪れる
  10. Skype側が数百のメガ・スーパーノードを投入(注:投入の正確な日時は不明)
  11. 23日昼:全ユーザーの15~20%しか回復されていないため,数千のメガ・スーパーノードを投入
  12. 24日0時頃:大多数のユーザーの接続が回復
  13. 24日昼:グループビデオ通話リソースもスーパーノード化して投入
  14. 24日夕方~夜:スーパーノードネットワークの安定を確認
  15. 25日:上記リソースをグループビデオ通話用に戻し,ある程度のメガ・スーパーノードをネットワークから切り離す(注:一部は安定性確保のため残す)
というものだった.最初のオフラインメッセージ処理用サーバのオーバーロードが,なぜ起こったのかは記載されていない.ホリデーシーズンの影響もあったのかもしれない.その後の流れは,比較的単純だ.

この記事にはスーパーノードの機能についても,以下のように解説されている.
スーパーノードは通常のノードと比較して、ディレクトリーとして機能したり、他のスカイプ・クライアントをサポートしたり、それらの接続をサポートしたり、それぞれのスーパーノードごとに数百のピア・ノードをまとめたローカルな一群を作成する点において重要
上記に書かれているとおり,スーパーノードはSkype通信の接続中継(ルーティング)を行うのが主な役割だ.このいわゆるP2P通信は,サーバ経由通信とは異なり,負荷分散が簡単でインフラ投資が少なくて済む等のメリットを持つ.ただ今回の記述で,スーパーノードにディレクトリ機能があることを私は初めて知った.ディレクトリ機能とは,一般的な使用においては,メールアドレス(連絡先)等のデータベースを意味する.Skypeにおいては,おそらく通信相手のネットワーク上の位置を特定する機能だと推測される.またスーパーノードは数百のピア・ノード(スーパーノードに所属する通常のノード)を束ねていることから,スーパーノードは,この所属ピア・ノードのディレクトリ情報を持っているのだろう.通信相手のネットワーク位置特定は,おそらくスーパーノード同士のネットワークへの問い合わせによって解決されると想像される.また問い合わせ負荷を軽減するために,それぞれのスーパーノードはキャッシュを持っているに違いない.

さらに
オペレーション上のパラメータが期待値の範囲内でない場合、スーパーノードには自らを守り、それらをホストするシステムに不利益となる影響を避けるためのメカニズムが組み込まれています。

この自己防衛システムの詳細については記載されていないが,おそらくノードダウンに陥りそうな負荷がスーパーノードにかかったときに,他のスーパーノードからの問い合わせを拒否する機能と想像される.つまり自らをスーパーノードネットワークから切り離し,最悪な状態であるノードダウンを避ける方法だ.これならば,自己防衛システムを発動したスーパーノードに所属するピア・ノード同士の通信だけは,確保できる可能性が高い.またおそらく自己防衛システム発動スーパーノードは,定期的にスーパーノードネットワークに接続し,他のスーパーノードからの問い合わせ数をモニタリングし,負荷が許容範囲であれば,ふたたび問い合わせを受け付ける「自己防衛状態解除」システムも組み込まれているのだろう.

Skypeでは,この自己防衛システム発動のトリガーとなる負荷閾値を,現在のSkypeネットワークからの観測値とコンピュータ・シミュレーション等により,決定したのだろう.ただしご存じのように,P2Pネットワークは非線形でダイナミックな複雑系であり,ネットワーク挙動の完全な未来予測は不可能だ.今回,自己防衛システムは結果的には,スーパーノードネットワークを崩壊させる一因ともなってしまった.

ネットワーク挙動の完全制御は本質的に不可能であり,カタストロフィーに落ちる可能性を0にすることはできない.ネットワーク運営者にできることは,コストの許す限り,様々な,互いに独立した緊急時対策を,常に準備しておくことだろう.自己防衛システムによるスーパーノードネットワーク維持が失敗した時,Skype側にはまだ(最後の)切り札が残っていた.

それは,「メガ・スーパーノード」インスタンスの投入だった.ブログ記述によると

P2Pネットワーク上に何百ものスカイプ・ソフトウェアのインスタンスを作成し、複数の専用スーパーノードの働きを担わせました
(おそらくアウトソーシング仮想マシン上だと思われるが)Skypeは一時的に数百のスーパーノードをP2Pネットワーク上に投入し,壊滅状態にあったスーパーノードネットワークを支えようとしたわけだ.ただ…,この呼称には疑問が残る.なぜキロ(K=数千)にも満たない数百のスーパーノードで,メガ(M=数百万)なる呼称をつけたのだろう?確かに「キロ・スーパーノード」では頼りない印象を受ける時代ではあるが,もともと想定されていたスーパーノード投入数の単位は,数百ではなく,数百万ではなかったのか?

いずれにしても,緊急時シミュレーションをSkype側では行っているはずであり,緊急事態に対するメガ・スーパーノードの適切な投入量,その効果予想,さらには対策コストをも事前に計算していると思われる.しかし残念ながら数百という初期の投入量は,今回の危機に対して適切ではなかった.これが,SKypeネットワークの回復に24時間近くかかった要因となったのは間違いないだろう.

ブログ記事によると,SKype側は今後の対策として
  1. パッチ及びバグ修正済みクライアントの提供
  2. 新しい自動更新方法の検討
  3. 障害検知のスピードを上げる
  4. ベータテスト方法の検討
  5. 中核システム容量を定期的に見直す
をあげている.これらの対策は当然と言えば,当然のことだ.

ただ自分としては,メガ・スーパーノードの投入タイミングと投入量の判断について,全く記載されていないことに疑問が残る.もし迅速に数千単位あるいは数万単位のメガ・スーパーノードが投入されていたのであれば,もっと早く障害から回復できたのではないか?一端,崩壊してしまったP2Pネットワークが再び正常化するまでの時間は,線形ではないはずであり,それをSkype側も熟知していたはずだ.初期に大量のメガ・スーパーノードが投入されていれば,カタストロフィに陥る前に,SKypeネットワークを安定させることができ,しかもすぐにメガ・スーパーノードを離脱させ,メガ・スーパーノード維持コストをも押さえることができたかもしれない.Skype経営陣の判断は適切だったのだろうか?それとも「緊急時対策コストを最小限に抑えるために,カタストロフィ発生から復旧までには,24時間かけてよい」という危機管理ポリシーが存在するのだろうか?

サービスのダウンタイム時間と,ユーザーの信頼度の関係も,線形でないように私には感じられる.Skype側は「復旧がクリスマスイブに間に合って良かった」としているが,信頼を再び裏切られたユーザーの失望感やSkype使用に対する不安が,クリスマスイブに影響しないとでも言うのだろうか?今回の不具合対策発表の他に,有料ユーザーには30分無料通話クーポンを配布しているようだが,無料ユーザーには何もないのだろうか?実際,無料ユーザーの中でも一部のユーザーは,スーパーノードとしてSkypeネットワークを支え,それに貢献しているユーザーもいるはずだ.

これを機に,Skype側はスーパーノードであるクライアント上に,それを明示し,サービス貢献度(処理量・サービスアップタイム)に応じて,無料通話クーポンやポイントなどの何らかのキックバックを与えてはどうか?そうすれば,そのユーザーはスーパーノードをできるだけ維持するように,以前よりも努力するだろう.

いずれにしても,今回上げたSkype側の対策案はまだ不十分に思う.危機管理にはいくらでもコストをかけることはできる.したがってどこまで危機対策を行うのか,明確な危機管理ポリシーを経営陣は採択する必要がある.AUをはじめとして,Skypeが今後の携帯端末やスマートフォンに採用されていくのは間違いないだろう.そうなればSkypeネットワークはさらに大規模な社会インフラとなると同時に,その複雑度を増し,挙動予測はますます難しくなる.そのような状況下で今回のような大規模な不具合が発生すれば,社会的混乱すら招きかねない.Skype経営陣には,社会インフラ企業としての自覚を持って,危機管理ポリシーの再検討に着手していいただきたい.


Skypeの全世界的不具合,(今度こそ)終息へ向かう

2010-12-23 23:57:18 | ネットワークサービス
私の所持するSkypeの2つのアカウントは,2台のWindows PCにそれぞれ設定してあるが,2010/12/23 23:33に両方のアカウントでサインインに成功した.この両アカウントは互いに,相手をコンタクトリストに登録しているが,互いにオンライン状態を確認できている.この両者間で文字チャットや音声チャットも可能な状態だ.

ただしGoogleリアルタイム検索,及びTwitterクライアントsobeesによるキーワード検索を観察すると,SkypeのP2Pネットワークが完全に安定していないためか,現在も接続できていないユーザーや,サインイン・サインアウトを繰り返すユーザーも存在する模様.SkypeのP2Pネットワークが安定な状態にならない限り,今後再びSkypeからサインアウトされたり,サインインできなくなる可能性も否定できない.

気になる復旧の状況についてだが,Skype公式Twitter(@Skype)によると,本日23時にはすでに1000万人ほどのユーザーがサインインしている状態と推測している.ちなみに,私のSkypeの表示では,890万人ほどがオンラインであると表示されている.Skype基幹技術がP2Pネットワークであるため,復旧は今後も徐々に進んで行くのではないかと思われる.


続報:Skypeの全世界的不具合,終息へ向かうもまだ不安定

2010-12-23 18:57:44 | ネットワークサービス
私の所持するSkypeの2つのアカウントは,2台のWindows PCにそれぞれ設定してあるが,2010/12/23 18:35現在,1台はサインインした状態,もう一台がサインインできない状態が継続している.一時は2台ともサインインし,安定的接続を維持していたのだが,現在は再びSkypeのP2Pネットワークが不安定になっているようだ.

今回の不具合(スーパーノード数の減少)に対してSkype側は,メガ・スーパーノードを確保し対処を行っている.本日16:00頃になされたSkype公式ツイートでは,おおむね復旧したかのように見えた.実際,私のSkypeにおいては,その後一時的には正常な状態に戻ったようだったが,再び現在のように不安定な状態になってしまった.

もしかしたらSkype側が適切なスーパーノードが確保できたと判断し,経費のかかるであろうメガ・スーパーノードの一部あるいは全部を引き上げてしまった結果,再び不安定になってしまったのかもしれない.ただし,メガ・スーパーノードが
  • どのように生成されたのか(P2P上のクライアントの強制スーパーノード化?Skype側からの提供?)
  • どのように維持されている(いた)のか(処理能力の増減調節を行っているのか?)
がわからない以上,これも憶測に過ぎない.

プロプライエタリな技術であるSkypeが,さまざまな技術情報やネットワーク状況を,ユーザーに報告するのは難しい事は理解する.ただ,今回のような大規模不具合に対し,公開されている情報があまりにも少ないのではないか?

有料のユーザーが存在するサービスである以上,真摯な対応を望みたい.


続報1:Skypeの全世界的不具合,終息へ

2010-12-23 17:23:34 | ネットワークサービス
Skypeの全世界的不具合は,広範囲において終息してきており,大多数のユーザーがサインインできるようになってきている.私の所持するSkypeの2つのアカウントは,2台のPCにそれぞれ設定してあるが,両方とも同時にサインインが可能になった.

しかしそのうちの1つのアカウントについては,2010/12/23 17:13現在,再びサインアウトされ,接続リトライ状態に入ってしまった.未だSkypeのP2Pネットワークが安定していないようだ.特に多くのノードが一斉にリトライを始めてしまうと,再びP2Pネットワークに過負荷状態になる可能性がある.接続リトライ状態のユーザーは,手動サインアウトし,P2Pネットワークの負荷が下がるのを待った方がよいかもしれない.

取り急ぎご連絡まで.




Skypeの全世界的不具合,終息へ

2010-12-23 16:28:48 | ネットワークサービス
Skype公式Twitter(@Skype)によると,Skypeの全世界的不具合は,1時間ほど前に広範囲において終息した模様.Googleリアルタイム検索およびTwitterクライアント sobeesによる観測からも,大多数のユーザーが接続可能の状態になったことがわかる.おそらく安定的なスーパーノードの数が,ある程度確保できたのだろう.

2010/12/23 16:20現在,私のSkypeはサインイン可能であり,数人のオンライン状態も確認できている.

取り急ぎご連絡まで.




続報3:緊急連絡!Skypeが全世界的に使用不能 - サインアウトできないケース

2010-12-23 06:19:54 | ネットワークサービス

今回のSkypeの全世界的不具合について,Googleリアルタイム検索とTwitterクライアント sobbesを用いて,Skypeに関する全世界のツイートを観測している.

主なツイートは「サインインできない」というものだが,中に「サインアウトできない」というツイートも散見される.これは単純にサインイン・サインアウト系の不具合なのかもしれないが,もしかしたら今回のようなスーパーノード不足時に,サインインしているスーパーノードのユーザーは,サインアウトができないように,Skype側が制御できる仕様なのかもしれない.Skype側のサーバのみで,メガ・スーパーノードを作り出すのは確かに限界があるような気もする.

以上は憶測ですので,悪しからず.

Skypeの復旧状態の確認は下記リンクで.
Skype公式Twitter(@Skype)




続報2:緊急連絡!Skypeが全世界的に使用不能 - Twitterにも波及か?

2010-12-23 05:13:36 | ネットワークサービス
今回のSkypeの全世界的不具合に伴い,大量のツイートが発生し,Twitterのサーバが一時的に過負荷状態に陥った模様.このため一時にTwitterが使用不可能となったが,2010/12/23 5:09現在は回復した模様.ただし,今後再び過負荷状態に陥る可能性もあるので,Twitterユーザーは十分注意されたし.

Skypeの復旧状態の確認は下記リンクで.
Skype公式Twitter(@Skype)




続報1:緊急連絡!Skypeが全世界的に使用不能に

2010-12-23 04:37:37 | ネットワークサービス
今回の不具合に関する記事(英語)が,Skype公式ブログに発表された.それによると「ある問題が発生し,それがあるバージョン(複数)のSkypeに影響を及ぼし,多くのスーパーノードがオフラインになった」のが,原因とされている.

これに対し,Skype側は「メガ・スーパーノード」を作成して対応中とのこと.この問題の収束には,数時間はかかるとの見通しを明らかにした.

取り急ぎ御連絡まで.


緊急連絡!SKYPE が全世界的に使用不能に

2010-12-23 04:19:17 | ネットワークサービス

 緊急業務連絡です.2010/12/23 3:55現在,高品位音声チャットで有名なソフトSkypeが,世界的に使用できない状態に陥った模様.

 具体的な現象としては,サインインができないため,Skypeの全機能が使用できない.このような全世界的不具合は,2007年8月にも発生したが,今回も同じ原因で発生した可能性がある.

Skypeユーザーはできるだけサインインを控えて,Skypeのサインインサーバが復旧するのを待った方がよいだろう.

Skypeの状態は,下記リンク先を確認されたし.
Skype公式Twitter(@Skype)はこちら.



Twitter の「軽さ」と企業による活用

2010-12-01 10:00:23 | ネットワークサービス
Twitter@watermindpc)を始めてから,ブログを書くことが少なくなってしまった.自分の場合,比較的長い文章でも,Twitterで書いてしまう癖があるためだが,世界規模だったブログサービス Windows Live Spaces が終了し,WordPress.com に移行するところを見ると,ブログサービスもいろいろとたいへんらしい.

ブログ継続には努力が必要となる.ブログはまとまった文章や画像付きとなる場合が多く,思いつきで書くわけにはいかない.ある程度の推敲も必要となるため,1つの記事作成にかかるコストが大きい.そのためブログの継続には,モチベーションの維持が必要となるのだが,アフィリエート・アクセス数・コメント・トラックバックによる報賞が,記事作成コストに見合わない場合もある.よって自然消滅していくブログは多い.

Twitterの良いところは,その軽さにある.140文字の制限は,くだけた表現・省略表現・他人にはわからない独り言といった,本来ならば極めて限定された空間で行われるべき発言を,インターネットという衆人環視状況下でも許すという文化を作り上げた.Twitterの軽さの本質は,この発言内容の軽さにある.発言内容の軽さは,読み手側の読みコストも減らすことに成功した.つまり流し読みを可能としたのだ.ふんわりと空に浮いているかのようなTwitterの鳥のキャラは,正にこの「軽さ」をシンボライズしたものと言える.

このようにして Twitter は,いままでブログが取りこぼしてきた,軽いパーソナルな情報を拾い上げる標準的ツールの地位を確立した.が,Twitterが一般ユーザーに認知されるようになってくると,その役割も変わらざるを得なくなってきた.

Twitterには,
  1. Webサイトやブログといった情報提示
  2. メールやIM(インスタント・メッセンジャー)といったコミュニケーションツール
  3. メーリングリストやメルマガといった同報通信
  4. RSSのような更新通知付きブックマーク
  5. FaceBookやmixiといったSNS
の側面がある.

またTwitter自身はその機能を限局しているため,他社サービスとの連携が最初から考慮されている.

これらの特徴は,従来のサービスをTwitterの付帯サービスの地位におとしめ,また同時に,新興のサービスをTwitterの中に吸収していく事を可能にした.結果,かつてYahoo!等のポータルサイトがそうだったように,Twitterはすべてのネットサービスの入り口となる可能性をはらんできたのだ.しかもTwitterでは,ポータルサイトでは提示できなかった極めてパーソナルな情報をも,他の一般情報とともに一元的に提示可能となっている.これはネットプレゼンスが必要な企業にとって見過ごすことのできない事態だ.

Twitter企業アカウントの主な顧客向けの役割は,次のようになる.
  1. 今まで取りこぼしてきた顧客の意見を吸い上げる情報収集(特にキーワード検索)
  2. 顧客との,より深いコミュニケーションとその公開
  3. 企業の現状を発言することによる透明性の確保
  4. 新着情報やサイト・ブログ更新等の告知
  5. 上記活動に伴って発生した情報の共有・公開
これらを実現するためには,企業側が適切なTwitterアカウントを取得し,そのアカウントを顧客に認知させ,フォローしてもらう必要がある.メールアドレスと異なり,Twitterのアカウントは顧客に認知されるだけでなく,フォローされなければならないところがポイントだ.さらにTwitterでは簡単にフォローを止めることが可能であるため,顧客にフォロー状態を維持してもらう努力も必要となる.

企業Twitterアカウントの認知徹底については,ほぼサイトアドレスやメールアドレスと同じだ.メールの署名やWebサイト・紙媒体にアカウントを提示し,さらにtwinavi等のディレクトリサイトにアカウントを登録する.Webサイトの場合は,最低でもそのアカウントのタイムラインへのリンクをおいた方がよいだろう.余裕があれば本ブログのように,ツイート内容を表示するガジェットをWebサイトに埋め込んでも良いかもしれない.

顧客にフォローさせる方法に関しては,基本的にはWebサイトならば,リンクでタイムラインへ導けば簡単だ.紙媒体の場合は,QRコードを印刷し,簡単にアカウントのタイムラインに誘導することが望ましいだろう.

一番難しいのがフォローの維持だ.このフォローを維持させるためには,顧客のニーズに合わせて,ツイートの発言頻度や内容を調整する必要がある.発言頻度が多いとうるさく感じられるが,発言頻度が少ないと読み飛ばされてしまう可能性がある.また発言内容が常に軽いとフォローを止めてしまう可能性もあるが,重要情報だけツイートしていると親近感や透明性の確保が難しい.そのため一企業で,複数のTwitterアカウントを準備し,ユーザーの用途別に運用する必要が出てくるかもしれない.またクーポン的なものやタイムサービス的な情報を,定期的にツイートするのも効果的かもしれない.いずれにしてもフォロー維持に関しては,試行錯誤が必要となるだろう.

最後に最も重要なのは,Twitterそのものを顧客に知ってもらうことだ.Twitterは,TVやニュースでも取り上げられることが多くなったが,まだケータイ文化に慣れ親しんだ若者が主要ユーザーだ.顧客に中高年が多く含まれと想定される場合,Twitterの簡便性を認知してもらい,日常的に使う情報ツールとして使っていただく必要がある.そのためにはまず,企業アカウントをフォローすると得られる具体的なメリット(特典や値引き等)をアピールすると同時に,Twitterの簡単な導入方法や使い方をWebサイトなどに掲示するとよいだろう.

いずれにしても,Twitterの持つ「軽さ」は,企業にとって致命的なダメージを与える場合も考えられる.企業Twitterアカウントの責任者は,それを肝に銘じ,Twitterをうまく活用して欲しい.

参考資料:TwitterやFacebookなどで企業はどうしたらアンフォローされないか


Windows7 XPモードにおけるFDD

2010-03-18 06:50:29 | Windows
 私が,私的にFDを使用しなくなってから,既に数年が経ったように思う.ただし仕事では未だにFDを使用する機会は多い.古い業務用アプリの再インストール等では,未だにFDを使っている.またそのような古いアプリは,FDDの存在が前提となっている場合もある.このような理由から新品FDを常備している事業所も,まだ多く存在することだろう.つい先日にも,ゆうちょ銀行の支店でFD紛失事件が発生したことからも,FDが未だに生き延びていることがわかる.

 ただしその古いアプリを動かしていたPCは,どんどん老朽化するため,PCのリプレースはほぼ避けがたい.このようなケースのリプレースでは,以前はWindowsXP PCを確保する事が重要とされてきた.そのようなアプリがWindowsXPではなんとか動いても,WindowsVistaではまったく動かないケースがあったからだ.しかし,今は違う.

 Windows7のXPモードは,「Vistaで動かずXPでは動くアプリ」を,Windows7内で動かすしくみだ.XPモードを使えば,Windows7のデスクトップに,もう一台のWindowsXPマシンが内蔵されているかのような,仮想のWindowsXPマシンを作り出すことができる(仮想マシン).この仮想XPマシンに,「Vistaで動かずXPでは動くアプリ」をインストールすれば,問題なくそのアプリは作動するはずだ.

 もちろんVirtualBoxのような,フリーの仮想マシンソフトを使用すれば,このようなことはできないわけではない.ただしその場合は,Windows7とWindowsXPの両方のOSライセンスが必要となってしまう上に,仮想マシンにOSをインストールする手間もかかる.XPモードを使用すれば,XPのライセンス料金(注:Windows7 pro以上でXPモードは使用可能なので,厳密には料金は取られている)や,XPのインストールは不要だ(注:最初の初期化にやや時間がかかる).

 さらにありがたいことにXPモードには,自動「統合機能」が存在する.この機能は,ホストOS(Windows7)側に存在するドライブやプリンタ等を,ゲストOS(WindowsXP)側と自動的に共有する機能だ.これらのドライブやプリンタはネットワークドライブ・ネットワークプリンタ扱いとなるが,この理由がおもしろい.

 実はXPモードは単純な仮想マシンソフトではなく,仮想マシンにリモートデスクトップで接続し,その画面を表示している(注:画面表示方法等で厳密には通常のリモートデスクトップとは異なるかもしれない).そのため,リモートデスクトップの持つ「リモートセッションでのローカルリソース(プリンタ・ドライブ等)の使用」が可能なのだ.つまり統合機能は,XPモードの機能と言うよりも,(ほぼ)リモートデスクトップの機能と言うことができる.

 この統合機能を利用すれば,USB接続の外付けドライブも含めて,Windows7PCのすべてのドライブに,仮想のWindowsXPマシンからアクセスできる.

 ちなみにXPモードには,PC本体にUSB接続されているドライブを,仮想マシン側にリダイレクトする機能を持っている.XPモード画面の「USB」メニューからUSB接続ドライブを選んで「共有」すると,そのドライブは仮想のXPマシンのUSBポートに接続したような状態となる.注意したいのは「共有」と言っても,実際には共有ではなく,ホストOSからUSBデバイスは切り離され,ゲストOSに「占有」される点,すなわちリダイレクトである点だ.したがって,この操作を行うと,Windows7のマイコンピュータからそのUSB接続ドライブは消えてしまう.

 さてこのように,ホストOSのリソースに簡単にアクセスできるXPモードだが,やっかいな問題もある.XPモードの仮想マシンは,なぜかFDDが一台接続されたことになっているが,その仮想FDDをホストOSのFDDに割り当てることができないのだ!ではなぜFDの使用不能な,いわばフロッピー挿入口のない仮想FDDが存在するのか?

 やはりそれは,FDD(ドライブA)の存在をチェックする古いアプリが存在するからだと推測する.すなわちドライブAが存在しないと,起動すらしないアプリのための対策だ.この対策でそのようなアプリは起動するにはするが,その後ももちろんドライブAは使用できない.しかしドライブAの使用が必須でないのであれば,起動さえすればOKだ.でもハズレかな?なぜならば,仮想FDDにホストOSのFDDを割り当てる設定を設けるぐらいたいしたコストではないと思われるのに,それがないということは,むしろ意図的にドライブAを使用させないようにしているのではないか?と思えてくるからだ.ちなみに外付けUSB接続のFDDを「共有(リダイレクト)」すると,見事にドライブBとなる.実際の古いアプリでは,ドライブAに対するアクセスが必ず発生するものもある.そのようなアプリはどうして動かすのか?これは大きな問題だ.

 とはいえ,既にこの問題に対するいくつかの回答が出ている.正当な対処方法は,仮想マシン構成ファイルを編集することのようだ.ただ私の場合は,別の方法で対処した.以下はその手順.なお統合機能によりドライブは共有されているものとする.またホストOSにはFDDが接続され,そのドライブ文字がAであるとする.
  1. XPモード仮想マシンを立ち上げる(注:以下の操作はすべて仮想マシン内での操作
  2. XPモード仮想マシン内でデバイスマネージャを開く
  3. フロッピーディスクドライブの冒頭の+をクリック
  4. 表示されたフロッピーディスクドライブを右クリック
  5. 「無効」をクリック
  6. デバイスマネージャを閉じる
  7. スタートボタン→マイコンピュータとクリック
  8. 表示されたマイコンピュータ内にFDDが存在しないことを確認
  9. マイコンピュータ内に「(ホストOSのコンピュータ名)のA」と表示されているネットワークドライブ(ホストOSのFDD)が存在することを確認する
  10. ツールメニューをクリック
  11. 「ネットワークドライブの割り当て」をクリック
  12. ドライブとして「A:」を選択
  13. フォルダとして半角で「¥¥tsclient¥a」と入力
  14. 完了をクリック
  15. マイネットワークにネットワークドライブとして「TsclientのA(A:)」が表示されているのを確認.これでホストOSのFDDがゲストOSのドライブAとなった.
  16. 必要ならば上記のドライブを「FDドライブ」等のわかりやすい名前に変更
 アイコンはネットワークドライブだが,この操作によって,ゲストOSのドライブAがホストOSのFDDとなったはずだ.この方法がベストかどうかはわからないが,比較的簡単にできるのでお試しあれ!



楽器としてのNintendo DSi LL

2009-11-23 14:12:30 | ハードウエア
 自分の所有しているNintendo DSiは,事実上,携帯楽器兼DTMマシンと化している.すなわちDSソフト「大合奏!バンドブラザーズDX(略称:バンブラ)」専用機となっていると言って良い.このソフトと出会ってから,DSiはゲーム機ではなく,「自分の身体の延長=楽器」としてとらえるようになり,それまででは考えられない「愛着」をDSiに感じるようになった.バンブラとの出会いは.それまで自分が何十年間か持っていた音楽観を,全く変えてしまうほどの衝撃的な事件でもあった.

 詳しいバンブラの解説は他のページに譲るが,このソフトは画面に表示された譜面を見ながら,ボタンを押して音を出し,演奏する楽器ソフトだ.譜面は楽器毎に8パートに分かれており,プレイヤーはその中の一つを演奏し,残りのパートはDSが自動演奏する.つまり「楽器のカラオケ」だ.また通常のボーカルのカラオケ機能を搭載しているため,メロディパートは演奏せず,歌うことも可能.さらに無線LANにより,各パートを担当する他のプレイヤーとともに,合奏することも可能であり,気軽にセッションを持つことができる.セッションの時に問題になる「実力差」も,バンブラの演奏操作は,その熟練度により,単純な方法(1個のボタンを使用)から複雑な方法(10個のボタンを使用)まで選択きるため,未熟なプレイヤーが演奏の足を引っ張る事が少ない.そして極めつけは作曲機能(簡易DTM)で,各パート毎に譜面を入力し,アップロードすることにより,バンブラのすべてのユーザーを対象にして曲を配信することができる(ただし審査を通過する必要がある).

 私の場合は,ヘッドフォンを使用して,一人で演奏することはもとより,友人や母親とセッションしたり,耳コピによりポップスなどを打ち込み,サーバに投稿するなど,カラオケやフリー演奏(楽譜なしでの演奏)以外のバンブラの機能はフルに使用している.すでにソフトを購入してから1年以上経っているはずだが,全く飽きることなく,ちょっとした時間や気分転換が必要だと感じた時に演奏を楽しんでいる.ちなみに耳コピによる打ち込みは,莫大な時間がかかるため長期休暇時のみ.

 こんな私が「Nintendo DSi LL(以下LLと略す)」の発売を知ったのは,偶然に見たTVCMからだった.その名称やTVCMから受けたLLの印象は,「お年寄りのために画面を大型化しただけのDSi」といったものだった.この軽薄短小の時代に,LLを発売する理由が他にあるだろうか?すでにDSiを持っている私にとっては,「2万円も払って,改めて購入する必要もないもの」とその場では判断し,しばらくの間,LL新発売への関心は薄れていた.ところがその後,あるきっかけから,心の片隅に妙にむずむずした何かを感じ始めた.それは,最近バンブラ譜面として配信された中島美嘉の曲「Will」のベースパートを練習していた時だった.

 自分の場合,10個のボタンを使用して演奏している(操作タイプ:マスター)のだが,この曲のベースパートはかなり難しい(レベルは最高難度★10個).このような難曲の練習中は,どうしても力んでしまい,指の動きにより画面が揺れるため,譜面を目で追うことができなくなる.このため目の疲れ方が尋常ではない.さらには力みによって,DSiを支える手や指がだんだん痛くなってくる.

 バンブラマスター操作では,3つのボタンの同時押し(Lボタン+Rボタン+他のボタン)が存在する.私の場合,強くLRボタンを押してしまうため,通常の持ち方では,本体の位置がカラダの方向にずれてしまう.これを防ぐため私の場合は,両手の小指を本体前方側面に立て支えているのだが,これはたいへん不自然な持ち方だ.しかもこの方法でも,だんだん本体が手のひらの中でカラダ側にずれてくると,DSiの底面隅にある足(小さな突起)が,小指と薬指の間の根本に食い込んできて,これが非常痛い.

 疲れるのは目や指だけではない.意外なことと思われるかもしれないが胸や耳も疲れる.胸はDSi本体が操作によってできるだけ揺れないように,脇を締め,両手で横から挟むように持つため,大胸筋に力を入れているためだ.また耳かけヘッドフォンを使用しているため,耳たぶもかなり痛くなってしまう.

 このような状態でベースパートの通し練習と部分練習を繰り返していると,やはり一段落つく毎にかなりの疲労感を感じてしまう.そんなときにふと思った.「もしもあのLLで演奏したらどうなんだろう?」

 以前はDS Liteでバンブラ演奏をしていたのだが,DSi発売をきっかけにバンブラをDSiに移行した時に非常に驚いた.DSiではDS LiteよりABXYボタンの高さが低くなり,「こすり」奏法(指の腹で連続的にボタンをこすって高速に演奏する方法)が,やりやすくなっていたのだ.十字キーも高さが低くなり,同じく,こすり演奏しやすくなった上に,十字キー特有の「ぐらつき」が減少していた.もちろんDSi最大の特徴であるやや大きくなった画面により,楽譜はDS Liteよりも見やすくなっていた.しかもDS Liteではつるつるだった底面が,DSiでは滑り止め加工になっていて,感触も良くなった上に,手が汗ばんできても滑らなくなった.音量調節はDS Liteのアナログ的なボリュームから,デジタル的なサイドボタンとなり,フリー演奏時に素早く的確に音量を操作できるようにもなっていた.

 私にとってこれらの職人芸的改良は,DS Liteの改良と言うより,バンブラのための改良,さらに言えば楽器としての改良にすら思えたのだ.もしやこれらの改良がLLに対しても施されているのではないか?仮に改良されていなかったとしても,最もバンブラ演奏に向いているとされている初代DSに近い大きさを持つLLならば,少なくとも演奏しやすいのではないか?そして何より確実言えることは,目には優しいはずではないか!これは!

 この最後の「目に優しいDS = DSi LL」という部分が決め手となり,LLに対する評価が一気に変わり,発売当日にLLを購入した.通常,製品の初期ロットは購入しないというのが私のポリシーだが,LLは例外的扱いとなった.実際,DSでバンブラ演奏をやり始めてから,視力は確実に落ちており,健康面の不安があったのは事実だ.

 結論から言うと,バンブラ楽器としてのLLは,DSiよりも優れていると思う.特に画面が大きくなった効果は絶大だ.演奏していても目が疲れない上に,画面が揺れてしまった場合でも,DSiよりも譜面を追うことが楽になった.またDSiよりも本体を目から離すことができるようになったため,演奏姿勢も以前より良くなった気がする.

 演奏ではないが,バンブラ作曲を行ったことがあるユーザーは,長時間小さな画面を見続けなければならず,非常に苦痛やストレスを感じていたはずだ.私自身もバンブラ作曲時に,これだけ作曲が苦痛ならば,思い切ってバンブラから,PCのDTMソフトに移行してしまおうかという誘惑に何度も駆られた.DTMソフトならば,PCの大画面のモニタとマウスで操作ができ,さらにはバンブラ作曲上の様々な制限もないからだ.LLの大画面は,このバンブラ作曲作業上の苦痛をかなり解消してくれるものと期待している.

 バンブラの画面デザインは,ペンでタップするよりも,指で直接画面に触れることを想定していると思われる個所が多い.例えば「戻る」ボタンの位置は,明らかに右手親指で直接触れることを前提としている.しかしながらバンブラ画面操作のすべてが,指による操作を前提としているわけではない.例えば曲検索におけるキーボード画面がそれだ.指で押せないわけでもないが,DSiの画面ではボタンが小さいため指での入力は困難だった.

 LLの大画面ではありがたいことに,このキーボードボタンも大きく表示されるため,指での操作が可能となった.小さな事ではあるが,煩わしいペン操作がなくなったのはうれしい限りだ.

 ただしLLの画面も弱点はある.例えばDSiに比べて,やや粒状感(ざらつき)があり,白地の画面になった場合に特に目立つようだ.さらにDSiよりも輝度がやや低く,全体的に少々黄色が強くなっている.バンブラの場合,黒地の画面が多く,また色はほとんど演奏に関係しないため,大した問題とは言えないだろう.

 ABXYボタンについては,若干DSiよりも高くなったように思う(以下,やりこんだDSiとの比較であるために,正確には不明).そのためキーのストロークも長くなっていると思われる.キーの重さも,LLのほうがDSiよりもやや重い感じなので,LLの方が誤ってボタンを押すことは少なくなるが,発声させるためには,DSiよりもしっかりボタンを押す必要があるかもしれない.これらはこすり奏法等に影響があると思われるが,どちらが演奏しやすいのかはまだ判断できない(曲によって,演奏しやすさが異なる可能性あり).

 また押し込みきった時のボタンの高さもDSiよりも若干高くなっているようで,押し込み時にボタンの輪郭が指にはっきり感じられる.DSiでは押し込みきった時に,ボタン輪郭があいまいになるが,隣のボタンとの位置関係を把握するためには,LLのほうがよいのかもしれない.キーの大きさ・膨らみ具合・表面加工・各キーの間隔などはDSiと変わらないように思う.

 十字キーについては,DSiとほぼ同じだが,LLではキーを離した時に「ポコッ」という比較的大きな音がする.筐体が大きいので,中で共鳴しているのかもしれないが,やや気になる点ではある.ヘッドフォンをして演奏しているのであれば,もちろん問題はない.クリック感はDSiよりもやや強いので,キーが入ったかどうかはDSiよりもわかりやすいかもしれない.

 音量のサイドボタンは,他所でも書かれているとおり,DSiよりも高くなり,上げと下げボタンが離れたため,明らかに操作はし易くなった.

 LRボタンについては,DSiよりもクリック感やクリック音が小さくなり,キーも軽くなったように思う.バンブラではRキーをオクターブを上げるために押し続けることが多いが,キーが軽くなったことにより,押し続けても指の疲れが少ないかもしれない.また曲によっては半音を下げるLキーをABXYボタン並みに使用する部分を持つ場合もあるが,キーが軽くなったことにより,疲労の少ない高速な打鍵が可能になったように思う.

 劇的に変わったのは本体の持ち方だ.前述のLRキーが軽くなったことと,本体のホールド感が向上したことによりに,LRキーを押しても,本体がカラダ側にずれることが少なくなった.これにより,小指を本体前方側面に立てる必要はなくなった.

 奥行きが深くなったため,DSiのようにLRキーをすべて覆うように指はかからなくなった.自分の場合はLRボタンの半分ぐらいを覆う程度だが,演奏に支障は感じられない.

 自分の持ち方では,LL本体前面の角は薬指の根元あたりにくる.角のあたる位置は,DSiとほぼ同じなのだが,LLの角はDSiよりもゆるやかに湾曲しているため,長時間あたっていても,あまり痛くならないようだ.しかもあの,削り取ってしまおうかと思ったほど痛かったDSi底面の足が,LLでは大きく低く丸い足に変更されていた.

 重さについては,確かにDSiよりもかなり重い.が,この重さは本体位置のホールドの安定感にもつながっているように思う.長時間演奏には影響がないとは言えないだろうが,短時間の演奏であれば,ほとんど問題はないだろう(ただしユーザーが子供の場合,手に対して本体が大きく,また重いため,演奏に支障が出る可能性はある).

 最後にスピーカーだが,これも他所で言及されているように音質が若干向上している.DSiでは,音がややこもった感じがしていたが,LLではそのような感じはなく,クリアな感じがする.ただし音量に関しては,どちらも同程度のようだ.

 実に長々と書いたが,自分のようにDSをバンブラ楽器として使用しているユーザーは,できたら試奏したうえで,早急にLLを購入したほうがよいと思う.これは特に眼の健康のためにお勧めする.DSが2台になってもったいないと思われるユーザも多いかもしれないが,1台目のDSが無駄になるわけでもない.LLを家での練習用やセッション本番用に使用し,DSiは普段持ち歩き,時間が空いた時に素早く取り出して,軽く練習する等の使い分けができると思うからだ.最後に言い訳がましいが…

「本レポートは個人的感想であり,客観的資料に基づいたレポートではありません.また本レポートは一個人の購入したLLに関するものであり,すべてのLLに当てはまらない可能性があります.ご注意ください.」