皆さんごきげんよう。

フロントエンドエンジニアの西川です。

今回は弊社トゥモローゲートのWeb制作フローについてお話ししていきたいと思います。

弊社は2022年の4月に制作フローをリニューアルしました。走り出したばかりなのでまだまだ発展途上ですが何年か前に比べれば数段よくなってます。クオリティとスピードを上げるための連携方法がすこしずつ確立されてきました。逆に言うとそれまでの弊社の制作フローは至らない部分がそこそこありました。

コーディング開始後にデザインの変更。WordPress実装後に仕様の変更。ダミーテキストの文字量をはるかに超えた本番用のテキストデータ。一向に来ないサーバ情報。すでに「あるある」とうなずいているコーダー、エンジニアの方もいらっしゃるのではないでしょうか。

そんな現状を打ち破るためにリニューアルしたWeb制作フロー。

今回のブログではリニューアルするきっかけとなった制作フローの出来事を書いていきたいと思います。これを読んで「うちの会社と同じだ」と思ったら、それは制作フローを見直すべきタイミングかもしれませんよ！

ダミー地獄

トゥモローゲートではウォーターフォール型の制作フローを採用しています。ウォーターフォール型とは上流工程から下流工程へ水が流れるような進め方をするWeb制作フローのこと。各工程で作業が完了してから次の工程に取り掛かるのが基本です。

ですが、数年前までトゥモローゲートでは前の工程が終わっていない、つまり、Web制作に必要な情報が揃ってないのにコーディングを進めなければいけないケースが多々ありました。中には情報がほとんどなく、ほぼ全てがダミー要素の状態で進めなければいけない…なんてことも。

そして、そんな状況でコーディングをした時によくあるフィードバックがこれ。

「デザインのイメージ、なんか変わってない？」

ダミーしか入っていないのにイメージなんてできませんよね？
どんな出来上がりにすればいいのかの想像なんてできませんよね？

一度このようなフィードバックを受けて修正対応する流れになってしまうと、その後の工程がぐちゃぐちゃに乱れます。追加でイレギュラーなことが起こったら大変です。綱渡りしながら歩いている感じです。

画像にしてもテキストデータにしても。完成してから次の工程に行くべき。その方が効率的で質の高いデザインに仕上がるはず。そんな当たり前を徹底できていなかったことが、Web制作フローを見直す1つのきっかけとなりました。

忘れた頃に回ってくるボール

Web制作にはその全てに意図が存在しています。レイアウトにしても配色にしても全てに意図があります。その意図にはクライアントの想い、考え、強みなどが込められているためクライアントのことをより深く知る必要があり、また深く知れば知るほどクライアントに愛着が湧いてきます。

ただ、完成までに1年近くの時間を費やすWeb制作では、すべての職種がすべての工程に関わっているわけではもちろんありません。そうすると、プロジェクト開始当時は愛着があったのに関わらない期間が続いてしまうと、どうしても人間なので愛着は薄れてしまうことがあります。

トゥモローゲートではデザイナーもエンジニアも関係なく企画会議やクライアントヒアリングに参加するため、僕のような下流工程を担当する人間でもクライアントに近い距離で仕事をスタートさせることができます。

でも、ひとたびスタートしたら僕にボールが回ってくるのは半年以上後なんてこともある。これだとなかなかコーディングに身が入らないということで、コーディングを担当する人間もそのもっと前の工程から携わるのはどうかという話になりました。

赤ちゃんの成長過程をほとんど見ていないまま大人になって再会しても「ああっ。。」ってなるだけですよね。それと一緒です。クライアントに愛着を持って、熱量を持ってコーディングするために、テキストやデザインの確認などにも積極的に入っていこう！という方針でフローの見直しが進んでいきました。

すべりこみサーバ確認

公開環境とはいわばお弁当箱のようなものです。いくらおいしいご飯をつくろうとも、お弁当がないとどこにも持っていけません。いくら綺麗なサイトを作っても、サーバがないと公開できません。誰にも知られないまま終わってしまいます。

トゥモローゲートではこのサーバの確認が疎かになってしまうケースがポツポツありました。だからこそWeb制作フローを見直す際にサーバ確認のタイミングを明確にすることにしよう！という話になったんです。

便利なWordPressであってもPHPのバージョンが古いと最新のWordPressのバージョンに対応していないことがあります。そうなるとセキュリティ的に問題アリです。どうしても対応できるPHPが無い場合はいちいちダウングレードの対応をしたり、PHPのバージョンがアップできるか調べたりすることになります。

そんなことを公開直前にはやるわけにはいきません。公開直前はただでさえバタバタするのにそこに「無事に公開できるのか？」という疑問まで追加されたら不安で夜も眠れません（大袈裟）

仕様はどこに

WordPressを使った実装は比較的簡単です。ですがそれは仕様がしっかりと固まっている場合に限ります。

「いい感じに作って」という指示を受けてデザインが並んでいる通りに実装したとします。でもそこには大きな罠が。例えば実際は必要のない仕様がまぎれこんでしまったりと、仕様が固まっていない場合は余計な仕様がどんどんプラスされていくのです。

「イチから作った方が速かった」なんてこともありました。デザインがシンプルではない案件の時は管理画面が複雑で更新作業を覚えるのに一苦労…なんてこともありました。

WordPressの仕様を固めるためには

誰が更新するのか。
更新者のリテラシーはどの程度なのか。
月にどれくらい更新するのか。
何を更新するのか。
複数人で投稿する場合どうやってアカウントを管理するのか。

など考えることが山のようにあります。いついかなるプロジェクトでもWordPressの仕様を固めないといけない。そう思ったのもWeb制作フローを見直すひとつのきっかけでした。

下流工程を忘れないで

Webで制作するものには必ず納期が設定されています。上流工程が遅れたら交渉をして納期を後ろにズラしたり、1次公開、2次公開と公開を複数のフェーズを分けることも会社によってあると思います。

弊社トゥモローゲート、そんなことが行われない案件がありました。撮影が遅れてもデザインが遅れても納期が変わらないことが多々ありました。結果、普段は定時上がりの僕が猛ダッシュで終電に駆け込むなんてこともありました。

やっぱり定時で帰りたいですよね？
家族みんなでご飯を食べたいですよね？

下流工程になればなるほど、融通が利かなくなります。なぜなら納期に近いタイミングでの作業になるから。だからこそ上流工程がズレたら下流工程をズラすことも徹底する必要があると思い、制作フローを見直すことに決めたんです。

次回からどう改善したのかを書いていきます

鬼畜（言い過ぎ？）だったトゥモローゲートのWeb制作フロー体験談をお届けしました。これらが今では完全に改善された…というワケではありませんが、当時と比べればかなり良くなってきています。

そしてそれをさらに良くするために新しい制作フローを2022年の4月から導入しました。具体的にどんな制作フローなのか、どう改善しているのかを次回以降のブログで書いていきたいと思います。