Forwork

知っていることと、伝えられることは別の能力

深い専門知識があっても伝わらないのはなぜか。知識を、他者が理解し、記憶し、使える形へ変換する方法を考えます。

01

よくある逆説

10年の経験がある人でも「これはどうやって進めますか?」と聞かれると、細部を大量に話し、聞き手が何を重要視すべきか分からなくなることがあります。専門性がないのではありません。専門性と、それを伝える力が別のスキルだからです。

専門家は複数の情報層を同時に見ています。初心者はそうではありません。専門家は自分の認知モデルの内側から話すため、相手に必要な中間ステップを無意識に飛ばしがちです。

02

知る・理解する・説明する・理解してもらう

四つの段階があります。情報を 知る 。因果や関係を 理解する 。理解したことを 説明する 。そして、相手に合った言葉、例、構造を使って 理解してもらう 。

Tipsやガイド、専門的な文章が目指すべきなのは最後の段階です。読者はあなたの知識の全量を見る必要はありません。自分の問いから、使える結論まで進める明確な道筋を必要としています。

03

よくある失敗:自分の知識から始める

書き手は「自分が話したいこと」から始めがちです。しかし読者は、質問、違和感、判断できない状況から入ってきます。

「何を共有できるか」ではなく、 読者はいま何を理解し、何を解決しようとしているのか を問いましょう。すると、入れる情報、例、順番が変わります。

04

Framework: Reader → Problem → Insight → Explanation → Application

五つのステップで考えます。 Reader — 誰に向けるのか。 Problem — 何につまずいているのか。 Insight — 最も重要な気づきは何か。 Explanation — どんな論理、例、対比が必要か。 Application — 理解した後、何を変えられるか。

この型は、文章を知識の誇示ではなく、読者を前進させる道具にします。

05

個人の経験を、使える知識へ変える

プロダクトデザイナーが「私はwireframeの前に必ずユーザーインタビューをします」と言うだけでは、まだ個人の習慣です。

より使える形はこうです。「wireframeを早く作りすぎると、検証されていない仮説にチームが固定される。画面を描く前に、ユーザーが達成したいこと、障害、現在の代替手段の三つを確認する。」

経験が、他者も使える原則になります。

06

単純化は、浅くすることではない

分かりやすい説明には深い理解が必要です。本質、例外、限定的な条件でのみ必要な詳細を区別できなければなりません。

良い説明は複雑さを消しません。 読者が必要とする順序に複雑さを並べ替えます。

07

良い文章は、知識量を証明しなくていい

無意識の目的が「自分は詳しいと見せること」になると、専門用語や補足、枝分かれが増えます。目的が理解なら、情報量は減っても精度が上がります。

編集時には、 この段落を削除したら、読者は中心的な考えを理解・適用できなくなるか? と問いましょう。

08

Forwork Tipsでの応用

Forworkの良いTipsは、具体的な仕事上の問題から始まり、一つの中心的なInsightを示し、なぜ重要かを説明し、最後に適用方法を提示します。

Projectにリンクして実践の根拠を示したり、Profileで専門性を補強したり、EventやLetterで議論を広げることもできます。

09

結論

知識を伝えるとは、知っていることを短くすることではありません。他者がその知識に入っていける道筋を設計することです。

そうして初めて、経験は一人の頭の中だけにあるものではなく、読まれ、記憶され、議論され、使われ、他の仕事の証拠とつながる知識資産になります。