マインドマップから文章のアウトラインを作るには、まず主な枝を読み手に伝える順に並べ、それぞれを見出しにします。子トピックは見出しの下の説明項目に、枝をまたぐ関係は短い参照に置き換えます。未解決の疑問は別の節にまとめましょう。元のマップがいろいろな方向へ広がっていても、アウトラインでは文書として順に読めることが大切です。
書き始める前に、共同編集できるマインドマップで枝を整理できます。ここでは、家族で使う買い物リストアプリの企画概要を例に、発想を広げたマップを番号付きのアウトラインへ変える方法を紹介します。報告書やプレゼンテーションの構成にも応用できます。
画面上の位置ではなく、読む順番を決める
左側にある枝が、必ずしも最初の節になるわけではありません。読み手がまず知りたいことから始めます。製品の提案なら、解決策より先に課題を説明することが多いでしょう。一方、進捗報告なら、現在の成果を冒頭に置くほうが伝わりやすい場合があります。
今回のマップは、中心テーマを「共有買い物リストアプリ」とし、「課題」「初回リリース」「リスク」「未解決の問い」の四つに枝分かれしています。これは企画方法を説明するための架空の例で、公開済みの製品に関する報告ではありません。
- 課題：家族が同じ品物を重複して買ってしまう。店内で加えられた変更を見落としやすい。
- 初回リリース：共有リスト、招待リンク、購入済みの印を付ける機能。
- リスク：オフラインの古いコピーが新しい変更を上書きする可能性。招待が意図しない相手に届く可能性。
- 未解決の問い：招待の有効期限をどうするか。同じ品物を二人が編集したらどうするか。
チームで初回リリースの範囲に合意するための企画概要なら、「課題 → 初回リリース → リスク → 未解決の問い」の順にします。同じアプリでも、サポート担当への引き継ぎ資料ならリスクから始めることも考えられます。テーマが同じでも、読み手の目的によって順番は変わります。
主な枝を見出しに、子トピックを説明項目にする
中心テーマを仮のタイトルにします。四つの主な枝は番号付きの見出しとし、その直下の子トピックを各見出しの説明項目に移します。さらに深い階層の項目は具体例や補足にできます。すべてを新しい見出しにする必要はありません。
図では対応関係を簡潔に示しました。実際の企画概要に必要な情報を加えると、次のようなアウトラインになります。
- 解決したい課題
- 家族が別々に買い物をしていても、まだ必要な品物を把握できるようにする。
- 確認が必要な問い：重複購入や更新の見落としはいつ起こり、誰に影響するか。
- 初回リリースに含めること
- 共有リスト：メンバーが品物を追加し、購入済みかどうかを確認できる。
- 招待：メンバーが別の人をリストへ招待できる。
- 購入済みの状態：別の記録を作るのではなく、既存の品物に購入済みの印を付ける。
- 初回リリースに含めないこと：レシピの提案と価格比較。
- 設計に影響するリスク
- オフライン編集：古いコピーと新しい変更がぶつかったときの扱いを決める必要がある。
- 招待によるアクセス：招待先を間違えた場合や、リンクが転送された場合の扱いを決める必要がある。
- 影響する範囲：オフライン編集は2.1の共有リストに、リンクの転送は2.2の招待に関係する。
- 実装前に答えを出す問い
- 招待に有効期限を設けるか。設けるなら、どのような条件にするか。
- 二人が同じ品物を変更した場合、どの結果を表示するか。
- それぞれの問いに答えるために、どのような情報やチームの判断が必要か。
「初回リリースに含めないこと」は、最初の図では独立した主な枝にしていません。範囲の説明の下に加えると、文書を大きく長くせずに意図を明確にできます。追加した項目によって計画そのものが変わる場合は、マップにも反映して、両者の内容をそろえます。
重複や枝をまたぐ関係を、意味を残して整理する
マップでは、一つの考えを複数の枝へつなげられます。文書では、詳しい説明を置く場所を一つに決めると読みやすくなります。読み手が最初にその説明を必要とする節へ置き、ほかの節からは短く参照します。
買い物リストのマップでは、「招待」は初回リリースに含まれる機能であると同時に、アクセスのリスクにも関係します。機能の説明は第2節に置き、第3節には「2.2の招待について、リンクが転送された場合の扱いを決める」と書きます。これなら関係を残しつつ、少しずつ異なる二つの機能説明を読み手に比較させずに済みます。
名前が同じという理由だけで、二つの項目をまとめないようにします。「更新」が品物の情報を変更することなのか、古いリストのコピーを最新にすることなのかを、変換する前に名前で区別しましょう。反対に、「二重に買わない」と「重複購入を防ぐ」がこのマップで同じ課題を指すなら、一つにまとめ、それぞれにしかない補足は残します。
役立つ情報なのに親となる項目がはっきりしない場合は、移す先を決めます。この例なら、価格比較の案は後回しにする機能の範囲へ、出典からの引用は裏付けたい主張の近くへ置きます。まだ説明できない項目は変換の途中で消さず、「未解決の問い」に残します。
読み手に必要な部分だけ、短い言葉を説明文にする
マップの短いラベルは、考えるための手掛かりであり、完成した説明ではありません。「オフライン」だけでも作成者には通じるかもしれませんが、チームメンバーには条件と影響が必要です。「オフラインの編集が新しい変更と競合する可能性があるため、再接続した利用者に何を表示するかを決める」とすれば、解決済みであるかのように書かずに、設計上の問いを伝えられます。
補足は、次の三つを区別すると整理しやすくなります。
- 説明：その項目が、今回の例で何を意味するか。
- 根拠：主張を支える出典、観察、引用。リンクや参照情報を該当項目の近くに残す。
- 未解決の問い：何が分かっておらず、何があれば答えを出せるか。
変換するときに、可能性を事実へ変えないことも大切です。「利用者が変更を見落とすかもしれない」という枝を、「利用者は必ず変更を見落とす」と書き換えてはいけません。まだ調査していないなら、調べたい課題と、判断に役立つ観察内容を書きます。
マップとアウトラインを並べて見直す
元のマップを見える状態にして、文書に番号付きの構成を書きます。Boardmixでは、共有ボード上で枝のまとまりを話し合い、説明が必要な考えの近くにコメントを残せます。アウトラインは、チームが最終的な企画概要を書く文書に置いたままで構いません。ボードからその文書へリンクして、編集する場所が分かるようにします。
枝を一つずつ見ながら、子トピックの移し先をアウトラインの中で確認します。その後、マップを見ずにアウトラインだけを読みます。離れた枝の説明を聞かないと分からない節があれば、その説明を前へ移すか、短い参照を加えます。
これは、構成を考えながら手動でまとめる方法です。マップを画像やPDFで保存すると見た目は残せますが、編集できる番号付きアウトラインとは異なります。他のツールのアウトライン出力を使う場合も、画面上の配置が適切な説明順へ変わっているとは限らないので、出力された階層と順序を確認してください。
順序が整ったら、企画概要の目的に沿ってチームメンバーに読んでもらいます。初回リリースに含むもの、含まないもの、判断が残っているものを説明できるでしょうか。答えが見つからない場合は、該当する節の内容を補います。見栄えのために枝を増やす必要はありません。
自分のマップに使えるアウトラインのひな型
次の構成を文書へコピーし、見出しを自分のマップの主な枝に置き換えてください。
- 目的・課題
- 誰が、どのような場面で、何を必要としているか。
- それを支える観察や出典は何か。
- 提案する方法・主な知見
- 一つ目の要点と、その補足。
- 二つ目の要点と、その補足。
- 対象範囲：何を含め、何を含めないか。
- 制約・代替案・リスク
- 解釈を変える条件や、方法の限界は何か。
- それぞれの制約は、前のどの節に関係するか。
- 未解決の問い・次に決めること
- まだ何が分かっていないか。
- 何があれば答えを出せるか。
学術的な文章なら、主張、根拠、反論などに合わせて枝を変える必要があります。枝分けの基本から確認したい場合は、マインドマップの書き方と企画メモの整理例が参考になります。会議の記録を扱う場合は、会議メモをマップに変えるガイド（英語）で、その前段階に当たる決定事項と疑問の分け方を説明しています。
