ウェブの構造エンジニアリング

施策


ウェブの構造エンジニアを支援します


ウェブの構造エンジニアは、バックエンドのデザイナです

たとえば建築物は、意匠(外観)と構造(内部)の、2つのデザインを必要とします。

ネット上の建築物であるウェブサイトも、フロントエンドの<情報アーキテクチャ>と、バックエンドの<データ&ドキュメント構造>の、2つのデザインを必要とします。[※1]

かれ/彼女は、フロントエンドを柔軟に構成できるよう/またエージェント(検索エンジンのクローラや音声アシスタントなど)からの問い合わせに直接答えるために、サイトのあらゆる情報(事物一般と文書情報)を統一した様式で再編します。そしてサイトが持続して成長できるよう、あらゆる媒体(ウェブ〜メール〜印刷媒体、オウンドメディア(自サイト)〜アーンドメディア(SNSなど)、基幹システム〜オープンデータ、異種CMS/WAF)を、連携〜統合します。

わたくしたちは、企業/団体/教育機関/公共機関に対し、ウェブの構造エンジニリングに関する技術支援人材育成を行います。[※2][※3][※4]


※1
情報アーキテクチャは(おもにヒトに理解させるための)ヒト寄りの構造ですが、データ&ドキュメント構造は(おもに機械に理解させるための)機械寄りの構造です。
※2
これは比較的新しい職業です。近年のリンクトデータ/セマンティックSEOの広まりにより、ウェブサイトは、文書情報だけでなく事物一般も構造化する必要が出てきました。この状況に対応できるエンジニアが求められています。
※3
わたくしたちの提案する構造エンジニアリングは、W3Cの標準技術(XML/XSLT/XSL-FO/RDF/JSON-LD )を採用する、もっとも汎用的な統合手法です。
※4
すでに東大や多国籍企業、ウェブの基幹企業など、多くの運用実績があります。

問題


あなたのサイトはなぜ運用しづらいのでしょうか?


建築物はその外観の意匠がどれだけ優れていても、内部の構造がまともに設計されていなければ、崩壊します。

ウェブサイトも同様です。フロントエンドの情報アーキテクチャがどれだけ優れていても、バックエンドのデータ&ドキュメント構造がまともに設計されていなければ、<持続的に成長できる>運用はできません。[※1]

たとえば運用中のサイトで、次のような問題が起きていないでしょうか?


新しいCMS/AWFを導入したいのに、移行/併用が難しい
制作ツール類の氾濫(静的サイトジェネレータやCSSプリプロセッサなど)
基幹システムと連携できない
セマンティックSEO(構造化データ/リッチリザルト)への対応に手間取る
サイトの再構築が円滑にいかない、時間と費用がかかりすぎる
デザインガイドラインの共有がうまくいかない

※1
まずサイトの運用に手間がかかるようになり、コンテンツ企画〜更新への意欲が薄れ始めます。<廃墟サイト>化を免れるために再構築を行いますが、内部構造がまともに設計されていなければ、多くの時間と費用をムダに費やすことになります。

原因


運用しづらいのは、内部構造がデザインされていないためです


ウェブサイトが時間とともに/また拡張するにつれ運用しづらくなるのは、サイトの内部構造がまともに設計されていないことが原因です。

サイトの変化には次のパターンがありますが:


記述内容の変化(文書情報):
HTMLコーディングのトレンド変遷(テーブル→フロート、ソリッド→リキッド、……)
HTMLのバージョンアップ(4→5→……)
記述内容の拡張(事物一般):
ドキュメントのみの構造化から、あらゆるモノ/コトの構造化へ(文書情報→事物一般)
出力媒体〜入力要素の拡張:
各種媒体への出力(ウェブ/メール/電子書籍/印刷媒体、オウンドメディア/アーンドメディア、リンクトデータ/セマンティックSEO、……)
各種要素からの入力(基幹システム、オープンデータ、……)
管理要素の拡張:
各種管理ツールの導入と併用(各種CMS(WP、MT、……)/WAF(レイルズ、ケイク、……)/制作ツール類(静的サイトジェネレータ、CSSプリプロセッサ、……))

これらの要請にその場しのぎで対応していけば、サイトのツギハギがホコロビを生み、不整合をごまかしつつ運用することになります。

とくにリンクトデータ/セマンティックSEO/基幹システム/オープンデータは、あらゆるモノ/コトをあつかいます。文書情報だけでなく事物一般についても体系だった整理がなされていないと、システム間の連携はうまくいきません。また構造化データに対応できければ、検索サイトに表示されるリッチリザルトも貧弱なものにしかなりません。

解決


構造エンジニアリングで、持続して成長できるサイトに


サイトの内部構造が統一された様式で整理されていれば、どのような要請がきても柔軟に対応できるようになります。たとえ再構築が必要になっても、最低限のコスト(時間/費用)で済みます。

この再編〜統合は、W3Cの標準技術を使う場合、次のように実現していくことになります:[※1]


サイトの情報(文書情報と事物一般)を記述する中間形式を、とくに次の要素を勘案し設計
リンクトデータ/セマンティックSEO(構造化データ/リッチリザルト)(RDF, JSON-LD, Dublin Core, schema.org )
サイトのデザインガイドライン
HTMLコーディングのトレンド変遷/HTMLのバージョンアップ
設計した中間形式にもとづき、情報をメタマークアップ言語(XML )や関係モデル(RDB )で記述
文書情報は、文書構造のあらゆるレベルでパーツ化(ヘッダ/フッタ〜表組/一覧〜文字装飾)
大量の情報/高速な操作が必要な情報は、リレーショナルデータベースに移行
各種テンプレートを、関数型スタイルシート言語(XSLT)で記述
各種媒体のためのテンプレート(ウェブ/メール/電子書籍/印刷媒体、オウンドメメディア/アーンドメディア、リンクトデータ/セマンティックSEO)
CSS生成のためのテンプレート(CSSプリプロセッサとして)
各種CMS/WAFのテンプレート(テンプレートのテンプレート)
変換処理の流れを、パイプラインとプログラミング言語(Java, Scala, Ruby, Haskell, etc.)で実装
リンクトデータ/セマンティックSEOに向けた変換
ウェブ(HTML)/メール(TEXT)/電子書籍(ePub)/印刷媒体(XSL-FO )への出力
オウンドメディア(自サイト)への出力、アーンドメディア(SNSなど:ツィッター/フェイスブック……)への自動投稿
基幹システム(RDB )との連携(マーケティングオートメーション、など)
オープンデータの利用(マッシュアップ、など)
各種CMS(WP、MT、……)/WAF(レイルズ、ケイク、……)の導入〜併用のためのデータ変換

とくに重要になるのは、組織(ドメイン)内で使う中間形式のデザインです。内部で使う言葉を明確な様式/用語で統一するともに、外部の各種様式に変換しやすい形でもある必要があります。[※2]

ウェブの構造エンジニアリングは、<言葉のエンジニアリング>の側面も併せ持っています。


※1
わたくしたちがW3Cの標準技術を推奨するのは、他の技術にくらべ永続性があるからです。また関連ツール類が普及しているため、無償ですぐに使える、という利点もあります(たとえばW3C標準のテンプレートを記述する言語XSLTは、すべてのOSに標準で添付しているか/無償でダウンロードできます。またすべてのブラウザが標準で対応している、唯一の汎用テンプレートです)。
※2
たとえばサイトのデザインガイドラインを、すべて自前のタグ(<..>)で表現することができます。引き継ぎのマニュアルはもっとも簡潔になり、初心者でも独自タグの一覧を覚えるだけで、柔軟かつ正確にコンテンツを制作していくことができます。

目的#1


マクロの目的:知識の共通基盤/AIとデータのウェブ


いまのウェブは、かならずしも使いやすいとはいえません。自然言語の集まりから目的の情報を得る<キーワード検索>は、曖昧で試行錯誤が必要だからです。[※1]

W3Cのティム・バーナーズリーは、データのウェブを提唱しています。そこではあらゆる情報が統一された様式(RDF/OWL )で表現されリンクされます。これは工学的に定義された人工言語なので、ヒトだけでなく機械もそれを理解します。[※2]

機械(エージェント:検索エンジンのクローラや音声アシスタントなど)は近年、(深層学習などの)解析的なAI技術により、自然言語をより深く理解できるようになってきました。ただ解析的手法は多くのデータを必要とし、解析結果もそこから得られた標準を超えられないため、情報の精度は保証されません(これはヒトも同様で、自然言語の読み書きには曖昧さが残ります)。データのウェブ(セマンティックウェブ:リンクトデータやリンクされた構造化データ)は、記号的なAI技術のひとつで、機械が世界を正確に理解する背景を作ります。

ウェブの構造エンジニアは、サイトを持続して成長させるために、自分たちのコンテンツを構造化します。副次的に、データのウェブがすこしずつ形づくられていきます……わたくしたちがかれ/彼女を支援するのは、その仕事が、ヒトと機械の共通の<知識の基盤>を拡大することにつながるからです。


※1
ただ構造化データがある程度普及したので、音声アシスタントが店舗の開業時間などを直接案内できるほどにはなっています。
※2
これはすべての人類とすべての機械のための共通言語であり、現代のエスペラント語といっていいものです。

目的#2


ミクロの目的:職業としての言葉のエンジニア


HTMLコーダは、次のステップにどのような職業を選べるでしょうか?

言葉の意味や概念の形成に興味をもつ人は、(JSプログラミングやCSSエディトリアルデザインより)HTMLコーディングそのものに志向があるといえます。

近年のリンクトデータ/セマンティックSEOの広まりにともない、ウェブのコンテンツはあらゆるモノ/コトを構造化することが求められています。またさまざまな媒体/要素との連携も必要とされています。これらの要請にウェブの構造エンジニアは応えますが、この職種にいちばん近い位置にいるのが、HTMLコーダです。

かれ/彼女が言葉をあつかうことに志向があるなら、<言葉のエンジニア>であるウェブの構造エンジニアも、職業選択の候補になります。次の知識を必要としますが、どれも<言葉と対話>の技術にまつわるものです:


ナレッジ・エンジニアリングの一部(意味ネットワーク、オントロジー、記述論理):RDF, JSON-LD, SPARQL, Dublin Core, schema.org (, OWL)[※1]
ドキュメント・エンジニアリング(木構造モデル、関数型スタイルシート):XML, XPath, XSLT, HTML, CSS (, SVG, XSL-FO)
データベース・エンジニアリング(関係モデル、集合演算):RDB, SQL
プログラミング(順序/分岐/反復、関数型/手続型(オブジェクト指向)/論理型、同期/非同期):Java (, Scala, Ruby, Haskell, Prolog, JavaScript/Node.js)
分散型ネットワークの概論(ウェブサービス、OSI7階層):WebAPI, REST, JSON (, TCP/IP, DNS, SMTP, HTTP)
オペレーティング・システムの概論(プロセス管理、ファイル管理、シェル):UNIX like OS, sh
ウェブデザイン/ウェブマーケティング/インターネットビジネスの概論

ウェブは、制作会社やネット企業はもちろんのこと、一般の組織でも広報だけでなくさまざまな業務に使われています。その統合は、組織の生産性の向上(営利企業なら費用削減/売上増大)に大きく貢献します。


※1
記述論理は、セマンティックウェブにおけるルールの記述(OWL )を理論面で支えるものです。一階述語論理のうち決定可能な領域をあつかい、オブジェクト指向寄り(クラスとロール)の考え方で宣言的なルールを記述します。

このサイトについてのお問い合わせは:

アゼロス