『ＳＥ の文章術』 （編纂‘09.06.30 渡邊） ∼ 相手の立場を考え、解りやすい・理にかなった文書 を作成 ∼ 文章は､会話やﾌﾟﾚｾﾞﾝﾃｰｼｮﾝと同様に､人間の基本的なｺﾐｭﾆｹｰｼｮﾝ手段の１つ。これがなくては､自分の主張や指示 を他人に効率的に伝えることができない。IT 現場では文章力が不足で､「要件が曖昧でﾃｽﾄｹｰｽが漏れた」､｢ｼｽﾃﾑ設 計書が解り難いためﾌﾟﾛｸﾞﾗﾑの製造効率が悪い」など､品質や生産性が低下するケースがよくある｡ 技術力に傾注しがちな 1T 業界だが､論理的な思考展開と文章力向上の必要性が叫ばれている。 第 1 章：なぜ文章力が必要なのか ◆ SE は文章作成が苦手 ・・・ 文章を書くのに苦労した経験はありますか・・・ IT 業界を含め､ﾋﾞｼﾞﾈｽ現場では､議事録や報告書など､多種多彩なﾄﾞｷｭﾒﾝﾄを書く必要に迫られる。 ﾄﾞｷｭﾒﾝﾄは､人と人のｺﾐｭﾆｹｰﾆﾝﾖﾝ手段の基本｡ SE もﾋﾞｼﾞﾈｽ人として最低限の文書作成ｽｷﾙが必須。 会話と異なり､ﾄﾞｷｭﾒﾝﾄは､紙や電子ﾌｧｲﾙとして残る｡ 電子ﾒｰﾙを介して多くの人に配信され､一つの ﾄﾞｷｭﾒﾝﾄが､個人･組織に多大な影響を与える。設計の上流工程の成果をﾄﾞｷｭﾒﾝﾄに整理し後工程へ渡す。 そのﾄﾞｷｭﾒﾝﾄ品質が低ければ､後工程の作業､ｼｽﾃﾑの品質に大きな影響を与える。 SE にとって､文章作成ｽｷﾙは､基本的･最重要ｽｷﾙである。 文章力は､論理的な思考力や読者視点に立つ共感力など､根本的な部分に問題があることが多い。 ◆ 文章には機能がある 小説やｴｯｾｲは､読者を感動させることが主題だが､ﾋﾞｼﾞﾈｽ文章は､次の機能特性を持っている。 ・正確性： 収集した情報をいかに整理し正確に表現するかということ。 ・伝達性： さまざまな読者に対し､自分の考えや意見が伝わるかということ。 ・納得性： それが読者の晰に落ちて、次の行動につなげることができるかを指す。 これらの機能が不足すると､文章の内容が事実と異なる､また曖昧だと､読み手に間違った認識を与える。 内容が正確でも､文章表現が不適切でわかりにくければ、書き手の主張が読み手に伝わらない。筋の通った 理屈で裏付けられた主張でないと､意図したように読み手を動かすこともできない。 ﾋﾞｼﾞﾈｽで作成するﾄﾞｷｭﾒﾝﾄの目的は､それによって相手に行動を起こさせることにある。 * 提案書 >>顧客からの発注行為 要件定義書 >>ｼｽﾃﾑ化用件の明確化 技巧的な表現に走ることなく客観的かつ正確に記述し､情報提供者の意図を明快に伝え､目的達成へ向け 読み手を説得していく文章が必要となる。 文章の骨格形成､展開方法､表現のｽｷﾙ修得が必須である。 ﾋﾞｼﾞﾈｽでは、ｺﾐｭﾆｹｰｼｮﾝの手段の道具として､文章を使いこなす能力が位置付けられる。 ◆日本語は難しい 数ある世界の言語の中でも日本語は特に難しい。表現や文法面で､日本語は外国語にない特徴がある。 ・ひらがなとカタカナ､漢字（音読み・訓読み）の３種類の言葉を使う： 英語はｱﾙﾌｧﾍﾞｯﾄ:４８字､中国語は漢字のみ（戦後の文字改革後の簡体字と､昔の画数の多い繁体字の２種類） ・同じ物事や動作を表す語彙の数が多い： 「何かを口頭で伝えること」の語条例:言う、話す、語る、しやべる、述べる、触れる、弁じる、説明する、 解説する、口にする、いわく・・・ 我々は、状況や相手との関係などで微妙によって使い分ける。 ・である調､ですます調など､多様な文体を使い分け､相手との関係で敬語の種数も多い。 文体は､公文書に使う硬い印象の「である調」と､口語的で柔らかい印象の「ですます調」の２種類がある。 会話文や箇条書きの部分を除き､文章ごとに使い分け･統一する。敬語は､聞き手を敬う尊敬語､へりくだって 敬意を表す謙譲語､丁寧語の３種類がある。よく使う言葉に､｢貴社｣「御社」･「弊社」｢当社｣がある。 また、これに合わせ､「送付させていただきます」 のように、動詞も変化するのが特徴です。 表現や文法の特徴に加え､日本人の文化的な背景(自己主張や明言を避け､曖昧にする)がある。謙虚を美徳と する日本では､自己主張は嫌われ､組織内で角を立てず丸く収める心理が働きやすく､その心理が､文章を 曖昧な表現にする。「基本的には・・」を頭に付け断定を避け､「おそらく」「ほぼ」のぼかし言葉を使う人が多い。 ぼかし言葉を削除すると､論理が明快になり､誤解が生じない例が数多くある。 「日本語は曖昧で論理的でない」という俗説もあるが､日頃使う言葉自体が非論理的なわけでない。 日本語は､使い方で､論理的にも非論理的にもなる。要は、日本語を使う人の思考そのものが問われる。 1 ◆ ｼｽﾃﾑ開発は伝言ｹﾞｰﾑ 伝言ｹﾞｰﾑは､7∼8 人が一列になり先頭の人に紙に書いた要件を見せ､順に内容を小声で､次々と伝える。 実際にやると､情報が伝達する過程で､抜け落ちたり変形したりする。はじめの要件とかけ離れた結果となる。 これと同じことがｼｽﾃﾑ開発で頻繁に発生する。 ① 顧 客 ﾌﾟﾛｼﾞｪｸﾄに予算をつけｼｽﾃﾑを開発する組織や人。ｲﾝﾃｸﾞﾚｰﾀからみれば､ﾕｰｻﾞ企業のｼｽﾃﾑ部門。 ﾕｰｻﾞのｼｽﾃﾑ部門からみれば､社内でｼｽﾃﾑを導入する部門。広義には､「顧客の顧客」も含む｡ 「予算元」は､少ない予算と短い開発期間で､最大のｼｽﾃﾑ効果を享受したいニーズがある。 ② ﾕｰｻﾞ ｼｽﾃﾑが提供する画面や機能を実際に使う組織や人。現状サービス内容に不満を感じてる場合が多い。 レスボンスが悪い､ﾃﾞｰﾀ入力の作業負荷が高い､最新の納期情報が見えない ・・・ 「業務の現場」の問題が多い。そこでは、現在抱える業務の問題を解決したいというニーズがある。 ③ 営 業 ｼｽﾃﾑｲﾝﾃｸﾞﾚｰﾀに属し､顧客窓口となって､ｼｽﾃﾑの開発案件を受注するために活動する組織や人。 業界の動向や､IT の市場動向にも精通する。IT 製品の情報提供やｼｽﾃﾑ提案、クレーム受付も担当。 顧客満足を高め､最大ﾌﾟﾛｼﾞｪｸﾄために顧客とﾌﾟﾛｼﾞｪｸﾄの問を調整するコーディネータ役も担う。 ④ ﾌﾟﾛｼﾞｪクトﾏﾈｰｼﾞｬｰ ｼｽﾃﾑｲﾝﾃｸﾞﾚｰﾀやﾕｰｻﾞ企業のｼｽﾃﾑ部門で、開発の実行貴任を負う人。 ﾌﾟﾛｼﾞｪｸﾄを計画し､ ﾌﾟﾛｼﾞｪｸﾄﾒﾝﾊﾞｰ(ｼｽﾃﾑｴﾝｼﾞﾆｱ､ﾌﾟﾛｸﾞﾗﾏ・・・ )に仕事を割り当て､ｼｽﾃﾑ設計･製造･テストを推進する。 ｼｽﾃﾑ開発を成功に導くため､与えられた予算と期間で､進捗､コスト､品質を管理する役割を担う。 ⑤ ＳE ﾕｰｻﾞの要求内容を分析し､業務課題を解決するｼｽﾃﾑを設計する。SE は、要件定義から基本設計に いたるまで、上流工程の作業を一貫して担当。また、IT に関する技術的な視点からﾕｰｻﾞ要求を調整する。 現在の技術では実現不可能な要求を排除して、新しい技術によって可能となるやり方を提案する。 ⑥ ﾌﾟﾛｸﾞﾗﾏ SE が設計した内容に基づき詳細設計してﾌﾟﾛｸﾞﾗﾑﾗﾑﾗﾑを製造(ｺｰﾃﾞｨﾝｸﾞ)する。最近は､開発部品が 高機能化し業務ﾊﾟｯｹｰｼﾞの適用も進み､手作り部分が少なく､上位 SE が自らｿﾌﾄｳｪｱ製造をする場合がある。 ⑦ テスター(試験員 品質管理者) テスターは、製造されたﾌﾟﾛｸﾞﾗﾑが、要求仕様どおりに動作しているかを検証する。多くの場合、ﾃｽﾄ手法 を理解したＳＥ自身が､仕様書の内容と照らし合わせ製造したﾌﾟﾛｸﾞﾗﾑ(ｺｰﾃﾞｨﾝｸﾞ)をﾃｽﾄする。 ｢ﾊﾞｸﾞをたたきだす｣と云うが､ｼｽﾃﾑ品質を上げるため､ﾃｽﾄ工程で潜在バグを無くすことが重要である。 ⑧ ｼｽﾃﾑ運用 ヘルプデスク 総合ﾃｽﾄを終えたｼｽﾃﾑは､移行作業で実稼動する。稼動は､ﾌﾟﾛｼﾞｪｸﾄのゴールだが､ﾕｰｻｰ部門に とっては新ｼｽﾃﾑのスタートになる。スムーズな業務運用のために､ﾌﾟﾛｼﾞｪｸﾄ側から運用サイドヘ､運用管理 機能やｼｽﾃﾑの操作ﾏﾆｭｱﾙなどを引き継ぐ。ｼｽﾃﾑ運用には､ｼｽﾃﾑ操作方法､ｵﾍﾟﾚｰｼｮﾝや動作監視・障害 時の復旧、ヘルプデスクは､ｼｽﾃﾑに関する問い合わせ対応や教育訓練を担当する。 ◆ ｼｽﾃﾑ開発の登場人物 ｿﾌﾄｳｪｱｼｽﾃﾑの開発に登場する人物の役割を、上工程から順に述べる。 1 人目 ：開発要求元の顧客企業のﾕｰｻﾞ担当者か､顧客企業にサービス要求する｢顧客の顧客｣に相当。 2∼3 人目：要求内容を吟味し予算を承認する顧客企業のｼｽﾃﾑ部門の管理者や経営層になる。 4∼6 人目：ｼｽﾃﾑ開発を請け負うｼｽﾃﾑｲﾝﾃｸﾞﾚｰﾀのﾌﾟﾛｼﾞｪクトﾏﾈｰｼﾞｬｰや SE になる。 7∼8 人目：ｼｽﾃﾑｲﾝﾃｸﾞﾚｰﾀやソフトハウスに所属しﾌﾟﾛｸﾞﾗﾑを作成するﾌﾟﾛｸﾞﾗﾏ になる。 9 人目以降：海外のﾌﾞﾘｯｼﾞＳＥやﾌﾟﾛｸﾞﾗﾏで､最終的にﾌﾟﾛｸﾞﾗﾑ作成する人が国内にいない場合もある。 伝言ｹﾞｰﾑは､伝える人が多い程､内容が変形したり漏れたりする。国内や海外企業を巻き込んだ多層的な ｼｽﾃﾑ開発環境では､当初の要求仕様を最終的なﾌﾟﾛｸﾞﾗﾑに「抜け漏れ変化なく」反映するのは至難である。 2 ◆ｼｽﾃﾑ開発では､ﾄﾞｷｭﾒﾝﾄが成功の鍵を握る ｿﾌﾄｳｪｱｼｽﾃﾑ開発は､関係者の間で、設計や検討に関わる情報が伝言ｹﾞｰﾑのように受け渡される。 これら情報をﾌﾟﾛｼﾞｪｸ内で共有するため､口頭報告･指示､会議開催、ﾄﾞｷｭﾒﾝﾄ配布､電子ﾒｰﾙなどの情報伝 達手段を使う。その中でﾄﾞｷｭﾒﾝﾄは、作成時間が掛かり､ｺﾐｭﾆｹｰｼｮﾝ効率が低いように見える。 しかし､構造化・共有･維持の三つの視点で重要な役割を果たしている。 ①構造化： 作成する過程で､考え方や前提条件が整理でき、伝える内容を構造化できる ②共 有 ： ﾕｰｻﾞや SE などの問で共通認識を持ち、認識のズレや漏れを防げる ③維 持 ： 記録に残るため、ｼｽﾃﾑの保守で変更の影響を分析したり、他ﾌﾟﾛｼﾞｪｸﾄで活用できる ﾄﾞｷｭﾒﾝﾄは､会議の場で配布され顧客に納品する公式ﾄﾞｷｭﾒﾝﾄと、内部検討用の非公式ﾄﾞｷｭﾒﾝﾄがある。 工程 計画､実行管理 設計 製造 ﾃｽﾄ･移行 運用 公式ﾄﾞｷｭﾒﾝﾄの例 スケジュール､ 体制表､ コスト管理表、ｺﾐｭﾆｹｰｼｮﾝ計面書､ ﾌﾟﾛｼﾞｪｸﾄ憲章､ ﾘｽｸ管理表、 変更管理票､レビュ記録票､ 進捗管理表､ 連絡票､ 議事録 要求定義書､ 機能設計書､画面致計書､アーキテクチ設計書､用語集､コード 定義書､ FRD､ データベース定義書､ ｼｽﾃﾑ構成図､ リソース見積表､ 共通部品 API 説明書､ 例外設計指針､ セキュリティ設計書 ﾌﾟﾛｸﾞﾗﾑ設計書､ テストデータ管理表､ 単体ﾃｽﾄ結果､ ﾊﾞｸﾞ管理表､ コーティング規約 テストシナリオ設計書､ ﾃｽﾄ仕様書､ 品質評価レポート､ 移行計画書､ 性能評価報告書 稼動報告書､ ﾄﾗﾌﾞﾙ報告書､ 操作ﾏﾆｭｱﾙ､ 運用管理ﾏﾆｭｱﾙ､ ﾌﾟﾛｸﾞﾗﾑ導入教育資料 公式ﾄﾞｷｭﾒﾝﾄは、完成したﾌﾟﾛｸﾞﾗﾑの処理前提や考え方を記述する。ﾕｰｻﾞ要件の変更や追加に対し､将来 にわたり維持運用する必要がある。顧客とのやり取りで、後で「言った、言わない」という事態を避けるため､連 絡票で相互確認する。ﾚﾋﾞｭｰｭｰ結果は､漏れないように記録票を作成する。 非公式ﾄﾞｷｭﾒﾝﾄには、設計･技 術課題の個別検討資料や､残件を管理する課題管理表、会議ﾒﾓもある。 * 「ﾄﾞｷｭﾒﾝﾄを作成したところで、動くｿﾌﾄｳｪｱは作れない」 ・・・と言う声をよく聞く。 もし､1 人で自己完結的に作成できるｿﾌﾄｳｪｱ規模で､低い捨てのｼｽﾃﾑならその通りかも知れない。 しかし、ﾋﾞｼﾞﾈｽで使うｼｽﾃﾑは、複数人チームで数ケ月をかけて開発していくものばかり。チームの SE は、ﾕｰ ｻﾞの要求仕様に同じ認識を持ち､整合のとれた要件定義を前提に、ｼｽﾃﾑを設計し製造へと渡す。テスター は、ﾕｰｻﾞの要件定義書からテストシナリオを作成して､動作確認を行う。ｼｽﾃﾑの完成後も、顧客の業務環境 に合わせて機能を追加･改編して維持する。ﾄﾞｷｭﾒﾝﾄは､儀式でも形式でもなく､本質的に不可欠なもの。 ﾄﾞｷｭﾒﾝﾄに起因するﾄﾗﾌﾞﾙには事欠かない。 『ｿﾌﾄｳｪｱ開発 201 の鉄則：AlanM.Davis』の原理 41 ・・・ 「今すぐ要求仕様書の誤りを直せ」 もし、要求仕様書に誤りがあれば、見つけるのが後になるほどとんでもなく高く付く もし、要求仕様書の誤りが設計まで残っていたら、それを見つけて修正するのに 5 倍コストがかかる もし、コーディングまで残っていたら、10 倍かかる もし、テステイングまで残っていたら、20 悟かかる もし、納入時点まで残っていたら、200 倍かかる 上流工程の作業は、ﾕｰｻﾞをヒアリングし、ﾄﾞｷｭﾒﾝﾄを作成しでﾚﾋﾞｭｰする仕事がほとんどである。 ドキュメントの品質が低ければ、ﾌﾟﾛｼﾞｪｸﾄに大きな影響を与えることを覚悟しなくてはいけない。 下流工程はオフショアが進んで、ﾄﾞｷｭﾒﾝﾄなしに開発を委託するのは困難。日本人でない相手に､正確に 要件を伝えることを意識しなければならない。 3 第 2 章 なぜ下手な文章ができるのか ◆ 下手な文章が持つ要素 読み手の立場から見たら・・・下手な文章とは ● ● ● ● ● 書き手の言いたいことが明確でなく、主張が伝わってこない 内容の構成や順序が整理されておらず、わかりにくい 主張を裏付ける情報がなく、論理的に納得できない 難しい用語が定義しないまま使われ、意味がわからない 長い文が続き､冗長､曖昧な言い回しが多く、読みにくい 読み手にとって｢伝わってこない｣｢解り難い｣｢納得できない｣｢読み難い｣･･ のが悪文である。 書き手の独りよがりな文章は､読み手を悩ませ･混乱させる｡ 出来が酷いと信頼を失う､誤解される。 す−と頭に入る文章は､何を(WHAT)､根拠(WHY)､表現(HOW) の要件が明快である。 １）目的のないﾄﾞｷｭﾒﾝﾄ： ・・・ ｢文章を書くこと｣は手段で目的ではない ｢読み手に何を伝えたい？｣｢どう動いてほしい？｣ ﾋﾞｼﾞﾈｽ文書には､必ず目的がある。 企画書や提案書は､意図を相手に伝え､具体的に行動してもらう目的。技術報告やﾄﾗﾌﾞﾙ報告は､仕事の 成果を伝え､仕事に役立ててもらうことが目的。 のﾄﾞｷｭﾒﾝﾄが多々ある。 ﾄﾞｷｭﾒﾝﾄ作成自体が目的になり､内容がない目的不在 小説､ｴｯｾｲなど文学作品とは異なる。 そもそも仕事の目的を考えていない 仕事の成果をまとめる段階で､ﾄﾞｷｭﾒﾝﾄを作成する。仕事の目的が明確でないと､ﾄﾞｷｭﾒﾝﾄもいい加減。 目的が設定されていない仕事に終わりはない｡ 結論のないﾄﾞｷｭﾒﾝﾄができあがる。 受け身の姿勢でﾄﾞｷｭﾒﾝﾄを作成している 上司の指示で､仕方なく受け身の姿勢で作成したﾄﾞｷｭﾒﾝﾄは､形式に始終し文章の主張に迫力がない。 受け身になる理由は､モチベーションの低下､知識不足､重要性の認識不足がある。 文章作成の技術が身についていない 目的意識をもって主体的に取り組んでも､文章作成力が低いと､正確･適切なﾄﾞｷｭﾒﾝﾄは作れない。 ﾄﾞｷｭﾒﾝﾄ構成の設計､適確に表現するｽｷﾙを身につける必要がある。 上司や顧客へのお願い。進捗報告は､遅れを正確に伝え､リカバリ策を提案し実行承認をもらう。 必要なら上司の支援を要請する。順調なら､自分のﾏﾈｼﾞﾒﾝﾄ能力を認めてもらう。 先ずは､『目的意識を持つ』、『最初に結論､言いたいことを定義する』。 そして文章を書き始める。 ２）読み手の視点がない： すべてのﾄﾞｷｭﾒﾝﾄは､それぞれに読み手が存在する ｼｽﾃﾑ開発の例では､ﾌﾟﾛｸﾞﾗﾑ設計書:ﾌﾟﾛｸﾞﾗﾏ､ﾌﾟﾛｼﾞｪｸﾄ進捗報告書：顧客、操作ﾏﾆｭｱﾙ:ﾕ-ｻﾞなど､読み手側の立場で､読みたくなる文書に仕上げることが鉄則。 ﾄﾞｷｭﾒﾝﾄの種類により読者は異なる [自分だけが読む私的なもの] 日記はごく個人的｡読まれることを想定しない。備忘録､ﾒﾓ､ﾉｰﾄも同じ。 [特定の人向けで私的なもの] 友人や親など、特定の人に対して書かれる手紙の類。 [特定の人向けで公的なもの] ﾌﾟﾛｼﾞｪｸﾄﾒﾝﾊﾞｰ､上司、顧客の特定な人向けに公式に作成する。 進捗報告書､設計書、ﾚﾋﾞｭｰｭｰ記録票など、ｼｽﾃﾑ開発で作成するﾄﾞｷｭﾒﾝﾄはすべてこの範囲。 [不特定多数の他人(公開する)] 誰に読まれるかが想定できない。 研究論文や新聞・雑誌の記事など。 ﾌﾟﾛｸﾞ日記は個人的な情報だが､ネット利用者の不特定多数に読まれることを想定する。 特定の人に手紙を書く場合､相手を思い浮かべて書く。ごく自然に内容も相手に合わせている。 会社･組織の公人が相手の場合は､読み手の特性を理解し､納得させる展開や記述が必須。 読み手の視点を忘れている例が見受けられる [顧客経営層が読み手の提案書] 現場の課題解決のみ記述し､収益・経営的ﾒﾘｯﾄの説明がない。 [当該業務を初めて担当ＳＥ向けの要件定義書] 業務の専門用語を解説していない。 [顧客責任者が読み手の障害報告] 被害を受けた心情を無視し､障害･対策のみを淡々と述べる。 読み手の視点がないと､相手の興味をひかない。内容の理解を阻害し､相手は目的行動へ移らない。 相手のｲﾒｰｼﾞを頭に画き､『誰が何のために読むのか』を強く意識して書くことが重要。 4 ３）論理的でない： ・・・ 事実や根拠を論理的に文章で表現する ﾄﾞｷｭﾒﾝﾄは､結論･主張が必ずある。それを裏付ける事実が､読み手を納得させ動かすことになる。 結論や主張が正しいことを示す事実や､根拠を文章に記述することが必ず必要。 [ﾄﾗﾌﾞﾙ報告書] 対策が原因解決に有効なことを筋道立てて説明する。 [提案書 ] 提案内容が顧客の課題に応えていることを証明する。 論理的な筋道を通す必要がある。 論理性は説得力つながる。 論理的でない文章のパターンを示す。 論証なしに展開する ・・・「論理の飛躍」 読み手は「なぜ」？疑問が生まれる。 例示：｢ｵﾌﾞｼﾞｪｸﾄ指向は､携帯電話など､組込み系ｼｽﾃﾑの開発で普及している｣ ｢したがって､ｵﾌﾞｼﾞｪｸﾄ指向開発は､大規模な業務系ｼｽﾃﾑでは成功しない」 行間の論理が飛んでいる。大規模な業務系ｼｽﾃﾑの開発で成功しない理由が無い。 失敗事例､技術的な実現性､体制･ｽｷﾙ確保の課題に対し､事実の裏づけや論理的な根拠が必須。 前提が明らかでない ・・・読み手と前提の共有ができていない 前提の記述が曖昧で､明文化を省くことがある。 先の例では､『ｵﾌﾞｼﾞｪｸﾄ指向開発』とは何を指す？ ｢ｵﾌﾞｼﾞｪｸﾄ指向ﾌﾟﾛｸﾞﾗﾐﾝｸﾞ｣ｏｒ「ｵﾌﾞｼﾞｪｸﾄ指向設計からﾌﾟﾛｸﾞﾗﾐﾝｸﾞ」までの範囲の何れ。 前提の定義で結論への道筋が異なる。読み手の解釈に任せるのでなく､文章で正確に伝える。 反論に応えていない ・・・物事には良い面・悪い面が必ずある 例示：「要求仕様書の誤りが残っていたら、それを見つけて修正するのに 5 倍コストがかかる」 「したがって、要求定義書の誤りは､設計まで残してはいけない」 「しかし､全ての誤りを排除するのは人間が作業する以上、不可能である」 「そのため、早い段階で要求定義書をﾚﾋﾞｭｰｭｰし、誤りを検出しなければならない」 要求仕様書の誤りがｼｽﾃﾑ開発全体に大きな影響を与えるのは、経験値的に納得が得られる。 「残さない」というだけでは実現性が乏しく、「簡単にはできない」という反論がある。主張の論理性を一面で 確保しても､他面で反論が必ずある。主張に対し､予測される反論に応える論理を展開する必要がある。 ４） 読みづらい： ・・・読みつらければ、台無し 目的が明確で読み手の視点にたって論理的に展開しても､読み難いと、頭に入らない。 骨格がない 小学生が書く作文のように、思いつくまま文章を書くスタイルでは､まとまりのない内容になる。 文章には型がある。「起・承・転・結」や「序論・本論・結論」などの型を学び､活用する。 長文が多い 一つの投落が長く､だらだらの長文は、一度読んでも頭に入らない。心理学者(ﾐﾗｰ)の論文:『不思議な 数 7±2』で､人間の短期記憶の情報量は『7』が限度とある。長文になればなるほど、短期記憶の原理 に反して理解が難しい。 したがって、文はできるだけ短く簡潔にまとめる。 あいまいな表現が多い 文章を書くとき､反対意見を恐れ､「基本的に∼」として例外を後で認められる逃げをうって､曖昧言葉 を使う。知識不足で自信がなく､断言を避ける心理が働き「おそらく」「らしい」｢だろう」「∼かもしれない」 の言い回しになる。曖昧表現を多用すると,読み手に正確に伝わらない。行動に移してもらえない。 このほかの読み難いパターンに､漢字が多すぎる場合がある。接続詞が欠け関連が解り難い。 用語の定義が固定していない。 紙に印刷した文字ｻｲｽﾞが小さく読めない。 多くの要素がある。 いくら内容が良くても、表現が悪ければ伝わりません。 表現の技術を身につける必要があります。 5 第 3 章 文章術の基本原則 良い文章には、目的と読者設定の明確化、納得させる論理性や､わかりやすい表現が必要。 文草術として、文章の骨格や論理性の確保、表現方法の基本原則がある。 ◆ 文章の骨格 順序を考えず思いつくまま作文したら､纏りのない文章になる。 文章は､骨格･構成に順序､型がある。 「起・承・転・結」の 4 部構成 ・・・ 漢詩の典型的な構成､小学校の作文教育で必修 「起」は、自分の主張･意見を述べ問題提起する。「承」は､主張･意見の裏付け事実や根拠を述べ論証する。 ｢転｣は､異なる論点を引き出し予測される反論を検証する。「結」は､ﾃｰﾏを結論づけ､今後の課題を述べる。 *「承」=｢証｣：意見の論理的な証明 「転」=｢展｣：他方の反論を取り上げ､論旨に広がりをもたせる 「起・承・転･結」構成は、主張を基に分析し展開する研究論文や技術報告書に向いている。しかし､「転」 で論点を変え過ぎると論点が解り難くなり、「結」にいくまでに遠回りになる恐れもある。ﾋﾞｼﾞﾈｽでは、より簡潔 な 「序論・本論・結論」 の型も活用する必要がある。 「序論・本論・結論」の 3 部構成 ・・･古来の能楽や舞楽の典型的構成「序破急」の型 「序論」で､問題提起する。 「本論」で､意見やその根拠を述べる。「結論」で､纏め､今後の課題を述べる。 この形式は、情報処理技術者試験でも出題される型で、技術文書の基本になる。 「序論・本論・結論」の型は､課題を分析して､解決策に展開し､評価する流れで､平易・素直な文章である。 最近の事例では､IT 製品や技術の調査報告書､問題解決報告書に向いている。 「結論・理由」の 2 部構成 まず冒頭でズパリと結論を述べる。続けて､根拠を展開する。忙しい現代に相応しい型です。 * ｢ｴﾚﾍﾞｰﾀｰ･ﾌﾞﾘｰﾌｨﾝｸﾞ｣：いっしょにｴﾚﾍﾞｰﾀｰに乗り込んで到着する間(30 秒)で説明する。 「起・承・転・結」で経緯を長々と説明したら、最後の「結」にたどり着くことができない。 ﾄﾞｷｭﾒﾝﾄも同じ。 読み手は、最初に書かれていることにより、その文章全体が読むべき価値があるかどうかを判断したい。 最後まで根気よく読んで､はじめて結論がわかるのでは歓迎されない。 「結論・理由」の型は、最初に結論を示して魅力を感じさせる提案書、進捗サマリを報告する進捗報告書、 解決の方向性や見通しから始める課題検討書など、多くのビジネスドキュメントに向いています。 ◆ 納得させる論証 読み手に､ﾄﾞｷｭﾒﾝﾄの結論や主張の妥当性を､事実や根拠を示し証明して納得させるために論証がいる。 論理的な文章作成に重要な考え方である。 論証方法にも、いくつかの方法がある。 前提と結論 「結論」は､書き手の主張や意見、「前提」は､その結論を理由づける根拠や事実。 読み手が結論を妥当であることを理解するために､誰もが納得する根拠･事実･例を前提で示す。 隠れた前提 論理佳を確保する､隠れた前提(自明の理)が沢山ある。広く一般に浸透している知識(常識)を前提がある。 ｢統計ﾃﾞｰﾀを基に論旨展開｣する場合は､ﾃﾞｰﾀが実態を正しく反映･信頼できることが前提になる。しかし､ 隠れた前提を全て網羅的に記述したら､冗長な読みにくい文章になる。読み手に受け入れられる範囲､ﾚﾍﾞ ﾙﾙに合せ､隠れた前提をあえて記述しない考慮が必要になる。 技術論文では､読み手の知識ﾚﾍﾞﾙﾙを 想定して､前提となる技術的な解説が必要となる。書き手は、文章に書かれた前提で違和感なく読み手に 伝わることを意識しなければならない。 演繹法 ｢演繹法｣は、前提から結論を導き出す推論の方法。「三段論法」として知られる。 『前提が正しいならば､結論も正しいのに違いない』 という論証になる。 ①人間はいつか死ぬ ②ソクラテスは人間である ①人間の作業にﾐｽは必ず起きる ②ｼｽﾃﾑは人間が開発する ③ソクラテスはいつか死ぬ ③ﾊﾞｸﾞの無いｼｽﾃﾑはない 演繹法では、正しい前提を順に深堀して､結論が 100％言い切れる形をとる。文章で説明するためには､ 結論の妥当性を証明する前提の全てを一つずつ示すことになり､長い道程の難解な文章になってしまう。 そこで、文章作成では、効率的に結論を導く方法として帰納法も利用される。 6 帰納法 「帰納法」は、さまざまな事例から共通性や類似性を見極め、普遍的な規別を導く推論方法。 『前提が真なら､結論も真にちがいない』となる。帰納法は､前提が真でも結論が真になるとはかぎらない。 世の全ての例を調べるのが不可能な場合､一部の事例をもとになんらか規則や結論を導く方法である。 つまり、言い替えると「演繹法は、結論を 100％言い切れる帰納法」である。 ① 統計によれば、90％以上の企業がﾌﾟﾛｼﾞｪクトﾏﾈｰｼﾞｬｰの不足を示している ② 一部の企業では、ﾌﾟﾛｼﾞｪクトﾏﾈｰｼﾞｬｰの上級人材を役員待遇にしている ③ ﾌﾟﾛｼﾞｪクトﾏﾈｰｼﾞｬｰは重要な人材として位置づけられている 帰納法では、正確な事例から推論した結果として結論を出す。100％と言い切れないにしろ、読み手に対 し効率的に納得感をもたらす。文章作成では､効率的に結論を出す帰納法が有効である。ただし、一人よ がりで独善的にならないように､結論の可能性を高める事実の積上げが必要になる。また､場合によっては 結論を控えめに言い換えた､調整する配慮がいる。 具体例の提示 「IT ｽｷﾙ」や「技術力」など､文中の言葉が抽象的だと､読み手の解釈が広がり､理解の仕方も異なる。 正確に情報を伝え理解を促すために､具体例の提示が重要になる。 「∼の」「∼など」で補足する方法と、 帰納法で説明したように実例をあげる方法がある。 ① アマゾンは､アフィリエイト(成果報酬型)ﾌﾟﾛｸﾞﾗﾑを活用して急成長した ② 楽天も、ｱﾌｨﾘｴｲﾄﾌﾟﾛｸﾞﾗﾑを活用して成功をおさめた ③ ネット専業企業の成功は､ｱﾌｨﾘｴｲﾄﾌﾟﾛｸﾞﾗﾑを､いかにﾋﾞｼﾞﾈｽﾓﾃﾞﾙに組入れるかがﾎﾟｲﾝﾄである この例では、事例をもとに共通要素を一般化し主張に展開している。誰もが知っている事例であれば､ 主張は受け入れられる。よく知られている事例､複数の適切な事例を根拠にするのが効果的。 比喩の活用 複雑な概念や問題の説明に､似たものや身近なものに置き換えると､わかりやすくなる。 『複数のものが共通の性質 A を持つことから、別の性質 B も共通に持つはず』という推論です。 類推は､多数の事例でなくただ一つのものの性質から､別のものの性質を察するところに特徴がある。 *『狼人間を魔法のようにしずめる銀の弾は､ｿﾌﾄｳｪｱ開発では存在しない。つまり､ｿﾌﾄｳｪｱの生産性を 飛躍的に向上させる特効薬はない』 ・・・ [銀の弾は存在しない]：IT 業界の有名な比喩:ブルックス *「温故知新」「先んずれば人を制す」「井の中の蛙」･･･ 中国故事から 的確な類推には､取り上げる比喩が主題に類似している必要がある。ｲﾒｰｼﾞが伝わり易く､印象づける働 きがある。 多用しないで､しっかり主張したい箇所に限定して使うのが効果的になる。 反対意見への反論 ものごとには､裏と表があるように､前提から導かれた結論が､唯一絶対に正しいということはない。 反対意見を否定して主張を通すだけでなく､反対意見を想定して､論理展開を補強する方法もある。 * 環境や人命に影響する制御ｿﾌﾄｳｪｱを除き､ｿﾌﾄｳｪｱは､60％程度のﾃｽﾄｶﾊﾞﾚｯｼﾞ(ﾃｽﾄの網羅率) で出荷されているのが現状だ。 このｶﾊﾞﾚｯｼﾞ率を上げることが品質の向上につながる。 * 但し､ｶﾊﾞﾚｰｼﾞ率をやみくもに上げるのは得策でない。ﾃｽﾄ作業の費用は総開発量の 50％を占める。 ﾃｽﾄ費用は､ｶﾊﾞﾚｰｼﾞ率を 100％に近づけると､指数関数的に増大してしまう。 ｶﾊﾞｰしてない範囲の調査､ﾘｽｸの評価､追加ﾃｽﾄｹｰｽの検討 も重要である。 * ｶﾊﾞﾚｯｼﾞ 100％でも､ｼｽﾃﾑは完璧ではない。数字は､作成するﾌﾟﾛｸﾞﾗﾑに対するﾃｽﾄの網羅率である。 ﾌﾟﾛｸﾞﾗﾑ仕様が間違っていたり不足している場合もある｡ 従って､早い段階の仕様ﾚﾋﾞｭｰが欠かせない。 文章を作成するとき､反対意見も想定し､反論ロジックを展開しておく必要がある。 提案書では､想定される反対意見は？それで十分か？現実的に実現できるか？そのために失うものは？ 代案は？・・・という視点がある。 「内なる批評家」を､最人限に発揮させてみることです。しかし､反対意見 の反論を展開し過ぎると､本論が見えなくなり､伝わり難くなる。主旨から脱線しないよう注意が肝要である。 7 用語に敏感になる 文章を書く側と読む側で受け取り方が同じになるように､使う用語は正確､敏感､一意でなくてはならない。 IT 業界では、３文字略語をはじめ、カタカナ用語がたくさんある。 このようなキーワードは業界紙､書籍に頻繁に登場するため､聞いた瞬間に誰もが解った気になる。 しかし､ 思考が停止に陥り､曖昧なまま読み進むことになる。多くの用語が概念的で､実体はいかように理解される。 * SCM 広義：自社を中心に供給元(原料､部品ﾒｰｶ)から販売先の流通･顧客まで包括的な概念 狭義：出荷から販売先のみを対象にする [Supply Chain Management] SCM をどの範囲でとらえているのか、用語の定義をはっきりしなければならない。自分の常識が､相手の常識 と同じかは保証されていない。 ・用語に対する自分の常識をあえて疑ってみる ・知っている用語は他人に正確に説明できる知識ﾚﾍﾞﾙにする ・重要な用語は、最初に定義する ・意味が固定的でない用語は使うのを避けるか、言い換えるか、補足する 読み手を混乱させないため、一つの用語を定義したら､始終徹底して一つの意味で使う。 「川‥論集を作る感覚」で望むことが亜袈です n なぜなら、一環した用語の位用が、文章全体の論理的な 整合件の確保につながっていくからです。 8 ◆心理的な作用 「言葉遣いは人格を表す」 文章には､書き手の自信や姿勢が表れる。曖昧な表現が多いと､根拠が 弱いか知識不足で自信がないと思われる。受動態が多いと､書き手の姿勢が受け身に見えても仕方ない。 読み手の心理的な作用を考慮した表現法に充分注意を払う必要がある。 曖昧さの排除 日本人は､周りに気をつかう国民性から､明言を避け曖昧な表現を多用する。日本式の美徳でもあるが､ 論理的な文章を書くのに障害になる。曖昧さを排除する方法を示す。 ① ぼかし言葉を避ける ぼかし言葉は､和を乱さないために自己主張を抑えようとする曖昧な表現。口語で､「とか」「みたいな」 「∼的には」をよく使うが､文章には必要ない。ぼかし言菓は、断言を避ける心理が働いた場合に登場し、 書き手が自分の知識に自信がない､根拠が不明確なことが背景にある。読み手の主観に任せるより､ 主張を明確に断言して､内容をハッキリと読み手に伝える事が重要です。 それでも、「おそらく」「ほぼ」「ような」「ぐらい」「らしい」といったぼかし言葉を使う場合は､本当に必要かを 自問し､できれば定量化してみることが肝要です。 ② 接続詞に注意する 文章では、文と文とをつなぐ接続詞が論理展開を担う。 「したがつて」＝結論 「しかし」＝否定 「なぜなら」＝理由 「つまり」＝総括 「ただし」＝補足 主張の流れが変わらなければ､文と文の間に接続詞がなくても､読み手に違和感はない。しかし､主張が 大きく変わるとき､強調したい場合は､読み手に論旨構造を明確にするため､接続詞をきちんと入れる。 文と文をつなぐ接続詞【が】は､使い方に注意を要す。本来の否定の意味で使う場合と､単に意味を繋ぐ 意味がある。誤解を避けるために､【が】で文節を切り､２つの文のすることで明解にする。 ｅｘ：△ 「当ｼｽﾃﾑは立ち上げ後から 3 年たっているが､まだ大きなトラプルはない」 ○ 「当ｼｽﾃﾑは立ち上げ後から 3 年たっている。まだ大きなトラプルはない」 ③指示代名詞の使い方に注意する 指示代名詞：「これ」「その」「どこ」「こんな」｢といった」は、前に出てきた言葉を引川する。 もし、遠いところにあるものを指していれば、何を意味するかがわからず、読み手の理解に負担が掛かる。 したがって、使う場は、できるだけ元の言葉の近くで､明解なことが重要です。 受動態よりも能動態 受動態：「∼される」「∼と思われる」は、論文やﾄﾗﾌﾞﾙ報告によく使っている。受動態は、本来の受身 以外に､対象を客観的に観察している姿勢として表れる。読み手は､動作主体が解らず曖昧に感じる。 主体性がなく､無責任な感じがする。したがって、受動態でなく､できるだけ能動態を使うべき。 ｅｘ：△ 「A ｼｽﾃﾑの開発ﾌﾟﾛｼﾞｪｸﾄでは、新しい開発プロセスが導人される」 ○ 「A ｼｽﾃﾑの開発ﾌﾟﾛｼﾞｪｸﾄでは、標準化グループが新しい開発プロセスを導人する」 能動態にすると､主語の追加が必要になり､だれが主体なのか､責任の所在が明確になる。 また、書き手が主体的に主張しているような､力強く､良い印象を読み手に与える 否定形よりも肯定形 否定形：「∼できない」「∼しない」は、文書全体がﾈｶﾞﾃｨﾌﾞなｲﾒｰｼﾞになる。 とくに提案書では､書き手の 姿勢が問われる。ﾎﾟｼﾞﾃｨﾌﾞな姿勢を伝えるためには､条件をつけて肯定形にする。 「この機能は提供できない」 「セキュリティは確保できない」 ＞ ＞ 「∼すれば、この機稚は提供できる」 「∼することで､セキュリティは確保できる」 全否定と部分否定の取り違いが起きやすく意味が曖昧になる。「問題を全部解決するのは難しい」 「解決できる問題は小郡のみである」 ｏｒ 「問過の一部は解決できるが全ては解決できない」 二重否定は、もったいぶった間接的な表現で奥深さを感じるが､ﾋﾞｼﾞﾈｽ文書では煩わしい。 「ないはずはない」 「できないことはない」 「解決できない問題は一つもなかった」 ＞ ＞ ＞ 「ある」 「できる」 「全ての問返を解決できた」 9 ◆ わかりやすい文章構造 わかりやすい文書は､筋道立てた前提や結論を展開する。さらに､文章の構造も工夫が必要になる。 一文一意 文章は複数の文で構成する。一文に多くの情報を詰め込むと、読み難く何が云いたいのか解りに難い。 ・主語に着目して、一文に一つになるように短文にする ・同じ言い回しを繰り返さない ・行動目的と、行動内容で文を分ける 箇条書きの規則 箇条書きは､重要なことを解り易く纏めるのに有効。何らかの規則性を持たせるとより明解にできる。 ① 数 お勧めは【3】。重要なもの 3 点に絞る。 三極､三位一体、など 3 つは安定的な数字。 段階的にあげる場合は【５】。ﾓﾁﾍﾞｰｼｮﾝ理論：ﾏｽﾞﾛｰ段階説。 多くても【７か条】が良い。 ② 順列 箇条書きの順序の意味付けが、読み手の理解を助けます。 ・重要度（影響度） ・時系列（発生帽） ・内外 ・既存から新規 ・原則から例外 ：対策や原因の重要順 ：ﾄﾗﾌﾞﾙの発生や対策の実行順 ：内部のｼｽﾃﾑから外部へ、外部環境から分析し内部環境の分析へ ：既存ｼｽﾃﾑから新規システムヘ、既知の事実から新しい事実へ ：原則的なケースから例外的なケースへ ◆ 読み易い表現 一読して「すーっ」と頭に入る文章を書くためには、これまで説明してきた文章の骨格や論理性だけでなく､ 適切な表現も必要です。 よく見られる冗長な具体例の､読みやすい文章表現のﾎﾟｲﾝﾄを示す。 冗長性の排除 「文章は簡潔なほど良い」 頭ではわかっていても、コツを知らなければ冗長になりやすい。 ①｢∼行い｣言葉を避ける 動詞を重複して、丁寧な文章にすると(積もり・・)､くどくて､難解になる。 ｢操作を行います」 ｢試験を行う｣ ｢開発することができる」 ｢品質評価を実行する｣ ＞ ＞ ＞ ＞ 「操作します、する」 ｢試験する｣ 「開発できる」 ｢品質を評価する｣ ②誇張表現を定量化する 「大規模な」「非常に」「複雑な」 ・・・ 意図的な誇張表現を、論文や報告書によく使う。 読み手の主観で､いかようにも受け取り方が変化してしまう。誇張に関する修飾語を多用して､大きさ複雑さ を示すのでなく､事実を客観的、定量化して記述し内容そのもので正しく理解させる。 「大規模なｼｽﾃﾑ」 ＞ 「2000 人月程の∼」「500 万ステップ程の∼」 「都市銀行の勘定系ｼｽﾃﾑと同じ程度の ∼」 *読み手がｲﾒｰｼﾞし易い・・・ 表現の統一 文章全体を通じ､表現方法を統一する。 混在しやすい具体例を示す。 ・「及び」「又は」「例えば」といった接続詞を｢漢字｣にするのか｢ひらがな｣にするか ・「行なう」「行う」 の送り仮名はどちらにするか ・「1」「二」｢Ⅲ｣ を、漢数字にするのか英数字にするか ・「平成 19 年」「2007 年」 を、年号にするか西暦にするか 年/年度 の混在は､間違い ・「米国」「英国」、「アメリカ」「イギリス」のどちらにするか 「ら抜き言葉」：日本語の乱れであるが、使い方により、可能を示したり､尊敬､受け身の意味もある。 ・「見れる」「食べれる」・・・ 本来は、「見られる」「食べられる」 とするのが正しい日本語。 しかし、可能を表す場合には「ら」抜きの方がかえって効果的に使えるという見方もある。 いずれにしても、使用する場合は､どちらかに統一すべき。 10 文章の見た目 「外見よりも中身」と云うが､実際は、見た目の印象に左心される。アメリカの心理学者は､人の第一印象 は､言葉よりも見た目･表情･しぐさの影響が人きく､90％を超えることを報告している。文章の同じである。 漢字が多いと､硬い印象がある。漢字だらけだと文書の見た目が黒くなり、読み難い。 エンジニアには、 漢字を多く使ったほど格調の高い文書になると考える向きもあるが､それはひとりよがりに過ぎません。 読み手にとって読みやすい文章にするために､ひらがなで置き換えることも大事である。 「業務要件に対する理解」 ＞ 「業務要件への理解」 「曖昧性を排除する」 ＞ 「曖昧性をなくす」 「対象業務に存在する」 ＞ 「対象業務にでてくる」 「複数の解釈が可能な」 ＞ 「複数に解釈できる」 *接続詞(したがって､ところで､ために・・・)をできるだけ､ひらがなにするのも良い。 リズム感 人間は文字を目で追うとき、頭の中で言葉を読み上げる。リズム感が良い文章は､印象が心地よく､情報 が記憶に残りやすい。文章のリズム感は､短文化､句読点､文末の変化で決まる。 ①句読点を適切に入れる 古典には､｢、｣や｢。｣はない。 『井上ひさし』：句読点は漢文訓読の読解を助けるために始まった。 句読点が多いと、一見、読みやすく感じる。一方､理解力のある読み手は､ぶつ切れで読み難いと感じる。 読点は､読みやすくすることを意識して､意味が切れる箇所や一呼吸入れたい部分に的確に入れる。 ②文末に変化をつける 報告書で､「∼である」「∼である」「∼である」と同じ文末が何回も続く場合がある。単調でメリハリがなく、 リズム感が感じられない。読みやすい文章にはりズムが必要です。 *文学作品:「我輩は猫・・」の文末は「ある」「ない」「つかぬ」「いる」「みた」「そうだ」「である」とすべてが異なる。 ﾋﾞｼﾞﾈｽのﾄﾞｷｭﾒﾝﾄでも名文まででなくとも､参考にしたい。 リズム感を良くするためには、次の方法に取り組むと良いでしょう。 ・長文は適度に接続詞を入れて短文にする ・同じ文末が続く箇所に変化をつける ・書いた文章を音読して流れを確認する 11 第 4 章 ﾄﾞｷｭﾒﾝﾄの作成術 ◆設計 やみくもに書き進めても､良い成果は得られない。ﾄﾞｷｭﾒﾝﾄの要件をおさえて､読み手を納得させる。 報計図を描く 設計なしで物作りは不可能です。ﾄﾞｷｭﾒﾝﾄの作成も同じで、設計図のないﾄﾞｷｭﾒﾝﾄ作成は、いつまでた っても完成にメドが立たず、ストレスがたまるばかりです。大げさな設計図を作る必要はない。 『ﾄﾞｷｭﾒﾝﾄによって目的を達成するために盛り込むべきことはなにか』を突き詰め、何のためにどのように書 くかをおさえたプランが設計図です。矛盾がなく頭の中に描ければ、ﾄﾞｷｭﾒﾝﾄはできた半ば完成です。 そのために、次の要素を織り込む必要がある。 ・類型 ・目的 ・読者 ・目次 ・論理 ：提案書や議事録。要件定義書などのﾄﾞｷｭﾒﾝﾄの型 ：ﾄﾞｷｭﾒﾝﾄによって実現したいこと、主張や結論 ：ﾄﾞｷｭﾒﾝﾄが対象とする読み手 ：ﾄﾞｷｭﾒﾝﾄで展開するあらすじ ：主張や結論を裏づける事実や根拠 ﾄﾞｷｭﾒﾝﾄの類型 ﾄﾞｷｭﾒﾝﾄの類型は、読み手がひと目見て､それとわかる形です。 技術調査報告書：表紙にタイトル/報告者名/作成年月日/要約があり､本文/添付資料が続く。 会議議事録 ：見出しに部分に議題/日時/出席者､本文/議事内容や結論がある。 要件定義書 ：成果物の番号/作者/作成日/業務分類に続き､本体部分に要求内容/ 現状の課題や改善策などを記述する｡ ｼｽﾃﾑ開発で作成するﾄﾞｷｭﾒﾝﾄは組織活動として取り組む公式なものです。 所属する組織には､ﾄﾞｷｭﾒﾝﾄのﾌｫｰﾏｯﾄが定義され､サンプルが存在するはずです。 目的を決める ﾄﾞｷｭﾒﾝﾄ作成は､書くこと目的でない。読み手に意図を伝え､動機づけて行動してもらうことが目的です。 経営戦略の企画書(ｺﾝｻﾙﾀﾝﾄ立場)は､顧客経営陣が企画に納得し経営戦略を実行して目的は達成する。 出張･技術報告書は､単に説明するだけではなく､上司や同僚がその知見を仕事に役立てるのが目的。 ﾄﾞｷｭﾒﾝﾄには必ず目的があり､それを目指して回り道せずに最小限の努力で達成させるべき。 そのために､「何を書く・・」でなく、『なんのために書く・・』、ﾄﾞｷｭﾒﾝﾄの存在理由を意識する必要がある。 ・何のために書こうとしているのか ・これだけは伝えたいというメッセージは何か ・読み手に何をしてほしいのか ・読み手はどのように反応すると想定できるか ・読み手にとってどんなﾒﾘｯﾄがあるのか ﾄﾞｷｭﾒﾝﾄの目的 ﾄﾞｷｭﾒﾝﾄの主張､結論 ﾄﾞｷｭﾒﾝﾄの目的 日的にそった形で設定しなければ、目的に近づくことはできません。 経営戦略の提案書は､戦略の実行が現実的であり､取り組む効果が､読み手に伝わる必要がある。 業務効率化の要件定義書は､処理の自動化/操作性改善により､作業時間短縮/省力化を具体的な数値 で結論を示す必要がある。問題解決報告書は､問題を解決が出来たか否かが、最も重要な結論になる。 読み手にﾒﾘｯﾄがなければ、ﾄﾞｷｭﾒﾝﾄは読んでもらえない。 読み手を設定する ｢ﾄﾞｷｭﾒﾝﾄは､作者の目的を達成すること｣ ＝ 『読み手の期待にこたえること』 読み手は千差万別：（ﾚﾍﾞﾙﾙベル 関心･興味対象 利害関係 職位 ニーズも異なる。 ﾄﾞｷｭﾒﾝﾄを作成する際は、読み手を調べる（想定/設定/前提）努力が必要です。 ・読み手の知識やｽｷﾙのレベル ・読み手置かれた状況､持っている役割や権限 ・読み手の立場によって異なる関心や動機づけのポイント 「ﾃｰﾏの背景知識」：ﾄﾞｷｭﾒﾝﾄの必要性がどれほど理解されているのか？ 「ﾃｰﾏの前提知識」：業務､技術､製品にどの程度の知識があるのか？ 12 メインの読み手はだれか？ 組織で役割･権限はあるか？ ﾃｰﾏの背景知識はあるか？ ﾃｰﾏの前提知識はあるか？ 関心ごとは何か？ 専門分野や強みは何か？ 顧客企業の IT 部門責任者 IT 投資（2000 万円以下）の決裁権限あり 現場が抱える業務課題に精通せず､必要性を理解してない恐れあり 提案しているｿﾘｭｰｼｮﾝ｢ＥＲＰﾊﾟｯｹｰｼﾞ」についてやや知識不足 短期間でのｼｽﾃﾑ再構築 もともとは経理出身で財務【こ残い。ｼｽﾃﾑについては素人 ｅｘ： 読み手のプロフィール (在庫管理集務の改善提案の例） 読み手の琴線に触れるﾄﾞｷｭﾒﾝﾄ構成､論理展開にするため､読み手の関心事､専門分野を把握する。 読み手のレベルに合わせる わかりやすい文章を書ﾚﾍﾞﾙ､読み手の知識やｽｷﾙのレベルを意識することが重要。読み手により、 何を前提にするか､どこまで専門的に掘り下げるかが異なる。前提の前提まで､記述が必要な場合もある。 要件定義書の専門用語 ： ﾄﾞｷｭﾒﾝﾄ内で解説するか否か？ 業界の常識だから解説するか否か? ｼｽﾃﾑ設計書の技術用語： 基礎知識として解説をするか否か？ 専門性の高い人ほど、『わかりすぎてわからない』・・・・ わからない人の気持ちが理解でなくて省略する。 読み手の知識ﾚﾍﾞﾙﾙを設定したら、あえてもう一段、下の目線で書くのが良い。 自己を振り返る 『敵を知り己を知れば百戦危うからず』：読み手を知るだけでなく、自己を評価し振り返ることも重要。 無から有は生まれない。 作成するﾄﾞｷｭﾒﾝﾄを書くのに必要な情報は何か、自己にその知識があるか・・ 情報、知識が不足する場合は､謙虚に学ぶことを最優先すべきである。 ◆骨格と本文の作成 ﾄﾞｷｭﾒﾝﾄの骨格や本文を作るアプローチは､二つある。 アウトラインを描く 『目次先行型』：ﾄﾞｷｭﾒﾝﾄの目的にそった形で、アウトラインをまず描く。 ﾃｰﾏの内容を、概要から詳細/ 結論から理由/前提から意見、トップダウンに目次や見出しを展開する。ﾃｰﾏに関して､頭の整理ができて いると効率良く理想的にﾄﾞｷｭﾒﾝﾄが書ける。 しかし､目次の立案が進まない限り､本文を作成できない。 アイデアが出ない､情報が不足している、などで実践は難しいことが多いかもしれない。 とりあえず書き始める 『本文先行形』：まずは、書いてみる。 書いたことの一部が無駄になり､必ずしも効率的でない。 まずは悩まずに､一歩、書き出してみる。書くことで､内容をｲﾒｰｼﾞし､ﾄﾞｷｭﾒﾝﾄ全体構成を思考し、練る。 書くことで頭の中を整理できる。そう割り切って考え続け､自分で脳内対話することが大切です。 目次先行型と本文先行型を組み合わせる 『目次先行型』+『本文先行形』： 最初に立てた目次は、本文を書き出す前の時点の､仮説にすぎない。 本文を書き進め､目次の分類･順序が目的に合致するか､論理的に矛盾がないか、仮説を検証する。 軌道修正が必要なら､仮説の目次を調整する。仮説＞検証＞仮説＞検証 を繰り返しﾄﾞｷｭﾒﾝﾄを完成する。 最初は目次先行形で本文を書き進め、構成上の抜けや矛盾を発見したら､目次を見直していけば良い。 ・仮説として､目的にあった全体の目次を階層的に立てる ・最初に立てた目次に沿って､本文を書き進む ・本文を意味のあるかたまりに分け、抽象概念を抽出する ・抽象概念をもとに、目次を適宜、追加・修正し、全体の整合性を確認する ・新しい目次をもとに、さらに本文を見直して加筆する 13 自分に問いかける 目次の抽出・選定に悩むなら、論点を明確にするため､自分白身に質問を投げかけるのが有効。 ｅｘ： ｢品質改善策の検討書｣の事例 ･ｼｽﾃﾑの品質とは何か？現状はどんな？ ･品質が悪化した原因は何か？ ・対策による改善効果はどの程度？ ・なぜ？ 改善しなければならない？ ・どうやったら？改善できるか？ ・対策は具体的にどのように実行する？ これらの問いをもとに、目次に展開する。各章に盛り込む内容の構想をまとめる。 【品質の現状認識】：機能性や性能､保守性 ・・・、品質の中で､検討する品質項目を選ぶ。 現状ｼｽﾃﾑの現在の品質をできるだけ具体的に記述する。 【品質改善の必要性】：悪化している品質をなぜ改善しなければならないのか？なぜ、ﾕｰｻﾞの 変更要請に短期間に修正できていない？ 品質が与えるビジネスヘの影響をあげる。 【品質の悪化原因】：なぜ、品質が悪化した？ 長年にわたる保守でﾄﾞｷｭﾒﾝﾄとｿｰｽが不整合。 ﾃｽﾄが不足している。 これまでを振り返り、主な原因を考察する。 【品質の改善策】：原因をふまえ､ﾄﾞｷｭﾒﾝﾄとの突合せﾁｪｯｸ、ﾚﾋﾞｭｰの徹底､ﾃｽﾄ範囲の拡大 など 品質改善するための対策を立案する。 【改善策による効果】：対策の実施で､どの程度の改善効果が見込めるのかを予測する。 【改善策の実施計画】：対策を誰が何時から実施する？必要な予算？計画を整備？ 最初に目次を洗い出せないのは、書き始めの論点が不明確だから。 論点を出すためには・・・ 「それは何か」:WHAT 「なぜなのか」:WHY 「だからどうしたのか」:SO WHAT 「どうするのか」:HOW 自分自身に問いかけて目次を検討する。迷ったら、繰返し問いかを実践する。 多角的に理論を展開する 読み手に､結論や主張を納得してもらうために､論理的な裏づけが必要になる。提案する解決策が妥当 なことを文章で記述する必要がある。 演繹法：前提を置いて原因を論理的に突き止める。 帰納法：類似した改善事例を分析して効果的な対策を整理する。 論理的な抜けを防ぐため､反対意見を想定して反論を展開しておくことが有効です。 ・全ての原因を取り除く必要があるのか？ ・改善策は費用や期間で現実的なのか？ ・他に有効な対策は考えられないのか？ これらの反対意見に対する反論を展開し、主張の妥当快を多角的に証明すると､ﾄﾞｷｭﾒﾝﾄの論理的な厚み がぐんと増し、読み手の疑問を解決し､よりわかりやすい内容になる。反対意見を出すために､執筆者の立 場と異なる立場を想定して、それぞれの立場の視点で批判てみるのが有効です。 ・前提となっている事実や制約、必要性をあえで疑ってみる ・案の実現性やﾃﾞﾒﾘｯﾄ、副作用の視点から反対意見を想定する ・代替案を評価し、主張した案が他の案よりも優れていることを証明する 多角的に論理を展開するために､制約を取り払って考えたり､別の面から批判的に思考する必要がある。 14 ◆ チェックと見直し 本文を止じきあげた時占仰では、まだ、ﾄﾞｷｭﾒﾝﾄは完脱していませんり完成度を上げるために、詣罪緬と表 税面をチェックして、見直していく必妥があります。 推敲して整える 書きあげた時点では、ﾄﾞｷｭﾒﾝﾄにはたくさんの贅肉がついています。すなわち、伝えたい主張以外の情報 が付け加わったり、衣規が冗長になったりしているはザノです。 3 草四節で解説したように、災い文朽丁ほど、複数のメッセージが潜みます。また、「非常に」なピの誇鞋・衣 現や美辞艦句は、読み手の止確な理解を妨げてしまいます。 したがって、一眈、完成したと感じたならば、あえて何檻も、推甑することが大切ですゥその中で、過剰な表 現をそぎ遁川としたり、論理的な袈づけをさらに見直していきます。とくにチェックしたいのは次の点ですし ‥王張や練論は十分に伝わっているか ▼論理的な矛盾や抜けはないか ・用語の定義や使い方は首尾一質しているか ・曖昧な記述は言い切れないか ・読みにくい衣現はないか では、これらのポイントをピのようにチェックすれば良いのでしょうか。人間工学や人間心理などの組点から、 筆者は、次の三つの方法でﾄﾞｷｭﾒﾝﾄをチェックし修正するようにしています。 画面よりも紙で確認する 米国での実験結果によれば、一枝的に人が画面の情報を見るとき、耗よりも集中力 151 が落ちることがわか っています。おそらく、ディスプレイから出ている光線が眼の疲れに影響するからではないでしょうか「■また、 パソコンの両而は、検来したり作付するには便利ですが、深読みしたり全体を見回したりするには不便ですり とくに、ノー 15 トパソコンのような 12 インチ程度の場面ｻｲｽﾞの場合、見えている伯袖量が少ないだけに祝 野が狭窄的になる可能性もあります。したがって、ﾄﾞｷｭﾒﾝﾄは、紙に印刷し、全体を見て推敲していくべきで す。 声に出し山間いて確かめる 岡潔な短文や論理的な展開を示す接続詞、又末のリズム感など、文章の試みやすさを確認するためには、 声に出して沈むのが効架約です。人は文環を読むとき疏の小で読み上げていますが、声に出すことでさらに チェックが効きやすくなります。 時間を置いてから読む 一つの主鮎や柿論の出帆に鮭申していると、他のことまで気が同りませんっそれ□体は良いことなのですが、 多杓的な他山で見たいとき、思考が一方巾に仙っていては 新たな視山を思いつくことさえ錐 L くなるでしょう b したがって、▲晩鎚てから新鮮な…地で最初から通読す る。関係のない本を読んで気分転換してから読み返すといった取り紳みがおすすめです。 ゼロベースで書き直すこともいとわない チェックした紡果の停止はピのようにすれば良いのでしょうか。もちろん、既卜〃のﾄﾞｷｭﾒﾝﾄがありますから、 それを▲花に女付き血 L ていくのが、もっとも勅平的でしょう J しかし、人は一斑、決めたことを守ろうとする心 理が働きヤすくなっでい王す。したがつて、人改造が必姿な場合でも、同じﾄﾞｷｭﾒﾝﾄを九にすると、かえって 足かせにな h リ大きな愕正にまで柑み込めないものです。 そこで、論理的な流れがすっきりしないとか、構成を組み変えたいとき、別のﾊﾞｰｼﾞｮﾝを作って止じき碑すぐ らいの気持ちで耽り組むと良いでしょう亡 「元のﾄﾞｷｭﾒﾝﾄは、思考するためのプロセスだった」と割り切ること が大切です「労 15 第 5 章 ﾄﾞｷｭﾒﾝﾄ別必須ポイント これまで文章術の原則やﾄﾞｷｭﾒﾝﾄの作成プロセスについて解説してきました。 本章では、提案書や要求定義書など、ﾄﾞｷｭﾒﾝﾄ別に必須のポイントを解説します。 ◆ 提案書 情報ｼｽﾃﾑ分野では､提案書はｼｽﾃﾑ開発の仕事を受注するために欠かせない。しかし､顧客ニーズを 無祝し､自社に都合の良い内容で、見かけばかりに､こだわったものが多いのが現状である。 提案書は、仕事の前提を確認したうえで開発のスケジュールや費用を提示し､自社ならではの強みをアピー ルする役割がある。 その役割を意識して、提案書の構成を組み立てることが肝要です。 ５W1H３Ｃ をおさえる 顧客と直接やり取りするｿﾘﾕｰｼｮﾝ営業では、顧客のニーズが不明確な場合が多く、従来の足を使った｢御 用聞き営業｣や取扱う製品の説明と押し売りに徹する｢解説営業｣は､通用しないことが多い。 ＷＨＹ ＷＨＡＴ WHERE WHEN WHO HOW COST COMUPETITOR COMPANY 顧客ニーズが発生した背景や目的 顧客の要件､提案方針とその理由 対象とする業務やｼｽﾃﾑの範囲 提案内容を進めるスケジュール 顧客側･自社の体制と役割 開発作業の内容や開発手法、成果物 開発作業費や機器費などの費用 競争相手と差別化ポイント 自社の開発実績のアピール 表 3 提案書の構成 これに対しては、顧客の経営環境や IT の動向なピから顧客ニーズの仮説を立て、その解決手段として自 社の商品やサービスを提供する「仮説検証型営業」が有効です。まさに提案力が問われる状況にあり、提案 書はその結氷が凝縮されたものでなければなりません。そのためには、表 3 に示す 5WIH3C の視点でポイン トをおさえておく必要があります。 ・WHY ・WHAＴ ：提案の前提となる RFP（Request For Proposal）に沿って背景や目的を押さえる。 ：願客の要件を前提に提案方針を示す。 ｅｘ:業務改善のｺﾝｻﾙﾃｨﾝｸﾞ､新親ｼｽﾃﾑの構築､乗務ﾊﾟｯｹｰｼﾞを適用・・ など ・WHERE ：願客の業務や既存ｼｽﾃﾑとの関係、新規導入機器などの切り口で定義する。 ・WHEN ：要件定義や基本設計、ﾃｽﾄなどの工程を別にしたスケジュールを示す。 ・WHO ：自社だけではなく顧客倒の実行体制を示し諾任関係を明らかにする。 ・ＨOW ：具体的なﾀｽｸとｱｳﾄﾌﾟｯﾄの関係を整理する。 WBS（Work Breakdown structure）を活用する。 ・COST ：ｼｽﾃﾑの開発費用や機器の導入費用を提示。保守費用の目安を示す必要もある。 ・COMPETITOR：競合他社を意識した差別化ﾎﾟｲﾝﾄを提示する。 一社からのみの提案はまずない。 差別化ﾎﾟｲﾝﾄは､費用面の他､開発手法の特徴､品質管理体制などをｱﾋﾟｰﾙする。 ・COMPANY ：自社のｱﾋﾟｰﾙ。初めて仕事をする顧客の場合､自社の紹介が欠かせない。 提案内客に関連したﾃｰﾏの開発実績の一覧･事例を紹介する。 これら視点を網羅して､提案前提の確認をふまえ提案方針や作業内容､費用を提示し､他社との差別化 や自社をｱﾋﾟｰﾙする。 16 ◆ 結論から入って理由を示す 提案書は､文章の型『結論・理由』が活かせるﾄﾞｷｭﾒﾝﾄで、冒頭で読み手の関心を呼出し､後の展開に引 きずり込むことができる。逆に結論を後回しにすると､読み手に与える印象は薄く興味が持続しなくなる。 そのため､WHAT：最初に結論を明快に提示する。そして､なぜか理由を丁寧に説明していく流れにする。 結論が最後に登場する悪い例と､改訂した提案の事例を示す。 ｅｘ：提案方針：御社の RFP やﾋｱﾘﾝｸﾞを通じて､御社の現状の業務ﾌﾟﾛｾｽは属人が強く､標準化がされていないこと を認識しました。また､日本版 SOX 法への対応では､まず業務ﾌﾟﾛｾｽの可視化が求められます。一方で､御社の業種に おいて､ERP ﾊﾟｯｹｰｼﾞ適用による成功事例が増えている状況にあります。そこで、今回は次を提案方針といたします。 『ERP ﾊﾟｯｹｰｼﾞを導入し、これを活用して業務ﾌﾟﾛｾｽを再構築する』 この例では、顧客の状況から入って世の中の働向を示し、捉案方針へつなぐ流れとなつていますっこれでは 鮒論まで行くのに時間がかかってしまい、効率的にメッセージを伝えることはできませんじ次に、 伸正した例を示しますっ ｅｘ：提案方針： 御社の RFP やﾋｱﾘﾝｸﾞの u 柿架をふまえ、今回は次を州叱凝十〃針といた L ますノ「ERP ﾊﾟｯｹｰｼﾞ を将人し、これを柄用して柴務ﾌﾟﾛｾｽを再構築する」その理由は、次のとおりですり ・御社の現状の業務ﾌﾟﾛｾｽは購入性が敷く、標準化が必要であるじ ・日本牧 SOX 法への対応では、まず常務ﾌﾟﾛｾｽの叶祝化が求められる。 ・御朴イの≠火脚汀では、ERP ﾊﾟｯｹｰｼﾞ適用による成功瑞丁例が増えている C 愕正結釆のように結論から人って、読み手に 「なぜ？」と疑問を起こさせることが大切です。この例では、 「なぜ ERP なの？」 「なぜ再構築なのフ」という疑問が生じるでしょう仁その疑問に対して、l つずつ理山川を 示していくのです C そのことで、読み手の関心が継続することになりま寸 C 甥際の提案書では、この例のよ うにシンプルではないでしょうから、結論を滋初に持ってくるのはもっと効果的になるはずです。 17 ◆ 要求定義書 要求定義書は､ｼｽﾃﾑが実現しなければならない機能要件と､非機能要件を定義するﾄﾞｷｭﾒﾝﾄがある。 機能要件は､ｼｽﾃﾑ化の前提となる業務フロー､ｼｽﾃﾑで実現する入出力機能､管理ﾃﾞｰﾀの関係をまとめる。 非機能要件は､直接使う機能ではなく、ｼｽﾃﾑの信頼性､性能､可用性などの動作環境を定める。 要件定義は､ｼｽﾃﾑ構築の最上流にあり､ﾕｰｻﾞの承認を受けた後､要件定義書をもとにｼｽﾃﾑ設計が始まる。 要件定義書の品質が､開発ﾌﾟﾛｼﾞｪｸﾄ全体に大きな影響を及ぼす。モデル図や表、箇条書きを多用して､ わかりやすさと正確性を追求する必要がある。 なぜ必要なのかを明記する まず、現状のﾕｰｻﾞ業務を分析し、業務効率が悪い､納期に時間がかかる、などの課題を抽出する。 あるべき業務の姿を描き､解決策として新業務を支えるｼｽﾃﾑの要件を抽出する。ｼｽﾃﾑ要件は､ﾕｰｻﾞ業務の 課題解決につながり､全ての要件には、その存在理由があるはずです。 しかし、「要求定義書」という名前で､ひたすら紋切り型で要件定義するケースを多く見かる。各機能がﾕｰｻﾞ にとってどんな意味があるのかを意識しなければ、その必要性も理解できない。より良くする知恵もでない。 ・その機能はなぜ必要なのか？ そもそもの目的は何か？ ・その機能は、だれがどのタイミングで必要としているのか？ ・その機能を実現できないとすると､どんな不都合が生じるか？ 曖昧さを排除する 要件定義書に曖昧な箇所が残っていると､ｼｽﾃﾑ設計で要件を正確に反映できない。 要件定義書の曖昧 さは、最終的にｼｽﾃﾑのﾊﾞｸﾞや手戻りの原因になる。曖昧さを排除し正確にするチェック点を示す。 ・用語は一貫した意味で使っているか ・能動態を使って､主語を明確にしているか ・曖昧な表現や抽象的な表現はないか 要件定義書でよく使われる曖昧な表現の一例。 定量、具体的な表現をする。 ・効率的な ：「効率的な意思決定」「効率的な発注処理」など・・・ どのくらいｼｽﾃﾑが早く処理するべきか？ どのくらい人が簡単に使えれば良いのか？ ・柔軟な ：業務のどんな変化に対し､ｼｽﾃﾑがどのように変わるかを具体的に定義する必要がある。 ・必要に応じ ：判断するための方法､条件は？ 具体定量的な表現にする。 ・十分な ：何がどの程度あれば十分なのか？ 具体定量的な表現にする。 ・∼を管理する：具体的な機能に絞りこむ？ 発行する､発行する､変更する､取り消す・・・ ・∼しなくてはならない ：否定形を極力使わないで､肯定形で表現する。 ｅｘ：「ｼｽﾃﾑは、受注両面で受注情報を削除するとき、ﾕｰｻﾞに確認を求めなければならない」 ⇒ 「ｼｽﾃﾑは、受注画放で受注情報を削除するとき、ﾕｰｻﾞに確認を求める」 要件定義書は、記述内容を正確に伝えるため、曖昧な表現を排除することが重要。 もちろん、要件そのものの曖昧さについても考慮して明確にしなければならない。機能の前提条件に漏れ 矛盾がないか、機能間に矛盾はないか、あらゆる視点に留意する必要がある。 18 ◆ 技術調査報告書 顧客に大きなﾒﾘｯﾄをもたらす革新的なｼｽﾃﾑを提供するためには、最新技術や 1T 製品をｼｽﾃﾑ開発 に取入れることが肝要。 そのため､最新技術を調査し組織に報告して普及させる活動が必要。 技術報告書は､調査結果を整理･考察するもので､最新技術の専門用語が数多くﾄﾞｷｭﾒﾝﾄに登場する。 内容は､世に普及していない事柄や､技術評価も定まっていないことが多い。したがい､読み手の知識ﾚﾍﾞﾙ に人わせて書く、また、多角的に反対意見に応えることが重要になる。 読み手に合わせて書く 技術調査をする人は､組織の中で技術ｽｷﾙの高い人材になる。 一方、読み手は､むしろ対象技術につい ては素人(部下､異分野､管理･経営層)の場合が多い。調査した執筆者自身の技術ﾚﾍﾞﾙで書いた報告書を 散見するが､独りよがり(ﾒﾓ)の難解な場合が多い。 読み手に理解･納得してもらうのが､報告書である。 常に読み手のﾚﾍﾞﾙを意識して文章を書くことが必須である。極端な例で､入社まもない新人と､経験数十年 の専門家が､いずれのﾚﾍﾞﾙで話してもﾁﾝﾌﾟﾝｶﾝな対話になる。読み手のﾚﾍﾞﾙに目線を知って丁寧に書く。 技術調査報告書の多種･多数登場する技術用語の定義は、間違い･曖昧･漏れは許されない。 ①用語の定義から始める 文章の書き出しで用語の定義を記述する方法。 ｅｘ：｢IT ｱｰｷﾃｸﾄ:ｺﾝｻﾙﾃｨﾝｸﾞｻｰﾋﾞｽの動向：ｿﾌﾄﾊﾞﾝｸ」の冒頭部分 ｺﾝｻﾙﾃｨﾝｸﾞとは、経営目標を達成するために理想と現状のｷﾞｬｯﾌﾟにおける問題の解決を支援することです。 顧客ﾆ-ｽﾞや競争関係の悪化など、企業の経営環境は常に変化しています。その外部環境変化を分析して、 最適な戦略を策定し､事業の見直しや IT による業務効率化などに取組んでいく必要があります。 読み手に「ｺﾝｻﾙﾃｨﾝｸﾞ」とはなにかを理解してもらうため､まず「ｺﾝｻﾙﾃｨﾝｸﾞ」を定義し､続けてｺﾝｻﾙﾃｨﾝｸﾞ の重要性を書く。冒頭に定義して読み手にｲﾝﾊﾟｸﾄを与える。対象の用語が重要な意味をもつ際に有効。 ②説明をその場で付け加える 文章の流れの中で登場した用語について、その場々で説明を付け加える方法。 ｅｘ：｢ｸﾘﾃｨｶﾙｼﾝｷﾝｸﾞ実践論：E･B･ｾﾞﾂｸﾐｽﾀ/J・E･ｼﾞｮﾝｿﾝ｣の例から われわれは､自分がどんな知識をもっているかについて､ﾄﾞﾚﾀﾞｹのことがわかっているだろうか。これらは､心理学 者がメタ認知と呼んでいる問題である。「メタ」という接頭語は､「より上位の」とか「∼を越えた」という意味である。 つまり、われわれの認知活動そのものを認知する働き､それがメタ認知である。 ｢ﾒﾀ認知｣の言葉に続き､意味を解況する。言葉の意味を知らないと読み進めないとき有効。 ③補足的に解説する たくさんの用語を､本文で一々説明すると､幹となる論理展開がぼやけて読みにくくなる。 用語の後に括弧書きで説明･定義する文章も見かけるが､括弧が多いと読んでいて思考が中断する。 本文の中で解説対象は､内容理解に有用な用語に絞り､その他は脚注､添付(補足)資料､備考などに まとめるのも．一つの方法です。 つまり、外部に用語集を作成する。 多角的に反対意見に応える 何事にも､表/裏がある。技術にも良い面/悪い面がある。読み手に納得感を与え､技術の重要性を認め てもらうためには､取り上げる技術のﾒﾘｯﾄ/ﾃﾞﾒﾘｯﾄをバランス・良く整理する必要がある。 反対意見を出すには、自分が考察した結果に対し､多角的に検討しなければなりません。 そのためには､別の立場から利川価値を考える､技術の適用前提をなくしてみる､接術の適応事例を調べる、 などの取組みが有効。 19 ◆ ﾄﾗﾌﾞﾙ報告書 障害発生したときに提出するﾄﾗﾌﾞﾙ報告書は、発生経緯や原因の分析、対策立案まで、顧客や関係者 に報告する。改修後には、完了報告書の提出も必要になる。 ﾄﾗﾌﾞﾙ報告は、読み手に納得してもらうため､技術の正確な裏付けと､納得できる論理性が要求される。 また、論理的な整理だけでなく、迷惑をかけた相手に対して謝非の気持ちを示すことも肝要です。 原因を論理的に分析する ﾄﾗﾌﾞﾙ報告書は、障害の発生内容とその原因の因果関係を論理的に説明する役割を担う。 ｢前提と結論｣の関係と何様に､｢原因と結果｣の関係を論証しなければならない。 たとえば､ｻｰﾊﾞｰ停止障害では､ｼｽﾃﾑ運転監視のログから証拠をつかみ､ﾊｰﾄﾞﾃﾞｨｽｸの空き領域が不足 したことを特定できれば､前提と結論の因果関係を整理できます。実際は､単純な現象(処理停止､画面ﾛｯｸ) でなく､ｼｽﾃﾑが不安定､稀に処理抜け､など複雑なﾄﾗﾌﾞﾙが多く､簡単に原因を特定できない。 最近のｼｽﾃﾑは、ｿﾌﾄｳｪｱ,ﾊｰﾄﾞｳｪｱ,ﾈｯﾄﾜｰｸの数多くの要素で構成される。原因が､複雑に入り組んで簡単 に特定できない場合は､原因の候補をいくつかあげ､可能性が高い原因を推論する 。そのためには､可能 性が高いことを示す証拠が必要になる。ﾄﾗﾌﾞﾙ報告は､間違った推論は､絶対許されない。 ①前後関係だけで因果関係にしてはいけない 二つの別の現象が時間的に近接すると､両者に因果関係を想定しがちです。 *ｿﾌﾄｳｪｱ･ﾊﾞｰｼﾞｮﾝ更新したらｼｽﾃﾑが不安定。 ﾙｰﾀを交換したら応答性が悪化した。 因果関係の有無？ 時間的に単に重なった？思考の迷路にはまらないよう､冷静な分析が肝要。 ②権威に訴えてはいけない ｢権威に訴える」とは､雑誌に事例がある、メーカーがこう言っている、など他者の情報をうのみに結論 の論拠とする。推論が手詰まりのとき､権威に訴えて結論をだしがちです。これら情報源は､信頼できる かもしれないが､入手情報の根拠を把握し､権威が信頼できる筋の説明が必要です。 ③二分法で割り切ってはいけない 二分法：多くの選択肢､複数の選択肢の組み合わせを､二つの極端な選択肢だけを提示する。 *ｲﾝﾀｰﾈｯﾄﾓｰﾙ･ｼｽﾃﾑで障害が発生し､決裁処理を委託する提携先ｼｽﾃﾑに原因がある例の解決策 提携先のｼｽﾃﾑをすぐに修理する、もしくは､全サービスを停止する､二案が提示された。 第３案：他社に決裁を代行してもらう。 第４案：自社で電話を使い手作業で決裁する。 二案から顧客に選ばせるのが､一見効率的だが､有効な手除外する側面もある。 可能性を広げ有効な案を出すことが重要です。 相手の心理面に配慮する 顧客やﾕｰｻﾞからのﾄﾗﾌﾞﾙやクレームは､二つの要素がある。ﾄﾗﾌﾞﾙやクレームの内容そのもの、もう 一つは人間としての､怒り､戸惑い、失望感です。 SE は､論理的に考え､ﾄﾗﾌﾞﾙ内容に焦点を絞り淡々と対応することが多い 。それだけではいけない。 相手の感情的な側何にも配慮し、共感しながら対応していくことが大切です。 ・相手の感情面に配慮して、丁寧な謝罪の言葉をまず入れる ・経緯を長々と説明すると 「言い訳」 と見られるため、簡潔に結論から入る ・いつまでにﾄﾗﾌﾞﾙが復旧する見通しなのか、時期を明確にする 20 第 1 章 なぜ文章力が必要なのか SE は文章作成が苦手/文章には機能がある/日本語は難しい/ｼｽﾃﾑ開発は伝言ｹﾞｰﾑ/ｼｽﾃﾑ開発はドキュメトが成功の鍵 第 2 章 なぜ下手な文章ができるのか 下手な文章とは何か/目的が存在しない/読み手の視点がない/論理的でない/読みづらい 第3章 文章術の基本原則 1)文章の骨格 ：「起･承･転･結」4 部構成／「序論･本論･結論」3 部構成／「結論･理由」2 部構成 2)納得させる論証：前提と結論/隠れた前提/演繹法/帰納法/具体例の提示/比喩の活用/反対意見への反論/用語に敏感 3)心理的な作用 ： 曖昧さの排除／生地使よりも能動態／否定形よりも 1H 定形 4)わかりやすい文章術：一文一意／ 箇条譜きの粗別 5)読みやすい表現：冗長性の排除／表現の統一／廿へ孝の見た臼／リズム感 第 4 章： ﾄﾞｷｭﾒﾝﾄの作成術 1)設計：設計図を描く／ﾄﾞｷｭﾒﾝﾄの類型的を決める／読み手を設ハ杷する／読み手のレベルに合わせる／己を振り返る 2)骨格と本文の作成：アウトラインを描く／と h リあえず書き始める/目次先行型と本文先行型を組み合わせる／ 自分に問いかける／多角的に論理を展開する 3)チェックと見直し：准放して整える／画面よりも紙で確認する／台ノに出し聞いて確かめる／時間を置いてから読む／ゼロペース で杏き直すこともいとわない 第 5 章 ﾄﾞｷｭﾒﾝﾄ別必一貌ポイント 1)提案書： ５W1H3C をおさえる/結論から入って理由を示す/結論から入って理由を示す 2)要件定義書：なぜ必要なのかを明弘する/曖昧さを排除する 3)根術調査報告書： 愉 流み f にム‖わせて市く／多角的に反柑意丸に応える 4)ﾄﾗﾌﾞﾙ報告苔： 原囚を論理的に分析する／相手の心理面に配慮する 第 6 章 文章力を向上するには 1)文車力の向上に近道はない 三多の法∴［‥血をこなせば許へ転換する 2)本をたくさん読む 不を読むことは考えること／批判的に本を読む／豊結な詔免を身につける／忙しいときほピ本を読む 3)文革をたくさん肯く 日記を杏く／告辞を古く／人の文率を添別する 4)論理的に考える ディープシンキング／コンセプチャルシンキング／メタ思考／思考フレームワークの汁椚用 5)ツールを利用する 辞典を使う／校正機能でチェックする／手筈きの効用 6) 文章力向上のための必読吾 糊 丈杏丁作法／思考法 」仇＊H 法 あとがき 21
© Copyright 2024 Paperzz
