おっホイ別館　−　はてな村の物語

2012/05/01から解禁なった「Zeroプレーヤー」のお話、の続き。

色々利用し、評判を聞き、開発者さんからのアウトプットを拝見して、自分なりに再考をしてみたり。

5/4 0:00の時点で、色々と修正が入った事

・コメント入力欄の常時動画下部表示が可能に

・動画説明常時表示が可能に

も交えて、思考してみた内容を書いてみようかと思います。

■ 恐らく、最初に「動画の拡大リサイズに相当自信があった」事が、新プレイヤー開発の引き金だったんじゃなかろうか。

新プレイヤーで再生する動画窓サイズは、そのまま旧プレイヤーを拡大すればOKという大きさではありませんでした。

旧プレイヤーサイズは、これから急速に進むであろうモニタの高精彩化には耐えられないサイズであり、早急に対応する必要があったはずです。

ニコマスPとしては、画質があるんだから、安易に素材サイズ（古くなら横512、最近では横640）を弄らずにそのままにしてくれと言いたくなりますが、そのサイズではフルHDを軽々と飛び越えてしまったモニタ・タブレットその他で見た場合には、冗談のようなサイズでの再生しかできないわけです。

新プレイヤーのサイズ（横864）はそれなりに十分なサイズですし、ニコ動が溜め込んだこれまでの動画資産の再生でも、画質破綻が少なく見えました。

■ 新プレイヤーサイズでは、UIを変えなければならなかった（かも）

新プレイヤーサイズを画面に乗せてみると判るのですが、動画サイズの画面占有率が半端なく大きくなります。

一般的なPCその他、ニコ動を利用するシーンを考えてみれば、

横 1024〜1920

縦 600〜1200

程度の画面がメインであるはずです。

この中に、864x486の動画がデデーンと鎮座するわけで、サブノートPCなどの画面では、どのようにすればいいのか？

それこそ、他の情報なりUIなりを、どうすれば載せられるのか？

それなりに悩んだはずです。

■ UIの指針はなんだったんだろう？

もちろんこれも推測ですが、

１）とにかく雑多なリンク、ボタン、情報を整理

２）動画再生位置の固定（特に縦位置）→動画説明の折りたたみ、タグ表示の最小化等

３）Metro/iPadなどによるタッチ操作に破綻が無いこと

は、必須だった（と、製作者は思い込んでしまった）のではないでしょうか。

「動画がメイン」で「共通体験」を標榜していたという事であれば、様々な機器であっても、「ニコ動です！」という共通画面を作る必要はあったはずです。

しかし、これによって、

１）は、動画に対するアクション（コメント・マイリス・タグ弄り等）を行う為の手間を増やしました。

２）は、動画説明やタグ情報を楽しむ層にブーイングを引き起こしました。

３）は、マウス利用前提設計であれば可能であった、ボタン・リンクの詰め込みを排除しなければならなくなりました。

■ 何をすべきだったの？それとこの先どうすべきなの？

以前の騒動でもそうですが、ニコ動はユーザーの意見を”聞いているフリをする”のがヘタクソな訳です^-^;

Appleプロダクトでも、その他の成功したオンラインサービスでもそうですが、

基本的にユーザーの意見なんざ、そのまま実装する必要は無いんです。

それに縛られてしまえば、進歩はしても、進化はしません。

しかし、ユーザーの意見を聞いているフリをするのは、とても重要なんです。

新しいモノを出そうとするのであれば、用意周到に準備と仕掛けを行い、テスト版を見せ、その背景とポリシーを説明する。

今回の新プレイヤーにしたって、

「テストしますので、まず気になる人は見てやって下さい。」

「動画が大きくなります。頑張ったから綺麗なはずです。」

「色々UIは整理しなきゃ動画をズバッと見せることが出来ないんでこうなりました。面倒に思った所を聞かせてください。」

とやっていれば、ここまで怨嗟の声が大きくなるわけもなかったはずです。

どういう評価が生まれるか判らんものを、金払ってるユーザーにどばっと展開するなんてありえないでしょう。

ヘビーユーザーとライトユーザーを両立させるのは、とても大変な訳です。

ヘビーユーザーであればあるほど、「操作の短縮化」と「覚えた機能の変動を許さない」方向に行きます。

MS-Officeその他のリボンUI同様、あまりにも増えてしまって不恰好となった機能ボタンを整理し、ライトユーザーに、多くの機能を順番に判りやすく覚えてもらうようにする事は、ヘビーユーザーにとっては我慢ならん手間を発生させてしまいます。

（まぁ、以前から、ニコ動の各種機能は、ヘビーに使おうと思うと「ふざけてんのか」と言いたくなるほど、その機能のUIが甘い事が多々あったりもするわけですが…ｗ）

新旧プレイヤーを切り替えて使えば判るとおり、旧プレイヤーには一目で入ってくる情報が多くなりすぎた面は、確かにあるでしょう。

新プレイヤーでは、画面サイズの制約もあり、ファーストルック画面（スクロール等の操作無く目に入る画面）上で、旧プレイヤー同様の情報を乗せ、1クリック操作可能箇所を大量に盛る事は、したくなかったのかもしれません。

MetroUIの件も含め、これから先、Webコンテンツサービスには、とにかくUIに関して様々な問題が浮き上がってきます。

ここに挙げた通り、

タッチ優先orポインタ操作優先／Windowシステムor1アプリフルサイズ

あまりにもバラけてしまった想定利用者の画面サイズ

の2点だけでも、シロウトな私でも、担当者なら逃げ出したくなるんじゃないかと思うほど、検討しなきゃいけないことが有りますし。

但し、前エントリにも書いた通り、「操作方法/デバイスが1つに決まる未来」はありえないのです。

Look＆Feelの重要性も必要ではあるのですが、それぞれに適した画面の追及は継続すべきでは無いでしょうか。

そしてその中で、改善して欲しいという意見に対しては、

「実装するor実装しないならそれなりの根拠を言葉or態度で見せる」

という姿勢が必要なのではないかな、と思います。

ニコ動に足りないのは、ここじゃないですかねｗ

2012/05/01から解禁なった「Zeroプレーヤー」のお話。

私のTwitterラインは製作者さんが多いので、怨嗟の声がコレを書いている間にも渦巻いている訳ですがｗ

【新プレイヤーの印象】

■一番気にしてたのは、元動画サイズからのスケールアップによって、動画が汚く見えるんじゃないかという心配は無かった。

これは、単純なスケールアップではないのか、解像度のマジックなのか、思ったよりもずっと元画質を維持できてました。

前プレーヤーで再生窓を大きくした時の画質破綻を感じる事無く、古い動画もそれなりに見えるようにしたことは、個人的に拍手を贈りたいと思います。

…とはいえ、今度は製作者として、新サイズに対応できるかどうか、製作環境の調整とテストをしなきゃいけないわけですが^-^;

検証用：

640x360でUpした自作動画

【亜美真美誕生祭2011】XANADU−桃源郷的な何か。

864×486にスケールアップされて再生っぽい。

512x288でUpした自作動画

いおりんもシャンソンで気取ってみたようです【オー・シャンゼリゼ】

648x364にスケールアップされて再生っぽい。

→ （追記）512x384で上下黒帯でした。。（汗）そういや512x288で作ってた作品って、上げてなかったなぁ。

512x384でUpした自作動画

【昭和メドレー3】ヤッターマンED／天才ドロンボー

648x486にスケールアップされて再生っぽい。

■PCから俺は見てんだよ！新UI使いづれぇよ！

ぶっちゃけ、このUIは「タッチパネル操作」を目指しすぎていて、マウスで指定したり、キーボードアクションしたりといった、PC向けのUIじゃありません。

タッチパネル操作に必要なのは、とにかく「アクション可能箇所のサイズをどれだけ大きくするか」という事。

そういう意味では、PC上からではふざけてんのかと思うようなコメント入力操作は頷けます。パネルから旧プレイヤーでコメント打とうとは思わんですものね。

他のアクションについても、指で大雑把な操作でもちゃんと意図した通りの操作に出来るように出来ているので、さぞかし”目的の機器からは”使いやすいでしょう。

■動画情報を端っこに追いやるとか舐めてんのか？とは思うけども。

画面固定でスクロールしない事を前提にした構成。一見では見れない為に、とにかくアクションしないと動画情報が見れない仕様についても、フルサイズ固定画面を前提にしてみれば、このUIはソコソコ良くできてると思います。

しかしタイトル脇をクリックで投稿者コメ＋α、ってのは、判り辛ぇ…！ｗ

製作者モチベーションの向上の為に、再生数や投稿者コメが一見して判らずあんな位置になるのは許せん、という意見も見ますが、1画面固定前提では仕方ないかなぁ…と思います。

【新プレイヤー、使い続ける？】

一応、自分は新プレイヤーで固定にするつもりです。

PCからはアクションに必要な操作が2段3段増えてる事は判っていますが、まぁ、新しいモノ好きなのと、新サイズの検証はやはり必要だと思いましたし。

【こんなクソなUIが主流になるん？】

自分の疑問はここに集約されます。

言わずと知れたiPad、そしてWindows8が目指す、Metro UI。

どちらもタブレット系UIが主流になるという将来を目指して、作りこまれたものではあるのですが…

今までのPC系UI舐めんなよと。

PC系UIは、情報入力と情報閲覧に関して、バランス良く操作の最小化を目指してきたUIだと思います。

タッチパネルは、情報入力はソコソコに、情報閲覧と指操作にやや特化したUIです。

既存のPC系UIは、PCで業務やコンテンツ製作を行う事に必要なUIであり、それが少数派になる未来は、あまり想像できません。

もっと言えば、タッチパネルUIに全てが集約されると思ってる人は、PCで作業をした事が少ない人か、新しいモノ＝正義とするタイプではないでしょうか。

3Dコンテンツに飛びついて「これから映画は全部3Dだよ！」とか、既存のSNSの歴史を知らず「FaceBookが全部を制する！」とか言い出す、困ったタイプではないかと思います（毒）

この辺の関係に関して、丁度よい記事があったので、ここにリンクを。

アップルは“MacBookとiPadの統合”など目指さない――クックCEO／computerworld.jp

個人的にAppleはキライなのですがｗ クックCEOは「判ってる」と言わざるを得ない…^-^;

タッチパネルUIが必要なシーンと、既存のPC系UIが必要なシーン、両方とも生き延びる訳です。

であれば正解は１つ。

PC用のUIと、タッチパネルUI、どちらも利用シーンが判っているのですから、それぞれに受け入れられるべきUIがあり、共通化なんぞありえないのです。

両方のUIを覚える手間を、利用者は払わないと思っているなら、UIそのもの共通化ではなく、UIの直感的なわかりやすさをそれぞれで優先するべきでしょう。

という訳で、ニコ動においては、動画サイズはそのままに、「PC向けUI」と「Metro/iOS向けUI」の両立と、直感的判りやすさの追及をお願いしたいなぁ、と思いました。

こちらのTogetterエントリ

サーバのディスクの話

http://togetter.com/li/238411

に、大量にはてブがついているのをみて、今までの私の話などを。

このエントリが、何故に多くの人の関心を寄せるか…というと、「RAIDの一般化」という部分が大きいと思います。

今じゃSATA(&SAS)RAIDが、Intelチップに機能として搭載され、数万円台の外部NAS、RAIDカードで、RAID5,6どころか1+0や50まで構築できる時代。

「Diskが壊れても、データは壊れない！」という売り文句は、非常に魅力的だったりします。

今ではSATAのRAID1（HDD2本でミラーするだけ）なら、数千円のレベルでカードが買えますね。

では、Intelのチップセットや激安RAIDカードで、保護的RAIDを組んだ状況で、どれだけデータ保護が出来るかというと、

HDDの故障を救える確率と、ミラーが壊れてデータの不整合が発生する確率が、ほぼ同じ位になってしまう…というレベルでしょうか。

特に、安いRAIDの場合、ライトバックキャッシュの有効化は鬼門です。出来ればこれは無効にしないと、HDD物理障害を含む様々な要因でOSが不安定になった時に、データ不整合が簡単に発生してしまいます。

では、HDDの信頼性そのものはどうなのか？と言われると、確かに件のエントリに書かれている通りで、初期不良率が３％〜５％程度混じるレベルのブランドがあるのは確かだったり。

私の経験（15年前〜現在までの、単体〜中規模RAIDアレイがメインです）からみても、SCSI対ATA（現在ではSAS対SATA）の信頼度の違いは確実にありますし、それを束ねるRAIDにおいて、論理・物理障害によるデータ破壊の確率は、その束ねたHDDの数だけカーブを描いて上がります。

10年位前のサーバで、OSレベルのソフトウェアミラーRAIDを組んだ機器の保守運用もやっていたりしますが、壊れるのは殆どがATA系のHDDばかりで、SCSI系のHDDはほんとに壊れにくいです。

もちろん、「Diskがどれだけ実際にデータアクセスするか」によっても、故障率は左右される訳ですが…

HDDの信頼度を維持する為に、構築運用屋が検討し実施することといえば、

■エージング（継続したランダムHDDアクセスをしばらく仕掛けて、初期不良品を弾いたり、長期利用可能であることを確認する）

■設置場所の温度維持（HDDは本当に湿気と温度変化によって、故障率が変ります）

■サーバorストレージ筐体の選定（HDDマウント部分及びエアフロー）

■ケーブリング（SATAのケーブルは、安物だと緩くてアウトなケースが。。）

■Microcodeの更新（HDDにもいわゆる「ファームウェア」がありますし、メーカーから訂正版が出ることが多々あります）

■ドライバの更新（FCカードやSCSI/RAIDカードのドライバの更新などは、ほんとに頻度が高いです。）

■RAIDの組み方の検討（実用レベルならRAID1,5,6,10,50とホットスペアを検討して、パフォーマンスとデータ保持を天秤にかける必要があります）

■最終バックアップの取得と方法（ミラー＆スプリット、テープ保管、差分保管等）

といった所でしょうか。

これだけみても判るとおり、ここの部分においては、構築運用経験が欠かせませんし、出来れば物理層のレベルでの知識も欲しい所ではあったりします。

サーバの保守運用といってもピンキリで、100万円以下のサーバをラックに積んで、小規模な社内向けサービスを組む程度から、億単位のストレージを運用する事まであるわけです。

考えなくてはいけない事は、「掛ける費用や人員と、データロスト時の被害レベル」を算出して、データ保護に掛ける費用と手間と責任範囲を明確にする事。

当然のようで、ここをなあなあにして運用を始めて、いざ事故が起きた時に責任の擦り付け合いになるケースが本当に多いです。

全般的に言えることとしては、「お金が掛かるのは、それだけの理由がある」という事。

どのようなメーカー製のサーバであれ、安いサーバHWと、高いサーバHWは、ちゃんとそれなりの理由があったりします。

HDDだけが、この例外から逃れられるわけもありません。

ぶっちゃけ、どんなメーカーの製品であれ、100万以下で買えるPCサーバには、メーカーは大して長期運用を目指した設計なぞしていません。

　安ケミコンぶち込んで、コンデンサのお腹がパンパンだぜぇ…

　廃熱計算もせずにGPUチップのせたら、DC環境下でも異常高温で50日に1回程度勝手にOS停止

　CPU横付けにしたら、ヒートシンクの重みでソケット足がゆがんだ

　稼動チェックしない大容量メモリを積んで、10%弱の不良品を出荷

　RAIDカードとバッテリを一体化したら、バッテリが膨れてRAID基盤が歪んだ

　2重化電源なのに、故障した電源ユニットを抜いたら筐体停止

　1年電源ON稼動で、ファン故障率5割越え

など、など。もちろんそれぞれメーカーは異なります。HP,旧COMPAQ,IBM,DELL,SUN,富士通,NEC,日立。どこのものでも「ありえます」。

ストレージメーカーから人員を出すレベルのシステムであれば、ストレージ設計自体を引き渡す事も可能ですし、対障害レベルについて、ヒアリングの段階から任せる事が出来たりもしますが、某メーカーだと、出してくる人員のスキルが…ゴニョゴニョ…とか。（汗）

そして何より、RAID故障よりも頻発する障害は、「運用でデータが壊れるor消える」こと。

人的ミスやOS・アプリケーションのバグによるデータロストは、HWの故障などよりもずっと多くありますし、それに耐える運用（バックアップ頻度とリストア手順・時間の検討）をしなければなりません。

先ほどのエントリでは、「メールサーバとSATAを組み合わせるな」というような話がありますね。

メールサーバというより、「特定のディレクトリに、大量のファイル作成・削除が発生する運用が前提のアプリケーション」というべきかもしれません。

LinuxやWindowsなどの、既存のFileSystemにおいては、1つのディレクトリ直下に、数千を越えるファイルを置くような運用をすると、ファイル読み出しだけで目に見えてレスポンスが悪くなりますし、ディレクトリファイルそのものが壊れて、データの論理異常が発生する確率があがります。

メールキューファイルやメールボディファイルを、1つのディレクトリ直下に置くような運用をせず、アプリ側でディレクトリを分散させる方法を考えるべきですね。

こんな事を考えていくと、「データ保護には何が必要なのか」という命題に対して、RAIDレベルやHDDの信頼性というような部分よりも前に、まず考える事があるのに気付くかと思います。

以下に挙げてみますが、会社のデータが入る機器であれば、メーカー問わず利用形態問わず、最低限検討すべき内容かと思います。

１）HDD及びストレージの中に入るデータが、どれだけ貴重で、ロストしたときにどのような手を打てるか。

定期的に、データの更新を止めて、そのバックアップを取れるシステムであれば、それこそ安いサーバでソコソコのRAIDを組んでおけば良いという判断はありですし、それがコストパフォーマンス上も正しい判断です。

但し、必ず復旧すべきデータなのであれば、その手順と対応コストも加味しなければなりません。

２）アクセスパフォーマンスの確保

DBサーバ、流通量の多いメールサーバ、コンテンツサーバなど、1日にテラ単位でデータが更新される事がありえるサーバであれば、RAID1+0以上の検討やキャッシュ設定、メンテナンスしやすいように特定部分だけを外出ししたり、その部分のHDDの寿命を短めに見積もったり、など。

最近ではSSDの検討なども必要になるでしょうか。

３）サーバの利用を止めて定期メンテナンス出来る日程と、緊急メンテナンスが必要となった場合の承認フローの作成

PCサーバレベルであれば、最低でも月1で6h程度のメンテナンス時間は確保したい所です。（OSのアップデート、microcode適用等）

更に、稼動状態でバックアップが取れないようなシステムであれば、頻度とバックアップ時間も確保する必要があります。

※ここが一番難しいというか、なあなあにしてしまって、一回痛い目を見てから再検討となる事が多いですね。。

４）どれだけ費用と運用時間を掛けられるのか

「絶対データは保護しろ、24h365d稼動させろ、金は出来るだけ掛けるな」というのが案件になる事、多いですよね。もしくはこれが暗黙の了解になっているケース。

9割は上手く行くのかもしれませんが、残り1割が発生したときの事を考えるのが、構築運用屋に必要なスキルです。

中のデータ、システムが生み出す利益との兼ね合いですが、まずは中のデータの重要性とサービス要求レベルをほぐしてみる事から始める必要があります。

どのようなストレージ製品を使い、HDDのRAIDレベルをどうするかという検討は、少なくともこれらを決めた"後"の話。

これらをきちんと細かく検討していれば、それほど悩む事ではない…と、私は思いますし、データセンター構築レベルの仕事でない限りは、十分だと思います。