ソフトウェア開発におけるプロジェクト管理は、大きな転換期を迎えています。全体計画ありきの従来のプロジェクト管理から、開発計画を細かく区切り、作業量の実測に基づいて短期間で繰り返すプロジェクト管理に移りつつある中で、プロジェクト管理で活用されるツールも進化しています。本記事では、ITS（Issue Tracking System、課題管理システム）の変遷を振り返りながら、これからのプロジェクト管理ツールに求められるものを探ります。特に、プロジェクト管理ツールとして日本でも導入されることが増えてきたAtlassian JIRA（以下、JIRA）に注目して、その特徴や人気の理由も見ていきます。

ExcelとITS、2つのプロジェクト管理ツール

Excelによるプロジェクト管理

日本のソフトウェア開発の現場では、プロジェクト管理にスプレッドシートがよく使われます。ここではその代表格としてMicrosoft Excel（以下、Excel）を取り上げますが、ほかのスプレッドシートでも基本的に同じことが言えます。Excelは、おもに次の理由からプロジェクト管理でよく使われています。

誰もが使えるOffice製品である

• 操作の学習コストが少なくて済む
• 誰に配布しても閲覧、編集できる

スプレッドシートの利点を活かせる

• 一覧表示に長けている
• 帳票表現や整形がしやすく印刷もできる
• 結果の集計やグラフによって可視化できる

誰もが使えるというのはどの分野でも強みです。表現力の高さも相まって、ガントチャートをExcelで書くという文化も生まれました。「⁠Excelで管理しておけば無難」という意識も浸透してきました。

ITSによるプロジェクト管理

一方、欧米では、Excelはチェックリストなどで活用されることはあっても、プロジェクト管理に使われることはあまり多くありません。なぜならば、2000年前後から、バグや障害の追跡システム（Bug/Defect Tracking System）を起源として、さまざまな課題（Issues）や作業（Activities）を取り扱うプラクティスとツールが考案・実践されてきたからです。これがいわゆるITSです。

この時期は、オブジェクト指向パラダイムやアジャイルマニフェストなど、ソフトウェア開発でさまざまな取り組みが始まった時期でもあります。ソフトウェア開発が一気に複雑になることがわかっていたため、できるだけコントロールされた状態を保つための方法論が考案されました。

当初、ITSはプロジェクト内の特定の事項を追跡・管理することをおもな目的としていました。たとえば、「⁠バグを改修する」というプロセスの追跡と管理をする場合、次のようにバグのライフサイクルをコントロールするところからスタートします。

1. バグを発見し、バグ情報を起票する
2. 改修の可否を意思決定する
3. バグの原因を分析する
4. 改修作業を行う
5. 改修内容とテスト結果を確認する
6. バグ改修版をリリースする

これらが一連のワークフローを形成すると、バグ改修という開発者の作業だけではなく、テスト担当者やプロジェクト管理者、ビルド管理者、リリース管理者などほかの多くの担当者が関心を持つ事象にも応用できることがわかってきました。これはいわゆる「変更管理」のしくみです。ソフトウェア開発では、機能拡張も、仕様変更も、バグ改修も、すべてソフトウェアへの変更と位置づけられます。これらの変更を適切に収集し、意思決定し、遂行すること、またその状況が見えることは、複雑なソフトウェア開発を簡素にする方策として有益であることが見えてきました。

ExcelとITSの違い

それでは、ExcelとITSにはどのような違いがあるのでしょうか。ここでは、次の3つの点に注目してそれぞれの特徴を把握していきましょう。

• 情報の管理形態
• 取り扱える情報の性質
• 成果（物）との関連性とそのしやすさ

情報の管理形態

Excelはファイル単位で情報を管理します。ファイルサーバやクラウドストレージなどで共有しない限り、基本的に情報は分散する傾向にあります。各自がコピーを持ち、ローカルディスクに保管している様子をイメージしてください。この場合、「⁠どれが正しい情報か」「⁠更新が正しく伝わっているか」を把握するのが難しく、人手や人のモラルに依存する傾向があります。

ITSはDBで一元管理されており、最新の正しい情報が明確なので、共有と更新について神経をすり減らす必要はありません。また、ITSは専用のクライアントや、Webブラウザからアクセスできるインタフェースを備えており、目的に応じたIssueの一覧表示と選択したIssueの詳細を表示・編集するしくみを提供してくれます。

取り扱える情報の性質

Excelでの情報は、あくまでスナップショットです。今の状況を把握し、更新したい場合には都合がよいですが、履歴の表現には向いていません。履歴を表現するには、以前の状態のファイルをコピーし、ファイル名の後ろに日付と時間を付加したりして保管することがよくあります。

ITSでは、DBによる蓄積と更新が行われ、履歴を閲覧できるようになっています。また、ワークフローが定義されており、一連の手順に従ってステータスを更新したり、そのときに必要な入力を促したりするしくみがあります。これにより動的に情報を扱いやすくなり、入力や更新、情報の閲覧の負担が軽減されます。

成果（物）との関連性

ソフトウェア開発でのプロジェクト管理という性質上、その作業には、成果（物）が伴います。たとえば、バグの改修ならば、成果として、バグが改修されたソースコード、ビルド成果物が発生します（また、目に見える成果以外にも知見を得ることができます⁠）⁠。

Excelでのプロジェクト管理では、一般的に手作業で成果（物）を記録します。バージョン管理されているソースコードのコミットIDを把握し、所定の列に手作業で入力します。この作業はとても負担がかかるうえに、ミスが起こる恐れもあります。

ITSでは、バージョン管理システムや要求管理システムなど、ほかのシステムと連携可能なしくみを持っているものが増えています。手動で入力するもの、情報をITSとバージョン管理システムなどで二重管理するもの、APIで連携し合うものなどさまざまな種類のものがありますが、Excelでの管理と比べると入力の負担は少ない傾向にあります。

以上をまとめると、表1のようになります。

項目	Excel	ITS
情報の管理形態	ファイル単位でデータを管理。情報の集中と分散は手作業で行わなければならない	DBでデータを一元管理。情報は集中管理されている。DBにアクセスできないと情報を得られない可能性がある
情報の性質	静的。履歴の記録や、ワークフローに従って入力し把握するのには不向き	動的。ワークフローをあらかじめ定義する。情報の履歴を記録し、閲覧可能にする。権限設定や、入力項目の制限もできる
成果（物）との関連性	進捗と成果（物）の関連付けに負担がかかる	進捗と成果（物）を関連付けるしくみが確立されつつある

ITSの導入と定着の壁

Excelを使い続けるわけ

プロジェクト管理では、計画を行うだけでなく成果を含めた進捗を把握できることが重要です。プロジェクトをフォローし、問題発生時に適切に対処するために、迅速に実情を把握できなければなりません。

ところが、実際はプロジェクトの計画を立てることに比重が置かれ、その結果プロジェクトの監視が重視されがちです。この場合、計画と実績のスナップショットを知るには、ガントチャートや課題表が作成しやすいExcelでの管理は理にかなっており、都合も良いのです。

それでは、プロジェクトの監視ではなく、プロジェクトの運営に注目した場合はどうでしょうか。おそらく多くのプロジェクトがExcelでの管理に負担と限界を感じることでしょう。特に現場にかかる負担がどんどん大きくなることが予想されます。「⁠今までこれでやっていたから」という理由だけでExcelを使い続けるわけにはいかなくなるでしょう。

しかし、多くのプロジェクトでExcelが使われ続けるのはなぜでしょうか？ プロジェクト管理ツールの進化を振り返りながら考えてみましょう。

限られたプロジェクトのための商用ITS

Excelが使われ続ける理由として、誰もが使えるツールなので抜け出せないというのは十分に考えられます。もう1つ考えられるのは、考案されたばかりのころのITSが比較的高額な商品であったという理由です。ITSに投資できる組織やチームでは導入されましたが、多くの開発の現場で広く認知され、普及するまでには至らなかったのです。

内製ITSのジレンマ

もともとバグ帳票とバグ票による紙文化が根付いている日本企業では、ソフトウェア開発に合わせた電子的な方法でそれらを踏襲する方法が模索されました。商用のITS製品はコストがかかるうえに自社文化や用語に合わせる手間もかかるため敬遠され、内製ITSが選択されることがありました。内製ITSは自社事情に特化できる利点があったからです。その反面、「⁠紙文化をそのままシステム化」「⁠全社全業種統一」といった目的が優先され、使い勝手と柔軟性に課題が残りがちでした。

オープンソースITSの貢献

この状況が変化してきたのは、2010年前後のオープンソースITSの台頭です。Trac、Redmineといったオープンソースプロジェクトが立ち上がり、成果が出始めると、ITSの意義を含めたさまざまな情報が共有・蓄積されていきました。商用製品も手に入りやすくなり、ITSを活用して本業に注力していこうと考える企業が増えてきました。オープンソースのITSは初期投資が最小限で済むため、開発現場でのボトムアップ導入が進みました。最終的なアウトプットはExcel管理表で出さなければならなくても、開発現場ではITSを使うという選択肢も出てきました。

ITSの次のステップ

開発現場主導によるITSの導入が加速すると、その課題も見えてきました。次のステップが見えてきたということです。

限られた人による活用からの進化

開発作業の促進が目的のITSは、ほかのロールやほかの目的（企画やテスト、プロジェクト管理）にとっては必ずしも都合が良いものではありませんでした。

開発者がタスクとそれに関わるソースコードとの関連を取るためにITSを活用した場合、プロジェクト管理者などの別の立場から見ると、そのタスクに関する細かい情報が多過ぎてプロジェクトの状況を包括的に知ることが難しく感じます。それを補完するために、Excelによる情報提供を別途要求することもあります。

ITSによって作業の効率化とコラボレーションが進むことを身をもって体験している開発者からすると、良いITSのしくみができたらほかのロールでも活用してもらいたいのですが、なかなかうまくいかないという状況になっているのです。

例としてバグの改修を考えてみましょう。開発者は、ソースコードを修正するための情報とワークフローがあれば十分です。それに対してプロジェクト管理者やテスト担当者は、ユーザフィードバックやテスト結果に基づくバグの追跡と説明に責任があるため、バグの登録から修正版のリリースまでの全体を見ることができるワークフローでなければ活用しづらいのです。

ある程度の目的が果たせるからこその悩みではありますが、欧米では10年以上前から、これらをスコープに入れた変更管理のワークフローを定義し、運営するのがセオリーになっています（図1⁠）⁠。

ITSの定着に向けたツールの統一の必要性

視点を変えてみましょう。ITSの普及とともに、好みのITSを導入する現場も増えてきました。あるプロジェクトではAというITSを、隣のプロジェクトはBを、その隣はAをベースにしたカスタマイズ版A'を使うということが起きてきました。独立したプロジェクトであれば、ボトムアップ導入で問題は起きませんが、ITSが各現場に定着するに従って次の課題が見えてきます。プロジェクト間でのITSの種類の違いが異動者や兼務者の戸惑いや不満を引き起こし、生産性にも影響が出てきます。ボランティア運営に委ねるのも限界が見えてきます。

ここで、もう一度Excelの特性を振り返ってみましょう。Excelのメリットは、ファイル単位で情報を管理するため、自分たちの環境に合った「オレオレ管理表」を容易に生み出せることです。デメリットは、情報の分散化と更新の難しさです。ITSがプロジェクトごとに異なるという状況は、「⁠オレオレ管理表」が「オレオレITS」にスケールアップしたにすぎないともとらえることができます。ITSをより定着させスケールさせるためには、プロジェクト間でITSを統一する必要も出てきます。

望まれるITSとしてのJIRA

JIRAは、Atlassianが2002年に提供を開始したITSです。Atlassianでは、良いITSをスタートアップ企業やチームで活用できるように、次のプログラムを継続提供しています。

無償提供

オープンソースプロジェクト、NPO法人、授業用に無料で提供

スターターライセンス

10ユーザが利用できる製品を10ドルで提供し、売り上げを全額チャリティーとして寄付[1]

JIRAという名前を知らなくても、著名なオープンソースプロジェクトのITSで利用されているのを見たことがあったり、知らないうちに実際に使っていたということもあります。JIRAは、多くの先進的なプロジェクトで利用され、揉まれてきているのです。

Atlassianは、製品の価格に加え、ドキュメント、既知の問題点、ユーザフィードバックを公開しているので、明確な投資がしやすくなっています。営業部門を持たずにエンジニアに投資するビジネスモデルはビジネスシーンでも注目されています。これは口コミによる評判と製品の浸透度が高くなければできない方法です。

JIRAはどんなITSか？

JIRAには、ITSの代表格と呼ばれるのに十分な理由があります。その主なものは次の3つです。

• 使い勝手が良くなるよう工夫されている
• プラットフォームとして確立されている
• 部門やロールを問わずに利用可能なしくみに拡張できる

JIRAは、ITSの中でも特に標準機能が充実しています。ここでは標準機能の代表例としてスマートクエリを紹介します。ITSでは、あらかじめ定義しておいたフィルタを選択して目的のIssueの一覧を表示します。しかし「自分が担当している一覧を即座に知りたい」「⁠自分が報告した一覧の状況を即座に知りたい」「⁠期日が近いものを把握したい」というときには、フィルタを定義する時間と手間がかかります。JIRAには、検索ボックスに特定のキーワードを入力すると、欲しい情報を提供してくれるスマートクエリが備わっています。この機能を使うことで、表2のような情報を即座に得ることができます。

また、JIRAはITSを含めたワークフローエンジンのプラットフォームとして知られています。AppleのApp StoreのようなAtlassian Marketplaceにより、目的に応じた拡張機能やシステム間の連携を行うアドオンを容易に検索・調達できます。開発者にも名声や収益を得る機会として提供されています。

検索ワード	提供される一覧情報
my	自分が担当しているIssue
r:me	自分が報告したIssue
r:tnagasawa	ユーザ「tnagasawa」が報告したIssue
overdue	期限の切れてしまったIssue
due:.1d,1w	期限が昨日（.1d）から来週までの1週間（1w）のIssue
created:yesterday	作成日が昨日（yesterday）のIssue

JIRAにはプロジェクトの事情に応じて展開できる柔軟な提供形態が用意されています（表3⁠）⁠。

提供形態	特徴	適用例
JIRA Server	（旧名称：Download）	自社サーバに構築自社のプロジェクトルームや機密性の高いプロジェクト
JIRA Cloud（旧名称：OnDemand）	AtlassianがホストするSaaS	期間の短いプロジェクトや分散拠点間での共有
JIRA Data Center（※新設）	自社サーバに構築	部門や企業内で統一したITSプラットフォーム

JIRA ServerやJIRA Cloudを現場に導入することから始めて、JIRAが社内で定着してきたらJIRA Data Centerで包括的に運営するなど、柔軟に利用できる点がJIRAの大きな特徴です。

JIRAでITSを統一する

JIRAの採用例では、最初はスターターライセンスで試しに使ってみて、社内での実績を積み重ねていき、プロジェクト・部門・会社標準へと次第に広がっていくケースが多く見られます。採用の理由として、商用製品なのでサポートを受けられるという点や、会社資産として保持・運営しやすいという点を挙げるユーザも多くいます。

スターターライセンスの売り上げを全額チャリティーに寄付しているにもかかわらずAtlassianの会社運営が順調に推移していること、JIRAの製品戦略がより広範囲への適用に舵を切っていることなどは、上記のような活用の幅の広がりを示しています。

JIRAの採用が進む理由として、「⁠成果（物）との関連付けのしやすさ」も挙げられます。バージョン管理システムやヘルプデスク、情報共有システムなどとJIRAを連携するしくみがサードパーティからも提供されています（Atlassian Marketplaceから調達可能⁠）⁠。JIRA自身もDVCS（Distributed Version Control System：分散型バージョン管理システム）をベースとしたGitHubなどとの連携や、Subversionとの連携アドオンを提供しています。

JIRAは情報ハブ

ITSは、ほかのシステムと連携することでプロジェクトを広範囲にわたり詳しく追跡できるようになります。それぞれの作業を支援しつつ、それぞれの価値観や把握したい粒度に合わせた見せ方・追跡を行える情報ハブがITSなのです。

要件からソフトウェアへの中間成果物としてソースコードなどがあるととらえると、中間成果物は一部の関係者（開発者）にはわかりやすいですが、それ以外の多くの関係者（プロジェクト管理者やエンドユーザなど）にとってはわかりにくいものです。開発者以外の関係者は「要件が次のリリースで提供されるか？」「⁠バグが改修されているか？」に関心があります。ITSは情報ハブとして、大きなくくりと細かい成果をつなぐのりしろのようなものです。次の工程に引き継ぎ、移行する情報源となります（図2⁠）⁠。

JIRAは、さまざまなプロジェクトで揉まれてきた実績から、どのような立場の関係者にも直感的にわかりやすく、負担を軽減するしくみを提供しています。

これからのプロジェクト管理を支えるJIRA

これからのITSには、一歩先を行くためのしくみが求められてきます。ソフトウェア開発の過程で得られたあらゆるフィードバックを収集し、実践していくことが求められます。これからは実践・学習・蓄積を繰り返すプロジェクト管理が必要なのです。

Issueを基点とした情報ハブ

• Issueと開発成果（物）を追跡可能にするシンプルな開発フローの形成と協調の促進
• さまざまなツールやシステムからアクセスできる情報ハブ
• Issueの発行や閲覧をITSで行わない情報共有と協調の促進

あらゆる関係者からIssueに情報を引き込むことによる情報ハブ

• Issueの見せ方を関係者に応じて使い分ける協調の促進

これらを行うことで、企画→計画→開発→ビルド→デプロイ→運用のライフサイクルでITSが情報ハブとして力を発揮します。

開発フローの簡素化と定着化を担うGit Essentials

とはいえ、開発者の作業はソフトウェアの源泉であり、重要な役割を果たします。最近では頻繁にソースコードの履歴を取得できるDVCSが活用されるようになってきました。ただし、DVCSはリポジトリが分散するため、管理や開発フローの統一方法が従来の中央集中型バージョン管理よりも複雑です。

DVCSの代表格であるGitをベースとした開発フローを情報ハブであるJIRAで統制することで、計画→開発→ビルド→デプロイの一貫性を保ちながら簡素化し、定着させるソリューションがGit Essentialsです（図3）。

Git Essentialsは、JIRAと、JIRA Agile（JIRAにアジャイルな運営機能を追加するアドオン）、Stash（Gitのリポジトリ管理を行う）[2]、Bamboo（継続的インテグレーションとデプロイを実現する）を組み合わせたものです。

Git Essentialsでは、開発のすべての成果（物）が開発の動機となったIssueに関連付けられます。ブランチをはじめ、コミットやプルリクエスト（コードレビュー）、マージ、ビルド結果、デプロイ状況をJIRAのIssueに関連付けて把握できます。これは、開発者だけでなくプロジェクト管理者やテスト担当者などほかの関係者にも価値のある情報源となります。

現実的な企画と開発計画を支えるAgile Ready

ビジネスに合ったソフトウェアを提供し続けるためには、企画と開発計画を密接に関連付けることが重要です。企画担当者は開発チームの現状を理解したうえで企画を練る必要があり、開発チームは当初の企画だけでなく企画の更新内容も把握しながら開発を進める必要があります。

Agile Readyは、開発の複雑さをJIRAを使って誰もが把握できる粒度に調整することで、開発計画とより上流の企画をつなぐソリューションです。企画担当者が、情報を共有し練り上げることを容易にするチームコラボレーションツールConfluenceで企画書を管理することで、文書内の要件項目をJIRAのIssue（バックログ項目）として起票できます。企画担当者は、自分の責務である企画書に集中しながら開発チームに要求を伝達できます。開発チームは、JIRAで意思決定や進捗状況を明確にできます。企画書内の要件項目にJIRAのIssue IDと現在のステータスが動的に更新されるため、企画書は透明性と追跡可能性を兼ね備えたものになります（図4）。このように、ITSを間接的に使いながら情報をつなぐということもITSには求められてきます。

運用サポートとエンドユーザとの対話を実現するJIRA Service Desk

エンドユーザからのフィードバックに応えるためには、エンドユーザにもITSを使ってもらうことが必要です。ただし、ITSはエンドユーザにとって必ずしも使いやすいものではありません。情報量や専門用語などの壁があります。エンジニア以外にもITSを使ってもらうしくみを考えなければなりません。

JIRAのアドオンであるJIRA Service Deskでは、ヘルプデスク業務でJIRAを活用するしくみを提供しています（図5）。エンドユーザは、シンプルなポータルと必要最小限の入力でフィードバックができ、それに対応するエンジニアはより専門的な情報を参照できるしくみです。

すべての関係者の手間を軽減し、ITSがより広範囲に活用されるためには、同じIssueに対して使う人の立場に応じて見せ方や提供のしかたを変えるしくみを持つことが必要となります。

健全なソフトウェアライフサイクルをこの手に

最近、ソフトウェア開発現場の資質が問われるようになってきました。より透明性の高いプロジェクト管理に移行するには、ITSの積極的な活用がカギを握ります。開発の環境を整備し、負担を軽減し、本来注力すべき本業にフォーカスできるようにする必要があります。

ITSを導入し定期的に見直すことで、みなさんの開発現場の良い点・改善点を再発見してみてください。JIRAは十分にその手段の1つになれるでしょう。また、JIRAから多くを学ぶこともできます。ほかのITSを使い続ける方もJIRAを知っておいて損はありません。