はじめに
- 内製プラットフォームを開発することになったときに、最初に準備したことのメモです
- 何もない状態から、後はコードを書くだけ、という状態になるまでにやったことをまとめました
前提
- 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)
- デザインドキュメント
- Scope, Background, Problem Statement, Proposal
- 参考
チケット管理ツールの整備
-
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）
- スプリントによらず自分のチケットたちをステータスごとに管理
- 障害、問い合わせ、課題
- Backlog（テーブル）（Group by Epic）
-
分析グラフを作成した
- バーンアップチャート
- ベロシティ（スプリントごと）（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を作成した
開発規約の整備
以下を開発規約として記載した
- ブランチ戦略
- GitHub フロー
- mainでstg、tagでprod
- 命名規則
- コミットメッセージのプレフィックス
- Pull Requestのテンプレート
- レビューコメントのプレフィックス
初期コード配置、CI/CD設定、開発環境構築手順作成
- Python