ProjectKeeperに見る開発方法論

はじめに

　第1回では、アジャイル開発の選定までを紹介しました。今回は、弊社の開発製品群「SIOS Applications」の中の1つであるプロジェクト管理ツール「ProjectKeeper」のアジャイルによる開発プロセスを、実例とともに紹介します。

　ProjectKeeperの最初のバージョンを開発した当初は、プロジェクトメンバーの人数と経験から開発手法はウォーターフォール、開発言語にはJavaを、フレームワークには自社フレームワーク「Ninja-VA」を選びました。

　この選択に至った経緯は、先に自社開発をしていた営業支援ツール「SalesForceAutomation+（以下SFA+）」の開発基盤を再利用することとなったためです。これにより、開発コストを抑えるとともに、ProjectKeeperとSFA+の連携を簡略化させることができました。

アジャイル開発へ

　ProjectKeeperの開発手法をウォーターフォールからアジャイル開発へ移行させることを決断したのは、2008年初期になります。移行当時の開発体制は、プロジェクトメンバー8名（うち開発者4名）でした。この開発プロジェクトの管理は、全体の進ちょくはProjectKeeperで、タスクはExcelで行っていました。

　しかしこの方法は、文書ではなく動いているソフトウエアを使って要求を確認していくアジャイル開発には合いません。また、パッケージ製品の開発では、顧客からの要望が頻繁に発生します。Excelではバージョンの管理が困難ですし、印刷物では2日経過した時点で信ぴょう性が低くなってしまいます。SI開発の仕様書と異なり、パッケージ製品の開発は、クローズされるタイミングがはっきりしないため、リアルタイムでの情報共有が必要です。

　また、絶えず製品の機能に対する要望が上がってきて、リリースのタイミングや順序を変更することもあります。そのため、各要望のステータスの変化を開発の進ちょくと連動させて管理する必要があります。

　そこで、ProjectKeeperの開発時には、タスク管理としてRedmineを導入しました。Redmineとは、オープンソースのプロジェクト管理ソフトウエアです。顧客からの要望や、開発中のバグをチケット（タスクのことをRedmine上では、チケットと呼んでいます）として管理し、このインフラを用いたアジャイルによる開発を開始しました。

　アジャイル開発の初期段階は、以下の2つを特に気を付けるべきです。
・ウォーターフォールによる開発と比較し、成果物として作成する文書が少なくなる分、コミュニケーションを密に行う必要がある。
・ささいなコミュニケーションの内容についても整理して残しておく。

　ProjectKeeperに限らず、SIOS Applicationsの開発ではコミュニケーションはRedmineのチケット上で行うことを原則としています。報告の際は、チケットに対してコメントを行い、エビデンスとしてキャプチャー画像や動画等を添付します。

　Redmineでは、チケットの種類をわけてタスクを管理することが可能です。SIOS Applicationsでは、3つのチケットに分けています（図1-1）。

　顧客や社内の要望は、「要望」としてRedmineに登録されます。登録された「要望」は、承認を経て、対応中のステータスとなります。その後、開発プロセスに入り、「機能拡張」を作成します。この時「要望」と「機能拡張」は、Redmine内で関連付けることを義務付けています。どの「要望」にもとづいた開発を行っているかを明確にするためです。もちろん1つの「要望」に対して「機能拡張」が1つとは限りませんので、その場合は複数の「機能拡張」を「要望」に関連付けます。

　こうすることで、顧客からの要望と実装担当者までの見通しが良くなり、情報の連携が実現します。「要望」は、関連しているタスクがすべて終了すると、自動的に対応済みとなります。要望に対してどのような変更がされているかがリアルタイムに管理可能になることで、少人数でも多くの要望に対応できるようになります。

　こうしてRedmineにより、製品開発のためのインフラの準備が整いました。その後、いかに運用していくかが課題となります。