Agileツール適合化分科会（issue tracking system）

1Copyright (C) Masanori Kataoka All Rights Reserved.
チケットベースの進捗管理システム
ITS(Issue Tracking System)
～Redmine, GitHub Issueを中心として～
２０１５年６月２３日
片岡雅憲
2015/6/24
1
Agileツール適合化分科会（第５回）資料

１．プロジェクト進捗管理とITS
２．BTS/ITSの歴史
３．アジャイル開発とITS
４．ITSにおける電子化情報の共有
５．アジャイル開発におけるRedmineの活用
６．Redmineと関連ツールとの連携
７．GitHub IssueによるITS機能
＜付録１＞ ITSベース開発のプラクティス
＜参考文献＞
＜内容＞

１．プロジェクト進捗管理とITS
アジャイル開発では、短期間のイテレーションを繰り返すことにより開
発がすすめられる。開発対象の機能はストーリーと呼ばれる小さな機
能に分割され、その開発が各イテレーションに割り当てられる。ストー
リーは、ストーリーカードあるいはチケットに対応付けられてストーリー
IDあるいはチケットIDにより管理される。
システムの運用中に検出された不良あるいは課題に対してチケット
が発行され、チケットＩＤにより進捗が管理される。
このようにアジャイル開発では、新規開発項目も不良もその他の課
題もIDを付与された課題として管理される。ITS(Issue Tracking
System)とは、このようなID付きの課題を管理することにより、プロジェ
クト管理を行うシステムのことである。
アジャイル開発では、多くの作業において自動化ツールを活用してい
く。その作業および作業対象・成果のすべてがこの課題IDと対応付け
られる。ITSは、このIDにより各種の自動化ツールと連携してプロジェク
ト管理の効率化を支援する。

2.1 BTS/ITSの歴史
BTS(Bug Tracking System)/ITSの歴史を以下に述べる。
１） Bugzilla：インターネットWebの草分け的存在であったNetscape
Navigator(Firefoxの元になっている)が内部で利用していたものを
1998年にOSS化したものがベースになっている。BTSの先駆けで
あり、世界中で広く活用されている。プロジェクトの特性に応じ様々
な属性を管理でき、例えば、カテゴリー別、コンポーネント別にバグ
を整理出来る。
２） Trac ：プロジェクト管理及びバグ管理のためのOSSである。バグ管
理に限定せずに広く課題管理に利用されるために、ITS(Issue
Tracking System)と呼ばれることもある。SVN, Git, Mercurial など
のバージョン管理システムとも連動する。また、TestLink等のテスト
支援システムとも連動する。すなわち、Trac は、広く課題管理に利
用でき、他のテスト関連支援ツールと連動することに特徴がある。
2003年に登場した。wikiをベースにして開発されている。

2.1 BTS/ITSの歴史（続き）
３） Mantis ：変更管理システムの機能を統合した小規模プロジェクト
向けのBTSであり、OSSである。多様なレベルの人（素人でも）が使
えることを目指していて、多様なOS上で稼働する。日本人
（Kenzaburo Ito）が開発者であり、主として日本で使われている。
2000年に登場した。
４） JIRA ：Atlassian社製のプロジェクト管理及び課題管理システムで
ある。 SVN, Mercurial, ClearCase などのバージョン管理システム
とも連動する．非営利団体に対しては、無料で提供されていること
から、多くのOSSプロジェクトで利用されている。Java言語で記述
されている。（注）JIRAの発音は「ジラ」
５） Redmine ：Ruby on Railsで作られたITSで、OSSである。Tracより
も新しく、豊富な機能を備えている。複数プロジェクトを扱うことが
出来る。また、極めて拡張性に富んでいて。他の関連ツールとの
連携が容易な仕組みになっている。2006年に登場した。

2.1 BTS/ITSの歴史（続き）
６） Pivotal Tracker:アジャイル開発専用のITSであり、用語もアジャイ
ル用語を用いている。アジャイルプロジェクト対象に、急速にユー
ザー数を伸ばしている。特徴は次の通り。日本語化されていない。
①アジャイル開発管理をWebサービス化（インストール不要）
②入力項目が少なく、シンプルなワークフロー
③Webブラウザで、ドラッグ＆ドロップで操作できる高い操作性
④外部APIから操作可能
⑤公共機関、非営利団体、個人利用、教育機関の場合無償で
利用可能
７） GitHub Issue: GitHub専用のITS機能。Redmine, Tracなどの
Issue管理専用ツールに負けない機能を持つ。これらのIssue管理
専用ツールよりも軽量で使い易いという人もいる。アジャイル開発
との親和性が高い。

2.2 BTSとITS
BTSは、2.1 で前述したように、ソフトウェアの不良の解決のための
管理システムとして発展してきた。
一方、ITSの方は、元々はコールセンターの課題追跡・管理システ
ムとして発展してきたものである。問い合わせ、クレーム、不良対策
等、様々な案件の発生から解決までの処理状況を追跡・管理するた
めのシステムである。
このように考えてみると、ソフトウェア開発においても、追跡・管理す
べきはバグだけでなく、機能追加要求、機能変更要求、問い合わせ
等、多様な課題が起こりうる。特に、アジャイル開発においては、この
ような変更を積極的に受け入れることを方針にしているためにITSが
必須となる。アジャイル開発では工期が短いためにプロジェクト管理
も自動化することが必要であり、ITSの活用が欠かせない。

アジャイル開発とITSは、元々は別の概念に基づいて生まれたもの
である。アジャイル開発はITS無しでも実現できるし、ITSはアジャイル
開発だけでなくWF開発にも貢献できる。
しかしながら、アジャイル開発とITSは非常に相性が良い。この両者
を組み合わせることにより、大きな効果が期待できる。
3.1 イテレーションの管理
アジャイル開発においては、イテレーションを中心にして作業が進
められる。イテレーションは開発対象ソフトウェアのバージョンと対応付
けられる。イテレーションは、ストーリー対応の作業で構成され、これは
チケットで管理される。すなわち、
version－iteration－story(ticket)
の対応管理が重要である。これにより次のような改善が実現出来る。
１） No Ticket, No Commit (チケット無しにコミット無し）。ソースコード
変更のコミットに必ずチケットが要求される。従って、ソースコードの
コミット単位が明確になり、目的が異なる修正による競合が防げる。

3．アジャイル開発とITS
3.1 イテレーションの管理（続き）
２）チケットにより、開発内容、変更内容の管理が容易になり、集計等
の作業管理を合理化することが出来る。
３）あらゆる作業がチケットにより管理される。したがって、作業メンバ
の作業内容がチケットIDにより正確に把握される。例えば、毎朝会
議での昨日の進捗状況や今日の作業予定はチケットIDで報告、
管理することにより、正確で迅速な管理が出来る。
４）チケットをキイとして、変更歴管理ツール、テスト支援ツール等との
連携の自動化が推進される。これにより、指標(Metrics)ベースでの
作業の「見える化」が徹底される。

3.2 イテレーションの内容の見直し
アジャイル開発では、イテレーションを単位として開発サイクルを
繰り返す。
イテレーションは、開発期間と工数（コスト）が固定になっていて、
サイクルを回すリズムを作り出す。
そして、このリズムを壊すことなく、イテレーションの内容を見直しな
がら開発が進めれる。
１）イテレーションでの開発項目の優先順位が見直される。この見直
しにおいて、チケットを単位とした開発順位の入れ替えを行うことが
出来る。
２）アジャイル開発は、既存の部品、パッケージ、フレームワークを活
用して行われることが多く、開発を始めてみて問題に遭遇すること
が少なくない。変更は高頻度になりがちであり、チケットによる管理
が極めて有効である。

3.3 変更歴管理と並行開発
アジャイル開発では、一つのイテレーションが終了すると、その成果
をリリースし、また、もう一方では次のイテレーションにとりかかり
並行開発が行われる。Subversion, Git等の変更歴管理ツールでは、
リリースしたイテレーションをブランチで、次のイテレーションを
トランクで扱う。そして、次のイテレーションのリリース時に、旧ブラン
チはトランクにマージされる。
変更歴管理ツールは、このようなブランチの作成やトランクへの
マージを容易に支援するものでなくてはならない。そしてまた、これら
の作業が高頻度で行われるために
「チケットIDと変更管理タグを対応付ける」
ことが作業効率と確実性を着実に改善する。

3.4 バックトラッキング
アジャイル開発では、既存の部品、パッケージ、フレームワーク等を
ベースに開発することが多い。このために、WF開発と違って
「下流工程から上流工程へと作業が遡る（バックトラッキングする）」
ことが少なくない。
すなわち、上流では定義されていなかった多様な作業が下流で発
生し、結果として上流にも影響を与える。このことが、結局はイテレー
ションの内容や既存の作業に変更を強いることになる。このような
バックトラッキング作業はチケットで管理するのが適している。すなわ
ち、極めて動的な変更を伴うアジャイル開発の作業管理に適している。

アジャイル開発の本質は、高速開発、共同開発である。そこでは、
電子化された情報の共有が重要な役割を演じる。
ITSでは、チケットをキイにして、ソフトウェア開発に関するあらゆる情
報を電子的に統合管理する。これにより、プロジェクトの関係者が情報
をリアルタイムに共有することが出来る。最近では、ソフトウェア開発に
おいて分散型開発、更にはオフショア開発を行うことが一般化してきて
いる。このような状況下でITSは、その強みを発揮する。
ITSで共有される電子化情報として次の３通りがある。
① チケットそのものに記述された情報
② チケットからリンクされたドキュメント
③ チケットに付随したチャット
上記のうち①のチケットそのものに記述する情報は簡潔にすることが
望ましい。複雑な記述は、②のように別のドキュメントとして記述して、
チケットからリンクするようにすべきである。

チケットからのリンクで添付するドキュメントはどのような形式のもの
も自由にするべきである。例えば、バグに対応するチケットでは、不良
が検出された画面を添付することにより、不良の内容が的確に伝えら
れることになる。
また、プロジェクトやチームで共有する規則や規格等を共有ドキュメ
ントとして管理することも効果的である。記述形式をwiki形式に標準化
してチーム全員で共有・保守する。その変更時には、そのことが共有
者全員にリアルタイムで報告される。異なるバージョンのドキュメントを
各人が保有するよりもはるかに合理的である。Wikiは、その用途ごと
の方言が用いられている。例えば、RedmineではＴｅｘｔｉｌｅ記法を、
GitHub IssueではGFM(GitHub Flavored Markdown）記法を用いて
いる。
前記③のチャットをチケットと共に用いるのも有益である。関係者間
の意見交換がリアルタイムに出来て、チケット処理を加速化する。いわ
ば、ITSとSNSとの融合による機能を活用することになる。

5.1 Redmineとは
Redmineは、BTS(Bug Tracking System)あるいはITS (Issue
Tracking System)の代表的な存在として活用されているシステムであ
る。すなわち、課題あるいはバグについてその発生から解決までの処
理状況を追跡する。
ITS/BTSは、WF、アジャイル開発の両方において必要とされるが，
管理の迅速性が大切なAgile開発においては必須のものとされる。ア
ジャイルの繰り返し開発サイクルを、優れたリズム感を持って、着実に
進めて行くために欠かせないツールとなっている。ITS/BTSの発展の
歴史を経て、現在では、Redmineがもっとも使われている。
Redmineは、Rubyで記述されているが他の言語を用いるプロジェク
トにおいても利用可能である。拡張性に富み、他の関連ツールとの連
携機能も豊かである。

5.2 Redmineを用いたアジャイル開発フロー
Redmineは、アジャイル開発のための中核的な作業管理システムと
して用いられる。図5.1は、その運用フローを示したものである。ここに
見られるようにRedmineは、ソフトウェア作業管理用のワークフローシ
ステムであると言うことが出来る。
１） PL(Project Leader)は、新しいバージョンを開始するに当たって、
これをRedmineに登録する。
２） PLは、新しい作業を始める際に、そのためのチケットを作成して、
これをRedmineに登録する。
３） PG（担当者）は、チケットに基づいて作業を行い、それが完了した
ら、その旨をRedmineに登録する。
４） PLは、そのバージョンを構成する全てのチケットの完了を確認した
ら、そのバージョンをリリースする。Redmine上では、そのバージョ
ンはクローズ（閉鎖）される。

5.2 Redmineを用いたアジャイル開発フロー（続き）
５）開発チームは、バージョンが完了したところで、Redmineのデータ
を集計表示して、そのバージョンの振返り会議(Retrospective)を
実施する。そして、改良すべき点があれば、次のバージョンにその
改良案件を送る。
６）ユーザは、リリースされたバージョンを試用して、あるいは、
Redmine上の情報を問合わせ・分析して、不良を検出した場合、
あるいは改善要望がある場合は、それを次のバージョンでの
対応案件として送る。

Redmine
バージョン作成
バージョンを
リリース
チケット作成
チケット解決
改善要望・
障害発生
バージョン振返り
PL(Project Leader)
チケット更新
PG(担当者)
バージョン管理
バージョン
をクローズ
集計表示
ユーザ
開発チーム
問い合わせ
次バージョンへ
図5.1 Redmineを用いたアジャイル開発フロー

5.3 Redmineのチケット管理
Redmineのチケット管理は、BTS用からITS用へと発展させたもの
である。その概要は、次に示すとおりである。
１）チケットとは何か
Redmineのチケットは、ITSとしての案件（Issue)を管理するための
「作業管理票」の役割を持っている。
BTSでは①バグ管理が作業の中心であったが、
ITSでは、その他の ②問合わせ ③設計 ④開発 ⑤リリース等
の全ての作業が対象となる。
また、これらの作業に関連する仕様書、コード等はチケットからリン
クされる。
したがって、チケットの概念には、アジャイル開発でのストーリー
カードやタスクカードの概念が包含されている。

5.3 Redmineのチケット管理（続き）
２）チケットの粒度
アジャイル開発に適用することを考えれば、チケットの作業粒度
は、イテレーション（2~4week)よりも、十分に小さくなくてはならない。
具体的には、半日～５日位に細分化される必要がある。そして、
RedmineのTime Trackingを用いてチケットの進捗状況を管理する
ことが出来る。
３）非機能案件はチケット管理の対象となるか
アジャイル開発では、顧客に見える機能に基づきチケットを管理す
るのが原則である。しかし、大きなプロジェクトになれば、複数機能に
またがる共通内部機能、性能評価、ビルド等の非機能作業の比率が
高くなる。これらは「内部機能」「その他」等のタグを付けたチケットで
管理するのが得策である。

４）チケットの主要な管理項目（作業の性質により使い分ける）
a) トラッカー：チケットの種類（バグ、機能、サポート）
b) ステータス：チケットの作業状態、管理画面で設定。
c) 優先度：チケットの優先順位、管理画面で設定。
d) 担当者：作業の担当者、プロジェクト設定画面で設定。
e) カテゴリ：システムの機能やコンポーネント。
f) バージョン：リリースするバージョン。
g) 開始日、終了日：作業の開始日、終了日。
h) 予定工数：見積もり工数、時間単位。
i) 進捗：作業の進捗率。
j) 作業時間：実績工数、時間単位。
k) 作業分類：作業の種類。例えば、設計、テスト、レビュ等

５）ステータス管理
トラッカー（バグ、機能、サポート）の区分ごとにステータス（状態）が
定まり、ワークフローも定まる。例えば、バグ（障害）管理チケットのス
テータスは次のとおり。
a) 新規（New):障害の発生を受け付けた、担当者を割当て。
b) 担当（in Progress):担当者が原因究明中。
c) 解決(Resolved)：障害の原因が判明、対応作業が終了。
d) フィードバック(Feedback)：確認作業で問題が発生、
再度、対応作業を行う。
e) 終了(Closed)：確認作業が完了。
f) 却下(Rejected)：仕様通りの動作であったなどの理由で
対応せずに終了。

６）ロールとワークフロー
プロジェクトを開始するに当たって、最初に「ロール（役割）」と
「トラッカー（作業分類）」を定める。
・ロールのデフォルト：管理者、開発者、報告者
・トラッカーのデフォルト：バグ、機能、サポート
ロールとトラッカーが定まると、その組み合わせに対応したチケット
のステータスが決まり、ステータス間の状態遷移としての「ワークフ
ロー」が定まる。

5.4 Redmineでの階層構造管理
プロジェクトがある程度以上の大きさになった場合には、プロジェク
トの階層構造を管理し、Redmineでの管理もこれに対応しなければ
ならない。階層分割自体は、WBS (Work Breakdown Structure)等
の方法（注）によるとして、Redmineでの階層構造は次のように
管理される。
プロジェクトーサブプロジェクトーバージョンーチケット
もしも、上記で階層が不足する場合は、次で対処出来る。プロジェ
クトが大きくなった場合は、①を進める必要がある。
① サブプロジェクトに階層を持たせる（Redmine0.9以降）
② チケットを階層化（Redmineのsubtasking機能）
（注）組織―その成果物―成果物を実現するタスクを管理。

5.5 Redmineによるバージョン管理と並行開発管理
新しいバージョンをリリースした場合には、このリリースに対応した
ブランチを作り、リリースに関連する更新はこのブランチで行う。
継続する次期のバージョンは、トランクで開発する。そして、ブラン
チは、次期バージョンがリリースされる時にトランクへマージされる。
このようにして、並行開発が管理される。
ブランチとしては、次のものがある。
① リリースブランチ：上記で説明済み
② リリース準備ブランチ：リリース準備作業が大きい場合
③ ベンダーブランチ：第３者のソースをトランクと別に管理
④ タスクブランチ：メインへ大影響を及ぼす変更に対応
⑤ トピックブランチ：分散開発においてチケット対応開発

6.1 関連ツールとの連携
アジャイル開発では、Redmineが中心に、次のツールと連携する。
１）変更歴管理ツール：Subversion等の変更歴管理ツールと連携して、
チケットと変更内容を対応付ける。
２）ビルドツール、CIツール：Maven, Rake, Jenkinsなどのツールと
連携して、チケットとビルド、CIの生産物とを対応付ける。
３）テスト管理ツール：TestLink等のツールと、テストの状況、テストの
結果についての情報を共有する。
４）チケットのCSVインポート：Redmineの外部で作られたチケットの
内容をCSV形式で一括してRedmineに取り込む。
５）上述したようにツール間で次のように作業分担し、かつ連携する。
―Redmine: チケット番号を含めたアジャイル開発作業の管理
―Subversion: リビジョン番号を含めたソースコード変更歴の管理
―Jenkins: ビルド番号を含めたビルド作業とその成果物の管理
―TestLink:テスト作業の進捗状況の管理

6.1 関連ツールとの連携（続き）
７）以上のツール間の連携の結果、次のような関連付けが実現されて、
総合的なプロジェクト管理が可能になる。
ストーリー－チケット－ソースコード－ビルド－テスト
（機能）
or バグ

6.2 REST API
Redmine1.0.1（２０１０年８月リリース）でサポートされた新機能とし
て、REST(Representational State Transfer)APIがある。これは、他
のツールとRedmineとの間で情報を授受することを可能にする機能
である。例えば、ビルドの結果、テストの結果をRedmineに連絡する
ことが出来る。
この機能により、Redmineでソフトウェア開発に関する全ての情報
を一括管理して、Redmineをソフトウェア開発管理の中核ツールとし
て機能させることも視野に入りつつある。

6.3 Redmine対Trac
ITSとして、Tracは２００４年にリリースされ、着実にユーザ数を伸ばし
ていった。一方、Redmineは、２００６年にリリースされ、Tracよりも後
輩である。しかし、Redmineは急速にユーザ数を伸ばし、２００９年か、
２０１０年にはTracのそれを抜いたと言われる。
Redmineは、Tracと比べて次の点で優れている。
１）ユーザインタフェースが全てWebベース（Tracは一部、コマンド
インタフェースを使わざるを得ない）
２）複数のプロジェクトを管理可能（Tracは複数は不可）
３）Subversion以外の多様な変更歴管理システム（例えば、CVS,Git
他）に対応している（Tracは当初Subversionのみに対応し、その後
Git等への対応を拡大した）

6.4 Redmine対新興ITS
以上に見てきたように、ITS分野においてRedmineは先輩を追い抜
き、先頭を走っている。しかし、クラウド化が進展する中で新興のITSが
ユーザー数を急速に伸ばし、Redmineを追いかけている。
１）Redmineは、汎用的なITSツールであり、その概念も用語もＩＴＳに
適合するようになっている。この点において、アジャイル開発で用いら
れる用語とずれがある。
２） Pivotal Tracker, GitHub Issue などの新興ツールはアジャイル専
用に開発されており、概念も用語もアジャイルに合わせてある。
３）新興ツールは、操作性において直観的で簡易である。
４）新興ツールはクラウド上のWebサービスとして実現されており、イン
ストールをすることなく容易に利用が開始できる。
５）現時点においては、機能的にはRedmineの方がカバレッジが大き
い。しかし、新興ツールも急速に機能を充実してきており、今後の経
緯を着目していく必要がある。

7.1 GitHubサービスの概要
GitHubは、Gitを利用するプロジェクトのためのホスティングサービス
である。GitHubは、Logical Awesome社が運営しており、2008年から
サービスが開始された。
GitHubを利用すれば、設備の準備に気を使うことなく、グローバルな
分散開発が出来る。このために、Eclipse等の多くのOSSプロジェクト
がGitHubに移行していて、現状ではOSSプロジェクトの半数を超えて
いるという。OSSプロジェクトは、GitHubを無料で利用出来る。
主要なOSSプロジェクトがGitHubに移行していること、また、GitHub
専用の最新ツールが拡充されてきていることから、GitHubは新しい世
界標準としての地位を獲得しつつある。
Gitは、コマンドベースのツールであるが、GitHubでは、Gitインタ
フェースを内部に隠ぺいし、全てをWebインタフェースで利用できるよう
にしている。

7.1 GitHubサービスの概要（続き）
GitHubが提供している主な機能は次の通りである。
１）Organizationアカウント
GitHubをグループで利用することが出来る。ソースコード情報だけ
でなくイベント情報や管理情報もグループで共有できる。
２）Issue管理機能
バグや改善要求などの課題とその処理状況をIssueとして管理する。
Redmine, TracなどのIssue管理専用ツールに負けない機能を持つ。
これらのIssue管理専用ツールよりも軽量で使い易いという人もいる。
３）Pull Request機能
機能追加やバグ修正などの結果をGitHubリポジトリに登録（push)
したものを、他の開発者が取り込む（pull)ための要求を発行する。
この機能によりGitHubでは、いわゆる「ソーシャルコーディング」が可
能となる。

7.1 GitHubサービスの概要（続き）
４）hubコマンド
Gitコマンドをラップしてさらに高度の機能を付け加えて使い易くした
CLI(Command Line Interface)機能である。Git + hub = GitHub と
の説明がされているように、GitHubの代表的な機能である。GitHub
では初心者はGUIを、上級者はCLIを利用するものと想定している。
５）Git Flow機能
リリースを中心に据えたバージョン管理を支援する（図7.1参照）。
図7.1における各ブランチは次の役割を分担している。
①master:常に正常に動作する状態のブランチ
②develop：開発の中心となるブランチ。開発者がこれを直接に更新
することはなく、featureブランチからマージする。
③feature: developを起点としてfeatureで開発作業を行う。
④release: リリース用のテストとバグ修正を行い、masterにマージ
⑤hotfixes: 運用中に検出されたバグの修正、確認を行う

図7.1 A successful Git branching model （参考文献7)を参照）

7.2 GitHub Issue機能
GitHub Issueは、GitHub内のITS機能を提供するものである。
Redmine のように独立したITSではないのでコンパクトに作られていて、
GitHubとの連携機能に優れている。
以下では、GitHub IssueのITSとしての基本的な機能は省略し、特徴
的な機能について紹介する。
１） Issueに関する文書をwikiの一種であるGFM(GitHub Flavored
Markdown）記法で記述する。修得し易い標準記法になっている。
２） Issueに分類わけのラベルを張り付けられる。分類わけは各プロ
ジェクトで自由に設定できる。色分けが出来るので、どの分類に属
するのかが一目で分かる。また、ラベルごとの選別検索が出来る。
３） Milestoneが設定できる。これにより Issueの日程管理が出来る。
４）このIssueを、チームメンバーのだれに割り当てるかを選択するこ
とが出来る。

7.2 GitHub Issue機能（続き）
５） Pull Request 機能と連携する。Pull Request 機能は、GitHubの
代表的な機能の一つであり、いわゆるチームコーディング、ソー
シャルコーディングを可能とする。すなわち、プログラマーが一人で
コーディングの完成を判断するのでは、チームで、あるいはプログ
ラマーコミュニティーの助けを借りて、コーディングを完成していく。
GitHubは、Pull Requestが発行されると同時にこれに対応した
Issueを発行して、このPull Requestがどのように処理されているか
をフォローしていく。
６）チャット機能と連動する。例えば、Gitterというチャット機能をIssue
機能と一緒に用いることにより、関係者がリアルタイムで連携しな
がらIssueの処理を加速化することが出来る。

ITSベースの開発における重要なプラクティスを、以下にあげる。
P1: チケットファースト
チケットが全ての作業の入力となる。逆に、チケットを見れば、
どのような作業が行われているかが分かる。
P2: 分割統治（Divide and Conquer)
複雑な作業は、より小さな単純な要素に分割して統治することが
大切である。次の３つの観点がある。
P2.1: チケットで分割統治（機能分割他）
P2.2: イテレーションで分割統治（バージョン分割他）
P2.3: プロジェクトで分割統治（サブプロジェクトに分割他）
P3: チケットはシンプルに
チケットの入力項目やワークフローはシンプルに。
P4: No Ticket, No Commit ! （チケット無しに、コミット無し）
修正、追加の意図が不明なコミット（コード変更）は認めない。

P5: ペア作業(Pair Work)
Redmineのワークフロー機能を使って、一つのチケットは、原則
的に二人の関与を経由して完了させるようにする。これにより作業
の信頼性を上げる。
P6: 小規模リリース
小さいサイズで、短いサイクルで、小刻みなリリースを進める。
P7: 棚卸し
休眠チケットが無いか、チケットを統合した方が良くないか、等を
棚卸しする。特に、大規模プロジェクトでは重要である。
P8:見える化
ITSベース開発では、チケットがプロジェクト全体の情報のハブに
なっている。チケットを中核のキイとして、プロジェクトに関するどの
ような情報も「見える化」していくこと。

P9: 朝会
コミュニケーションの場としての朝会には、次の３つの役割がある。
チケットをキイとして、これらの作業を管理する。
－各メンバーのその日のタスクを全員で確認する
－直近のリリース予定を全員で確認する
－隠れ作業等、問題点やリスクを摘出する、嗅ぎ取る
P10: 振り返り（Retrospective)
リリース後の反省会。K（良かったので続けること）、P（悪かったの
で止めること）、T（試したいこと）を明確化。

１） “Continuous delivery: reliable software releases through build, test, and
deployment automation” Jez Humble, David Farley 2010 Addison-Wesley
２） “The ThoughtWorks Anthology-Essays on Software Technology and
Innovation” R. Singham, M. Fowler, et al.2005 by O’Reilly「ThoughtWorks
アンソロジー」（訳）オージス総研２００８年オライリー・ジャパン
３）「Redmineによるタスクマネジメント実践技法」（著）小川明彦、阪井誠
２０１１年１月翔泳社
４）「入門 Redmine 第２版 Linux/Windows対応」（著）前田剛
２０１０年８月秀和システム
５）「いまアツいアジャイルプロジェクト管理ツール9選＋Pivotal Tracker入門」
佐藤聖規, 岡本隆史２０１２
http://www.atmarkit.co.jp/ait/articles/1205/14/news150.html
６）「Git&GitHub入門」岡本隆史、大塚弘記（著） Software Design ２０１５年
６月号技術評論社
７） “A successful Git branching model” By Vincent Driessen Jan 2010
http://nvie.com/posts/a-successful-git-branching-model/
８）「GitHub実践入門」大塚弘記（著）２０１４年技術評論社

Agileツール適合化分科会（issue tracking system）

Recommended

Recommended

More Related Content

Similar to Agileツール適合化分科会（issue tracking system）

Similar to Agileツール適合化分科会（issue tracking system） (20)

More from masanori kataoka

More from masanori kataoka (14)

Agileツール適合化分科会（issue tracking system）