開発規程

第1章 総則

第1条 (目的)

1. 本規程は、〔会社名〕（以下「会社」という。）が提供する自社サービス及び受託システム開発における開発活動の品質、安全性及び生産性を確保するため、開発プロジェクトの推進に関する基本的事項を定めることを目的とする。

第2条 (適用範囲)

1. 本規程は、会社の全ての従業員及び業務委託先のうち、ソフトウェア開発業務に従事する者に適用する。
2. 本規程は、自社 SaaS プロダクト、社内システム及び顧客向け受託開発の全てに適用する。

第3条 (用語の定義)

1. PRD とは、Product Requirements Document（プロダクト要求仕様書）をいう。
2. ADR とは、Architecture Decision Record（アーキテクチャ意思決定記録）をいう。
3. SAST/DAST とは、それぞれ静的／動的アプリケーションセキュリティテストをいう。

第2章 プロジェクトの起案及び承認

第4条 (起案及び承認プロセス)

1. 開発プロジェクトの起案者は、PRD を作成し、プロダクトマネージャー及び開発責任者の承認を得る。
2. 承認後、技術リードは設計書を作成し、設計レビュー会において他の開発者 1 名以上の承認を得るものとする。
3. 設計レビュー承認を得たうえで実装に着手し、リリース判定会議を経て本番環境に展開する。
4. 重大な仕様変更が発生した場合は、PRD を改訂し再度承認を得る。

第5条 (アーキテクチャ意思決定)

1. アーキテクチャに関する重要な意思決定は、ADR としてリポジトリに記録し、決定の経緯、選択肢及び影響範囲を明記する。

第3章 ソースコード管理

第6条 (ブランチ戦略)

1. リポジトリは原則として main ブランチを保護ブランチとし、main への直接 push を禁止する。
2. 開発者は feature/* ブランチを切り、Pull Request（以下「PR」という。）を経て develop 又は main にマージする。
3. ホットフィックスは hotfix/* ブランチを用い、リリース後速やかに main 及び develop に反映する。

第7条 (コードレビュー)

1. 全ての PR は、起票者以外の開発者 1 名以上によるレビュー承認を必須とする。
2. レビュー観点は、機能要件の充足、可読性、テスト充足性、セキュリティ及びパフォーマンスとする。
3. セキュリティ又はインフラに重大な影響を及ぼす変更は、技術責任者の承認を追加で要する。

第8条 (コミット及び履歴)

1. コミットメッセージは、変更の意図が判別できるよう簡潔かつ具体的に記述する。
2. force push は保護ブランチに対して禁止し、レビュー履歴の毀損を防ぐ。

第4章 テスト

第9条 (テストの方針)

1. 全ての機能追加及び修正には、ユニットテスト、統合テスト又は E2E テストを適切に追加する。
2. ユニットテストのコードカバレッジは、原則として 70% 以上を維持することを目標とする。
3. CI 上で全てのテストが成功していることを、マージの前提条件とする。

第5章 リリース

第10条 (リリース手順)

1. リリース対象の変更は、ステージング環境において機能検証及び回帰テストを実施したうえで本番環境に展開する。
2. 本番デプロイは、原則として営業時間内に実施し、深夜及び休日のデプロイは緊急時に限る。
3. リリース後は所定のスモークテストを実施し、想定外の挙動が確認された場合は速やかにロールバックする。
4. 全てのリリースは、リリースノートとして変更内容、影響範囲及び実施者を記録する。

第6章 開発環境

第11条 (開発環境の標準化)

1. 開発者は、会社が指定する IDE 推奨設定、lint 及び formatter を使用し、コードスタイルを統一する。
2. ローカル開発環境のセットアップ手順は、各リポジトリの README に明記する。

第7章 OSS 及び依存関係

第12条 (OSS の利用ポリシー)

1. OSS を新規導入する際は、ライセンスを確認し、GPL、AGPL 等のコピーレフト系ライセンスについては法務及び技術責任者の事前承認を要する。
2. 利用中の OSS は、ライセンス及びバージョンを SBOM 等の形式で一覧管理する。

第13条 (依存関係の更新)

1. 依存ライブラリは、原則として月次で更新状況を確認し、セキュリティ修正は速やかに適用する。

第8章 セキュリティ

第14条 (セキュリティ対策)

1. CI パイプラインに SAST 及び依存関係の脆弱性スキャンを組み込み、検出された High 以上の脆弱性は原則として速やかに修正する。
2. 本番環境に対しては、年 1 回以上の DAST 又はペネトレーションテストを実施する。
3. 開発者は、不正アクセス禁止法、個人情報保護法その他関連法令を遵守する。

第9章 ドキュメント

第15条 (ドキュメントの整備)

1. 各リポジトリには、概要、セットアップ手順及び運用方法を記載した README を備える。
2. 公開 API は、OpenAPI 等の形式で仕様書を整備し、変更時には併せて更新する。

第10章 障害対応

第16条 (インシデント対応)

1. サービスに影響を及ぼす事象が発生した場合、発見者は速やかにインシデントを宣言し、Slack の指定チャンネルで関係者に共有する。
2. インシデントは重大度（P1〜P3）を分類し、P1 については 24 時間以内に経営層へエスカレーションする。
3. 収束後、原則として 5 営業日以内にポストモーテムを作成し、根本原因及び再発防止策を文書化する。

第11章 雑則

第17条 (改廃)

1. 本規程の改廃は、開発を所管する責任者が起案し、稟議規程に基づき決定する。

附則

本規程は、〔施行日〕から施行する。