私はSES事業でエンジニアと一緒に仕事をしていますが、現場で「テキストコミュニケーション力の差」が評価に直結する場面を何度も見てきました。技術力は十分なのに、報告書やSlackの文章がわかりにくくて信頼を得られないエンジニア。逆に、技術は普通でも文章が的確で重宝されるエンジニア。この差は思った以上に大きい。
ライティングというと「ブロガー向けのスキルでしょ？」と思われがちですが、仕事のメール、提案資料、障害報告、議事録——全部ライティングです。
普段チームのメンバーに伝えていることを、文章を書くときに知っておくと便利なフレームワークとしてまとめました。
まず、なぜ文章力が大事なのか
リモートワークが増えた今、仕事のやり取りの大半がテキストになりました。Slack、メール、チケットのコメント、ドキュメント。対面で話していた時代は表情や声のトーンで補えていたことが、テキストでは全部「文章の質」にかかってきます。
私自身、発注側の立場でSESエンジニアの報告を読む場面が長くありましたが、正直なところ「何が言いたいかわからない」文章は珍しくなかったです。長いのに要点がない、結論がどこにあるかわからない、読み手の知りたいことと書き手の書きたいことがズレている。
これは頭が悪いとか能力が低いとかいう話ではなく、単純に「文章の型」を知らないだけのケースが多い。型を知っているかどうかで、伝わり方が全然変わります。
3種類のライティングを知っておく
文章には大きく分けて3つの種類があります。それぞれ目的が違うので、「今自分はどの種類の文章を書いているのか」を意識するだけで、ブレが減ります。
1. 人を集めるための文章
ブログ記事やSNSの投稿など、まず読んでもらうための文章です。タイトルや冒頭で興味を引かないと、そもそも読まれません。
エンジニアの仕事に置き換えると、技術ブログの記事タイトルや、社内Wikiのページタイトルがこれに近い。同じ内容でもタイトルの付け方で読まれるかどうかが変わります。
2. 理解してもらうための文章
読者の知識やスキルを底上げするための文章です。手順書、マニュアル、技術解説記事がこれにあたります。
エンジニアが一番書く機会が多いのはおそらくこの種類です。設計書、障害報告書、引き継ぎ資料。「正確で、わかりやすく、必要十分」な文章を書く力は、直接的に仕事の評価に影響します。
3. 行動を促すための文章（コピーライティング）
読者に具体的な行動を起こしてもらうための文章です。広告やランディングページが典型ですが、実は提案書や社内の企画書にも通じるところがあります。
「この技術を採用しましょう」「このツールを導入しましょう」と上司やクライアントを説得する文章は、広義のコピーライティングです。
4つの文章フレームワーク
ここからは具体的なフレームワークを紹介します。知っておくと、文章を組み立てるときの引き出しが増えます。
1. QUESTフォーミュラ
セールスの世界で使われる型ですが、提案資料や企画書にも応用が効きます。5つのステップで構成されます。
- Qualify（興味付け） — 最初に「これは自分に関係ある話だ」と思わせる。実績や具体的な数字を出すのが効果的です。「このツール導入で作業時間が30%削減できた」のような切り口
- Understand（共感） — 相手の悩みや課題に共感を示す。「毎回手動でデプロイしていて面倒ですよね」
- Educate（教育） — 解決策と、なぜそれが有効なのかを説明する
- Stimulate（想起） — 解決後の状態をイメージさせる。「自動化すれば、その時間を開発に使えます」
- Transition（行動） — 具体的な次のステップを提示する
提案書を書くときに、この順番を意識するだけでも説得力が変わります。
2. GDTの法則
人の動機を3段階で整理したフレームワークです。Goal、Desire、Teaserの頭文字。
- Goal（目標） — 人は基本的に、少ない労力で成果を得たい。「簡単に」「すぐに」が刺さるのはこの心理
- Desire（欲望） — 評価されたい、収入を上げたい、快適に暮らしたいといった欲求
- Teaser（好奇心） — 希少性や意外性への反応。「期間限定」「実は逆だった」が効くのはこの層
マーケティング寄りのフレームワークですが、「なぜこの文章が人を動かすのか」を理解するのに役立ちます。広告やLPを読むときに「あ、これはGDTのDesignを突いてるな」と分析できるようになると、自分が文章を書くときの精度も上がります。
3. 共感ライティング
読者の「でも、本当に大丈夫？」という疑問を先回りして潰す技術です。
手順はシンプルで、
- 反論を予測する — 自分の主張に対して「いや、でも…」と思われそうなポイントを洗い出す
- 共感を示す — 「そう思いますよね」と否定しない
- 根拠を添えて安心させる — データや実績で裏付ける
障害報告書にもこの考え方は使えます。「なぜその対応を選んだのか」を書くとき、「他の方法もあったのでは？」という疑問を先回りして説明しておくと、読む側の信頼感が段違いです。
4. PREPの法則
おそらく一番実用的で、一番使う場面が多いフレームワーク。
- Point（結論） — まず結論を述べる
- Reason（理由） — なぜそう言えるのか
- Example（具体例） — 実例で補強する
- Point（結論の再提示） — もう一度結論を念押し
Slackでの報告、会議での発言、設計レビューのコメント。PREPを意識するだけで、「で、何が言いたいの？」と言われることが激減します。
おわりに
ライティングのフレームワークは「知っているかどうか」で差がつく種類のスキルです。特別な才能は要りません。
ただし、知識だけでは身につきません。実際に書いて、読み返して、直す。この繰り返しでしか文章力は上がらない。ブログを書くのは、そのトレーニングとしてもかなり有効だと思っています。
まずはPREPから意識してみてください。次にSlackで報告を書くとき、結論から書く。それだけでも伝わり方が変わるはずです。
