文章を見直す、って何を見直せばいいのかまとめてみた
同僚の資料を添削する機会があって、添削と議論の中でわかったことをまとめておく。
NOTE: ここで資料とは、要件を議論するたたき台資料とか設計の選択肢の検討資料を指す。
正直自分も同僚と同じ年代の頃に「これロジカルじゃないよ」とか言われても、いや分からんなぁ...と思ってたし、その時にこんなことを分かってればもう少しうまいことやれたのかなぁ、と思いつつ。
自分が書いた文章を例文として拝借されることを快諾してくれた同僚氏、ありがとう。
資料を構成する要素を一つずつチェックする
資料を構成する一番小さな要素から順にチェックしていく。
資料は
- 単語
- 文
- 段落
- 章
が集まってできている。 チェックの観点は、これら一つ一つが日本語として正しいことと論理的に正しいこと。
単語
PCで書くなら関係ないけど、存在しない日本語を書いていないか調べる。 論理構造はないので調べない。
文
同音異義語を使い間違えていないか調べる。
破戒的変更を許容します。
日本語として「てにをは」が破綻していないか調べる。
この処理には外部アクセスに必要ない。
-> 外部アクセス「は or が or ...」
主語と述語だけを読む。それだけでも主張がズレないかを調べる。
自分の意見は、S3にあるファイルをサーバーの特定の箇所に置くという処理です。
-> 主語と述語だけを抜き取ると「意見は、処理です」となり、文章の意味が通らない。
ズレる場合、修正する。文を短く切るのが有効な場合があるので、検討する。
段落
ここらへんから日本語として正しいかを調べる必要がなくなってくるので、ある段落が論理構造的に正しいかを調べる。 あと、正直好みもある気がするからなんとアドバイスしてよいか悩ましい...。
段落の結論を述べている一文を探す。ない場合、作る。ある場合、それが1、2文目に入っていなければ移す。 2文目でも良い理由は、たとえば問いかけから始まったり、前の段落を受けての1文で始まったりする場合が考えられるから。 （というか本来は何文目でもいいはずだが、慣れないうちから変な場所に結論を書くのは筋が悪いと思う。）
次に、段落に見出しがある場合は、見出しだけを読んでみる。見出しだけを読んでその段落の主張が分かるか調べる。 わからない場合、わかるように書き直す。
## 自分の意見 自分の意見は、今回はS3のPUTイベントを使って処理を行うべきだと考えています。 ========================== ## S3のPUTイベント通知を使うべき 自分の意見は...
文と文のつながりが破綻していないか調べる。 具体的には、ある文の主張と次の文の主張を比較して、その関係を表すのに適切な接続詞を使ったり使わなかったりする。
案としては、S3のPUTイベントを使うことが考えられます。さらに、バッチ処理で実装することも考えられます。
-> 2つの文は内容は案の列挙。しかし接続詞の「さらに」は前の文に詳しい説明を追加する時に使う。よって不適。
また、段落の主張と、段落に含まれる文リストを比較して十分な論拠を示せているか調べる。 具体的には、今まで出会った中で一番意地悪な質問をする人を脳内でエミュレートしてその人にツッコませる。 ロジックツリーを書いても良いけど、どちらにせよセルフツッコみは必要。
文章
段落に対して行ったチェックを文章に対しても行う。
文章の結論を述べている一文を探す。ない場合、作る。ある場合、それが最初に書いていなければ移す。
文章には普通見出しがあるので、なければ作る。ある場合、見出しだけを読んでみる。見出しだけを読んでその文章の主張が分かるか調べる。 あるいは文章の見出しなら、主張ではなく目的がわかるだけでも良い気がする。 たとえば、以下の見出しはどちらでも良い気がする。
# ○○処理の自動化の実装方針を決める ========================== # ○○処理の自動化をS3のPUTイベント通知をつかって実装したい
段落と段落のつながりが破綻していないか調べる。 こちらは段落内の文のチェックと違って、前後のつながりというよりは論理構成が正しいかを確認する。 具体的には、まず段落の見出しだけを読む。それを読んだだけで大筋は納得できるか調べる。
まとめ
まとめてみた。 文章の論理構造が正しいかのチェック方法を、まだうまいこと明文化できない。自分でもうまいことできてないんだろうな。
