仕事柄、書籍の構成案の作り方を相談されることもよくあるので、実例も交えつつ説明してみたいと思います。
まず基本として、構成案の作り方は書籍のタイプによって主に3通りあります。
1. 入門書の構成案
入門書は全部を教える必要はないので、まず書籍のゴール（読者が何をできるようにするか）を決めます。あとは、スタート時点の読者のペルソナ（何を知っているか）を決め、そこからゴールまでの間で教える必要があることを、順に知識が増えるように並べていきます。
2.逆引き本（Tips本、テクニック集）の構成案
逆引き本の場合は、まずネタを大量にピックアップします。あとはなるべく量が同じぐらいになるようジャンル分けしていきます。各ジャンル内では、基礎技→応用技の順にネタが並ぶとベターです。解説対象によっては、先にジャンル分けを決めて、その中でネタを考えていくというやり方もアリです。例えばExcelなら、「統計関数」「文字列関数」などのジャンル分けを決め、その中でネタを考えていきます。
3.網羅型（リファレンス）の構成案
網羅型は特定のアプリなどの全機能（少なくとも7、8割程度は）を解説する書籍です。まず、ツールボタンからメニュー項目、設定ダイアログなどを見て、すべての機能をピックアップします。あとは逆引き本と同じように、ジャンル分けして並べ替えていきます。
基本だけではイメージしにくいかと思いますので、過去に作った構成案を例に、具体的な例を挙げてご説明しましょう。
効率計算で作る——ふりがなプログラミングのPythonとJavaScript
ふりがなプログラミングの最初の2冊は、営業戦略的に2冊同時に刊行しようという話になっていました。こういう場合、構成案レベルから制作効率を優先して計画を立ておかないと、絶対に成功しません。そこで構成案を作るにあたって2つの方針を立てました。
1. フォーマットが奇抜なので、構成やサンプルはオーソドックスに。ふりがなをふりやすいことを最優先にする
プログラミング入門書でオーソドックスな構成とは、「計算」「変数」「分岐」「順次（繰り返し処理）」「関数／メソッド定義」の順番で解説することです。最終章のみ言語の特徴に合わせた章を設けることにしました。
オーソドックスな構成は必ずしもベストではありませんが、長く使われてきた実績があります。また、執筆する側としても説明し慣れているので早く書けるというメリットがあります。
2. 可能な限り2冊の解説を共有できるようにする
どのプログラミング言語でも、基礎部分は共通点が多いので、なるべくまとめられるようにします。具体的には先にPythonを執筆し、章単位でJavaScriptに作り替えていきました。
※以下の構成案PDFは、下のリンクをクリックすると別のタブで開きます。
構成案と一緒にスケジュール表の一部が残っていました（今見るともう同じペースではできないなと感じます……）。こういう並列案件は1つのスケジュール表にまとめると管理が楽ですね。
感情で作る——InDesignレッスンブック
『InDesignレッスンブック（ソシム社、2017年刊）』は網羅型の書籍です。なので、「機能のフルピックアップ」「ジャンルごとに分ける」「それに合わせてサンプルを作る」という流れで作りました。機能が多いので、フルピックアップまでは手分けしてやった記憶があります。
ふりがなプログラミングの構成案は「効率計算」で作りましたが、こちらは主に「怒りの感情」を込めて作っています。というのは、当時は外部から支給されたデザインフォーマットを元に組版する仕事が多かったのですが、InDesignデータでもらってもスタイル設定などが不適切なことが多く、DTPする前に1～2日掛けてファイルの再調整をする必要がありました。まだ自分でDTPもやっていた時代だったので、フラストレーションがたまっていたのです。
DTP作業をしなくなった現在の立場で冷静に考えると、組みやすいデータというのはプロダクションごとに結構違いますし（リブロワークスの場合はインライン偏重型で、見出しでも画像でもたいていはインライン配置にします）、デザインの良し悪しと組みやすさはまったく関係がないので、しょうがないかなと思っています。
ともあれ当時はかなり困っていたので、それが構成案冒頭の「（ページ）量産ツールであることを意識」「あなたそれ、数百ページにわたって設定できますか？」というメモに表れています。小見出しに手詰めカーニングがかかっているフォーマットが届いて、「これを全ページでやれと？」みたいなことがよくあったわけで、そこはご推察、ご容赦ください。
少々感情が入っていますが、InDesignが、IllustratorやPhotoshopと大きく違うのは、デザインツールというよりは、デザイン指定に沿ってページを量産するツールだという点は、間違いないところかと思います。
ふりがなプログラミングに比べて備考欄のコメントが長く、ところどころ感情がだだ漏れていますね。ただ、「こういうデータにしてほしい」という主張を、理詰めでまとめることはできたかなとは思います。
増刷はかかりませんでしたが、今でも社内の学習に使っていますし、少なくとも執筆したことでかなりスッキリしました。毒が出きってしまったのか、この頃からInDesignをあまり触らなくなった気がします。
構成案に込めるべきことは、本や著者の方針によってさまざまです。「楽しさを教えよう」「啓蒙しよう」「講座で使いやすくしよう」などいろいろあります。構成案作りは本に魂を込める重要な作業なので（極論すれば執筆とは構成案で作った見出しの「間」を埋める作業です）、心を込めて作るのが大事かなと思います。