こんにちは。みきです。
皆さんは普段の業務で、文章を作成する場面はありますか？
メール作成、提案資料の作成、手順書作成など。
PCを使ってお仕事をする方なら、毎日文章を作成する機会があるのではないでしょうか。
通常の文章作成はもちろんのこと、専門的な内容や技術的な情報を、わかりやすく正確に伝えるのは難しいですよね。
私はSaaSのテクニカルサポートの仕事をしています。
日々の問い合わせ対応での回答文作成やユーザーマニュアル、FAQの記事作成なども行っており、いかにわかりやすく、簡潔に説明できるか、日々試行錯誤しています。
実は、わかりやすく伝える力は、「テクニカルライティング」を学ぶことで強化することができます。今回は、テクニカルライティングについてのポイントや、場面ごとで気をつけたいことについて、ご紹介します。
テクニカルライティングとは
技術的な情報を、わかりやすく伝える文章作成テクニック
「テクニカルライティング」とは、技術的な情報を簡潔でわかりやすく伝えるための、文章作成のテクニックのことです。
テクニカルライティングの手法は、製品の取扱説明書やユーザーマニュアル、障害報告書など、多くの場面で活用されています。
テクニカルライティングは「センス」ではなく「技術」
「私は文章を書くのは苦手だから・・・」と言う人もいますが、詩や小説を書くのとは違い、技術文章を書く力は「センス」ではなく「技術」なんです。
私は社会人１年目の頃、ITに関する問い合わせ対応を行う部署に配属となりました。
ある日先輩から「メールで問い合わせが来ているから、返信してみて」と言われて、30分間自分自身のメール文を添削し続けたことがありました。
「あーでもない、こーでもない」と考えながら修正しましたが、「これでよし！」と思える文章は書けませんでした。
それもそのはず。当時の私は「型」を知らなかったからです。
文章作成に完璧な答えはありませんが、わかりやすい文章が書ける「技術」は存在します。技術を学んで、わかりやすい文章を作成しましょう！
テクニカルライティングのポイント
「一文一義」で書く
これは「一文につき、一つのメッセージに絞る」という意味です。こうすることで何を伝えているかが読み手にわかりやすくなり、また誤解を与えにくくもなります。
悪い例：プールで走ると滑ったり転んだりして、怪我をしますし、他人に迷惑がかかる可能性があるので、プールでは走らないように気をつけてください。
良い例：プールでは走らないでください。滑ってケガをする恐れがあります。また、他の人にぶつかって、ケガをさせる場合もあります。
1文は50文字程度を目安に、長くしない
1文が長くなると、読み手が理解しづらくなります。50文字以内を目安にして、簡潔に表現しましょう。
悪い例：弊社の採用管理システムですが、他の転職システムとの外部連携ができることはもちろんのこと、直感的に操作しやすいUI・UXになっているなど、採用ご担当者様からも大変ご好評いただいており、そこが弊社の採用管理システムの強みです。
良い例：弊社の採用管理システムをご紹介します。特長は２つあります。１つ目は、他のシステムとの外部連携ができることです。２つ目は、直感的に操作しやすい画面設計になっていることです。これらの特長から、採用ご担当者様からも、大変ご好評いただいています。
タイトルから、文章の目的がわかるようにする
読み手が文章のタイトルを見た段階で、その内容や目的が理解できるようにタイトルを工夫しましょう。
悪い例：dbサーバーの不整合について
良い例：【報告書】データベースサーバーの障害について（2024年8月1日発生）
ユーザーマニュアルのポイント
ここからは、具体的なシーン別に気をつけたいポイントをご紹介します。
まずは「ユーザーマニュアル」作成時を例にお話します。
「読み手」と「目的」を意識する
マニュアルを作成する際は、読み手の知識レベルや、マニュアルを使用する目的を明確に意識することが重要です。
例えば、専門用語をいきなり使うと、読み手によっては理解されにくいかもしれません。
また、読み手が「フォルダの名称を変更したい」と思っているのに対して、ユーザーマニュアルの章のタイトルが「フォルダについて」だと、読み飛ばしてしまうかもしれません。
このように、読み手の「気持ち」や「目的」を考えた上で、マニュアルを作成することを心掛けましょう。
全体の構成を設計する
一からマニュアルを作成する場合は、まずマニュアル全体の構成をしっかり設計しましょう。
例えば、管理者向けの内容と、一般ユーザー向けの内容が同じマニュアルにまとまっているのではなく、管理者向けと一般ユーザー向けの内容を章ごとに分けたり、マニュアル自体を分けた方がわかりやすいです。
読み手が必要な情報にすぐにアクセスできるように設計しましょう。
どのような場面でマニュアルを読むか想定する
マニュアルを使用する場面を想定して、理解しやすい表現や流れを意識しましょう。
緊急時や操作中にも役立つ内容にすることがポイントです。
このように、ユーザーマニュアルを作成する場合は、「読み手」と「目的」を意識し、
「読み手」の立場で構成にして、具体的にマニュアルを読む場面を想像しながら文章を作成することがポイントです。
障害報告書のポイント
続いて、システム障害の際などに書く「障害報告書」作成のポイントについて見ていきます。
わかりやすく書く
基本的なことですが、障害報告書は「わかりやすく書く」ことがポイントです。
当たり前に思われるかもしれませんが、実はわかりやすく書けていないことも多いのがこの障害報告書。
その理由として、障害報告書の作成者がシステムの構成に詳しい技術者が書く場合があり、その人が文章作成技術には長けていない、と言う場合が挙げられます。
また、障害が発生した場合、障害対応でバタバタしてしまい、障害報告書のわかりやすさまで気が回らないこともあります。
そのような内部事情から、わかりにくい障害報告書が完成してしまうこともあるようです。
お詫び→概要→原因→再発防止策→お詫びの順で書く
障害報告書の基本的な型を抑えましょう。
お詫びで始まり、障害の概要、原因、再発防止策、最後にもう一度お詫びを述べる形が一般的です。
もう少し詳細に書く場合は、時系列に発生したことや対処したことを書く場合もあります。
各社のフォーマットに従って作成しましょう。
担当者の上司や経営層が見てもわかるように書く
障害報告書は、顧客の担当者だけでなく、上司や経営層が読む場合もあります。
そのため、担当者には通じる専門用語も、経営層が読むと伝わらない場合もあります。
そのシステムをよく知らない人が読んでも理解しやすいように、専門用語や略語などは避けて記載しましょう。
以上が、障害報告書を作成する際のポイントです。
ここからは、障害報告書を作成する際、NGパターンについて、具体的に見ていきましょう。
NG①：言い訳や責任逃れの印象を受ける
障害の発生原因を「他ベンダーのオペレーションミスでした」として締めくくってしまうなど、自社に落ち度はなかったような印象を受ける表現は避けましょう。
誠実さが欠けますし、今後も同じような障害が発生してしまうのではないか？と心配になってしまいます。
「他ベンダーのオペレーションミスですが、チェック体制が不足していました」など、事実は事実としつつ、自社の責任や落ち度についても明記しましょう。
NG②：約束できないことを対策にする、もしくは自己防衛しすぎる
再発防止策で「2度と障害を起こしません」などと書いてしまうのも問題です。どんなに注意しても、障害を０にすることは出来ないからです。
また、約束できないからといって、「障害は今後も起こり得ます」などと記載してしまうと、それは顧客を不安にしかねないので避けましょう。
対策は実現可能なこと、行動できることを対策にします。
【まとめ】テクニカルライティングを身につけて、業務に活かそう！
テクニカルライティングは、ビジネスや日常のコミュニケーションでも役立ちます。明確で簡潔な文章を書くスキルを習得し、業務効率を向上させましょう！
最後に、今回の記事作成にあたり参考にした書籍と、テクニカルライティングの資格を紹介します。
参考文献
初心者にもわかりやすく、読みやすいので、おすすめです。
