■ 1. 記事の概要
- タイトル: 言語化に苦しむ全ての人(エンジニア？)へ。今日から変わるコミュニケーション術補遺
- 著者: ココナラ DevOpsグループCREチーム y.s.（@inu_no_hou）
- 公開日: 2026年4月20日
- テーマ: communication・mindset・technical writing
■ 2. 概念操作の手法
- 基本テーゼ:
- 言語化とは「概念操作とその操作結果の伝達」である
- 概念操作力とその伝達力の二軸を鍛えることが重要
- 主観と客観の整理:
- 主観は自分のみで有効であり、客観は広く妥当する可能性が高い
- ビジネスで求められる数値化やファクトとオピニオンの分離はこれに該当
- 抽象化:
- 個別概念を削り落とす工程
- 例: 「林檎2つ、バナナ3つ」→「果物5つ」
- 一般化:
- 抽出した本質を複数の具象に当てはめる操作
- 例: Tシャツの本質（襟なし・T字型・かぶり式）は生地や色を変えても成立
- 例え話:
- 概念構造が瑣末な変更を経ても同一であることを利用する手法
- 具体と抽象を行き来する能力を磨くことに有効
- メタ化:
- 「本当だろうか？」という問いで自分の概念体系全体を問題化する
- 問いの次数を上げ下げして視点を調整する
- 結論:
- 概念操作力とは「具体と抽象を反復横跳びする筋力」であり日々の鍛錬が必要
■ 3. テクニカルライティングの鉄則
- 基本原則:
- 文章の目的は読者が「わかった・できた」となること
- 自分の賢さの披露や情報の網羅は目的ではない
- 7つの鉄則:
- 短く書く: 1文=1アイデアとし文・語・段落を全て短くする
- 能動態で書く: 「誰が」「何をした」を明確にする
- 強い動詞を使う: be動詞やoccurではなくgenerate・trigger・deleteなど具体的な動詞を用いる
- 無駄を削る: 冗長な修飾語や形容詞を排除し数字を活用する
- 構造で見せる: 見出し・リスト・表で情報を構造化する
- 読者を意識する: 対象読者の知識レベルを把握して執筆する
- 一貫性を守る: 同じ概念に同じ用語を使い続ける
■ 4. セルフ編集チェックリスト
- 文の構造:
- 1文1アイデアを守り複数概念を1文に詰め込まない
- 受動態を能動態に変換する
- be・occur・happenなど弱い動詞を回避する
- 「There is/are」を削除し主語を前面に出す
- 冗長表現を削除する（「in order to」→「to」・「make use of」→「use」）
- 語彙と用語:
- 表記ゆれを避け初出時にフル名と略称を定義する
- 頭字語は初出時に正式名称を説明する
- It・This・They等の代名詞を具体的な名詞に置き換える
- 形容詞を数値化する（「very fast」→「225-250%高速」）
- 段落構成:
- 冒頭文で内容を予告し読者が先頭文のみで内容を判断できるようにする
- 1段落1トピックを原則とし3〜7行を目安にする
- 見出しとリスト:
- 見出しは内容を正確に予告する（「Details」×→「Configure the database connection」◎）
- リストの並列構造を統一する（名詞のみ・命令形のみなど）
- トーンと表現:
- ユーザーを責めない表現を使う（「Invalid ID」×→「You need an ID that looks like...」◎）
- pleaseの過剰使用を避ける
- ジェンダー・文化バイアスを排除する（he→you）
- エラーメッセージ:
- 「何が問題か」と「どう直すか」の2点セットで構成する
- 例: 「Error: Invalid input」×→「Can't save because file name contains invalid characters. Remove: / \ : * ? "」◎
- グローバル対応:
- 文化固有表現を排除する（「a piece of cake」→「simple to set up」）
■ 5. LLMをテクニカルライティングに活用する方法
- 活用場面:
- 初稿生成: 立場・対象読者・形式を指定して生成する
- 文書推敲: 受動態検出・文法チェック・スタイル統一に使用する
- フォーマット変換: Word→Markdownなどの形式変換に使用する
- 要約: 長文の要点整理に使用する
- 注意点:
- LLMはハルシネーション（虚偽出力）があるため事実確認が必須
- 「提供テキストの情報のみ使用」と制約を明示する
- LLMに書かせすぎるとメタ認知のメリットが消失する
■ 6. テンプレート集
- 技術ドキュメント: 概要・対象読者・前提知識・対象範囲・セクション・関連リソースで構成
- APIリファレンス: メソッド名・構文・パラメータ表・戻り値・例・備考・関連項目で構成
- エラーメッセージ: 何が問題か・なぜか・どう直すかの構成で良悪例を含む
- How-toガイド: タスク名・前提条件・手順・確認方法・トラブルシューティング表・次のステップで構成
- リリースノート: 新機能・改善・バグ修正・破壊的変更・既知の問題・アップグレード手順で構成
- トラブルシューティングガイド: 症状・原因・解決策・未解決時の対応で構成
■ 7. 結論
- 概念操作もテクニカルライティングも単なる筋トレであり継続的な実践が重要
- 日々の鍛錬は裏切らないと著者は強調する