ProjectKeeperに見る開発方法論

RedmineとSubversionの連携

　SIOS Applicationsでは、成果物管理にSubversion（ソースコードを管理するシステム）を使用しています。それぞれのシステムで、「要望・タスク」と「ソースコード」は管理されるのですが、この2つを橋渡しする手段がありませんでした。そうなると、バグが発生した際に影響範囲の把握や原因の調査に工数を費やしてしまうことになります。

　要望を実現したソースコードを明確にすることで、後の改善やバグ発生時の対応を円滑に行うことが可能になります。

　RedmineにはSubversionと連携する機能があり、こういった懸念事項を解決できます。コミット（ソースコードをSubversionに登録する）時のコメントにRedmineのチケットIDを記述することで、チケットとソースコードが関連付き、どの機能でどのソースコードを編集したかが明確になります。
しかし、少人数の開発現場等では、繁忙のため、この機能を活用することは現実的ではないかもしれません。

　そこで、ProjectKeeperの開発時には、Subversionのhook機能を活用しました。hook機能とは、コミット前やコミット後にスクリプトの処理を実行する機能で、コミットコメントのチェックや、メール配信のトリガーとして使用されます。このコミット前（pre-commit）に、以下のチェック項目の確認を行うことで、チケットとタスクIDに整合性を持たせました。

・コミットコメントにチケットIDが含まれている。
・チケットIDの担当者が自分である。

　つまり、すべてのソースコードは、チケットが存在しなければコミットできません。こうすることで、ソースコードと「バグ／機能拡張」の関連が保障されます。開発者にとっては、運用方針のドキュメントを見るより明確で、理解しやすい運用方法です。

　また、Redmine内部については、システムで管理しにくい部分もあります。それは、登録されたチケットの要件があいまいであることや、障害報告の内容が不足している場合です。その際は、要件定義や障害報告をしている担当者に対し、不足している内容をコメントに記述し、チケットを差し戻します。チケットを差し戻された担当者は、不足内容の調査・説明を追記し、あらためて担当を割り振ります。

　このように、要望からテストまでチケットに基づいて異なる割り振り・担当者で運用することは複雑なように思えるかもしれませんが、基本のルールがあるので、運用管理が煩雑になることはありません。その基本ルールとは、自分が担当者であるチケットは、自分が何かしらのアクションをする必要があるということです。

　例えば、間違ってアサインされている場合や内容が不足している場合は、プロジェクトマネジャーや各担当者へチケットを差し戻します。差し戻された担当者は、必ず担当者の割り振りや不足内容を再確認するアクションをとらなければなりません。

　こうして、チケットを中心にコミュニケーションのサイクルを止めることなく、開発を前進させていきます。

ガントチャート機能の改修[前編]

　ここまでは、開発手法や管理手法について書いてきましたが、ここからは実際のどのようなアプリケーションをどのような経緯で開発していったのかをご紹介します。
2008年9月にリリースしたProjectKeeper Version1 Update2では、「ガントチャート機能の改善」という大きな変更がありました。これは新しい技術へ挑戦という側面が強く、今までのようなウォーターフォール開発手法は、最初から通用しないものでした。

　当時のProjectKeeperのガントチャートは、従来のWebアプリケーションに多少のインタラクティブさを持たせた程度で、到底RIA（Rich Internet Applications）と名乗れるようなものではありませんでした、Webアプリケーションでよく用いられる「ページ遷移」を多用する傾向にあり、これが操作性の問題となっていました。

　ガントチャート改修の要件は、Webブラウザーであることを意識させないユーザビリティの実現というものでした。