- ○
- ウェブサイトの運用が破綻するとき、原因のひとつに挙げられるのが、内部構造がデザインされていないことです。
- ○
- ウェブのコンテンツは、外観だけでなく、その内部構造（意味構造）も、サイトが持続して成長できるように設計されている必要があります［※１］［※２］。
- ○
- ウェブサイトの内部構造を構築・再編するエキスパートが、ウェブの構造エンジニアです。
- ○
- わたくしたちは、ウェブの構造エンジニアをふくむ＜言葉のエンジニア＞への、技術提供と人材育成を行っています。
- ※１
- とくに現代のウェブコンテンツは、ヒトだけでなく、音声アシスタントなどのエージェント（機械）も閲覧します。機械が理解できる構造でないと、コンテンツはユーザに届きません。
- ※２
- コンテンツの意味構造をデザインする標準技術に、ウェブの標準化団体（Ｗ３Ｃ）が提唱する、XML/XSL/RDF があります。
バックエンドを支える、ウェブの構造エンジニア
ウェブの構造エンジニアは、バックエンドのデザイナです
たとえば建築物は、意匠（外観）と構造（内部）の、２つのデザインを必要とします。
ネット上の建築物であるウェブサイトも、フロントエンドの＜情報アーキテクチャ＞と、バックエンドの＜データ＆ドキュメント構造＞の、２つのデザインを必要とします。［※１］
かれ／彼女は、フロントエンドを柔軟に構成できるよう／またエージェント（検索エンジンのクローラや音声アシスタントなど）からの問い合わせに直接答えるために、サイトのあらゆる情報（事物一般と文書情報）を統一した様式で構築・再編します。そしてサイトが持続して成長できるよう、あらゆる媒体（ウェブ〜メール〜印刷媒体、オウンドメディア（自サイト）〜アーンドメディア（ＳＮＳなど）、基幹システム〜オープンデータ、異種ＣＭＳ／ＷＡＦ）を、連携〜統合します。
- ※１
- 情報アーキテクチャは（おもにヒトに理解させるための）ヒト寄りの構造ですが、データ＆ドキュメント構造は（おもに機械に理解させるための）機械寄りの構造です。
サイトの運用に、問題をかかえていませんか？
建築物はその外観の意匠がどれだけ優れていても、内部の構造がまともに設計されていなければ、崩壊します。
ウェブサイトも同様です。フロントエンドの情報アーキテクチャがどれだけ優れていても、バックエンドのデータ＆ドキュメント構造がまともに設計されていなければ、＜持続的に成長できる＞運用はできません。［※１］
たとえば運用中のサイトで、次のような問題が起きていないでしょうか？
- ・
- 新しいＣＭＳ／ＡＷＦを導入したいのに、移行／併用が難しい
- ・
- 制作ツール類の氾濫（静的サイトジェネレータやＣＳＳプリプロセッサなど）
- ・
- 基幹システムと連携できない
- ・
- セマンティックＳＥＯ（構造化データ／リッチリザルト）への対応に手間取る
- ・
- サイトの再構築が円滑にいかない、時間と費用がかかりすぎる
- ・
- デザインガイドラインの共有がうまくいかない
- ※１
- まずサイトの運用に手間がかかるようになり、コンテンツ企画〜更新への意欲が薄れ始めます。＜廃墟サイト＞化を免れるために再構築を行いますが、内部構造がまともに設計されていなければ、多くの時間と費用をムダに費やすことになります。
運用しづらいのは、内部構造がデザインされていないからでは？
ウェブサイトが時間とともに／また拡張するにつれ運用しづらくなるとき、サイトの内部構造がまともに設計されていないことも、原因のひとつになります。
サイトの変化には次のパターンがありますが：
- ●
- 記述内容の変化（文書情報）：
- ・
- ＨＴＭＬコーディングのトレンド変遷（テーブル→フロート、ソリッド→リキッド、……）
- ・
- ＨＴＭＬのバージョンアップ（４→５→……）
- ●
- 記述内容の拡張（事物一般）：
- ・
- ドキュメントのみの構造化から、あらゆるモノ／コトの構造化へ（文書情報→事物一般）
- ●
- 出力媒体〜入力要素の拡張：
- ・
- 各種媒体への出力（ウェブ／メール／電子書籍／印刷媒体、オウンドメディア／アーンドメディア、リンクトデータ／セマンティックＳＥＯ、……）
- ・
- 各種要素からの入力（基幹システム、オープンデータ、……）
- ●
- 管理要素の拡張：
- ・
- 各種管理ツールの導入と併用（各種ＣＭＳ（ＷＰ、ＭＴ、……）／ＷＡＦ（レイルズ、ケイク、……）／制作ツール類（静的サイトジェネレータ、ＣＳＳプリプロセッサ、……））
これらの要請にその場しのぎで対応していけば、サイトのツギハギがホコロビを生み、不整合をごまかしつつ運用することになります。
とくにリンクトデータ／セマンティックＳＥＯ／基幹システム／オープンデータは、あらゆるモノ／コトをあつかいます。文書情報だけでなく事物一般についても体系だった整理がなされていないと、システム間の連携はうまくいきません。また構造化データに対応できければ、検索サイトに表示されるリッチリザルトも貧弱なものにしかなりません。
構造エンジニアリングで、持続して成長できるサイトに
サイトの内部構造が統一された様式で整理されていれば、どのような要請がきても柔軟に対応できるようになります。たとえ再構築が必要になっても、最低限のコスト（時間／費用）で済みます。
この再編〜統合は、Ｗ３Ｃの標準技術を使う場合、次のように実現していくことになります：［※１］
- ●
- サイトの情報（文書情報と事物一般）を記述する中間形式を、とくに次の要素を勘案し設計
- ・
- リンクトデータ／セマンティックＳＥＯ（構造化データ／リッチリザルト）（RDF, JSON-LD, Dublin Core, schema.org ）
- ・
- サイトのデザインガイドライン
- ・
- ＨＴＭＬコーディングのトレンド変遷／ＨＴＭＬのバージョンアップ
- ●
- 設計した中間形式にもとづき、情報をメタマークアップ言語（XML ）や関係モデル（RDB ）で記述
- ・
- 文書情報は、文書構造のあらゆるレベルでパーツ化（ヘッダ／フッタ〜表組／一覧〜文字装飾）
- ・
- 大量の情報／高速な操作が必要な情報は、リレーショナルデータベースに移行
- ●
- 各種テンプレートを、関数型スタイルシート言語（XSLT）で記述
- ・
- 各種媒体のためのテンプレート（ウェブ／メール／電子書籍／印刷媒体、オウンドメメディア／アーンドメディア、リンクトデータ／セマンティックＳＥＯ）
- ・
- ＣＳＳ生成のためのテンプレート（ＣＳＳプリプロセッサとして）
- ・
- 各種ＣＭＳ／ＷＡＦのテンプレート（テンプレートのテンプレート）
- ●
- 変換処理の流れを、パイプラインとプログラミング言語（Java, Scala, Ruby, Haskell, etc.）で実装
- ・
- リンクトデータ／セマンティックＳＥＯに向けた変換
- ・
- ウェブ（HTML）／メール（TEXT）／電子書籍（ePub）／印刷媒体（XSL-FO ）への出力
- ・
- オウンドメディア（自サイト）への出力、アーンドメディア（ＳＮＳなど：ツィッター／フェイスブック……）への自動投稿
- ・
- 基幹システム（RDB ）との連携（マーケティングオートメーション、など）
- ・
- オープンデータの利用（マッシュアップ、など）
- ・
- 各種ＣＭＳ（ＷＰ、ＭＴ、……）／ＷＡＦ（レイルズ、ケイク、……）の導入〜併用のためのデータ変換
とくに重要になるのは、組織（ドメイン）内で使う中間形式のデザインです。内部で使う言葉を明確な様式／用語で統一するともに、外部の各種様式に変換しやすい形でもある必要があります。［※２］
ウェブの構造エンジニアリングは、＜言葉のエンジニアリング＞の側面も併せ持っています。
- ※１
- わたくしたちがＷ３Ｃの標準技術を推奨するのは、他の技術にくらべ永続性があるからです。また関連ツール類が普及しているため、無償ですぐに使える、という利点もあります（たとえばＷ３Ｃ標準のテンプレートを記述する言語XSLTは、すべてのＯＳに標準で添付しているか／無償でダウンロードできます。またすべてのブラウザが標準で対応している、唯一の汎用テンプレートです）。
- ※２
- たとえばサイトのデザインガイドラインを、すべて自前のタグ（<..>）で表現することができます。引き継ぎのマニュアルはもっとも簡潔になり、初心者でも独自タグの一覧を覚えるだけで、柔軟かつ正確にコンテンツを制作していくことができます。
マクロの目的：知識の共通基盤／ＡＩとデータのウェブ
いまのウェブは、かならずしも使いやすいとはいえません。自然言語の集まりから目的の情報を得る＜キーワード検索＞は、曖昧で試行錯誤が必要だからです。［※１］
Ｗ３Ｃのティム・バーナーズリーは、データのウェブを提唱しています。そこではあらゆる情報が統一された様式（RDF/OWL ）で表現されリンクされます。これは工学的に定義された人工言語なので、ヒトだけでなく機械もそれを理解します。［※２］
機械（エージェント：検索エンジンのクローラや音声アシスタントなど）は近年、（深層学習などの）解析的なＡＩ技術により、自然言語をより深く理解できるようになってきました。ただ解析的手法は、多くの・正しいデータを必要とし、解析結果もそこから得られた標準を超えられません。データのウェブ（セマンティックウェブ：リンクトデータやリンクされた構造化データ）は、記号的なＡＩ技術のひとつで、機械が世界を正確に理解する背景を作ります。
ウェブの構造エンジニアは、サイトを持続して成長させるために、自分たちのコンテンツを構造化します。副次的に、データのウェブがすこしずつ形づくられていきます……わたくしたちがかれ／彼女を支援するのは、その仕事が、ヒトと機械の共通の＜知識の基盤＞を拡大することにつながるからです。
- ※１
- ただ構造化データがある程度普及したので、音声アシスタントが店舗の開業時間などを直接案内できるほどにはなっています。
- ※２
- これはすべての人類とすべての機械のための共通言語であり、現代のエスペラント語といっていいものです。
ミクロの目的：職業としての言葉のエンジニア
ＨＴＭＬコーダは、次のステップにどのような職業を選べるでしょうか？
言葉の意味や概念の形成に興味をもつ人は、（ＪＳプログラミングやＣＳＳエディトリアルデザインより）ＨＴＭＬコーディングそのものに志向があるといえます。
近年のリンクトデータ／セマンティックＳＥＯの広まりにともない、ウェブのコンテンツはあらゆるモノ／コトを構造化することが求められています。またさまざまな媒体／要素との連携も必要とされています。これらの要請にウェブの構造エンジニアは応えますが、この職種にいちばん近い位置にいるのが、ＨＴＭＬコーダです。
かれ／彼女が言葉をあつかうことに志向があるなら、＜言葉のエンジニア＞であるウェブの構造エンジニアも、職業選択の候補になります。次の知識を必要としますが、どれも＜言葉と対話＞の技術にまつわるものです：
- ・
- ナレッジ・エンジニアリングの一部（意味ネットワーク、オントロジー、記述論理）：RDF, JSON-LD, SPARQL, Dublin Core, schema.org (, OWL)［※１］
- ・
- ドキュメント・エンジニアリング（木構造モデル、関数型スタイルシート）：XML, XPath, XSLT, HTML, CSS (, SVG, XSL-FO)
- ・
- データベース・エンジニアリング（関係モデル、集合演算）：RDB, SQL
- ・
- プログラミング（順序／分岐／反復、関数型／手続型（オブジェクト指向）／論理型、同期／非同期）：Java (, Scala, Ruby, Haskell, Prolog, JavaScript/Node.js)
- ・
- 分散型ネットワークの概論（ウェブサービス、ＯＳＩ７階層）：WebAPI, REST, JSON (, TCP/IP, DNS, SMTP, HTTP)
- ・
- オペレーティング・システムの概論（プロセス管理、ファイル管理、シェル）：UNIX like OS, sh
- ・
- ウェブデザイン／ウェブマーケティング／インターネットビジネスの概論
ウェブは、制作会社やネット企業はもちろんのこと、一般の組織でも広報だけでなくさまざまな業務に使われています。その統合は、組織の生産性の向上（営利企業なら費用削減／売上増大）に大きく貢献します。
わたくしたちは、企業／団体／教育機関／公共機関に対し、＜言葉のエンジニリング＞に関する技術提供と人材育成を行います。［※２］［※３］［※４］
- ※１
- 記述論理は、セマンティックウェブにおけるルールの記述（OWL ）を理論面で支えるものです。一階述語論理のうち決定可能な領域をあつかい、オブジェクト指向寄り（クラスとロール）の考え方で宣言的なルールを記述します。
- ※２
- ウェブにおいて、これは比較的新しい職業です。近年のリンクトデータ／セマンティックＳＥＯの広まりにより、ウェブサイトは、文書情報だけでなく事物一般も構造化する必要が出てきました。この状況に対応できるエンジニアが求められています。
- ※３
- わたくしたちの提案する構造エンジニアリングは、Ｗ３Ｃの標準技術（XML/XSLT/XSL-FO/RDF/JSON-LD ）を採用する、もっとも汎用的な統合手法です。
- ※４
- すでに東大や多国籍企業、ウェブの基幹企業など、多くの運用実績があります。
資料など
- ○
- 教材「ウェブの構造エンジニアリング」シリーズ（ＰＤＦ）
このサイトについてのお問い合わせは：
アゼロス
