WPでサービス・サイトをつくるお話・その1

WordPressを使って「サービス・サイト」つまりWEBサービスを構築する時の心づもり、というかよもやま話をしたいと思います。

「サービス・サイト」って何?

前提として、「サービス・サイト」とはどういったサイトを指すのかということですが、これは要するに一方的なコンテンツの提供のみならず、何らかの特定の「機能」をユーザーに提供するサイト、ということになります。

たとえば、

  • 情報検索系サイト(ポータルサイト)
  • 予約系サイト
  • 販売・レンタルサイト(ECサイト)
  • マッチング・サイト
  • etc

というようなものが考えられます。
これらのサイトの多くはメンバーシップ機能を持ち、ここが一般のコンテンツ提供サイトと一線を画する部分となります。

なぜかと言うと、メンバーシップ機能を有することにより、特定のサービスを特定のユーザーに提供することが出来、またそれらのためのシステムを構築する必要があるからです。

ですので、サイトとしての要求事項はコンテンツ・サイトとは段違いに違ってきます。特に、WEBサイトの「フロント」のみならず、普段は目にしない「バックエンド」の部分に多くの手間を割く必要が出てきます。

「サービス・サイト」を作るには?

当然、動的サイトを制作するわけなので何らかのプログラム言語(およびデータベース)を駆使し、WEBサーバ上で動かします。このときによく使われる言語としては、PHP、Java、Rubyなどがあるのはご周知の通りだと思います。

ある程度の経験があればこれらの言語を使い構築することはできるのですが、より速く、確実に開発できるよう、WEB開発に必要な骨組みや機能のソースコードがまとめられたパッケージ(フレームワーク)が多数用意されており、有名なものでは

  • CakePHP, Laravel , symphony , Zend Framework….
  • Ruby on Rails

といったようなものがあります。実際1からコードを組んでサイトを制作する(スクラッチ開発)のはかなり大変ですし、似通った機能を毎回開発するのは不合理ですので、ほとんどの現場ではこのようなものが利用されることになると思います。

しかしながら、フレームワーク(以後FW)を用いたとしても必ずしも快適に開発できるものではありません。

FWはプログラミングの基礎知識を持っていることが前提ですし、仮に言語を理解していたとしても、すぐに便利に使いこなせるようなものではありません。そのフレームワークの「作法」について習熟する必要があり、相応の学習期間が必要です。さらに、フレームワーク間の互換性はほぼないので新しいフレームワークに移る場合は再び学習する必要が出てきます(もちろん共通性はありますので、ひとつこなせば他のシステムもある程度速く身に付くと思います)

もっと簡単に作れないか?

ということで、CMSをいじって行けば何となく「それっぽい」ものになるのではないか、という試みもされて来ました。

たとえば、CMSの基本は「投稿」ですが、この投稿に一般的なブログ記事などではなく、何らかのジャンルの情報を記述し、検索が出来るようになれば一種の情報検索ポータルサイトになってきます。

 WordPressであれば、その他必要とされるメンバーシップ機能やコンタクト機能や、その他必要な細々したものは(仕様にこだわらなければ)プラグインの実装だけで導入することが出来ます。

ですので、ごくごくシンプルな形態のもであれば、かなり低コストで実現できると言えるでしょう。

しかし、ここで罠があります。

WPによる開発で遭遇する「壁」

プラグインの実装だけで片付く場合は良いのですが、そのプラグインの機能を超えたものが欲しくなった場合、どうすれば良いのでしょうか?そのプラグインを改造すれば良いと思われるかもしれませんが、(よほどシンプルなプラグインでない限り)WPのプラグインの解析は想像以上に大変です。そしていったん改造を加えてしまうとそのプラグインのアップグレードを受けることが出来なくなります。

これではWPの本体もおいそれとアップグレード出来なくなりますので致命的です。プラグインの改造は、そのプラグインのソースを隅から隅まで理解していない限り、NGと思って良いでしょう。

たった一つの要求のために、利用していたプラグインと同等のものを自前で開発する必要が出てきてしまい、開発手間・コストは大きく膨らみ、納期を圧迫します。私はこれを勝手に「プラグインの壁」と呼んでいます。

この様子を簡単に図示するとこのような感じになります。あくまでも感覚的なものなので、数値的な根拠はありません。雰囲気を見て頂ければと思います。

 

PHPなどの言語を使い原則的にゼロから開発することをスクラッチ開発と呼びますが、このスクラッチ開発やFWを使った開発の場合、開発の手間はほぼ要求項目に応じて比例します。さらにこの両者を比較すると、FW開発の方はスタート地点での手間を大きく低減することが出来る分有利になります。これは、大抵のFWがWEB開発で必須のコンポーネントをあらかじめ用意しているからです。

いずれにせよ、これらの場合はプロジェクト全体の作業ボリュームを積み上げ式で、比較的容易に掌握することができるでしょう(もちろん、途中で大きな仕様の追加や変更がない限りにおいてですが)。

これに対してWPでの開発はというと、先の「プラグインの壁」にぶつかるごとに大きく工数が跳ね上がり、サイトが複雑になればなるほどコストが大きくなります。

そして厄介なことに、プロジェクトの企画段階ではなかなか「プラグインの壁」が見えず、往々にして開発途中でプラグインの限界が見えてしまうことが少なくないのです。

こうなってしまうとWPでサクサク簡単に構築するという感覚はなくなり、手間とコストでの優位性が見いだせなくなってしまいます。最悪の場合、スクラッチ開発に匹敵する手間ばかかって採算が合わなくなり、納期も圧迫されてしまいます。

「見立て」が重要

そこで重要になってくるのが、受注前に、あらかじめサイトの目的・規模・仕様を見定め、上図の緑の範囲、つまりWPが優位な範囲に収まるかどうか見立てをするということです。どのようなサービス・サイトであれ、さすがにプラグインの利用だけでは使えるものにならないので、どの部分でプラグインが利用でき、どの部分が自前のコーディングになるのかを大まかに掴んでおき、それに応じてボリュームを把握しておきます。

この際見落としがちなのがバックエンド部分の開発コストです。少なくとも投稿されるデータ、ユーザー情報、主なオプションなどはサイト管理者が編集できるようにするのが基本なので、この部分の開発ボリュームも見込んでおく必要があります。

これらを見込んだ上でなおWP開発が手間・コスト・納期で優位になりそうであればこちらを選定すると良いでしょう。

実際問題としてこの全体の「見立て」はそこそこの経験値がないと難しく、経験値があっても往々にして想像以上の事態に発展しまうことも少なくありません。

そこで、WPで開発しようと迷った場合は以下の点をチェックしておくと良いと思います。

  1. サイトオーナーがWPに親しんでいるか
  2. サイトとして持たせたい機能が明確に洗い出されているか
  3. 仕様やルック&フィールなどにおいて、機能に抵触しない範囲である程度の許容範囲が認められるかどうか
  4. その他にWPを使いたい理由があるかどうか(コンテンツの管理等)

次稿では上記の点についてもう少し具体的に説明して行きたいと思います。

(その2へつづく)