スキーム図とスキーマ図は、区別を覚えるより現場での意味を一行で決める

スキーム図をください、と頼まれたとき、相手が欲しいのが箱と矢印の全体像なのか、テーブル定義の入った設計図なのかは、聞いてみるまで分かりません。二つの図の区別は教科書の上でははっきりしていますが、現場の言葉としては定着していないからです。この記事では、語源と図の中身を確かめたうえで、区別を覚えるより、自分の現場での意味を一行で固定する方が事故を防ぐ、という見方を示します。

語源の上では、計画の図と構造の図です

スキーム（Scheme）という英語には、計画、枠組み、概要をまとめる、といった意味があります。動詞では「策略を立てる」というやや否定的な響きもありますが、図の文脈では全体を見渡して計画するという意味が強くなります。スキーム図は、システム全体の流れや大まかな枠組みを、ブロックと矢印で示す図です。細部を省き、何がどちらへ流れるかを一目でつかめることが大事で、配色やアイコンで分かりやすくする工夫も歓迎されます。

スキーマ（Schema）は、形、図、構造を意味するギリシア語のσχῆμα（スケーマ）に由来します。心理学のスキーマ理論のように概念の構造を指す言葉としても使われ、ITやデータベースの分野では構造の定義を指します。スキーマ図は、モジュール、クラス、テーブルといった実際の構造を描き、列名や型、一対一、一対多、多対多のような関係まで厳密に書きます。ER図は代表的なスキーマ図で、データベースの設計図をデータベーススキーマと呼ぶのはよく知られた例です。ネットワークやシステム構成のスキーマ図では、サーバーの配置や振り分けといった物理的な構成まで描きます。

段階ごとの持ち替えは、言葉がそろって初めて機能します

教科書的には、企画や要件定義の段階はスキーム図で大枠をそろえ、詳細設計と実装ではスキーマ図で構造を固め、運用と保守ではスキーマ図で障害の原因を探し、規模の拡大や再設計のときにスキーム図で全体を描き直す、と整理されます。

問題は、この整理の前提である言葉の意味が、現場ごとに揺れていることです。日本では、スキーム図を「ざっくりした図」と受け止める人が多く、スキーマ図という言葉はデータベース設計の文脈でしか使われないことがほとんどです。基本設計書の図をスキーム図、詳細設計書の図をスキーマ図と呼ぶ現場もあります。海外ではUMLのクラス図などをschemaと呼ぶ場合もあります。同じ単語で別の図を思い浮かべた二人が、同じ会議で頷き合っている。名前の似た二つの言葉の区別は、両方の意味を知っている人の間でしか機能しません。

区別を覚えるより、現場での意味を一行で固定します

だから、正しい区別を覚えるより先に、自分たちの案件でその言葉が何を指すかを一行で書いて共有する方が確実です。たとえば、この案件でスキーム図とは要素7つ以内で業務の流れを示す図、スキーマ図とはテーブルと列と型と関係を示す図、と決めます。発注の書類に「スキーム図一式」とだけ書いて納品物で揉めるのは、図の問題ではなく言葉の定義の問題です。

図の種類ごとの運用の違いも、この定義に書き込んでおくと効きます。スキーム図は方針転換や機能追加のときに直し、PowerPoint、Keynote、Lucidchart、Draw.io、Miroのような見た目を整えやすく共同編集しやすい道具で描かれることが多い図です。スキーマ図はコードやインフラが変わるたびに更新するのが望ましく、Visio、PlantUML、MySQL Workbench、pgAdmin、Graphvizのような構造を正確に表せる道具で描き、Gitなどで版を管理しておくと最新を参照できます。細かさの加減も逆向きで、スキーム図は細かく描きすぎると見る人が迷い、スキーマ図はあいまいにすると実装で誤解と手戻りを生みます。

AIにも、図の名前ではなく中身で頼みます

生成AIも、人間と同じ揺れを抱えています。学習した文章の中で、スキーム図とスキーマ図はさまざまな意味で使われているからです。図の名前だけで頼むと、どの意味の図が返ってくるかは運しだいです。名前ではなく中身を指定します。

会員管理の仕組みを、技術者向けの図として描いてください。テーブルごとに列名と型、主キーを書き、テーブル間の関係は一対多などの記号で示してください。PlantUMLのコードで返してください。

図の記述コードで返してもらえば、そのまま版の管理にも載せられます。

もっとも、チームの全員が同じ教育を受け、言葉の意味がすでにそろっている現場なら、定義を書く手間は省いてかまいません。定義が効くのは、部署や会社をまたいで図を受け渡すときです。自分の現場の言葉がどの程度揺れているかは、実際に何人かに聞いてみるまで分かりません。

あなたの現場で、スキーム図という言葉を三人に説明してもらったら、同じ図が三つ描かれるでしょうか。発注書や議事録の中で、意味を確かめないまま使われている図の名前はどれでしょうか。

この記事の背景にある考え方は、拙著『GoogleのAI NotebookLM 意思決定の強化書』の1章1節「意思決定の構造と前提の要素」に書きました。業務効率化という一つの言葉で、残業削減を思い浮かべる人とミスの削減を期待する人がいる、という例から、重要な言葉の意味を短く固定する定義辞書を扱う節です。「前提が違えば、同じデータからでも結論は真逆になってしまいます。」その節を読むと、自分の現場で意味が割れている言葉はどれか、それを誰と合意すればよいかを、自分で洗い出せるようになります。