水無月ばけらのえび日記

bakera.jp > 水無月ばけらのえび日記 > 2009年のえび日記 > 2009年11月

2009年11月

2009年11月28日(土曜日)

楽天Webディレクション&デザイン2009: 常に改善、常に前進 変わり続ける楽天市場トップページ!

公開: 2009年12月12日23時30分頃

メールマガジンの話の後は、「常に改善、常に前進 変わり続ける楽天市場トップページ!」。楽天市場のトップページを改善してきたお話。

楽天市場トップページ
  • トップページ担当: 5名
  • 1997年5月開始: 13店舗、売上げ32万円。売上げの半分は三木谷氏購入という噂も……
  • 現在は3万店舗、600億円に成長。
  • 2008年の注文実績は8900万件、これは0.3秒に1回の購入実績
  • トップページのPVは490万/1日、1秒に57回アクセスされている
変遷
  • 2005年にはほぼ現在のスタイル
  • 細かなチューンナップを繰り返す
  • 大幅に変更してしまうと、蓄積されたユーザー学習効果が失われることにより、重要指標への影響リスクが大きい
改善の例
  • 商品検索経由の購入転換率が高い
  • 検索の利用率が上がれば流通アップ→目立たせたい
  • 検索窓を大きく?
  • ABテストを実施: 従来ページ90% / テストページ10% (テストパターンの数だけ案分)
注意事項
  • 対象の母数を揃える (表示率を揃える)
  • 他要素への影響度合いも比較する (検索は良くなったが、他は悪化→×)
  • テスト期間やサンプル数を考慮する。期間が短い場合は表示率を上げる
成功事例
検索窓のサイズ
  • 検索窓の幅を変更: A.昔のまま / B.幅が広いバージョン
  • 結果: B の流通貢献度 +0.36%
  • 0.36%は小さく見えるが、半年で13億円の改善。この規模の改善を10箇所で行えば、130億円のプラスとなる
テキストの修正
  • A.シューズ / B.靴
  • 結果: 「靴」の方がクリック率 +17.5%
  • ただし、効果についてはこの項目単独で判断しているのではなく、他の要素のクリック率も考慮している
バナー
  • デザイン・モーションの異なるパターンを作成してABテスト
  • 半年かけてFlashバナーのスタイルを確立した
  • 結果: 動的Flashバナー +0.24%
失敗事例
ジャンル一覧の改善
  • ジャンルが探しづらいのでは?
  • ジャンルをグルーピング化してアイコン化 → 長期間試したが、従来のものの方が良かった
  • オンマウスでサブジャンルをポップアップ → サブジャンルへの移動は増えたが、戻ってくる率が非常に高かった
  • そのようなニーズがなかった事が分かった
  • とりあえずやってみる、の精神。仮説には限界がある。
  • 失敗は成功のもと。失敗を繰り返すことによって成功要因を絞り込める。
  • テストは小数でやっているので、リスクは大きくない。
  • 事実に勝る根拠はない
テストの落とし穴
  • 計算できる馬ハンス : 試験者を変更・目隠しをしてテスト・群衆の中でテストしても正解を出した。出題者らが答えを知らない状態で出題すると……。
  • 数字だけを根拠にしていると、根本を疑うことができなくなる
  • 結果を疑うことも大事
Q&A
  • 全部署・全ページでABテストができているわけではない
  • トップページにはサーバサイドのツールを入れている
  • ABテスト中に「これは何?」などの問い合わせを受けたことはない。そもそも、それほど悪影響のあるテストはしていないし、おかしいと気付いても問い合わせするほどではないのではないか。

ABテストで結果を出してきたというお話ですね。興味深いのはジャンル一覧の改善が失敗したという話。実際には画面キャプチャつきで説明されていたのですが、ビジュアルつきで分類されたもののほうが明らかに良さそうなのに、それが負けたというのは驚きました。負けっぷりの詳細が分からないので何とも言えませんが、そもそもジャンルはメインで使われていないので目立たせても仕方ない、ということなのかもしれないですね。

関連する話題: Web / RWDD2009

楽天Webディレクション&デザイン2009: 1,000万人のメルマガ購読者を飽きさせない仕掛け

公開: 2009年12月12日12時45分頃

楽天ブックスの話の次は、「1,000万人のメルマガ購読者を飽きさせない仕掛け」。メールマガジン「楽天市場ニュース」のお話。

メルマガ2種類
  • 楽天市場から送っているメルマガ
  • 店舗から送られているメルマガ
メールマガジンの役割
  • ユーザーリアクションによる売上げ貢献
  • 広告媒体
  • 新規ユーザー獲得
  • 既存顧客育成
  • マーケティングツール
  • 売上げ比率に占める広告の割合が大きい。
  • KPIとしては配信数、開封数・開封率、CTR、CVR、売上げ。
  • メルマガからの売上げは順調に推移
  • 流行発信・トレンド創出の役割も。例: ビリーズブートキャンプ、花畑牧場、六厘社つけ麺、端っこグルメ、訳ありグルメ&グッズ特集など
  • テレビで放映された商品をいち早くお届け
  • ニュース性のある話題をテキストメールで配信
楽天市場ニュースの規模感
  • 2009年11時点で、1060万通を発行
  • 朝日新聞の発行部数よりも多い

しかし配信数と反比例し、CTRは右肩下がり

媒体改善戦略
  • 「送客」に絞って改善
  • クリック数を上げてユーザーの定着をはかれないか?
  • クリック数を上げる→活性化する→定着する→開封率が上がる
ナビゲーションの改善
  • first viewで逃げられないように。first viewは雑誌の見出しのような役割
  • これまで: 目次的な役割なのに情報が薄い
  • 改善: first viewで多くの選択肢を見せる
  • 多様なユーザーにいろいろな選択肢を提示する。例: ポイントアップには興味ないが、スイーツに興味がある

結果、17.2%アップ

コンテンツのマンネリを改善
  • 掲載商品が偏りがちだった
  • 異なる企画なのに、同じ商品・同じ価格 (出稿店舗の偏り、複数の店が同一の季節商品に注力)
  • 改善: ユーザにマッチした企画、メルマガ読者限定のシークレットセール
パーソナライズの強化
  • 男性版・女性版を出し分ける

結果、29.6%アップ

継続改善のための仕組み
  • 号ごとに想定クリック数を算出 (過去のデータから予想)
  • その目標に対するアクションを導き出す。プロデューサー・ディレクター
  • 結果を分析
今後の取り組み
  • 「楽天スーパーDB」を活用したコンテンツ供給 : グループ内でのユーザーの行動履歴を蓄積。たとえばトラベルで北海道旅行を購入 → 楽天市場でカニを表示
  • メルマガのパーソナライズも強化 : ユーザを7種にカテゴライズしてパーソナライズ。パーソナライズでCTR67%、CVR130%アップ

しょっぱなのトークセッションで駄目出しされてしまったメールマガジンですが、いろいろ工夫しているのだというお話。

発行部数が1,000万を超えているというのは正直驚きますね。もっとも、そのうちの何人が自分の意思で購読しているのかは良く分かりませんが……。

つづきます: 常に改善、常に前進 変わり続ける楽天市場トップページ!

関連する話題: Web / RWDD2009

楽天Webディレクション&デザイン2009: 「楽天ブックス」ユーザー中心設計アプローチの実践と商品検索UIの改善

公開: 2009年12月11日18時40分頃

楽天トラベルの話に続き、「『楽天ブックス』ユーザー中心設計アプローチの実践と商品検索UIの改善」。UCD (user-centered design, ユーザー中心設計) とユーザーテストのお話ですね。

UCDについて
  • 楽天グループのユーザビリティに関する取り組みは遅れている。
  • 今年からSiteCatalystを全社導入。
楽天ブックスについて

200万点以上を取り扱うオンライン書店。Amazonと比較すると、以下のような点が特長。

  • 楽天スーパーポイントが貯まる・使える。
  • コンビニでの商品受け取りが可能。
  • 楽天市場との連携 (市場での検索結果にブックスの商品が出る)。

利用者の男女比はほぼ半々で、これは市場とほぼ同じユーザ構成。

UCDに取り組むきっかけ
  • 担当部署の要望がユーザーを向いていないことがあると感じた。
  • サイトを使っているのはユーザー。使ってもらえなければ意味がない。
検索の改善
  • ユーザテスト・データ解析を実施
  • 当時、ログ解析レポートがほとんどなかった
  • ユーザテストを依頼したいが、お金・時間がない……。
  • 自分で実施!!
調査結果
  • 中吊り・テレビを見て特定商品を求めて来る人が多い
  • レビュー、画像・商品名を重視
  • 検索→UUが多いのに流入率が低い
改善の方針
  • 少ないステップで希望の商品をヒットさせる→インターフェイス改善
  • 検索データの範囲を広げる
  • ユーザニーズ
    • 目的の商品を早く正確に見つけたい
    • レビューを見たい
    • 大きい画像で商品を確認したい

    ビジネスニーズとすりあわせ

ペーパープロトタイピングの実施
  • 検索窓をたくさん作った方が良い?
  • 著者で検索 / 出版社で検索 / アーティストで検索、を用意→どれに入れて良いのか分からない、分かりにくいという結果に
  • など、など
テスト環境を構築して再テスト
  • 検索結果のレビューの星がクリックされる → リンクを設定
  • 画像大小バージョンを用意 → 最初から画像が大きい方が良い、デフォルト大にした
ABテスト
  • 新旧で画面の出し分け
  • 新サイトでは流入率が約4%アップという結果
  • リリースしたところ、流入率が約2倍になった
リリース後
  • 再度ユーザーテストを実施
  • おおむね好評
その後の改善検討事項
  • 「もしかして」機能
  • ジャンル間違いのケースに対応 → ジャンル内での検索結果がゼロ件の場合、全体検索候補を出す
UCDのメリット
  • ユーザテスト → 問題点を客観的に判断できる
  • エンジニアの考え方自体がユーザ寄りになってくる
  • 社内で行うと短期間・低コストで実施可能 → 経理・人事・総務の人を活用
今後の課題
  • UCDについての啓蒙 → 10月リニューアル後、ユーザテストの費用が出るようになった
  • ユーザテストの技術、ノウハウ → 実施できる人は少数。増やしていきたい
Q&A
  • ペルソナの想定は? → 2人。「小林真弓32歳 : 女性子持ち、月に1~2回本・雑誌を買う。テレビのはやりと文庫本」「加藤大介 : DVDマニア、安く早く。上司に言われてビジネス本も買う」
  • 11月の楽天ブックス売れ筋は? → 巻くだけダイエット (www.amazon.co.jp)
  • アマゾンとの差別化・意識している点は? → 楽天市場のユーザー、特にプラチナ会員の利用が多い。ポイント指向の人にアプローチ。
  • 注意している点は? → ユーザーの「行動」を見る。「意見」は必ずしも聞かない。
  • アイトラッキングなどは? → UserInsightはマウストラッキング可能だがアイトラッキングはできない。ユーザテストを専門のコンサルに依頼すると、アイトラッキングができるのが大きい。
  • 自分でやる場合と外部に依頼する場合の差は? → 検索に関しては、あまり差がなかった。サジェストなど、機能的な部分でいくつか指摘があった程度。

楽天とUCDというのもなかなかしっくり来ない組み合わせだ、と思われる方もいらっしゃるかも知れません。最初のトークセッションでも「メールマガジンのチェックボックスが……」という話が出ていましたが、楽天グループはユーザビリティにはあまり熱心でないように見えがちです。

しかし実際には、ユーザビリティを高めたいと思っている現場の方はずっと前から大勢いらっしゃいました。前後のセッションにもありますが、今年になってアクセス解析やABテストの環境が整った、というタイミングです。これは、ユーザビリティ改善の結果を数値化しやすい環境になったということでもあります。

こういった背景から、あるいは今年は楽天のユーザビリティ元年として位置づけられるのではないかなと、そんなふうに思いました。

つづきます: 1,000万人のメルマガ購読者を飽きさせない仕掛け

関連する話題: Web / RWDD2009

楽天Webディレクション&デザイン2009: 日本最大級の総合旅行サイト「楽天トラベル」の改善プロセス

公開: 2009年12月11日1時20分頃

アクセス解析の話の後は、「日本最大級の総合旅行サイト「楽天トラベル」の改善プロセス」。

楽天トラベルについて
  • 日本最大級を自負
  • 国内・海外どちらも対応
  • 国内宿泊中心
サイトの改善
  • UIは論理の集積によって形をなすもの。感覚ではなく論理の集積
  • 良いところを積み上げる
  • 悪いところをつぶす
  • フルリニューアルは、積み上げてきたものを失うリスクがある
  • 改善の手応えがWebの醍醐味
サイト改善のフレームワークと実例
  • 流通構成比 (発生する売上げの比率) を考慮し、その割合の大きい経路を選定
  • 経路の分析と問題点の洗い出し
  • 「問題児」の分析と改善案の検討
  • 改善の実施
流通構成比のツリー
  • トップ
    • 日付検索 (X%)
    • ワード検索 (Y%)
    • 地図検索 (Z%)

もっとも多いのは日付検索 (XはYやZより大)。トップで日付を入力したあと……。

  • (3割)→エリアを選択
    • (8割)→プラン一覧
      • (5割)→施設ページ
        • (3割)→施設プラン
          • (5割)→プラン詳細 (7割リターン)

と、経路を確認した上で、「問題児」ページを発見する。

前後のページ、類似ページと比較して戻り率、ドロップ率が高いページが問題児。

問題児の解決
  • 改善の目標を設定して取り組む。
  • ページの存在意義を確認。このページでユーザーに何を提供する? 本当に必要? 場合によってはページをばっさりカットする勇気も。
改善する要素
  • 重複性がないか : 他のページで訊いたことをまた訊いていないか? 例: トップで日付を選択しているのに、下位のページでまた訊かれる→Cookieに日付を保持して重複をカット。
  • 有効な導線が死んでいないか : このページからどこへ流すのが効果的か
  • ユーザーニーズを満たすサービス(機能)があるか? 例: プラン一覧に並び替え・絞り込み検索機能を実装

これら改善により、月間6億円の売上げアップ

AB分析の実施
  • 旧ページ・新ページを両方用意
  • 最初は新ページの比率を低めにしてスタート
  • 良さそうなら新ページの比率を上げていき、最終的に100%に
要件の優先順位
  • 上流から手を入れていく (上流の方が流量が多い)
  • 効果と工数を軸に取ったポジショニングマップに各項目をプロットして、優先度を決定
体制
  • 管理者・プロデューサー・フロントエンドエンジニアを組み合わせる
  • 要件定義から一緒にやっていく
Q&A
  • ABテストでは季節変動などの要因は考慮している? → 楽天トラベルの商品には季節要因があるので、ABテストを長めに行っている。3ヶ月やれば変動要因は吸収できると考えている。
  • チームは社内? → 社内。
  • 目標を腹に落とす、納得させる。いくら売上げを伸ばすのか、数字を出して、そこへ行き着くための手法を考える。今までのユーザーを離反させない・検索の使い勝手が重要。
  • 楽天トラベルでは、10%は自由なことをして良い。iPhone、twitterなどへの取り組みはそこから生まれてきた。

いわゆる「PDCAサイクル」を実際に回していて、そのプロセスが確立されているというお話ですね。

印象に残ったのは、現状分析、目標設定、検証といった全てのプロセスで数値の裏付けがあるということ。特に、リニューアル実施前にABテストで数値を出すという点について、実施しているサイトはそう多くないのではないでしょうか。

前後の話にも出てきますが、楽天トラベルに限らず、楽天グループ全体として、行動の根拠として数値の裏付けが求められているようです。

※ECサイトでは売上げの数値がはっきり出るから、ということもあるでしょうけれど、前の話に出ていたように、インフォシークのようなサービスでは「送客率」を測定していて、やはり数値ベースの評価になるようです。

つづきます: 「楽天ブックス」ユーザー中心設計アプローチの実践と商品検索UIの改善

関連する話題: Web / RWDD2009

楽天Webディレクション&デザイン2009: 月間50億PV、社内ユーザー1000人のアクセス解析で分かったこと

公開: 2009年12月10日1時40分頃

RIAの話に引き続き、「月間50億PV、社内ユーザー1000人のアクセス解析で分かったこと」。

ちなみに、タイトルの「社内ユーザー1000人」というのは、アクセス解析の結果を利用するサイト運営者が1000人いるという意味です。

何故アクセス解析?
  • 思いつきでの改善には限界がある、逆効果のこともある。KPI(重要業績達成指標)として使いたい
  • SiteCatalystを導入。今年になってグループ全社導入を実施。サイト単位の解析ではなく、グループ全体での解析を進めている。「楽天経済圏」での測定
アクセス解析の導入
  • ギャップ分析 : 事実がゴールとどうかけ離れているか
  • 分析方法や深度が事業や人によりバラバラ : ツールも色々あった。GA、合併前から使われていた社内ツール、Analog等々。UserInsightは現在でも併用している。
  • 標準化と知識共有に課題 : 成果を挙げた人への評価もできていない。
  • 専任チームを結成 : 編成部 アクセス解析・最適化推進チーム 2009年頭に結成。Omnitureから2名常駐、ほか数名サポート
  • グループ47社のうち、導入済みだったのは13社のみ。今年9月までかけて全社に導入。
  • SiteCatalystをカスタマイズ導入。後半は「Test&Target」も
  • 測定コール数 +27% (月間50億)、社内ユーザー数 1.5倍 (約1,400) に
アクセス解析の手法
  • 流入分析 / SEO効果の測定
  • SEOのゴールを設定 : 訪問・3000、売上げ5%アップなど
  • フォーム分析 : SiteCatalystのプラグインで実現。どこでエラーが起きたのか、どの入力項目にフォーカスした状態で離脱したのかを測定。
  • Excelによる定型レポート : 特集のURLを入れるとPV、流入もと、商品ごとのCTRなどが表示される。運用を楽にしないと普及は難しい。
Flashの計測
  • Flashバナーのマウスオーバーやクリックを計測。HTMLのページよりも細かい単位で計測が可能となる。
動画の計測
  • 例: オードリーの販促ビデオ
  • 時間べつの再生時間 (何分まで見てくれたのか) を測定。内容が悪いのか、2分では長すぎるのか、などを判断。
  • グループ内でのCV数・売上げが分かるため、動画クリック→オードリーのブログへ→商品リンクをクリック→購入、というルートも追跡可能。
  • 動画は離脱率が低い。8割もの人が、続けて別の動画を見る。
オフライン成約データとの連携
  • サイト→資料請求・電話→成約というルートも測定
  • 通常は資料請求の回数しか取得できない。Salesforceと連携してIDを結びつけることで成約率を取得。
グループ全体の計測
  • 通常はサイトごとに計測するので、楽天市場→楽天トラベルの遷移は楽天市場から見ると「離脱」になる。これを「送客」として測定 (グループ全体を一つのサイトとみなして測定する)。
  • 楽天ブログ→市場の送客や時間をまたいだ購入なども測定。
  • どのサービスがどのくらいグループ外からの流入に依存しているのか、グループ内外比率を測定できる。
  • インフォシークなどは外からの集客を担う位置づけなので、外部比率が多い方が良い。他のサービスは、グループ内部からの流入を増やしたい。
  • サービスの種類の組みあわせ (どのサービスからの流入なのか) によってCTRが変わる。
ABテスト
  • 一部分だけを出し分けることもできる。AB50%ずつ、だけでなくパターンを増やしたり比率を変えたりする。
  • Refererによって出し分ける、初回訪問時は出し分ける、なども可能
  • 10%の危険率で検定して3%の効果、などという感じで数値を出す
やっていくこと
  • 定点観測による早期警戒 : 定点観測によって異常な変化を検出し、警告を出す。たとえば、Google経由での「オーガニック」へのランディング数が急変→Googleのアルゴリズムが変わっていたことが判明
  • データ計測 : データ量が限界に近付く (グループ全体で毎月50億PV)。BIなどの併用も検討
  • 解析の底上げ : PV・UUなど旧来の考え方から脱却、手法のパターン化、共有
  • ガバナンス : 経営判断に使えるようにフロー化

楽天グループはアクセス解析をガンガンやっていると思っていましたが、昔からやっていたのは市場やトラベルといった主要サイトだけで、グループ全体に行き渡ったのは今年に入ってからなのですね。

グループ全体で運営手法を統一していく、というのは巨大グループ企業に共通した課題だと思いますが、楽天の場合はサービス買収でグループを大きくしてきた経緯もあるので、運営側のツールを統一するだけでもかなり大変なようです。

つづきます : 日本最大級の総合旅行サイト「楽天トラベル」の改善プロセス

関連する話題: Web / RWDD2009

楽天Webディレクション&デザイン2009: 楽天グループ、RIA表現への取り組み

公開: 2009年12月9日14時25分頃

twitterの話に引き続き、「楽天グループ、RIA表現への取り組み」。スピーカーの竹部さんは普段はIA(情報設計)の話をされることが多いそうですが、今日はRIA推進の立場でのお話でした。

時間が押していたためか話のペースがかなり速く、手元のメモもだいぶ歯抜けです。

チームのミッション
  • 1. richUIの検討 : サービスUX向上、バックオフィス作業負荷軽減
  • 2. 事例共有、ノウハウ蓄積 : 共有方法の模索・勉強会の開催
  • 3. 効果測定・課題点 : SiteCatalystの導入、SEO・アクセシビリティの標準化、標準コンポーネントの整備
RIAに期待すること
  • ユーザビリティとマネタイズ : 「儲からないでしょ?」→儲かるUX、概念モデルと行動モデルの乖離
  • 新しいユースケース : AIR・Silverlight / 番組中でその商品を買わせる、GPSでレコメンド、などの新しい試みも出てきている
  • Flex : ファッションサイトのデモ / 画面遷移に費やしていた時間を、なにを買おうか悩む時間に
  • 楽天アフィリエイトで商品を出すパーツのUIをリッチなものに変更したところ、CVRが2.3倍になった
社内での共有
  • SharePointを利用
  • デザインパターンの事例を共有
課題点と今後の取り組み
  • UXの評価方法。事前にROI(投資対効果)を示せるのか
  • 定量評価なのか、定性評価なのか
  • 「今はお金がないからお気に入りに入れました」→購入していないが評価すべき
  • RIA開発の標準化 : UI・インタラクションのコンポーネント / UXガイドラインの整備 / マルチデバイス対応
Q&A
  • Q. IAとして意識していることは? → ナビゲーション部分。RIAは画面遷移が発生しないので、アニメーションなどでユーザに説明する。

全体的には、これからという印象。そもそも楽天とRIAとが結びつくイメージがあまりないかもしれませんが、実は楽天もRIAC (www.ria-jp.org)会員企業 (www.ria-jp.org)なのですよね。

楽天グループでは数値が重視される傾向にあるようですが、RIAの導入でどれだけ数字(売上)が出るのか定量的に予測することはなかなか難しいようで、その点が大きな課題となっているようです。

つづきます: 月間50億PV、社内ユーザー1000人のアクセス解析で分かったこと

関連する話題: Web / RWDD2009

楽天Webディレクション&デザイン2009: 「楽天トラベル」つぶやきながら見えてきたTwitter活用3つのポイント

公開: 2009年12月8日13時50分頃

トークセッションの後は会場AとBに分かれて、それぞれで異なる話が聞けるという形になっていました。つまり、二者択一でどちらかを選ぶ必要があります。

私が選んだのは、「『楽天トラベル』つぶやきながら見えてきたTwitter活用3つのポイント」。楽天トラベルの林さんのお話です。プログラムを見ると30分の話のように見えますが、実は30分で2話入っているので、実質15分。ほとんどライトニングトークですね。

楽天トラベル公式twitterアカウント
  • 楽天トラベル公式twitterアカウントは @RakutenTravel (twitter.com)
  • 「つぶやき娯レンジャー」と称して5人で担当。林さんはアカ。
  • 2009年8月3日に、公式twitterアカウント開設の提案を行った。
  • 目標は、「多くの人に楽天トラベルを好きになってほしい」ということ。売上げ目標は持っていない。
つぶやきの特徴
  • 時間と共に注目度が低下する。
  • ただし、RT されると注目度が復活、長持ちする。RTされやすいつぶやきが重要。

※RT = retweet、他人のつぶやきを転載すること。頭に RT: と書いて retweet であることを明示するのがならわし。

方針
  • 1. reply、フォロー返しもする。「旅行に行く予定が無くても、フォローしていて楽しいアカウント」を目指す。
  • 2. つぶやきたくなる企画を考える。頭文字俳句のようなネタなど。ただし、企画自体を知ってもらうのが難しい。他のメディアと組み合わせる試みが必要かもしれない。
  • 3. 中の人の個性を出す。フレンドリーな対話を通じて信頼につなげて行く。「オフィスにバナナトラップを仕掛けてみました」「ちょ、楽天トラベル何やってるの」というようなやりとりも。
twitterのメディア特性を理解する
  • 流れていく / 堅苦しくない / つぶやく瞬間が大事
  • twitter自体がこれから成長していくメディア。リスクを恐れず試行錯誤して行く
Q&A
  • Q. つぶやきにどのくらいの時間を割いている? →業務の合間でつぶやいたりしている。業務に支障を来さない範囲で。twitterの特性上、短時間に大量につぶやくのはNGなので、時間をまとめて、というのはしていない。
  • 予約への貢献は? → 正直難しい。たまに、すぐに予約につながる反応があることもある。タイムセールのようなものには効果がありそうだが、未知数。

メモだけだと分かりにくいですね……。実際は写真やグラフなども交えてのプレゼンテーションだったのですが。

replyやフォロー返しもしている、というのがポイントでしょうか。企業の公式アカウントでのフォロー返しには賛否両論ありそうですが、目標が明確にされているので、迷わずにこの方針で行けているのでしょう。

後で出てくるのですが、楽天トラベルでは就業時間のうち10%を好きな研究に宛てることができるそうで、twitterの活用はその中から出てきたものだそうです。そういう経緯だからこそ、具体的な売上げ目標がなく、自由にできているのかもしれません。

つづきます: 楽天グループ、RIA表現への取り組み

関連する話題: Web / RWDD2009

楽天Webディレクション&デザイン2009: トークセッション

公開: 2009年12月8日0時50分頃

楽天Webディレクション&デザイン2009 (corp.rakuten.co.jp)」(RWDD2009)というイベントがあったので参加してみました。

楽天のテクノロジー系カンファレンスは何度も開かれているのですが、今回のRWDDは編成部の方が開催されたものです。システム開発の部門ではなく、実際に普段サイトの運用を行っている現場の方たちのお話が中心です。

最初はトークセッション。三木谷氏、iモードの立ち上げに携わった夏野剛氏、元スクウェア社長の鈴木(ひさし)氏、の3名による楽天についてのトークです。

以下、気になったところを断片的にメモ。話がつながっていないように見えるのはメモの品質が低いせいです。その他、不正確な部分もあるかもしれません。

パネリスト自己紹介
  • 鈴木さんと夏野さんが知り合ったのはiモード版のファイナルファンタジーをつくったとき。
  • 楽天立ち上げ当初は、ファイルをいかに軽くするか考えていた。更新感、ライブ感を重視 (当時は更新がほとんどされないサイトが多かった)。売っている人の顔が見えるような、親近感を重視 (楽天用語で「人気(ひとけ)」と呼んでいる)。
  • iモードは11年目。コンシューマビジネスの面白いところは、ウソが通用しないところ。手を抜いたり、「システムの都合で……」などといって妥協したりすると、売り上げに直結する。それが逆に面白い。結果が出せるので、やる気がある人に向いている。実は当時は、iモードがうまく行くとは思っていなかった。これは「ドコモを育てた社長の本音 (www.amazon.co.jp)」という本にも書いてあることで、秘密でも何でもない。「当時としては」ぎりぎりのところまで妥協しなかった、というのが成功の理由だと思っている。
楽天の良いところ、駄目なところ
  • 楽天は日本を変えている。流通の構造を変革させた。夏野さんは都会の店ではなく、広島や岡山のワイン店からワインを買う。ワインは知識がないと、立地が良くても仕入れができない。楽天が提供するのは共通プラットフォーム。店ごとにカード番号や送り先を入れ直さなくて良い。
  • ネットの利点は、こまめに改善が効くこと。ある程度の完成度で出して改修を加えていく、というやり方が可能。いかに早く・細かく・データに基づいて直していくかが重要。
  • 小さな実験ができる。1日やるだけで、だいたいわかる。CTRCVRを見る。
  • 楽天で買い物するとき、メールのチェックボックスを毎回外す (会場笑)。楽天から来るメールのクオリティが悪すぎる。ショップから来るメールは良いが、楽天からのメールはばっくりしすぎていて刺さらない。デフォルトオンを押し通すのは良いことだと考えるが、メールのクオリティが低いことが問題。
  • iPhone向けはトップページだけで終わり? →今やってます。→供給側から見ると提供のスピードは早いのだが、ユーザー側から見ると、もっと早くしてほしいとなる。
  • そろそろWebオンリーの時代は終わる? 専用アプリで、というのも考えている (特に、店舗側のインターフェイス)。
  • Webでもできる。今はWebで専用アプリと遜色ないインターフェイスが作れる時代。
  • 組織が大きくなると硬直化してくる。新しいトレンドを若い人からどうやって吸い上げるか。楽天では「執行役員2.0」という試みをしている
  • 日本には大きなポテンシャルがある。個人金融資産1500兆円。国内に金は唸っている。
  • 金を払わなくても働くエンジニアがいる。勤労意欲のレベルが高い。ITのインフラが整っている
  • 日本から世界に冠たるIT企業が出てこないのは? → 国内競争に疲弊したり・テレビ業界にいじめられたり(会場笑。TBSの件と思われる)。
人材の話
  • 自分で目標設定してやりとげる人。自分のサービスに誇りを持って出していける
  • 探求心を持つ人。
  • 大義・何のために仕事をするのか。
  • ただし必ず障害がある。
終わりに
  • 多角化によるシナジー。楽天経済圏。次のミッションは、オフラインとオンラインをつなげ行くこと。Edy の買収もその一環?
  • 楽天の中だけでサービスを完結させるのは難しくなった。オープン性が必要。たとえば Yahoo! との協力、twitterとの連携など。
  • ITは世直し。しかし抵抗勢力がいる。厚生労働省とか。
  • 300兆のうち6兆のみがeコマース。まだまだ行ける。

以下、私の感想。

「メールのチェックボックスを毎回外す」という話が印象に残りました。楽天市場で買い物をする際、確認画面にメールマガジンを受け取るかどうかのチェックボックスがあるのですが、それがデフォルトでオン (受け取る) になっているという話ですね。楽天の話をすると必ずと言って良いほど出てくる話ですが、こんな楽天のオフィシャルなイベントで出てくるとは。

もっとも、今日の話の大きな流れは「楽天のユーザビリティを改善して行く」という話であるので、流れとしてはきわめて妥当な話ではあります。後のセッションでは、そのメールマガジンの話も出てきます。

つづきます: 「楽天トラベル」つぶやきながら見えてきたTwitter活用3つのポイント

ドコモを育てた社長の本音

関連する話題: Web / RWDD2009

2009年11月27日(金曜日)

ぱにぽに13

公開: 2009年11月29日13時10分頃

出ていたので。

って、よく見ると背表紙が微妙に「ぱにぽに」じゃないぞっ!?

12巻ラストで「ベッキーって誰?」となっていた続き。普段からなんだか良く分からない世界ですが、今回は輪をかけて分からないです。

初回限定は謎のゲームブックでした。

ぱにぽに 13 (ガンガンファンタジーコミックス)

関連する話題: マンガ / 買い物 / ぱにぽに

よつばと! 9

公開: 2009年11月28日1時0分頃

出たっ!

ジュラルミン登場。よつばこのお父さんスイッチがガンガンにカスタマイズされているとか、積み木を完成させた風香が……とか、あさぎのヘリポクターとか、細かいところがいちいち面白いです。

一番可笑しかった&可愛かったのは、よつばが風香にコーヒーを持って行こうとして……という話ですかね。父ちゃんが事前に「たぶん多少こぼれると思うけど」と予想していたのがまたなんとも。

※どうでも良いのですが、60話の扉の看板が「ググるな あぶない」に見えて仕方ないです。

よつばと!  9 (電撃コミックス)

関連する話題: マンガ / 買い物 / よつばと! / あずまきよひこ

文字列を数値に変換する際もカルチャに注意

公開: 2009年11月28日0時35分頃

こんなお話が: 「伊郵政金融、小数点処理のバグにより大混乱 (slashdot.jp)」。

イタリアでは位取りではなく小数点にカンマが使われるので、こういうコードを実行してみると……。

string s = "1,234";

Decimal invDecimal = Convert.ToDecimal(s, CultureInfo.InvariantCulture);
Console.WriteLine(invDecimal);

CultureInfo jp = CultureInfo.CreateSpecificCulture("ja-JP");
Decimal jpDecimal = Convert.ToDecimal(s, jp);
Console.WriteLine("{0}: {1}", jp, jpDecimal);

CultureInfo it = CultureInfo.CreateSpecificCulture("it-IT");
Decimal itDecimal = Convert.ToDecimal(s, it);
Console.WriteLine("{0}: {1}", it, itDecimal);

結果はこうなると。

1234
ja-JP: 1234
it-IT: 1.234

文字列比較の時、カルチャに気をつけないと予想外の文字が同一視されて大変なことになるという話はよくありますが、文字列を数値に変換する際も要注意ということですね。

関連する話題: プログラミング / C#

2009年11月25日(水曜日)

大阪万博はある意味すごい

公開: 2009年11月27日14時45分頃

ある意味、すごかった。後半のアンソロジー系4コマがすごい……というかここまで来ると恐ろしいです。たぶんわざとやっているのだろうと思いますが、これあずまんが大王じゃないですから。

特に驚異的なのは「苺ましまろ」で、ともと神楽の見分けがつかないです。よみはメガネで分かりますが、他のキャラはかなり難易度が高いです。

しかしまあ、ネタとしては面白いですね。特に「苺ましまろ」と「日常」は元の作風そのまんまで読めるので、ファンにはお勧めかもです。

大阪万博

関連する話題: マンガ / あずまんが大王 / あずまきよひこ / 苺ましまろ / 日常

2009年11月24日(火曜日)

docomoのJSケータイ、DNS Rebindingで「かんたんログイン」を突破される

公開: 2009年11月26日22時0分頃

iモードIDを用いた「かんたんログイン」のDNS Rebinding脆弱性 (www.hash-c.co.jp)」。docomoのJS対応端末では、DNS Rebindingでsame originポリシーを突破されてしまうことがあるというお話ですね。タイトルは「かんたんログインのDNS Rebinding脆弱性」となっていますが、DNS Rebindingで攻撃されるのは端末……というか、docomo側のゲートウェイの問題かと思います。

基本的には端末、もしくはdocomo側が対応する必要があるのだろうと思いますが、サイト側で可能な対策として、Host: が違っている場合にアクセスを拒否することが挙げられています。つまり、名前ベースのバーチャルホストを使っている場合は影響を受けないということで、影響を受けないサイトも多いのではないでしょうか。とりあえず、ケータイサイトにIPアドレスでアクセスしてみて、アクセスできなければ大丈夫と考えて良さそうです。

ユーザー側では、端末側のJSを無効という対策が挙げられています。

が、これで完全に対策できるのかどうかは、私には良く分かりません。ここではXmlHttpRequestを使った攻撃が想定されていますが、same originポリシーが突破されるとまずいことは他にもありそうです。たとえばiframeであるとか、Flashであるとか、そういったものを利用した攻撃というのも考えられそうですが……。実際にケータイでそれらがどこまで動くのか、ちょっと分からないので何とも言えないですね。

※JSまるごと無効ならiframeは大丈夫そうな気もしますが、Flashはどうなのかなぁ。

関連する話題: セキュリティ

2009年11月23日(月曜日)

サンシャイン牧場の件、まとめ

公開: 2017年9月25日20時0分頃

サンシャイン牧場の件、ひとまずまとめたので暫定的に公開。

技術的に興味深い話は特になくて、基本的には「ガッカリ」という感じだろうと思いますが。

疑問点などがありましたら、できる範囲で補足しようと思いますので、コメントいただければと思います。

関連する話題: ゲーム / サンシャイン牧場 / セキュリティ / 情報セキュリティ早期警戒パートナーシップ

2009年11月21日(土曜日)

論理少女3

公開: 2009年11月23日19時30分頃

3巻が出ていたので。

うーむ。今回は、自分で解いてみようと思えるような問題がほとんどないですね。「問題がつまらない」というのが問題のヒントになっていたりもするので、そういうものなのかもしれませんけれど。

※どちらかというと、3巻はいつきとミーナの私服&浴衣を満喫すべしという主旨なのかも。:-)

3であるもの

自然界には「2であるもの」はたくさんあるけれども「3であるもの」はほとんどない、という話。

しかし「3であるもの」という定義は分かりにくいですね。とりあえず「地球は太陽系第三惑星」「物質の相は固体、液体、気体の三態」なんてのを思いつきましたが、こんなのもOKなのでしょうか。

三角砦

3巻のメイントリック。つまらないパズルが連発され……。原始疑似完全数とかマニアックすぎます。

しかしこの砦、ギブアップの際の処理はどうするのでしょうね? うまく処理しないとネタバレしそうです。あと、メンバーがはぐれたりすると、やっぱりネタバレになりますね。「数人で力を合わせないと見つからない」というのはそういうことなのかなぁ。

論理少女(3) (シリウスKC)

関連する話題: マンガ / 買い物 / 論理少女 / 論理

2009年11月20日(金曜日)

どうぶつの森 1周年

公開: 2009年11月21日10時35分頃

街へいこうよ どうぶつの森 (www.amazon.co.jp)開始から1年経ちました。

村長さんから手紙が。

便箋の模様が亀なんですね。プレゼントが添付されていて、開けてみたら「やくばのもけい」でした。

あと、ニンテンドーからもアニバーサリーケーキが配信されていますね。

街へいこうよ どうぶつの森(ソフト単品)

関連する話題: ゲーム / Wii / 任天堂 / どうぶつの森 / 街へいこうよ どうぶつの森

2009年11月19日(木曜日)

どうぶつの森 きのこ家具

公開: 2009年11月21日10時10分頃

街へいこうよ どうぶつの森 (www.amazon.co.jp)。始めたのが去年の11月20日ですから、明日でちょうど一年になります。

そんなタイミングで、きのこ家具がコンプリート。

あと、カブ価がなかなか良い感じになっていました。

1カブ578ベルだなも!

でも、こういうときに限って白カブを持っていないという。

街へいこうよ どうぶつの森(ソフト単品)

関連する話題: ゲーム / Wii / 任天堂 / どうぶつの森 / 街へいこうよ どうぶつの森

MT:アーカイブテンプレートを消したらMTArchiveListで出していたものが消滅

公開: 2017年9月25日12時25分頃

Movable TypeのテンプレートタグにMTArchiveList (www.movabletype.jp)というものがあります。これはエントリを年別・月別に表示できるので便利です。これをインデックステンプレートで使って、過去のエントリを年別・月別に一覧表示したりすることもできます。が、これはあくまでアーカイブの一覧であってエントリの一覧ではないということのようで、アーカイブテンプレートが無いと、MTArchiveListは何も出力しません。

MTをブログとしてではなく、コンテンツ管理のために使用するケースは結構あると思います。1ページに全てのエントリを出せば良く、個々のアーカイブページは必要ない、という状況もあります。そんなとき……。

……なんてことをやると、次に再構築した瞬間、エントリが全く出なくなって大変なことになります。

アーカイブテンプレートを追加してやると回復しますが、そもそも、アーカイブページを用意しない場合にはMTArchiveListは使うべきではないようですね。

関連する話題: Movable Type / 失敗談

2009年11月18日(水曜日)

サンシャイン牧場の件、取扱終了

公開: 2017年9月25日13時10分頃

サンシャイン牧場の件ですが、IPAの方から取扱終了のご連絡をいただきました。本件に関わられたすべての皆様にお礼申し上げます。

というわけで一段落しましたので、暇を見て、技術的な面を含めて少しまとめようかなと思っております。私の持っている情報もそんなに多いわけではないのですが、「ここが知りたい」といった要望がもしありましたら、お寄せいただければと。

関連する話題: ゲーム / サンシャイン牧場 / セキュリティ / 情報セキュリティ早期警戒パートナーシップ

2009年11月16日(月曜日)

サンシャイン牧場のRekoo日本法人設立で、情報漏洩の件の話

公開: 2009年11月17日14時0分頃

サンシャイン牧場の件。先日、サンシャイン牧場のRekooが日本法人を設立したというニュースが出ていましたが、その会見の中で情報漏洩の件についても触れられていたようで。

なお、サンシャイン牧場のシステム不具合で、2009年10月21日から23日の3日間にクレジットカードでアイテムを購入した約4000人の利用者の電話番号とメールアドレスが閲覧可能な状態になっていたとの報道があった件に関して、小野氏は「ご迷惑、ご心配をおかけたことを申し訳なく思っている。ただ、一部報道にあったようにリストとして4000人分の情報を取り出せる状況にあったということではなく、事実としては他人のIDをたまたま知ることができた場合に、不正にアクセスして情報が取れたかもしれないという状況だった。今後はこうしたことのないようにしていきたい」と述べた。

以上、ITproの「SNSネイティブが世界を変える」---mixi最大のゲーム「サン牧」仕掛け人たちが明かす急成長の理由 より

会員情報の件は、課金システムのドラブルがあった期間中に、課金サービスを利用したユーザー約4200人の情報が他人に閲覧される可能性があったとのこと。「外部サイトへ飛ぶときに表示されるURLに他人のIDを加えれば、当該ユーザーの情報を閲覧できるようになっていた」。

小野氏は、「ユーザーにご心配をおかけしたことを申し訳なく思っています」とした上で、「誤解されがちだが、約4200人の情報が一気に引き出されるような状態ではなく、問題のあった期間中に課金したユーザーのIDを入手できたとして、それを悪用したら当該ユーザーの情報を閲覧できる可能性があった。今後、そのようなことがないように注意していく」と説明した。

以上、INTERNET Watchの「サンシャイン牧場」のRekoo日本法人設立、街版や深海版も予定 より

同じ話のはずなのですが、ITproとInternet Watchとでだいぶニュアンスが違うのが面白いですね。

ITpro側には「他人のIDをたまたま知ることができた場合に」とありますが、Internet Watchの方を読むと、このIDが「ユーザーのID」であることが分かります (セッションIDではない)。これを「たまたま知る」のがどのくらい難しいのか、という点が一つのポイントではないかと思います。

たとえば、Rekoo自身がmixiのアカウントを持っているわけですが、そのRekooさんのページは以下のようなURLで見られます (要mixiログイン)。

http://mixi.jp/show_friend.pl?id=24428176

この末尾の"24428176"がRekooさんのユーザーIDです。

つまり、そのユーザーのページに到達できれば、それだけでIDを知ることが可能です。なお、mixiのコミュニティにはメンバー一覧を表示する機能があり、サンシャイン牧場の公式コミュニティも例外ではありません。他人のIDを知りたいという明確な意図を持って「たまたま知る」のは、さほど難しくないことであるように思います。

※ついでにいうと、IDは単なる数字の連番ですから総当たりも可能です。もっとも、そんな派手なアクセスがあったらログからすぐに分かるでしょうが。

「他人のIDをたまたま知ることができた場合に」……などと表現されると、それだけでなんとなく「IDを知る手段が限られていた」というような印象を受けますね。ITproの記事は、スピンとしてはなかなかうまい感じになったのではないでしょうか。

関連する話題: ゲーム / サンシャイン牧場 / セキュリティ / 情報セキュリティ早期警戒パートナーシップ / スピンドクター

2009年11月15日(日曜日)

きみといると 2

公開: 2009年11月17日13時30分頃

出ていたので購入。

最初から最後まで顔を赤らめている感じ? 春がアレな想像をして悶えてしまうあたりがなんとも……。

きみといると2(アクションコミックス)

関連する話題: マンガ / 買い物 / きみといると

2009年11月12日(木曜日)

古レール

公開: 2017年9月25日16時0分頃

またしてもこんなマニアックな本が。線路マニアの世界は深いですね。

古レールで構築された駅舎建築の写真と、その分類・分析。地域ごとに「好み」があったりとか……。

古レールの駅デザイン図鑑

関連する話題: / 線路マニア

2009年11月11日(水曜日)

MS09-065(KB969947)でDELL OPTIPLEX 740が死亡

更新: 2009年11月13日13時40分頃

本日のWindows Updateに登場しているMS09-065 (KB969947) (www.microsoft.com)ですが、これをDELL OPTIPLEX 740に適用したところ、フリーズが発生。ログオン完了後にデスクトップ画面が表示されてしばらくすると、画面の一部が赤くなってフリーズし、キーボード入力も何も受け付けず、電源を強制的に切るしかなくなります。別の同機種でも再現する模様。

どうもビデオドライバ周りで死んでいるようですが、MS09-065は「Windows カーネル モード ドライバーの脆弱性により、リモートでコードが実行される」という問題を修正するものですね。おそらく、OPTIPLEX 740のドライバとの相性が悪いのでしょうね……。

※以下、2009-11-12追記

他のDELLマシンでも発生しているようですね。

症状が発生した場合ですが、とりあえずセーフモードでは起動できますので、KB969947を削除することができます。参考までに、以下、Windows XPの場合の手順です。

あとは再起動すると復活します。ただ、自動更新を設定している場合はシャットダウン時に勝手に適用されてしまったりするので、「更新の通知を受け取らない」ように設定した方が良いかもしれません。

ただし、この状態では深刻な脆弱性が残ったままになりますので、いつまでもこのままにしておくべきではありません。おそらくDELLかMSから何らかの対応策が出ると思いますので、それを見てしかるべき対応をする必要があります。

※2009-11-12さらに追記

どうもATIの古いドライバがだめだったらしく、ドライバを最新にしてからKB969947を適用すれば良いようです (適用して30分ほど経ちますが、今のところ大丈夫)。

※2009-11-13追記

マイクロソフト側でも問題を認識されたようで、以下のような話が出ています。

英語版のKBに"Known issues with this security update"という項が追加されています。

Known issues with this security update

After you install this security update on a computer that is running Windows XP and that is using an ATI Radeon HD 2400 series video adapter, you may find that the computer does not start correctly. To resolve this issue, follow these steps:

以上、MS09-065: Vulnerabilities in Windows kernel-mode drivers could allow remote code execution より

関連する話題: Microsoft / Windows / セキュリティ / 失敗談

2009年11月8日(日曜日)

スピンドクターと脆弱性関連情報

公開: 2009年11月10日22時5分頃

読み終わったので。

スピン = 情報操作のお話。さまざまな操作の例が紹介されているのですが、興味深いと思ったのは、先に情報を出してニュースとしての価値を低下させてしまうという手法。「しんぶん赤旗」にスクープさせると、他紙が後追い取材をしなくなるとか……。民主党偽メール事件の話も非常に興味深かったですね。

※個人的に期待していたネット情報操作の話は、最後にちょこっと出ていただけで、ほぼ既知の話でした。そこは少し残念でしたが、他の部分は読み応えがあったかと。

しかし考えてみれば、脆弱性関連の報道やリリースなんてのは「スピン」の典型例でしょうね。

私が発見・報告して報道された事例としては、最近ではサンシャイン牧場、古くはニフティのXSSJVNアンケートACCSのXSS脆弱性などがあります。あとは、ソフトウェアの脆弱性もそれなりに。が、思い起こすと、JVNアンケートの件はともかく、他は……。報道された内容に違和感を覚えなかった例の方が少ないですね。

そもそも、脆弱性の話は全く表に出ないケースも多いです。基本的には以下のようなメソッドが標準になっていると思います。

つくづくスピンだと思いますね。ウェブに限らず、ソフトウェアの脆弱性についてもこういう傾向はあると思います。マイクロソフトなんかはちゃんとアナウンスしているわけで、できないことはないと思うのですけどね。

※サンシャイン牧場の話などを見ていると、どうも、「脆弱性を通知された運営者は即座に対応し、速やかに情報を公開するものだ」と思っている方が結構いらっしゃるようで。まあ、そういう運営者も全くいないわけではないのですけれど、そういう期待は裏切られる確率の方が高いです。

関連する話題: / 買い物 / セキュリティ / スピンドクター

2009年11月7日(土曜日)

ゼロのプレスリリース

公開: 2017年9月25日15時25分頃

サンシャイン牧場の件ですが、ゼロからこんなリリースが出ています。

当社が課金システムを納入しているSNSサイトにおける不具合発生について、課金システム自体に問題があったとも受け取れる報道が一部でなされましたが、そのような事実は一切ございません。既に当該サイト運営者様からも、当社側決済システムに脆弱性が無かった旨の確認をいただいております。

Rekooのアナウンスに追記されている通りですね。ゼロ側に問題があったという主旨の報道は出ていないように思いますが、読売などは「導入した課金システムに不具合があった」と表現していますので、このあたりが誤解を招いているという話なのでしょう。

関連する話題: bakera.jp / hatomaru.dll

bakera.jpナビまわりのプチリニューアル

公開: 2017年9月25日15時20分頃

ナビまわりを少しリニューアルしました。

右側(?)に「人気のページ」「最近の日記」を追加してみました。この日記を普段からチェックしている方やセキュリティホールmemoから来られる方は良いのですが、そうでない方には全体の雰囲気が分かりにくいようなので、少しでも分かりやすくなれば良いかなと。

実は単にリンクが増えただけではなく、内部的にもいろいろ変わっています。例によってバグっているかも知れませんが、何か変でしたらお知らせください。

関連する話題: bakera.jp / hatomaru.dll

2009年11月5日(木曜日)

サンシャイン牧場・Rekooからのアナウンスに追記

公開: 2009年11月5日14時10分頃

サンシャイン牧場の件、mixiからのお知らせに追記があり、既に出ているRekooからのアナウンスに追記がある旨書かれています。Rekooのアナウンスに追記された内容は以下のとおりです。

****************** 〔追記〕 ******************

サンシャイン牧場におけるトラブルにつきまして、 一部のユーザー様からお問い合わせを頂いているため、改めて下記ご説明を追加 させて頂きます。

■「第三者より情報が取得可能な状況」について

「ユーザー様のメールアドレス・電話番号が第三者より取得可能な状況」は、当社が当初用いていた課金サービスの脆弱性をついて、第三者のIDを許可なく利用して能動的に不正アクセスした場合にのみ取得可能であり、通常だれもが情報を取得できるような状況ではございませんでした。

■「不正アクセスによって取得可能な状態にあった情報」について

上記の状態において、不正アクセスにより取得可能であった情報は、サンシャイン牧場の課金サービスを利用したユーザーが入力した「メールアドレス」および「電話番号」になり、クレジットカード情報等その他の情報は含まれておりません。

またこれらの情報は、当社が独自にユーザーより決済サービス時の連絡用として取得したものでありミクシィ社より提供をうけたものではございません。

※本課金サービスにおいて、決済代行会社の課金システムを利用しておりますが、本不具合に関しましては、決済代行会社の課金システムに問題はございません。

以上、[mixi] 「サンシャイン牧場」Rekoo | 課金サービス開始時の不具合について より

各紙報道では「本人と偽ってプログラムを操作」、「プログラマーなど特殊な知識を持った人」とパワーアップしてきていて、これはきっとRekoo側がそう言っているのだろうと想像していました。Rekoo自身の説明では、「課金サービスの脆弱性をついて、第三者のIDを許可なく利用して能動的に不正アクセス」となりましたね。

「誰でも取得できたわけではなかった」と印象づけて利用者を安心させたいという気持ちは分からないでもないのですが、あんまり意味がないと思うのですよね。利用者の関心事は、あくまで「漏れたかどうか」でしょう。たとえ情報の取得が簡単であっても、「ログを調査した結果、漏れていないことが判明」と言われればひとまず安心でしょうし、その逆もしかりです。情報の取得が難しかったかどうか、専門知識が必要だったかどうか、などということをいくら印象づけても、利用者の不安の解消にはつながらないと思うのですね。

とはいえ今回の場合、ログを調査して漏洩の有無を確認することも困難でしょう。派手に大量アクセスして舐めていった人がいれば分かりますが、そうでない場合、ログを見ても漏洩の有無を判断できない可能性が高いと思います。なかなか難しいところですね。

関連する話題: ゲーム / サンシャイン牧場 / セキュリティ / 情報セキュリティ早期警戒パートナーシップ

2009年11月4日(水曜日)

サンシャイン牧場・決済代行会社のサポートからの情報

公開: 2009年11月5日10時11分頃

サンシャイン牧場の件ですが、決済代行会社であるゼロのサポートから回答を得たという方が、公式コミュニティにその内容を書き込まれています。

以前のアナウンスに追記されたとおり、今回の話はRekoo側の問題です。が、ゼロ側でもかなり詳細な情報を把握されていて、問い合わせに対してはかなり細かいところまで回答されているようですね。興味深い内容が含まれていますので、一部引用しておきます。

---流れ---

1回目の購入

Kコインチャージページ

クレジット決済会社ページ(メールアドレス、電話番号、クレジット情報入力)

アプリ会社にメールアドレスと電話番号を渡す(クレジット情報は渡さない)

2回目以降の購入

Kコインチャージページ(前回入力したメールアドレス・電話番号の情報をページに持たせる)

↓ ここで専門知識を持った人だったらページに持たせている情報を見れる状態だった

クレジット決済会社ページ(メールアドレス、電話番号の入力不要)

---ポイント---

・今回の件でクレジット決済会社から情報は一切漏洩していない

・現時点で、上記の購入システムは廃止し、2回目の購入以降も1回目の購入と同じように再度メールアドレス・電話番号を入力しなくてはいけない

・今回の件に限らず、不正課金などのトラブルがあった場合は迅速に対応する体制あり

とのことです。

(注意:mixiのページ(外部リンクへとぶ)やページ遷移の際に電話番号・メールアドレス以外にもユニークIDなどを情報に持たせている可能性がありますがややこしくなるので割愛させていただきます)

以上、「サンシャイン牧場」Rekoo トピック 課金サービス開始時の不具合について #192 じゅ~たん☆さんの書き込み より

当初、サンシャイン牧場のKコインチャージ画面では、「新たなクレジットカードを使う」「前回のクレジットカードを使う」のいずれかを選択するようになっていました。

初回の購入前は、Rekoo側のサーバにはメールアドレスも電話番号も登録されていません。この時はそのままゼロ側のサーバにリダイレクトされ、そこでカード番号やメールアドレス、電話番号などを入力します。この課金が完了すると、メールアドレスと電話番号の情報がRekoo側に(おそらく自動的に)送られて、サーバに格納されます。そして「前回のクレジットカードを使う」を選択した場合には、メールアドレスと電話番号の情報を一度「ページに持たせ」てから、その情報をゼロ側に引き渡すという構造になっていた……。

……と、こんな感じであったらしいことが読み取れます。

さらに、別の方がこんな情報を書き込まれています。

■個人情報流出の範囲等

まず、弊社を通じてクレジットカード決済をされたお客様のクレジットカード番号や有効期限の情報につきましては、mixi上での発表にもございますが流出はしておりませんのでご安心ください。

(電話番号/メールアドレスが閲覧できた状態だったと発表)

また、弊社が保有しておりますお客様の個人情報は弊社決済ページにてご入力いただいた下記の情報等となります。

・クレジットカード番号

・クレジットカードの有効期限

・決済時のお電話番号

・メールアドレス

・入力氏名

・その他決済時のアクセス先IPアドレス等

■その他ご質問事項について

今回の一連の報道・発表については、弊社でも確認しておりますが、現時点では技術的な面での詳細は発表されていない状況です。

したがって、詳細についてはサンシャイン牧場の運営者またはmixi側の公式発表をお待ちいただければと存じます。

また、今件については「流出」と記載されているケースもあるかと存じますが、実際には「閲覧可能な状態にあった」という表現が適切でおり、元々存在するデータがまとまって流出したのとは異なる性質がございます。

したがって、  様からいただいたご質問である「誰にきいたら、自分が被害者かどうか分かるのか」という点については、サンシャイン牧場の運営者やmixi側でわかるかどうかも断定できかねる状況でございます。

(現時点では4200人という数字が出てはおりますが、閲覧されてしまった対象のお客様がどの程度いらっしゃるのかは弊社では把握できておりません)

この度はご心配をお掛けしておりますが、何卒ご理解の程、お願い申し上げます。

以上、「サンシャイン牧場」Rekoo トピック 課金サービス開始時の不具合について #204 ゆきさんの書き込み より

「現時点では技術的な面での詳細は発表されていない状況」「詳細についてはサンシャイン牧場の運営者またはmixi側の公式発表をお待ちいただければ」ということは、技術的な詳細を発表する予定があるということなのでしょうかね。被害については、「サンシャイン牧場の運営者やmixi側でわかるかどうかも断定できかねる状況」だそうで。

関連する話題: ゲーム / サンシャイン牧場 / セキュリティ / 情報セキュリティ早期警戒パートナーシップ

特殊な知識を持った人 (サンシャイン牧場の件・朝日新聞版)

公開: 2017年9月25日14時35分頃

サンシャイン牧場の件、朝日新聞はこんな感じです : 「ミクシィ利用者の個人情報丸見え 4200人分、3日間 (www.asahi.com)」。

さらに10月21日から23日にカード決済した約4200人の電話番号とメールアドレスが、プログラマーなど特殊な知識を持った人が操作すれば閲覧できる状態だった。ミクシィは「一般の利用者が目にした可能性はほぼないと考えられる」と言い、今のところ個人情報を悪用された報告はないという。

昨日の毎日新聞では「本人と偽ってプログラムを操作」でしたが、朝日新聞は「プログラマーなど特殊な知識を持った人が操作」だそうで、なんだかどんどん難しそうな感じになっていますね。

※たぶん、マークアップエンジニアも「など」に含まれるのでしょう。しかしこの伝で行くと、この前のW2Cでの話で紹介したFF13の話なんかも「特殊な知識」が必要ということになりそうな感じがしますね。

関連する話題: ゲーム / サンシャイン牧場 / セキュリティ / 情報セキュリティ早期警戒パートナーシップ

2009年11月3日(火曜日)

本人と偽ってプログラムを操作 (サンシャイン牧場の件・毎日新聞版)

公開: 2017年9月25日22時35分頃

サンシャイン牧場の件、毎日新聞にも出たようですね : 「ミクシィ:ゲーム利用者の情報閲覧一時可能に (mainichi.jp)」。読売新聞の記事とは微妙に異なるのが興味深いです。

同社が調査した結果、クレジットカードでコインを購入した利用者4200人分の電話とアドレスが1件ずつ閲覧できる状態になっていた。

これは実は重要な情報で、あくまで「1件ずつ閲覧」できる状態だったということですね。中には「リストが見えるようになっていた」と誤解している方もいらっしゃるようですが、そうではないということです。

1件ずつしか取得できないと言っても、繰り返せば大量の情報を取得することが可能ではあります。が、そんな派手なことをしたらRekooのサーバのログにあからさまな痕跡が残るはずで、調査ですぐに判明します。悪用された可能性は低いと発表されていますから、おそらく、このような大量取得の形跡は認められなかったのでしょう。

※まさかログがないなんて事はないですよね……。

ミクシィによると、カード決済時のシステムに不具合があったのが原因。他人の電話やアドレスを閲覧するには本人と偽ってプログラムを操作する必要があり、一般の利用者が情報を目にした可能性は低いという。

これはたいへん興味深いですね。本人と偽ってプログラムを操作ですか。良く分かりませんが、なんだかとっても難しいことをする必要があったという印象を受けますね。

※「本人と偽ってプログラムを操作」という言葉が面白くて、笑いのツボにはまってしまいました……。取扱終了はまだかなぁ。

関連する話題: ゲーム / サンシャイン牧場 / セキュリティ / 情報セキュリティ早期警戒パートナーシップ

女番社長レナWiiはあのジョルダンのゲーム

公開: 2017年9月25日19時45分頃

女番(スケバン)社長レナWii (www.amazon.co.jp)」というゲームが話題になっています。話題といっても、「発売初週売上げが100本」という悲しい話題ではありますが……。

※参考: 「『女番社長レナWii』、初週100本で大コケ、賞金総額40万円のコンテストも開催中で数少ない売り上げも水の泡 (blog.livedoor.jp)

このゲーム、メーカーは「ジョルダン」となっていますね。ジョルダンといえば乗り換え案内で有名な会社がありますが、同名のゲームメーカーなのでしょうね……と思いつつ、何気なく「乗換案内 ジョルダン (www.jorudan.co.jp)」のサイトを見たら、トップページに「女番社長レナWii (rena-wii.jp)」へのリンクがあるではありませんか!

あの乗り換え案内のジョルダンがゲームを作っていたのですね。知りませんでした……。

関連する話題: ゲーム

サンシャイン牧場のアナウンス・追記

公開: 2017年9月25日18時55分頃

サンシャイン牧場・課金システムの問題についてのアナウンス」ですが、Rekooからの報告の中の「原因の究明及び対策の実施」の部分に、新たに文章が追加されていることに気付きました。いつ追加されたのかは良く分かりませんが……。

新しい文章は以下の通り。

  • 10月23日(金) 午後 原因の究明及び対策の実施
    弊社及びミクシィ社と、不具合について詳細な調査を行い、原因となるあらゆる可能性についてチェックを行い、対策を施し、不具合を解消いたしました。なお今回のトラブルは弊社側のシステムに問題があったことで生じており、決済代行会社のゼロ社の決済システム自体に問題はなかったと認識しています。

以上、[mixi] 「サンシャイン牧場」Rekoo | 課金サービス開始時の不具合について より

「なお」以降が追加された部分です。決済代行会社側の問題ではなく、Rekoo側の問題であることが明記されています。

※「決済代行会社に問題がなければ漏洩するはずがない」という主旨の事を書かれている方もいらっしゃるようですが、それは、決済代行会社が用意した仕組みを正しく使っていればの話でして。根本的に使い方が間違っているような場合には、今回のようなことも起こり得るでしょう。

関連する話題: ゲーム / サンシャイン牧場 / セキュリティ / 情報セキュリティ早期警戒パートナーシップ

サンシャイン牧場の件が全国ニュースに

更新: 2017年9月25日15時30分頃

サンシャイン牧場の件ですが、読売新聞に出たようですね: ミクシィ、4200人の情報が3日間「露出」 (www.yomiuri.co.jp)

リクー社が調べたところ、判明しただけで80人分の購入した計38万円分のアイテムの記録が消滅していたことが判明。さらに、クレジットカードでゲーム内通貨を購入しようとした利用者4200人分の電話番号やメールアドレスが外部から閲覧できる状態になっていたことが分かった。

最大約4200人というのは、修正前にクレジットカードを利用した人の総数でしょうね。

80人で38万円購入というと平均5000円近いわけで、ずいぶん単価が高いように見えますが、その80人はおそらく、「前回のクレジットカードを使う」を選択して2回目の課金を行った人たちでしょう。もともと購入意欲の高い層だった上に、「Kコインが増えないので課金操作を繰り返した」という方もいらっしゃるようなので、単価が高く出ているのだろうと思います。

ミクシィは「現時点で個人情報を悪用されたという報告はなく、一般のユーザーが偶然に見た可能性はほぼないと考えられる」としているが、「今後、課金システムを導入する際には弊社として審査するなど、運用を見直したい」としている。

「一般のユーザーが偶然に見た可能性はほぼない」というのは、単に「現時点で悪用の報告がない」からそう判断しているのか、それともログを確認した上で言っているのか、どちらなのでしょうね。前者っぽい気もしますが。

いずれにしても、停止の判断や修正作業が素早かったために被害の拡大を防ぐことができた、と考えて良いのでしょうか。カカクコム事件では停止の判断の遅れが問題になりましたが、今回はそこはきちんと対応されたのではないかと思います。

ただ、対応後の告知は分かりにくかったようで。30日の夜に出た公式コミュニティのアナウンスには、10月31日までに49のコメントがついて止まっていましたが、今日になってコメントが100を超えています。mixiの「重要なお知らせ」にも出ていたのに、「コミュニティ内部でしか報告されていないのはおかしい」という旨のコメントが複数ついていますし、告知に気付いていない方も多かったようですね。

※追記: テレビのニュースでもやっていたようで : FNNニュース: 「mixi」上のゲームで利用者約4,200人分の個人情報が3日間にわたり閲覧可能な状態に (www.fnn-news.com)

関連する話題: ゲーム / サンシャイン牧場 / セキュリティ / 情報セキュリティ早期警戒パートナーシップ

人気のページ

最近の日記

関わった本など

デザイニングWebアクセシビリティ - アクセシブルな設計やコンテンツ制作のアプローチコーディングWebアクセシビリティ - WAI-ARIAで実現するマルチデバイス環境のWebアプリケーション体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践ウェブの仕事力が上がる標準ガイドブック 5 WebプログラミングWeb Site Expert #13Dreamweaver プロフェッショナル・スタイル [CS3対応] (Style for professional)

その他サイト