この記事はDrupal Advent Calendar 2022の14日目です。

DrupalCon Portland 2022 Driesnote に登場した Ambitious Site Builders という言葉が一部で注目されています。

Drupal Advent Calendar 2022 でも、すでに複数の方がこのテーマで記事を書かれていますね。

両記事とも、とてもよい考察が書かれているのでぜひ読みましょう。

お二人の属性は、記事の内容や bio からどちらかというとプロジェクトマネージャー・ディレクター寄りのように読み取れます。

ということで、この記事では開発者の目線から次のことを考えてみようと思います。

  • Ambitious Site Builder とは
  • こんなサイトビルダーと一緒だといい仕事できるよね

決して記事のネタが思いつかなかったから真似しているわけではありません。😇

Ambitious Site Builder とは

これを考えるには、まず（普通の、もしくは以前の）「サイトビルダーの役割・スキルセットとは」の整理からですね。

この点については、先に紹介した @gongo_k さんの記事中の 旧来のサイトビルダー のセクションにまとまっています。ありがとうございます（他力本願）。

一言でまとめてしまうと、「Drupal のコアとモジュールを使い、管理画面の機能でサイトを構築する人」でしょうか。

一方で、 @hagi60 さんの記事でも言及があるように (他力本願その2)、

  • Drupal 8での大きなアーキテクチャ変更により、 Drupal 7 では存在したモジュールが使えなくなったり、開発が滞るようになった
  • モジュールを導入する際に composer, config management などの知識が必要になった

という歴史的な背景もあり、「サイトビルダーだけで完結できること」が少なくなってきているのが現在の状況です。

ざっくりの方向性としては、（もちろん Drupal 自体がより使いやすくなる前提で）この状況を変えていける人材が Ambitious Site Builder なのかなと思います。

では、具体的に 「Ambitious Site Builder はどんなことができればいいのか」問題です。

キーノートの42分50秒あたりを見てみましょう。

https://www.youtube.com/watch?v=Ig676RzJbLo&t=2570s

Mostly through the UI, Write (some) custom code という2つの要素が登場します。

Mostly through the UI

Drupal を使うと、多くの機能やUIを管理画面からクリックすることで生成できます。この点に関してはこれからも変わりません。 これに加えて、46分20秒あたりで言及されているように 「discover -> install -> configure -> update」 のサイクルを回すことが、これからのサイトビルダーに求められるのではないかと思います。

このうち、 install と update は、現状では最低限 composer を CLI で扱えないと対応するのが難しくなっています。 同キーノートで紹介されている Automated Updates と Package Manager により、 将来的にはこの領域のタスクを管理UIから実行できるようになるようです。

ただし、install を除けば、ふれこみ通りに簡単になるかに関しては、個人的には懐疑的に見ています。

discover

まず、discover はとても難しいフェーズです。 単に「あるモジュールで機能的にやりたいことができるか」という観点だけではなく、「メンテナンスが続くか」、「品質が十分か」、「他のモジュールやカスタムコードと衝突しないか」など、包括的な視点が求められます。

Drupal の性質上、discover と configure、つまり「モジュールの選定と設定」でアーキテクチャが決まってしまうというか、別の言葉で言い換えると「アーキテクチャ上の制限が発生する」側面があります。

つまり、discover フェーズの本質は「できること」を探すことではなく、「できないこと」や「制約事項」を把握することだと私は考えています。

configure

configure については、これまで通りの観点が必要です。

つまり、サイトビルダーは「小さい単位で変更を積み重ねていくこと」、「変更をバージョン管理すること」、「エンドユーザーに破壊的な変更をさせないこと」などを考えましょう、ということですね。

update

最後の update についても、 discover と同様に難しいフェーズになります。 Automated Updates は非常に便利に見えますが、内部で動いているのは魔法ではなく composer, composer-patches などの単なる既存技術のはずです。

最近では GitHub CodeSpaces, GitHub Actions などを活用し、アップデートや検証環境の構築を自動化している方も多いかもしれません。

しかし、経験則としては、アップデート後にパッチやコンフィグの変更をしないとクリティカルな問題が発生することもしばしばあり、手放しで自動化できるとは言えないことが多いです。

以下のような前提をうまく担保しないと、アップデートしても予期しない問題が起こり、サイトビルダーだけでは対処できないケースが発生するのは今後も変わらないでしょう。

  • あまり多くのモジュールを利用しない
  • モジュールを利用する場合は、後方互換性や他モジュールとの整合性などを考えてメンテナンスされているものを選ぶ
  • カスタムコードをがんばって書きすぎない、書く場合はベストプラクティスに従う
  • OSS部分にパッチを当てすぎない
  • CI/CD の仕組みを整える

git 等によるソースコードのバージョン管理との連携も考えないといけないですね。

Write (some) custom code

これについては、@gongo_k さんの記事中の ambitous site builders に求められるスキル のセクションにまとまっています。ありがとうございます（他力本願その3）。

記事に書かれていることができれば素晴らしいですね。 ただし、サイトビルダー自身がコードを書く必要があるかどうかは、プロジェクトの性質やチームメンバーのスキルによるかなと思います。

頼れる開発者が周りにいないというハードモードな環境では、サイトビルダー自身が簡単なカスタムコードが書けたほうが当然いいでしょう。

開発を外注するにしても、成果物の検証ができなければ仕事としては成り立たないため、手を動かしてコードを書いてみるのは重要ですね。

こんなサイトビルダーと一緒だといい仕事できるよね

開発者目線だと、端的には以下の3点です。

  1. サイトビルディングで「できること」だけではなく、「できないこと」や「制約事項」まで考えて動ける人
  2. サイトビルディングで「できないこと」に関して、どういうカスタム開発をすればいいかのイメージを持っている人 (コードをバリバリ書けなくてもOK)
  3. システム稼働後の運用やアップデートの課題について、サイトの構築段階で想像できる人

実体験としても、このようなサイトビルダーとは非常に仕事がやりやすく、お互いのコミュニケーションコストも低くなるため、とても気持ちよく仕事ができます。

逆に、ここで上げたような観点がないサイトビルダーであれば、開発者自身がサイトビルディングもしてしまった方が上手く回るかもしれません。

まとめ

開発者目線で 「Ambitious Site Builders がこうだったらいいなー」、を書いてみました。

色々と悲観的なことも書いていますが、管理UIからできることが増えるという方向性は素晴らしいことです。

一方で、抽象化・ブラックボックス化された道具は使う分には簡単ですが、使いこなすにはそれなりの知識が求められる側面があります。

サイトビルダーの話題からは少し逸れますが、

  • PM: 「Drupal知らないけど、クライアントがこういう機能が欲しいと言っていて、このモジュールでできるって書いてあるからできるって言ってきた。あとよろしく！」
  • ディレクター: 「Drupal知らないけど、デザイン全部決めてきました。この通り開発してください、あとよろしく！」

のような光景が常態化している場合、サイトビルダーや開発者がどう頑張っても炎上確定です。

サイトビルダーが ambitious かどうかの遥か以前の問題ですね。

Drupal、というよりは自動生成系の OSS や SaaS を利用したプロジェクトにおいて、道具を知らない人間が意思決定を行うことは極めて高いリスクになります。Drupal を使う場合、ロールに関わらずサイトビルディングの基本はしっかりと押さえておきましょう。