読み方の教科書が必要。
卵・ニワトリ問題かなぁ。
クソ文章とヨサゲな文章を読み分けられない人が、ヨサゲな文章を書けるものでしょうか。
# ごみためまんはいまだに見分けられませんがね。
もし書けたとして、どうしてそれがヨサゲな感じに書けたと判断できるでしょうか。
結局、読めない人に書き方だけ教えると、
へんてこりんな文章を書き散らかしておいて、
『ＸＸＸセミナーで仕様書書き方認定試験をパスした
俺様の仕様書が読みにくいはずがない』
というような厄介な裸の王様を量産してしまう恐れはないでしょうか。
「SEとプロマネを極める 仕事が早くなる文章作法」（発行：日経BP社）にまとめました。
まだ立ち読みしてない
世間にイナゴのように湧いている自称プロマネの皆様の日本語リョクの最大の問題は、上位設計書、あるいは上流工程の要求仕様書を読みこなせていないことではないでしょうか。
# メールの用件も通じにくいから無駄なピンポンが増える感じ？
ごみためまんのカスのような仕事の経験でさえ、いわゆる大企業や、元請のSIerの書く仕様書はそれなりの品質を満たしているように感じられました。
たしかに大企業の仕様書は無駄にボリュームが大きく冗長で、誤字脱字や細かい矛盾を多数はらんではいますが、SGMLで構成された厳密な電子文書よりは１００倍読みやすいでしょう。
問題はそれらをブレークダウンして書かれる個別の仕様書やQ&Aがクソ過ぎることです。
枝葉末節にこだわるばかりのQ&Aや、車輪の再発明ばかり。printf＋ラッパーでできることを、いちいち仕様書に書き起こしているのも見たことがあります。
# 「車輪の再設計」というフシギなワードを広めてる阿呆も最近見かけました。
これをもって書く能力の不足と考えるのはやや危険と思われます。
原因の多くは、どちらかというと上流の仕様書を理解できていないことではないでしょうか。理解できていれば、Q&Aは要点を押さえたものになるはずで、冗長さや誤字脱字に対してはスルー力（りょく）が発揮されるはずです。
理解できないために、誤字脱字によって簡単に惑わされ、いちいち言葉のロジックを確認するためのQ&Aを連発することになるのです。
かつては、この手の仕様理解にまつわる諸問題を占めたのは、
ドメイン知識の有無
でした。制御システムの仕様を読むには、制御系のコトバが分からないと話になりません。単語、用語ひとつずつは簡単なものですが、それが数十・数百なければ、特定ドメインの知識を前提に書かれた文書は仕様書であろうがなんであろうが読めないでしょう。
# いちいち説明しないと分からない相手とは仕事したくないでしょうな。
それを誰でも読めるように書けと元請/客先に要求しているのが、現状ではないでしょうか。
つまり年を追うごとに問題が劣化してるわけです。これでは国際競争力もクソもないでしょう。
さらに状況を悪化させているのが、オフショアへのアウトソースです。
上記のような日本語が不自由な自称プロマネの皆様のレイヤーが、海外の文字通り日本語が不自由なコーダーやSIerに仕事を振って生産性向上と叫んでいるのです。
あっというまにナカヌキされないのが不思議でしようがありませんが、オールドエコノミーを支えた
日本の商習慣(IFRS怖い)
が抵抗しているようです。（a.k.a. グループ内循環取引で売り上げ倍増）
大企業や元請SIerの劣化が進めば、あとはパッケージを買ってくるだけの商社しか残りません。
カスタマイザー(UIだけ格好付けた)
アドバイザー(a.k.a.保険の窓口)
が幅を利かせる貧乏産業に落ちぶれるのも時間の問題かもしれません。
リンクル：
10年前から（愛ちゃんよりも、）四元派 ごみため(ー日ー膳！)
それで最近気づいたのは、自称技術者の方々が日本語を読めなくなっているということです。
Things You Should Never Do, Part I – Joel on Software
It’s harder to read code than to write it.
This is why code reuse is so hard. This is why everybody on your team has a different function they like to use for splitting strings into arrays of strings. They write their own function because it’s easier and more fun than figuring out how the old function works.
