オープンソース・ソフト Drupal を使った Web サイトの構築・サポート・研修

Drupal の「評価者体験」を改善できる 3 つの方法

先週、マシュー グラスミックMatthew Grasmickは、Drupal の経験がない開発者の立場で行った実験結果を公開した。彼は、WordPressLaravelSymfonyDrupal という 4 つの PHP フレームワークを使って新規の「Hello World!」サイトを立ち上げてみたのだ。彼はその模様を包み隠さずブログ記事にシェアしてくれている。そこには、Drupal のダウンロード手順とエンドユーザー用の文書類が非効率的であることが詳しく書かれているが、マシューは、それに加えて、4 つのフレームワークのうち、Drupal はインストール完了までに必要な操作ステップがいちばん多かったことも挙げている。

これを読むと現実に目を覚まされるようだが、僕はマシューがこの問題を前面に持ち出してくれたことを喜んでいる。評価者体験(評価する人のユーザー体験)が良好であることは普及度に直接、影響を与えるので極めて重要だからだ。Drupal とは何か、それがどういう風に機能するのかを知るところから始まって、インストールの仕方、最初のコンテンツを公開するところまでなど、望ましい評価者体験を決める要素はたくさんある。

では、どうやったら、Drupal の評価者体験に絶対に欠かせない改善を実行できるだろうか?

僕は評価者体験をひとつの「コンバージョン ファネル」と考えるのが好きだ。それは 1898 年にセント エルモ ルイスが考案した「パーチェス ファネル」に似ている。ある製品がユーザーの目にとまってから実際に使用するまでのエンドユーザー ジャーニーを図にしたものだ。このプロセスは「じょうご」(ファネル、漏斗(ろうと))として視覚的にとらえるのが便利だ。というのも、障害物がどこにあるか、注力するべきところはどこなのかをよりよく理解するのに役立つからだ。たとえば、Drupal.org には 2017 年に 1,300 万人を超える訪問者があった(じょうごのいちばん上)。そして、約 75,000 の新しいプロダクション サイトが Drupal 8 で立ち上がった(じょうごのいちばん下)。このコンバージョン ファネルを下に進む間に膨大な数の評価者が失われているわけだ。その間に何が起こっているのかをもっとよく理解した方がいいだろう。

Drupal コンバージョン ファネルの例と各レベルの第 1 次ステークホルダー

上の図からわかるように、じょうごの最上部では Drupal Association が重要な役割を果たす。すなわち、Drupal のことをみんなに教えるところから、Drupal.org 上でダウンロードまでスムーズに進めるようにすること、テーマやモジュールを見つけやすくすることなど、たくさんある。

Drupal Association は評価者体験をもっと簡素化できるだろう。たとえば、ホスティングされたワンクリックお試しサービスを Drupal Association が提供するのもいい。それは Simplytest.me のようなサービスをホスティングされた評価サービスに拡張することで構築できる。特に、これから登場する Umami インストレーション プロフィールと組み合わせるといい(現在の「Try Drupal」プログラムは「Try hosting platforms」プログラムへと発展させればいい。現在はシームレスな Drupal 評価体験を提供するというよりは、いくつかのホスティング サービスを陳列することにフォーカスしているので、そう発展させれば、ユーザーの期待とのミスマッチも解消できるだろう)。

この話のいいところは、Drupal Association も同じニーズを認識していることだ。ここ数か月、僕たちは Drupal のコンバージョン ファネルを改善するプランに共同で取り組んでいる。Drupal Association は 2018 年の実行プランを数週間以内に公開する予定だ。それを見ればわかることだが、そのプランは評価者にとっての「ペイン ポイント」(痛い部位)に対処することになる(ただ、エンジニアとインフラのリソースが相当、必要になってしまうので、必ずしもホスティングされた試用サービスによってというわけではない)。

ドキュメンテーション作業部会The Documentation Working Groupも、このプロセスにおいてとても重要な役割を果たす。マシューの記事を読んだあと、僕は Drupal ドキュメンテーション作業部会のメンバーであるジョー シンデラーJoe Shindelarにコンタクトをとってみた。彼の話では、ドキュメンテーション作業部会は、もう長いこと、定期的にミーティングも開いていないし、(他の)イニシアチブとの連携活動も行っていないとのことだった。

Drupal のドキュメンテーションについてのアプローチを考え直すべき時だ。長年の Drupal コントリビューター(開発貢献者)であるアダム ホーニックAdam Hoenichは、ドキュメンテーションをれっきとしたコア イニシアチブとし、コア コミッター チームにドキュメンテーションのメンテナーを加えることを推奨している。また、彼の提案には、ドキュメンテーションに関する Drupal へのコミットをブロックする機能も含まれている。

僕たちがドキュメンテーション関連のガバナンス(統治管理)モデルを発展させる必要があることは間違いないと思う。良好なガバナンスのない委員会によって世界トップレベルのドキュメンテーションを執筆するのは厳しいわけで、アダムの提案はもっともだと思う。たとえば、Drupal の API ドキュメンテーションはコア コミッターたちによって管理されている。改善する余地は常にあるにしても、実によくメンテされている。以前はジェニファー ホッジドンJennifer Hodgdonという公式のドキュメンテーション メンテナーがいたことを覚えている人もあるだろう。そのポジション(役職)をもう一度設ければ、ドキュメンテーションはまた、注力すべきポイントがはっきりして、必要な管理を行えるようになるかもしれない。あと、僕が推測するには、連携調整、ガバナンス、ドキュメンテーション作業に対する評価にもっと力を入れれば、もっと多くのコントリビューターが協力してくれる気になるのではないかと思う。

話の順序としては最後になったが、大事なのは、これが Drupal(コア)コントリビューターにも影響するということだ。評価者は、Web サーバーの設定、PHP のインストール、データベースの設定に何時間もかかることがよくある。単独の「推奨デフォルト インストレーション環境」を作ることに決めれば、僕たちはコミュニティーとして、この「痛み」を軽減させられることだろう。たとえば、最新バージョンの Drupal に Docker コンテナ(公式の docker-compose.yml を含む)を加えてリリースすることにして、それをメンテ、プロモートするのもいいかもしれない。そうすれば、ドキュメンテーションにかかる多くの手間がもっと簡単になって、評価プロセスにおける多くの障害物がなくなることだろう。

おすすめをまとめよう。僕は次の 3 つのステップを提案する。

  1. 単独の推奨デフォルト インストレーション環境(たとえば Docker コンテナ)を用意し、評価者または開発者が Drupal 開発における最初のステップを踏めるようにする
  2. Drupal Association にインフラ予算とエンジニア人材を確保し、実際にホスティングされている「Try Drupal」サービスを提供できるようにする
  3. ドキュメンテーションのメンテナーを置き、エンドユーザー向けドキュメンテーションに集中できるようにする。そのメンテナーは、コア コミッター チームのメンバーとして、文書を作成すべき対象範囲を決める任務を負う。作業の量からして、このポジションにはコストがかかるだろう。部分的にでも資金を得られたら理想的。

もちろん、解決方法は、ほかにもたくさんあるだろうが、僕が注力したいのは上記の範囲だ。常々の話だが、成功するかどうかは、僕たちが、解決に向かって、まとまり、すべての作業を連携し、必要な改善策を施すために時間とお金を割り当てる、その能力にかかっている。僕が提案したうちの1つにでも協力できるようなら、コメントを追加して教えてほしい。そうしたら、参加できるよう案内しよう。