サーバーサイドエンジニアが初めてDrupalを触ってみた

本稿では、いわゆる「プログラミング」を仕事とするサーバーサイドエンジニアが初めてDrupalを触ってみた所感を、エンジニア目線でお伝えしていきます。

Drupal とは

日本においてはWordPressやMovableTypeなどと比べるとまだまだ耳にする機会が少ないDrupalですが、思いの外なじみやすく、エンジニアフレンドリーなアプリケーションです。

Drupalとはズバリ「Webアプリケーション構築のための高抽象的フレームワークとも言えるCMS」です。

エンジニアの皆様には「Drupalで構築できるWebアプリケーションの参照実装としてCMS機能が提供されている」と言い換えたほうが伝わりやすいかもしれません。

その特性のなかでもとりわけ目を引くのは、プログラミングによって実装するような機能が、標準のGUI操作で実装できてしまうということです。エンジニアが「あのフレームワークを使って、こういう設計で実装していけば作れそうだ」と想像するようなモノが、Drupalでは標準機能のGUI操作だけでほとんど作成できてしまいます。

本稿では取り扱いませんが、Drupalはまた、蓄積したデータを既定の形式でWebリソースとして提供する機能を備えており、データのゲートウェイとしても活用できます。「Webリソース管理システム」とも言えるかもしれませんね。

データ構造に見る柔軟性、WordPressとの違い

「CMSなのにWebフレームワーク？」と疑問を持たれる方もいらっしゃるかもしれません。

Web アプリケーション開発は通常、要件に基づいて業務ドメインのデータモデリングを行うところからスタートします。業務ドメインに関してフレームワーク側が既定のテーブルを持ってしまっていると、要件にマッチせず不都合である場合が多いでしょう。

CMS と言うからには、コンテンツを管理するためのテーブルをすでに持っていそうです。Drupalではどうなっているのでしょうか。

今回はWordPressを比較対象としてDrupalのデータ構造について見てみます。

ご存知の通りWordPressは「ブログウェア」であり、そのデータベースは「wp_posts（投稿）」を主軸としたテーブル設計がされています。このテーブルの属性（カラム定義）はあらかじめ定められています。ブログウェアという大前提があるので、ブログのデータを保管しやすいように考案された構造になっているわけです。

言い換えれば、WordPressのデータベースはすでにブログ投稿に最適化されたデータモデリングが成された状態になっており、また、そのデータモデルを変更する機能までは備えていません。

一方でDrupalは純粋にCMSであり、WordPressよりも抽象度が高い領域をターゲットにしています。多様なコンテンツを保管することができるように「ノード」という抽象的なモデルを採用しており、そのテーブル設計は高度に正規化された状態になっています。

参考： Drupal 8のノードのデータ構造を見てみる (1)
参考： Database schema | Drupal.org

ノードには、どのような属性を持たせるかを設定可能です。属性の種類や数は固定されていないので、データがどのような項目を持つのかを柔軟にカスタマイズできます。

すなわちDrupalはデータモデリングを行う機能を標準で備えており、Drupal上でデータモデルの変更ができるということになります。

これにはどのような恩恵があるのでしょうか。

アプリケーション開発のハードルを下げるDrupal

例えばWordPressで、定形項目を備えた「レポート」を投稿したくなったとしましょう。

レポート投稿機能の開発です。

技術的な見方をすると、要点は次のとおりです。

• レポートを記録するための、定形項目に対応したデータモデルが必要。
• レポートのデータを読み書きする処理の実装が必要。
• レポートを表示する画面が必要。

これにはいくつかのプラグインを導入して、カスタムフィールドを持ったコンテンツタイプを作成する必要があります。プラグインの導入・カスタマイズには、PHPプログラム読み書きしたり、WordPress本体やサーバーの設定に関する知識がある程度要求されます。

また、このケースではWordPressの特性上、本来「ブログ投稿」を保管するためのテーブルに「レポート」のレコードも記録していくことになります。ここで記録されるレコードは、テーブル本来の目的とは異なる独特の意味を持ってしまうことになり、多少違和感があります。

一方Drupalでは、「レポート」というデータモデルを標準のGUI上から新規作成します。

この「レポート」のレコードはあくまでノードの一種であり、意味的にも自然な状態が保たれます。

標準機能かつGUIでできるというところもポイントです。ノードの概念や管理画面の操作方法などを習得する必要はもちろんありますが、PHPプログラムを読み書きできるようになる必要はありません。

つまり、Drupalなら非エンジニアでもレポート投稿機能を開発することができてしまいます。

Drupal の採用が開発現場にもたらす効用

とはいえ、標準機能やモジュール (※1) だけでカバーしきれない特殊な要件はプログラミングによる開発が必要になってくることがあります。

※1 : Drupalに機能を追加するための、WordPressでいうプラグインのような仕組み。

またDrupalそのものの導入作業や、セキュリティアップデート等の保守作業も必要なため、非エンジニアのみで Web アプリケーション開発プロジェクトを進めるのは難しいのが現状です。

しかしながら、開発現場における議論に非エンジニアが積極的に参加できるようになることや、エンジニアと非エンジニアの認識レベルが近づくことは大きなメリットと言えます。

開発現場では、メンバー同士の業務的・技術的な知識の差から生じるコミュニケーションの摩擦が少なくありません。エンジニアが専門用語を用いてしまうと非エンジニアには伝わりませんし、逆に非エンジニアが話す内容を噛み砕いて理解する必要があります。

しかしDrupalを知る人同士であれば、共通の用語でコミュニケーションが取れます。スキルが異なるメンバー同士で会話する際の「説明するコスト」「理解するコスト」を大幅に削減でき、認識齟齬も生まれにくくなります。

エンジニア的な所感

エンジニアの中には、何らかの「手順」のなかにGUIによる手作業が入ることを好ましく思わない方もいらっしゃるかと思います（筆者もそうです）。新しいフレームワークやアプリケーションを試す際、まずはコマンドやコード主体の入り口から入る方も多いでしょう。

しかし、Drupalの場合はまずはGUIから触り、後でコードと対比するのが良いと感じました。

はじめに、Drupalの用語や各機能の概念、GUI 操作でどのようなクエリが流れるのか、レコードが画面上でどのように表示されるのかといったことを確認しましょう。たとえ煩雑に思えても、信条的に美しくなくとも、まずはマウスでぽちぽちしてみましょう。

その後GUI操作に対応するコードを後追いしていくほうが、迷子にならずに理解が進むと思います。

尚、GUI 操作から行う設定は、Configuration ManagerコアモジュールによってYAMLファイルで読み書きすることができます。Drupalのコマンドラインツール “Drush” を通して操作することで、コードベースでの設定管理が可能となります。

参考： Configuration management | Drupal 8 guide on Drupal.org

特にインフラ構成をAWS CloudFormationやTerraformでコード化し、サイト構築を自動化する際に有用です。

おわりに

いかがでしたでしょうか。少しでもDrupalの特徴をお伝えすることが出来ていれば幸いです。とりあえず試してみたくなったら、次のようなクイックスタートが利用できます。

• Drupal VM
• Docker イメージ

弊社 青山の記事「Drupalのローカル開発環境の構築方法について詳細解説」も一助としてください。

非エンジニアの方でも、無料からスタートできるDrupalホスティングサービス「Pantheon」などを利用してDrupalを体験することができます。