ECサイト構築・CMS導入

CMSもECも、
導入した日からが本番です。

方式の選定から設計、構築、データ移行、運用までをワンストップで担います。会員サイトやECサイト、アプリ開発まで、長く使える基盤をつくります。

ISSUE

選択肢が多いほど、選定は難しくなる。
比べる観点を定め、最適な方式へ導きます。

CMSもECも、製品の数だけ長所があります。製品の比較から始めると、迷いは深くなる一方です。先に運用の実態から比べる観点を定めることで、選ぶべき方式は自然に絞られます。

01 どのEC・CMSプラットフォームが合うのか、判断できない
02 更新のたびに、外部へ依頼している
03 既存のデータを移せるのか、分からない
04 運用の担当者が少ない
05 アプリとの連携まで、見通せていない

OFFER

製品から選ばない。運用から選ぶ。
方式の選定から、移行・運用までを設計します。

誰が、どの頻度で、何を更新するのか。運用の実態から逆算して方式を選び、構築、移行、公開後の支援までをひと続きに担います。

実績を見る

製品に偏らない、方式の選定

ECサイトは、ASP、オープンソース、パッケージ、フルスクラッチの中から構築方式を選びます。CMSも、WordPressやMovable Typeから、microCMSなどのヘッドレスCMSまでが候補です。比べる観点を先に定め、運用に合う方式を一緒に決めます。

要件を決めたチームが担う、設計・構築

会員機能、決済、外部システムとの連携。定めた要件を、そのまま動く仕組みへ実装します。

検証してから移す、データ移行

商品、会員、記事。既存のデータを欠かさず新しい環境へ移す計画を立て、検証します。

自社で更新を続けられる、運用設計

少人数でも回る更新の流れを設計し、マニュアルとガイドラインを整えます。

FLOW

選定の根拠を、あとから説明できるように。
比較から運用まで、判断の過程を残します。

なぜその方式を選んだのか。担当が替わっても、数年後に見直すときも、判断の過程が残っていれば迷いません。各工程で、根拠を成果物として残します。

進め方・体制を見る

要件定義

運用の体制と、必要な機能を定めます。誰が、どの頻度で、何を更新するのかを伺い、機能の優先順位まで決めておくことで、方式を比べるときの物差しになります。

成果物
要件定義書
方式の選定

観点を定め、候補を同じ物差しで比べます。費用、更新のしやすさ、拡張性などの観点で候補を並べ、選んだ理由を比較表に残します。社内でご説明するときも、そのまま根拠としてお使いいただけます。

成果物
方式比較表
設計・構築

定めた要件を、動く仕組みへ実装します。要件を定めた当社がそのまま設計と構築を担うため、途中で意図が変わりません。会員機能や決済、外部システムとの連携も、同じチームで進めます。

成果物
設計書
データ移行

既存のデータを移す手順を定め、試行します。本番の切り替えの前に試しの移行を行い、件数や表示に欠けがないかを確かめます。切り替えの日取りも、運用に影響が出にくい時期を一緒に決めます。

成果物
移行計画書
テスト・公開

決めた範囲をすべて確かめ、公開します。何をもって完了とするかは着手の前に決めておき、公開の手順と、元の状態へ戻す手順もあわせて用意します。

成果物
検証計画書／テスト結果報告書
運用

更新の流れを整え、公開後も支えます。更新の手順をマニュアルとガイドラインにまとめ、ご担当者様が迷わず更新できる状態にしてお渡しします。公開後の改善のご相談にも、同じ窓口でお応えします。

成果物
運用ガイドライン