Webサイトリニューアル案件。『今のサイト』を知っておいてよかった #233
2026-09-07 12:15

Webサイトリニューアル案件。『今のサイト』を知っておいてよかった #233

spotify apple_podcasts youtube

先日、6月末にリリースしたとあるサイトリニューアル案件の打ち上げがありました。
メンバーにも恵まれ、良いプロジェクトだったと感じるのですが、振り返ってみるとこの案件はいきなりリニューアルから始まったわけではありません。
旧サイトの保守や改修から関わっていたことが、その後のリニューアルにどう効いたのかを話します。

▼関連する過去回:大型リリースの節目に。自分の価値を高める下半期の仕事の選び方を考えた #220
https://listen.style/p/choisaki/uanjlae7

 

■おたより募集
番組では、働き方やキャリアに関する悩み、聞いてみたいこと、エピソードの感想などを募集しています。隣の席の先輩だと思って、気軽にお送りください。
▶︎ ハッシュタグ: #ちょいさきトーク
▶︎ おたよりフォーム:https://form.run/@choisaki
▶︎ マシュマロから匿名でもOK! https://marshmallow-qa.com/mypacecreator

■パーソナリティ:けい|Webと仕事を語る、隣の席の先輩
40代・2児の母。会社員を経て、現在はフリーランスとして、Web制作や中小企業のWeb活用支援に取り組んでいます。職場で隣の席の後輩にそっと話しかけるような感覚で、働くうえでのちょっとした経験や思いを音声にしています。
▶︎ Xアカウント:https://x.com/mypacecreator
▶︎ note: https://note.com/mypacecreator

#ちょいさきトーク #Web制作 #フリーランス #キャリア #仕事

感想

まだ感想はありません。最初の1件を書きましょう!

00:01
ちょいさきトーク,あなたよりちょっと先歩いてきた人のWebと仕事の話. この番組ではフリーランスでWeb制作をしている私,けいが,上司じゃないけどちょっと気軽に話ができる隣の席の先輩のような立場でWebと仕事について語ります。
さて、私6月の末にちょっと大きな案件のリリースを無事に完了しましたよという話を配信でしました。
先日この案件に関わったメンバーと打ち上げ総称して飲み会を行いまして大変楽しい時間を過ごさせていただきました。
メンバーは製作チーム。製作チームは主に名古屋近郊を拠点にするメンバーが集まりまして、クライアントさんは会社は東京なんですけれども、それぞれリモートでちょっと離れた場所を拠点にしている方もいらっしゃって、
クライアント側のメンバーが3人、製作側が私を含めて4人という合計7人で楽しい飲み会をさせていただきました。
チーム名はプロジェクトの途中で停職をされまして、途中でプロジェクトメンバーからは抜けられたんですけれども、今回リリースを無事にしましたよということで改めてお声掛けをしてですね、一緒に打ち上げをしたという感じだったんですけれども。
何ですかね、会社を離れてもこんなに仲良く飲み会ができる関係性というのは本当に良い会社だなというのをあたから見てもすごい感じたんですよね。
今回クライアントさんと受託側という関係性ではあるんですけれども、どちらかというとかなりワンチームに近い感覚でできた、本当に良いプロジェクトチームができたなという印象でして、メンバーには本当に感謝をしております。
こういう感じで飲み会ができると、しかも普段関東を拠点にしているクライアントさんもわざわざこのために名古屋に来てくださいまして、本当に飲み会の中では仕事の話がほとんどなく普通に楽しい飲み会だったという感じなんですけど。
お互い今後も運用フェーズでお付き合い続いていくので、これからもよろしくお願いしますということで一応開きに会ったんですけど。
そこで飲み会から帰って、この案件どうしてこんなに良いチームで進められることができたのかなというのを考えてみたんですね。
なので今日はこの話をしたいなと思います。
行ってしまうとクライアントさん側のITデラシーも比較的高くて、前方にもプロジェクトマネジメントされた経験があったりとかしますので、
その辺の知見が生かされてうまくいったのかなという話にはなるんですけど、
でもそれだとちょっと再現性がないですよね。
クライアントさんが優秀だったからうまく進められました。
そうではないから進められませんでした。
そうではないというのはちょっと語弊があるんですけど。
03:00
いうのは再現性ないですし、いろんな方とプロジェクトを進めていく立場としてあまりそういう結論にしたくないなというのがあるので、
もう少し何か今後に活かせるところないかなと考えてみたところですね。
他に過去に私がリニューアルで関わった案件と共通するここが良かったなと思うところが一つ見つかりました。
そもそもこの会社さんのウェブサイトに関わることになったというのは、今回のサイトのリニューアルからいきなり入ったというわけではなかったんです。
もともとは他社さんが制作した既存サイト、そこに関して改修とかいろいろやりたいことがあるからということで、
先に運用とかマーケティングのサポートの方で入っていた方からお声掛けいただいて、
WordPressのサイトなので私の方でできないかということでチームに入れていただいたんですけど。
結構リニューアルする前の他社さんが制作したサイトの更新、改修、機能拡張、リファクタリングなど結構やりました。
1年以上ぐらいそういった形で関わったのかなと思うんですけれども。
つまりリニューアルの相談を初めて受けてその会社さんとのお付き合いが始まったというわけではないんですね。
振り返ると他社さんの制作したサイトのメンテをやっていた期間っていうのがかなり今回のプロジェクトを進めるにあたって効いていたのかなというのを感じました。
今回の案件の会社さんでは複数の事業があって、今その事業ごとにウェブサイトが別々にあったりとか、
その事業サイトごとに担当者が別々にいたりして、それぞれの事業で動き方も違うということもあり、
外からサイトを眺めたり会社概要を読んだだけではわかりづらいいろいろな内部の事情というのがあったんですね。
講習とか改修なんか続けていますと、誰が何を担当していて、事業部が何をしているのかとか、
実際にサイトの更新担当する人たちがどういう風にやっているのかというのがちょっとずつわかってくるので、
それはいきなりリニューアルが決まってからの短時間でそれを知るよりも、
結構深く会社さんのことを理解した状態でリニューアルプロジェクトに入れるという大きな利点がありました。
過去の別案件でも、最初既存サイトのメンテナンスでご相談いただいて保守契約を結んでいただいて、
そこから何年か経ってリニューアルという風に至ったケースというのが一覧あるんですけれども、
そういったケースってお客さんの事業内容とか、お客さんの顧客がどういう層なのかっていうのを理解した状態から始められるので、
かなり前提条件を揃えるのがスムーズだったりとか、要件定義もあんまり外さないという印象がありますので、
リニューアルの前に一旦保守から入るっていうのはかなりいいのかなというのは強く感じたところです。
06:02
あとはちょっと枝葉の話になるんですけれども、私が制作側だから感じる話として、
保守で入ってサイトの回収なんかをしますと、既存のサイトのコードとかWordPressのどういうカスタマイズが入っているのかというのも見ることになるんですよね。
そこにはそれまでの制作や運用の積み重ねが化石のように残っておりまして、
そこだけ見るとなんでこんな実装になっているんだろうとか、このコード読みづらいなとかいうことが正直あるんですけれども、
もう少しちゃんと丁寧に見ていくと、たぶん作った当時はこういうことをやりたかったんだろうなとか。
でもたぶんその時点の技術の制約とか予算の上限とか、いろんな事情でこの方法しかもしかしたら取れなかったのかもしれないなとかですね。
今ならもっとシンプルに少ない実装でこういうことはできるけど、当時はできなかったのかなとかですね。
過去の制作会社さんや担当者さんが試行錯誤した後っていうのがですね、なんとなく見えることも多いんですよね。
ですのでリニューアルの時に古いから変えましょうっていうのではなくて、
なんで今こうなってるかっていうこの背景を知ってから次の試作を考えることができるというメリットもありますね。
その理解が今回リニューアルするにあたって何を変えるかというところの理解につながったのかなというふうに思います。
例えば今回でいうとプラグインがかなり多く入っていたので、必要な最低限のものに整理したりとかですね。
あとはWordPressがまだクラシックエディターだった頃のやり方で実装されているところが多かったので、
そこを今のブロックエディター中心で更新できるように変えるようにしたりとか。
あと運用する人たちは割りかし若い人が多いので、そんなに抵抗なく使っていただけるかなとは思いつつ、
ただ皆さんお忙しいのでできるだけわかりやすく迷わず更新できる方がいいだろうなというような判断ができました。
さらにクライアントさん側でも今回のリニューアルは何を目的にしていて、一方で何はやらないのかというのをしっかりハンドリングしてくれていたので、
この両方が揃っていたのはプロジェクトとしてすごく良かったところだなというふうに思いました。
今回の案件は事業が複数にわたりまして、複数担当者さんで運用されている状態で、複数のサイトを一つに統合するというちょっと難しい案件だったので、
その前に1年とか長く関わっていた意味が特に大きかったんですけれども、何も全てのリニューアル案件でそこまでやらないといけないかというと別にそういうことはなくて、
一人でやられているスモールビジネスの方とか事業のサイトであれば、そんなに長い期間はいらないとは思うんですけど、
それでも可能なら現行サイトの運用を少し面倒を見る期間というのが実際のリニューアルの前に少しあるとベストなのかなというのは感じました。
やっぱりヒアリングだけで聞くのと実際にサイトが使われている様子を見るのと得られる情報量が全然違いますので、
もし可能であればいきなりリニューアル作り始めましょうではなくて、作り始める前に少し期間をとって一回ちょっと補修を引き受けする期間があったりなんかするとリニューアルスムーズにキックオフしやすいのかなというのを思いました。
09:10
もちろんですねいろんな制約がありますし代理店さんとかが経由している案件だとスケジュールがきっちりしているのでそういうことできないことも多いことは承知しているんですけれども、
もしですねその受託側としてそういうことをハンドリングできる立場にあるのであれば少しちょっと期間リニューアルの前の期間を見せていただくというのを提案するのはありなのかなというふうに思いました。
この配信聞いてくださっている方は受託側の方が多いかなと思うんですけど、仮に発注側の立場の方いらっしゃればいきなりリニューアルする前に一旦補修を頼んでみるというのはですね、
リニューアルを視野に入れた場合に少し時間はかかるんですけども長期で見ると結構メリット大きいかなと思うので、
もし様々な事情を許すのであればその方向はお勧めかなと思います。
発注先の制作会社さんとか制作者さんとの相性もそれで見ることができますし、ちょっと頭に置いていただけると良いのかなと思いました。
なかなかねちょっとそこを全てのケースでそれができるわけではないことも承知はしているんですけど、
過去の経験上やっぱり補修から入ったサイトのリニューアルは結果うまくいってる確率がかなり高いなというのが私の個人の肌感ですけどありますので、
参考にできるところがあればしていただけると嬉しいなと思います。
今日のまとめとしましてはですね、サイトのリニューアルというとどうしても新しいサイトをどう作るかというところから考えがちですし、
自宅で製作をしているとそうせざるを得ないケースの方が圧倒的に多いんですけど、
今のサイト、リニューアル前のサイトを一緒に見て、事業とか運用のあれこれを知る時間を先に持てた案件ほどその後のリニューアルを進みやすいというのも経験上感じておりますので、
今回のリニューアルプロジェクトの打ち上げでですね、いいチームだなと思ったんですけど、
その関係もリニューアルが始まった瞬間にできたものではなくて、それ以前の保守フェーズとかから積み重ねで始まっていたのかなというのも思いますので、
もし諸々事情が許せばそういった選択が取れるといいのかなと思いました。
さてこれをお聞きくださっているリスナーの方はですね、
実際プロジェクト後クライアントさんとの関係がお仕事以外で長く続いているとか、
メインのプロジェクト以外の派生したお仕事とかでおつやいが続いているとか、そういったケースってありますでしょうか?
多分そういったケースがあるっていうのは、とてもクライアントさんとかといい関係ができているという証拠なのかなと思うので、
もしこういうのあるよとか、よくクライアントさんにのみ連れて行かれるんだよねとかですね、
そういうのありましたら差し支えない範囲で、
今日も最後までお聞きくださりありがとうございます。
おたよりや感想は概要欄のおたよりフォームか、Xでちょいさきトークのハッシュタグでポストをお願いします。
12:01
ちょいさきはひらがな、トークはカタカナです。
それでは次回は金曜日にお会いしましょう。今週も頑張っていきましょう。
12:15

コメント

スクロール