ドキュメント作成時のあるあるアンチパターン20 - Qiita
業務でドキュメントを作成するケースは多々ある 例：仕様書・設計書・提案書・メール・障害票．．． ここでは各ドキュメント共通してありがちなアンチパターンをまとめてみました。 1. 表記がバイト表示・マイクロ秒表示 プログラムが出した数値をありのままに表示するパターン ファイルサイズが100MB, 1GBあろうと、バイト表示にする 桁数が多い数値に、桁区切り（,）を入れない 時間を何でもマイクロ秒・ミリ秒にする（1/100万秒までの精度が必要？体感で分かる？） 桁数が多い＝精度が高い＝良い文書、ではなく、見る人が必要とする精度に切り上げることが重要（売上で１円単位まで出すことが無いのと同様） 悪い例 No ファイル名 ファイルサイズ(byte) 処理時間(秒)
わかりやすさの技術 - やしお
社内向けの教育資料を、ど素人でもわかるようにと思いながら作っていて、じゃあ「わかりやすい」って何だろうって考えてた。今まで読んできたいろんなわかりやすかった本とそうでない本を思い浮かべながら、一般的にここを注意すればわかりやすさを確保できるだろうっていうポイントを一旦まとめておこうと思った。そうしてまとめてみると、本に限らず人に何かを伝えること一般に適用される話だなと思った。 読む側の負担を減らす わからない＝理解をはばむ障害物がある。この障害物を取り除く／回避する作業が「わかる」ために必要になる。その作業を、作者ではなく読者が負担するとき「わかりにくい」本になる。 日本社会だと情報の受け手の側がこの「わかる」ための作業を負うことでコミュニケーションを成立させる傾向にある。空気を読むというようなことだ。そのため発信者側が事前に手を尽くしてわかりやすく発信するというのが苦手で、相手が汲み取っ
説得力のある文章を書く技術――説明文の方程式 - 週刊アスキー
前回は「世界を見つめる解像度」について書きました。前回も書いたように、たくさん書くことで世の中を見つめる「解像度」が上がっていくのですが、文章を書くには最低限の技術も必要です。そこで今回は、物事を説明するための文章の書き方を説明していきます。 ■報告書やメールの書き方 まず、超シンプルですが、基本はこれです。 結論をまず書いて、それについて説明して、最後にもういちど結論をまとめます。報告書やメールなどはこのフォーマットが一番適していると思います。もちろん、メールでは、お礼や挨拶などがここにくっつきますので、お忘れなく。 よくある失敗をふたつ上げておきましょう。 失敗1：「結論」と「説明」を逆順に書く まず長々と説明を書いて、その次に結論を書くという失敗です。おそらく、わかってほしいからこそ、延々と説明してしまうのだと思うのですが、結論がなかなか出てこない文章は読んでるほうはイライラして、読
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
