GitLabのIssuesでQA(課題)管理/不具合管理/変更管理/進捗管理を行ってみる

目的

Excelで管理して、煩雑になりがちなQA(課題)管理、不具合管理、変更管理、進捗管理をIssuesで一括管理してみる。

---

問題

Excelだと、コミュニケーションしている間にどれが最新か分からなくなりがち。
そして、週1回の進捗のタイミングで棚卸されていれば、まだ良いが、工程終わりに棚卸してしまうと、誰も顛末がわからないままクローズとする謎の課題が大量発生する。

アプローチ方法

GitLabのIssuesのチケットで管理することで、常に最新を保つ。
そして誰でも確認できるような状態にすることで対応漏れを削減する。
コメントにて、長いやり取りもすべて記録することで、経緯も正確に追跡できるようにする。

---

考察

導入Point	活用機能	説明
担当者が手軽に使用できる事	GitLab	構成管理で利用しているGitLabのIssuesなので、Excelを開くよりも手軽に扱うことが可能
記載レベルが統一できる事	テンプレート	テンプレートを設定することでExcelで記載する程度の記載レベルは守る
品質分析など、分析項目の集計が可能である事	ラベル	ラベルを利用して分析項目を設定することで、Issuesの検索機能を利用して集計可能
社内規定のドキュメントに転記可能である事	RSS or CSV	CSVエクスポート機能を利用したい所だが、メール設定を行っていないのでRSSで対応
新規プロジェクトへの導入が簡単である事	テンプレート	GITLABのインストール＋テンプレートとラベルを設定するだけを導入可能

---

導入手順

Step0.GitLabを導入する

社内用には、Azure上のUbuntuに、https://about.gitlab.com/install/#ubuntu を参考にコミュニティ版を導入ずみ。
また、メールが利用できないため代替手段としてSlackに通知されるように設定済み。
（また別の記事で記載します。）

Step1.テンプレートディレクトリを作成する

作成ディレクトリ：.gitlab/issue_templates

Step2.テンプレートを作成する

作成したディレクトリに、.mdファイルを作成するだけでテンプレートとして利用できるようになる。
初心者であまり詳しくないので、簡単なテンプレートを作成。

QA(課題)管理.md

## QA(課題)内容


## 回答期限


## 影響範囲

------------------------
>   発行する前に確認してね！
>    1. タイトルは、[ QA-yyyymmdd-概要 ]となっているか。
>    2. ラベルは、[ QA ]となっているか。
>    3. 回答希望者をアサインしてください。
>    4. 回答希望日を選択してください。
>    5. 急ぎの場合は、Slackで催促してください。

------------------------
>    クローズする時確認してね！
>    1. QA内容に対して、十分な回答が得られているか。
>    2. 口頭で終わらせたなど、履歴が残っていない場合は、コメントに顛末を記載しているか。
>    3. 発行者がクローズしているか。

不具合管理.md

## 事象


## 操作方法／発生条件


## 不具合分類（事象検知時の一次切り分け）

コーディング起因、環境起因、データ起因、既存起因


## 影響範囲（起票時に確認できているレベル）


------------------------
>   発行する前に確認してね！
>    1. タイトルは、[ BUG-yyyymmdd-概要 ]となっているか。
>    2. ラベルは、[ Bug ]となっているか。
>    3. エスカレーション先をアサインしてください。
>    4. 不具合解決希望日を選択してください。
>    5. 急ぎの場合は、Slackで催促してください。

------------------------
>   クローズする時確認してね！
>    1. 直接原因が回答されているか。
>    2. ラベルに直接原因分類が追加されているか。
>    3. 根本原因が回答されているか。
>    4. ラベルに根本原因分類が追加されているか。
>    5. ラベルに不具合埋め込みフェーズが追加されているか。
>    6. ラベルに対応分類が追加されているか。
>    7. 対応内容が回答されているか。
>    8. 対応資源が回答されているか。
>    9. ラベルに横展開有無が追加されているか。
>    10. 横展開有無理由が回答されているか。
>    11. 横展開条件／方法が回答されているか。
>    12. 横展開結果が回答されているか。
>    13. 横展開結果の影響資産が回答されているか。
>    14. 横展開結果の影響資産の対応結果が回答されているか。

変更管理.md

## 変更理由


## 変更内容


## 概算工数（起票時に確認できているレベル）


## 影響範囲（起票時に確認できているレベル）


## 本体合流タイミング目処


------------------------
>   発行する前に確認してね！
>    1. タイトルは、[ CH-yyyymmdd-概要 ]となっているか。
>    2. ラベルは、[ Change ]となっているか。
>    3. 回答希望者をアサインしてください。
>    4. 回答希望日を選択してください。
>    5. 急ぎの場合は、Slackで催促してください。

------------------------
>    クローズする時確認してね！

>   ＜対応不要でクローズする場合＞

>    1. 対応不要と判断した理由が記載されているか。
>    2. 関係各位と合意できているか。
>    3. 結果のラベル [対応不要] を設定しているか。

>
>   ＜対応要でクローズする場合＞

>    1. 対応対象機能、またはプログラムが記載されているか。
>    2. 実対応内容が記載されているか。
>    3. 変更対応検討結果が記載されているか。
>    4. 追加発注が必要な場合、必要な手続きが行われているか。
>    5. 関係各位と合意できているか。

進捗管理.md

## 進捗状況（状況はどうか、ボトルネックとなる課題が発生していないか等）


## 課題発生状況

  * 新規発生課題件数：　　件
  * 　　　残課題件数：　　件
  * クローズ済み件数：　　件
 
  * 残課題の状況


## 不具合発生状況

  * 新規発生不具合件数：　　件
  * 　　　残不具合件数：　　件
  *   クローズ済み件数：　　件
 
  * 残不具合の状況


## 進捗遅れタスク（遅れる可能性のあるタスクを含む）

  * 1つ目

　　　         　タスク：
　         　　遅れ理由：
     キャッチアップ方法：
         合流タイミング：

  * 2つ目

　　　         　タスク：
　         　　遅れ理由：
     キャッチアップ方法：
         合流タイミング：

  * 3つ目

　　　         　タスク：
　         　　遅れ理由：
     キャッチアップ方法：
         合流タイミング：


## 依頼事項


## 連絡事項



------------------------
>   発行する前に確認してね！
>    1. タイトルは、[ PR-yyyymmdd ]となっているか。
>    2. ラベルは、[ progress ]となっているか。
>    3. WBS等の資料が添付されているか。

Step3.ラベルを作成する

必要なラベルを作成する。

作成ラベル

• QA
• Bug
• 直接原因-ロジック不良
• 直接原因-データ不良
• 直接原因-環境不良
• 直接原因-ケース不良
• 直接原因-手順不良
• 根本原因-要件/設計誤り
• 根本原因-ルール不徹底
• 根本原因-技術習熟不足
• 根本原因-準備作業漏れ
• 埋め込みフェーズ-要件定義
• 埋め込みフェーズ-基本設計
• 埋め込みフェーズ-外部設計
• 埋め込みフェーズ-内部設計
• 埋め込みフェーズ-PG
• 埋め込みフェーズ-単体テスト
• 埋め込みフェーズ-内部結合テスト
• 埋め込みフェーズ-外部結合テスト
• 埋め込みフェーズ-システムテスト
• 横展開-有り
• 横展開-無し
• Change
• 対応不要
• 対応要
• progress

Step4.利用してみる

起票は簡単にできそう。
あとは、不具合時の分析項目用ラベルのつけ方を統一していくことで、うまく管理できるはず！

もちろん実際に運用してみて、カスタマイズは必要と思われるが、仮運用としては十分。

最後に

2次受け常駐型案件主体の老舗SIerでは、DevOpsやAgileを導入しないといけないと分かっていても、難しい。
DevOps、Agile開発に必要なチケット駆動開発をじわりじわりと導入する為、数少ない持ち帰り開発でGitLabを活用してみる。
あわよくば、開発標準としいつの間にか、チケット駆動開発が主流となる事を期待して…。