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