技術系イベントにおけるアンチハラスメントポリシーの効果について

技術に関するカンファレンス等のイベントで使われるアンチハラスメントポリシーとは、技術系イベントなどでハラスメントに反対するというポリシーを明示するしくみで、最近では様々なカンファレンスで同様のポリシーが適用されています。私が運営に関わっているRubyKaigiというイベントもその一つです(ちなみにRubyKaigiでは2020年1月14日まで発表者募集中で、また現在スポンサーも募集中です)し、同じく運営に関わっている技術書典というイベントでも導入されています(ちなみに技術書典8サークル当選者の入金は12/22(日)本日締め切りなので、まだの方は今すぐ対応願います。そして技術書典8でもスポンサーを募集中です)。

とはいえ、アンチハラスメントポリシーは必ずしも正しく理解されているわけではないかもしれません。 まあ、正しいかどうかを私が判断するのは適切ではないかもしれませんが、私から見るとこれはちょっと理解されていないのでは、という発言も見かけます。

そのため、アンチハラスメントポリシーを実際に適用しているイベントの関係者として、私のアンチハラスメントポリシーの理解の一端を書いておきます。

アンチハラスメントポリシーを掲げることによって得られる効果

「アンチハラスメントポリシーを掲げれば参加者はハラスメントしないようになる(はず)」、と思われる方もいるかもしれませんが、それは正直誤解というか、過信と言ってよいでしょう。 なぜなら、ハラスメントは本人が意識していなくても行ってしまうものであり、そして意識していないのであればそれを封じるポリシーが提示されていても、言動が変わることが期待できないためです。

それでは、なぜ多くのイベントでアンチハラスメントポリシーが掲げられるのでしょうか。それには様々な理由があります。

ハラスメント遭遇時の報告先を明示できる

ハラスメントに遭遇した者が、ハラスメントがあったので何とかしたい、という場合、まず報告先をどこ・誰にすればよいかを考えるはずです。 ところが、ポリシーがない場合、どこに報告するのが正しいのかは自明ではありません。

とりあえずスタッフに言えばいいのかと思いつつ、そもそも誰がスタッフなのかも分からない場合もあります(イベントでは、スタッフでもないのにスタッフのように仕切ろうとされる参加者の方もたまにいらっしゃいます)。 そもそもハラスメントの報告は、あまり気軽に行えるものではなく、良く分からない人に伝えるのに不安な場合もあるでしょう。

アンチハラスメントポリシーには、多くの場合ハラスメントの報告先が明示されます。スタッフに伝える場合にも、スタッフの特徴(名札、Tシャツ、腕章等)が明記されます。 それによって、正しい報告先がわかります。

さらに、スタッフと思われる人がハラスメント的な言動をしていた、というケースもありえます。その場合、とりあえず問い合わせ先に投げるとしても、普通の問い合わせ先に投げるとその人にも直接伝わるのでは(そして報告者が特定されてしまうのでは)、という恐れがあります。

アンチハラスメントポリシーに特別の連絡先を用意する場合、スタッフの中でも少数の人のみに連絡し、報告者の秘密を守ろうとすることが可能です(それが期待されます)。 さらに慎重な場合には、匿名の報告を受け付ける窓口が別途用意されている場合もあります。

このようにして、ハラスメントの報告先を示すことで、問題があった場合、あるいは問題かどうか判断つかないけれど報告したい場合に、その適切な報告先を参加者全員に伝えることができます。

「ハラスメントに遭遇した」という「報告」を積極的に求めていることを明示できる

先ほどの項目以前の大前提として、そもそもハラスメントを受けた、あるいはハラスメントを見かけたことを通知することが適切な行為として認められており、そのことを参加者とも共有する必要があります。

ハラスメントの問題をより深刻にする、二次的被害をもたらすものとして、「ハラスメントを軽視する」ということがあります。 具体的に言うと、ハラスメントを受けたと報告があった時に、報告された側の人が「そんなの大したことじゃないですよ」とか「それくらいのことならよくあるし、気にすることじゃないのでは」といったような言葉を返したり、そう思わせるような言動をすることがあります。これがハラスメントの軽視です。
(なぜ軽視なのか念の為説明しておくと、ハラスメントが大したことか、気にすることかどうかを判断するのは報告を受けた者ではなく、ハラスメントを受けたその人であるべきだからです。もちろん、よくあることかどうかもハラスメントを受けた人にとってはどうでもいいことです。「私が」「今」「ここで」ハラスメントを受けたことが問題だからです。さらに念の為説明すると、ハラスメントの問題やその報告を重要視することと、そのハラスメントをはたらいた人に対して重い処分を下すかどうかは、直接関係しているわけではありませんし、処分を約束するものでもありません。)

ハラスメントの報告は、基本的にハッピーなものではありません。それは報告を受ける者にとってもそうですが、報告する人にとっても同様です。 何も好き好んで報告したいのではなく、報告することが今後の改善につながると期待して報告する場合が多いはずです。誰も報告しなければ、自浄作用も期待できないからです。

しかし、それをためらわさせる要素があると、報告も期待できません。報告はあくまで報告者の「善意」によるものでしかないためです。

また、報告者自身ですら自分の受けたハラスメントを軽視している場合もあります。残念ながら当たり前のように日々ハラスメント的な言動が行われている場も世の中にはあるようで、そのような経験を重ねた場合、主催者としては重視しているような言動ですら報告を遠慮してしまうかもしれません。しかも、ハラスメントの対応にはそれなりにコストがかかることは事実です。そのような背景を推測してしまうことにより、ハラスメントに遭遇しても、報告をためらってしまう危険性があります。これはハラスメントを防ぎたい主催者の意に反することです。

アンチハラスメントポリシーを提示することにより、その報告者の行為を無碍にせず、主催者としてはコストがかかろうが適切に対処したいと考えていることを明示することができます。

全スタッフにハラスメントを防ぐための権限を与えることができる

アンチハラスメントポリシーは、一般の参加者だけではなく、スタッフへのメッセージにもなります。

多くのイベントでは、スタッフ経験も豊富で、長い時間をかけて深く関わっているスタッフだけではなく、当日のみイベントのお手伝いを行うために参加するスタッフの方もいます。 とはいえ、参加者からみたら当日のみのスタッフもスタッフです。

イベントの発表中にハラスメントと思われる言動が含まれることはあります(実際にありました)。 そのような発表は、場合によっては即座に中止したり、そこまでいかなくても発表中・発表直後にお詫びをお伝えする必要もあるかもしれません。 これは、控えめに言って、発表の場を壊してしまうことになりかねません。

運営チームの代表者であればそのような強い措置の判断もできるはずですが、そうではないスタッフしかその場にいない場合、そんなことをやっていいのか…と躊躇ってしまう可能性は高いです。 そして代表者に情報が伝わり、その場に来たときにはすでに発表も終わっているかもしれません。

そのような状況でも、アンチハラスメントポリシーがあれば発表も中断させることも可能にする、とても強い権限をその場にいるスタッフに与えることの後ろ盾になります。 少なくとも、何もないよりは判断の助けになるでしょう。 もちろん、そのことも含めて、スタッフにはその権限の使用についてしっかりと情報共有し、理解を徹底する必要はありますし、相当頑張っても実際に現場で振る舞えるかどうかは未知数ではあります。そこは本当に難しいところなのですが、上手く運用したいところです。

まとめ

アンチハラスメントポリシーは、掲げることでハラスメントを排除できる、便利な御札ではありません。 このポリシーは、ハラスメントをなくそう、少なくとも減らしたい・見逃さない、という主催者側の意志を伝え、ハラスメントを受けるかもしれないなら参加したくない、という方にも参加してもらい、一緒にハラスメントをなくしていくためのツールの一つです。

もっとも、イベントの主催は簡単なことではありません。アンチハラスメントポリシーがあろうがなかろうが、主催者の苦労は少なからずあります。 正直ハラスメント対応まで気が回らない、想定できない、現実的にコストが割けない、などということもあるかと思います。 ハラスメント対応ができないのであればあらゆる規模のイベントを開催するべきではない、というのも現状では非現実的もしれません(将来的には違ってくるかもしれません)。

実際、比較的小さなコミュニティのイベントでは、ポリシーを明示せずともハラスメントを未然に防いだり、ハラスメントがあってもその対応をうまくハンドリングできることもあります。 しかし、様々な背景を持った、多くの参加者が見込まれるイベントでは、最低限の振る舞いのルールも共有されていない可能性が高いです。

そこで、困難を引き受けてでも、アンチハラスメントポリシーを掲げて、ハラスメントの防止に努めることを宣言し実施することには大きな意義・効果があります。 今後とも、より良いイベントが開催され、技術コミュニティが活発化されることを期待しつつ、イベントを開催される方・イベントに参加される方を応援したいと思っています。頑張っていきましょう。

蛇足

なお、ここに書いたことは、運営視点からのプラクティカルな効果についてであり、ポリシーを提示する本当の理由は「参加者の技術的な興味・関心と参加者自身を大切にし尊重するため」「人権を損なわないため」です。が、それについて書き出すとさらに長い話になるのでここでは省略しました。

開発者向けopenBD関連リンク集

公式

openBD | 書誌情報・書影を自由に

API仕様書 OpenBD 書誌APIデータ仕様 (v1)

2017/01/23 セミナー資料

GitHub Organization

github.com

https://github.com/OpenBD は別物なのに注意

ライブラリ・ツール・アプリ in GitHub

Go

github.com openBD APIライブラリ (Go)

github.com ISBNで書誌情報を取得するツール (Go)

JavaScript

github.com Chrome拡張

github.com 書誌情報表示サンプル (JavaScript)

github.com 新刊情報アプリ (JavaScript)

openBDの全データを整形しつつ単一ファイルにダウンロード · GitHub 全件取得スクリプト (JavaScript)

Ruby

Crawl all data using openBD API · GitHub 全件取得ダウンローダ (Ruby(Rails))

github.com openBD APIライブラリ (Ruby)

github.com openBD APIライブラリ (Ruby)

github.com openBDの登録データ取得 (Ruby)

Python

github.com 全件取得用ダウンローダ (Python)

PHP

github.com ISBNから書誌情報を表示するサンプル (PHP)

github.com 出版社記号を使って特定出版社の書籍データを抽出するサンプル (PHP)

hontoの書籍ページにISBNでリンクする

hontoの書籍ページは独自IDが振られているので、直接リンクできない。

例えば以下のようなURLになっている。

https://honto.jp/netstore/pd-book_28169493.html

これとは別に、ISBNを指定する方法がある。

http://honto.jp/redirect.html?bookno=(ISBN)という形だが、ここでのISBNは13桁ではなく、末尾のチェックデジットを落とした12桁になるのがポイント。

http://honto.jp/redirect.html?bookno= 9784822239176 ではダメ。

http://honto.jp/redirect.html?bookno= 978482223917 だとうまくいく(冒頭のURLにリダイレクトされる)。

もうちょっと何とかならなかったのか…という仕様としか言いようがない。

textlint-rule-preset-ja-technical-writingが厳しすぎるのではないか問題

というのを某所で見かけたので。

github.com

「このルールをエラーなしで通る文章の集合」よりも「特に問題なく読める技術文書」の方がだいぶ大きそうなので、一般的な技術文書のlintの雛形として導入するのは過検出が多発してたいへんとのこと。もうちょっとゆるいサブセットを作るべき?

一般的には外したいルールとしては、

  • 1文の長さは90文字以下とする
  • カンマは1文中に3つまで
  • 読点は1文中に3つまで
  • 連続できる最大の漢字長は5文字まで
  • 同じ助詞を連続して使用しない

辺りとかでしょうか。

あと、例えば『「ですます調」、「である調」を統一します』辺りは一般的には導入したいけど、引用が入るとどうにもならなくなるので、その辺りは簡単に対応できるようになると幸せになれそうです。つまり引用文は例外にするとか。

2017年のmd2reviewの開発目標

github.com

今年はとりあえず2.0をリリースしたいです。2.0での大きな変更点は2つです。

  1. Kramdownのサポート
  2. 1ファイルのFrontmatterつきMarkdownをRe:VIEWプロジェクトに変換する機能を追加

1については、Redcarpetよりは手軽にMarkdownの拡張に対応できるのでは…という期待があります。が、全てのオプションが同じように導入できないかもしれません。それもあってメジャーバージョンをあげます。 Kramdownに完全移行するか、Redcarpetとどちらを導入するかを設定で決められるようにするかは未定です。

2についてですが、JekyllやMiddlemanが対応しているやつですね。

jekyllrb.com

Middleman: Frontmatter

MarkdownからRe:VIEWへの変換で問題になるのは「Re:VIEW側のconfig.ymlをどう生成するか」なのですが、Frontmatterで対応できればこれでいけそうな気がします。

実際にはちょっとFrontmatterのparserを書きかけた程度なのですが、まずはエンジンの方を解決した方がよさそう…ということで後回しになっています。

個人のOSS開発は作者個人のメリットを最優先させるのがよさそう

chezou.hatenablog.com

読みました。私は英語でばんばんissueが飛んでくるようなプロダクトを作ってるわけではないので、実感としてはわからないところもあるのですが。

歌を作るたびに どこかで傷つく人がいる
誰かをほめることは 誰かを敵に回すこと
片桐麻美『つまらないものですが』より)

大原則として個人プロジェクトであれば、自分にとってのメリットを最優先するべきだと思います。 作ってる人が幸せになれないプロダクトは使ってる人も幸せにならない、少なくとも一時的には幸せであってもその幸せは持続可能な形にならないのでは、という気持ちがあります。

自身の意に反して、人生を削ってまで生み出す価値のあるプロダクトなんてこの世にありはしない、というのが私の信念なので。事実でも真実でもないかもしれませんが。

その前提をおいた上で、でも、プロダクトを世の中に送り出してしまうということは、それを使ったり使わなかったりする他の人々を巻き込んで不幸にしてしまう可能性があります。それはもちろん知ったことではないと言うか、そこは責任の範疇とするべきではないと思うべきだと思っているのですが、そう割り切れないことはあって。そういう時はつらいですよね。

よくある作戦としては、手伝ってくれるメンテナを見つけて(趣味的なものではあっても)複数人体制にしてみる等がありますが、そうすると今度は開発チームをメンテナンスするコストが発生したりするので、根本的には解決してないような疑念もあります。もうちょっと強行的な策としては、issueを閉じて質問についてはStack Overflow等に振ることにして、pull requestのみを受け付ける作戦もあるそうですが、そうすると変なPRが飛んでくるのは容易に想像できますし。うーむ。困ったものですね。

また、chezouさんの認識とは異なるかもしれませんが、多くの人に使われてすごいissueやPRがばんばん飛んでくるのをびしばしさばくのが理想的なOSSプロダクト開発であって、そうしないと承認要求を満たせない、みたいに思われがちなのかもしれません。それはそれで理想形の一つではありますが、そういう形にみんなが固執してしまうようになるのはいろんな意味で健全ではないんじゃないかなと思うわけです。別にユーザを減らすべきとは思いませんが、プロダクトやその開発プロセスにはさまざまな理想形があるべきで、どんな形を選ぶのかは作者次第であって、根本的には作者がうれしいプロダクト開発の形を選ぶことがそのプロダクトの理想形であるべきだと信じています。

……なんかいろいろ書いたけどタイトル以上の内容がなさそう。でもやっぱりその一言に尽きるし、それでもいろいろ言ってくる人への回答としては「言い出しっぺの法則ってご存知ですか?」に尽きるんですよね……。

他人の人生を巻き込んで 私は歌を作り続ける
本当につまらないわたしだけど
いま 好きな人がいます
(同)