導入事例の書き方

取材でよい話が聞けても、文字起こしを整えただけでは読みやすい導入事例になりません。話し手は思い出しながら話すため、時期が前後したり、同じことを別の場面で説明したりします。

書くときは、その人が伝えたかったことを確かめながら、初めて読む方が理解できる順に組み立てます。文章を滑らかにするために、聞いていない理由や成果を足さないことも、編集の前提です。

まず、事実・評価・未確認を分ける

取材メモを読み、確かめられた事実と、話者の評価、追加確認が必要なことを分けます。この区別がないと、本人の印象を客観的な効果のように書いてしまうことがあります。

数値、製品名、役職、時系列は、原稿の最後にまとめて調べるより、この段階で確認箇所として残しておく方が見落としを減らせます。

話した順番から、経緯が伝わる順番へ

次は説明用の架空の取材メモです。

「今は申請者が画面で進捗を見られます。拠点ごとに申請の項目が違っていたんです。ワークフローを入れる前は、進捗について管理部門に問い合わせが来ていましたね。まず一部門で試して、入力するときに分かりにくい項目を直しました」

この順番のままでは、現在、導入前、試用時の話を行き来します。メモにある内容を、導入前から現在へと並べ直してみます。

導入前の状況、試用時の工夫、現在の使い方を追いやすくなりました。ただし、このメモだけでは、問い合わせが減ったか、どの部門まで利用が広がったかは分かりません。そこまで書く場合は追加確認が必要です。

地の文とコメントに、別の役割を持たせる

事実関係を地の文で説明し、判断や実感をコメントで伝えると、同じ内容の繰り返しを減らせます。本文で説明した直後に、ほぼ同じ言葉の引用を置く必要はありません。

例えば、導入の工程は地の文で短く伝え、「最初から全拠点に広げなくてよかった」という担当者の振り返りをコメントで残します。なぜそう感じたかを前後に添えると、その人の経験として読めます。

同じ発言でも、記事の中心に置くか、経緯を補うコメントにするかで構成は変わります。取材相手が繰り返し話したことや、振り返って初めて言葉にしたことに目を向け、その背景を読者がたどれる順番を考えます。印象的な一言だけを見出しにして、本文から理由が抜けないようにします。

記事の形式も、残したい話に合わせて選べます。複数人を取材したからといって、必ず対談形式にするわけではありません。個別の経験を一つの経緯にまとめたいなら、地の文と各人のコメントを組み合わせる方法もあります。

「です・ます調」か「だ・である調」かは、これとは別に媒体の語り口として決めます。地の文が常体、コメントが敬体という組み合わせも自然です。語尾を機械的にそろえるために、話者の声を変える必要はありません。

専門用語は、読者が迷う場所で補う

すべての技術用語に長い説明を付けると、話が進まなくなります。想定する読者に必要な説明を、用語が初めて登場する場所で短く添えます。

システム名を並べるより、それぞれが何を受け持つかを示した方が理解しやすい場合もあります。データの流れが主題なら図版、比較した条件が主題なら表も使えます。説明の形は、デザイン・レイアウトと合わせて考えます。

社内だけで通じる略語や、業界によって意味が違う言葉は、確認してから使います。読みやすい言葉に置き換えた結果、技術的な意味が変わっていないかにも注意が必要です。

見出しと冒頭を書き、原稿を推敲する

本文の流れが固まってから、見出しと要約を書きます。見出しだけで課題から変化まで追えるか、要約で成果を強く言いすぎていないかを読み直します。

推敲では、一文ずつより先に全体を見ます。その後で、長い文や重複、不自然な語尾を直します。

• 最初に示した課題に、後半で答えられているか
• 選定理由と製品の一般説明が混ざっていないか
• 誰の発言・判断・実感なのかが分かるか
• 数値の対象と時期、効果が出た条件が残っているか
• 同じ説明が見出し、要約、本文で過度に重なっていないか
• 音読すると引っかかる長い文や、同じ語尾の連続はないか

最後に、取材記録と照合します。文章だけがきれいになっても、本人が伝えたかった意味から離れていたら戻す必要があります。公開前には、取材先を含む原稿確認を行います。