Ⅳ 作文ルール:目標は通じる文章


 1.明快・具体的に書く
 ◇筋道が明らかですっきりしている
 ◇動作が見えるように具体的に書く

 2.標準書式を守る
 ◇日付の記入を忘れない
 ◇A4縦置き・明朝・10.5P

 3.見直しをくり返す
 ◇時間をおいて見直すこと

 ◇検索の要求に応えること 



1. 明快・具体的に書く

【明快に書く】
明快とは、筋道が明らかですっきりしていること。明快でない文章とは、表現が冗長だったり、もって回った言い方だったり、主語と述語の対応がはっきりしない、などの弱点を持っている。

ITエンジニアの仕事は、ヒト――顧客・開発チームのメンバ・品質管理部門など――を対象とする。情報伝達にしても情報共有にしても、ヒトを動かし仕事を遂行するためには、あいまいなものではなく、言い切る姿勢からの、明快な文章が要求される。

次のような文章は言い切る姿勢で明快に書き直そう。
・この方式を採用した方が良い結果になると思われる → この方式を採用すること
・おそらく事故の原因は設計不良と考えられる → 調査結果によれば原因は設計不良である

文章を読み下して、そのまますんなりと理解できるように、一直線の流れで書こう。例えば、カッコをやめることである。カッコを取ると、文の中断がなくなり流れがスムーズになる。

パスワードは半角10桁以内でお願いします。英数字(アルファベットか数字のみ。
ハイフンや@などは使えません)のみとして下さい。
   →パスワードは半角10桁以内の英数字でお願いします。
英数字とは、アルファベットか数字。ハイフンや@などは使えません。


【あいまいさを無くす】
技術文書では正確な情報を伝えることが使命である。正確なデータを、そのデータにふさわしい方式で表現することが必要である。次のような「あいまいさ」を含むことばを使わないこと。
ほぼ、約、ほど、ぐらい、たぶん、ような、らしい
 かなり、少し、多少、なるべく
「数人」とは、何人か? ある人は「2、3人」と考えるし、 「5、6人」とする人もいる。

「など」は範囲がぼやけるので、使わないこと。確信犯的に敢えてぼやかすために「など」を使う場合もあるようだが。「など」には、その他大勢が一緒くたに詰め込まれているので、対象範囲を明確に限定するためには表現を工夫しなければならない。
 ①「など」を使わないで全部を列挙する
→納入ドキュメントは、操作マニュアルと機器説明書だけである。
 ②「など」の内容を推測できるようにする
→CPU、メモリ、ハードディスクなどパソコン部品を購入する。
   (メモリもパソコン部品として推測できる)
 ③総数を示して、「など」の内容を限定する
   → ピンク、ブルー、モスグリーンなど全部で6色。

【具体的に書く】
2つの文を比べてみよう ・マイクロソフトは世界一の優れたソフト会社です。
    ・マイクロソフトの年間の売上高はXXX千億円です。
前者は「意見」であり、後者は「事実」の記述である。技術文書では、事実の具体的表現が必須である。「具体的」とは実際的で、細かい所まで取り上げる様子。

マニュアルであれば、「操作は非常に簡単です」というような表現でなく、その製品の操作を目の当たりにするように書くこと。計画書であれば、実際に何人の開発要員が必要で費用はいくらかかるのかが主題であって、「開発は重要ですが非常に困難です」――のような文章は役に立たない。


◆誰が何をするのか。顔や動作が見えるように書くこと。
「何日、どの球場で、誰が、ホームランを打ったか」がすぐ分かるように
行動内容を具体的に書くこと
・プログラムの品質が悪い →外注会社へ指示した品質目標が低かった
・納期が遅延した →事故対策にまぎれて本来の開発作業に手を着けられなかった
・仕様を凍結する →画面操作が旧システムと同じになることを顧客に確認する
・検査が甘い →新製品に対する検査基準を改訂する必要性に気づかなかった
・発注作業を改善する →SAPを導入し在庫状況が即座に判明するようにする

◆多い・若干・遅い・大きい等の形容詞に代わって数値で置き換えてみよう。

◆概念的な動詞を避け、具体的な動作を示す動詞に代えること。
 ・新聞を見る →新聞を読む
 ・パソコンを使う →パソコンを操作する or Excelで計算する
 ・データを出力する →データを印刷する
 ・仕様を固める →画面のレイアウトを決める


◆仕事で達成すべき目標は具体的にはっきり書くこと。
・基本を徹底する →品質保証テストを出荷前に実行する
・きちんと性能を保証する →ベンチマークテストによって処理時間を確認する
・処理時間を短縮する →日次処理を2時間で終わらせるように設計する
・販売を強化する →販売戦略会議を月1回開き重点製品を決める
・処理時間を短縮する~具体的な問題点と目標に置き換える
        →日次処理を2時間で終わらせる
        →データベースの使用方法を見直す
        →Javaの部分をCで組み直す
        →条件を変えてベンチマークテストを再実行する
    
【数値で示す】
新幹線が開業して30年の歳月が流れた。この間、新幹線は山陽に東北に上越にと路線をのばし、延べ50億人以上の乗客が利用した。年間利用客は、2億7500万人を超え(91年度)、1日平均で75万人以上に達している。全国民平均で年間2回以上利用していることになり、国民経済からみても、国民生活からみても、今や完全に「国民の足」になっている。


【行動的な表現】
行動的――個人の行動が目に浮かぶような表現を活用すること。そして動作の指示は時間を追って逐次的に書くのがよい。そうすれば仕事の成果として期待されている目標がはっきりする。また技術文書に基づく人間の動作がより一層具体的になる。

雪の日の運転には気をつけなさい。といってもほとんど何もいっていないのと同じである。どのように気をつけるかについて、――チェーンをつけなさい。ギアは2速にしなさい。ブレーキを一気に踏んではいけません。などと具体的に述べなくては意味がない。

 イギリス人の記録文 ――役に立つこと――

たとえば、山にのぼる。日本人は、そんなとき、こんなふうな文章を書く
――「朝の冷気を吸いながら夢中になって登ってゆく。小一時間も歩いただろうか、急に視界がひらけて高原に出た。名も知らぬ花がちらほらと咲いていた」

しかし、イギリス人は、おなじ経験をたとえばこう書く
――「午前7時に出発。気温18度。方角を北西にとって50分後に標高1200メートルの高原に到着。タムラソウの群落あり」
おなじコースをとって、あとからおなじところに行こうとする人のための手引き書としてどちらが役に立つか、といえば、文句なしにイギリス式記録文だろう。どんな準備をしていったらいいか、どんなことに注意すべきか、イギリス人の書いた克明な記録は、徹頭徹尾、役に立つ。 (加藤秀俊著『自己表現』) 




BOOK 『能力構築競争』もの造りとは設計情報の転写作業である 
世の中のすべての産業は広義の情報産業とみることができる、と著者はいう。もの造りのプロセスを「情報のやり取り」とみなし、製品=情報+媒体(メディア) という発想だ。すると、製品開発は設計情報の創造と考えられる。設計品質は、市場情報と技術情報をもとに新製品の設計情報を創出する際の効率・スピードなどに当たる。生産とは製品への設計情報の転写。製造品質は転写精度、「生産性」は製品への情報転写の発信効率である。

この「設計情報転写説」によれば、生産・開発現場の実力=「深層の競争力」は、設計情報を創造し媒体へ繰り返し転写する情報システムの特性として分析することができる。鋼板、樹脂、シリコン片など、耐久性のある媒体に設計情報を仕込んで顧客に提供するのが製造業である。

特に設計情報の転写が難しい素材、つまり「書き込みにくい媒体」を扱うタイプの分野が日本企業の得意領域だったと考えられる。自動車の鋼板は基本的に「書き込みにくい媒体」であり、高価な金型と数千トンのエネルギーを使ってようやく情報転写(プレス作業)が完成する。自動車は鉄の塊の上に製品設計情報が転写・刻印されたものだ。

日本のもの造りシステムを支えたメカニズムの中心的コンセプトは「能力構築競争」である。企業が開発・生産現場の組織能力を切磋琢磨し、工場の生産性や工程内不良率や開発リードタイムなど、顧客が直接評価しない裏方的な競争力指標の優劣を、まじめに、かつ粘り強く競い合うことである。

能力構築に長けた企業は、競争合理的な発想が企業の隅々にまで行き渡っている。しかし、創発的な状況、つまり「霧中の山登り」を想定すると、事前合理的な意志決定能力だけでは不十分である。もっと広い意味での合理性――「運を実力に転換する能力」「失敗から学ぶ能力」「怪我の功名をきっちり活かす能力」「何が起こっても結局学習してしまう組織の能力」――が浸透している必要がある。トヨタ自動車の強さの究極の源泉は、こうした能力構築能力――「進化能力」である。

生産においては、開発部門が創出した製品設計情報を正確に淀みなく製品に転写する「作り込み能力」がポイントである。

◆『能力構築競争』 藤本隆宏*著、中公新書、2003/6
  * 東京大学ものづくり経営研究センター長 


 


2.標準書式を守る

技術文書としての標準書式を慣用的規則をふまえて、最大公約数的な基準を拾い出した。

【表記の基準】 (参考:『朝日新聞の用語の手引』)
漢字:漢字は原則として常用漢字を用いる。
平仮名:連体詞、感動詞、助動詞、助詞、補助動詞、形式名詞などは平仮名で書く。
片仮名:外国語、外来語など。
漢字と仮名の使い分け:接続詞、代名詞、副詞は仮名書きするものが多い。
句点:句点は文の終わりに付ける。
読点:読点は、記事を読みやすくするためや、文意を正しく伝えるために、息の切れ目や、
読みの間を考えて打つ。①誤読・難読の恐れがあるとき、②語句を並べるときや、
対立節に。
中点(中黒、なかぐろ):同格の単語を並べるときや、判読しやすくするために使う。

不確定数詞:
 ①漠然とした数詞 数人、約十人、何十回、……
 ②一定の基準の前後をあらわすもの 未満、超える、以内、以下、まで、……
 ③期間の経過 満3年、3カ月、3周年、足かけ3年、3年越し、3年がかり、3年ぶり

数字:数の幅を示すときは、誤解を避けるために上位のけたの数を省略しない。
 横書きのとき:昭和63年12月15日 午前0時15分 3,560人 8,561,321円 650万円

以上・以下・未満 (一定の基準の前後):
 a 20歳未満、100点未満、千円未満 基準の数値に達しないことをあらわす。
 b 20歳を超える、50人を超える、千円を超える 基準の数値を超えることをあらわす。
 c 10人以内、30日以内、500メートル以内
 d 20歳以下、50番以下、千円以下
 e 20歳まで、50番まで、千円まで
 f 20歳以前、30日以前 基準の数値を含めて、それより小さい数値をあらわす。
 g 20歳以上、50人以上、千円以上
 h 20歳から、30日から、千円から

【単位の表し方】
 テラ TB、ギガ GB、ナノ n、センチ c、ミリ m
 メガ MB、メガヘルツ MHz、キロ kB (KB*とは違う)

   * パソコン等でメモリ容量などに使用される「KB」は、1024バイトを単位と
    している場合がある。

【日付の記入を忘れない】
技術文書では時間が重要なキーとなる。日付のない文書は技術文書ではないと言い切る人もいる。「いつ」このプログラムを修正したのか、「いつ」顧客の了解を得たのか、「いつ」出荷日が変更になったのか、等々。日常の仕事はすべて時間を基軸としている。そして仕事には期限(納期)が必ずあるのだから。

たとえ1枚のメモであっても日付(作成日など)を必ず記入しよう。日付は自らの作業記録であると共に、読む人には情報の鮮度を示す。年号を忘れないようにしよう。また、ほとんどの仕事は1週間を単位として動いているので、できれば曜日まで記入するのがよい。

Windowsでは、ファイルのタイムスタンプは意外と役に立たない。例えば、ファイルの作成日時は、このファイルをコピーすれば変わってしまうし、保存操作でも更新日付が変わってしまう。文書中に、しっかりと日付を示す文字列を明示的に書き込んでおくことが大切だ。検索時のヒットミスを防止するためにも、日付の文字列の記入方法は統一しておく必要があるだろう。


【ページ番号の記入】
Pi/Pn形式で一連の通しページ番号を入れよう。このページで終わるのか、あるいは後続のページがあるのかを読む人にはっきり伝えること。特にファックスでは送信事故に備えるために必須である。


【A4縦置き】
社内外とも公文書を含めて文書はほとんどA系列(A4)に統一されている。またオフィスのファイリング機器もA4を前提にした方式が普及している。技術文書もA4が基本である。
・A4縦置き(Portrait)の横書きが基本
・とじ代を左わきに取ること。JISの規定は25mm
・同一文書中では縦置きと横置きを混在させない
・A4とA3のように、サイズの異なる用紙は混在させない
やむを得ず混在させる場合は、小さいサイズから大きいサイズへと並べる

【明朝フォント・10.5ポイント】
ひとつの文書中にさまざまな複数のフォントが混在するのは、読みにくいものである。また品位を失うことにもなるので節度を保って使うようにしたい。

通常の文書は明朝体が標準である。ゴシック体は強調する部分に限って使用するのがよい。
よく全文ゴシックという文書があるが、べったりとして読み難いものであり、ひとりよがりの印象を与える。フォントサイズは、10.5ポイントが標準である。



  日付の表記に関するノート

日付を表記する場合、その形式は他の文書との統一性や旧来データとの互換性などを考慮する必要があり、簡単には決めにくい。しかし、国際的に相互運用を考える場合にはISOのノートを参考にする必要がある。

例えば「06/09/02」という日付の表記。これは次のように地域によって全く意味が違ってくる。
  日本……2006年9月2日
  英国……2002年9月6日
  米国……2002年6月9日

◆ISO(国際標準化機構)では、日時を一意的に表記できるように標準を定めている。
 W3Cノート[W3C-DTF] (Date and Time Formats)として公開された内容は次の通り。
  (1) 年のみ YYYY 例:2006
  (2) 年月 YYYY-MM 例:2006-09
  (3) 年月日 YYYY-MM-DD 例:2006-09-02
  (4) 年月日および時分 例:2006-09-02T10:45+09:00
  (5) 年月日および時分秒 例:2006-09-02T10:45:23+09:00
  (6) 年月日および時分秒および小数部分 例:2006-09-02T10:45:23.5+09:00
 日付と時刻はTで区切る。タイムゾーンはUTCとの時差を示す。UTCそのものはZとする。
 UTCとは、かつてのGMT=グリニッジ標準時のこと。

◆ピリオド区切りの日付
 日本では2006.09.02 と表記する。欧州標準規格では02.09.2006(DD.MM.YYYY) となる。
 JISX0301(日付及び時刻の表記) では元号を表記する書式として追加されている。
  例:H18.09.02

◆Microsoft Excelでのデータの扱い
 日付データとして扱われるもの:2006-09-02、2006/09/02、2006年9月2日
 文字列として扱われるもの:2006.09.02




3.見直しをくり返す

文章を書き上げたならば、必ず見直しをすること。自分の書いた文章の悪い箇所は、自分ではわからない。自分の書いた文章は、書いたままでは「悪文」――相手に正しく理解してもらえない――と第一に認識すること。

見直しにはさまざまな方法がある。
・時間をおいて見直す
・第三者に目を通してもらう
・チェックリストを準備し活用する

第三者によるチェック/査読はてきめんに効果がある。自分では全く気付かなかった凡ミスや文章の欠点が、他人からは即座に指摘される。前提条件が脱けている場合とか、難しい用語をそのまま定義しないで使っているとか。誤字・脱字など、かな漢字変換のミスなども多い。

【カタカナ語のチェック】
カタカナの多い文章は読みづらいものである。長いカナ表現だと字面からその意味を即座に把握するのが難しく、日本語としてのパターン認識がうまく行かないのだ。

読みにくい例
メニューはWindowsで扱うコマンドの一覧表です。メニューはアプリケーションのウインドウの一番上にあるメニューバーにあります。また、どのアプリケーションのウインドウにもコントロールメニューという、共通の基本操作を集めたものがあります。コントロールメニューを開くには、ウインドウの左上隅のボックスをクリックします。


 ライトついてますか? ――大事なことは一言でいえる――

教訓;もし人々の頭の中のライトがついているなら、ちょっと思い出させてやる方が、ごちゃごちゃいうより有効なのだ。 長い自動車用トンネルでは大事故を防ぐためにライトをつけておくことが必要であった。そこで、こんな標識を出した。「注意 前方にトンネルがあります ライトをつけて下さい」

トンネルの出口から少し行った所に眺めのよい休憩所があった。1日何百人という旅行者がそこに車を停めて、眺めを楽しんだ。しかし、そういう何百人のうち十人以上が、しまったライトがつけっぱなしだった。バッテリーが上がっちゃたぞ、と気づくのだった。警官たちはそういう車をスタートさせたり、牽引したりで手一杯になってしまった。

解決策として、運転者なら、何もかもいってやらなければならないほどバカではない、彼らには「ライトついてますか?」とだけいってやれば十分なのだった。この標識のおかげで問題は消滅した。
(ワインバーグ著『ライトついてますか』)  





【同音異義語のチェック】
同音異義語は日本語の宿命である。国語辞書をこまめに引いて、正しい用語を常に確認することが必要だ。かな漢字変換のとき、よく確かめないままにうっかり確定キーを押してしまうことがあるので注意。

同音異義語は、読めば分かるのであるが、耳で聞いたときにはどちらなのか一瞬とまどうことがある。まったく逆の意味になるときもある。
・時期と次期 縮小と縮少 稼働と可動
・雨天決行です←→ 雨天欠航です

以下にソフト関連の同音異義を並べてみた。

あらわす
表[表面に出す、表示、表明]  変化が表れる
現[隠れていた姿・形が見えるようになる、現象・出現]  姿を現す、太陽が現れる

かいほう
解放[束縛・圧迫を解いて自由にする]  解放区、農地解放
開放[開け放つ、出入り自由]  運動場を開放、市場開放、窓を開放する

かえる
代[代理、代表、交代]  あいさつに代えて、代わりの品
変[変化、変更]  位置が変わる、色が変わる、形を変える、立場を変えて、方針を変える
換[AとBを交換、置換、転換など]  言い換え、置き換え、書き換え、空気を換える、
      遺伝子の組み換え(一般用語は組み替え)、乗り換え
替[変・換以外の場合、前の物事をやめて別の物事をする]  入れ替え、移し替え、買い替え、
      差し替え    (注)「替」か「換」か迷うときは「替」を使うこと。

かた
形[フォーム、すがた]  跡形もない、大形の花、小形のチョウ
型[手本、パターン、タイプ]  足型、うるさ型、大型機械、最新型、ひな型、紋切り型

けい
形[すがた、かたち]  円形、図形、三角形
型[かたどる、模範となるもの]  原型、定型業務、理想型

かどう
可動[動く仕掛け]  可動式書庫
稼働[かせぎ働く、機械を動かす]  稼働率、稼働日数

さくせい
作成[文書などを]  計画書を作成
作製[物品・図面など]  ソフトウエア、地図、パンフレット、ビデオ

しこう  「オブジェクト指向」か「オブジェクト志向」か?
志向[心がある目的に向かう、一般用語]  学問を志向、権力志向、ブランド志向
指向[特定の方向を向く、限定用語]  指向性アンテナ、指向性の強いマイク
思考[考えられた事柄]  プラス思考

せいさく
製作[主として具体的、実用的なもの]  機械・器具の製作、
制作[主として芸術的、ソフト的なもの]  絵画・工芸品の制作

たいしょう
対象[相手、目標]  調査の対象、
対称[つり合っていること]  左右対称
対照[比較、取り合わせ]  AとBを対照、対照的な存在

はかり・はかる
計[計算、計画]  国の将来を計る、時間を計る、取り計らう
図[意図、企図]  解決を図る、合理化を図る、将来の繁栄を図る
量[計量、推量]  推し量る、目方を量る
測[物事の広狭、長短・遠近・高低・大小などをはかる、測定、測量、推測]
謀[謀議、謀略]、諮[たずね相談する]  審議会に諮る

はる
張る 張り紙、張り付け、ポインタを張る?
  貼り紙→張り紙。「貼り付ける」か「張り付ける」か?
  「カットアンドペースト」をMicrosoftは「貼り付ける」としているようである

ほしょう
保証[請け合う、損害の責めを負う]  命の保証、身の安全を保証する、品質保証
保障[一定の地位や状態を災害や危険から守ること] 安全保障、言論の自由の保障、身分保障
補償[与えた損害を補い償う]  遺族補償、損害補償

れんけい
連携[手をつなぐ]  両者連携して推進
連係[切れ目なく続く]  連係動作、連係プレー[運動用語]


【漢字/用語のチェック】
◆ひとつの文書の中では統一すること
  コンピュータかコンピューターか
  ソフトウエアかソフトウェアか (現状ではソフトウエアが大勢)

◆まぎらわしい漢字
繊細と精細
偏差と誤差 (偏差は平均値からのかたより)

◆うっかり誤字
メモリの2重使用 →二重
2値画像、二値画像 ……どちら?
3次元、三次元 ……どちら?

◆漢数字を使うこと。アラビア数字としない
<不確定数詞> ○ 数百人、数人、数十個
     × 数100人、数10人
<慣用句> 一部分、七転八倒、再三再四

◆使わない方がよいもの
 ・頁 →ページ
 ・電源をONにする →電源をオンにする (日本語と英語の混在はさける)

◆ことばの照応関係に注意
 ・応答性が遅くなる →応答性が悪くなる
応答時間が長くなる
応答が遅れる


【冗長/重複表現をチェック】
・大別すると2つに分けられる → 大きく2つに分けられる
・.NETが事実上のデファクト・スタンダードになる可能性がある
・入金条件のチェックを行う → 入金条件をチェックする
・通信装置の無応答を検出し → 通信装置から応答がないので


【誤使用】
 ・シュミレータ →シミュレータ
 ・デッドロック(deadlock)とは会議などの進行がゆきづまることを言う。
  lockをrockと誤り、暗礁の意味に誤使用している例がある。
  ○ タスクAとタスクBが資源を奪い合ってデッドロック状態になった
  × 問題が紛糾し会議がデッドロックに乗り上げた



【見直しトレーニング1】――悪文から明文へ――

<例文1>
国際通信の世界では、衛星などに比べて容量が大きい上に、とくにデータ通信では極めて重要な途中での情報劣化が少ないという利点を持つ光ファイバー回線を介したものが先進国では主流になりつつある。(1文、92文字)

《問題点と改善策》
・文が長いので、主語と述語の対応が一読して分からない。
・1つの名詞に、複数の修飾句がからみ複雑な構造である。
→ 改善:①短い単文に分けること、②修飾関係を明確にすること。

<リライト1a>
国際通信の世界では、光ファイバー回線を介したものが先進国では主流になりつつある。光ファイバー回線は、衛星などに比べて容量が大きい上に、とくにデータ通信では極めて重要な途中での情報劣化が少ないという利点を持つ。

<リライト1b>
光ファイバー回線は、衛星などに比べて容量が大きい上に、とくにデータ通信では極めて重要な途中での情報劣化が少ないという利点を持つ。このため、国際通信の世界では、先進国で主流になりつつある。



<例文2>
ROEは売上高利益率と資産効率を示す指標である総資産回転率、借入金依存度を示す財務レバレッジの3つを掛けたもの。

ROEをどう計算するのかよく分からない。リライトしてみよう
《番号を附けた箇条書きに直す》
ROEは、①売上高利益率と、資産効率を示す指標である②総資産回転率、借入金依存度を示す③財務レバレッジの3つを掛けたもの。

《文を2つに分ける》
ROEは、売上高利益率と総資産回転率、財務レバレッジの3つを掛けたもの。総資産回転率は、資産効率を示す指標であり、財務レバレッジは借入金依存度を示す。



【見直しトレーニング2】――複雑なメカニズムを分かりやすく説明する――
<例文3>
ディスク円盤(プラッタという)と磁気ヘッド、それに、磁気ヘッドを装着し駆動するためのアームからハードディスクの基本構造は成り立っている。高速にアームはプラッタ上を移動して、プラッタの任意の位置に記録されたデータの読み取りや書き込みを行う。プラッタは、ガラス製が一般的であり磁性体が塗布されている。ディスク停止時には磁気ヘッドとプラッタは接触しているが、回転数が上がるにつれ、ヘッドがわずかに浮き上がって接触を避ける。

ヘッドがプラッタに引っかかるように衝突すると、ヘッドクラッシュという障害を起こすが、データの読み書きが全くできなくなる深刻な現象である。プラッタ上の記録密度は、面内記録で1平方インチ辺り120Gbit程度である。しかし、垂直記録方式では高密度を実現している。最近の超高密度記録のハードディスクドライブでは、ディスク回転時のプラッタとヘッドの距離は、タバコの煙の粒子と比較できるほどに狭く、10~30ナノ・メートルである。


《問題点と改善策》
・グループ分けして説明するのがよい。ディスク→プラッタ→磁気ヘッドの順に。
・全体構造から細部へと、段落を分けて説明する。
・形容詞/副詞句の位置を適切に直す。長い文は短く書き直す。

<リライト後>
[全体構造]
ハードディスクの基本構造は、ディスク円盤(プラッタという)と、磁気ヘッド、それに、磁気ヘッドを装着し駆動するためのアームから成り立っている。アームはプラッタ上を高速に移動して、プラッタの任意の位置に記録されたデータの読み取りや書き込みを行う。プラッタは、ガラス製が一般的であり磁性体が塗布されている。
[回転メカニズム]
ディスク停止時には磁気ヘッドとプラッタは接触しているが、回転数が上がるにつれ、ヘッドがわずかに浮き上がって接触を避ける。ヘッドがプラッタに引っかかるように衝突すると、ヘッドクラッシュという障害を起こす。これは、データの読み書きが全くできなくなる深刻な現象である。
[プラッタへの記録]
プラッタ上の記録密度は、面内記録で1平方インチ辺り120Gbit程度である。垂直記録方式では、さらに高密度を実現している。最近の超高密度記録のハードディスクドライブでは、ディスク回転時のプラッタとヘッドの距離は10~30ナノ・メートルであり、タバコの煙の粒子と比較できるほどに狭い。


■ チェックリストの具体例

分 類  レベル1(全体構成)  レベル2(段落・文章) 
全体構成  ◆三段構成を採用する
序論・本論・結論
◆本論は目的に沿った構成である
記録型・説明型・証明型
◆ライトついてますか?
大事な一言を忘れないこと 
 
冒頭案内  ◆冒頭(序論)で案内図を示す
全体像・要約・結論など
◆読み手は明確である
◆読み手の理解レベルに合わせた記述
チャンネルが一致している
◆文書の目的が明確である
依頼・指示・連絡・報告・解説など
◆件名/題名は具体的な内容を表している 
 
重点先行  ◆読み手にとって重要な情報が先頭部にある
◆重点箇所が明確になっている
 結論・問題点・主要課題など 
◆段落(ブロック)の先頭には中心文がある 
三等分割  ◆マジックナンバー3を意識する
◆適当なグループに等分割してある
◆段落(ブロック)で構成している 
◆それぞれのグループ/段落の属性は明確で、お互いに混入していない 
短文連結    ◆一つの文は長くても50字である
◆単文を基本とする 
主題再現  ◆主題をサンドイッチ方式でくり返す
◆表現を変えてくり返すのがよい 
 
作文ルール    ◆明快な記述である
◆主語と述語の対応が正しい
◆誤字・脱字・同音異義語をチェック
◆かな漢字変換のミスがない◆あいまい語を使っていない
◆否定文に注意する 





BOOK  『失敗学のすすめ』創造的な設計をするためには失敗が必要
「失敗学」とは立花隆が名付け親とのことだ。失敗から新たな知識を学ぼうというのが趣旨。著者は大学院工学系の教授である。まず失敗とは「人間が関わっている」「望ましくない結果」である、と定義している。大学3年生の最初の授業では、技術の進歩に大きく貢献した失敗の例として、三大事故の話をするとのこと。(1)アメリカワシントン州のタコマに新しく完成した吊り橋が自励振動によって崩壊した例(1942年)。(2)ジェット旅客機デハビランド・コメット機の金属疲労による墜落事故(1954年)。そして、(3)第二次大戦中のアメリカンのリバティー船の破壊事故。

タコマに完成した当時最新の吊り橋は、秒速19メートルの横風によってあっけなく崩壊した。横風による共振と自励振動が原因であった。橋が大きく振動し崩壊する様子は16ミリフィルムに撮影されていた。この貴重なデータの解析や風洞実験によって、当時はまだ未知のものだった自励振動のメカニズムが明らかにされた。秒速80メートルの風にも耐えられる明石海峡大橋にもタコマの教訓は生かされている。

失敗情報は伝わりにくく、時間が経つと減衰する。一度経験した失敗がごく短期間のうちに忘れられ、再び同じ失敗を繰り返すことは珍しくない。失敗を生かすためには、失敗が起きるにいたった原因や経過などを正しく分析した上で「知識化」して、誰もが使える知識として第三者に情報伝達することが重要なポイントである。

失敗を知識化するための出発点は「記述」。「事象」、「経過」、「原因」、「対処」、「総括」などの項目ごとに書き表すと、問題が整理されて失敗の中身もクリアになる。この記録のあとに「知識化」という作業を入れる。知識化とは、起こってしまった失敗を自分および他人が将来使える知識にまとめること。

「知識化」とは、「失敗(事故)の中から普遍的な知識を抽出する」ことと理解できる。
タコマの吊り橋の事故例で考えると、今後の対処だけであれば、「つり橋を設計するときは、突風に注意しよう」となってしまう。しかし、これを突き詰めて知識化すると、「風の強さが秒速Xメートルのときは、ロープの強度をいくつにしろとか……」という普遍的な"吊り橋の建設技術"に完結するのである。

◆ 『失敗学のすすめ』 畑村洋太郎著、講談社、2000/11
 



4.ライフサイクルを考える

技術文書にもライフサイクルがある、と考えよう。いったん完成したITシステムは、初期バージョンに続いて機能改善・追加が繰り返され、長期にわたりシステムの拡大・成長――ライフサイクル――が続く。機能が陳腐化し世の動きに追従できなくなったときに寿命を終える。ITシステムに対応する技術文書も、そのシステムと共に長いライフサイクルに耐えるように、設計され書き表され、維持される必要があるだろう。

ライフサイクルは、2つのフェーズに分けて考える必要があるだろう。一つは文書作成それ自身が関わる初期フェーズ。文書が実用に供される(仕事を動かす)段階である。その後に、もうひとつのフェーズとして閲覧・維持・保管段階が続く。技術文書は作成段階だけではなく、第2の保管フェーズにも注目する必要がある。時間のスケールを考えても、保管のフェーズが占める比率は高いのだから。文書作成の時点から、もっと保管段階での効率的活用を考えることが要求される。

保管フェーズにおいては、技術文書は再利用に備えて機会を待っている。必要な文書は、検索ツールによって拾いだされるのが普通だ。だから、技術文書は、書く瞬間から将来の閲覧・検索に備えておく必要がある。検索ツールを利用するにしても、うまくキーワードにマッチするように工夫しておくことが必要だろう。最も検索頻度が高いものは、経験から言っても「日付」である。次位は固有名詞だろうか、人の名前とか、企業の名前、プロジェクト名称、等々。だから、日付の記入されていない技術文書は、まったく役に立たない。

【閲覧・検索のタイミング】
技術文書の保管は、情報を効果的に検索できる仕掛けでなければ役に立たない。検索された文書は、再利用され新しい情報として生き返る。また今日の情報を補強するデータとして利用されることもある。検索のタイミングとしては次のようなものがある。

・担当者が異動してしまって、文書の格納場所が分からない
・過去に作成した提案書や契約書をベースに新しい顧客向けのものを作成したい
・前回の総合テストの結果をもとにしてテスト計画書を練り直し改善したい
・以前のレビューで仕様を変更したが、特別な顧客事情があったのかを確認したい


また、内部統制あるいはマネージメント・システムにおいて、その管理サイクル(PDCAなど)を順守/維持するという観点から、文書を検索することがある。一つひとつの作業がルールに従って実施されていることを確認するために、該当の文書を検索し、証憑として抜き出して確認するためである。



BOOK 『曖昧性とのたたかい』 夢にみるほど考え抜くこと  
 日経コンピュータによれば、プロジェクトの成功率――品質(Q)、コスト/予算(C)、納期(D)が計画通りだったもの――は3割にもとどかないという。

著者はプロジェクトの失敗要因を「曖昧性」に求める。プロジェクトの見積りがもっとも大切だと考えている。見積りはSEの開発業務の中で一番難しく、しかも一番重要な業務であると。見積りは必ずしも見通しが立っていない未来――プロジェクトのさきざき――を予測し、あたかも確定しているがごとく未来を表現しなければならない業務である。したがって、見積りには想像力・勘といったあらゆる知的能力が要求されるのだ。

見積り能力向上のためには、見積りと実績の差を反省し発生責任を追求するだけではなく、何が原因でそのような差が生じたのかを、冷静かつオープンに見極めることが大切である。そして、正しい実績データを自分なりに蓄積することが必要だ。

本書の底流となっているキーワードは間違いなく「設計」だろう。例えば、見積もりという日常行為に対しても、ひとつの作業としてではなく「見積設計」と表わしている点にも、著者の真骨頂があるではないか。とにかく考え抜くことだと言う。それも身体をつかって、五感をフルに働かせて。重要な課題だったら「夢に見るほど考えよ」。考え抜いて、一歩でも曖昧さを正確に近づけることだと。
――IBMの企業標語「THINK」を思い出させる

隅々にまで著者の体験が書き込まれている。机上の空論ではない。柔軟で多面的な発想にも目を開かされる。プロジェクト計画段階から、「人は間違える」「機械は故障する」「ソフトウェアのバグはゼロにできない」で、取り組めとか。また、著者独特の切れ味のよいアフォリズム(格言)にもドキッとする。「良い名前は幸せの始まり」や「公倍数的リーダーと公約数的リーダー」とか。

SE向け教科書としては新人にはちょっとピンと来ないかもしれない。若手管理者がプロジェクトに行き詰まったとき、ぱらぱらとページをめくるという読み方もあるだろう。処方箋のヒントが見つかるはずだ。

◆ 『曖昧性とのたたかい 体験的プロジェクトマネジメント論』名内泰蔵*著、翔泳社刊、2005/3
  * 日立製作所を経て、日立システムアンドサービス取締役社長を務めた。



次の章へ / 前の章に戻る / Homeへ戻る