コンテンツにスキップ

技術引き継ぎ書

本書は、納品時の技術引き継ぎで最初に確認すべき論点を短く整理した入口資料です。詳細な構成値、運用手順、障害対応は各正本ドキュメントを参照してください。

この文書の位置づけ

  • 引き継ぎ担当者が「何を確認し、どの資料を正本として見るか」を把握するための案内資料
  • 現行の実装・配備モデルに合わせた要点のみを記載し、古い構成や推測は載せない
  • 具体的な担当者名、連絡先、機密値は本書に埋め込まず、別管理の最新台帳を参照する

最初に確認する資料

まずは 引き継ぎ向けコードベース全体像 を起点にし、その後で構成・運用の正本へ進んでください。

引き継ぎ開始 30 分の読む順

  1. 引き継ぎ向けコードベース全体像 で「何がどこにあるか」を把握する
  2. プロジェクト背景と全体像 で業務背景と対象範囲を確認する
  3. 03. 実装仕様ポータル で詳細設計の入口を把握する
  4. 保守・サポート計画書 で契約条件・窓口・応答条件を確認する
  5. システム保守ガイド で日常運用と障害一次対応の入口を確認する
目的 最初に見る資料 補助資料
コードベース全体像をつかむ 引き継ぎ向けコードベース全体像 プロジェクト背景と全体像
システム構成と配備先を確認する システムアーキテクチャ設計書 デプロイメントガイド、Storefront の Cloudflare Workers デプロイ手順
環境変数・シークレット運用を確認する Secrets Manager 運用 環境変数ガイド
日常保守・障害一次対応を確認する システム保守ガイド バックアップとリストア、Storefront メンテナンス運用 Runbook

文書の役割分担

文書 役割 この文書で判断すること
technical-handover.md 引き継ぎ時の確認順、権限移管、参照先の案内 何をどの順で確認すれば保守開始準備に入れるか
codebase-architecture-overview.md コード配置、外部依存、環境境界の俯瞰 どの領域をどこから読むか
maintenance/ 配下の runbook 日常運用、障害一次対応、バックアップ/復旧の runbook 何か起きたとき最初にどの手順を開くか
../../04-project-management/maintenance-support-plan.md 保守契約条件、窓口、応答条件、料金 どこまでが保守契約の範囲か
../../03-implementation/infrastructure/ 配備・監視・シークレット運用の技術詳細 実装/基盤の詳細をどこで確認するか

現行構成サマリー

領域 現行方針 正本
Storefront Vite Storefront を Cloudflare Workers + Static Assets で配備 storefront-cloudflare-deploy.md
Backend Vendure サーバーを Fly.io へ配備 deployment-guide.md
管理画面 運用画面は Vendure Dashboard。配備面では React Dashboard を Cloudflare Workers（vendure-dashboard / vendure-dashboard-staging）で配信 deployment-guide.md
データ層 PostgreSQL と Redis は環境ごとに Fly.io 側で分離して運用 system-architecture.md
ストレージ アセット・帳票系は Cloudflare R2 を中心に運用し、一部 Fly Volumes を併用 system-architecture.md
シークレット CI / deploy の正本は AWS Secrets Manager。GitHub secret を別正本として持たない前提 secrets-manager-operations.md

引き継ぎ時に確認する項目

1. アクセスと権限

  • GitHub リポジトリ、Actions 実行結果、環境変数参照に必要な権限が引き継がれている
  • AWS（Secrets Manager / OIDC 利用先）の権限が引き継がれている
  • Fly.io（Vendure、PostgreSQL、Redis）の参照・操作権限が引き継がれている
  • Cloudflare（Workers、R2、KV、DNS）の参照・操作権限が引き継がれている
  • 監視・エラー追跡に使う外部サービスの参照権限が引き継がれている

2. 配備・運用フロー

項目 現行の見方 詳細
staging 配備 develop への push、または手動 dispatch を起点に GitHub Actions で実行 .github/workflows/deploy-staging.yml
production 配備 main への push を起点に GitHub Actions で実行 .github/workflows/deploy-production.yml
Vendure 配備 Fly.io へ配備 .github/workflows/_deploy-vendure-fly.yml
Storefront 配備 Cloudflare Workers へ配備 .github/workflows/_deploy-storefront-workers.yml
React Dashboard 配備 Dashboard UI 変更時に Cloudflare Workers へ配備 .github/workflows/_deploy-dashboard-workers.yml

2.5 保守開始可否を判断する最小チェック

「共有された」「把握した」だけで終わらせず、最低限次の状態になっていることを確認してください。

確認項目 完了の見方 正本
権限移管 GitHub / AWS / Fly.io / Cloudflare / Sentry で必要な参照先を開ける 本書「1. アクセスと権限」
本番・ステージングの健全性確認 production / staging の URL、/health/live、/health/ready、/version の参照先を把握している 監視・運用設計書
ローカル保守導線 just dev-vendure / just dev-storefront / just dev-dashboard / just dev の入口を把握している 環境変数ガイド
runbook 導線 日常保守、バックアップ/復旧、Storefront 緊急停止の参照先を開ける システム保守ガイド
契約条件の理解 応答条件・窓口・対象範囲を契約文書で確認済み 保守・サポート計画書

3. 引き継ぎ後に最低限確認すること

  • production / staging の URL、ヘルスチェック、バージョン確認導線を把握した
  • バックアップ / 復旧手順の参照先を確認した
  • Storefront のメンテナンス切替が Cloudflare KV を正本としていることを確認した
  • ローカル起動導線（just dev-vendure / just dev-storefront / just dev-dashboard。必要に応じて just dev）を確認した
  • コードベースの読み始めは 引き継ぎ向けコードベース全体像 を起点にすることを共有した

障害一次切り分けの最短順

  1. Sentry を最初に確認する
    実環境エラーの正本は Sentry とし、Storefront / Vendure / React Dashboard のどこで失敗したかを先に切り分けます。詳細は 監視・運用設計書 を参照してください。
  2. safe probe とバージョン導線を確認する
    /health/live、/health/ready、/version の導線と、production / staging のどちらで起きているかを確認します。
  3. 基盤ごとの責務面へ進む
    Storefront / React Dashboard 側なら Cloudflare、Vendure / PostgreSQL / Redis 側なら Fly.io、シークレット同期や CI 導線なら AWS / GitHub Actions を確認します。
  4. 該当 runbook を開く
    障害内容に応じて、保守ガイド、バックアップ/復旧、Storefront メンテナンス切替の各手順へ進みます。

運用 Runbook 早見表

状況 最初に開く資料 補助資料
日常保守・定期点検 システム保守ガイド 保守・サポート計画書
バックアップ / 復旧 バックアップとリストア システム保守ガイド
Storefront の緊急停止 / 復旧 Storefront メンテナンス運用 Runbook 補足仕様
監視・アラート・Sentry 切り分け 監視・運用設計書 システム保守ガイド

この文書に含めない情報

以下は変化しやすいため、本書へ固定値として書かず、各正本または別管理台帳を参照します。

  • 実際のシークレット値、トークン、接続文字列
  • 個人名ベースの連絡先一覧
  • 暫定運用メモや未承認の手順
  • 根拠が追えない監視閾値、同期頻度、性能値

参考資料