Ticket管理ツールを使ってベトナムオフショア開発を成功させる秘訣 | ヒャクテムのブログ

プロジェクト管理ツールやバグ管理システムと呼ばれるツールって、Webシステム開発で必須のツールですよね。

私は最近はJIRAをよく使っています。

ここ7,8年くらいの私の経験プロジェクトでは、Trac -> Redmine -> JIRA みたいな順番で徐々に使うツールが変化してきています。

これらのTicket管理ツール、かなり便利なんですが、「使う側が使いこなせていない」と思う場面に遭遇する事があります。

Ticketで何を管理するのか

どのツールを使っても共通しているのは、
・Ticketを担当者にアサインして管理する
という特性です。
これは、誰が玉を持っているのか管理する。
ということだと思います。
今、このTicket(玉)に対し誰がActionをしなければならないのか、という管理です。

プロジェクトを進める上で、Ticket(玉)にも様々な特性があります。

想定される課題や未検討事項
ステークホルダーへの質問事項
未実施/実施中のタスク
テストで発見されたバグ

などです。
突き詰めて考えると全てタスクなんですが、うまく管理出来ていない事が多いです。

特に、日本側のメンバーがプロジェクトの立ち上げ段階などで起票するTicketは特にひどいケースが多いです。
Ticketがただの備忘録やTODOになっていて、Ticketを見ただけでは結局最終的にどのように処理されたのか、後続タスクはなんなのか、誰に玉が移ったのか、読み取れない事が多いです。
話が繋がっていないのです。ストーリーが無いというか。。
何がひどいか自分なりに整理すると、下記が不明確なんですね。。

Ticketのワークフローが不明確
→ 最終的に誰にTicket(玉)を渡せば良いのか不明確
Ticketクローズの条件が不明確
→ どんな条件を満たせばクローズしてよいか認識が合っていない

日本人チーム内で作業をする際は、定期的にTicketの棚卸しなどを実施してこういった問題をカバーしているケースが多いです。
Ticketをただの備忘録のように使っているので、大体において陳腐化したTicketが大量に発生し、それらをクローズするために、みんなで集まって読み合わせをしながら棚卸して更新するんです。
全くもって無駄ですね。

さらに棚卸しの結果、誰が誰に何を伝えたのかもよく分からない状況でTicketがクローズされることが往々にして発生します。

例えば、
「XXXについて検討する」
というTicketがあり、中身を確認すると
「YYYなのでZZZとする」
と書いてあり、クローズされていたりします。

または、
「XXXについて質問です」
というTicketがあり、中身を確認すると
ステークホルダー：「ZZZとしたいです」
質問者：「承知しました！」
と書いてあり、クローズされています。

え？それって仕様書にもう反映されてますか？
されているならどの仕様書ですか？
という事が分からない。
その結果、Ticket更新者にわざわざ問い合わせて確認する必要があります。
ひどいものになると、結論も記載されていなかったりします。
(おそらく関係者間では、口頭で合意済みと思われる状況。)

この場合は、
「AAA仕様書に記載済み。クローズ。」
と記載するのが好ましいです。
仕様書名も、具体的に記載されているのが良いです。

こういった事は、Ticket管理ツールを使用する上での基本的な事ですが、驚くべきことに全員がキチンと上記のようにTicketを更新してくれているプロジェクトに出会ったことがありません。

大規模開発になり人数が増えると、全員の意識を統一するのが難しいんですよね。Ticket管理ツールに慣れている人もいれば初めて使う人もいる。

ルールをキレイに整理してプロジェクト開始段階で全員に理解してもらうのが一番良いのですが、このルールを整理するのがなかなか難しいのです。

以下、ルールを整理する上での考え方を整理してみます。

考え方１：Ticketの種類はなるだけ少なく

まずは、Ticketの種類を決める必要があります。

JIRAでは「課題のタイプ」、Redmineでは「Tracker」と呼ばれているものですが、プロジェクトごとにどんなTicketの種類を使うのかを決定する必要があります。

Ticketの種類は、なるだけ少ない方が良いです。種類が多いと、それだけ作業者が迷う要素や覚えなくてはならないルールが増えるからです。

Ticketの種類	用途	考え方
Issue	想定される課題や未検討事項	まだ誰も考えていないこと
QA	ステークホルダーへの質問事項	誰かが既に考えていること
Task	定義済みのタスク	実施が必要なこと
Bug	テストで発見されたバグ	対応が必要なこと

これだけあれば十分です。

作業依頼とか、レビューとか、翻訳依頼とか、仕様変更とか、案件とか、いろんなTicketの種類に出会った事がありますが、基本的にすべて実施しなければならない「タスク」です。なので、これらはすべて「Task」として管理すれば良いと思います。

そして、オフショア側の成果物(Output)の作成タスクは、すべて「Task」チケットとして起票して管理します。

曖昧なことや決まっていないことなどは、「Issue」と「QA」に集約します。誰も考えていない（と思われる）ことなら「Issue」ですし、誰かが既に考えている（と思われる）ことなら「QA」です。

考え方２：ワークフローは後から設定すると割り切る

Ticket管理ツールでは、Ticketの種類ごとに異なるワークフローを設定出来るようになっています。

しかし、ワークフローをツールの設定も合わせてキチンと運用するにはそれなりに準備が必要で、大規模開発になるとルールを適用する難易度が高いです。

ツール上のワークフローを設定するということは、アカウントごとの権限管理が必要ですし、また、関係者間でワークフローの調整が終わっていなければなりません。

ですが、プロジェクト立ち上げ段階でこれらを整理する事は現実的に不可能なケースが多いです。具体的な体制も決まっていないような状況でワークフローを定義しても、現実がついてこない事が多いと感じています。

ですので、ワークフローに関しては、まずはツールに頼らずに別途パワーポイントやKeynoteなどで定義するのが現実的です。

「ワークフローを定義しなくて良い」訳では無く、「まずはツールに頼らない」と割り切ることが大事です。「ワークフローを定義する」のはとても大事ですが、現実がついてこないと意味がないので、まずはツールとは別の次元でキチンと関係者間ですり合わせをする方が先決です。

「ツールのワークフローの設定は、作業が起動に乗ってから後から実施する」

と考えたほうが、ツールに振り回されて混乱するリスクが減ります。

実際のワークフローの考え方に関しては後述します。

考え方３：ベトナムオフショア作業者の役割は３つに分ける

ベトナムオフショア開発をスムーズに進める為には、下記４つの役割を立てるのがオススメです。３つはベトナム人の役割で、１つは日本人の役割です。

役割(en)

役割(ja)

説明

Member

メンバー

実際の作業を実施するメンバー（ベトナム人）

各タスクをアサインする担当者であり、成果物をOutputします。アサインされた各機能のOutputに責任を持つ役割です。

TeamLeader

チームリーダー

メンバーをまとめるリーダー（ベトナム人）

メンバーのOutputをレビューし、チームのOutputの品質をチェックします。チームのOutputに責任を持つ役割です。１人のリーダーに対し、５名程度のメンバーを割り当てます。

TaskManager

タスク管理者

進捗管理の責任者（ベトナム人）

各タスクの進捗管理や課題の交通整理を実施します。Outputには責任を持たず、進捗管理と報告に責任を持つ役割です。実力値に応じて複数チームを管理します。

Counterpart

カウンターパート

オフショアメンバーの対面に立つ対応相手（日本人）

オフショアメンバーから問い合わせや相談を受ける窓口となる担当者です。オフショアメンバーへのInputとなる仕様書や要件定義書などを作成した担当者が実施します。

小規模な開発や、ベトナム人メンバーが少ない場合には、上記のように３つに分けるのは難しいかも知れません。

しかし、なるだけ役割を明確にし、タスクを単純化する事によりベトナム人メンバーのパフォーマンスがアップするという特徴があるため、上記のような役割分担にするのがオススメです。

また、Counterpartとのやり取りをするベトナム人は、Leaderのみと決めた方がスムーズです。各Memberと直接QAなどをやり取りしてしまうと、ベトナム側での情報共有がうまくいかなくなるケースが多いです。

考え方４：Ticketのステータスをシンプルにする

Ticketのステータスは、ワークフローとセットです。

Ticket管理ツールとしては、「AAAステータスからBBBステータスに変更出来るのは、XXX権限のユーザーのみ」といった制御を入れることが可能ですが、前述したとおりプロジェクト初期に整理するのは難しいケースが多いです。

TicketのステータスはTicketをアサインされた人が検索しやすいように「〜待ち」のような形式にしているケースもあります。しかし、完璧なワークフローを定義した後で無いとそのようなステータスは使えないです。

なので、「誰がTicket(玉)を持っているのか」だけを識別可能なステータスと割り切ります。そう考えると、下記のステータスがあれば十分です。

QAのステータス

Status(ステータス)	Ticket保持者	ステータスの意味
New(新規)	Leader/Counterpart	新たに登録されたもの。作業は未着手。
Progress(進行中)	Counterpart	担当者が回答中。
Feedback(フィードバック)	Leader/Member	担当者の回答が終了。回答の確認待ち。
Closed(完了)	Leader/Member	作業終了。

「Closed(完了)」のTicket保持者を”Leader/Member”としていますが、これは起票者が”Leader”のケースも”Member”のケースも両方ある為です。

ただし、”Counterpart”へTicketを回すのは、必ず”Leader”経由とした方が良いです。また、”Counterpart”からのFeedback先も、必ず”Leader”にしてもらいます。

その結果、すべてのQAに”Leader”が目を通せる状態にします。

具体的なステータス更新イメージは下記です。

Member/Leaderが「QA」Ticketを作成し、Leaderにアサイン（New）
Leaderが質問を確認し、自分で回答出来ない場合はCounterpartに回す（New → Progress）
Counterpartが「QA」に回答し、Leaderに回す（Progress）
Leaderが回答を確認し、質問者のMember/Leaderに回す（Progress → Feedback）
Member/Leaderが回答に応じてOutputを更新してクローズする（Feedback → Closed）

この例では、”Leader”だけが意識してステータスを更新すれば成り立ちます。

なので、全員がステータス更新を意識する必要がなくなります。

Issueのステータス

Issueのステータスは考え方が難しいです。前述したとおり「まだ誰も考えていないこと」を扱うTicketなので、誰が検討して誰が作業するのか、Ticketの内容によって異なります。

オフショア開発目線でいうと、オフショアチーム内部のIssueはTicketとして扱わない事が多いです。上記の通り、課題により対応内容もさまざまで、Ticketを作成してもスムーズに話が進みません。なので、オフショアチーム内部のIssueは、別途TODOリストとしてExcel等で管理し、対面で日々すり合わせをしながら進めています。

一方、日本側の開発チーム内ではIssueを備忘的に使うことが多いです。ここで、結論や次のアクションが不明確になるケースが多いので、オフショアへの繋ぎが必要であればCounterpartにまわしてもらい、オフショア側へ連携します。

Status(ステータス)	Ticket保持者	ステータスの意味
New(新規)	日本人	新たに登録されたもの。作業は未着手。
Progress(進行中)	日本人	担当者が検討中。
Feedback(フィードバック)	日本人/Counterpart	担当者の検討が終了。次のActionへの引き継ぎ待ち。
Closed(完了)	日本人/Counterpart	作業終了。

Taskのステータス

Taskは、オフショアMemberによるOutputの作成作業で使用します。Outputは、設計書 or ソースコード or テストケース、がメインとイメージしてください。

Status(ステータス)	Ticket保持者	ステータスの意味
New(新規)	Member	新たに登録されたもの。作業は未着手。
Progress(進行中)	Member	MemberがOutputを作成中。
Reviewing(レビュー中)	Leader	Memberの作業が終了し、Leaderがレビュー中。
Feedback(フィードバック)	Member	Leaderレビューが完了し、Memberがレビュー結果の反映中。
Closed(完了)	Member	作業終了。
Rejected(取り下げ)	Member	作業自体が不要になったので取り下げ。

Taskで識別したいのは、下記の３つの状態だけと考えます。

詳細は後述しますが、下記３つの作業が時間がかかる作業であり、見積りが必要な作業になる為です。

「MemberがOutputを作成中」の状態
「LeaderがOutputをレビュー中」の状態
「MemberがLeaderの指摘を修正中」の状態

「Pending(保留中)」といったステータスをよく見かけますが、保留中のTicketが検索出来て嬉しい場面にあまり出会ったことが無いので、除いています。

Bugのステータス

Bugのステータスは、詳細に考えると細かくなってしまいます。

発生したBugによっては、複数箇所のソースコード修正が必要になるケースもありますし、未検討事項が発生することにより仕様書の更新を伴うようなケースもあります。例えば、下記のような作業が必要になります。

発見したBugによる他の箇所への影響調査
影響する仕様書やソースコードの修正
必要であればテストケースの更新
再テストが必要なテストケースの選別
再テストの実施

シンプルに考え、これらはすべて「Progress(進行中)」として扱います。

Status(ステータス)	Ticket保持者	ステータスの意味
New(新規)	Member/Leader	新たに登録されたもの。作業は未着手。
Progress(進行中)	Member/Leader	Leader/Memberが1. 2. 3. 4. 5.を実施中。
Reviewing(レビュー中)	Leader	Memberの作業が終了し、Leaderがレビュー中。
Feedback(フィードバック)	Member	Leaderレビューが完了し、Memberが指摘の対応中。
Closed(完了)	Member/Leader	作業終了。
Rejected(取り下げ)	Member/Leader	作業自体が不要になったので取り下げ。

ステータスのまとめ

ステータスの設計は、真剣に考えれば考えるほど難しいです。チームの体制や状況、担当しているタスク内容などにより最適な解が異なります。

オフショア開発を進める場合のポイントとしては、「ツールに頼りすぎない」事だと考えています。Ticket管理ツールですべてのタスクの進行状況がスムーズに確認出来るようになるのは理想的な状態ですが、前述したとおり体制やワークフローをすべてキレイに整理して、関係者にも共通認識を持ってもらい、かつ、全員がルールを守る必要があります。これは経験上現実的でないケースが多いです。

ですので、考え方３で前述したとおり「TaskManager(タスク管理者)」という役割のメンバーをオフショア側に用意するのがオススメです。ツールで制限するのでは無く、人力で担保するという事です。そうすることで、各Memberが細かいステータスでTicketを検索することが出来なくても、タスクをスムーズに進める事が出来ますし、さまざまな作業上の細かい問題にも柔軟に対処することが出来るようになります。

考え方５：Ticketのクローズ条件

Ticketのクローズ(完了)条件を明確にし、「TaskManager(タスク管理者)」に各Ticketが条件を満たしているかチェックしてもらいます。

「Issue」のクローズ条件

後続のタスクが明確になっている場合は、後続のTicketを作成済みで有ること
後続タスクが不要である場合は、その理由がTicketに記載されていること

「QA」のクローズ条件

回答内容が、然るべき成果物に反映出来ていること
もしくは、回答により発生したタスクが別Ticketとして起票済みであること

「Task」のクローズ条件

別途定義されたTaskの完了条件を満たしていること

「Bug」のクローズ条件

本Bugに対する修正／再テスト等のすべての作業が完了していること

まとめ

Ticket管理ツールでは、「Ticket(玉)に対し誰がActionをしなければならないのか」のみを管理すると考えて、細かいステータス制御は行わない。
Ticket管理ツールのワークフロー設定機能には頼らず、「TaskManager(タスク管理者)」という役割のメンバーをオフショア側に用意する。
各タスクのワークフローはTicket管理ツールとは別の次元で明確にし、「TaskManager(タスク管理者)」に進捗状況を管理してもらう。
Ticketクローズの条件を明確にした上で、「TaskManager(タスク管理者)」に人手でチェックしてもらう

実際のワークフローについても書こうと思ったのですが、長くなりすぎたので別途記載します。