サイトリニューアルでサーバーとCMS問題が発生して困ってます。サイト制作(100ページのコーポレートサイト)は制作会社に800万で依頼してます。
CMSは既存サイトがMT6を使っているためリニューアルではMT7を使います。サーバーは当社で使っているサーバーを継続利用します。
デザインが固まったあたりで、制作会社から既存サイトのMTバージョンアップを先に行ってくれと言われて、やってもらえるのかと思っていたら対象外だと言われ自分でやる事になりました。いざ自分でやろうとしたらサーバーのParlのバージョンが低くMT7へのバーアップができないことが発覚。
そこでParlのバージョンが高いサーバーを新規で用意することに。であれば既存サイトのCMSバーアップではなくMT7を新規でインストールしてゼロベースで新サイトを構築すればいいではないかと思ったのですが
「それは想定していない」と回答でした。。
24 件の回答
すでに構築されている既存MTの構造そのまま使ってリニューアルサイトを構築することを想定してたのでゼロベース構築では対応が難しいと言う話です。(やるとしたら時間がかかる)。
そんなのここにききて初めて知りました。こういうやり方が普通なのでしょうか。
ちなみにMTを使っているのは「お知らせ」の部分だけでそのほかは完全静的です。
バーアップのデッドが5/11と言われ。
サーバー準備ができるのが5/8ごろ、新サーバーへのサイト引っ越しとMTのバーアップがこちらマターで私(インハウス Webデザイナー)は未経験領域。
元のサーバーでPerlのバージョンを上げられないって共有サーバー使ってるの？
完全に初心者ならちゃんとした制作会社に既存環境を見せる形で依頼した方がいいよ。ここで愚痴書いても仕方ない。
Re:3
アドバイスありがとうございます。共有サーバー利用です。既存環境は制作会社に共有していたのですが特になんの指摘ももらってません。
今回の制作会社は「ちゃんとしていない」というご判断でしょうか。10社くらい比較検討して決めた中堅の制作会社なのですが、見極めるのは難しいです。
すでにデザインフェーズが終わり構築に入っているので他社に切り替えはできそうにないです。
知りたいことは下記です
・上記を前提にしたときの一般的なリニューアルの進め方
・現状でリリースまでの効率的でリスクの少ない進め方
・制作会社に非があるならその内容
→MT7を使うのにParlの上位バージョンが必要なら事前に制作会社が気付くべき思うのがひとつ。
・こちら側に問題があるならその内容
リリースまでこの制作会社とやっていくしかないので、反省会を改めて実施したく。見積もりも再交渉したい。
ちゃんとしている会社ほど、当初の想定になかったことは対象外になると思うよ。
見積もりにも入れてないだろうし。
既存のアップグレード済みのMTの改修作業と、新規構築じゃ工程も工数も違うんだから「想定してない」って回答でも仕方ないよ。
で、１がサーバーの準備が難しいなら別途見積もりとってやってもらうか、
共用サーバーの簡単インストールみたいなのでMT7入れて、中身だけコピペしていくかどっちかじゃないかな。
旧サーバーのDBダンプして、ドメイン周りのデータを修正して新サーバーにリストアってのが一番簡単だけどね。
Re:6
アドバイスありがとうです。
当初よりMT7で構築してくれと依頼はしましたが「既存のアップグレード済みのMTの改修」という話は一度もしていないのは確かです。見積もりに「過去の投稿記事の移設作業3年分 20万くらい」が入っていたので新規構築を想定していたはずと思うのですが。
手元に見積もりがないので改めて確認しようと思います。GWはやくあけないかな。
新サーバーは手配済み、MT7のインストールやデータ移行はやろうと思えばできそうです。バージョンアップやろうとした時さんざん調べたので。最近のMTは簡易インストール機能はサーバー各社で用意ないみたいなのでいろいろ手間取りそうですが。
なんだかふに落ちなくて相談させていただいた感じですー。
Re:6
制作会社は要件定義の段階で確認すべきことを怠ってるよ。共有サーバーならミドルウェアのバージョンは自由に出来ないし、既存環境の確認の時点で、互換性の確認は普通する。デザイン専門なのかもしれないが、それも言い訳にはならない。
何よりクライアントのリテラシーレベルも把握してない。リプレイス案件はクライアントのリテラシーレベルの誤認トラブルが多い。営業による瑕疵担保責任だけちゃんとしてるけど、要件定義もまともに出来ないてないというのは中堅にはほど遠いよ。
ただ、トピ主がどういうやり取りをしたか分からないから制作会社が誤認する要素はあったんじゃないなと思う。
サーバーの環境確認、ミドルウェア環境確認。
移行環境、バージョンの確認、ここで詰まるから提案をするのが普通。けど、今だとコロナの影響で知見ある人がメンバーから抜けた可能性となもあるかもしれないから、納期を緩めて歩み寄らないとダメだろうな。
基本的にリプレイスは揉める案件が過半数以上だよ。
新サイトに切り替えるまでは、旧サーバでMT6のまま公開
新サイト用にMT7と旧サイトのテーマ、エントリーをコピーし、ここで制作させる
切り替え時にニュースあたりの差分があればコピー
＞・上記を前提にしたときの一般的なリニューアルの進め方
要件を見直す
＞・現状でリリースまでの効率的でリスクの少ない進め方
制作会社を変更する か MT6でリニューアルする
＞・制作会社に非があるならその内容
＞→MT7を使うのにParlの上位バージョンが必要なら事前に制作会社が気付くべき思うのがひとつ。
それはない。環境を提示するのは依頼側の問題だ。制作者はエスパーじゃない。例えばサイト制作もサーバ構築もコンサルも同じ制作会社に依頼していて、「MT7にバージョンアップしましょう」って提案されたのに、「うちではできません」ならおかしいし、詐欺だ。でも、そうじゃないんなら、依頼する側が悪い。
＞・こちら側に問題があるならその内容
制作会社の選択をミスってる。新しいことがしたいなら、それに対応できる制作会社を選ぶべき。今の制作会社を選んでも絶対失敗する。
Re:4
>10社くらい比較検討して決めた中堅の制作会社なのですが、見極めるのは難しいです
何をもってして中堅と判断したのか興味があるけど、要件定義の担当窓口が素人同然なのは確実。
ある程度の規模のものを環境を含めてリプレイスする依頼を無事に終わらせるのは難しいから大手だとPM、マネジメント経験がある人をなるべくSIerとして用意する。
相見積もりを取っても請け負った会社がまともかどうかは知見を持ってない分野がでると判断が出来ないのでそこは仕方がない。トピ主のようにWeb全般(デザイン以外？）に明るくない人にとっては信用できるサーバーサイドもわかるエンジニアを探して発注担当として雇うか、失敗を糧にして自らが学んだ方がいいと思う。
無責任な意見としてだが個人的にはさほど素人でも敷居が高くないのではと思う。
新共有サーバーにPerl7環境があり、ほかのミドルウェアを満たしてるならDBのDumpしたデータをインポート,バージョンそのままのMT6をインストールするだけでいけるだろうから、段階を踏んで環境を変えればどこが問題なのかもわかると思う。あと一番ダメなのは共有サーバー。
800万の案件で共有サーバーは今の時代では考えられない。Dockerとかの提案は無かったのかも気になる。
Re:13
アドバイス、ご意見ありがとうございます。バックエンドに詳しいのですね、勉強になります。
中堅と判断した理由は過去の制作実績だったり(有名企業のサイトリニューアル手掛けてる)、会社の規模や体制だったい(内部にちゃんと制作部隊がいる)、見積もりの予算感などでした。仰るように主担当者は素人で新卒の若手、それにベテランのPMが付き。若手は不安でしたがベテランがつくならと。。
アドバイスもろもろありがとうございます。
この制作会社を選定した私の責任がありますので自分が動いて何とか着地させようと思います。担当の若手君の熱心な売り込みは良かったんですけど。。
外出もできないGWで暇なので、昨日は一日中自分のプライベートのレンタルサーバーでMTのインストールや設定をやってみました。WPサイトはさんざん作ってきたのでわかるのですが、MTは10年くらいぶりなので調べまくりでなんとかなりそうな予感です。
Re:9
ご意見ありがとうございます。参考になります。
私のサーバーの知見が低いので誤認に繋がった可能性はあるかもです。
利用中レンタルサーバーはこれですって、サービス提供会社と契約中のプランのURL、契約管理画面のキャプチャなどを送って共有し、問題ないと回答をもらっていたのですが。
実は利用サーバーのParlのバージョンはその領域を契約した時期に依存するらしく、現在のサイトの領域確保(契約)が5-6年前(私がこの会社に入社前で詳細不明)。同じプランでも最近の契約であればParlのバージョンが高い領域での契約となるので、これで誤認になったのかも、と今思いました。
>リプレイス案件は揉める
そ、そうなのですね。私は今回初のリニューアルプロジェクトリーダー経験なので業者選定からRFPの作成など勉強の連続でしたが良くも悪くも良い経験となってます。
コロナを理由にして違約金払ってキャンセルにしたら
Re:18
今だと制作会社側もコロナの影響はあるから客には言えない問題あっても不思議じゃないよ。本当にタイミングが悪いし納期は諦めるしかないよ。大切な命を危険に晒してまで仕事して欲しくもない。
800万規模の案件で共有サーバーなんてありえるんだね。
勉強になったよ。
共有サーバーということは、サーバーインフラに関わる開発・設定・管理コストがかからないというわけで、正直、いったい何に800万が消費されてるか甚だ疑問。
Re:20 金額が大きい案件は専用サーバーを使う？のが一般的なんです？
800万の金額は置いておいて、私からみるとたかが静的コーポレートサイトでちょこっとCMSつけるだけなので、言い方はアレですが、そんな壮大な？サーバーが必要なのかなと逆に？な感じで。既存サイトもこれまでその共用レンタルサーバーで5-6年運用してきたわけで。その間にいろいろ進化？変化？があったのです？
サーバー難しいなー(涙)
見積もりが手元にないので800万の内訳は出てこないですが、100ページのデザイン、コーディング(レスポンシブ)、CMS開発、ディレクション、過去投稿移設といった内容です。同じRFPで相見積もりとった中では800は安い方で大手他社は1000万超えでした。
Re:22
そんだけ予算あれば普通は共有サーバは避ける。他の借主がセキュリティ的なポカをしたり、プログラムの無限ループを走らせたりすればこちらも巻き添えを食うからね。
Re:22
サーバー周りのハンドリング(決定権)は誰がやってるの？
話を聞く限り、そもそもそこから素人がやってるんじゃないの？
Webデザイナーやってるなら分かると思うんだけど、コーディングコストはページ数じゃなくて、テンプレート数が主ね。ページの量産なんてテンプレートさえあれば流し込むだけだからコストのうちに入らない。それにCMSでの実装がくっついてるだけだから、俺の見立てだと、ディレクション費が600〜700万だね。
そういう相場観で、月1〜2万円のサーバーコストをケチるんだ。へー。っていう感想。
Re:22
共有サーバーは権限が不足してることで、簡単にターミナルからミドルウェア等の管理が出来ないし、今回ならperlのアップデートすら出来ない。
制作会社からしたら開発環境から本番環境への移行も共有サーバー運営元の独自コントロールパネル、権限を挟むので予想外のことが増え、コストも危険度も上がる。一般には要件定義で共有サーバーと聞き出したら制作会社がAWSやGCPなど提案するんじゃないかと思う。
更にはサーバーが不安定になる要素も多く、負荷分散、スケール設定も自由でないので安定稼働できない。Webデザインだけで800万ってのが一概に高いわけじゃないけど、どうしても指定の共有サーバーにしたいというのでなければ辞めた方がいい。ランニングコストも損だし一般的にコマンドで環境構築するものなので次にリプレイスする時にも制作会社の見積もりが上がると思う。