はじめに

アプリを開発する際、自社常駐スタッフ、アウトソース先制作業者、リモートワークスタッフ、ビジネス関連の方など 多様なステークホルダ が存在します。

また、自社アプリサービス開発の場合、事業とアプリサービスが一体となるケースもあるので、 要件や優先順位がビジネスシーンに応じ頻繁に変更 します。

そんな状況下、サービスの価値を最短で最大化するための開発管理を整え、関係者と管理進行について共通理解を得る必要があるので、まとめ、がてらqiitaに概要を記すことにしました。

開発コンセプトとしては、

バージョン＞開発内容＞期限目標

みたいなイメージです。

つまり、まず 何する? を 会議で確認 し、バージョンに記す ことを必ずやろうということです。

そして、 どのバージョンで何をした? をリリース後、管理することに重きをおくことです。

プロジェクトの 最初と最後 を大切にするイメージです。

基本的に、当たり前のことですが。。。

基本コンセプト

期限のある開発には向かない
割り込みは別開発フローで対応 する例外処理
リリースしたい開発がある場合、 案件をバージョン管理会議に必ず通す
バージョン内で決めたこと 以外はやらない

要件管理

##バージョン管理会議

目的
次バージョンに開発する内容を決める
次バージョンのリリーススケジュール
進行
ディレクションチーム
実施
前のリリース直前直後
参加者
可能な限り全チームメンバー

進捗管理会議

目的
次バージョンリリース開発の改題・進捗確認
進行
ディレクションチーム
実施
必要に応じて
参加者
ディレクション
オペチーム

開発管理

コミュニケーション

バージョンルール

0.0.0
1桁
major
仕組みが変わったりする場合
2桁
minor
主要な機能追加系
3桁
small
改善、修正系

ソース管理

ツール Github

Organization

github.com/orgs/組織名/projects/番号

Repository

github.com/組織名/App-iOS
github.com/組織名/App-Android
github.com/組織名/API

プロジェクト管理

ツール Github

Project

開発範囲と関連レポジトリを設定する
命名規則 iOS Release バージョン番号
Project Template: Automated Kanban Template
Organization配下に、プロジェクトを作ると、例えば、APIレポジトリとiOSレポジトリにリンクができるので、アプリ開発に対応するシステム開発とを同時に同じプロジェクトで管理ができる

Milestone

期限を設定して開発内容を説明に記入する
Smallアップデートに関するイシュー用に設定
命名規則開発バージョン番号

イシュー運用

ツール Github

Normal Issue

Assingee（担当者）担当者は必ず設定
Label チケットが該当するラベルを必ず指定する
Project 登録するプロジェクトが分かっている場合、設定する
Milestone 登録するマイルストーンが分かっている場合、設定する
テンプレート使うのあり

PR Issue

Reviewerを必ず設定する
Projectを必ず設定する
レビューして欲しい内容を必ずリスト（チェックボックス）で、コメントに記す
再現が必要な場合、その手順を記す
コメントコマンド
関連のイシューの場合 #イシューID を指定
クローズしたいイシューの場合 close #イシューID を指定
テンプレート使うのあり

Commit

コメントコマンド
関連のイシューの場合 #イシューID を指定
クローズしたいイシューの場合 close #イシューID を指定

ブランチ運用

production ブランチ

stable
リリースソースを管理するブランチ
直近のPRにリリースバージョンを入れる
命名規則　Rlease バージョン番号

master ブランチ

unstable
開発のメインブランチ
masterブランチからブランチを切って、masterに戻すが一連の流れ

ツール

mkbranch.sh を使ってリモートブランチを作って、作業をする。
ブランチ名は、 #イシューID-イシュー名 になる（mkbranch.shが自動でやってくれる）。
./mkbranch.sh "イシュー件名 #イシューID" で実行、シェルへの引数は、イシューの件名をコピペすれば使えるようになっている。

#!/bin/bash
issue_string="$1"
issue_string=${issue_string//\ /-} #replace whitespaecs with -
issue_number=`expr "$issue_string" : '.*\(#[0-9]*$\)'` #extract issue number
issue_name=${issue_string%$issue_number} #remove prefix
issue_number=${issue_number//#/} #replace hashmark with 'issue'
branch_name="$issue_number-$issue_name" #join strings in reverse order
branch_name=`echo ${branch_name} | sed 's/.$//'` #remove trailing -

echo "switching to master"
git checkout master

echo "fetching origin"
git fetch

echo "pulling latest master"
git pull 

# check if branch exists and silence output
git rev-parse --verify "$branch_name" &> /dev/null

if [ $? -eq 0 ]; then
    echo "branch $branch_name already exists locally"
    git checkout "$branch_name"
    git branch
else
    echo "creating branch $branch_name"
    git checkout -b "$branch_name"
    git branch
    echo "pushing local branch to origin"
    git push --no-verify -u origin "$branch_name"
fi

チーム編成・役割

ルール
個人は複数のチームに所属できる

マネージメントチーム

役割

要件・要望
優先順位判断

メンバー

決裁権者
サービス責任者（プロマネ）

ディレクションチーム (Project, Milestone, ToDo)

役割

要件調整
開発範囲を決定調整
開発進行・管理
開発管理
MTG管理運営レジメ準レジメ録
バージョン決定
プロジェクト準備
マイルストーン準備
イシュー作成と担当調整
Slackバージョンチャンネル準備
プロジェクト運用開発範囲が決まったら、プロジェクトをGithubに作成
マイルストーン運用開発範囲が決まったら、マイルストーンをGithubに作成
イシュー運用開発範囲が決まったら、要件を ToDo に追加担当は、開発/オペチームの誰か
ディレクションや調整が得意、サービスのことを理解している必要がある

開発/オペチーム（In progress）

役割

技術仕様作成
工数見積
実装、DevOps
イシュー運用
作業開始時、In progress にする
作業終了後、Review in progress にする
レビュワーはレビューチームの誰か

レビューチーム（Review in progress)

役割

イシュー/PRのレビュー

イシュー運用

確認がOKの場合、Reviewer approved にする
確認がNGの場合、In progress に戻し、開発/オペに Slack でメンションする
PRレビューの場合は、Merge後、Close 可

QAチーム（Reviewer approved)

役割

Reviewer approved イシュー最終確認
仕様一覧管理（必要に応じて仕様一覧更新）
リリースアナウンス

イシュー運用

Reviewer approved のイシューの最終動作確認後、Close
全てクローズしたらリリース依頼

リリース管理

検証バージョンリリース

リリースタイミングレビューチームのレビューがClose後

本番リリース

リリースタイミング QAチームの確認終了後

開発手順

（ディレクタ）バージョン管理会議を開催
（開発者・デザイナー）要件イシューから仕様検討・作成し開発プランを策定
（開発者・QA・レビュアー）リリース前の検証項目を作成
（ディレクタ・開発者）開発プラン検討し開発範囲を最終確認
・・・実装中・・・
（開発者・レビュアー）イシューがCloseしたらレビュー依頼
（開発者）検証バージョンをリリース
（レビュアー・QA）最終確認し、仕様管理運用を行い、リリース内容アナウンス
（開発者）本番リリース