What If We Work Together? Fostering Reflections on Designer Inclusion in Open Source Software Through Speculative Design
本論文は、オープンソースソフトウェアの実践者に対して批判的省察を促すため、2 つの架空の社会を用いたスペキュラティブ・デザインを採用し、コミュニティの開発者中心の思考様式に対処するとともに、デザイナーにとってより包括的な環境を醸成することを目的としている。
原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。 免責事項の全文を読む
オープンソースソフトウェア（OSS）を、大規模で賑やかな建設現場だと想像してみてください。この現場は長年にわたり、建物の構造を堅固にし、配管を機能させ、電気を通すことに夢中になっているエンジニアや建築家たちによって完全に運営されてきました。彼らはその点において卓越しています。しかし、彼らがあまりにも建物の「内臓」部分に集中しているあまり、壁を塗ることを忘れ、快適なドアノブを取り付けることを怠り、部屋が容易に移動できるようであることを確認することを怠ることがよくあります。
その結果、この建物は驚くほど強力ですが、もしあなたがエンジニアでなければ、中を歩くことは暗闇で迷路を navigating しようとするような感覚に陥ります。
この論文は問いかけます：もし、インテリアデザイナーを建設現場に招いたらどうなるでしょうか？
研究者たちは、デザイナーは助けたいと望んでいるが、歓迎されていないと感じ、ツールに混乱し、自分の仕事が「本物の」仕事ではないとよく言われていることを発見しました。これを解決するために、研究者たちは単に規則のリストを作成するのではなく、「スペキュラティブ・デザイン」と呼ばれる手法を用いました。これは、建設チームに二つの全く異なる未来を示す二つの「もしも？」タイムマシンを構築するようなもので、彼らを目覚めさせ、今日の働き方について異なる視点で考えさせることを目指しています。
二つの「もしも？」の世界
研究者たちは、現在の現実を映し出す鏡として、二つの架空の社会を創造しました。
1. ハイブ（Husia）：究極のチーム・ハドル
誰もが一つの巨大で幸せな家族の一部である世界を想像してください。「私の」デザインや「あなたの」コードといったものはありません。すべてがグループに属しています。
- 仕組み： 新しいデザイナーが到着すると、フレンドリーなロボットガイド（「中央ボード」）が即座に彼らに何をすべきかを正確に示し、彼らが得意とするタスクとマッチングさせます。彼らは壁が彼らに語りかけ、ユーザーのニーズを思い出させるハイテクな部屋で働きます。
- 教訓： この世界では、誰も誰がクレジットを得るかを争いません。焦点は完全にコミュニティを支援することに置かれています。
- 現実のチェック： 研究者たちは、この「クレジットを与える」ことが重要である一方で、現在のシステムはデザイナーを不可視化させていることを示すためにこれを用いました。しかし、彼らはまた、クレジットを完全に排除すれば、人々は「なぜそんなに頑張る必要があるのか？」と疑問に思うかもしれないことも示しました。
2. レピュテーション・シティ（Reetar）：ハイ・ステークスのゲーム
次に、あなたの社会的地位が「評判ポイント」という通貨である世界を想像してください。良い仕事をするだけでポイントを獲得し、ミスをすればポイントを失います。
- 仕組み： この世界では、製品が醜ければポイントを失うため、デザイナーは不可欠です。開発者とデザイナーは密接に協力しなければなりません。そうでなければ、彼らの「スコア」が低下するからです。このシステムは彼らに互いに話すことを強制します。
- 教訓： この世界は、デザイナーが現在過小評価されていることを浮き彫りにします。この未来では、彼らの仕事が生存の鍵となります。
- 現実のチェック： 研究者たちは、このシステムが敬意を強制する一方で、人々が互いを支援することよりも「ポイントを獲得すること」に集中するかもしれない、熾烈な環境も生み出していることを示しました。
これらの世界を見せたときに何が起こったか？
研究者たちは、実際にオープンソースプロジェクトで働いている12人（デザイナー7名、開発者5名）を招いて、これらの二つの世界を訪れさせました。彼らは単に「これは好きですか？」と尋ねるのではなく、「これが現在の仕事についてあなたにどのような感情を抱かせますか？」と尋ねました。
その結果、全員にとって電球が点くような瞬間が訪れました。彼らが気づいたことは以下の通りです。
- 「オープン」の神話： 誰もがオープンソースはすでに誰にでも開かれていると思っていた。しかし、これらの世界を見ることで、「待てよ、コードはオープンだが、ツールやプロセスはデザイナーを遠ざける技術用語の壁の背後に閉ざされている」と気づいた。
- 誤解： 開発者は、デザイナーが単に「ものを美しくする」だけだとよく考えていることに気づいた。シナリオは、デザインがコーディングと同様に問題解決についてのものであることを示した。
- クレジットの危機： デザイナーは感謝されていないと感じていることに気づき、開発者は誰が何をしたかを追跡する方法がない限り、誰が「ありがとう」に値するかを知ることは難しいことに気づいた。
教訓：建設現場をどう改善するか
これらの極端な未来を見ることで、参加者は現在の「建設現場」をデザイナーにとってより良くするための実践的なアイデアを提案しました。
- より良い歓迎マットを構築する： ハイブの「中央ボード」のように、プロジェクトはデザイナーがコードの中で迷子にならないよう、明確でシンプルなガイドを提供する必要がある。
- デザイナーにテーブルの席を与える： 建物が完成してからドアを直すようデザイナーに頼むのではなく、最初から彼らが青写真の計画に協力できるようにする。
- 「デザイン GitHub」を作成する： 開発者にはコードの変更を追跡するシステムがある。デザイナーが作品を失うことなく、自分の図面を保存、共有、更新できる同様のシステムが必要である。
- 「ありがとう」と大声で言う： デザイナーがユーザーインターフェースを修正したとき、プロジェクトはバグを修正した開発者に対して行うように、それを大声で宣言すべきである。
結論
この論文は、単に人々に「もっと優しく」「もっと頑張れ」と言うだけではだめだと主張している。文化を変えなければならない。これらの想像力あふれる「もしも？」の物語を用いることで、研究者たちはオープンソースコミュニティが自分自身の盲点を認識するのを助けた。彼らは、誰もが使えるソフトウェアを構築するためには、デザインを後回しにするのをやめ、チームの核心的な部分として扱うことを始めなければならないと気づいた。
それは、家が屋根と四つの壁だけではないことに気づくようなものだ。それは家である。そして、それを家にするためには、最初のレンガからエンジニアとデザイナーが共に働く必要がある。
自分の分野の論文に埋もれていませんか？
研究キーワードに一致する最新の論文のダイジェストを毎日受け取りましょう——技術要約付き、あなたの言語で。