こんにちは、しょーごです。
突然ですがみなさん、このようなお悩みをお持ちではないでしょうか。
そもそも進捗を報告する必要があるのを知らなかった方は、今回このコンテンツを見つけられてラッキーだと思います。
なぜなら、Web制作では大体のプロジェクトで進捗を報告する必要があるからです。
しかし、今回紹介するような手法でわかりやすく報告する人は少ないのと、
自主的に報告してくれる人はかなり依頼者に喜ばれるため、
今回の内容は「知っているだけでも大きなアドバンテージ」になります。
最初に軽く私の実績をお話すると、フリーランス歴3年ほどで、制作・開発会社案件を中心に、100件近くをこなしてきました。
最近は逆に下請けの方に「進捗報告」を受けたり「納品」してもらうことも多いので、依頼者視点もあります。
なので、今回のコンテンツを見てもらえば
お、このフリーランス、やるな…!?
と依頼者に思ってもらえる途中報告ができるようになります。
今回は「進捗報告の手法だけでなく、どのタイミングで行うのが依頼者的に嬉しいか」
また、後半は納品方法にも触れていきますので、ぜひ最後までご覧いただければと思います。
- 用語の説明、開発の流れ確認
- 進捗報告方法
- 進捗報告のコツ
- 納品方法
依頼者に喜ばれる「途中経過報告」と「納品方法」がわかる
この記事を書いたのは
しょーご（@samurabrass）
このブログ「しょーごログ」の運営者。本業でエンジニアとしてサイト制作やシステム開発を数年行っており、ブログとYouTubeで情報発信を行っている。駆け出しエンジニアのコーディング課題添削も行う
＼現役エンジニアのレビュー付き／
実践レベルのコーディング課題公開中
- デザインカンプからのコーディングを経験したい
- 現役エンジニアのレビューを受けてみたい
- 即戦力級のポートフォリオを用意したい
2024年にデザインを完全リニューアルしています！
コーディングに自身をつけるにはプロからのレビューを貰うのが必須なため、制作会社も利用するレビューツールで添削をしています。
Web制作学習ロードマップにも取り入れているため、学習終了まで迷わず進むことが可能です。コーディングを本気で仕事したい方はぜひご活用ください！
＼無料の入門編から本格企業サイトまで／
この記事のYouTube版
進捗報告に関して前提
テキストだけではなく、見せる場合がある。
まず、大前提としてWeb制作における進捗報告は「制作しているものを見せられるのが一番いい」ということです。
例えばあなたがサイトをコーディングしていてトップページを制作しているなら、その制作途中のトップページが見られる形で相手に共有する必要があります。
「そんなことできるの！？」と思われるでしょうが、できます。ただ前提知識が必要になってきますので、
今回使う用語の説明及び制作の流れを説明していきます。
Web制作の流れ_用語の整理
これから紹介する用語は制作だけでなく、Web開発の現場でも使われる用語なので、このタイミングでしっかり理解しておくようにしましょう！
| 制作フェーズ名 | 説明 |
| 開発環境 | いわゆる「ローカル環境」で、あなたのVSCodeだったり、仮想環境など。 人まちまちだったり、本番とは違うサーバーになっていることも多い。自分の所で動けばOKの状態。 |
| STG環境 | 読みは「ステージング」。いわゆる「テスト環境」で、本番環境に上げる前に「極力本番に近い環境」で「試しに動かしてみる環境」。 また、クライアントにチェックしてもらうのもこの環境。ここで本番移行前にバグを取り除く。 |
| 本番環境 | 公開する場所（サーバー）。ここに上げることでリリースとなる。 Web制作では公開＝納品条件なことが多い。 |
Web制作の流れ_王道パターン
おそらく用語だけでは分かりづらいので、画像でも説明します。
- ローカル環境で開発（MAMPなどPCで立ち上げたWebサーバーなど）
- 都度STG環境にアップロード
- クライアントに都度進捗報告（STG環境を共有する）
- セルフチェック後クライアント確認（セルフチェックについては以下の記事を確認、クライアントに負担をかけないために行う）
- OKが出たら本番へ移行
- クライアント最終確認（検収と言う、本番で動かない可能性があるため）
- そのまま納品
Web制作の進捗・途中経過報告について
プロトタイプを見せる
まず、進捗報告の際はテキストによる文章だけではなく、「プロトタイプ」をみせるようにします。
STG環境で動いているサイト、システムをここでは指す
なぜなら、テキストだけでは進捗がわかりにくいのと、本当にできているのかわからないからです。
STG環境の注意点
BASIC認証とnoindex
具体的な手法を紹介する前に、注意するべきことがあるので先にお伝えしておくと、「BASIC認証」は必ずかけるようにしましょう。
駆け出しのころにやりがちなミスとして、「STG環境」をGoogleにインデックスされて、検索結果に載ってしまうという事件が起こります。
公式サイトと同時にテスト環境が表示されていたら、まずいのはなんとなくわかるかと思います。
また、まだリリースしていないものをそもそも赤の他人に見られるのは大変危険です。
なので、STG環境には最低限BASIC認証をかけておくのです。
また、このタイミングでmetaタグのnoindexを付ける場合は、本番前に外すのを忘れないようにしましょう。
noindexは検索結果にでないようにGoogleのクローラーをブロックするものなので、本番でかけたままだと逆SEO対策になってしまいます。
BASIC認証と違ってサイト自体は見れるので見過ごされがちなので、注意ですね。
進捗・途中経過報告方法
- xfreeのHTMLサーバーにアップ
- 自分のレンサバにアップ
- Githubにコードをあげていく
①xfreeのHTMLサーバーにアップ
xfreeとは？
xfreeは無料で使えるレンタルサーバーのことで、HTMLファイルをアップロードするだけでサイトを公開することができます。
またBASIC認証をかけることができるので、STG環境としてもってこいのサーバーになっています。
ファイルのアップロードもとても簡単で、「ファイルマネージャー」という備え付きの機能を使って、簡単にファイルを移してサイトを公開することができます。
②自分のレンタルサーバーにアップ
自分のサーバーとテスト用ドメインを持っている場合は、自分のレンサバで構築してもいいと思います。
その場合はFTPツールを使ってサーバーにHTMLファイルや画像などを入れていくことになります。
FTPツールはサーバーとのファイルのやり取りをするツールという認識でOK。FTPツールはこの後の「納品方法」でも必須のツールになるので、このタイミングでどういうものなのか、なんとなくでも理解しておきましょう。
私のおすすめはWindows,Mac両方で使える「FileZiila」です。
FTPでサーバーと接続するには、まずはサーバー契約時に送られたこれらの情報が必要になるので、確認します。
- ホスト名
- ユーザー
- パスワード
確認できたら、これらホスト名やユーザー、パスワードの情報をFTPツールの接続画面で入力して、サーバーに接続します。
接続されると、以下のような画面になります。
左側の「ローカルサイト」が自分のPCで、右側の「リモートサイト」が現在接続しているサーバーになります。
大抵のサーバーではリモートサイトの中の「public_html」の中にファイルを入れていくことで、公開することができるようになっています。
③Githubにコードをあげていく
Web開発会社のPHPやRailsを使ったシステム開発案件などだとあるあるなんですが、コードは都度Githubにあげてくれと言われることがあります。
その理由は、システム開発はサーバーサイドやフロントエンド、マークアップが大体同時に進行していて、
まとめてzipファイルなんかでファイルを渡されるよりも、細かくコードを共有できたほうがお互い開発しやすいからですね。
そして、Githubのプロフェクトはだいたい他の自動化ツールと併用して、テスト環境で確認できるようになっています。
更に本番反映はシステムを担当する先方が基本的に行ってくれるので、
この場合は都度納品していくような形になります。
イメージしやすいように「お問い合わせフォーム」を例に、流れを画像にしてみますが、大きく２種類の工程に別れます。
マークアップ→プログラム埋め込みの場合
こちらの場合は、まず私達「マークアップエンジニア・コーダー」がデザイン通りにコーディングを行います。
そしてできたページからGithubにプッシュしていきます。
そして、サーバーサイドエンジニアなどがそのHTMLファイルなどを元に、システムを入れ込んでいくという工程です。
この場合我々マークアップエンジニアはシステムに使われるプログラムを理解していなくても良いので、あまり問題ではないかなと思います。
難しいのは後者です。
プログラムと簡易なHTML→マークアップ
まずサーバーサイドエンジニアがプログラムと、プログラムの動作が確認できるだけの簡単なページを作成します。
このフォームは実際に機能する状態です。
我々マークアップエンジニアはこれをGithubで取得した後に、デザイン通りに整形していきます。
終わったら、またGithubで反映していくという流れになります。
GitHubの勉強方法
と入っても、いきなりGithubの環境に実務で放り込まれるのはきついです。
なので、最低限の対策を学習書２冊で行っておくといいかなと思います。
わかばちゃんと学ぶ Git使い方入門は私が知る限り「一番わかりやすく」Gitの使い方を説明してくれている本です。
また、この本は2021年6月14日に改訂版が出ておりますので、内容も最新の物になっており、今からGitを学ぶなら、間違いなくこの本だと思います。
Gitが、おもしろいほどわかる基本の使い方33改訂新版は、二冊目に読む本としておすすめです。
特に「実際のチーム開発でコンフリクトしたらどうするのか」みたいな、実務視点でのケースが載っているので、この本まで読めば、あとは実践でOKかなと思います。
それでも不安な人は、自分で一回仮のプロジェクトをGitで管理してみて運用してみるといいんじゃないかなと思います。
続いてWordPressの場合を見ていきましょう。
- XfreeのWordPressサーバーにアップ
- 自分のレンサバでテスト専用の環境を作る
- 先方が用意していることもある。
- 先方のサーバーでサブドメインでテスト環境つくる
①XfreeのWordPressサーバーにアップ
先程も紹介したxfreeですが、便利なことに「WordPressサイト」を構築することもできます。
ただし、バナー広告がスマホ表示の時に自動挿入されるので、あくまでテスト確認用となります。
WordPress案件では、開発環境と本番環境のPHPのバージョンを合わせるのも大事だったりするのですが、PHPのバージョンも切り替えられるのが嬉しいですね。
テスト環境を構築したら、あとは基本的には管理画面から「All-in-One WP Migration」などのプラグインでデータを移行すればいいかなと思います。
なお、最初に述べたとおり、検索結果に載ったり外部の人に見られないように、「BASIC認証」を必ずテスト環境にはかけておくようにしましょう。
②自分のレンタルサーバーにアップ
自分のサーバーを持っている人はテスト用ドメインなど準備して環境を作ってもいいかなと思います。
特に複数WordPress案件が走るとxfreeだけだと足りなくなったりするので、すでにサーバーを持っている人は、テストドメインも持っておくのはおすすめです。
③先方が用意してくれている
まれにですが、先方がテスト用のWordPress環境を用意してくれている場合があります。
とはいえ、実際にはほとんど遭遇したことはないので、あくまで「まれに」という感じですね。
④先方のサーバーでサブドメインでテスト環境つくる
これが一番理想的で、かつ難易度も高い方法になります。
なんと言っても、利点はこれです。
サーバーは同じなので、本番と同じスペックでテストを行える
どのようなドメインになるかと言うと、
簡単な手順としては、
（１）本番サーバーで、本番のWordPressとは別のディレクトリに、もう一つWordPressをインストールする。（これをステージング環境に）
（２）適当にサブドメイン（完全に別ドメインでもOK）を登録して、そのドメインが、１でWordpressを配置したディレクトリを指すように設定。
という流れになりますが、更に詳しくはこちらのサイトが参考になるかと思います。
https://www-creators.com/archives/218
ただこの手法を行うには、
- 先方に構築してもらう
- サーバーの管理IDとパスワードをもらい、自分で管理画面から設定する
どちらかが必要になりますので、ハードルは高いかなと思います。
進捗報告のコツ
ここまで様々な手法を紹介してきましたが、この進捗報告は果たしてどのぐらいの頻度で行えばよいのかということをお話していこうと思います。
ずばり「3日に一度」が無難かなと思っています。
相手によっては「毎日報告して！」とか「一週間に一度はお願いします」と言うかもですが、本音として発注者は作業者の進捗が「非常に」気になっているので、
そのちょうどよいバランスが「3日に一度」の頻度になります。特に相手から指示がなければ「3日に一度」進捗報告をするだけで、
このフリーランス、しっかりしてるな
と間違いなく思ってもらえます。
ぜひこれだけでも覚えて帰っていただきたいですね。
進捗報告の具体例
コーディングの場合
お世話になっております。
現在の進捗状況をご報告させていただきます。
現時点でトップページと、会社概要ページ、商品紹介一覧ページが完了しております。
以下はテスト環境のサイトURLと認証情報となりますので、ご確認下さいませ。
開発中サイトURL
https://test.shogo-log.com
ID test-shogo141
pass jsl!ngjo592olvmFJdlsD
今後の予定としましては、〜日までに特設LPとお問い合わせフォームを完成させ、〜日までに、WordPress対応を行う予定です。
また、3日に一度のペースで進捗を報告させていただきますので、宜しくお願い致します。
先方はこちらが想像する以上に進捗を気にかけるので、今後の予定も織り込んであげるのが大事です！
デザインの場合
私はデザインを外注して作ってもらうことがありますが、以下のように進捗報告を求めることが多いです。
PC版ファーストビュー作成→確認しOKなら下層作成→OKならスマホ版作成
デザインは差し戻しが多くなりやすいので、進捗報告する際は、まずファーストビューの段階でOKの確約をもらったほうがいいです。段階的にOKを取っていくのが両者にとってWin-Winかなと思います。
Web制作の納品・受け渡し方法
BASIC認証やnoindexを外すタイミングについて
- 本番でも動作確認してから最終OKもらって外す
- 本番には一切認証をかけない
案件によって柔軟に対応してもらえればと思いますが、無難なのは前者かなと思います。
- zipファイルを送付する
- FTP情報をもとに、ファイルをアップロードしていく（FileZiilaなどを使用する）
- Githubでマージしてもらう
①zipファイルを送付する
これは説明するまでもなく、zipファイルを送れば終了です。アップロードは向こうが行うので、一番ラクな方法になります。
②FTP情報をもとに、ファイルをアップロードしていく（FileZiilaなどを使用する）
FTPツールを使って、直接サーバーにファイルをアップロードして公開まで担当することがコーダーは非常に多いです。
FTPツールは実務になって初めて触る人が多いですが、案件前に自前のサーバーで練習しておくことをおすすめします。
方法はSTG環境のときと同じなので、詳しくは割愛しますが、以下３つの情報は必ず必要になりますので、クライアントに確認しておくといいでしょう。
- ホスト名
- ユーザー
- パスワード
③Githubでマージしてもらう
先程Gitは「都度納品していくような形」と言いましたが、厳密には先方にマージしてもらうか、プルリクエストを出して先方のレビューの上、通してもらうことが必要になります。
色々専門用語が出てますが、簡単にいえば「先方のチェックを通過して初めて納品」という、当たり前のことですね。
なので、基本的に先方のレビューが通れば、そのコミットは完了という認識でいいと思います。
このあたりは上記２冊の本を読んでもらえればイメージがつかみやすいかなと思います。
- 相手のサーバーにAll in one WP Migrationプラグインでアップロード （.wpressファイル受け渡しでいい場合もまれに）
- FTPで差分ファイルだけ変更する（本番のDBが更新されてる場合など）
- 「WordPress簡単インストール」などで作ってプラグインで移行
①相手のサーバーにAll in one WP Migrationプラグインでアップロード （.wpressファイル受け渡しでいい場合もまれに）
新規にWordPressサイトを構築する場合は、相手の契約したサーバーのWordPress管理画面から、「All-in-One WP Migration」などのプラグインでデータを移行すればいいかなと思います。
この場合は難しくないですね。
また、相手が同じエンジニアの場合は「All-in-One WP Migration」でエクスポートした「.wpressファイル」を渡すだけでいい場合もあります。
これは同業のフリーランスと仕事をする際によくありますね。
②FTPで差分ファイルだけ変更する（本番のDBが更新されてる場合など）
案件の性質として、「本番サイトが動いていて、かつ開発中にいくつか記事などが本番で投稿されている」ような場合は、
FTPでファイルだけ差し替えて対応することも多いです。
これはWordPressサイトは
- コアシステム
- データ格納領域(データベース)
- テーマ(テンプレート)
- プラグイン
これらでできていて、
先程の「All-in-One WP Migration」をつかっちゃうと全部書き換えて、本番の投稿データが消えてしまうためです。
なので、自分が変更を加えたファイルだけFTPで追加するということになります。
大抵は見た目を司るCSSなどのテーマファイルが大半になるかなと思います。
③「WordPress簡単インストール」などで作ってプラグインで移行
相手がWordPress環境を用意していないケースに多く巡り合うと思います。
その場合は相手側のサーバーにWordPressを入れないといけないわけですが、
昨今はどのサーバーでも「WordPress簡単インストール」のような機能があるので、そこまで難しくないです。
サーバーの契約から代行する場合も、相手がすでにサーバーを契約していた場合も、サーバーの管理画面から「WordPress簡単インストール」を行えばいいかなと思います。
不安なら自分のサーバーで練習しておくべし
ここまで
- サーバーの管理画面
- ドメイン
- STG環境
- FTP
- Git
様々なワードが出てきましたが、実案件ではある程度扱えないと高確率でパニックになることになります。
なので、個人的には「実案件までに練習しておいてほしい」のですが、２つ、方法があるのでご紹介します。
- 自分のブログやポートフォリオサイトを作成する
- 実務と同じような工程でコーディング演習課題を行う
①自分のブログやポートフォリオサイトを作成する
例えば私の場合、実案件の前に
- ポートフォリオサイトを作成し、FTPでサーバーにアップロード
- 個人ブログを案件前に初めて、サーバーでのWordPressk環境の構築方法、ローカルと本番のデータのやり取り方法
これらを「実案件前に」練習することができました。おかげで案件もなんとかこなすことができました。
私がおすすめしているConoHa WING 
なんかは、とても簡単にWordPress環境を構築できて、非常におすすめです。
このしょーごログも実務を行う前に立ち上げております。
②実務と同じような工程でコーディング課題を行う
宣伝になってしまうようですが、私の出している「コーディング演習課題」では、
- デザインと仕様書を元にコーディング（コーディング目安期間設置）
- セルフチェック項目を元にチェック
- サーバーにアップロードしてBASIC認証をかけて、初稿提出
- 修正依頼があれば修正して、再レビュー依頼
- 合格（ポートフォリオ使用可能）
という手順を踏んでいます。
サーバーへのアップロード方法はおまかせしてますので、あとは自分で「FTPでサーバーにアップロードしてみる」という工程を入れるだけで、ほとんど実務と同じ工程を体験することができます。
というような方もとてもおすすめできる課題になっております！
おわりに
Web制作で地味に情報の無かった「進捗・途中経過、報告」「納品方法」について解説しました。
今後もこういった「これが知りたかった！」なノウハウを発信していきますので、宜しくお願いします。
ご寄付を頂けると今後の更新の励みになります！
