見出し画像

なぜITエンジニアの文章は、一般の人には「わかりづらい」のか

べとりん

筆者はWebエンジニアとして働きながら、ちまちま文章を書いている。

Webエンジニアの中では、文章を書くのは得意な方だと思う。最近は学術雑誌から原稿の依頼をいただいたりもしたので、一応ギリギリ"お金をもらって文章を書く人"の仲間入りもした ※1。

しかし、"一般の人"向けにわかりやすい文章を書くのはとても苦手だ。
例えば、Webサイトに初めて訪れる人向けの説明文や、新サービスの告知文などは全く書けない。

どうやら、私が"わかりやすい"と感じる文章は、多くの"一般の人"にとっては非常に"わかりづらい"文章であるようなのだ。
この感性の差が理解できず、ずっとこの手の仕事を遠ざけていた。

しかし、友達のWebマーケターに、SNSにおける告知文の考え方を丸々1時間ほどかけてレクチャーしてもらった時に、どうやら、私が今まで文章を書いていた時と、”わかりやすさ”に対する考え方が全く違うことを知り、愕然とした。（なお、上述のtweetはその指導の成果である）

この経験を複数の知り合いに話したところ、どうやら同じように"わかりやすさ"の感性の違いに悩んでいる人が多くいることがわかったので、私が教えてもらったことをここに記す。


"良いデザイン"とは"解釈"が要らないこと

この写真を見てほしい。

このようなエスカレーターサインは、"優しいデザイン"としてよく持ち上げられる例だ。世間一般の理解として、このエスカレーターサインは"優れたデザイン"であると言えよう。

この事例を元に、"エンジニア的なわかりやすさ”と"UIデザイナー的なわかりやすさ”の対比を試みてみよう。


先に述べておくと、私のようなITエンジニアという人種は、このサインを見た瞬間に、気持ち悪いと感じる ※1。

なぜなら、情報の粒度が揃っていないように見えるからだ。片方が「上り」を示す記述である以上、もう片方が「下り」の記述であるべきだ。全く異なるタイプの情報が並列に置かれているように見えて、気持ち悪いと感じるのである。 ※2。

（あなたはそう感じないとしても、一旦そういうものとして読んでほしい）


一方で、このエスカレーターにこれから乗ろうとする人にとっては、このエスカレーターサインは「間違ったエスカレーターに乗ること」を防いでくれる、"優しいデザイン"であると言えるだろう。

仮にサインを上り／下りで記述した場合、サインを解釈し、自分のとるべき行動に変換する必要がある。（例：「左のエスカレーターは上り、右のエスカレーターは下り。私は上に行きたいから、私が乗るべきエスカレーターは左のエスカレーターだな・・・」）。

大した思考負荷ではないものの、これは利用者にとって負荷となる。実際、左右のエスカレーターを乗り間違える人がたまに出ているので、この"ちょっとした思考負荷"が、利用者にとっては大問題なのだ。

"優しいデザイン"の根幹は、このような"解釈"にかかる思考負荷を徹底的に取り払うところにある。

そのためには、エスカレーターを主語にせず、このエスカレーターサインのように、ユーザを主語にして記述することが重要だ。「このエスカレーターは上りです／下りです」と述べるのではなく。「あなたは進んでいいよ」「あなたは止まりなさい」と述べるべきなのだ。

原則として、「私を主語にしていない記述」を自分の利益につなげるためには、解釈、すなわち、他者についての言明を自分についての言明に変換する作業が必要になる。先の例で言えば、「左のエスカレーターは上り、右のエスカレーターは下り。私は上に行きたいから、私が乗るべきエスカレーターは左のエスカレーターだな」という思考がそれに当たる。

「このワクチンを摂取した人の1年後死亡率はn%です」よりも「このワクチンは（あなたの）死亡率を下げます」の方が、多くの人にとってはわかりやすい。もっと言えば、「この手術の（人類一般の）成功率はn%です」より、「あなたはこの手術を受ければ助かります」の方がわかりやすい。

このように、UIデザイナー的な思考における”わかりやすさ”とは、"解釈"の負荷が少ないことであり、つまりできる限り「読む人」の文脈に近づけた状態で記述されていることである。


エンジニアが好むのは、"解釈の足場"があること

「いやいや、私もエンジニアだけど、思考負荷を徹底的に取り払うことが重要であることは同意するよ。だけど、それはそれとして、このエスカレーターサインは気持ち悪いと思う。」という方もいるだろう。この私がそうだ。

私ならば、続けてこのように主張する。

「例えば、あなたがこの写真の右側の下りのエスカレーターに乗っているとしよう。降りる間際になると、突然、目の前に"止まれ"のサインが出てくることになってビックリするだろう。

このサインはこのエスカレーターにこれから乗ろうとする人にとっては正しい案内になっているかもしれないが、降りる人にとっては正しくない案内になっている。つまり、このサインを見る人の立場によって、記述の正しさが変わってしまうんだ。だからこれは良くない記述なんじゃないか」と。

＊

ITエンジニアは、基本的にパターン分けが増えることを嫌い、「ユーザがどんな状況であっても正しい記述」を好む（だって、そうしないとテストケースが増えるし、漏れやミスがあると怒られるから！）。

ITエンジニアは、想定もしていなかった"特殊なケース"の対応を日々迫られる仕事だ。「苗字が5文字以上の時に、Webサイトのデザインが崩れるんですけど」みたいな想定外のケースの相談を毎日のように受けている。

そして、このような考慮漏れのパターンが発生した時、対応するのはエンジニアの仕事だったりする。その対応のために、リリース直後に休日に呼び出されることもある。

だから、"特殊なケース"について想定漏れをしていそうなデザインを見つけると、エンジニアは過去のトラウマを思い出してしまう。特定の状況下でしか成り立たない記述を見かけると、あの憎むべき"想定漏れ"の数々を思い出し、過剰に怖がってしまうのだ ※3。

＊

エンジニアも、「”わかりやすさ”とは思考の負荷が少ないことである」という主張には同意する。しかし、エンジニアの場合、「解釈を全くしなくて済む」ことではなく、むしろ「どんどん自由に解釈できること（それも、できるだけ少ない思考負荷で、楽にたくさんできること）」を"わかりやすい"と感じるのだ。それは、情報の粒度が揃っていることや、情報の並べ方が変えられること、自分の見たい角度に変換して情報を検討することの負担が少ないことなどの要素で構成される。エンジニアは、「文脈が絞られている文章」より、「多様な文脈に耐える記述」を好むし、「情報が絞られている文章」より、「自分の文脈に引き付けて解釈するための"情報"が十分に揃っている文章」を好む。端的に言えば、適切に構造化されている文章を"わかりやすい"と感じる ※4。

昔、デザイナーからWebサイトの修正点についてExcelでまとめたリストを受け取った時、URL列の同じ値のセルが結合されていて愕然とした（ITエンジニアには絶対にやらない行為だ！）。おそらく、デザイナーは重複した情報をまとめることで、読む負荷を減らそうとしたのだろう。（デザイナーの思考における”わかりやすさ”とは思考負荷が少ないことである。）

このケースで言えば、修正点リストに「対応／未対応」の列を付け加えたり、URLではなく他の列でグループ化したり、という行為が防がれていることになる。「読むこと」の負荷が下がっている代わりに、「情報を並び替えること」「新しい情報を付け加えて整理すること」の負荷が上がっているのだ。

＊

エンジニア（に限らず、客観的な記述に正しさを好む人）は、特定の文脈でしか正しくない記述の場合は、その記述が成り立つ文脈について明言されているべきだ、と思っている。

なぜなら、記述が成り立つ文脈について明言されていない情報は、どう"解釈"して自分の人生に生かせばいいかわからないからだ。例えば「トマトを食べると健康に良い」という記述は、どういう条件で成り立つのか全く分からないので、この言明を自分を主語にした記述に変換することができず、"意味不明な主張"になってしまう。


徹底的に読み手の文脈に近づけて書け！

・・・と、自分の思考についての自己弁護を述べてきた。

が、このようなエンジニアの主張が成立するのは、当然、読み手にとっても「解釈の労力をかけるつもりがある」文章に対してだけだ。ITエンジニアであっても、twitterでたまたま流れてきた文章に対して、Excelのフィルタ機能を使ったりはしない。いくら解釈の足場があったところで、人は、興味のない記述に対して、思考負荷がかかる行為をしたりはしないのである。

友達のWebマーケターに、SNSにおける告知文の考え方を丸々1時間ほどかけてレクチャーしてもらったが、読み手にとって「（全く知らない雑誌の）告知文」は、「解釈の労力をかけるつもりがない」文章の最たるものに当たる。発信者は、読み手が頭を使わなくても数秒で読める文章、読み手に興味を持ってもらえる文章を組み立てなければならない ※6。

そのために必要なのは、徹底的に読み手の文脈を特定することだ。エスカレータサインの例で言えば、読み手の立ち位置を「エスカレーターにこれから乗ろうとする人」に限定することだ。このサインは「エスカレーターにこれから乗ろうとする人」に対し、徹底的に頭を使わずに済むメッセージを届けることに集中している。下りのエスカレータに乗っている人にとっては、突然、目の前に"止まれ"のサインが出てきてビックリするだろうが、それが問題になることはほとんどない。なぜなら、エスカレータが下っている以上、降りる以外の選択肢がないからだ。その一方、「エスカレーターにこれから乗ろうとする人」は、左右のどちらのエスカレーターに乗るかを、数秒の間に意思決定しなければならない。それも、友人とのおしゃべりを続けながら。

デザイナーやマーケターという人種は、このような「重要ではないケース」を想定の読み手から除外し、「メッセージを届けるべき人たち」の文脈を明確に絞り込むことによって、「解釈の労力をかけるつもりがない」人々に対しても、大事なメッセージを届けている。

一般に、私のようなエンジニアや学者などの人種は、このような思考が苦手な傾向にあるようだ。読み手が文章に対して「解釈の労力をかけるつもりがない」という状況を想定するのが苦手だからだと思う。普段から文章を読むのに慣れているし、文章の"解釈"が必要なことが読み手にとって負担になるという発想があまりない。

しかし、分野外の多くの人にもメッセージを届けたいと願うならば、そこから脱出する必要があるのだ、と知った。

正直なところ、今まで、UIデザイナー的な思考における”わかりやすさ”を好む人に対して嫌悪感や苦手意識もあったのだが、このたび目的の違いを言語化できたことにより、ある程度は「そういう考え方も認めてやってもいいかな」という気持ちになった。まだ理解しきれていないところも多々ありそうだが、自分もそういう文章が書けるように頑張りたいと思う。


※1 同人誌に寄稿したり、noteに投げ銭をもらったりしたことはあったが、原稿料をもらったのは初めてだった。嬉しかったので「印税等計算書」の通知を大事に取ってある。

※2 もちろんITエンジニア全体の傾向の話であって、全ての人に当てはまるわけではない。この記事は、人間の群ごとに、「わかりやすさ」の考え方の傾向がどう異なるのかを対比することを目的とするので、このくらいのざっくりした議論を許容いただきたい。

※3 左の矢印を「進め」、右のマークを「止まれ」と解釈すれば、情報の粒度は揃う。が、そう理解するのにちょっと時間がかかるし、左の矢印サインの意味するところに解釈の幅が生まれてしまうところが気持ち悪い。情報は常に意味するところが明確であるべきだ。

※4 実際、このデザインが後輩のデザイナーから出てきたら、私は不安を覚え、以下のように語って説得しようとしてしまうだろう。「このデザインは危険だよ。上り／下りのサインにするべきだ。上り／下りは、エスカレーターについての客観的な言明だから、利用者がどんな状況であっても関係なく正しい。いや、もちろん、あなたがデザイナーとしてユーザを主語に据えた記述にしたいのはわかってるよ。（僕もちょっとはデザインを勉強したからさ！）でも、今まさに下りのケースを検討できてなかったみたいに、あなたも誰がどんな状況でこのサインを見るかを全て予測できるわけじゃないでしょ？　いいかい、ユーザを主語にするってのはそれだけ危険なことなんだ。　もう少し慣れるまでは、エスカレーターの方を主語にした方がいいんじゃないかな。」

※5 客観的記述の方が、読み手にとって「行動の自由度」が高いと思っている、という点も指摘しておこう。エンジニアは基本的に「特殊なケース」のことを考える。例えば、「下りのエスカレーターを逆走して登りたい」というニーズを考えてみよう。この人にとって、「進め／止まれ」の記述は完全な誤りだ。他にも「下りのエスカレータだけを掃除するように指示された担当者」とか、「エスカレーターのスイッチを入れ替えて動きが逆になったケース」とか色々考えなければならない特殊ケースがある。このようなことを日々考えていると、「読む人」の文脈に絞った記述というのは、その文脈の外側にいる「特殊ケースの人」の存在を弾いていることになる。私のような根暗な人間は、望まずして一般的な文脈の外側にはみ出してしまった経験が多いので、そういう記述を見るとコノヤロウと思っている。


※6 私は告知ツイートをしようとすると「面白さを匂わせて読み手に想像させよう」としがちなのだが、友人のマーケターからはこれらの表現を徹底的に指摘され、「この記事の面白い主張を1行で端的に述べよ」と指導された。

例：

「心理士の賃金は安すぎる」という話題がTwitterでは定期的にバズりますが、これが事実なのかを最新の統計データを用いて検証しています。

友人のコメント「検証した結果として、どんな面白いことがわかったのかを書いた方がいい。検証したというだけでは面白さを読み取ることができない」

心理士は低賃金と言われますが、非常勤率や女性比を考慮すると、違った面が見えてきます

友人のコメント「"違った面"って何？　そこを書かないと読み手に面白さは伝わらない」

心理士は低賃金と言われますが、データを見ていくと、背景にある社会構造が見えてきます

友人のコメント「"背景にある社会構造"って何？　そこを書かないと（略」


この記事が気に入ったらサポートをしてみませんか？