別冊はてな話 このページをアンテナに追加 RSSフィード

 | 

2005-08-09

長々コメントでおじゃましています

http://beta.g.hatena.ne.jp/yukatti/20050808/#c

ええと、出来れば文章全体を読んで頂ければ幸いです。あと、リンク先も。

わたしの言葉が足りないのかもしれませんが。

飲み込み悪くてすみません……。文の最初と最後でもう何を言われてるのかわからなくなったりしてます。リンク先から帰って来ると……文脈忘れたり。30分間HTML入門を6時間かけて半分読む男ですから……。その場その場でレスしていきますね。

>>ASINという対象物を定め

これについてですが、わたしはこう書いています。

ASIN という対象物を定めて、ASINなりASINページに関するアイデアをツリーにしていくという風にした方が良いんじゃないか、ということを言っています(ですのですぎおさんが書いているのとほぼ同じかな)。逆を言えば、「不具合を改善して欲しい」とか「説明を詳しくして欲しい」つながりで親子関係を作らないほうがいいんじゃないかな、ということです(そちらはタグでフォローするとか)。

うんうん

つまり、sugioさんの案からでは親子関係の作り方がよく分からないんですよ。

えっさっき書いたのは?>「親アイデアが実装・他の方法却下になれば、その子アイデアもすべて実装・他の方法却下にできるような関係が望ましい」

あいまいさが残るのが問題ですか?でしたら私は反対に、仕様で禁止できないルールを作るほど管理の手間が増えて荒れやすいと思いますよ。だから親子の定義をはっきりして遵守させるより、親子をつくることによって個人が得をしないようにすることのほうが重要だと思います。

だからわたしが考えるに、具体的なアイデアを親子関係のツリーにして行くときに、たとえば「asinページ文字化け不具合がある」「asinページブックマークコメントの載せ方」といった「asinページに関するもの」といったものをツリーにしていくほうが絞りやすいんじゃないか、

うんうん。私が面白いと思っている「問題点メタアイデア」を作るよりそっちのほうがいいはずだというわけですよね。

スタッフも作業しやすいんじゃないか(asinページ担当しているスタッフが作業すればよい)、

いっぽうで「asinページ文字化け不具合がある」と「日記ページに文字化け不具合がある」といった「文字化け不具合」といった現象や状況とかでツリーにするようなルールにはしないほうがいいんじゃないかな(そうしてしまったときこの例だとスタッフから見ても、asinページ担当者日記ページ担当者の作業の問題になってしまう)、と思った、という話です。

これはわからないんですけども、抽象的な問題を仕事にして割り振るためにミーティングがあるんじゃないですか?

現象が同じでも原因は違うかもしれません(もしくは同じかもしれませんので、たとえば現象や状況のくくりは関連付けやタグでフォロー)。ですので、表記揺れの話とかしているのではありません。

ここの部分は何をおっしゃりたいのかわかりません(担当者の視点が想像できないからだろうなあ……)が、現象が同じでも原因は違うことはありますよね。

また、ツリーにしていくための何でくくるかのレベルは最終的にはケースバイケースでアイデア毎にユーザの判断でやっていくしかないでしょう、sugioさん案を前提に考える限り。ですので、ある程度自由でよいと思います。

ああ、これもボトムアップ式に底辺から組み立てるツリーなんでしょうか。ちょっと形が見えなくて歯がゆいです。

>絶対にもめます。

ですが、わたしは、キーワードツリーがあった頃の経験がどうしても頭から抜けないんです。善意のユーザ同士の間でさえキーワードツリーの親子関係を定めるのでさんざんもめたりトラブルになったり互いに不愉快な思いをしたりしたんですから、まして利害関係のある(アイデアポイントの増減や実装されるかどうかといった問題)アイデアに親子関係のツリーを導入するのはかなり難しいんじゃないか、無理なんじゃないか、と思うんです。複雑になってしまってユーザの参加の敷居があがることが一つ、そして何より、親子関係をどう決めるかのはっきりしたルールが定められず解釈の余地があるのであれば、親子関係ツリーの導入はキーワードツリーの時のようにもめごとの元になるし、そういう無用なもめごとの元になるものは導入しない方がよい、と考えます。

キーワードツリー最大の問題は、「1個の親しか選べない」だったじゃないでしょうか。私の案のは複数の親が可です。またアイデアを作るにはポイントもいりますし、意味なく深い階層にもなりにくいと思います。

「利害関係のある」は大事なポイントですが、親になったり子になったりということで、どのような有利不利を受けるのか、なにかその操作でうまいことができるのかが、よくわからないのです。うまく議論を誘導する親アイデアのようなものが、作れるのでしょうか。

ルールの曖昧さについては、こういうサービスで、仕様ではできちゃうこと禁止してカッチリしないほうがいいという先ほどの通りです。「関連アイデア」なんて、なにが関連なのか定義されてないですもの。

>「ボランティアするユーザが権力者になって仕切ってしま」うというのも、どのような理由で起こるのでしょうか

詳しいユーザがツリーを動かす形になりがちだろうこと、

これはあるでしょうね。

キーワードの時と同様にツリーの定義をローカルルールを定めてしまう可能性があること、

ローカルルールと違うツリーを壊してまわるわけですか。ないとは言えませんが、なぜやるのでしょう……。

親子関係の定め方によってはアイデアポイントの行方を左右してしまうこと。

どうしてですか?

本人が権力者になる意図が無くても、結果としてアイデアを仕切ることになるのでは、ということを危惧します。

なぜツリーになると急に仕切り屋になるんでしょう。全体が見えないので分類欲は刺激しないと思いますし、親もいくつも選べますし。

キーワードツリーが崩壊したのは何故か、をわたしはどうしても抜けることが出来ません。キーワードツリーの時にも当初からずっとツリーに反対している人がいました。結局、ツリーに反対していた人のように、緩やかな関連づけの方がフレキシブルで自由で、タグと検索で要望を整理したり探したりする形のほうが多くの人が関連づけに参加しやすいように結果として思いますし、シンプルシステムの方が「詳しい人」ががんばらなければならない余地が減る。そちらのほうが、知識に差がある不特定多数が使うシステムとしては良いんじゃないでしょうか。

これはわかりますが、「がんばらなければならない余地」がよくわかりません。親子関係はキーワードツリーのように必須作業じゃありませんから、やりたくなければバランバランのままでいいし、関連づけだけでもいい。「議論をうまく整えて俯瞰したい」というような欲求がある人が、やりたいときやればいいと思います。

タグについては、

アイデアの整理機能として予め指定した専用の共通タグを指定しておいても良いかもしれないなと思いました。

と書いているとおりで(共通化のものを定義するのは多数使われるタグを判断した上でスタッフが定めるなりローカルルール的に自然に統一して行くなりといったことがあるでしょうけど)、ブックマーク的なタグ入力支援機能やグラフみたいなタグ一覧があると良いんだろうと思います。

グラフみたいなタグ一覧ってこれですよね。→http://graph.hatena.ne.jp/t

うんうん

>「何を」が重要

については、わたしが説明するよりも、日記に書いているリンク先でありはてなオブジェクト指向について述べているhttp: //d.hatena.ne.jp/jkondo/20050530/1117436338やhttp: //d.hatena.ne.jp/naoya/20050529/1117368670 を読んで頂いた方がよいように思います。』

オブジェクト志向のお話ですよね。まあデザインパターンもTemplateメソッドも Factoryパターンロジッククラスの中に内包もインタフェースプログラミングもメソッドの中のロジックデータベース周りをオブジェクトにすることも、意味がわかりませんが。

同じ質問ですが、なぜその発想で「ユーザー」が「ツリー」を作ると良いのでしょう?スタッフが同じ部分で発生している要望をまとめて見やすくなり、いっぺんに作業できるということですか?

あとその方法では、ツリーを作っても自治厨が出たりしないんでしょうか?

# yukatti 『わたしとしては、今のように「何を」にあたるサービス毎の分類だけでないほうがいいなと思っています。つまり、いろいろクロスチェックしてもらえるようにして欲しいなと……

でもツリーをやるなら「何を」で分類なんですよね。なぜツリーのほうが「何を」志向なんでしょう……。

たとえばタグを導入して「不具合」や「機能改善」といった要望の種類、「文字化け」等々状況や状態、細かい機能別のタグ付けもあるでしょうし、あと、「実装済みでは?」等々メッセージ的なもの等々も定義出来る。それでもって、「どうしてほしいか」「何が問題か」といったことをサービス横断的にすぐに把握出来るようにしていって欲しいなと思ってます。

タグのほうで「何が問題か」はやるといいということなんですよね。結局アイデア並みの長さを書かないと伝わらない場面がでてくると思うんですけどねえ。問題は繰り返すから日付いりのタグとか……。アイデアにしてくっつけちゃうほうが表記揺れも気にしなくてよいし、いいと思うんです。

すでにタグのついた親アイデアにひっかけて子のタグづけは省略できたらいいとも思うなあ。


しかしyukattiさんが理想とする所はなんとなくわかってきました。お答えありがとうございます。とりあえずタグがつくと思いますし(←ほとんど決めている)、それでずいぶんいろんなことをカバーできそうと言うこともわかってきました。ツリーはそれでも困ったら、というのがありそうな展開でしょうか。

トラックバック - http://beta.g.hatena.ne.jp/sugio/20050809
 | 
日記内検索
カレンダー
<< 2005/08 >>
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31
画像置き場