失敗談を集めるとき、匿名はどこまで守れるか：制作のつまずきの扱い方

失敗談が役に立つ条件

失敗談は、書き方しだいで反省文にも手がかりにもなります。手がかりになる失敗談には、次の三つがそろっています。

• 何をしようとしていたかが分かります。目的が分からないと、別の人は自分の場合に置き換えられません。
• 止まった場所が具体的です。「うまくいかなかった」ではなく、「画面が真っ白のままだった」「音が出なかった」のように、現象で書かれています。
• 誰かを責めていません。「説明が悪い」「ツールのせい」と書くと、読む側は防御的になります。

アソバースの投稿を例にすると、確認済みの仕様の範囲で、つまずきの型を想像できます。投稿には、直下の index.html が入口になること、素材は相対パスで指定すること、サーバー用コードやサービスワーカーは対象外であることなどの条件があります。たとえば「ZIPを作ったときにフォルダごと固めてしまい、index.html が直下になかった」という場面を考えてみます。これは仮定の例ですが、条件を知らなければ起こりうる型の話です。この型の失敗談が一件あれば、同じ手順をなぞる人が事前に確認できます。

失敗談の価値は、書いた人の名前ではなく、型と手順にあります。ここが、匿名で集めても価値が落ちにくい理由です。

匿名にするとき何を消すか

匿名化は、名前を消す作業だけではありません。回答から「誰か」を推測できる手がかりを、種類ごとに洗い出します。

• 名前・ハンドル、そのままだと：直接特定される、書き換えの例：削除し、「ある制作者」とする
• 作品名、そのままだと：作品を開けば本人にたどり着く、書き換えの例：ジャンルだけにする（例：パズル系）
• 日付・時期、そのままだと：「先週の締切の日」などで絞られる、書き換えの例：「公開前」「公開直後」のような段階に直す
• 画面の画像、そのままだと：タイトル文字や絵柄で分かる、書き換えの例：載せず、現象を文章で書く
• 口癖・文体、そのままだと：親しい人には誰か分かる、書き換えの例：要点だけを編集者が短く書き直す
• 周辺の事情、そのままだと：「部活の発表前で」などで集団が絞られる、書き換えの例：事情を削るか、一般的な言い方にする

とくに忘れやすいのが、作品名と画像です。アソバースの作品は、タイトルの文字組みやカバーの雰囲気で見分けがつきます。画像を載せるだけで、匿名の意味がなくなることがあります。失敗談は画像なしで、「どこで、何が起きたか」を文章で書くのが基本です。

書き換えるときは、意味を変えないことが条件です。事実を足したり、複数の話を混ぜて一つの話にしたりすると、読む人にとっては実話ではなくなります。要約や言い換えにとどめ、混ぜるなら「よく聞く型」として、型の説明に切り替えます。

集め方の設計

募集から公開までを、手順にして考えます。

1. 問いを一つに絞ります。 「制作で一番時間を使った原因は何でしたか」のように、答えが短く書ける問いにします。自由記述だけだと、愚痴や自己紹介が混ざりやすくなります。
2. 書式を渡します。 次の五項目で十分です。

• 何を作ろうとしていたか
• どこで止まったか
• そのときどう判断したか
• 何を変えて先へ進んだか
• 次に変えること

1. 同意の段階を選ばせます。 次の三つを用意し、回答ごとに選んでもらいます。

• 件数の集計にだけ使う
• 匿名で文章を引用してよい
• 名前を添えて紹介してよい

1. 撤回の方法と限界を先に伝えます。 「連絡をもらえれば取り下げます」と伝えるだけでなく、すでに印刷した資料や、他の人が写し取った内容までは戻せないことも、募集の時点で書いておきます。
2. 原本と公開用を分けます。 回答の原本は、集めた人だけが見られる場所に置きます。公開用は書き換えた別の文章にします。原本には、消す時期をあらかじめ決めておきます。
3. 公開前に回答者へ見せます。 書き換えた文章を本人に確認してもらい、「これなら自分と分からない」と言ってもらえてから出します。

募集の入口については、アソバースにフレンドやチャットの機能はなく、失敗談専用の投稿窓口についても確認済みの案内はありません。そのため、窓口の有無は現在の案内で確認する必要があります。当面は、自分の集まりのなかで回答用の紙やフォームを用意する形が現実的です。

なお、アソバースのレビューは作品への評価を書く場所です。他人の作品を名指しして失敗を書く用途には向きません。自分の制作の失敗は、自分のメモや集まりの場で扱うのが安全です。

匿名でも特定されてしまう場面

名前を消したのに分かってしまう場面は、いくつかの型に分けられます。

人数が少ない場合。 十人ほどの集まりで「先月ZIPでつまずいた人」と書けば、誰のことか分かってしまいます。人数が少ないほど、時期や作業内容の情報は削る必要があります。回答者が少ないときは、公開をやめて、口頭で型だけ共有する方法もあります。

一人だけ特殊な状況の場合。 「一人で作っていて、デザイナーがいなくて」のように、環境を細かく書くと、それだけで絞られます。つまずきの原因に関係のない事情は削ります。

書き手の語りの癖。 文章の癖は、親しい人にはすぐ分かります。引用する場合も、要点だけを短く言い直します。

作者が作品を公開している場合。 作品を公開している人の失敗談は、作品を見れば裏づけが取れてしまいます。「公開前の手順でつまずいた」という話でも、作品とセットで出ると本人が分かります。作品名と失敗談を結びつけて出すのは、本人が名前つきでの紹介に同意した場合だけにします。

個人情報の混入。 回答に、メールアドレスや本名、学校名が書かれていることがあります。アソバースの仕組みでも、ログイン用のメールアドレスは公開されません。集める側も同じ姿勢で、公開用の文章に連絡先を含めないようにします。個人情報の扱いに不安があるときは、学校や団体の担当者、専門家に確認してください。

集まった失敗談の読み方

集まった回答は、まず原因別に仕分けます。ここでは次のような分類が使えます。

• 入口の問題：ファイルの置き場所、パスの指定、容量など、公開前の準備に関するもの
• 動作の問題：操作が反応しない、音が鳴らない、画面の大きさが合わない、など
• 設計の問題：遊ぶ人が何をすればよいか分からなかった、難しすぎた、など
• 進め方の問題：作りすぎて公開が遅れた、確認の時間がなかった、など

仕分けたら、件数を数えます。ただし、読み方には注意が必要です。

• 集めた件数が少ないときは、「多い」「少ない」と言わず、「この集まりでは〜という回答がありました」と範囲を限定して書きます。
• 件数を書くときは、自分で実際に集めた数だけを使います。他の集まりや世の中全体の傾向のように言い換えません。
• 同じ型が複数あっても、原因が同じとは限りません。現象は似ていても、直し方が違うことがあります。

読み終えたら、一つの失敗談から「次に確認すること」を一行ずつ取り出します。たとえば入口の問題なら、「公開前に、直下の index.html、相対パス、容量の三点を見る」といったチェックの一行です。失敗談そのものより、この一行が、あとから作る人の役に立ちます。

アソバースでは、投稿は入力、表示の確認、公開の三段階で、下書き保存もできます。失敗談から作ったチェックの一行は、公開前の表示の確認の段階に当てはめる使い方があります。

次の行動

自分の集まりで失敗談を集めるなら、まず五項目の書式と三段階の同意を、紙一枚に書き出してみてください。次に、募集前に「撤回の方法と、戻せない範囲」を一文で書き添えます。投稿の条件や機能については、現在の案内で最新の内容を確認してから、集めた型に当てはめてください。