いつか作ります RSSフィード

2008-08-26

[]ニコ割アンケート文面検討 23:33 ニコ割アンケート文面検討 - いつか作ります を含むブックマーク はてなブックマーク - ニコ割アンケート文面検討 - いつか作ります ニコ割アンケート文面検討 - いつか作ります のブックマークコメント

  • Q1. あなたは、MADをよく見ますか?
    • 1、よく見る
    • 2、たまに見る
    • 3、ほとんど見ない
    • 4、知らない・見たことがない
  • Q2. MADを作る文化についてどう思いますか?
    • 1、面白い文化なので残すべき
    • 2、面白いけど、こっそりやるべきものである
    • 3、面白くないので残らなくてもよい
    • 4、わからない
  • Q3.MADが元のオリジナル作品に与える影響についてどう思いますか?
    • 1、元のオリジナル作品に興味がわき宣伝になる
    • 2、元のオリジナル作品には興味がわかないので宣伝にはならない
    • 3、元のオリジナル作品のイメージが壊れるのでマイナス
  • Q4.MADを作るときのルールをどのようにするのがいいと思いますか?
    • 1、著作権者に事前に許可をとってからでないとつくってはいけない
    • 2、自由にMADをつくる権利を認めるべき
    • 3、自由にMADをつくる権利を認めるべきだが、著作権者に対価を支払う仕組みを作るべき
  • Q5.ニコニコ動画にMADは必要だと思いますか?
    • 1、必要
    • 2、必要だが、無くてもやむをえない
    • 3、必要ではない
ニコ直しアンケート結果

酷いね。

定量化できない質問

アンケートを取る意味と言うのは、意見を定量化する事にある。「なんとなくMADを見る人が多い」ではなく「全体の何%の人がMADを頻繁に見る」と言えるようになる事に意味がある。

Q1は、定量的な聞き方をしなければならない。

「あなたはMADを週に何本程度見ますか」「あなたの見る動画のうち、MADは何割くらいですか」というように。

「あなたはMADを週に何本程度見ますか」という質問には答えづらいと言う配慮は分かるが、安易に定性的な質問に変更するのではなく、答えやすい定量的な質問を検討しなければならない。

対称性を保つこと

  • あなたはハンバーグが好きですか
    • ものすごく好き
    • かなり好き
    • 割と好き
    • どちらかといえば好き
    • 嫌い

ハンバーグが好きな人と嫌いな人、どちらが多いかという結論を、このアンケート結果から算出できるだろうか。

Q2もこれと同じ過ちを犯している。1,2を足して3を上回ったからMAD支持派の方が多いとか言い出しても、マトモな人間は誰も相手にしないだろう。

軸を数える

Q2。「個人的には面白いとは思わないけど、MADを作る人の権利は尊重すべきだ」という意見(面白いけどこっそりやれ、のカウンターパート)はどこに入るのだろう。

この質問には「MADを面白いと思うか」と「MADは(アニメのように)社会的に広く受容されるべきか」という2つの軸がある。1問で聞くならば最低でも2*2プラス1(分からない)で5つの候補を用意すべきだ。あるいは、設問を2つに分けるか。

(面白い/面白くない、認められるべき/べきではないはYes/Noではっきり答えられる設問だし、円グラフで見せる事も考えると、今回は5候補用意するのが一番効果的だったと思う)

回答≠解答

Q3。せっかくいいチャンスだったのにもったいない。

聞くべきはこうだった。

  • あなたはMADを見て、そのオリジナル作品を何度買った事がありますか?
  • あなたはMADを見て、オリジナル作品をいくら位購入しましたか?

このアンケートが高いポイントを収めれば、「元のオリジナル作品に興味がわき宣伝になる」という結論を得られる。

アンケートによって得たい結論と、アンケートの回答をごっちゃにしてはいけない。

多数決で決めるべきでない質問は出さない

Q4。「事前の許可は必要だが、ニコニコモンズのように、事前にライセンスを決める事を習慣として定着させるようなインフラが必要だ」などの意見が出せない。

議論を尽くさず早急に多数決に飛びつくのは小学校で卒業しよう。

他の意見を持っていそうな人が多い設問は「回答できねえよ!」という多数の人間を生む。そういう人は適当な選択肢を選んでしまうので、アンケート自体の信頼度が大きく落ちる。

2008-08-27 22:58追記

と、苦言を呈したけれど。

今回のアンケート結果はこんな問題を考えるまでも無くかなりぶっちぎりに偏った結果が出ているので、「やり直せ!」とか主張する気は毛頭ない。何度やり直そうと、全体の結論は「MAD支持者が多い」に落ち着くだろう(Q3、Q4辺りは質問を変えて聞きたい気もするが、やり直しではなくいっそ別箇に質問を立ててもっと突っ込んだ調査が為される事を期待する)。

そもそもそういう結果になるのは目に見えていたわけで、もしかして定量調査としての精度は最初から期待していなかったのではないか、と思っている。問題提起、話題提起、あるいはニコ割アンケートの存在感アピールが目的とか、あるいは「MAD支持者が圧倒的に多い」という方針で動くための既成事実作りとか。

2008-08-24

乗り物酔いと3D酔い 01:29 乗り物酔いと3D酔い - いつか作ります を含むブックマーク はてなブックマーク - 乗り物酔いと3D酔い - いつか作ります 乗り物酔いと3D酔い - いつか作ります のブックマークコメント

乗り物酔いは、体が動いているのに視界が動いていないというギャップによって三半規管が混乱して生じる。

だから、きちんと前の風景を見て、自分の体が動いているという情報を脳に送ってやると解消される。

3D酔いは、体が動いていないのに(ゲーム画面と言う)視界が動くことによって三半規管が混乱して生じる。

対策はゲーム画面が自分の視界ではない事を脳に分かりやすく教えること。視野角を落とすのが技術的な解決策だが、視界を広くしモニターの縁を意識するようにする事でも解消される。

2008-08-16

コモンズ公式提供素材について 13:23 コモンズ公式提供素材について - いつか作ります を含むブックマーク はてなブックマーク - コモンズ公式提供素材について - いつか作ります コモンズ公式提供素材について - いつか作ります のブックマークコメント

運営からの提供素材という事は、暗黙のうちに運営が想定している「使い方」を提示している、と考える事ができる。

というわけで妄想してみた。

ロゴ

コンシューマー向けの事業をしている企業人であれば分かると思うが、大きな企業であればあるほどロゴの使用許諾にはうるさい。

赤の他人には許可されず、社内であっても使っていい文脈とか、余白の大きさ、背景のコントラストによる色バリエーションなどが厳密に定義されている事が多い*1。なんでかというと、ロゴはその会社のイメージそのものだから。いっぱんに、デザイン戦略、イメージ戦略を考える上で真っ先に取り掛かる最優先事項が、ロゴの使い方を決めること。

で、そんな中、ニコニコは自分とこのフラッグシップ・サービスのロゴを(ライセンス条項付きとはいえ)誰でも使って良いよ、と公開したわけだ。当然、どういう意図か考えたくなる。

  • ひとつの見方は、単にブランドイメージと言うものへの認識が全社的に薄い、という可能性。
  • もうひとつの可能性は、「ニコニコのブランドイメージはユーザー全体で作り上げる」という思想の表明であるという可能性。

思いつきで挙げてみたけど、まあ前者だろうな。後者だったら格好いいのだが。

メガネ

どう考えても素人クオリティの、運営ブロマイド。素材としても使いにくいし、なんだこれ。

  • ニワンゴ/ドワンゴで素材全部を提供する気はない、という放置運営意思の表明
    • i.e.もっと「使える」画像が手元に無かったから上げていない、というだけ
      • 使える画像は持っている人が上げればいいのであって、別に全体的なカバレッジを自社でサポートする気もないし、要望に答えて素材を追加する気もない、という事だろう
    • 音楽素材は運営から上がっているが、これは「着メロ会社」として手持ちのリソースを割いたに過ぎない。絵描きが画を上げるのと同様、音楽屋だから音楽を上げた、というだけだろう
      • つまり、作品提供に関しては「参加者」のひとりに過ぎない、と言うスタンスだと推定できる
  • 素人クオリティの糞素材でも歓迎する、という意思の表明
    • 少なくとも、メガネの写真以上のクオリティであれば、上げて文句を言われることはないと
      • 実際、地下鉄構内の写真(ケータイ撮り!)とかの、箸にも棒にもかからない素材が既にガンガン上がっている
    • 質の高い素材が集まる場、ではなく、質はごった煮状態でいい、という運営スタンスなのではないかと推定できる

JASRAC素材

JASRAC楽曲のmidiが運営から上がっている。これも

  • JASRAC管理楽曲であっても上げる事が可能
  • しかし、CDのような音源を上げることは出来ない

というガイドラインの役目を暗に果たしている、と言えるかもしれない。

(補足:一部報道で「ポニョも公式配布」とか書いてあったが、ジブリの許諾は取っていないだろう。midiであれば、JASRACの許可さえあれば作成/配布が可能である。これは「演奏してみた」も同様)

http://fragments.g.hatena.ne.jp/fukken/20080705/1215241437

*1:だからこそ、googleの「ロゴを季節によって改変する」というデザイン戦略が画期的だったわけだ。あれは要するに「うちはIBMやMicrosoft、Yahoo!のようにブランドイメージを押し付けるような企業様ではなく、こんな事ができる遊び心ある企業だ」というブランドイメージ構築戦略である

2008-08-10

ヒッピー2.0 22:12 ヒッピー2.0 - いつか作ります を含むブックマーク はてなブックマーク - ヒッピー2.0 - いつか作ります ヒッピー2.0 - いつか作ります のブックマークコメント

439 名前: 百威(東京都)[] 投稿日:2008/08/10(日) 11:18:46.08 id:GgbOJ19c0

そりゃ冷暖房がどうとかネット環境がどうとか言い出したら

木造ボロアパートより快適かも知れないけどさ、

大きな違いはボロアパートでも借りればそこに家具、荷物、財産を置けるという事なんだよな。

これ以上の快適さは無いだろ?

滞在時はどんなに快適であっても、出るときに荷物を全部持って出ないといけない。

ネカフェ生活なんか、長くは続けられない。

越えられない壁( ゜д゜):ネットカフェ難民の平均月収は16万5000円、半数以上が債務者で、その内4割は100万円以上の借金持ち

逆に言えば、物理的なモノや空間の所有に興味がないのならば、ネカフェは案外住み心地がいいのかもしれない。

メールだってmixiだってネカフェからログインできるし、ケータイだってあるわけで、他者とのコミュニケーションが断絶するって事もないし。

(実際、2chのオフ板にはスレ住人の家を転々としながら生活してると言う「お前はどこの家出中学生だ」といいたくなるような人間もいた)

勿論本気で困ってる人もいるだろうし、そういう人をなんとかする仕組みは必要だと思うが、案外「住めればそりゃ家のほうがいいだろうけど、別にネカフェでも特に困ってないしなぁ…」とか思ってるような人も結構いるんじゃないかという気がする。日雇いで転々とネカフェに連泊してる間に「あれ?ここ1月俺家に帰ってなくね?家って案外いらなくね?」と思っちゃったとか。

2008-08-06

同質文化と「コモンズ」 00:40 同質文化と「コモンズ」 - いつか作ります を含むブックマーク はてなブックマーク - 同質文化と「コモンズ」 - いつか作ります 同質文化と「コモンズ」 - いつか作ります のブックマークコメント

“ライセンス違反している”作品の、どれを削除し、どれを削除しないかについての判断は、権利者に委ねられます。そしてその基準を事前に明確にしておく義務もありません。

違反しているものはいつどんな理由で削除されても文句は言えません。

違反しているのに削除されないのは、ただ権利者の都合で“見逃されているだけ”に過ぎません。

要するに、何も言わない限り、二次創作を消すか消さないかは一次創作者の胸三寸。こんな状況ではオチオチ二次創作なんぞしていられない。だからこそ、コモンズが必要になる。

(クリエイティブ・コモンズでもニコニ・コモンズでもいいが)


この件に関してはそもそもライセンス違反なわけで議論の余地は無いのだが、論旨が「投稿者の気持ちを考えようよ!」ばかりで非常に気持ちが悪い。

まあ、ライセンスと言う無機質なルールで縛るよりも、同質性のぬるま湯に漬かってなあなあで使用許諾を出したり出さなかったり、まあその辺はよろしくやっていきましょうや、という運用の仕方のほうが一般人には受け入れられやすかったりするのかもしれないが。


ところで、今回の件で、原著作者が仮に「対象となる動画の削除」ではなく「損害賠償」を求めた場合、判断はどう変わっていたのだろう。論理的に言えば、どちらも著作権の正当な行使であり、一方を否定して一方を認める理由は無いのだが。

2008-08-02

OOコード養成ギプスのへっぽこ解説 19:39 OOコード養成ギプスのへっぽこ解説 - いつか作ります を含むブックマーク はてなブックマーク - OOコード養成ギプスのへっぽこ解説 - いつか作ります OOコード養成ギプスのへっぽこ解説 - いつか作ります のブックマークコメント

そもそも何を言っているのか分からない、というレベルの人間向け。

まあ、そういう自分もどこまで理解してるか怪しいものなのだが、だからこそ書く。

例に出すものの中には明らかに設計がマズいものも混ざってるが、あくまで問題になってる部分だけ見るって事で。

インデントは1メソッド1レベルのみ

ループのネスト、制御構造のネストをすると、その階層分だけ「いまどういう状態か」を覚えながらコードを読む必要が出てくる。

「ケータイで、キャリアがDoCoMoで、ユーザは18歳以上で、すべての所持アイテムに対し…」

じゃなくて。

  • ケータイかどうかを判定したら、ケータイ処理用の関数を呼ぶ。
    • ケータイ処理用の関数ではキャリアを判別だけしてDoCoMoユーザ用の関数を呼ぶ。
      • DoCoMoユーザ用の関数では18歳未満かどうかを判定して、子供向けの関数を呼ぶ。

複数のCSVファイルを扱うときは

  • 単一のファイルを開く
    • 単一の行を開く
      • 単一のセルをパースする

というように、関数を階層構造で分ける。*1

'else'は禁止。条件文はifだけ。

たぶん上記と絡む問題。elseを使うと、条件分岐のネストが可能になる。elseを使わなければ、そもそも条件分岐のネストを完全に封じられる。

あと、多重ネストのif-elseは、どのレベルに対応しているか読みづらいし書き間違えやすい。

追記:ガード節を使うとこのプラクティスをクリアしやすい。

if(...){
 // 処理A
}else{
 // 処理B
}

の場合、

if(){
  return 処理A関数();
}
 // 処理B、もしくは関数呼び出しを即return

とすると、処理Bの部分がちょっとスッキリする。条件分岐の整理にも有効。ファウラーの『リファクタリング』参照。

ガード節の後を関数呼び出しにするかガリガリ書くかは処理しだい。「ある変数がセットされているかを調べる」ガード節なら書いてしまったほうがいいが、「変数でモードを切り替える」ような場合は別のメソッドに切り出した方がいい。

全部のプリミティブとstringをラップせよ。"primitive obsession."だ。

"primitive obsession"は、プリミティブ型の使用をしないという事。要は全部クラス(あるいは構造体)にしろって事。

  • ひとつ。たとえばURL文字列を専用のクラスに格納していると、ドメインだけ抜き出すとかファイルパスだけ変えるとかの操作が可能になる。正しいURL形式かのチェックも可能になる。こんな感じで機能をメソッドと言う形で追加できる。
    • プリミティブ型にはふつうメソッドを持たせられないので、URLを文字列として格納していた場合、こういう機能がコードの各所に散る事になる。セットで使うものは、セットにしておくべし。
  • ふたつ。その数字なり文字列なりが「何を示しているのか」が非常に明確になる。変数名よりもかなり明白で厳密な形で。
  • みっつ。専用型になっているものをプリミティブに直すのは簡単だが、その逆は困難(すべてのintに対し、「これは年齢を示しているのか」を考えないといけない)。

1行に1つのドットのみ使うこと

company.section.team.leader.work() という指示の出し方はよろしくないですよ、と。

company.work()がsection.work()を、section.work()がteam.work()を…と階層的に呼び出されるようにしておかないと、発注元の会社が相手先企業の内部構造に依存する事になる。

Rubyとかでstring.split.sort.reverse.eachとかやる場合は多分例外。階層を辿るアクセスじゃなくて単なる処理のチェインだし。

ただ、メンバーや引数の関数の戻り値に関数を適用し、その戻り値に関数を…という呼び出しが多い場合はクラス設計を見直すべきかも知れない。

名前は省略しない

自動補完が利く環境なら、省略して分かりづらくする意味が無い。利かない環境では原文の通り。

エンティティを小さく保つこと

1メソッド、1クラス、1パッケージが大きすぎると、再利用しにくくなってOOPの利点が活かせない。


3つ以上のインスタンス変数を持ったクラスは使わないこと

要はインスタンス変数が多すぎると機能が増えすぎでよろしくない、という事。「3以上」なのは、理論上考えられる最低値がこれだからだろう。2つをNGにすると組み合わせる事ができない。

よく引き合いに出される、Point3Dクラスのx,y,zのような、本質的に3以上のものが1セットな概念は多分例外だろう。

追記:このパートに限った話ではないが、関数型言語の考え方がかなり色濃く現れている。RubyやPython、JavaScript以外でこれを完全に実践するのは困難。

ファーストクラスコレクションを使うこと

コレクションを含んだクラスが必要なら、そういう風に書くんだ

まんま。たとえば

class Team
{
	string teamName
	array members
}

と書きたくなったら、Members*2というクラスを定義し、それをメンバとして持たせろ、ということ。

配列じゃなくてコレクションクラスを使うのは、プリミティブ型を使うなってのと同じ。


セッター、ゲッター、プロパティを使わない

前のエントリで触れなかった辺りの事を。

あるクラスからメンバをget()して、それを元に処理をする、というコードを書いたら、そこでいったん立ち止まってこう考える。

この処理は、get元のクラスがメソッドとして持つべきではないか?

一般に、メソッドと言うのは、必要な変数を持っているクラスに実装するのが良い。そうじゃないと、あるものに対する処理があちこちに散らばる結果になる。

「聞くな、言え」というのはこの事。そのクラスが知らないものを他のクラスに「聞いて」自分で処理をするよりも、他のクラスのメソッドを直接呼び出しその処理をさせる方が良い。「言うな、聞け」よりも「尋ねるな、命令しろ」の方がニュアンスが近いかもしれない。

で。setterが使えないとなると、メソッドの実行に必要な非メンバー変数は、引数として与える形が多くなっていく。これがDependency Injectionパターンの基礎。

*1:制御構造ではなく、データ構造を変える事でも実現できるが、同じことなので割愛

*2:あんま良くない名前ですね

新着エントリは上に追加。コメントは「はてなユーザのみ」、公開設定はパブリック (だれでも閲覧ができます)。