編集者だったソフトウェアエンジニアが
ママを恋しいと思うとき


宮坂 聡

筆者がモノグサ社でソフトウェアエンジニアとして働くようになってから、この春で二年半になります。

その前は、とある教育系の出版社で、編集の現場にいました。日々、編集者としてゲラやPDFと向き合いつつ、少しずつエンジニアリング的なことも勉強していて、そして縁あってモノグサ社でエンジニアとして働くようになったものです。

会社も変わり、職種も変わったので、私にとっては新しいことばかりでした。

同じように作られたマンションの部屋と部屋でも、入ってみればそれぞれ家の匂いが異なるように、職場もまた、その会社の歴史や文化、人々の考え方ややり方が、その会社の空気をつくり出しているように思います。

空気をつくるもの

モノグサ社は、今のところキャリア採用が多い会社です。その中には、私のように他職種から転職したエンジニアもいますし、海外や他業種からの転職者もいます。その一人一人が、多かれ少なかれ、また意識的にも無意識的にも、それまでの経験や知識を持ち込んでいます。

もちろん、モノグサ社が昔から大切にしている習慣やカルチャーというものはあります。しかし、何か一つ不磨の大典のようなものに従っているわけではないので、やがてその上に少しずつ、メンバーが新しい見方や考え方、プラクティスを持ち込みます。それを積み重ねることで、会社の文化や、やり方というものが形成されるのだと思います。

私の前職は編集職ですから、エンジニアの仕事に直接持ち込めるようなものは少ないかもしれません。しかし、編集の現場で使っていた言葉や考え方、プロセスなどは、エンジニアリングの現場でも同じだと感じることがあります。

本稿では、そんな話をしたいと思います。

編集者がやっていること

編集者という職種がどんな仕事のことなのか、身近に編集者がいなければ、あまりイメージがわくことはないのかもしれません。

会社によっても、また担当している案件の種類によっても違うので、あくまで私の経験の話だという前置きをしましょう。その上で、ごく大まかに言えば、執筆者から原稿をもらい、それを読者に届けられる状態にする仕事と言ってよいと思います。

文章の修正

そんな仕事の中では、原稿やゲラなどを見て、文章の修正をする機会がとても多いものです。

ゲラというのは、出来上がった原稿をシステムに投入して、実際の誌面のとおりに紙に印刷したもののことです。ゲラに書かれている文字や図は、もし編集者がOKをすれば、そのまま製品になっていきます。

編集者は、このゲラをチェックして、原稿で見つけられなかった不備や、誌面をつくる過程で生じたミスなどを見つけ、最後の修正をするのです。

修正をするのは誰?

この仕事について、注目したい重要なポイントがあります。それは、ある人が原稿やゲラで修正点を見つけても、たいていは、その場で自分が修正作業をするわけではないということです。

たとえば、原稿を見ていて「記述のつじつまが合わない」と気づくことがあるでしょう。そんなとき、自分でつじつまが合うように直すのではなく、執筆者の責任として、執筆者に判断を求めることがあります。

また、編集者の責任で直すケースであっても、たとえば複数の編集者がかかわっている場合であれば、サブである自分はあくまで修正の提案にとどめ、メインとなる編集者に判断をあおぐということもあります。

さらに、修正の判断をしたとしても、実際にゲラに反映する作業は、専門的なツールを使うことのできる別の人が行うことも多かったりします。

修正を正確に伝える

このような場面では、修正についてのやり取りが生じます。そのときは、修正内容を正確に伝えることが重要です。そうでないと、たとえば、意図しない修正が行われて、ミスが増えてしまったりするからです。

そのために、今まで数多くの編集職の先人たちが、独特の校正記号や校正用語をつくり上げ、そごのないコミュニケーションをとるための工夫をしてきました。その結果、編集者の界隈では、文章の修正に関連する用語やプラクティスというのは、ずいぶん発達しているように思います。

一方で、ソフトウェアエンジニアリングの話に戻ると、どうでしょうか。

ソフトウェアエンジニアの仕事でも、誰かに修正提案を伝えるという場面は少なくはありません。たとえば、レビュープロセスの中では、他のエンジニアの書いたコードや文書、ドキュメントなどを修正する機会は、日常的にあることです。

編集者に比べると、そういった修正についてのやり取りというものが仕事のコアを占める度合いは、高くはないのかもしれません。それでも、(あるいは、それだからこそ、)編集者がつちかってきた言葉やプラクティスの中には、エンジニアリングの現場でも使えるものがあるのではないかと思います。

修正をしないという結論

前置きが長くなりました。

私が一番便利だと思う編集者の用語は「ママ」です。

ママという言葉を説明しておきましょう。この言葉は、一度は修正をしようと思った箇所について、「やっぱり修正しない」ということを意味します。たとえば原稿の修正であれば、「原稿に書いてあるとおりにする」ということですし、ゲラの修正なら「ゲラに印字してあるとおりにする」ということですね。

ソフトウェアエンジニアのレビューの中でも、「ママ」に相当することが言いたい場面はよくあります。たとえば、何か良くないと思う点があって修正意見をつけてはみたものの、議論した結果「やっぱり修正の必要はないですね」ということは、決して珍しくはありません。

あの案ってどれのこと?

一般に、いくつかの案を検討したあとには、「結局、あの案が良いね」というように、結論めいた意見を言うことはよくあるはずです。そんなときに注意しなければならないことは、「“あの案”ってどれのこと?」という疑問が生じないように、伝え方に十分気をつかうということです。

あるいは、疑問が生じるというのはまだマシなほうで、ひどく言い方が悪いときには、疑いもなく別の案のことだと信じられてしまうことだってあるでしょう。それは、かなり良くないことです。

伝え方に気をつかうというのは、つまり、どの案を指しているかが明確に伝わるようにするということです。

そのとき、議論の中で出てきた特定の案を指して、正確に伝えるためにはどうするでしょうか。

提案した人を指して「○○さんの案」と言うこともできますし、コメントのやり取りであれば、当該コメントのリンクや引用をすることもできます。あるいは、具体的に「○○にする案で行きましょう」と言う場合も多いでしょう。

ここで注意したいのは、いずれも、一連の議論の中でその修正案が登場し、また一度は推されたタイミングというものがあるからこそできる伝え方だということです。

何も修正しないという案

一方で、何も修正しないという案についてはどうでしょうか。提案者がいないので、「それが登場したタイミング」というものがありません。修正内容もないので、具体的に内容を述べることもできません。

なので、修正をしたくないという結論を主張する場合は、たとえば、「修正は不要ということにして元々の文言のとおりでいきましょう」などと、ちょっと回りくどい言い方をしながら、「本当に誤解の余地がないだろうか?」と二、三回確認をしてコメント送信することになるわけです。

こんなとき、「ママでいきましょう」と言えば、修正の意思がないことを明確に伝えることができるのになと思うと…、

編集者の使っていた用語が、少し恋しくなってしまうわけです。