はじめに
ある日。
私は、支給された原稿をコピペでHTMLに流し込みました。
ブラウザで表示されたページを支給原稿と照らし合わせながら一通り読み、原稿・表示共に問題ないことを確認、テストアップを提出しました。
すると、プロジェクトメンバーからお戻しを頂きました。
「『CO2』は『CO2』でお願いします」
あぁ、なるほど、確かにCO2の『2』は下付き文字で記述するのが通例だよな。
数カ所で『CO2』の記述があり、私はすぐに修正し提出し直しました。
その後、プロジェクトメンバーからお叱りの一言。
「こういう当たり前のことを指摘されるのが一番ダメ」
社会人はこういうときに原因と対策を考えると聞きます。
ということで、
- なぜ“当たり前のこと”に気付けなかったのか
- どうすれば気付くことができたのか
について考えてみます。
なぜ気付けなかったのか ― 原稿と同じならOK？
『CO2』→『CO2』と記述するのは、化学式を記述する際の一般的な規則です。
化学式における下付き文字は「直前の原子の個数」を表すという重要な意味を持っています。
これはある種常識といえますが、この常識をなぜ見逃したのか？
それは、「支給原稿と照らし合わせ、問題ない」と判断したためです。
これが今回の指摘に繋がるミスでした。
支給原稿にも『CO2』と書かれており、原稿と同じだったため見逃したのです。
口に出して読んだとき「シーオーツー」で一緒ですし、今回のようにコンピュータ上だと「CO2」と妥協して書かれていることも多いので気付きにくかったと自己分析しました。
どうすれば気付くことができたのか ― 『校正』と『校閲』
コンテンツを正す手法として、『校正』と『校閲』があります。
校正：原稿と照らし合わせて誤りを正すこと。誤字脱字の修正も含む。
校閲：誤記の訂正、一貫性のある表記、専門用語を正確かを確認することで、良い文章へ底上げする。
HTMLをマークアップするエンジニアは、往々にしてHTML内の文章の正確さを求められます。
その正確さとは、原稿との一致のみを意味するものではありません。文章そのものの正しさを求められます。
文章を正しくするには、日付や、慣用表現などをチェックすることで精度を高められます。
本来それはマークアップエンジニアの仕事なのかとも思いますが、自分が作ったものに対する責任という意味で、完璧な校閲とまでは言わずともある程度は確認すると"大人な対応"な気がします。
つまり、「原稿と照らし合わせ、形として『文字』の差異がないのでOK」、ではなく、その文字の意味もチェックすれば今回のミスは気付くことが出来ました。
校閲のための知識
今回のCO2話は、
- 化学式である
- 化学式内の数字は下付き文字にすることで直前の原子の個数を表す
というような化学式の知識を持っていなければ「CO2」に気付くことは不可能です。
故に、校閲するためにはある程度知識を持っている必要がある場合があります。
しかしながら、すべての知識を把握することは（殆どの場合）できませんので、また同じようなことがあったときのために、よくありそうな話をまとめておき、これを今後のための対策とします。
化学式
化学式内で登場する数字は2パターンあり、分子の個数を表現するものと、原子の個数を表現するものです。
後者については下付き文字にすることが規則です。
HTMLでは、<sub>1を用いて下付き文字を表現します。以下のようにコーディングします。
CO<sub>2</sub>
<sub>は、ただ文字を下付きに表示したいだけのときに用いるのは適切ではありません。
化学式や、数式内の変数、脚注の数字など、表記上の規則や習慣によって下付きにしなければいけない場合に使います。
例：
x1 + x2 = ...
脚注1は下部
数式
乗数を表現する際は、上付き文字要素<sup>2を使用します。
使う際の注意点は<sub>と同様です。
2<sup>16</sup>
日付
日付の正確さ
よくあるのは日付と曜日がマッチしてないパターンです。
例えば、2022/4/1は金曜日ですが、原稿では「2022/4/1(木)」となっている、などです。
これは知識は関係なく、日付が出てくる度にカレンダーで確認するべきでしょう。
また、例えばリリース日が本当に正しいか、という日付の意味の正確性を確かめることも必要です。
本当にローンチがその日なのか、スケジュールを確認する必要があります。
日付の英語表現
月名
月に関しては、英語で書くときは省略する場合も多いため、スペルが正しいかなどはチェックします。
また、英語における月の名前は固有名詞として扱うため、頭文字は大文字にします。
| 月 | 英語 | 英省略形 |
|---|---|---|
| 1月 | January | Jan |
| 2月 | February | Feb |
| 3月 | March | Mar |
| 4月 | April | Apr |
| 5月 | May | May |
| 6月 | June | Jun |
| 7月 | July | Jul |
| 8月 | August | Aug |
| 9月 | September | Sep |
| 10月 | October | Oct |
| 11月 | November | Nov |
| 12月 | December | Dec |
- 省略形の末尾にはピリオド[.]をつけるのが慣例です
- 日常場面では数字を用いることも多々あります。
フォーマルな場ではアルファベット表現を使うことが多いです
日付の書き方
日付を表記する場合、基本的には月名はアルファベットで表記し、日は接尾辞（-st, -thなど）を添えて記述するのが完璧な書き方です。
アメリカ式表記では「月 日, 年」と書きます。
- April 1st, 2022
-
4/1/2022
(数字表記のセパレータはスラッシュ、ハイフン、ピリオドを使うことが多いです)
イギリス式表記では「日 月 年」と書きます。
- 1st April 2022
- 1/4/2022
曜日をつける場合は、先頭につけます。
- Friday, April 1st, 2022
- Fri, 1st Apr. 2022
表記揺れ
日本語はとにかく表記揺れが発生しやすい言語のように思います。
例えば、「問い合わせ」。
- 問い合わせ
- 問い合せ
- 問合わせ
- 問合せ
などなど、送り仮名や「お」をつけるかなどによって書き方が変わります。
また、「分かります」「わかります」のように漢字にするかどうかなどでも揺れたりします。
これらはクライアントの判断によるところが多いかと思いますので、揺れがある場合はしっかり確認すべきでしょう。
固有名詞
固有名詞は一字一句正しくなくてはなりません。
例えば、Javascriptではなく「JavaScript」、FireFoxではなく「Firefox」など、正確に表記するようにします。
現在の言葉遣いの反映
時代によって、言葉が変化することはよくあります。
有名なものでいうと「ら抜き言葉」など、少し前は問題視されていたこともありましたが、今は「ら抜き」にすることで、「来れる」という可能の意味を表すことが明らかになるので認識しやすいという理由からそこまで問題視しなくても良いという意見も多くあります。
現在のスタンダードを原稿に反映することは重要です。
また、「看護婦」ではなく「看護師」、「スチュワーデス」ではなく「キャビンアテンダント/フライトアテンダント」などの単語の変化はなかなか気づきにくいところかもしれませんが、前の言い方だと現在では差別用語とされる言葉が含まれている場合があるので特に注意が必要です。
その他よくありがちなのが、「省略語」です。
以前、「まつエク」と省略された言葉を注釈で意味を説明する場面で、「まつげエクステの略」という原稿だったことがありました。
正確に書けば、「まつげエクステンションの略」です。
このように、知識があれば違和感を感じられるような場合もあるので、注意深く文章を読むことも必要です。
まとめ
文章をHTMLに落とし込む際はコピペするため、意識しないと文章をちゃんと読まないかと思いますが、最終的にWebで閲覧できる成果物は原稿でもFigmaやXDなどのデザインデータでもなく、エンジニアが書いたHTMLです。
故に、HTMLを書いた人に重い責任がのしかかります。自信を持って公開するためにも、自分の書いたものに責任を持ってある程度校正・校閲する必要があります。
本職の校閲者のように校閲するのはエンジニアの業務ではありませんし、もちろん時間も足りません。
しかし、納品物の品質をあげるためにエンジニアが気にかけられることはいくつかあるのではないかと感じ、記事として残しました。
今後もよくある校閲場面があれば追記していきたいと思います。