ドキュメントの作成について。
* まとめ前のメモ [#yd644eb8]
-フォーマット、命名規則などのルールを決める
厳しいところになると、パワポのカラーパレットすら決めているところもあるくらい。
雛型に従えば、余程すっ飛んだ感覚でない限り割と統一感が出ることもマル。
-メモを作らない
[[プロジェクト]]の工数は有限である。[[成果物]]以外は作成しないくらいの勢いで。
確かに「ちょっとした備忘」が欲しい場合もあるが、作ったら何らかの[[成果物]]の内容に組み込むか、添付資料にする。価値があるから作ったんでしょ？と。
-用語、表記の統一
極々当たり前のことだが、特定の意味をもった単語を色々な言い方・書き方で表現しないこと。
分かってる人は「日本語が不自由なnoobだな」で済むが、ユーザは違う単語 = 違う意味？と解釈しかねない。
また、[[議事録>成果物/議事録]]での口語・文語調の統一や、プレゼン資料のですます・である調なども。
-コピペしない
コピペミス、格好悪い。
あと、プログラムも一緒だが、コピペって作業効率が悪い人がするものなので。
コピペをした時、自分の作業効率またはフォーマットが悪くないか考えてみよう。
-要点しか書かない
グダグダ書いても邪魔なだけだし混乱や認識の齟齬を招く。
不要な記述は、内容が不足することよりも悪である。
-濁点を使わない
濁らない方が読んでいて良く流れる。
〜だが→〜とはいえ、〜なので→〜のため、〜が〜する→〜は〜する
～だが→～とはいえ、～なので→～のため、～が～する→～は～する
-同じ単語を連続して使いすぎない
上記の「用語、表記の統一」を逸脱しない範囲で言い換える。同じ単語が連続登場すると読みづらいし、そもそも文の内容が充分に精査されていないことが多い。
-説明資料やソリューション資料の組み立て
起承転結を組み立て、ストーリーを作る。
Overview→結論→補足→例出し→締め、Overview→問題点の列挙→解決案→オススメの提示とその根拠など。
~
~
CENTER:【スポンサードリンク】
#htmlinsert(amazon_book_sap_system_implement)
~
~
----
#pcomment(reply)
