そろそろ、仕事を通して遭遇した「悪文」を記録していこうと思います。もっと早くやっていればよかったのですが、こんなに「ITエンジニアって人達が日本語下手くそ」だとは思わなかったので。別に専門的に学んだ訳ではないのですが、少なくとも「読んでも読んでも意味が分からない」とか「気持ち悪い」と思う感性はそんなに間違ってないと思うので、思ったままを書き残していきます。同じような仕事をしている人のお役に立てば幸いです。
なお、仕事の文章をそのままコピペする訳にはいかないので、元ネタが判らない程度には改変します。
尻切れの文章
文章がなぜか途中で切れていたり、「で、何？」と言いたくなるような文章。下記は取引先のシステムエンジニアさんから送られてきた作業指示/依頼のメールです。この短い文章にここまで突っ込みどころを盛り込めるものなんだ、と思わざるを得ない内容。
① 統合購入機能を利用する
→ PRG改修でなく、
② 共通購入機能の複製機能新規対応
→ ①の機能を使って追加対応
③ 新規機能の追加
→ コードがA始まりの製品だったら、の条件で、新規対応を追加する
上記①について、問題無いかどうかの検証を実施し、他機能への影響含め問題無ければ、
以上の件、よろしくお願いします。
上記赤字部分ですね。
最初の「①」の部分ですが、おそらく言いたいことは「プログラム改修でなく、既存の共通購入機能を利用する」と言いたいのだとは思います。しかし、ここで倒置法を使う意味はありません。「～を利用する」が大事なことで優先したいのであれば、矢印の先はそれの補足として「プログラム改修は極力抑え、コストを抑える。」といったように、なぜそうするのか、意図を書いた方が読み手に優しいですね。また、右矢印（→）は、直感的に読むなら「左の事柄の結果、右の事柄になる」という順序をあらわす記号なので。この文章は矢印の流れにも逆らっています。
末尾の「問題無ければ、」は、これだけ読むと「末尾まで書かずにメール送信しちゃったのかな？」とも思えますが、上記の箇条書き①のケースがあるのでこの人の場合はこの文章が完成形です。おそらく、箇条書き①～③を書いてから、①について補足をしなければいけない、と気づいたのでしょう。そこで「①について、」と書くことで補足であることを宣言した上で、軽い気持ちで言い添えた……のでしょうが、これは文章ではやってはいけない方法です*1。この方は取引先の方なのですが、この人の文章は全体的にこのノリで、会話での文体がそのまま、思いついたまま書き綴られます。会話では時間を遡ることはできませんから、序盤で言葉足らずだった言葉は後半で言い添えるしかありません。しかし、文章は時間を越えて繰り返し読まれるもので、文章の流れは基本的に「最初から、末尾に向けて一方通行」が基本。「あ、さっきの件言い忘れたけどね……」という言葉があるならば、文章の場合は「さっきの件」にきちんと書き足すのが筋です。
チャットや会話の文章に依存しすぎてきちんと書き残すことをやってこなかった人はこうした文体を使いがちです。書き手はその時の気持ちを順次書き綴ってるだけですが、読み手は内容を読み解くために文章を組み替えて、時系列に並べ直さないといけません。いわば、正解がないジグソーパズルを解いて初めて読める。その労力を読み手に強いる文章は悪文です。
用語不統一
実は、下記例文の「統合購入機能」と「共通購入機能」は、同じ機能を指しています（青太字部分）。
① 統合購入機能を利用する
→ PRG改修でなく、
② 共通購入機能の複製機能新規対応
→ ①の機能を使って追加対応
③ 新規機能の追加
→ コードがA始まりの製品だったら、の条件で、新規対応を追加する
上記①について、問題無いかどうかの検証を実施し、他機能への影響含め問題無ければ、
以上の件、よろしくお願いします。
実際の業務やシステムを知っている人であれば、言い間違いであることや部署や場面で呼び名が違うことを判っていたりするかもしれません。しかし、これは取引先の相手から外部のシステム開発業者に送られた文章。こう言う場合は、違う名称であれば「別物」と扱われる可能性があります。たとえば別の場面で呼び名が違うのであればまだマシですが、1つの文章の中で言い間違いが起きると、わざわざ違う名称を書くことの意味について読み手は考えてしまいます。そして、安全をとって「別物の可能性がある」となり「この片方は新しい機能ですか？」という質問から余計なやりとりが発生してしまいます。
これは各自が気をつけるしかないですが、もし可能であれば以下のような方策も有効かも知れません。
- 命名を工夫する …… 1文字違いのような名称を避け、明らかに異なる名前を付けてしまうことで誤読や言い間違えを避ける。
- 機能名に番号や符号を割り当てる …… 機能一覧やタスク一覧のようなものから、作業対象を名称だけでなく番号や符号、コードで特定出来るようにしておく。仮に言い間違えても、「それは機能3のことですか？」といったように問合せも回答もやりやすくなる。
- 機能のカテゴリーを分けておく …… 似たような機能名を付けざるを得ないならば、それらがシステム内で別のジャンルの機能であることを表せるようなカテゴライズができないか検討する。これは直接的な効果はありませんが、上記のように質問をする際に「それはデータ取込工程の機能ですか？それとも仕分け工程の機能ですか？」というように区別を付けやすくなる。
結局、駄目な文章や誤記が招くのは「余計な作業」です。1人がそこで行き詰まるだけならまだマシですが、やりとりの中で発生した誤解は、それを解くために複数人の労力を必要とすることがあり、そうしたものの積み重ねがプロジェクトの遅延などにも繋がります。塵も積もれば……ってやつですね。また、コミュニケーションにストレスを感じるようになることで「あいつの言う事はよく分からないから、面倒だし勝手にすすめよう」といった状況を生むことにもなりかねません。
1つの文章の中で同じ事柄を指す場合の名称にはきちんと一貫性を持たせる。これは結構重要なことなので、注意された方が良いと思います。
箇条書きのルール違反
最後に、箇条書きについて。例文には3つの箇条書きがありますが、それぞれの文末に注目してください。
① 統合購入機能を利用する
→ PRG改修でなく、
② 共通購入機能の複製機能新規対応
→ ①の機能を使って追加対応
③ 新規機能の追加
→ コードがA始まりの製品だったら、の条件で、新規対応を追加する
上記①について、問題無いかどうかの検証を実施し、他機能への影響含め問題無ければ、
以上の件、よろしくお願いします。
- 利用する（動詞）
- 新規対応（名詞）
- 機能の追加（名詞）
大学で論文などを書くことがあると、おそらく教授や先輩達から徹底的に叩き込まれがちなのがこれですね。箇条書きのそれぞれの箇条は文体を揃え、文末の形式を揃えること。極端な駄目な例を挙げると
のような箇条書きは絶対ダメということです。上記の例に違和感を覚えないならば、日本語の単語の種類。少なくとも「動詞」「名詞」「形容詞」くらいはざっくりと分類方法を把握してから文章作成に挑まれることをお勧めします。極端な例を挙げましたが、問題の例文の箇条書きを改めて書くと
① 統合購入機能を利用する
② 共通購入機能
③ 新規機能の追加
こうなっています。この箇条書きにタイトルを付けるとしたらどうなるでしょうか？1番目だけ見ると、たとえば「改修にあたっての方針」なんてのもいけそうですが、そうすると2番目は機能名を書いてるだけなのでマッチしませんね。では、2番目を起点にタイトルを付けるとすると……たとえば「改修対象機能」であれば2番目はしっくりきますが、1番目、3番目には合いませんね。このように、箇条書きで書くならば、全ての箇条の内容は「同じジャンル、同じ種類のもの」であり、全体に対して「以下に～について列挙します」というような一文を入れても違和感がないようにするのが鉄則です。
これを意識していない人は結構多いので注意してください。
