デロイトの351ページ資料は「7つの型」だけでできていた ─ note記事からSVG図解スキルに足りない要素を洗い出した

開発claude-code-tools

デロイトの351ページ資料は「7つの型」だけでできていた ─ note記事からSVG図解スキルに足りない要素を洗い出した

デロイトが経産省に納品した351ページの資料を分析したnote記事を読んだ。結論は、自分が使っているsvg-diagram図解スキルに「出典表記」がまるごと抜けていたこと、それと「論証テーブル」という型がスキルに定義されていなかったこと。この2点は実際にスキルへ反映した。加えて、論証テーブルを作る過程で、マゼンタ強調のやり方そのものに安直な癖があるのも見つかり、そちらも直した。逆に、記事にあった「色帯で主張を強調する」「■マーカーで断定文を作る」「赤字で更新箇所を示す」といった手法は、今の運用には合わないと判断して見送った。

最初はスキルファイルを書き換えず、判断の経緯を残すためのメモとして書き始めた記事だが、話しているうちに直した方がいい点が固まったので、書いている途中でそのままスキル本体(SKILL.mdreferences/配下)に反映した。

元記事の要点

記事は、351ページの資料を分類したところ、使われている型が7種類しかなかったという調査結果を紹介している。使用頻度は次の通り。

頻度構成
論証テーブル45%課題→現状→打ち手の3列
データチャート11%グラフ+「So What」注釈が必ずセット
○×比較9%評価軸を統一し○△×で埋める
中扉10%ほぼ白紙、セクションの区切り
絵解き8%アイコン+矢印で全体像。冒頭専用
フレームワーク7%2軸マップ等、絞り込みの場面だけ
ロードマップ7%スイムレーンで主語(誰が)を分離

一番多いのは装飾性ゼロの表(論証テーブル)だという点が記事の主眼で、「一流ほど基本の型を使い倒す」という一文に集約されている。7つの型は文章で読んだだけでは構造の違いが頭に残りにくいので、テキストを抜いて背景色のブロックだけでレイアウトの骨格を並べてみた。

デロイト資料に見つかった7つの型のレイアウト早見図
図1: 7つの型は装飾ではなくブロックの分割の仕方(列で割る・軸で割る・レーンで割る)が違うだけで、頻度45%の論証テーブルが最も単純な3列構造にすぎない

もうひとつの柱が、全ページ共通の「5点骨格」。

  1. タイトル(14〜20字)
  2. リード帯 ─ 主張を1行で言い切る帯
  3. ヘッドメッセージ ─ ■付きで「〜と考えられる」と断定する文
  4. ボディ ─ 表や図はここだけ
  5. 出典 ─ 全ページ例外なし

「表や図を見なくても上の3行で結論が読める」という設計で、出典は全ページに例外なく付けると明記されている。この5要素がページのどこにどう積み上がるかも、同じやり方で図にしておく。

全ページ共通の5点骨格(タイトル・リード帯・ヘッドメッセージ・ボディ・出典)
図2: タイトル・リード帯・ヘッドメッセージの3行だけで結論が読め、根拠となる表や図はボディに封じ込め、出典は末尾に必ず置く

自分のスキルと突き合わせる

手元のsvg-diagramスキルには、色(グレー8段階+マゼンタ4段階)、テキストサイズ、viewBoxとグリッド、矢印の直角コネクタ、1図1メッセージの原則など、実装レベルの規律はすでにかなり細かく入っている。元記事と突き合わせて見えた抜けは、「出典」と「型のカタログ」の2箇所だった。

抜けていた: 出典表記

一番はっきりした抜け漏れがこれだった。データチャートの数値をどう描くかのルール(本体に数値を直接描く、ホバー依存を禁止する等)はすでにあるが、「どこから取った数値か」を図の中に明記するルールがどこにもない。beat-monitoringの決算チャートのように、数値そのものが記事の主張になる図解では効いてくる欠落だった。単に文字で出典を書くだけでなく、元がWeb上のデータならURLをリンクにする、というところまでルールに含めたい。

未収録だった型: 論証テーブル・So What注記・○×評価表

図解の型を選ぶためのボキャブラリー集にも、「課題→現状→打ち手」を3列で固定した型は入っていなかった。頻度45%という実務データを見ると、優先して型として持っておく価値がある。

データチャートについては「数値をチャート内に直接描く」というルールはすでにあるが、「主張そのものを注記ボックスとして図の中に置く」という具体的な実装パターンまでは踏み込んでいなかった。元記事の「グラフは主張の証拠品」という言い方がそのまま使える。

○×比較も同様で、対比図の高さ整合や反復ラベルの太字禁止のルールはあっても、○△×で埋める評価表そのものの型は明文化されていなかった。

見送った点

記事にあった手法のうち、次の3つは今回は取り込まないと判断した。

  • 色帯で主張を強調する「リード帯」: 手元のスキルには「カードのフチに色をつけない」「原色を混ぜない」という禁止事項がある。色面での強調はこの禁止事項とぶつかる可能性が高く、グレー濃淡とマゼンタ1色の枠内でどう表現するか詰めないと安易に真似できない(上の図2ではマゼンタ1色の帯として再現したが、実際に自分のスキルへ採用するかは別途詰める)
  • ■付きの断定文: 提出資料としての文体で、ブログ記事の図解キャプションには堅すぎる
  • 赤字での更新箇所の上書き: バージョン管理された社内資料の運用で、単発公開のブログ記事には出番がない

論証テーブルの列見出しと、マゼンタ強調の使い方を作り直す

論証テーブル型をスキルに追加する前に、「課題→現状→打ち手」を固定ラベルとして刻んでいいのか迷った。自分が扱う記事は提案書だけでなく要約・分析も多く、この3つのラベルが常に当てはまるとは限らない。

doc-communicationスキルのstory.mdを読み直すと、この3列構造自体が「状況→解釈→行動」という定番の骨格の1バリエーションだと分かった。定番パターン(原因対応型・大転換要求型・変化適応型・チャンス開拓型)は、いずれも3ステップの論証構造を持っている。「課題→現状→打ち手」はそのうちの原因対応型を提案書向けに言い換えたものにすぎない。

そこで論証テーブル型は、列見出しを固定せず「3列で完結する論証構造」という構造だけを定義し、列見出しは記事の主張構造に応じて選ぶことにした。ただし、doc-communicationスキルには「フレームワーク語彙を読者向けの図解ラベルにそのまま出さない」という禁止ルールがあるので、列見出しには「状況」「解釈」「行動」という言葉自体は使わず、記事の中身に応じた具体語に翻訳する。

もう一つ、論証テーブルの図を作る過程で気づいた点がある。最初のバージョンは「打ち手(結論)列」を丸ごと薄いマゼンタの背景で塗って強調していた。これに対して、強調ポイントはマゼンタでいいとしても、必ずしも列全体を塗る必要はなく、文字色をマゼンタにする方がいい場合の方が多い、という指摘を受けた。

たしかに、列全体を背景色で塗ると、その中のどの語句が重要なのかがかえって伝わらない。強調はまず「語句・数値・短いフレーズの文字色をマゼンタにする」で行い、背景(面)での強調は、独立した1枚のカードやバッジを他と区別する必要がある場合だけの例外にする、という優先順位に直した。上の図1・図2はこの直し方を反映した状態になっている(論証テーブルの3列は同じ背景のまま、結論列の中の語句だけが文字色で強調されている)。

スキルに反映した内容

実際にsvg-diagramスキル本体に反映したのは次の3点。

  1. 出典表記ルールの追加: URLがあれば必ずリンクにすることを明記
  2. 論証テーブル型の新規ファイル化: 列見出しを固定せず、doc-communicationの定番パターンから記事の主張構造に応じて選ぶ設計にした
  3. マゼンタ強調の優先順位の見直し: 文字色での強調を基本形とし、背景(面)での強調は独立した短い要素を区別する場合だけの例外にした

まだ反映していないのは次の2点。

  • データチャートのSo What注記ボックスの明文化
  • ○×評価表型の追加

こちらは追って必要になったタイミングで反映する。