令和ですね。こんにちは。バックエンドエンジニアのまさくにです。ゴールデンウィークで休んでいたら、シュワシュワと筋組織が融解し、「自然に帰ろう……自然に帰ろう……」と遺伝子に刻み込まれた内なる声が僕を光射す方へ誘いました。もはや社会復帰は難しいかもしれない。
さて。さてさて。
皆さま、いかがお過ごしですか。新しい期に入り、心機一転したい気持ちでしょうか。何ならアレですか。お持ちのWebサイトをリニューアルしたい、そんな気持ちをそろそろお持ちでしょうか。
失礼ながら、そのお気持ち、
たぶん5ヶ月、遅いです！
仕事としてWebサイトの制作に携わってから、5年くらいが過ぎました。現在はバックエンドの作業を行いながら、TD（テクニカルディレクション）やPM（プロジェクトマネージャー）として、プロジェクトに関わることも増えてきています。その観点から言って、お客様と我々の間には「Web制作」の考え方において、（当然のことなんですが）埋めがたいギャップが生じてしまっています。
当たり前なんですけどね。僕らはプロとして年間いくつもWebサイトやWebサービスを制作しています。ギャップがあって当たり前ですし、そのギャップを乗り越え、素晴らしい制作物を作るのが僕らの当然の務めであり、そうありたいと思っています。
ただ超えがたいのがお金と時間の厚い壁です。ご希望をもう一段下げることができれば200万円かわるのに、あと3ヶ月ご依頼が早ければ期日までに間に合うのに、そういったプロジェクトはどうしても散見されます。もちろん、ものすっごい善処するんですけど。僕らものすっごい頑張るんです。でも無理をすると必ずどこかにしわ寄せが来てしまうものです。
できればもっとお客様にも安心していただきながら、僕らもいいものを作りまくりたい。そこでWeb制作のフローを振り返りながら、「Web制作のここに金と時間がかかっちゃいます！」というところを、少し言いにくい部分ではありますが、明らかにしていきますね。
ところでWeb制作ってどうやって進めるの？
弊社では下記のようにWebサイトの制作を進めます。基本的にウォーターフォールと呼ばれる開発手法で、成果物を順々に出しながら完成を目指します。どんな作業、お客様との関わりが生まれるのか、上から順に説明させてください。
- 提案
- 要件定義
- デザイン制作
- マークアップ
- フロントエンド開発
- バックエンド開発
- テスト・検収
- リリース
提案
主に、お問い合わせいただいたお客様に対して「LIGはどのような課題解決ができるか」ということを提案させていただきます。抱えている課題を先にご共有いただくこともありますし、それも含めて提案することもあります。
課題の種類はさまざまで、サイトのデザインかもしれませんし、PVかもしれませんし、回遊率、コンバージョン、コンテンツ設計やコンテンツの編集、運用上のコスト、社内システムとの連携だったりするかもしれません。そういったWebサイト内外にある課題をあぶりだし、解決策を提案いたします。
このシーンで活躍するのは、基本的にプランナー、ディレクターです。ただこの時点でビジュアル的な強さが求められれば、デザイナーがアサインされることもあります。これ以降の話は、弊社の最も強い武器であるWebサイトで解決を求められた場合、もしくはWebサイト自体の課題解決を求められた場合、という前提で進めます。
要件定義
無事弊社からの提案が受け入れられ、ご発注をいただいたのち、本格的に「達成するもの」のすり合わせを行います。ここでの「達成するもの」は基本的に課題に対する解決策であり、どのようなWebサイトを作るかというお話になります。
ご提案時には考えられていなかった細かなところまで検討していくと、決めること、想定しておくことはさまざま存在し、また相対するお客様もWeb担当者から会長レベルまで多種多様。「達成するもの」は何で、いつまでにやるのかというお約束を、（弊社では）主にディレクターが中心となってお客様と結びます。
また、この工程の終わりに基本的なワイヤーフレームができあがります。ワイヤーフレームとは、Webページに何の要素をどの順番で配置するか、というのを視覚的に表したもので、デザインの前段となるものです。これはデザインの土台になるもので、デザインではないのですが、初見のお客様から見ると、載っている情報が少ない質素なデザインに見えるでしょうね。
デザイン制作
ディレクターがまとめた要件定義に沿って、ベストなデザインをデザイナーが作成します。特にお客様が最終的に目にする完成品（の見た目）なので、お客様と認識に齟齬がでないように注意を払います。特にトップページなどは、デザイナーが直接お客様のもとに赴き、考えと思いを伝えることが多いです。
先んじてお渡ししているワイヤーフレームをもとに、想像を超えるインパクトを与えられるよう、デザイナーが命をそそいでいます。デザイン初披露時は歴戦のデザイナーでも毎回緊張すると聞いています。
マークアップ
WebページのほとんどはHTMLというフォーマットで記述されています。この工程で初めてWebのページを作り始めます。文章でビジュアルを再現するため、HTMLはとても書く量が多く、デザイナーが作成したデザイン通りにページを作るのは困難を極めます。
「ピクセルパーフェクト」という言葉がありますが、デザイナーがフォトショップやXD、Sketchなどのアプリケーションで作成した「画像」を1ピクセルもずれなく、HTMLでモニタ上に再現するのは非常に根気のいる作業です。
世の中にはマークアップを専門に行うマークアップエンジニアという存在もいるらしいのですが、弊社ではこの部分をフロントエンドエンジニアが担っています。
フロントエンド開発
マークアップの工程でできあがったWebページは動きがなく、あくまでデザインを再現したものになります。次の工程では、アニメーションやUI部分の微調整などを作り込んでいきます。基本的にはJavaScriptを使用することが多いです。
たとえば、クリックしたときにボタンはどのような挙動をするのか、トップページのアニメーションはどのように動くのか、Webページをロードするとき画像はいつ読み込まれるのか、など……Webの持ち味を活かせるよう、細部にこだわって開発と検証を繰り返します。
弊社ではマークアップもフロントエンド開発もフロントエンドエンジニアが実装するため、同時に完了することになります。この工程が完了すれば、Webページの見える部分の作業は終了です。
バックエンド開発
前工程まででWebページが完成しているのですが、課題によってはCMSを導入する必要があります。CMSというのはWordPressのような「自分でコンテンツを管理できるシステム」のことですね。平たく言うとブログです。弊社ではだいたいWordPressでWebページを表示させています。フロントエンドエンジニアが作り上げたページをWordPressの仕組みで表示ができるように、組み込みを行っていきます。
それが作り終わると、サーバーにWebページを載せなければなりません。あらかじめ提案しておいたサーバーを作り、Webページを外部から見られるように設置します。
「Webサーバーを作り」と言ってもいろいろな手法があって一口に言えないのですが、触れたことがない人には、まったく想像もできないことと思います。強いてたとえるならば、そうですね……。
Facebookの設定を確認されたことはありますでしょうか。複雑で何を設定するための設定なのか分からなくなりますよね。少なく見積もって、このFacebookの30倍くらいの何言ってるか分からない設定項目を満たして、Webサーバーはできあがります。
なので、ここはお客様にはもっとも理解されにくい、もっとも遠い部分だと言えます。それでいいんです。だからこそのご依頼なのですから。ですが、WebページはWebサーバーに載っています。寡黙に安定稼働させるため、ここでも力は抜きません。
テスト・検収
ここでやっとページが確認できるようになるのですが、できたてのWebサイトなんてクリスタルスカルの魔宮くらいガタガタします。要するに動きません。いや語弊がある。動くようには当然作ってありますが、バグが絶対にあるのです。
そのため、ここでテスト項目を出し、テストを行い、修正し、完成品を作り上げます。ここではすべてのメンバーが、自分の領域で障害やスタイル崩れが起きていないかチェックをし、修正を行います。
また、お客様にも提出し、お約束どおりのものができているか確認をお願いします。ただ、お客様はWebのプロではないことがほとんどですので、弊社のテスト報告書などを提出し検収とさせていただくこともありますし、レクチャー会を開いたり、マニュアルを作成することもあります。
さらに、リリース時にコンテンツがなければならない場合、このテストのあとに入稿作業をおこなう必要があり、お客様側も慌ただしくなっていきます。
※Webサイトのテストについては、別に書きましたのでそちらもご覧ください。 Webサイト制作におけるテスト工程の難しさを考えます
まさくに
リリース
やっと公開できるWebサイトができ上がりました！
長い道のりでした。やっとリリースの時が来ます。だいたいここまでで三ヶ月以上はかかっているはずです。リリースはドメインの切り替えなどの作業が発生するため、バックエンドが担うことが多い作業です。デザイナーがデザイン提案で緊張するのと同様、バックエンドは最後のエンターキーを押す瞬間、たまらなく緊張しますし、高揚します。
うまくいけば長い道のりの一区切りとして打ち上げが開かれますが、もともとWebサイトは課題解決のためのもの。本当のスタートはここからなのです。目的を果たせるようにお客様によってWebサイトの運用が始まったり、さらに改善していくために弊社と運用保守契約を結んでいただいたりします。
Web制作はここにコストがかかります
ここまでで、Webサイトがどのように制作されているのかをご理解いただけたのではないでしょうか。ただし、上記のようにすべてがうまくいくプロジェクトなんてごくまれなことです。実際は数々の問題と直面・解決しながら、プロジェクトは進められます。
ここからが本稿の趣旨。
Webサイトを作るときに、思いのほかお金とコストがかかってしまうところと、そのリスクをお話します。逆に言えば、今からあげるポイントに注意すればコスパを上げることができるかもしれません。また、「僕らはこういうことまで注意しながらサイトを制作しているよ」ということも伝わるのではないでしょうか。
スケジュールにまったく余裕がない
冒頭で述べたとおり、お客様の大半はWebのプロではないため、Webサイトを一つ制作するのにどれくらいの日程が必要か、ということをご存知ではありません。
残念なお話なのですが、お客様としてはスケジュールに余裕をもってご依頼していただいたつもりでも、実際の見積もりを作成すると三倍の工期がかかってしまう、ということが少なくありません。
僕らとしても知恵を絞り、非常に切り詰めての工期なのですが、どうしてもリソースの関係や技術的難易度からそうなってしまうことが多く、とても無力感を感じます。
また無理をすればするほど各所のひずみが大きくなり、ページ数やクオリティを下げざるを得なくなったり、チェック期間が減り、ユーザーに与えるインパクトも薄いものになってしまったり、リリース後に本来必要なかった改修が必要になり、もとの予算を超えてしまったり……、という状況にもなりえます。
個人的な感覚の話ですが、弊社ですと15ページ程度の一般的なコーポレートサイトを一つ構築するのに、お問い合わせいただいてから、工期が三ヶ月を切ることはまずありません。Webサイトリニューアルのお問い合わせは、半年以上前にはいただけた方が、コスパのよりよいものが制作できるように思います。
お客様側に専門のWeb担当者がいない
Webサイトの成否を分けるのがお客様側のWeb担当者、というのはあながち過言ではありません。Webサイトを一つ作ろうとすると、お客様側の窓口の方は、弊社が提供する情報、問い合わせ、チェック項目、契約などの膨大な業務にさらされ、さらに社内の政治的な調整にも奔走していただくことになります。
これまでの経験から言うと、お客様側に専門のWeb担当がアサインされるケースはとても少なく、「普段の業務にプラスしてWebサイトを作ってくれ」と上長から指示されている方がほとんどでした。そしてその皆さんが疲弊されます。
僕らも当然サポートに尽力し、プロジェクト完了時には戦友のような関係になっていることも少なくないのですが、それでも円滑なコミュニケーションが確立できない場合、プロジェクトの成功率を下げてしまいます。
かなり難しいことではあると思っているのですが、少なくともリリースまでは、ITリテラシーが高い、専門のWebご担当をアサインしていただけると、プロジェクトの成功率は格段に上がります。これもひいてはコストを下げ、費用対効果を上げることにつながります。
お客様のWeb担当者が意思決定者ではない
こちらもお客様側のWeb担当者の課題なのですが、往々にしてWeb担当者の方にWebサイトの決定権限が与えられていません。この場合、担当者の方は社内調整に走り、確実に忙殺され、悪循環に陥ります。
また、各工程の社内調整でコミュニケーションロスが起き、その結果、成果物が巻き戻される可能性が著しく高くなります。これもプロジェクトの成否に関わる重要な要素になります。
Webサイト制作に関わることでないと思うのですが、ご担当には一定の決裁権と社内調整能力が必要になると思っています。これは僕らがかけるコストもそうですが、お客様が社内で必要になるコストもリードタイムで考えると相対的に下げることになるでしょう。
プロジェクト発足の目的があやふやで熱量がない
冗談みたいなお話ですが、「春だから……」というような理由で時折、お問い合わせをいただくことがあります。いや僕らとしてはいいんですが。全然嬉しいのですけれども。この場合、「強い課題はないけどリニューアルをしよう」と考えた方の部下がWebのご担当となることが多く、ご担当の意気込みや熱意は薄れているのが常で、窓口としてのご負担に耐えられない可能性すら出てきてしまいます。
また目的意識の希薄化から「何を課題とし、解決策とするのか」というものが確定できなくなってしまいます。僕らも精一杯ご提案をおこなうのですが、本当の課題解決のためには圧倒的なヒアリングが必要になり、全般お任せされてしまうと、課題の本質に近づけません。
そうするとたとえ制作が完了したとしても、何の意味もなさないサイトが出来上がることがあります。これ以上コスパが悪いことが他にあるでしょうか。
僕らはプロとして、意味のないと考えることには「意味がない」と伝えますし、効果が薄いと考えることには「効果が薄いでしょう」と伝えるようにしています。僕らが作り手として最も怖いのは、鋭意をもって作り終わったものが、意味のないもので、誰にも使われず、誰も幸せにできないことなのです。
僕が自分の立場をいったん置いて、本当にお客様のためを思ったとき、目的がないサイトなら作らないことが最もコスパがよい、ということを言わなければなりません。
「誰のために作るか」のコンセプトがブレる
デザインのコンセプト定義段階でサイトの方向性を決め、コンセプトの共通認識を持ちます。以後、あらゆる決定はそのコンセプトに沿って成か否かを考えることになります。
しかしみんな同じ人間なので、成果物が重なるうち、具体的なでき上がりの予想図が頭の中にできてくるせいか、弊社で考えているコンセプトに沿わないフィードバックが増えてきます。
一例はページ中の要素の色でしょうか。デザイナーはコンセプトに沿い、意図をもってその場所にその色を配しています。このため、実はひとつの色を変えるだけで他の色も引っ張られて変更せざるをえなかったり、要素の配置も変更しなければならなくなる可能性がでてきます。
当然、「そのフィードバックはコンセプトに沿わない」ということをお伝えするのですが、こうなると一番分かりやすくするために「複数パターンを用意して検討しましょう」というような成り行きになることが多く、コストが増大することになります。そして、なぜか「初期のデザインの方がいい」、ということになることが多いのです。
コスト感を保つためにも、コンセプトは一定にしなければならず、お客様にとっても、弊社にとっても初手は慎重に決めなければなりません。
一度FIXした工程が巻き戻される
これはあらゆる仕事で忌避されることだとは思うのですが、ウォーターフォール開発においてはプロジェクト失敗の致命的要因になりえます。特に弊社では分業化が進んでおりますので、フロントエンドは基本デザインを行いませんし、バックエンドは基本フロントエンドを行いません（できる者は多いですが）。
このため、すでにフロントエンド開発段階にある状態でデザインが巻き戻しになったりすると、影響範囲によりますが、プロジェクトは致命的な打撃を受けることになります。
当然そこにはコストが発生してしまい、プロジェクトがいびつなものになってしまいます。それを避けるために、特にデザインはFIXをいただくように気を払っています。この状況に陥りやすいのが、先方のWeb担当、もしくはその上長が変わられたとき、またはプロジェクト当初には参加されていなかった方が参加する場合です。
Web担当の方は、社内に情報を伝達する場合や、承認を得なければならない場合、引き継ぎをする場合、必ずプロジェクトの背景から経緯を含めてお話していただくと、巻き戻しが起こりにくく、スムーズになると思います。単に「LIGがこんなものを上げてきたので見といてください」というレベルで共有してしまうと、これまでの話が否定され、工程が巻き戻ってしまうことが多くあります。
古いブラウザ、不要なデバイスの表示が指定される
先日、Microsoftが「IEは技術的負債をもたらすので使わないで欲しい」という記事を公開して非常に話題になりました。Microsoftが自社製品にNGを突きつけたのです。
開発者たちは歓喜していました。なぜかと言えば、古いブラウザには現在の技術で非推奨となったもの、セキュリティ的に危ういもの、そもそも現在のブラウザと互換がないもの、再現ができないものが数多くあるからです。
弊社でも、お見積もりのときにベストビューのブラウザ（弊社で検証可能で、もっとも見栄えがよくなるブラウザ）を定義しており、原則としてその当時の最新版のブラウザが指定しています。現代ではブラウザも自動的にバージョンアップされていくので、そのように指定させていただいているのですが、時折、古いブラウザでも対応して欲しいと指定いただくシーンがあります。
たとえばリニューアルの場合、Analyticsなどを確認し、その古いブラウザを使用しているユーザーが無視できないほど存在する、もしくはこのリニューアルにおいて見込みユーザーがそれを凌駕することはないだろう、と確実に判断できた場合は、古いブラウザだろうと対応するべきだと考えます。
……しかし、そのようなことはほぼありません。おそらくブラウザのバージョンアップを禁じられた、閉じたコミュニティの内部システムくらいではないでしょうか。この指定があるのは、だいたい「お客様の環境だけが古いから」、もっと運が悪いのが「社長のブラウザがそれだから」となります。
不要なデバイス対応にも同じようなことが言えます。最近二つ折りのスマホが発売されましたが、今後、どのようなデバイスが流行っていくのでしょうか。
いずれにせよ、多数のブラウザ、デバイスに対応するためにフロントエンドは実装とテストに心を砕いており、それだけコストが必要になります。
しかし、無視できるユーザーは無視しましょう、という考えが正しいと僕は思っていません。妥当な数値、妥当なコストを鑑みて、バランスを一度検討すべきだ、と考えています。
これまでのサイトのデータを移行する
これもサイトリニューアルの案件で、「旧サイトのデータもそっくり新しいサイトに持っていきたい」という要望をいただくことが多いです。コンテンツ量はSEOにも関係しますし、その要望はごもっとも。当然、僕らもその前提で考えています。
ところで移行をどうするかというと、たとえば旧サイトもWordPressの場合はそれなりに話が早いです。どのような記事があるか調査をし、データと画像関係をいただいて、データを修正し、必要があれば記事内のURLを変更し、同じようなスタイルが適用されるようデザインを用意し、マークアップも用意し、データを入れ込むことになります（そこでだいたい画像が荒すぎたり、小さすぎたりするのですけれど）。
さらにこれが別のCMS、もしくはCMSではなかったりする場合も検討しなければなりません。この場合はデータの変換、スクレイピング（専用のスクリプトを書いてで旧サイトの文字を取得すること）なども視野に入れます。最悪、弊社かお客様が手動で入力することも考えます。
重ね重ね申し上げますが、このコンテンツの重要性は重々承知しており、できることなら移行したいと思っています。ですが、コンセプトによっては移す必要がないデータが存在し、サイトをチープに見せてしまうかもしれません。コストを下げる部分としてぜひご検討ください。
これまでのサイトと同じ古いサーバーを使う
リニューアル案件の場合、すでに既存のWebサイトが稼働しているサーバーが存在します。おそらく、金銭的にも開発的にもコストを下げられる方法だろうということで、「これまでのサイトと同じサーバーを使って欲しい」とご要望をいただくことが多いのですが、お客様、そのお考えは間違っています。この場合、開発をおこなう上でも、技術的に明確なリスクが2つあります。
これはお問い合わせをいただくお客様のサーバーを鑑みた事実なのですが、多くのお客様は既存のWebサーバーのメンテナンスを行っていないのではないでしょうか。このためこれまでと同じサーバーを使おうとすると大きなリスクを抱えます。そのひとつはサーバーのOS、ミドルウェアのバージョンが古いだろう、ということです。とても古いのだろう、ということです。
プログラムは常にバージョンアップを重ねて、進化していきます。その進化の過程で使われなくなった機能や、持っているとセキュリティリスクとなる機能、新しいバージョンでしか使えない機能、パフォーマンスを劇的に改善する機能などが盛り込まれます。
その成果物がOSであり、Webサーバーであり、WordPressであったりするのですが、古いサーバーですと、時間をかけて作り上げたそれらの発明一切を放棄することになります。というか、おおむね動かないんです。古いバージョンで、最新の開発を行おうとしますと。
もうひとつのリスクは開発中も現行サーバーと同居することになるので、開発時やリリース時にダウンタイムが多く発生する可能性があるということです。Webサーバーは24時間365日動いて当たり前。サーバーレスという考え方も広がってきていますが、レスポンスを返して当たり前という世界です。その中でダウンするというのは、やはり経営や営業のリスクと考えます。
リスクがあるということは、予期できないコストが増大するということです。自分の身内が自分の知らぬところで、一千万の借金を抱えているということです。というか、セキュリティリスクがわかっているものを、僕らは勧めることができません。
サーバーにハイスペックを求める
僕らがサーバーを構築するとき、ご要望をうかがい、これまでのPVを鑑み、これからのPVを想定し、ご予算を検討し、その中で現実的なものを構築するようにしています。こちらは上の項目とは違い、逆に将来のPV数増加をご心配し、サーバーにハイスペックを求められる場合です。
基本的にサーバーを作るときは、ピークは予想しつつも「最初はミニマルで」という思考で考えます。拡張性だけは残しておき、今後のリクエスト数や機能によって拡張することが、クラウドで可能になった時代です。PVの少ないリリース段階で、PV数の心配から万全の構成を構築することが正しいとは限りません。
すべてはバランスなので、一概には言えませんが、コストという観点からすると、月10万のランニングコストは、通年で考えると制作費の10%以上にはあたるはずです。Web制作完了はスタート地点です。その地点でピークの構成を持ってくることが必要かは一考の余地があります。
運用担当者が決まっていない
何度もお伝えしますが、Web制作完了は特にお客様にとってはスタート地点であり、CMSを設置するということは、運用が発生するということです。しかしWebサイトを作ったあと、運用を誰がするかということまで最初から考えられていないことが、ままあります。
制作にも時間と工数がかかりますが、運用にも想像以上に忍耐と努力が必要になります。特にメディアはそのようです。個人のブログならまだしも、企業のオウンドメディアとしてサイトを構築した場合、覚悟をもって臨まなければならず、その運用を担う人員が必要不可欠になります。
そのアサインについても、予期していなかったコストになるかもしれません。しかしここも手厚くサポートしなければ、せっかく制作したサイトが死んでしまいます。その結果、最悪のコスパを招くでしょう。そのため初めからWebサイトの運用のコストもどうか加味してください。
オウンドメディアの運用についてはQiitaで過去に記事を書いたことがあります。
だけど理想のプロジェクトなんてないから
これまでの経験上、もっと上手くできるのに、と思っていたものを少し熱っぽく語らせていただきました。ここで勘違いされないようにお伝えしたいのが、僕らはお客様に文句をつけたいわけでも、何も提案しないわけでも、すべて自分達が思うように進めたいわけでも、ましてや法外なご請求をしたいわけでは絶対にありません。
今回、本当にお伝えしたいのは、適切なものを真摯にご提供し、お客様がかけたコスト以上の成果を上げるために、僕らがどういうところにコストをかけざるをえないのか、という点です。
逆に言えば、コストとは僕らが気をつけなければならないところになります。その部分をお客様にご検討いただき、最適化することによって、もっと低コストで、もっと効果的で、関わる人員が幸せになれる……。そういったWeb制作、仕事を僕らは提供することができるでしょう。
繰り返しますが、僕ら、すっごい、頑張るんです。お客様の熱意ある難題、お待ちしております。
それから仲間ー！ こんな僕らと働いてみたいという、真摯な情熱を持つ仲間を探しています！ 募集要項は下記からご覧ください。
それでは！ まさくにでした。
LIGはWebサイト制作を支援しています。ご興味のある方は事業ぺージをぜひご覧ください。
