はじめに
筆者は、多様な事業展開を行うグループ企業傘下の小さなクリエイティブ制作会社に属しています。
所属企業で最近、紙媒体クリエイター（雑誌編集者・ライター）によるWordPressを軸としたwebサイト制作事業が始まることになりました。
現状、主な顧客はグループ関連企業なのでグループ向けのweb内製事業といったところです。
彼らは主にAdobe InDesignをメインに使うエディトリアルデザイナーで、webに関する知見はほぼありません。
本記事は、そういった社内の非エンジニア向けに書いたwebサイト制作に関する網羅的な資料となります。
と言うのも、自分がいま知識ゼロになったと想定した時「ある程度全体像が見えていたほうが自分の立ち位置や進む方向性などが見つけやすいなぁ」と感じたため網羅的な内容にしました。
そして書いていくうちに、web初学者の方にも役立つ部分が少しはあるかもと思って今回記事にしました。
資料（記事）に関しては、筆者の経験則が色濃く反映されたところもあり、再現性がなく、適切でない部分もあるかもしれません。
悪しからずご了承ください。
また、筆者の知識不足から誤った点や改善点などもあるかと思います。
そういったご指摘やアドバイスなどもいただけますとありがたく存じます。
そして、それら貴重なご意見・内容を社内向け資料に反映させていただくことをお許しいただければ嬉しく思います！
対象読者
- web初学者（駆け出しの方や、駆け出し前の情報収集をされている方）
- webに詳しくない非エンジニアの方（事務職、紙媒体をメインとしたクリエイティブ職など）
- webサイトが表示される仕組みや、web制作の流れをザッと知りたい方
以下より資料の内容となります。
一部ぼかしたり、調整したりしている部分はありますが内容に関して大きな変更はありません。
弊グループにおけるWEBサイト制作の留意事項
本レポートは「WEBサイト制作において諸々の概要理解を促進する資料」という位置付けです。
弊グループは特殊で、内製という形を採りながらも各社へクリエイティブの請求を行う「内製+受託開発」みたいなスタイルを採っています。
そのため各グループ企業に対して顧客として接する必要があるのです。
そういった前提条件を踏まえた上での、本レポートの主旨は「現在グループ内で唯一のWEB担当者がいなくなった場合に自分たちで少しは何とかできるように備えておく」となります。
これまで私がグループ各社の役員や事業責任者と折衝してきた経験則も踏まえて書いていきます。
とはいえ、WEB関連の知識はとても広く深いので、あまり踏み込んでいきません。
先述したように「概要理解の促進」を軸にしながら「弊グループに即した内容」という網羅的な資料です。
個人の経験則が色濃く反映されたところもあり、再現性がなく、適切でない部分もあるかもしれません。
参考程度という認識で、必要に応じて各自が情報収集・インプットを行ってください。
またインプットしたものや経験したことはチーム内で積極的に共有（MTやドキュメント作成など）したほうが（属人化も防げて）良いかと思います。
長くなったので上から全部読んでいくというより、必要に応じて項目別に読んでみてください。
目次
WEBサイトが表示される仕組み
深堀りすると大変な量になるので最低限かつ大まかに理解できるように説明します。厳密な部分は省きます。ご了承ください。
まず、皆さんが普段目にする各種WEBサイトやページは以下の流れで表示されています。
1. サイトURL（https://example.com）からドメイン名を把握。ドメイン名とは「インターネット上の住所のようなもの」でexample.comの部分です
2. ドメイン名を「DNS（ドメインネームシステム）」というインターネットの住所録のようなものに問い合わせて「IPアドレス」を把握します。このIPアドレスは数字の羅列であり、これがインターネット上での（当該サイト・ページにおける）住所の真の姿になります。
※コンピューターにとっては数字の方が親和性が高いのでこうなっていますが、人間は数字だと認識づらいので「ドメイン名」という分かりやすい形で扱う仕組みになっているのです
3. 判明したIPアドレスのもとにあるサーバーから希望するページの情報取得を試みます。これがリクエストです
4. そのリクエストに応じてサーバーは情報を返します。これがレスポンスです。例えば、404 Not Foundというのを見たことがあると思います。あれは「リクエストされたページが見つからない」というレスポンスになります
5. リクエストしたページがユーザエージェント（ブラウザ）に返されて、初めてあなたのブラウザ画面に表示されます。
※リクエストしたページに何か支障があれば相応のレスポンス（例：上記404のような）が表示されます
httpsやhttpというものを聞いたことがあるかと思います。これらはスキーム／プロトコルと呼ばれるものです。
httpとは「ハイパー・テキスト・トランスファー・プロトコル」と言って、簡潔に言うと「ユーザエージェント（ブラウザ）とサーバーがデータのやり取りをするための仕組み」となります。
httpsは「ハイパー・テキスト・トランスファー・プロトコル・セキュア」で、httpの安全版というイメージで一旦okです。
「データを暗号化し、通信の盗聴や改ざんを防ぐ」ようにしています。
つまり先に述べたリクエストやレスポンスとは、この仕組みに則って処理されています。
必要となる前提知識
技術関連
- 知識
- 必須：
HTML,CSS - 可能であれば（将来的には必須）：
jQuery（JavaScript） - 場合によって必要：
PHP（WordPress制作で使用）
- 必須：
- ツール（エディタ）
-
VSCode,Adobe Dw, etc...
-
- ツール（汎用）
家づくりを例にします。
HTMLとは「骨組み」です。柱や梁など家の骨格・基盤を担っています。
CSSは「外装・内装」です。塀や外壁、庭、クロスの色、ドアや引き戸、窓の形や色などデザイン面を担っています。
jQuery（JavaScript）は給湯器やエアコン、水回り、ガスや電気など住まいを豊かにする機能面を担っています。
エアコンやガスなどが生活に必須なように昨今のWEBサイト制作ではJavaScriptが必須となっています。
しかしJavaScriptはHTMLやCSSといったコンピュータ言語と違ってプログラミング言語です。
そのため学習コストがかかるので、比較的簡単に扱えるjQueryというライブラリ（*）を推奨します。
*：ライブラリ：本来ある程度の記述量を必要とするコードが2～3行で済むようになるなど、プログラミングを簡単にできるよう難度調整された便利なもの。
CSSにもライブラリやフレームワーク（※ライブラリの発展版のようなもので、web開発を効率的に行うためのツール）と呼ばれるものがあります。
例えば、TailwindCSSやBootstrapなどが代表的です。
これらを使えば手軽かつ無難にスタイリングできるのですが「基礎的な知識や概要理解が足りないと修正やカスタマイズなどで行き詰まる」ことも考えられます。
ライブラリやフレームワークの存在を認知しつつも、先ずはCSSを自分たちで書いてみてください。
その上で「もっと効率的に書きたい」と思ったタイミングで必要に応じてライブラリなどを用いるのがベターかと思います。
エディタは家づくりに必要なツールです。コーディングやプログラミングで使用します。
そもそもWEBサイトはコンピュータにコードを理解してもらうことで表示されます。
つまり、普段皆さんが使い慣れているAdobe InDesignのようにテキストボックスや画像、オブジェクトをドラッグ操作でレイアウトして「はい！完成」というものではありません。
具体的な一例をあげると、margin: 10px 0px 8px 4px;のようにコードを通じて要素のレイアウトなどデザインを整えていきます。
エディタは上記のようなコーディング・プログラミングを行いやすくするためのツールです。
技術関連については生成AIを活用しながら進めても良いかと思います。
内製事業ではWordPressでのサイト制作を軸に検討されていますね。
WordPressは世界的なシェアもあり、情報も豊富です。しかし反面、セキュリティ対策が非常に重要になってきます。主旨から逸れるためセキュリティ云々の話は一旦割愛しますが、これは念頭に置いていてください。
また現状WordPressには2通りの作り方があり、皆さんが行っているのはブロックテーマでの作成です。これはいわゆるノーコード・ローコードと呼ばれるもので、用意された（または用意した）ブロック要素を組み合わせてサイトを作っていくスタイルです。
（これまで説明してきたWEB知識が無くても）ある程度のものは作れる一方、どうしても凝ったデザインや複雑な機能は実装しづらいでしょう。
「その場合は外注で」という考えもあるでしょうが、何も考えずに外注するのは危険です。コミュニケーション齟齬によりコストが余計にかかってしまうリスクも考えられます。
非常に面倒かもですが、今後のためにも「WEB知識をある程度は習得・理解」しましょう。
※ HTMLやCSS,JavaScriptはドットインストールやUdemy、YouTube、書籍などで体系的に学ぶ他、QiitaやZennなど技術記事投稿プラットフォームで情報を集めても良いかと思います。
FTP
FTPは「ファイル・トランスファー・プロトコル」と言って「サーバーにファイルを転送するための仕組み」です。
例えば、自社サイトの更新作業で自分のローカルPCでファイルを編集し、画像も新規追加したいとします。この際にFTPを通じて先述した「IPアドレス（自社サイト）」のサーバーにそれらをアップするのです。
つまり、インターネット上の住所にアクセスするための通路・鍵のようなイメージです。
とりあえずは「サイト更新作業ではFTPを使う」程度の認識でokです。
昨今はGitHubなど「ファイル更新履歴管理ツール」のようなものを使って、（GitHub Actionsによる）CI/CD（継続的インテグレーション／継続的デリバー・デプロイ）を行って自動的に更新する仕組みもあります。
しかし一気に覚えることやすることが増えてしまうので、初めは上記FTPのやり方で慣れていったほうが良いかと思います。
Local
ローカル環境でWordPress開発を行うためのツールです。
※WordPressでのサイト制作を考えていないのであればこの項をスキップしてください。
そもそもWordPressはCMS（コンテンツ・マネジメント・システム）という類のもので、コンテンツ（記事）をデータベース（MySQL）に記録して管理しています。このコンテンツを取得する際にPHPというプログラミング言語が絡んできます（※ちなみにWordPress自体がPHPで作られています）。
先に説明したWEBサイトが表示される仕組みの工程間で、WordPressは「テンプレート階層に則ったURL（アドレス）に準拠したHTMLデータを生成して返す」という処理を行います。
月刊誌のレイアウト表のイメージです。
いくつかの雛形（テンプレート）があって、そこにコンテンツ（記事）を落とし込むことでページとして成り立たせています。
つまり「レイアウトAの雛形にリライト原稿をはめ込むことで当該クライアントページが完成する」というイメージです。
オリジナルデザイン（のテンプレート）を作るのも可能です。
このように、ある程度共通化されたコンテンツではあるもののURLの違いによって表示される内容が変化するものを動的サイトと言います。
逆にHTMLとCSS, JavaScriptで作られたものは（ファイルを修正しない限り）変化しないので静的サイトと言います。
WordPressは動的サイトなのでコンテンツを管理するデータベースが関わってきます。
データベースやそれを扱うための環境を一から自分で設けるのは厳しいのでLocalのような開発ツールを用いるのです。
Localでは数クリックでローカル環境にWordPressサイトを立ち上げられます。
もしLocalを使わない場合はテストサーバーにWordPressをインストールして「ファイルを修正する度にFTPでアップして更新する（*）」という手間が発生します。
時間の有効活用という面でも、まずはLocalのような開発ツールで制作を進めて、本環境に近い状況でデザインや機能チェックする段階になってテストサーバーを活用するのがベターです。
*：ブラウザには「キャッシュ」という機能が備わっています。これは端的に言うと「前回訪問時の内容の一時記録」です。
前に訪れた際に表示されていたテキストや画像などをブラウザは一時的に保持します。これは都度、新規リクエストを送ると負荷がかかるためです。
ブラウザの負荷軽減措置としてキャッシュというものがあると理解してください。
ページを更新して内容が反映されていない場合はキャッシュが絡んでいる場合があります。その場合は再読み込みするかcom/ctrl + shift + Rでスーパーリロードしてください。
それでも更新されない場合は更新ミスの可能性が高いのでサーバーやファイルを確認してみてください。
WordPressのブロックテーマを軸とした開発ではFTPが不要な場合もあります。
とはいえ、自分たちが扱っているサイトの在り処を理解しておくのも、そこへのアクセス方法を知っておくのも大事です。
そのためFTPについてもある程度の説明を行いました。
非技術関連
デザイン
- デザイン関連ツール：
Adobe Ai,Adobe Ps,Figma
Adobe系ソフトの説明は割愛します。
昨今の主流はFigmaです。これは、複数人利用・編集が可能なプロトタイプ制作ツールで、端的に言うと「みんなでwebサイトのデザインや（簡易な）機能を作っていけるよ」というものです。
後述するデザインカンプをAiで作っても良いのですが、その場合ページ遷移などwebサイトの「動き」の部分は表現できません。
しかしFigmaでは実現できるため、先方や関係者との制作サイトのイメージ共有において非常に役立ちます。
Adobe系ソフトのUI（ユーザーインターフェース：操作パネルみたいなもの）と親和性があるので学習コストもそこまで高くないと思います。
（※基本的な部分に関してです。オートレイアウトや制約、コンポーネント、バリアントなど別途学習が必要な部分も当然あります）
コミュニケーション関連
これが最も重要で、（現状）生成AIでも代替できない部分になります。
どれも共通して言えるのは、要望やタスクの背景を捉えて解像度を高めるのが重要ということです。
以下からはディレクション分野に偏った内容となります。
筆者の所属企業のようにエンジニアやデザイナー自身が顧客折衝する企業もあるかもしれませんが多くは分業体制が敷かれているはずです。
ディレクター視点の情報を今は必要としていない方はこの項をスキップしてください。
現状、月刊誌制作において皆さんは顧客折衝面では何かあれば企画部営業に任せることが多いかと思います。
彼らが契約関連を主に管理しているため現状こうなっていますが、今後事業としてweb制作を進めていく上では自分たちで顧客折衝していく必要があります。（顧客と言っても現状では社内の役員や事業責任者に留まりますが）
スムーズな案件進行と最適な成果物納品に努める、という観点から以下事項が大事になってきます。
- ドメイン知識（業界・業種への理解）
- ヒアリング
- 案件コントロール
- 領域横断的な視点と行動（他部署への根回し）
- SEO知識
※私の実体験を通した、弊グループでの優先順位が高い順に列挙しました。もちろん、私の経験不足から列挙できていないだけで他にも重要事項はまだまだあるかと思います。
ドメイン知識（業界・業種への理解）
弊グループは多種多様な幅広い事業を展開しています。
これら多様な業界・業種に関することをある程度理解していないとイメージの共有が難しく、最適な提案が行えません。
例えば、「何を、だれに、どうやって提供して事業成立しているのかというビジネスフロー」や「その過程で関わりのあるサービス（や取引先企業の情報）、制約」、「競合他社の事例や傾向」などを事前に調べておいても良いですし、ヒアリングを通じて伺うのも良いかと思います。
私は大概後者でしたが前者の方がスムーズでしょう。
GA4のデータを見て「優良ページや課題を発見」しておくと、ヒアリングフェーズがより充実するかと思います。
次のヒアリングフェーズに入る前に「（今回作る or リニューアルするサイトの）参考イメージの提出」を求めていても良いかと思います。
ヒアリング
ワイヤーフレームやプロトタイプ制作につながる重要なフェーズです。ここでイメージ共有や方向性がズレてしまうと後工程も漏れなくズレていってしまいます。「上流が汚れていると下流でどれだけ頑張っても綺麗にはできない」という意識のもと臨んでください。
聞くことは概ね以下です。
- 予算や納期
- コンテンツの種類（何ページ規模のサイトにするか）
- コラム記事など投稿機能は必要か（必要な場合は
WordPressなどCMSを利用）- 不要な場合でも、念のため後々必要となった時の制作コストを伝えておきましょう
- 必須機能の有無（問い合わせフォームや検索フォームなど）
- サイトをホスティングするサーバの用意や管理について
- 具体的な要件
- 希望するデザインやイメージ、カラーリング
- 必須機能の有無
- コーポレートカラーやレギュレーションの有無
- ロゴまたは広告フライヤー制作の必要性
- （必要に応じて）サイトマニュアルなどのドキュメント
「具体的な要件」は予算やスケジュールに関わってくる事項なので注意してください。
ちなみに、大抵具体的なイメージは固まってません。これまでの経験上「相談しながら決めていきたい」タイプが多いです。
先方が求めているのは言った通りに作ってもらうよりも「自分の考えや判断、方向性が正しいか」のアドバイスを求めているケースも少なくないです（*）。
*：トップダウンな場合もあります。中には「今言ったこと『Yes or はい』で進めて」という言外の指示が発生していることも多いです。
弊グループでは「できないです」とか「厳しいです」といった返答をはじめ、「しかし～、でも～、それだと～」など否定ニュアンスは（人によっては）地雷です。
厳しそうでも先ずは「検討させてください」や「チャレンジしてみます」と前向きな返答に努めて下さい。
その上で、できないなら何とか頑張るか、せめて代替案を提案するようにしてください。でないと全く案件が進まず時間だけ失っていき、自分が追い詰められます。
私は「技術的にできません」を連発しすぎて「『Google』でできてのる知ってるからできひんわけないやろ！」とお𠮟りを受けた経験があります。
実装や実現が難しい場合の代替案提出はマストです。
気持ちは重々分かりますが否定的な返答・雰囲気を控えて建設的に進めることを念頭に置いてください。
また、このタイミングで参考イメージが無い場合はヒアリングを通じて実際に各種WEBサイトのギャラリーサイトを見ながら参考イメージをすり合わせていっても良いでしょう。もちろん、先方に後日提出を求めても良いかと思います。
多くは事前に参考イメージもらっているか、後日提出のパターンが多いです。どちらにせよ参考イメージは互いにとって重要なので用意する（してもらう）ようにしてください。
あと、ヒアリング時は「理解と共感」を念頭に、安易に否定しないスタンスを意識してください。
これは建設的に進めていくために必要な配慮です。否定するにしても「専門的な知見に裏付けされたアドバイス」という形を採ってください。
ヒアリング時に、先方の好きなブランドやアーティスト、アニメ・漫画などを聞いてデザイン観を窺っておくのも良いかもしれません。これにより、その人のイメージする「かっこいい」や「かわいい」など抽象的なものを少しはイメージしやくするなるかもれません。
案件コントロール
主な要点は以下2つです。
- 適宜、案件全体を俯瞰的に見たり、局所的に見たりする思考の切り替え（定期的に立ち止まって全体の進捗を把握して調整していく）
- ファシリテーション（会議・MTなど話し合いにおける調整役）と進捗管理
例外的に、先に述べた「実装・実現が厳しい場合の代替案の考案及び提出」が生じますが、結局は上記2つの工程内に含まれます。
たった2つのことですが、これは本当に難しいタスクです。この点で言えば私などより皆さんの方が知見があるかもしれません。
例えば、先の実装や実現が厳しい場合で先方が怒りから詰めてきているパターンを想定してみましょう。
この場合「とにかく何とかしなければ」と、心理的にどうしても局所的な思考になってしまいます。
しかし、そこだけにとらわれると全体の進捗に影響を及ぼすリスクが出てきます。
不安もあって難しいかもですが、まずは一旦落ち着いて、そして開き直りましょう。
開き直らないと真面目な人ほど自分を追い込んでしまって潰れます。
しかし開き直ると言っても「もうさァッ 無理だよ わかんないんだからさァッ」という感情に走った負の開き直りにならないように注意してください。
「無理なものは無理やからなぁ～（はんなり）」って感じで、良い意味で開き直ると不思議と落ち着いて物事を考えられます。
さらにそこから代替案が浮かんでくることもあります。
ファシリテーションでも思考の切り替えが重要です。
複数人でのMTを円滑かつ建設的に進めて意思決定・策定していく場合も常に客観的な視点（俯瞰）と、サイト制作または運用していく現場の目線（局所）での考えが必要です。
会議に参加しているメンバーだけで進めるとスムーズな案件進行に無意識にとらわれて、どうしても機能の実装や（上役からの絶対的な修正指示による）改良への意識が先行し、機能の詳細仕様や使い勝手への考慮がおざなりになってしまうことがあります。
ですから、上役からの絶対的な修正指示をクリアすることを意識しながらも現場への配慮を行い、絶対的な修正指示の中身を変更してしまうのが最適解なパターンもあります。
※このとき勝手に進めるのではなく「案件関係者と協議した総意として～～。かような修正もいかがかと～～」と、変更して良いかの相談・報告を事前にしていたほうがベターだと思います。
また、場合によっては、リスケや機能削減、似たような機能・ページを統合するなどの提案、臨時MT、ヘルプ要請（例：外注依頼）なども必要になるかと思います。
領域横断的な視点と行動（他部署への根回し）
前項の「案件コントロール - ファシリテーション」に属するかもしれません。
webサイト制作案件なら起こり得ないかもしれませんが、webサービス制作案件なら「サービス内容が法的に問題ないかどうか」や「新しい契約書などを用意する必要があるかどうか」など法務部や事務など他部署を巻き込んだ規模になる可能性があります。
こういった部分で緻密に連携を取っていないと担当者の心象を悪くしたり、案件進捗に支障を来したりしてしまうリスクがあります。
（実際私は「急にそんな事言われても」や「聞いていた話と少し違う」など迷惑をかけてしまったことがありますので）
SEO知識
これを専門にしているところがあるくらいSEOは広く深い分野です。
ですから、初めから十分なSEO対策を施すのは厳しいと思います。※SEO特化で学ばせるチームを作るなら別だが、それでも簡単ではない。
あるにこしたことはないSEOの知見ですが、まずは先方の要望に十分に応えることが第一義です。デザインや機能など最低限の要望をクリアして、初めてSEOへの考慮を進めてください。
なぜなら、SEOへの考慮を優先した実装を行うと手戻りが発生した際にSEO対策部分が水泡に帰します。時間は有限なので先ずはデザインや機能といった顧客の要望達成を最優先に進めてください。
ただし、確実に変更・修正が無いと踏んだ部分があれば、この限りではありません。加えて当然ながら、納品時または納品後はSEO対策のフォローアップが程度に応じて必要です。
アクセシビリティは別です。SEOとアクセシビリティを混同した情報も中にはありますので注意してください。
例えば、画像を表示するためのimgタグというものがあり、それにはalt属性というものを設定します。これは「画像の説明テキスト」で、視覚障害者のためにスクリーンリーダーなどで読み上げられるテキストとなります。装飾系画像には不要ですが一般的には設定必須です。
『Google』はここをチェックしたりしています。そのため、アクセシビリティ＝SEOと混合されがちですが厳密には別物です。
さらにアクセシビリティは初期段階から意識して実装していく必要があるものです。このあたりはHTMLの十分な理解をはじめ、包括的な知識が必要になってきます。
このようにSEOは領域が広いし、専門的な知見が求められるので必要・程度に応じて外部業者の協力を仰いでください。
具体的なフロー
初めに重要事項として
弊グループにおける私の立ち位置は異端でイレギュラーです。それを理解・把握していないと、外部業者とコミュニケーション齟齬が発生してしまう可能性があるので注意してください。
例えば、私は案件において「ヒアリング、サイト解析、要件定義、技術選定、顧客折衝、ファシリテーション、進捗管理、（ワイヤーフレームまたは）プロトタイプ制作、デザイン、開発、運用保守、経過観察、（ロゴ作成、フライヤー制作）」などを一貫して全て一人で行う場合も少なくないですが、これは当然まともではありません。
一般的（まとも）な企業・事業所では以下のように分業化されています。
- ディレクター
- ヒアリング
- 顧客折衝
- ファシリテーション
- 進捗管理
- ワイヤーフレーム制作（
Figmaなどでプロトタイプ制作までする人も） - （知識があれば要件定義に関わる人も）
- デザイナー
- プロトタイプ制作（UI・UX）← webサービス・システム寄り
- デザインカンプ（ビジュアルデザイン）制作 ← webサイト寄り
- 各種クリエイティブ制作（バナーやサムネイル、イラスト、あしらいなど）
- デザインルールの設定（フォントやカラーバリエーション、余白間など）
- フォントは 「見出し、本文、あしらい用途」の3種類 ほどに留めて、ファミリー（フォントの太さや種類）が豊富なもの（例：源ノ角ゴシック, Noto Sans）を選んでおくほうが無難です。
- カラーリングに関しては 「ベースカラー（背景色）、メインカラー（文字色や随所に使用する上でのキーカラー）、アクセントカラー」の3軸 を決めて進めると良いかと思います。より細かくすると「問い合わせボタンなどCTA（
Call To Action）用のカラー」や「注釈やお知らせ分類などに使用するサブカラー」などもあるかも。
- （
HTML,CSSのコーディングまでするwebデザイナーも） - （ロゴデザイナー）
- （グラフィックデザイナー）
- コーダーまたはプログラマー（エンジニア）
- デザイナー兼コーダーの場合もあれば、コーダー（
HTML,CSS）とプログラマー（JavaScript,PHP,Java,Ruby,Pythonなど）で分かれている場合も - 要件定義や技術選定
- 各種機能の開発はもちろん運用保守も担う
- インタラクションの実装（ボタンクリック時の挙動やアニメーションなど）
- セマンティックなHTML構造など内部SEOやアクセシビリティ
※フロントエンド、バックエンド、フルスタック（フロントエンド+バックエンド）、インフラ、クラウド、DB（データベース）など幅広いエンジニア種がいる。webサイト制作ならたいていフロントエンド。
- デザイナー兼コーダーの場合もあれば、コーダー（
- ライター（キャッチコピーなど）
- （動画撮影またはカメラマン）
- マーケター（※程度・認識にばらつきあり）
- 簡易なサイト解析やデータ集計、レポート作成のイメージの人もいれば、
- 業界業種への深い洞察、市場調査や高度なSEO知識とSNS関連の知見、経営改善にまで繋がるような提案・レポート作成などまでイメージする人もいる
（まだまだ細かい粒度で分けられますが一旦）このような分業体制が当たり前という認識を持ってください。
途中、エンジニアの種類をいくつかあげました。これは私の経験上「こういったデザインのサイトを」というより「こういった機能を持ったサイトに」という要望が数年前から増えてきた肌感覚があるためです。
こうなってくると一般的なwebサイト制作の域を超えた話になってくる場合があります。
機能に関しては、求められる内容によってバックエンドやDB、インフラなどまで関わりを必要とする場合もあるため念頭に置いていてください。
また、分業だからと言って極端に線引きをするのではなく、あらゆるタスクや課題を自分ごととして捉え（て行動す）ることが重要だと思います。
なぜなら、専門分野を超えて行動しないと他の分野の気持ちを理解できないためです。
例えば、私はユーザーが求めるモノ・コトの実現を最重視するユーザー志向の人間です。
しかし現在、ユーザーが求めるものをフロントエンドのみで実現するのは難しいケースがあります。
そのため、あくまでフロントエンドを軸としつつも背景と根底にあるユーザー志向から、バックエンドの必要性を感じてPythonを学んでいます。
学ぶことで他分野の方とのコミュニケーション向上も期待できるかもと考えているのです。
webサイト制作の一般的なフロー
以下は「ウォーターフォール開発（※滝の流れのように一方向に向かって進んで後戻りしない）」を前提としたフローです。
web開発では「ウォーターフォール開発」や「アジャイル開発」というものがあります。
「アジャイル開発」で進めるなら「クライアントからの指示で都度修正して小さく作ったものを組み合わせて徐々に形にしていく」感じ（雑）なので、以下のように「初めから計画を設けて、それに沿って進めていく」というスタイルにはなりません。
- ヒアリング
- 参考検索（※既にある場合はスキップ）
- ラフ（ワイヤーフレーム）またはプロトタイプ制作
- 先方確認
- デザインカンプ（ビジュアルデザイン）制作
- 先方確認
- コーディング
-
WordPressの場合は「Localで開発」または「テストサーバーを用意して開発」する
-
- テスト（レイアウト崩れや動作チェック）
- 先方確認
- 公開
- 関係各所へ連絡・通知。必要に応じてSNSなどで情報発信
- PDCA
- 流入数や回遊率などアクセス状況をはじめとした経過観察や制作後の振り返りを行って新たな改善点の抽出・提案を行う
公開後は経過観察やサイト改善という流れになり、その繰り返しで当該サイトをより良くしていく流れです。
この点が紙媒体とwebの大きな違いです。
webは「中長期的な運用保守といった継続性を意識」してください。
webサイトのレイアウト例
以下は汎用的なwebサイトのレイアウト一例です。あくまで例示なので実際のレイアウトやデザインはヒアリングや参考イメージなどを通じて調整してください。
- ヘッダー
- ロゴマークやグローバルメニューと呼ばれるサイト内の各種ページリンク、各種SNSリンクを配置するのが一般的です。（メニューの配置は、横並びのリスト形式にしたり、ハンバーガーメニューで開閉式メニューにしたりなどバリエーションがあります）
- ファーストビュー
- ユーザーが最初に目にする「サイトの顔」となるセクションです。クリエイティブを発揮する場所でもありますが、まずは「このサイトが何なのか簡潔に自己紹介させる情報伝達性」を意識したほうが良いと思います
- 特徴紹介
- サイトやサービスの特徴を説明するセクションです。自己紹介した後は、サービスや製品が具体的にどんな価値（メリットや恩恵）を提供できるのかを説明します
- ユースケースや強みの紹介
- サービスや製品の導入実績をはじめ、より訴求効果を高めるための詳細情報を伝えるセクションです。第三者効果による信憑性向上や、顧客企業にサービス・製品が適しているかの判断材料（詳細情報）の提供を通じて訴求効果を高めます
- お知らせ・コラム欄
- その他、お知らせ欄やコラム欄など要望・必要に応じてコンテンツセクションを追加します。（情報伝達性に鑑みた優先度に応じて、お知らせやコラム欄をファーストビュー直下に配置するケースもあります）
- フッター
- ロゴマークやサイトの各種ページリンクの配置、コピーライト、各種SNSリンクなど配置するのが一般的です
※各セクションごとに「問い合わせボタン（CTA：Call To Action）」を配置することもありますが、やりすぎるとくどいので注意してください。
※ペライチ（1枚もの）のLP（ランディングページ）ではオリジナリティを優先して基本的なレイアウト構成にならない場合もあります。
※最近はレスポンシブデザイン（スマホやPCでの閲覧を最適化したwebサイトのつくり）で作成するのがほとんどです。
以下の「案件の進め方はアジャイル開発を推奨」項目は、筆者の属するグループ企業の風土になぞらえた記述が多くなっていますので一般的な内容になっておりません。
悪しからずご了承ください。
案件の進め方はアジャイル開発を推奨
これから説明するのは、私のこれまでの実体験を強く反映した内容になりますので参考程度に留めておいてください。
要点は「ちゃぶ台返しは防ぐ」という意見です。
ここでいう「ちゃぶ台返し」とは「ここまで進めてきた内容を全否定されて（場合によっては上流工程から）やり直すことになる現象」を指します。
多くは「デザインカンプ（ビジュアルデザイン）制作〜先方による最終チェック」の工程間で発生することがほとんどで、最悪の場合はワイヤーフレームから作り直す状況にまで発展するケースもあります。
これがいわゆる「手戻り・差し戻し」で、せっかく作ったものが無駄になる瞬間です。
これが起こる背景の多くは「コミュニケーション不足とイメージ共有ができていない」ことにあります。
例えば、私が経験した限り弊グループでは2通りの案件スタイルがあります。
- 決定事項案件：役員または事業責任者の「発案または意思決定に起因」する開発／リニューアル案件
- 準決定案件：事業責任者が「相談をベース」にした開発／リニューアルで、返答如何によって実作業に発展する案件
これら案件において最も気を配るべきは「先方担当者と上役（役員）の合意形成の確認」です。
（これは正直こちら側でコントロールできることではないのですが）ここのコミュニケーション不足によって「要望がふわついた or ズレた結果『ちゃぶ台返し』が発生する」案件を何度もか経験しました。
「先方はクライアント」という擬似的なヒエラルキーもあって泣き寝入りするケースもあります。
これを防ぐのに必要なのは「ドメイン知識」や「ヒアリング」はもちろん、先方担当者への「念入りなコンセンサス確認（*）」です。
*：しかしこれでも全ては防げません。（悔しいですが）たいてい役員からの指摘は高確率で理にかなっています。そこまでの視座や発想に至らなかった自分の実力不足も省みる必要があるかもしれません。
前置きが少し長くなりましたが、これらを少しでも防いで安全に案件を進めるには「アジャイル開発」が適しているように感じます。
私もまだ試したことがなく日々の業務に少しだけ採り入れたりしている「なんちゃってアジャイル」なので偉そうなことを申せませんが、
常にクライアントとコミュニケーションを取って都度修正し、徐々に形になっていくのをクライアント含めて確認しながら開発していくスタイルは、
今まで話してきた「ちゃぶ台返し」を防ぐ有効策になるかもしれません。
アジャイル開発
- 案件に対して細かくタスクを分けて、1〜2週間を目処に開発サイクルを取る。
- クライアントへの確認と修正を繰り返し、小さくコンポーネント（サイトを構成する最小単位・要素）を作っていく。
- それらを構築して（クライアント含めて）徐々に形になっていくのを確認しながら開発していく
アジャイル開発を大雑把に説明すると上記になります。
実際には「スクラム」やら「XP（エクストリーム・プログラミング）」やら「ユーザー機能駆動開発」やら色々な手法も絡んできて複雑です。
まずは「なんちゃってアジャイル」でも良いので「クライアントとの密なコミュニケーション」と「都度修正して小さくコンポーネントを作っていく」、「確認しながらの開発を徹底して進捗を共有する」程度のことから始めてみてはどうかと思います。
しかし、アジャイル開発は納期を定めず、予算も不透明で、クライアントとの密なコミュニケーションが肝要になるためクライアント側の負担が大きくなるケースもあります。
特にコミュニケーションに関しては、弊グループの最上流層は常に多忙なのでこのスタイルで進めづらいかもしれません。
また、アジャイル開発は以下のように「コスト的に容認しかねる性質」を持っています。
ウォーターフォールが対象とするプロジェクトは、計画通りにソフトウェアシステムを作り上げれば、それが誰かの価値になる場合ということになる。逆に、アジャイルソフトウェア開発が対象とするのは、計画通りに作り上げても、それが誰の価値にもならないかもしれないことを前提としている。ここが大きく違うのだ。
つまり、作ったものの「それが全く価値をもたらさない」可能性もあるということです。
この点も含めて弊グループでは導入は難しいかもしれませんが、試してみる価値はあるかと思います。
Tips
- スケジュール的に厳しい時の提案（WEBサイト制作）
- サブページを「近日公開（Coming Soon）ページ」にしたり、ページに「SNS情報の掲載」及び「各種メディアのリンクを案内」したりしてアタリを用意しておく
- （計画通りに進まないことを前提に）スケジュールや請負価格にバッファをとっておく
- メンバーの体調不良やスキル不足なども考慮したスケジューリングや価格決めしておく
- 引き出しを増やしておく
- いろいろなサイトを見て、各ブロック（コンポーネント）をコツコツ作っておく（
AiやFigmaなどで）
- いろいろなサイトを見て、各ブロック（コンポーネント）をコツコツ作っておく（
ここまでが社内向け資料の内容となります。
ご覧いただきありがとうございました。
さいごに
冒頭で説明した通り、本記事は社内の非エンジニア向けに書いたwebサイト制作に関する網羅的な資料となります。
web初学者の方にも役立つ部分が少しはあるかもと思って今回記事にしました。
本記事が少しでもどなたかのお役に立てれば嬉しく思います。