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

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

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

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

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

みたいなイメージです。

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

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

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

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

##基本コンセプト

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

#要件管理

##バージョン管理会議

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

##進捗管理会議

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

#開発管理

コミュニケーション

ツール Slack
#general 情報共有用
リリース案内など
no reply
#random 雑談部屋
なんでも
#times_ユーザー名ユーザー別公開トーク
個別の質問など
#development
開発全般に対する質疑用
#release_バージョン番号
プロジェクトURLをTopc説明に反映
このバージョンの要件や開発範囲調整
このバージョンのview、API、レビュー関連

バージョンルール

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）最終確認し、仕様管理運用を行い、リリース内容アナウンス
（開発者）本番リリース

自社サービスアプリ開発管理運用