TimeTracker NX開発チームのプロジェクト管理事例を大公開 【前編】 ～タスクアイテム管理をどうやってるの？～
デンソークリエイトの社内ツールでもあるTimeTracker NX。
TimeTracker NXの開発現場では、どのようにTimeTracker NXを活用しているのでしょうか？
今回は、弊社開発チームのTimeTracker NX活用例や管理事例を大公開します。
本稿はプロジェクト管理に関する弊社事例紹介として
・どのようにプロジェクトを作成しているのか？
・プロジェクトの中身（WBS）はどのような構成なのか？
・どのようにアイテム管理をしているのか？
上記に関して「STAR」と呼ばれるインタビュー手法を用いて、 Situation（状況） 、 Task（課題） 、 Action（行動） 、 Results（結果）別にヒアリングした内容をお伝えします。
特にAction（行動）の章では、具体的な運用事例を紹介しますので、ご一読いただければ幸いです。
------------------------------------------------------------------
取材対象者： TimeTracker NX開発PM Kさん
開発チームをまとめるデンソークリエイトのエース。
■Situation（状況）：チームや開発現場について教えてください
「Kです。TimeTracker NX開発のPMをしています。私たちチームの事例が皆様の一助になれば幸いです。
現在、チームは15名です。2班に分かれて、担当領域における機能開発・改善などを行っています。
各班のリーダーがメンバーの細かなマネジメントを行います。
私は主に開発プロジェクトの進捗やリソース管理を行っています。
チームのミッションはTimeTracker NXの開発です。
常に市場の声やお客様の要望に合わせて、柔軟に開発することが求められます。
誰かが仕様書をつくってくれるわけではないため、チームの中で「答え」をつくっていくことが求められます。
開発手法はアジャイル開発の「スクラム」を採用しています。開発チームで使用している*プロジェクトは「開発用」と「企画管理用」の2種類です。
開発用プロジェクトに対して10～16の*パッケージを作成し、それを「スプリント」と呼んでいます。
各スプリントの期間は4週間固定で区切っています。
スプリントは、企画管理用プロジェクトで管理されている「バックログ」から開発する 機能を決定しています。
この点は、Actionの章で詳しくお話しますね」
■Task（課題）：現在の管理手法に至った背景を教えてください
「アジャイル開発の「スクラム」を取り入れたのは3年前です。
以前は、開発すべきアイテム（機能・仕事内容）を詰め込むだけ詰め込んで製品リリースに時間を要してしまうことが課題でした。
お恥ずかしい話ですが、開発アイテム（機能・仕事内容）だけが雪だるま式に膨張して、完了できない「永遠の進捗率90％」に陥ることもしばしば起こったのです。
ユーザーファーストで開発をしているため、お客様の声を反映しながら「これをやろう」「これはやめよう」など柔軟に対応することが現場には求められます。
そのため、
・開発アイテムを記述しよう（仕事の明確化）
・開発アイテムを制御しよう（必要なことをやる）
・迅速に開発しよう（スピードアップ！）
という点をテーマとして、現在の管理方法に取り組みました。」
■Action（行動）：どのようにプロジェクト管理を行っていますか？
「はい。開発PMとしては、ユーザーの皆さまに一番お伝えしたい箇所です。
TimeTracker NX開発チームによるTimeTracker NXの運用事例紹介ですね(笑)。
【プロジェクト管理のメソッド】
前段述べた通り、開発チームで使用しているプロジェクトは「開発用」と「企画管理用」の2種類を作成しています。
・企画管理用プロジェクト
バージョンに限らず製品全体の要望・市場ニーズ・機能開発の優先順位を管理しています。
製品開発時は、このプロジェクトで管理されている「バックログ」から開発する機能を決定すします。
この企画管理用プロジェクトを常に最新の状態に更新し続けることで、機能開発の優先順位をメンバーと共有します。
・開発用プロジェクト
リリースのバージョン毎に1つのプロジェクトを作成し、企画からリリースまでを管理を行います。
スプリントを一つの区切りとして、PDCAサイクルを回します。
各スプリントは、要件定義、開発、テスト、評価まで完結させることをルールとして、期間は4週間固定で区切っています。
*プロジェクト（企画管理用）：「★Backlog」の直下には具体な機能要望アイテムを格納する
*プロジェクト（開発用）：「Sprint 」直下には具体的な開発アイテムを格納する
【パッケージの管理メソッド】
企画管理用のプロジェクトでは「バックログ」というパッケージを開発用のプロジェクトでは「スプリント」というパッケージを作成しています。
各パッケージは異なる管理項目や目的を持っています。
また、メンバーの入力負荷をさけるため開発用のプロジェクトの「スプリント」内のアイテムだけを主なタスク管理・工数管理の対象としています。
「バックログ」内には構成アイテムを記述しています。
・機能要望や開発アイテムの一覧を作成する
・機能要望や開発内容をアイテム作成ルールも記述する
・「実施済み」であるかを確認する
「スプリント」の記述ルールや構成は以下です。
・1スプリント4週間で区切る
・1スプリントに入れるアイテムの件数上限を決める
・バックログを参照し、アイテムを作成する
*パッケージ「バックログ」と*アイテム
*パッケージ「スプリント」と*アイテム
【アイテム管理のメソッド】
「スプリント」のアイテムには管理する内容に応じてルールや入力項目を定義しています。
・1アイテム1担当とし、リソースの未割り当てがないようにする
・「要求」「不具合」「仕様変更」「レビュー」「リリース」など管理内容ごとにアイテムタイプを変え、入力内容をアイテムタイプごとに定義する
・アイテムごとにステータスを細かく定義する
アイテムタイプを複数もちいることで、仕事の目的にあった管理をすることができるのでアイテムタイプ機能は重宝しています」
アイテムタイプとアイテムタイプに紐づく管理項目（アイテムプロパティ）の例：アイテムタイプごと入力する管理項目を変えてることができるため多様な管理をプロジェクト画面上で行うことが可能となる。
■Results（結果）：現在のプロジェクト管理での効果や得たものは何ですか？
「まず、製品開発現場でTimeTracker NXを利用するメリットをお話すると
プロジェクト＞パッケージ（バックログ・スプリント）＞アイテム（要求など）管理項目や粒度の異なる情報を同じツール上で管理できることが利点です。
「要求管理」「不具合管理」「タスク管理」「工数管理」など異なるマネジメントをTimeTracker NXで完結することができます。
管理したい内容を入力でき、すぐに見えることは、アジャイル開発の「スクラム」にもマッチしています。
「スクラム 」に変えたことで、開発アイテムを制御することに成功しています。
スプリントを区切ることでアイテムの量をコントロールし、できない仕事に溺れることなく、納期遅延を抑止することができ、アイテム（仕事）の完了までもっていくことができることは大きな価値ですね」
------------------------------------------------------------------
■次回予告
今回のインタビュー内容はここまでです。
次稿では、アイテムのステータス管理に関して触れつつ、各メンバーの工数管理事例に関してご紹介し、具体的なマネジメントの根幹に迫っていきます。
まだ、TimeTracker NXのことをもっと知りたいという方は、製品資料もぜひお手に取ってください。
*用語説明
プロジェクト：TimeTracker NX上で管理する仕事の集合体 管理する大きい粒度の情報を指す。
パッケージ：TimeTracker NX上のプロジェクトに属するWBSの構成要素、仕事の集合体を指す。
アイテム：パッケージもアイテムのひとつであるが、インタビュー中には、パッケージを構成する具体的な仕事内容・作業名などを指す意。