ソフトウェア開発チームの人数が増えると情報の整理方法が悩ましいので、網羅性はありませんが思いついたものを列挙しておきます。
- ドキュメントを書く
- インフラを整える
- 開発環境を整備する
- 設定情報を管理する
ドキュメントを書く
そもそも何を実現するソフトウェアなのかがブレてしまうプロダクトもあると思いますので、 基本的なことをしっかりと書いておくことは重要です。
- 基本事項
- 目標
- 要件 (機能要件、非機能要件)
- 設計思想
- 仕様 (外部仕様、内部仕様)
- チームメンバーの入り口となる情報
- ソースコード管理システムへのポインタ
- チケットなどのトラッカーへのポインタ
- 開発ロードマップとマイルストーン
- コミュニケーション・チャンネル (メール、チャット、ニュースレターなど)
- プロジェクトの用語集 - SQLAlchemy の場合
- プロセスに関するドキュメント
- 開発全般に渡るワークフロー - mozilla.org の bedrock の場合
- エスカレーション、バグトリアージの手法 - Mozilla の場合
- リリースサイクル (時間で区切るか、機能で区切るか) - Ubuntu の場合
- 機能に関するドキュメント
- API ドキュメント (ライブラリ、データ API)
- エンドユーザーマニュアル
- システム管理者マニュアル
- サービス品質、運用体制
- SLA: Service Level Agreement - AWS の EC2 の場合
- バックアップ計画、災害復旧の手順
- セキュリティポリシー
- 運用レポートや KPI
- 行動規範やガイドライン、ライセンスの考え方
- 各種ドキュメントのテンプレート
インフラを整える
サービスを運用するインフラはもちろんですが、日頃の開発やコミュニケーションを円滑に進めるためのインフラの整備も重要です。 英語版 Wikipedia の Deployment environment の分類がわかりやすいと思います。
- 運用環境
- クラウドサービス; AWS, Azure, GCP、その他
- オンプレミスのデータセンター
- CD 設定 (Continuous Delivery)
- ロールバックの方法
- ロールアウトの方法 - Canary Release
- モニタリング
- 検証環境
- 負荷テスト - Netflix の場合
- 開発ツール
- ソースコード管理システム
- 共有ドキュメント (例: Wiki)
- 不具合管理システム
- チャットルーム
- CI 設定 (Continuous Integration)
- アカウント管理
- スーパーユーザー (例: 他のアカウント作成や削除など)
- パワーユーザー (例: 読み書き権限を有する)
- 運用担当 (例: 読み込み権限のみ)
- 支払いアカウント
開発環境を整備する
個人の開発環境はお任せでも良いのかもしれませんが、複数のミドルウェアを組み合わせる場合は仮想環境を組み合わせた方が良いでしょう。 また、規模にもよるでしょうが、会社で何らかのライセンスを購入している場合は申請から割り当てまでのワークフローがあると良いでしょう。
- ツールのインストールや仮想環境の設定方法 - CircleCI Documentation の場合
- 品質保証の観点 - ユニットテスト、結合テスト、コードカバレッジなど
- 本番環境への適用方法 - Managing Multiple Environments for an App (Heroku)
- ビルドなど一連の処理に関するタスクランナー - JHipster の場合
- ダミーデータなど、テスト用データ管理 - Agile Support to Testing
設定情報を管理する
複数のメンバーが複数の環境で作業すると、設定情報の管理にも配慮が必要になります。
- アプリケーションやライブラリの設定
- ミドルウェアの設定
- OS のパラメータ
- データベース
- ロードバランサー
- スケールアップかスケールアウトか - Scalability - Wikipedia, the free encyclopedia
- 認証情報の管理
- Credential Management Level 1
- SSL 証明書 - Let’s Encrypt
終わりに
つらつらと書いてみましたが、すべてを一斉に揃えることは現実的ではありませんので、 プロジェクトの目的や規模、関係者に合わせて必要なものをピックアップする必要があります。 プロジェクトのメンバーが増えると、あれは無いんですか？、という質問も増えますので、 プロダクトの成長に合わせて管理対象を棚卸ししてみると良さそうです。