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