「wordpressで会員サイト、できる?」と訊かれた場合の検討の流れ

2013/07/11 (木) 案件検討

営業担当者から「Wordpressで会員サイトを作りたいと聞かれました。」という打診を受けた場合に、どのように検討していくかを書いてみます。
 
「すでに運用しているTokyoFloor上で構築できれば、弊社として構築や運用の効率も高いので、そちらにしたい」という認識は営業担当者と共有できているので、話はそこからスタートします。
 

Wordpressを指定された意味の確認

Wordpressという製品の指名は、どういう経緯なのかを確認します。
  • 揺るがせない事情があるのか。あるとしたらどういう事情か。
  • 価格面等の都合上、それを満たすプロダクトの一例として挙がっているのか。
このあたりはすでにお客様との打ち合わせにて確認していて、すぐに話してもらえます。Wordpress指名の場合、すでにWordpressの利用経験があるから、という理由が多いです。
 
この後、検討は2系統に分かれます。
  • Wordpress前提での検討
  • TokyoFloor前提での検討

Wordpress前提の場合は、一括納品のみの方向で検討

サーバ運用をお客様が行うか、弊社が行うか、が次のポイントになります。ここでいうサーバ運用の範囲は以下のものを含んでいます。
  • サーバ契約
  • バックアップ、リカバリーの準備、実施
  • OSレベルのセキュリティパッチ(これはレンタルサーバ会社のサービス範囲に含まれているかもしれない)
  • サーバ負荷の把握と増強
  • Wordpressのセキュリティパッチの適用
  • Wordpressで使うプラグインのセキュリティパッチの適用
項目によっては、やらない、という選択肢もあるかと思います。
弊社では、受託よりもASP方式でのサービス提供を指向しているため、サーバ運用のラインナップとして各種セキュリティパッチの提供などを含めて考えています。サーバ機器とWordpressなどのソフトウェアは階層が異なるモノなので、それぞれを分けてラベル付けしたほうがいいかもしれないですが、簡単のため一緒にしています。
 

お客様がサーバ運用される場合、デザイン・スタイリング面に限定した提案になる可能性が大

運用には目立たないメンテが結構かかることは一通り説明したうえで、初期サイトデザインのご提供という範囲に限定して検討・提案することになると思います。
機能面での検討は、弊社での会員用プラグインに関する知識と経験がないため、お役に立てないからです。短期間で知識を仕入れたとしても、その知識を最新にアップデートしていくためにリソースを割くのが厳しく、継続的な助言・回答ができないという問題もあります。
 

弊社にサーバ運用を委託される場合、デザイン面に限定した提案か、TokyoFloorを使った提案へ切り替える

これまでWordpressの案件数が少なく、また、会員用プラグインを扱った実績がないです。
そのため上記の範囲で責任を持ってサーバ運用しようとすると、運用対象の種類が増えてしまい、継続的に行うには厳しい状況です。
このため、デザイン・スタイリング面に限定した提案か、後述するTokyoFloor上での提案に切り替えることになると思います。
 
「このようなケースに対応したサービスをラインナップ追加する」と会社として決断する何かをそこに見いだすことがあれば、新サービスとして取り組むかもしれないです。
 

TokyoFloor前提での場合

運用を弊社が行うケースのため、Wordpressの場合と違い、運用主体と運用範囲に関する懸案は解消されました。
 
検討を一歩進めます。
  • やれること、やれないこと
  • 予算
  • 期間

予算と期間

予算と期間はケースバイケースですが、きわめて重要な点だと思うので、だいたいの目安を書いておこうと思います。
  • 初期費用:100〜300万円
  • 月額費用:3〜7万円
  • 期間:2〜5ヶ月

初期費用

初期費用では、移行するデータ件数が主要な指標値になります。
弊社とお客様で実施範囲、作業量の調整をして、費用の調整が行われるでしょう。

月額費用

月額費用では、会員数や月間アクセス量が主要な指標値になります。
 

やりたいこと、やれること、やれないこと

費用、期間の話と並行して関連しつつ、進められます。
相互に関連しますが、主にこのような流れで検討を進めます。
 
1. 背景も含めて、やりたいことのヒアリングをする。
 
2. 現状のTokyoFloorで対応できるか
  • 設定で対応できるもの→OK
  • 設定で対応できないもの→次へ進む
3. 本当に必要なのか、どういう背景があるのか
  • 不要→OK
  • 必要→次へ進む
4. 要件・仕様開発をする
  • 文脈を踏まえた上で、既存の範囲でできる別の方法を提案する
  • 汎用機能のどこかを拡張させて実現する見通しをつけ、OKであると提案する。
  • 厳しいことを伝え、業務を含めて別の実現方法を検討する。

特注機能開発ではなく、汎用機能開発で解決するように知恵を絞り、お客様と弊社のリソース効率アップを目指します

汎用機能として弊社が開発した場合、その機能に関する設定は初期費用になり、開発費用は弊社側の負担になります。
TokyoFloor自体のロードマップに沿いつつ実現できると、お客様にとっては費用が下がり、弊社としては実際の需要に応じた製品の成長となり、双方のリソースが効率よく活かされます。
特注で開発した場合、お客様側リソース増としては、初期開発費用に加え、月額の維持運用費用、以後の機能追加があります。また費用を頂いたとしても、弊社側も限られたリソースをその1点に割くことになります。
 

まとめ

弊社で会員サイトを提案する場合、現時点ではこのような検討になります。
  • お客様と弊社のリソース(費用、時間、人員)を効率よく活かすために、TokyoFloor上での構築、運用が第1の選択肢になります。
  • 現状で対応できていない利用方法や機能は、弊社の開発ロードマップを考慮し、汎用的な機能を弊社負担で追加開発することで対応できるかを主軸にして検討します。
 
<追記:2014年1月24日(金)>
 
Web制作会社様向けに、会員機能、メール配信などを含むCMSをASP形式で提供し始めました。
 
 
弊社の事例として、会員サイトの構築を掲載しました。

[案件検討]の記事