【要確認】Webサイトプロジェクト引き継ぎ時のチェック項目を紹介します

リリィ

2021.10.19

こんにちは、Webディレクターのリリィです。

今日はWeb制作のプロジェクト引き継ぎの際に必要なことをまとめてみます。私自身、前任者から引き継いだプロジェクトで何度か大変な思いをし、改めて引継ぎ情報の重要性を身に染みて実感しています。

そんなわけで、この記事では自分がWebサイト制作のプロジェクトを引き継いだ際の事例を踏まえながら、「これは確認しておきたい……！」という項目をまとめてみました。何を用意したらいいかわからない引き継ぐ側、何を聞けばいいかわからない引き継がれる側、もしくは新メンバーにオリエンする場合にも参考にどうぞ。

なお、この記事に出てくる項目はLIGで実際に使っている資料を参考に、社内のデザイナーさん、エンジニアさんにも確認をいただきながら作成しました。

失敗事例
- 事例1：仕様変更が伝わっていない……
- 事例2：リリース方法がわからない……
引き継ぎチェック項目
まとめ

失敗事例

引継ぎ内容リストを確認する前に、疎かにした場合どんなことが起きてしまうのか、実例をご紹介します（ほぼ実体験）。

事例1：仕様変更が伝わっていない……

とある案件にて、第1フェーズ、第2フェーズで公開を分けるWordPressサイトがありました。第2フェーズの開発から、ディレクター、エンジニアが交代し、引継ぎのうえ、対応をしました。

第2フェーズの開発も佳境に入ったころ、制作したページの一部URLに定義と相違があることが発覚。実は第1フェーズの開発中にすでに変更することになっていたものが、正式に引き継がれないままここまで進んでいたのでした。

二度手間となってしまったコーディングチェックのために残業しながら、仕様変更点は（できれば変更の背景を含めて）アウトプットに残すべし、と強く思いましたとさ。

事例2：リリース方法がわからない……

こちらは保守運用案件にて。

改修が発生したら都度、リソース状況に応じてアサインされるエンジニアさん。そんなエンジニアの方が、今回のサイトの対応は初めてなので、リリース方法を確認したいとのこと。

（あれ、そういえば、私もわからない。しかも前に担当してたのって誰だ……？）

雲行きが怪しいながら、リリース方法を記したドキュメントがどこかしらに残っているはず、と信じて探すこと小一時間。前任者のメモ書きのようなコメントを過去のチャットから発見し、ことなきを得る。

こうなる前に必要情報は資料化して後任者が引き継ぐだけの状態にすべし、と実感。

引き継ぎチェック項目

それでは、ここからスムーズな引き継ぎのために揃えておきたい情報を確認していきます。基本的にはディレクターが用意しますが、必要に応じてデザイナーさん、エンジニアさんにも協力してもらいましょう。

プロジェクト基本情報

会社・人によって、まとめ方や呼び方が違うかもしれませんが、要するに確認したいことはきっと同じはず。

概要と一括りにしても意外とたくさんあります。

クライアント	発注元のお客様は誰か？どんな業種？エンドクライアントがいる場合はそこまで各社の関係も把握しましょう。
案件概要	どんな背景で、何のために、何を制作する案件なのか？新規制作かリニューアルなのか？初見の人が見ても理解できるよう簡潔にまとめましょう。
プロジェクトスコープ	自社の担当作業範囲は？やらなくていいことは？控えめに言って大変重要です。
スケジュール	納期はいつ？マイルストーンは？詳細スケジュールの共有を。
体制図	社内メンバー、クライアント窓口・社内体制、関係各社が複数ある場合は全体像と各社スコープをしっかり整理しましょう。
コミュニケーションルール	連絡ツールは？会議の頻度は決まってる？すでに決まっているルールがあれば踏襲するのが吉。

突き詰めていくともっといくらでもありそうですが、一旦基本情報をここまでとします。

さあ、ここまで見ると何かに気づきますね。

そうです、これらはすべて要件定義段階までに絶対取り決めされているはずのことです。つまりしっかりアウトプットが残されていれば、引き継ぎ時は、要件定義時の取り決め資料を連携すれば済む話なんですね。

プロジェクト基本情報（実装編）

続いて、実装面での前提情報です。こちらも要件定義資料がきちんと残っていれば、それで終わりですが、肝心の中身に何が書いてあって欲しいかを参考までに挙げます。

ディレクトリマップ	ディレクトリ名、URL一覧、タイトル、ディスクリプション……。ディレクトリマップで定義されていることは全部最新にしましょう。
サイト名、サイトマップ	既存サイトがあれば対象サイト名、サイトマップ全体も確認できるようにしておきたいところです。
ドメイン名、公開URL	ドメイン名は決まってる？それは新規取得？取得済？これから取得するなら、お客様に取得してもらうのか代行するのかまでフォローを。
サーバー情報	既存のサーバーを使用する？それとも新規構築予定？
外部連携、GA/GTMの有無	Google Analytics、マーケティングオートメーションツールなど、外部ツールの連携がある場合はすべてのツールをリストアップしましょう。
CMSの有無	CMS導入の予定があればそれも明記を。
対応ブラウザ	対応予定ブラウザは？ IEの対応は必須？対応前提のブラウザによって実装方針が変わることも。
画面幅の定義	レスポンシブ対応？最大幅、最小幅の定義は？
デザインデータ	制作途中、FIXしたWF、デザインファイル、デザインガイドラインなどの一式。
仕様書一式	画面仕様書・CMS仕様書・フォーム仕様書……。呼び方はいろいろあれど、仕様書と名のつく定義資料はすべて共有を。

多いですね。Webサイトを作るときに決めることは、たくさんあることがわかりますね。

開発環境、リリース関連情報

特に保守案件において、「これわかる人誰だっけ？！」が起きないようにするために、揃えておきたいところです。この辺りは、担当エンジニアさんの協力を仰ぎながら、しっかりオフィシャルな形のアウトプットを残しましょう（個人のメモはだめ、絶対）。

開発環境	開発環境はどこ？ LIGではbitbucketを使用しているので、対象のリポジトリを確実に伝えられるようにします。
テスト環境	ステージング環境がすでに用意されていれば、そのURLは？そして、ステージング環境へのリリース手順も忘れずに。
公開環境	本番環境のURLは？そしてリリース手順も忘れずに。重要です。
各種接続情報	案件によって違いますが、FTPの認証情報、SSHの認証情報、ベーシック認証情報、WordPressのログイン情報、サーバーのアカウント情報などなど。 ※それぞれの利用手順をテキスト併記があるとなおよし

実はこれが一番重要かもしれない課題管理表

プロジェクトの進行中に、最初に定義されたことから諸事情で仕様変更がされる部分はゴロゴロあると思います（というか、変更がないプロジェクトはない）。

そして引き継ぎ時に最も厄介なのも、この”仕様変更”です。変更点を担当者が把握できているうちはいいのですが、変更履歴とともにドキュメントに残っていないと後から非常に危険なリスクになって帰ってくるのでしっかり対策しましょう。

課題管理表（制作フェーズ）	何らかの事情で仕様変更にいたったもの、何らかの質問があり調査回答したもの、など。
対応履歴（保守運用フェーズ）	改修箇所の記録、トラブル発生時の概要や対応内容。

特に当初要件からの変更や、議論の結果変更されたことはその背景とともに残しておけるとベストです。どんなフォーマットでどこに記録していくかは案件によって最適化が必要かと思います。

日々の業務に追われて、後まわしにしてしまいがちですが、引き継ぎのみならず未来の自分を助けることにもなるので侮れません。