プログラミングでは「スコープの広い変数、関数」はできるだけ使わないという原則がある。実は文章を書く場合もこの原則を同じように気をつけるべきなのだ。ある1行が別なn行と関係がある、というときに、そのn行は「極力近い位置に」そして「極力少なく」なるように文章を書くべきである。そのために役立つ「ゴール頭の原則」を知っておこう。
意識のスコープ
日本語による説明文の品質向上を目的として、IT技術者が直面するさまざまな文書事例からその問題点と改善策を検討する本連載、第3回は「意識のスコープを縮小せよ」というテーマでお届けしよう。
「スコープ」と言うとIT技術者の間では「プログラム言語における変数のスコープ」という概念がよく知られている。要するに、ある変数がソースコードのどこからどこまでの範囲から「見える」かを示すのがスコープである。この意味での「スコープ」はできるだけ狭いほうがよい(図1)。スコープが広すぎると、その分、思いがけないところに影響を及ぼしてしまう可能性が高くなり、プログラムの保守性が下がるわけだ。

文書を書く場合も実はまったく同じことが言える。「スコープを狭くすること」を意識して書かれた文書は、読者がそれを解読しようとするときに、狭い範囲の情報だけ覚えておけばよいので楽なのだ。まずはよくない例として、以下の一文を考えてみよう。
例文1:必要に応じて設定ファイルsx.confを編集してからrestartsxコマンドを起動することにより、SXサービスを再起動することができます。
短い文なので欠点が目立たないが、このような書き方はあまりよくない。なぜよくないのかを知るために、この文を前回説明した「ラベル付きステートメント構造」で書き直すと次のようになる。
【手順1】必要に応じて設定ファイルsx.confを編集します。
【手順2】restartsxコマンドを起動します。
【ゴール】SXサービスが再起動されます。
「ゴール」のところは「目的」や「結果」「成果」と書いてもかまわないだろう。
この記事は参考になりましたか?
- 例題でわかる! 伝わるドキュメントの書き方トレーニング連載記事一覧
-
- 意識のスコープを縮小せよ
- 文章を書くな、ラベル付きステートメント構造を使え
- ドキュメントに「夜間バッチ」と書いてはいけない
- この記事の著者
-
開米 瑞浩(カイマイ ミズヒロ)
東京大学理科一類中退。IT技術者の業務経験を通して「読み解き、考え、説明する」スキルの再教育の必要性を認識し、2003年からその著述・教育業務を開始。小説家を目指したほどの文章力にもかかわらず図解を多用し「文章は図解の添え物」との主張が持論。図解力、思考力、プレゼンテーション等の講師として民間企業・官公庁での研修実...
※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
この記事は参考になりましたか?
この記事をシェア