はじめに

内製プラットフォームを開発することになったときに、最初に準備したことのメモです
何もない状態から、後はコードを書くだけ、という状態になるまでにやったことをまとめました

前提

MLOpsチームとして内製MLプラットフォームを提供し、それを各PJが利用しました
以前、下記のような課題が発生したので、その時の反省を踏まえてルールを整備しました
- プラットフォームをエンハンス（PJごとの個別対応含め）するごとに、ドキュメント構成の整合性がなくなったり、更新漏れするドキュメントができてしまった
- ドキュメントは大別すると、プラットフォーム開発者向け・プラットフォーム運用者向け・利用者（ユーザ）向け・共通利用、があるが、混ざってしまって分かり辛かった
- チケットが乱立して、管理し切れず、正しく状況の把握や振り返りが出来なかった。また、ユーザからの問い合わせや依頼はチャットで対応してしまい、記録が残らなかった

準備したこと

ドキュメント管理ツールの整備

GitHub wikiに以下を作成した

00_共通
  障害・メンテナンス情報
    <内容>障害ステータスやメンテナンス予定が分かるようにする。チケットへのリンク。
10_MLプラットフォーム
11_プロジェクト管理
  ドキュメント管理ルール
  チケット管理ルール
  体制図
    <ポイント>ステークホルダー含め記載する
  アカウント管理台帳
  会議体
    <内容>下記に別途記載
　　　　コミュニケーションツール
  勤怠ルール
12_要件定義
  プロダクトビジョンステートメント
    <内容>プロダクトを作る目的やなぜ作るのかについてまとめたもの
    <内容>ex. 【顧客ニーズ】をもつ【ターゲット顧客】に対して、【商品名】は【USP】がある【カテゴリ名】です。【競合商品】とは違い、私たちの商品は【差別化ポイント】を有しています
  プロダクト戦略
    <内容>プロダクトを通して実現する世界のために何に優先を置き、何をしないかを明らかにしたもの
    <内容>リーンキャンバス: 顧客セグメント、課題、独自の価値提案、解決策、チャネル、収益の流れ、コスト構造、主要指標、圧倒的な優位性
  プロダクトコンセプト
  プロダクトロードマップ
    <内容>指標とマイルストーン
    <内容>KPIを決める、振り返る
  プロダクト要件
  非機能要件
    <内容>[インフラ構築のプロジェクトで実施していること](https://qiita.com/nokoxxx1212/items/2ec23c3575f17ae6f536)
    <ポイント>特に、メンテナンス時間は合意しておくこと
13_基本設計
  全体システム俯瞰
    <内容>外部システムとの連携含めて記載する
  アーキテクチャ構成
  ソフトウェア構成
  処理方式概要
    <内容>ユーザインターフェイスの観点も含める
  インフラコスト見積もり
14_詳細設計
  共通
    命名規則
    リソース一覧
    IAM一覧
      <内容>グループごとの権限・所属するユーザ
      <ポイント>変更履歴を管理する。後からどういう経緯（理由、誰の依頼）で権限が追加されたかを確認できるように
    ジョブ一覧
  実行環境
  運用環境
    踏み台
    デプロイ
    監視
    バックアップ・リストア・改廃
    セキュリティ
15_開発
  開発規約
16_テスト
  <ポイント>エンハンスのタイミングでケースを追加していくことになる
  テスト計画
  単体テスト
  結合テスト
  障害テスト
  性能テスト
  セキュリティテスト
  運用テスト
17_運用
  運用手順一覧
  環境利用計画
    <内容>どのPJがどの環境をいつからいつまで利用するか
  運用体制
  接続先一覧
  接続方法
  アラート
  問い合わせ
  変更管理
  定型作業
    接続方法
    インフラデプロイ
    バックアップ・リストア
    PJ追加時のエンハンス
20_ユーザドキュメント
  ユーザドキュメント一覧
  問い合わせ・作業依頼方法
  開発ガイドライン
    開発フロー
      <内容>全体の開発フローと、サービスごとなどの詳細（コンセプト、実装例）
    開発環境構築手順
    命名規則
    リポジトリ
      <内容>ブランチ戦略、ディレクトリ構成
    共通コンポーネント
      <ポイント>メンテナンスの役割分担については検討しておくこと
    ログ出力
    CI/CD
  開発Tips
  開発QA
30_プロジェクト
  PJ-A
    ヒアリング
      <内容>プロジェクト概要、プラットフォームの利用パターン（構成）、バッチウィンドウ、体制、スケジュール、予算
90_議事録
  <内容>会議体ごと/年毎にディレクトリを切っておく
91_QA

補足
- プロダクトビジョンステートメント
  - プロダクトビジョンステートメントの作り方
- ADR（Architecture Decision Record)
  - architecture-decision-record
- デザインドキュメント
  - Scope, Background, Problem Statement, Proposal
参考
- インフラ構築のプロジェクトで実施していること
- 設計ドキュメント腐る問題、Git管理で運用してみた結果

チケット管理ツールの整備

Custom fields を設定した
- Epic（追加）
- Type（追加）（チケットが Epic なのか実作業としての Task なのかを区別）
  - Epic
  - Story
  - Bug
    - プラットフォーム障害
    - プラットフォーム問い合わせ
    - プラットフォーム作業依頼
  - Task
  - Sub Task
- Status（デフォ）
- Sprint（追加）
- Priority（デフォ）
- Estimate（デフォ）
View を作成した
- Backlog（テーブル）（Group by Epic）
  - Estimate, Priority, Sprint, Assignees, Status
  - バックログの一覧を確認→スプリントに移動する
- Sprint（ボード）（Column by Status、 Slice by Assignees, sprint:@current）
  - そのスプリントのチケットたちをステータスごとにボード管理。人別にスライス。
- My Items（ボード）（Column by Status、 Slice by Sprint, assignee:@me）
  - スプリントによらず自分のチケットたちをステータスごとに管理
- 障害、問い合わせ、課題
分析グラフを作成した
- バーンアップチャート
- ベロシティ（スプリントごと）（x: sprint, y: Estimate, status:done）
補足
- ポイント
  - ストーリーポイントはフィボナッチ数を設定する
  - チケットが大きすぎると、スプリントごとのベロシティが分からなくなるので注意
    - サブチケットを切るなどして対応する。長くても1日で終わるように
    - スパイクチケットを作る
  - Storyはユーザストーリー、受け入れ条件を記載する
  - Storyはまとまりがなく見えがちなので、グルーピングを考える
  - 割り込みタスクのコントロール
  - プロダクトバックログとして一元管理したいが、場合によっては別の表を利用することも考える
  - チケットを切るのは誰か。みんな切るとまとまりがなくなる？とりあえず切れるチケットを用意する？
- チケットテンプレート
  - How to write a useful Jira ticket
  - 必要に応じて 🎯 Deliverables, 🔜 Remaining Tasks を追加する

## 🧑 Story

- 背景、やりたいこと

## 🔨 Acceptance Criteria

- AC1

## 📝 Task List

- [] XXX

## 📚 Resources

- [PLANNINGDOC1](WWWDOTEXAMPLEDOTCOM)

参考

会議体の整備

以下の会議体を設定した

スプリントイベント

スプリントプランニング
- 前回のスプリント確認
- 今回のスプリント計画
  - 何をするか
  - どうやってできそうか
デイリースクラム
- 障害、問い合わせ、課題確認
- スプリントタスク確認
  - 前回からやったこと、次回までにやること
- 各種相談
スプリントレビュー
- 成果物確認
スプリントレトロスペクティブ
- プロセスやツールなどの観点で今回のスプリントを精査する。KPTなど

ユーザ向けイベント

ユーザ向け共有会
- 障害・メンテナンス情報
- 環境利用計画
- その他共有事項
【不定期】ユーザフィードバック会

運用イベント

運用定例
- 作業工数確認
- 障害振り返り
- リリース計画確認
- システムダッシュボード確認（システムヘルス確認）
【不定期】障害振り返り
- ポストモーテム

チームイベント

全体会
相談会

リポジトリの整備

リポジトリを作成した
ブランチ保護設定をした
Readmeを作成した
- README-Template.md

開発規約の整備

以下を開発規約として記載した

ブランチ戦略
- GitHub フロー
- mainでstg、tagでprod
命名規則
- AWSインフラ命名規約
コミットメッセージのプレフィックス
- Semantic Commit Message
Pull Requestのテンプレート
- Pull Requestのテンプレートを作って効率よくレビューしよう！
レビューコメントのプレフィックス
- よく使うレビューコメントのプレフィックスまとめ

初期コード配置、CI/CD設定、開発環境構築手順作成

Python
- Python開発環境構築手順