[目的]複数の部門で個別に立ち上げていたサイトを一本化する。
サイトの目的はおおよそ下記のもので、現時点では、顧客サポート面が強いです。
- 会員向けに、情報提供
- 会員のうち製品購入ユーザーには、さらに追加で情報提供。
- 会員向けにメールマガジンを配信。このうち2週類は製品購入したユーザー限定。
- 非会員向けにも、情報提供。
- 各種お問い合わせフォームの運用。
[要件]サイトに盛り込む必要のあるコト
業務上、実現が必要な要件がいくつかあり、お客様のほうで明確になっていました。
そこからシステム仕様へと落とし込む点が、弊社で要件定義・設計作業にて注力した点です。
会員登録フロー
- 会員の登録時に、入力された会員情報を元に、競合社であるか否かのチェックを行いたい。
- 製品ユーザか否かのチェックを行い、製品ユーザには、追加で情報提供などを行いたい。製品ユーザのデータは社内の別システムにある。
メール配信
メールマガジンは3種類あります。
製品ユーザであるか否かの会員情報をここで使います。
- 1つめ：希望者全員
- 2つめ：特定の製品ラインのユーザで、購読を希望している人
- 3つめ：別の製品ラインのユーザで、購読を希望している人
このほか、バックナンバーはサイト上に掲載され、購読者が閲覧できるようにしたい。
会員限定コンテンツ
通常の会員に加え、製品ユーザ限定の情報もあり、閲覧の制限は主に3種類あります。
- 非会員が閲覧OK
- 通常会員が閲覧OK
- 製品ユーザ（それぞれ）が閲覧OK
また、情報の形式は2通りあります。
- Webページ
- PDFファイル
お問い合わせフォーム
様々なフォームがあります。
もともとの静的サイトでは動的なWebフォームを扱えなかったことが、各部門毎でサポートサイトを立ち上げる契機にもなっています。
このため、フォーム類の集約と業務フローへの効率的な組み込みが、大きな目的の1つでもありました。
特徴としては、
- 入力項目の値に応じて、運用側への通知メールの宛先を変える
- 会員登録済みの方は、名前等の入力を省略するなど、補助機能が欲しい。
- 製品情報ページとの連携。製品情報ページにあるお問い合わせボタンを押すとフォームに製品名が入力済みになっているなど。お問い合わせ業務を円滑に進めるためには製品名、型番等が必要なため。
[あとで追加]セミナー情報（情報＋申し込み）
様々な経緯があり、終盤が近づいてから急遽受け持つことになりました。
- セミナー情報の表示
- 各セミナーへの申し込みフォーム
- 申し込みフォームでは、セミナーごとに運用側への通知メールの宛先を設定できるようにしたい。
フォームを使った部分全般的に言えるのですが、担当者への通知メールの宛先を条件に応じて仕分ける、という作業が日常的にかなり面倒になっているようで、作業ミスの削減という目的も持っていました。
導入時の進行
お客様のほうで、実現したい要件がかなり整理されていました。
このため、妥当なシステム仕様へと落とし込んでいくことがメイン作業となりました。
- 要件をシステム仕様に落とし込み、要件を満たすかのチェックをしていただく。
- チェック作業において、暗黙知になっている関連要件が引き出される場合あり。
- システム側での制約がある場合は、代替え案を検討して、仕様を提示する。
会員データは既に存在していたので、各業務での利用方法、形式の変換など、システム開発でいうデータ設計に費やした時間が多くなりました。
また、込み入った仕様を割り切り、簡易な組み合わせにするなど、実際の業務頻度を考慮して設計した仕様もいくつかあります。
並行して行われていたコーポレートサイトのリニューアルのほうが人員規模が大きかったです。
2週間に1度くらいの頻度で打ち合わせ訪問し、それ以外はバックログ（ http://www.backlog.jp ）を使って質疑応答を行いました。
導入後の運用イメージ
会員登録審査
- 会員登録を行うと、いったん審査待ちのステータスになる。
- 運用側へ審査依頼メールが自動送信される。
- 通知を受けた担当者は記入された情報をもとに競合社チェックなどを行う。
- OKならば、アカウントを有効にする。
- 完了すると、会員宛に自動で登録完了メールが送信される。
製品ユーザ審査
- 会員が製品情報を記入した場合は、製品ユーザか否かをチェックする担当者宛に通知メールが自動送信される。
- 記入された情報と、社内にある製品ユーザ情報との突き合わせをおこない、OKならば、会員属性を変更する。
会員情報変更時の通知
- 競合チェックなどを行っているため、会員情報が変更されると、運用側へ通知メールが自動送信されます。
お問い合わせ
- 複数あるお問い合わせフォームは、それぞれ運用側への通知メールの宛先が異なる。
- フォームによっては、フォームにある選択肢に応じて、さらに通知先が異なる。
期間
並行してコーポレートサイト（日、英）のリニューアルがあり、本サポートサイトも日英の2サイト（内容がある程度異なる別々のサイト）としたため、お客様側の作業負荷が非常に高い中での進行となりました。
わたしのほうは、常時100%稼働ではなく、変動が大きくありつつの進行でした。
TokyoFloorが目指している柔軟な構築力を活かし、着実に現物を構築していくことになりました。
- 8月〜10月：仕様の検討、設計、不足機能の開発
- 11月〜12月：システム的な設定、仕様再検討、不足機能の開発
- 12月〜1月：コンテンツの移行作業