tracpath によるプロジェクト管理は、ガントチャートやWBSなどの管理者向けに開発されたツールではありません。開発チームにとって生産性向上と効率化するための仕組みを持った開発現場のためのツールです。

そのため、予算の管理、人材管理のための機能はありません。しかし、開発者や開発チームに必要なプロジェクト管理機能とソースコード管理があります。

大小を問わず、すべての開発チームに必須なツール

• プロジェクトのマイルストーン管理、タスク管理–簡単に実現できる仕組み–
• バグ専用のデータベース–それもシンプルで、カスタマイズ可能–
• バージョン管理システム–Git / Subversion / Mercural–

tracpath の強みである「課題がソースコードと連携していること」のメリットを説明します。
メリットは3つあります。
 

1. 開発のトレーサビリティ(追跡)

tracpath はあなたのプロジェクトの過去と現在の「なぜ」を理解するのに役立ちます。

以前に解決したバグに関連したファイルに作成された特定の変更を瞬時に見つけることが出来ます。これはプロジェクトの過去、現在含めすべての期間においてソースコードレベルで追跡することが出来ることを意味します。

プロジェクトの開始時点から現在までをタイムマシーンをつかって過去に移動することや特定の1地点だけを戻すことができます。

ソースコードをバージョン管理し、いつでも前のバージョンに戻すことが出来る安心感をあなたのチームに提供することが出来ます。

2. 開発のアクティビティ(活動)

プロジェクトの開発状況をリアルタイムに知ることが出来ます。開発状況を把握し、必要ならタスク・課題あるいはチェンジセット(コミットログ)を閲覧することが出来ます。

ソースコードのバージョン管理システム用に開発された tracpath リポジトリビューアーでは

• コミット履歴
• ソースコードの閲覧
• 差分表示
• リポジトリのログ
• コードレビューとコメント

が統合された機能として提供しています。

バージョン管理システムのクライアントツールを使わなくても、またコマンドを覚えなくても、ブラウザのみで同様の情報を取得することが出来ます。だれでも、簡単に利用できる機能を提供することで開発者以外のチームメンバーにも価値ある情報を共有することが出来ます。

さらに詳しく説明してます。「ブラウザでソースコードの変更履歴を管理する「リポジトリブラウザ」機能」をご覧下さい。

3. 開発のスマートな連携

開発チームはソフトウェア開発に必要な多くのアプリケーションを利用します。アプリケーションの切替を最小限にすることは、時間の節約と思考の切替によるロスを大きく削減します。

tracpath はコミットフックに対応しています。コミットフックによって開発者は簡単な構文をコミットログにメッセージとして追加するだけでワークフロー上のアクションを実行すること出来ます。

 $svn commit -m "fixes #40 に対応しました。"
 や
 $git commit -a -m "fixed #41 に対応した"

「開発チームの生産性を上げたい」「チームの情報共有化したい」「サービスの品質を上げたい」
プロジェクト管理ツールが解決すると謳っている課題である。ツールを導入したからといって生産性や情報共有化などの数値化しにくい点が改善した、と証明することは難しい。チーム全体が変わった気がする、前よりスケジュール遅延が少なくなったなどの感覚値で語られることが多い。

それなりの費用をかけてプロジェクト管理ツールを導入したけど、一部の人たちしか使っていない。数字をいじる仕事の人だけー管理者やリーダーのみーという声を聞く。

これまでいろいろな開発チームを見てきて、開発ツール等の選定、導入をサポートしてきた立場から
うまくいっている状態(チーム)に見られる特長として、チームのボトムアップでの盛り上がりとチーム全員がそれなりに使うことができる共通言語になる場(ツール)になれるかどうかだと思った。

ツールはあくまでもチームを成長させるためのきっかけにすぎないのではないかと思う。

医療業界向け業務サービスを提供している会社の話

医療業界向けに業務サービスを提供している約60名ほどの企業(エンド企業)でのこと。社内の基幹システム運用やホームページ、ウェブシステムの管理、運用まで4,5名の情報システム部が担当をしている。ただし、システム開発ができる技術者はおらず、外部にアウトソースしていた。開発会社として2社(A社、B社)といつくかのプロジェクトを進めていた。

エンド企業ではSI企業で開発経験があり、システムに詳しく業務知識に明るい担当者が管理者(リーダー)として、すべての開発プロジェクトのとりまとめを行っていた。情報システム部門メンバーの進捗管理から外部の協力会社との仕様取り纏めなども管理しなければならず、いつも忙しい状態が続きそれが普通になっていた。

このまま何事も無くリーダーの管理で仕事はスムーズに進めばよいのだが、、、これまで体調不良で数日休むことがあり、業務に致命的な穴が空くことが何度か発生したらしい。

1人の優秀な人のスキルに頼り切った状態で運用されていたため、その人がいないというだけで情報システムメンバーは穴を埋めることが出来なかった。メンバーからするといきなりリーダーがやっていた作業を引き継いで進捗管理から外注管理まで・・・無理な相談である。

よし、ツールを導入しよう

開発チームの生産性向上、チームの情報共有に効果があると思われるツールを入れて試用版をいくつか試してみた。約1ヶ月試用してみたけど、メンバーは最初ちょっと使うだけ、いつのまにか見向きもされなくなってしまった。

ツールが役に立たない訳ではない。ちょっとしたリーダーの作業とチーム体制を変えたことでこの後、ーチームに導入、浸透するまで2，3ヶ月の時間が必要だったー一気にツールのメリットが享受されるようになった。

エンド企業の情報システム部門に必要だったこと

新しい体制図では、これまで利用するツールが決められていなかったーメールに記載したり、Wordで書いたり、電話だったり..ーがツールを一元化しクラウドサービスに統一したことである。

外部の協力会社と一緒にプロジェクトの情報共有ができ、だれが、何をしているのかを見ることが出来る。

プロジェクトを進めるときに関係者が共有ツールを手に入れることでコミュニケーションコストの削減が実現ーコミュニケーションコストの削減は効率化に直結するーした。

これは、関係者で共通言語「今週中に対処が必要なレポートで進捗確認しよう」「#441 チケットにコメント書いたので、内容チェック後、コメントください。」「A社の提示した資料のチェックがまだです。いつまで？」が自然にできあがったためである。

もう一つ、重要な点はエンド企業の大きなシステム毎に専任の担当者を任命したことである。
社内の業務システム担当者とホームページやウェブシステムの担当者の2名である。

これによって、プロジェクトチームに推進力が生まれ数ヶ月後に多くの課題が解決されることになった。

まだまだたくさんの課題は残っており、体制とツールですべてが解決できたわけではない。

しかし、2，3ヶ月という期間でチームの風通しが良くなりプロジェクトが前に進んでいるという実感をチーム全員が感じていることはとても意義がある。

銀の弾丸はない、でもちょっとした改善で変わる

小さなチームのちょっとした改革によって前より少しだけよいチームになった。

この小さな改善のサイクルを繰り返すことがとても重要である。