[#TiDD] チケットの制約によるプロセスの自動化

プロセスの自動化には色々あります。

• 何もしなくても勝手にしてくれる
• 指示をすればしてくれる
• 判断する助けをしてくれる

といった自動化が、まず思いつきます。チケット駆動開発に関連する物なら、メールやrssによる通知、バージョン管理ツールでのコミット時にチケットをクローズする、デプロイ結果のチケット発行など、ツールの連携、レポートや集計、ガントチャート、バーンダウンチャートなど、情報の見える化、などが挙げられるでしょう。

プロセスの自動化にはこれ以外にも

• 確認しなくても良いように制約を与える

という自動化があります。本来ならその作業が行われたかを確認すべき作業が不要になるからです。

チケット駆動開発では、権限の指定によって、参照や更新を制限する事ができますし、本人(とツールの管理者)だけが参照できるプライベートチケットのしていなどがあります。さらにツールによっては、チケットの種類ごとにワークフローを指定できるものや、特定の項目の入力を必須にできるものがあります。

これらの機能は、作業者のミスを減らして楽ができるように、混乱を防ぐ事でより高度な作業ができる様に制約が与えられます。

かつて、ISO-9000の導入事例のお話を聞いたことがあります。押印欄や記入欄が埋まっていないといけないので、使われない欄を無くして、過去の文書には斜線を入れたそうです。

押印欄は業務のワークフローのエビデンス(証拠)で実施結果を可視化するものです。意味のある制約は使われる制約です。チケット駆動開発においても、むやみに制約を追加してしまうと確認作業がボトルネックになって作業が停滞したり、必須の項目にデフォルト値や曖昧な情報しか記入されなくなってしまいます。

必要な制約があっても、安易に全てのチケットにつけると危険です。制約が不要な場合があるならチケットの種類を分けて、ワークフローや必須項目を別にした方が良いでしょう。

以前、記事に書いた様に制約とチケット駆動開発は関連深い反面、よく考えないとチケット駆動開発によって仕事がやりにくくなる可能性もあります。ある種の制約は自由を増すと言われる様に、どのような制約なら自由を増すかを見極めるのがポイントです。現状の問題を見極めてその解決方法としてチケット駆動開発を利用するなら、きっとプロジェクトを成功に導く事ができるでしょう。