デザインフェーズが終わった後のサービス開発フェーズでは、リリースまでに考えることが多々あります。無事にリリースを行う為に、この記事では開発における前提や、開発フェーズで確認/考慮すべきことをまとめました。
すべての内容を網羅すると複雑になるので、今回はWebサービスに絞ってご紹介します。
開発フェーズまでに確認/考慮すべきこと
場合によっては要件定義やデザインフェーズに関わるので、適宜方針を定めましょう。
| 項目 | 詳細 |
|---|---|
| 開発言語 | 会社の採用言語や要件に対する最適な言語があるので、どの様に実現するか確認する。 |
| 依存環境 | 会社のリソースやセキュリティーなどによる影響がないか確認。 場合によっては機能制限につながる。 （Wordpressを使った方が便利だが、セキュリティーの関係で別の実現方法希望、など） |
| レスポンシブデザインの有無 | レスポンシブデザインの場合はブレイクポイントを考慮、レスポンシブデザインを採用しない場合は、追加でPC/SPそれぞれの環境準備、リダイレクト設定など考慮が必要 |
| 最小幅 | Googleアナリティクスで利用ブラウザサイズを確認できるので、利用者割合に応じて決める。 最小幅はiPhone12 miniに合わせた375pxが一般的。最近は少なくなったが、iPhone SEまで考慮するなら320px。 |
| 最大幅 | 一定以上幅を広げた時の制限値を設ける。 1,140pxが利用率が一番多く一般的。 |
| ブレイクポイント | CSSの切り替えポイントとなる。デザインもブレイクポイント時に制限が起こらないか確認する。サービスの特性に合わせて選ぶことが多い。サービスによってはタブレットをスキップすることもある 【ベーシック】 スマホ：~599px タブレット：600~959px PC：960px〜 【モバイルファースト】 スマホ：~480px タブレット：481~768px PC：769px〜 |
| 対応ブラウザ | Chrome、Safari、Firefoxは押さえる。サービス利用属性によってはEdgeも追加。 IEはサポートが終了すること、IE特有の不具合が多く工数が跳ね上がるので、対応は避ける。 |
| ドメイン | 新規サービスの場合はドメイン購入できるかを確認。購入できない場合はサービス名に影響する。 |
| SEO考慮 | リニューアルの場合、SEOの影響と引き継ぎ希望の有無を確認。Webの場合はパンくずやカテゴリー一覧など、SEOを意識したサイト、機能設計が求められる。 |
開発要件定義フェーズで確認/考慮すべきこと
| 項目 | 詳細 |
|---|---|
| テスト範囲 | 正常系：レイアウト（ブラウザ別）、遷移、基本機能、バリデーション、など。 異常系：意図しない動作の確認となるため、やりだしたらキリがないし、技術的知識も必要になる。 |
| 機能動作 | いつ、どんな挙動をして、結果どうなるか、をセットで整理する。 バリデーションについてはパターン分の洗い出しを行う。 パターンに合わせてデザインが作られているかを確認する。 |
| 開発スケジュール | 技術面での実現難易度、工数、優先度をすり合わせスケジュールを引く。 デザインフェーズで並行しての確認が望ましいが、難しい場合は一旦開発側の回答を持って、実現方法を決定させる。 |
| サイト構造 | サイト構造の一覧をサイトマップで可視化する。パターンがある場合はパターン分を網羅する。 |
| パス設計 | サイトマップに合わせたURLパスを設計する。 |
| リダイレクト設計 | サイトリニューアルで新旧のURLパスが変わる場合、旧URLに対応した新URLの一覧表を作成する。 リリース時に301リダイレクトを設定することで、リンク切れをなくし、SEO評価を継承する。 |
| タグ設計 | サイトマップに合わせた、Titleタグ、Descriptionタグ、OGP画像を設計する。 中身の異なるページは名前が被らないように注意する。 （検索結果の場合のTitleタグは「[検索名]の結果一覧」など。） SEOを考慮する場合は、テクニカルな要素も含まれるので、安易に決めない。 |
| ファビコン | 忘れがちなので気をつける。 |
リリース前後で確認/考慮すべきこと
タイミングによってリリース作業がうまくいかない可能性があります。事前に起こり得ることを網羅的に把握し、考慮しましょう。
| 項目 | 詳細 |
|---|---|
| リリース手順 | リニューアルの場合、順序が重要なケースが多い。リリース手順を設計した上でエンジニアと問題がないか、必ず事前打ち合わせを行う。 各手順で起こり得るトラブルの可能性と対応フローをすり合わせる。 （リリース後に検索機能が使えない場合、原因を調査。特定に時間がかかる場合は解析用のログを確認した後、ロールバックする、など。） |
| リリース日時 | 大規模サービスでは休日や深夜などメンテナンス期間を設けてリリースする。 必要であれば事前連絡でユーザーにメンテナンス期間をお知らせする。 |
| リリース後の動作確認 | 本番環境でのみ発生する不具合が潜んでいるケースがある。レイアウト（ブラウザ別）、遷移、機能、リダイレクト、を確認する。特にCVに直結するページは最優先で確認する。 |
| キャッシュの確認 | リニューアル後にキャッシュの関係で古いページやファイルを取得し、レイアウト等に影響を及ぼす場合がある。 事象発生時にはサービス側でキャッシュ削除を行い、リフレッシュする。 |
サービスの規模や対象によって変動しますが、最低限押さえる項目は今回挙げたものかなと思います。（見つけ次第追記していきます！）
プロジェクトごとにチェックリストを作成して、漏れがないように運用してみましょう！
会社紹介資料
セブンデックスの会社概要が解説されている資料を無料でダウンロードできます。
筒見 憲介 事業/組織開発
アメリカ/ボストン生まれ。新卒のナビタイムジャパンでフロント/サーバーサイドエンジニアを経験後、グッドパッチでプロジェクトマネージャー、UXデザイナー、マーケティングを担当。2019年セブンデックスに入社。事業・組織開発として、マーケティング、プロジェクトグロースに従事。SalesfoceなどCRMを活用した事業支援を行なっている。 
