「Designing Connected Content」を読んで
リデザインのたびにコンテンツの大規模な書き直しに取り組んだ経験はないでしょうか。かつて私も、マルチプラットフォーム対応で同じコンテンツを機能追加やナビゲーションの変更などのたびにUIをゼロベースで再検討する「作り直し」をした経験があります。CMS移行のプロジェクトなどでもよくある話ではないでしょうか。
今回は、Carrie Hane・Mike Atherton氏の著書『DESIGNING CONNECTED CONTENT デジタルプロダクトの長期的な成長を支える構造化コンテンツ』を読んで、その内容と私の感想、そして読んで良かったと思える学びを紹介します。
この本は、デザインが目的化してしまった「デザインファースト」なプロセスから、「構造ファースト」への根本的なパラダイムシフトを提唱する実践書と言えそうです。コンテンツを「見た目」ではなく「構造」として捉えることで、長期的な成長と保守性を両立させる方法論と、コンテンツを体系的に整理する考え方の示唆が得られるかもしれません。
この記事のターゲット
リデザインのたびに大規模な作り直しが発生している
同様のコンテンツを異なるプラットフォームで何度も再作成している
コンテンツモデリングの体系的な方法論を学びたい方
『Designing Connected Content』の概要
『Designing Connected Content』は、プロダクト開発における構造化コンテンツの実践的価値を体系化した書籍だ。単なるコンテンツ管理のテクニック集ではなく、Domain-Driven Design（DDD）の概念をコンテンツ戦略に応用し、技術的負債を回避するための具体的な方法論を提示しています。
この本では、「Create Once, Publish Everywhere（COPE）」の理念に基づき、コンテンツと構造は耐久性があり、インターフェース非依存であるべきという明確な原則を掲げています。構造化コンテンツスタックの5層モデル、ドメインモデリング、コンテンツタイプ設計といった実践的手法を通じて、未知の将来デバイスやAIアルゴリズムにも対応できる持続可能なシステム構築を可能にします。
日本語訳版はやや読みづらいと感じる箇所があります。ニュアンスを正確に汲み取りたい場合は原書もあわせて読むことをお勧めします。
本書の構成
本書は構造化コンテンツの概念から実装まで、10章構成で段階的に解説されています。
第1章 ボトムアップで設計する
第2章 デジタル・コンテンツに新たなアプローチが必要な理由
第3章 構造化コンテンツを理解する
第4章 主題領域の調査
第5章 ドメイン・モデルを作る
第6章 コンテンツ・モデルへの翻訳
第7章 つながり合ったコンテンツを設計する
第8章 つながり合ったコンテンツを実装する
第9章 コンテンツに生命を吹き込む
第10章 未来は待ってくれない
所感
「デザインとブランドは変更可能で適応的であるべき」という考え方は、つい「見た目」から入りがちなデザイナーや、リデザインプロジェクトで同じ轍を踏んできた自分にとって、耳の痛い話だと思います。
今でこそ、構造をデザインの基盤として捉える視点は、長期的な成長と持続可能性を重視する現代のプロダクト開発において不可欠だと断言できます。プロダクトが大規模であればあるほど、技術的負債を回避し、チーム間の協業を促進し、将来の変化に対応できる柔軟性を求めるなら、情報設計などの構造を見直すプロセスは必須でしょう。
また、これらのプロジェクトを組織やチームで実行する前提で紹介されている以下のような具体的な手法は、行き詰まった際の手掛かりになるかもしれません。
ドメインモデリングによる「ユビキタス言語」の確立
技術チームとビジネスチーム間の認識のズレを解消する具体的手法。付箋を使った協働ワークショップは、明日からでも実践できそうです。
「構造化コンテンツスタック」の階層化思考
最も安定的なドメインモデルを底辺に、最も変動的なナビゲーションを上層に配置する設計原則。これにより、インターフェース変更が構造に影響を与えない制約をデザインしていく。
COPE理念の実装
コンテンツをポータブルなブロックとして設計することで、マルチプラットフォーム対応への柔軟性を実現する。「同じコンテンツを何度も作らない」は理想ではなく、構造設計で実現可能という視点。
API-readyな構造の有用性
ヘッドレスCMSやJAMstackアーキテクチャとの親和性。将来の技術スタック変更にも柔軟に対応できる。
チーム協業のフレームワーク
IA、プロダクトデザイナー、フロントエンド開発者、バックエンドエンジニアの役割を明確化し、段階的なワークフローを確立していく。
これらの学びを実践することで、開発スピードの向上、保守コストの削減、そして何より「将来の自分たちを救う」システムが構築するヒントになるかもしれません。経験上、技術的負債は構造設計を過小評価した結果生まれやすいとか考えており、この本質を理解すれば、プロダクト開発のアプローチが根本から変えられると思います。
とはいえ、理論と実装のギャップはあると思います。既存の大規模コンテンツライブラリへの適用は、必ず例外対応や技術的に作り直すしかないという場面もありつつ、明確な納期によってできることが限られる場面がほとんどかと思いますので、現実問題としてはなんらかの妥協は発生するでしょう。
一方で、これから新しくプロダクトを開発しようとしているデザイナーにとっては、表層的なデザインシステムではなく、この構造化思考はデザイナーや開発者を含むステークホルダーが共通言語で語るためのツールとして、根本的な構造設計から始められるチャンスでもあります。
リデザインで消耗するのはもう終わりにして、構造から考えましょう。
