[TiDD] 制約とチケット駆動開発

前回は、ソフトウェア工学の歴史が、ソフトウェア開発に制約を与えることで高品質なソフトウェアの開発を実現してきたと説明しました。今回は、チケット駆動開発がこれまでの技術と同じように、ソフトウェア開発に制約を与えることで高品質なソフトウェアの開発を実現するものの、これまでの技術とは異なる特徴のあることを説明します。

それは、コミュニケーションに制約を与える点です。もちろん、

• 高機能ソフトウェアを実現するための作業分割が可能
• 不具合や修正メトリクスの収集やテストツールとの連携(リンク先はプログラマの思索)でソフトウェアの信頼性を高める
• アジリティを高めて、社会の変化に対応する

こともチケット駆動開発の特徴ですが、ワークフローや作業指示の形式化によって、新しい制約を与えることは他にない特徴です。

チケット駆動開発(TiDD)は「No ticket! No commit!」つまり、チケットのないソース更新は許さないという基本ルールも「制約」ですが、あきぴーさんと共著のSQiPの論文(PDF)に書いたように、ソースコードの2重管理をワークフローによって間違いなく実施することが可能です。このワークフローは、チケット駆動開発がコミュニケーションに与えるもっとも大きな制約と言えるでしょう。

このように書くと、チケット駆動開発は厳しい制約によって、形式的なコミュニケーションを与えるものだと思われる方もあると思います。しかし、XP祭り関西で発表したように、それはチケット駆動開発の管理方法によって変わるものです。

チケット駆動開発のもう一つの制約は、チケットそのものです。作業指示を口頭からチケットに形式化するという制約を与えることで、

• 言葉ではうまく指示できない場合も、明確に指示できる
• チケットは公開されているので、人に見られる前提で対応する

という2つの効果が現れます。このことを利用すれば組織体制にそった正常な業務の運用が可能になります。具体的には

• 作業分担の混乱(押し付け合いや譲り合いによるデッドロック)が生じにくくなる
• 遠慮がちな指導者も明確な指示ができる

というメリットが生まれます。11月のSPI Japanではそのような(XP祭り関西で紹介した)プロジェクトの背景について紹介する予定です。

ところで、チケット駆動開発による見える化に関しては、さらなる期待もあります。トレーサビリティの確保ができるほか、作業のエビデンスにもなるので、信頼感の向上や裁判対策といったStagEプロジェクトが狙っているような成果が期待できると思います。

また、チケットを上流から使うことができれば、CMMIで求められるトレーサビリティマトリクスをチケット間の関係から作成できるのではないか、などと妄想しています。