WEBSASが提供する医療従事者向けテンプレート”Pharma.websas.jp”とは！？

やはりこれが最大のポイントかと思っています。
例えばトップページに表示したい要素やデザイン面など、お客様毎でのご要望に応じたカスタムは有れど、既にベース機能が存在しているため、開発は非常に短納期で進めることができます。私も過去2案件、Pharma.websas.jpの導入案件に携わってきたのですが、いずれも「関連サイトを含む3サイトを6か月」「1サイトを4ヶ月」で構築ができました。ゼロベースでいわゆる要件定義から機能要件を伺って仕様を固めていく、という進め方なのではなく、「Fit＆Gap」という形で、既存のお客様サイトの仕様や求められる機能とPharma.websas.jpでどのようなGapがあるか？という見方で機能要件を固め、設計に落とし込めます。そのため、作り手としても最大限に効率的に構築を進められる仕組みが整っていると思います。

WEBSASとしてもPharma.websas.jpの導入実績が増えてきており、各案件での対応経験によるDrupalの開発ナレッジの蓄積や、他社様で導入した機能の設計を応用して新機能を生み出すなど、日々進化しています。例えば直近ですと、Pharma.websas.jpには元々お問い合わせフォームの機能があったのですが、この機能を応用してアンケートフォーム機能を構築し、機能メニューとして加わりました。ベースとなるテンプレートそのものが日々ブラッシュアップされ、導入されるお客様にとっても選択肢を広げていることは大きな特徴です。

テンプレート導入にあたり、もちろんそのままPharma.websas.jpの機能を導入するのではなく、お客様にあわせたカスタマイズも行っています。例えば、昨今のコロナ禍では必須機能ともいえる「Web講演会」について、Pharma.websas.jpの標準仕様としては「ライブ配信(申込必要)」「オンデマンド配信(申込不要)」の2種をベースとしています。しかし、お客様によっては申込の要否が異なったり、そもそも「ライブ配信/オンデマンド配信」というカテゴライズが異なるケースもあります。いくら機能テンプレートを保持していても、カスタマイズと称して都度大型改修が必要になってしまってはあまり意味がありません。こうした仕様の設計も開発者の腕の見せ所だと思っています。
Pharma.websas.jpは「汎用機能テンプレート」なので、いかに機能を汎用的な仕組みとして保持しておき、要件に合わせて展開するかがカギになります。例えばWeb講演会の例ですと、Web講演会コンテンツを作成する際に、チェックボックスを1つON/OFFするだけで、申込可否や区分を設定できる実装にしておく、など、選択肢を設けられる仕様もその一例です。お客様側でその機能を使用する・使用しないを選べるようにできると、サービスとしての幅も広がるのではないかと考えています。

先述のフォームや講演会の機能を1つ作成するだけでも、様々な設計方針・ロジック・考え方があります。このとき、私が重要だと思うのは、Acquia CloudというPaaSのサービスを用いて、DrupalというCMS上にシステムを構築する、ということを念頭に置いて検討することです。CMSとはコンテンツをマネジメントするシステムなので、エンドユーザー（今回は医師・薬剤師の方など）だけでなく、コンテンツのオーナー・作成者への意識も欠かせません。Drupalは、拡張モジュールというCMS上に追加機能を導入できる仕組みも備えているので、Drupalの機能を用いて構築できることがもちろんベストです。しかし開発するうえで、必ずしもDrupal機能に依存せず、どこまでをDrupal機能を活用して実現するかの見極めも重要だと思っています。
例えば講演会の申込をはじめ、サイト内で予約や申込をさせる機能はいくつか備えているのですが、それらについてはDrupalのデータベースではなく、Drupal外のデータベースに申込データを持たせる設計とし、いわゆるDrupalが備えるフォーム機能は用いずに構築をしているケースがあります。そのような作りにすることで、もちろん中には作り手が要件通りの見た目や機能で仕上げやすいという都合もあります。ですがやはり、コンテンツを作成する際にいかにしてシンプルに作成ができるか、また申込データを活用しやすい形で保管できるか、という運用面を考慮しているのです。