|
SEの仕事は文章を書く機会が多い。提案活動では提案書、受注後のシステム設計・システム開発では、要件定義書（要求仕様書）や基本設計書、インタフェース仕様書、操作マニュアル、運用マニュアル等の納品ドキュメントがある。また、これ以外にも進捗報告書や客先への報告資料などがある。
にもかかわらず、文章を書くのが不得手というSEは意外に多い。私もあまり得意ではない。
特に、プログラマーからSEになった人に多く見受けられる。プログラマーの場合は、詳細設計書や、ソースコードのコメント、テスト仕様書など、箇条書きに近い文章が多いせいかもしれない。
プログラマーが書く進捗報告書には箇条書きのものが多い。余計なことは書かきたくないから、とも考えられるが、文章を組み立てることに慣れていないから、という側面もありそうだ。
このような背景からか、SEを対象とした、文章力向上のための講座や書籍等が幾つかある。
その中には、文章力向上の重要な要素として「語彙」をあげているものがある。語彙を増やすことで表現力が増すという側面はあるが、それが求められるのは、どちらかというと小説や随筆の類であろう。
語彙を増やすことは間違いではないが、SEが書く文章に求められているのは、
① 正確性（正しい日本語で、内容が正確であること）
② 論理的な文書構造と定量的な表現
③ 専門用語への配慮（特にエンドユーザーも読むようなドキュメントでは、専門用語を控え、使用する場合は出来るだけ注釈を付ける）
だと考える。
(1) 正しい日本語
まず「日本語」について考えてみたい。
二畳庵主人加地伸行の「漢文法基礎」には、以下の指摘がある。
「“てにをは”という語句は、日本語の性格を代表する重要な意味を持っている。近代風に言えば、文の構造の根核ということだろう。文において最も大切なところである。
それは突き詰めると助詞の問題ということになるが、その助詞中、この“てにをは”が最もよく使われ、最も重要だということである。そして、おそらく、日本人でないと、こうした助詞をなかなか使いこなせない。
・・・・“てにをは”をしっかり読み取り、しっかり書けるということが、国語の基礎である」
“てにをは”をはじめとする「助詞」や、文章をつなげる「接続詞」を正しく使うことが、「正しい日本語を書く」ための基本である。
「“てにをは”くらい正しく使えるだろう！」という意見もあるかと思うが、他人の書いた提案書や設計書を読んでいると、“てにをは”の間違いは結構多く見られる。
小学校の国語の基本も、この助詞や接続詞を正しく使えることがポイントになっている。
また、抽象化と具体化も一つのポイントである。
小学生の国語力の1つに「言いかえる力」がある。これは、「つまり」と「例えば」の使い方である。
「AつまりB」のとき、Aは具体であり、Bは抽象である。
「B例えばA」のとき、Bは抽象であり、Aが具体である。
小学校レベルなので「言いかえる力」という表現になっているが、大人向けの表現に直せば、「抽象化能力」ということになる。
要件定義書（要求仕様書）では記載粒度が問題になるケースが多々ある。これは、具体化が不十分なケースがほとんどである。
例えば、「現行システムの画面操作性を向上する」というのは要件には違いないが、これでは何をどう変えるのかが分からない。これは極端な例であるが、似たようなことはよく目にする。また、「詳細な要件は行間に書かれている」とか「行間を読め」という人がいるが、これも単に具体化・詳細化が不足しているだけの話である。
そうはいっても、例えば画面設計では具体的に記述していたら切りがない。ボタンの大きさはxxピクセルで、ボタンとボタンの間はyyピクセル、などと書いてもイメージが湧かない。いっそのことプロトタイプを見せた方が早い。
このあたりは開発方法論や開発手法が絡む問題であり、さらに、自然言語で業務要件を記述する際の課題を内包している。
いずれにしろ、文章で要件を表現する場合は出来る限り具体的に書くべきであり、必要に応じて図表などで補完するのが良い。
日本語の文章には、「最後まで文章を読まないと、肯定しているのか否定しているのかが分からない」という特徴がある。「・・・・・・ではない。」のように、最後に否定がくる。この点、英語や漢文は否定を表す言葉が前に来るので、肯定なのか否定なのかが直に分かる。
従って、日本語で表現する場合は、あまり１文を長くしない方が良い。
また、あいまいな表現が可能であるという点も特徴ではあるまいか。「・・・と言えなくもない」、「必ずしも、・・・・というわけではない」、などの表現形式である。
これは、はっきりと白黒を付けるのを避ける、日本文化の特徴に由来しているように思う。白でもなく黒でもない、あるいは、白であり同時に黒でもある、のような二項対立や二律背反を否定する東洋的思想の影響とも考えられる。もっとも、最近は欧米流の合理主義が導入され、白黒をはっきりさせる傾向が強くなってきているようである。
システム開発に関わるドキュメントは、あいまいな表現は避け、結論をはっきりさせるべきである。
まとめると、SEが書く文章は、正確な日本語で、１文をあまり長くせず、結論を明確にする（あいまいな表現を避ける）のが良い。
(2) 論理的な文書構造、定量的な表現
文章を論理的に構成する方法や、文書の構造に関して参考になるのが、
バーバラ・ミント著「新版 考える技術・書く技術」である。
バーバラ・ミントのピラミッド・プリンシパルは、マッキンゼー社の標準ライティングとして始まり、その後コンサルティング業界の事実上の標準として普及したものである。
ピラミッド・プリンシパルの要点を引用すると、
「分かり易い文章は、主題に関する様々なメッセージ同士の関係を正確に分かり易く表現することから生まれます。正しく構成すれば、これらのメッセージは常に一つの考えを頂点とし、いくつかの要約層で成り立つピラミッドを作ります。
ピラミッド内のメッセージは、上、下、横の3つの方向で関連付けられています。
上部のメッセージは下部の複数の考えを要約したものであり、逆に言えば、下部の複数の考えは、上位のメッセージを説明しサポートするものです。
同レベルのメッセージは、横方向に論理的な順序で並べられます。その論理的な順序は、ピラミッドが演繹的に構成されているか、帰納的に構成されているかによって異なります。
これら2つの論証法以外に、メッセージを論理的に関連付ける方法はありません。従って、演繹法と帰納法の違いやルールを理解することは、自分の考えをグループ化し、それを文書で明確に表現するためにとても重要なことなのです。」
SEが作成する文書は、基本的に、結論先行の帰納法で構成する方が良い。
この点は、一般のビジネス文書と同じである。帰納法は、先ず結論を述べ、その次に結論を支える論拠を「漏れなく、ダブりなく」記載する構造となる。
定量的な表現について、であるが、例えば、「バグの混入が少ない開発手法を採用する」という表現は正確ではない。バグが少ないとは、Kstepあたり何件以下なのか、あるいはファンクションあたり何件以下なのか、定量的に表現しないと正確とは言えない。
定量化できるものは定量化するよう心掛けるべきである。 |
