この日記はMozillaのプロダクトへの貢献者としての私の成果を中心に、気になったバグやWeb界隈の話題について書いていますが、 断り書きがある場合を除き、いかなる団体のオフィシャルな見解ではありません。あくまでも個人的なものです。 Mozilla Foundation、Mozilla Corporation、及び関連企業の公式情報ではないことに注意してください。

現在、XHTML 1.0 (もどき)から、HTML5なコンテンツに修正中です。古い日記は修正が完了していませんので表示が崩れます。 順次、修正していく予定ですのでしばらくお待ちください。

もずはっく日記(2008年6月)

2008年6月13日

よりユーザ寄りの開発コミュニティを立ち上げた場合の問題は?
初回投稿日時: 2008年06月13日06時00分59秒
カテゴリ: Mozilla Core 雑談
SNS: (list)

よりユーザ寄りの開発コミュニティ、正確に言うなら、Bugzilla-jpや本家Bugzillaのデータベースを充実させるためのフィードバックをより簡単にユーザがポストできる、窓口となるコミュニティはどうあるべきなのか、どういう問題があるのかを、私が過去の経験から思いつく限りのものを列挙してみます。

システムがまずは必要

まずはベースとなるシステムが必要です。最低限必要と思われる機能は、まずはアカウントの作成機能です。これを煩わしい、と思うユーザのフィードバックはノイズとなって開発関係者の労働力を無駄に削ぐことになる可能性が非常に高いのでデメリットは無いと思います。アカウントにはメールアドレスを必須としておき、メールアドレスで最初のフィードバックに対するスタッフからの確認や問い合わせが通知可能である必要があります。

各フィードバックの内容は、ステータスを管理できなくてはいけないでしょう。例えば、フィードバック内容が未確認、フィードバック内容を確認済、Bugzilla-jpに報告済み、Bugzilla-orgに報告済み、Trunkでは修正済み、リリース版で修正済み、フィードバック内容はバグではなかった、等々が必要でしょう。

また、スクリーンショット等が必要になることも多いでしょうから、ファイルの添付機能も必要でしょう。

後は念のためにセキュリティフラグも用意しておいた方が良いと思います。

こういったシステムを作成、管理、メンテナンスしていくことが必要です。サーバ資源はもじら組等と交渉すれば使えると思います。

バグの再現確認は手間がかかる

バグの再現確認は現在のbugzillaよりも手間がかかるでしょう。Bugzillaではリリース版のBranch限定のバグを取り扱う特殊な場合を除き、基本的に全ての報告者が最新のTrunkビルドを利用していることが前提となります。

ですが、ユーザにTrunkを使わせるのは酷ですので、全てスタッフ側で検証する必要があると思います。その場合、報告されたバージョン、最新のリリース済みバージョン、そしてTrunkでの検証が必要でしょう。

重要度等の主観に関わる項目は作らない

エンドユーザと、開発者では考え方等がかなり違います。また、エンドユーザ同士でも、そのバグで実害を被っているか、否かで意見が変わってくるでしょう。Bugzillaはバグの担当者や、コンポーネントのオーナーにその設定権限があるため、基本的にもめることはありませんが、ユーザ主体のコミュニティではそれはもめ事の種となってしまう可能性があります。作らない方が無難というものでしょう。

要望は受け付けない

要望というものは人によって異常に温度差があるものです。

一部の人にはあったら便利なものでも、大多数のユーザにとって不要なものであったり、多数のユーザに混乱を与えかねないものは拡張機能にすべきものです。

また、より最悪な要望は技術的に困難すぎるものです。あれば理想的でも現実的ではない案であれば何の意味もありません。

ですが、要望を出した人というのは、真剣にその機能が実装されることを望んでいることに注意してください。要望を出す人は提案する内容がすばらしいと考えてフィードバックを返すわけですから、その提案を蹴られると不快に感じ、中には炎上する人も出てきます。

不毛な争いが起きないように要望は内容に関わらず一律受け付けない、という方針は必要でしょう。

開発経験者以外の報告は意味不明なことが多い

開発未経験な人ほど、その報告内容は支離滅裂だったり、情報が不十分だったりすることが多いです。ですが、これは自然なことです。開発経験者がなぜ有用な報告を行いやすいかというと、開発者の求めている情報の察しがつきやすいからです。

この差はどうしようもないので、必要となる情報のガイドラインは必要でしょう。しかし、ガイドラインを作ってもおそらく報告者は読んでくれません。そのため、Bugzillaで採用しているような、ダイアログ形式の報告フォームを作らなくてはいけないでしょう。つまり、スタッフが欲しくなる情報を入力してもらえるよう、うまく誘導できるようにすべきです。

コミュニティ内での上下関係ははっきりとさせましょう

コミュニティリーダをトップに据え、システム管理者や、各種貢献者と、その貢献量をはっきりとさせた方が良いかもしれません。相手が一見さんであればあるほど、対応してくれている人がどのようなレベルの人なのか気になると思われます。また、なにか決断しなければいけなくなった時に上下関係がはっきりしているのであれば、その決断を誰が下すべきで、誰が従うべきかがはっきりします。意志決定プロセスを尊重できない人はその組織内での活動には不的確な人と言えます。

また、貢献者の評価をなんらかの形で明確に集計するのであれば、昇格だけではなく、ブランク期間に応じた降格も必要でしょう。貢献を途中で中断した人が、現役の貢献者よりも発言権があると問題だからです。

たぶん、まだまだ出てくると思いますが、今考えついたのはこのぐらいです。これだけでも大変なように感じるかもしれません。それはもちろん間違っていません。コミュニティ運営というのはとてつもなく大変ですし、ボランティアだからと言って、中途半端な覚悟で出来るものではありません。

ですが、これらを全て一人で処理する必要はないのです。良いリーダが名乗りを上げてくれたら、スタッフは自然と集まってくるでしょう。もし、実際にやってみたい、という方が居たら、是非私にメールででも相談してみてください。

関連するかもしれないエントリ

関連するかもしれないエントリを発見できませんでしたが、無いとは限りません。

このエントリへのリンク元