チケット駆動開発を要求工学の品質特性の観点から考える～チケット駆動開発がAgile開発を必要とする理由

チケット駆動開発における「チケット」を要求とみなした時、要求工学の品質特性の観点から考えると理解しやすいように思えた。
ラフなメモ書き。

【参考】
要求仕様 - Wikipedia

要求の旅は終わらない――開発と並走する「要求管理」 － ＠IT自分戦略研究所

要求仕様（要求工学：第3回）

requirement-engineering

【1】ソフトウェアエンジニアリングの中で、要求定義の手順や要求事項を引き出す技法や概念を体系化し、整理したものが要求工学である。
ここで「要求」は「ソフトウェアやシステムを利用することで実現したいこと」、「要求仕様」（SRS：Software Requirements Specification）は「要求を実現するためのソフトウェアのインターフェイス、構造、機能」と呼ぶことにする。

要求を仕様化する時、どのように要求をまとめればよいのか？
この問題は古くからソフトウェア工学の課題として続いてきていて、今だに有用な解決法は見いだせていないのが現状。
あいまいな要求を仕様化する時、次から次へと矛盾や不明点が出てきて、なかなかFixできないのだ。

WF型開発では、要求仕様を厳密に定義して、仕様凍結してから開発を始める。
しかし、この手法は最近のようにビジネスの変化が激しい時代には正直マッチしない。
最近ならOOAならユースケース、アジャイル開発ならストーリーカードへ落として、反復的に開発す手法が多分有名だろう。
だが、要求から良いユースケースやストーリーカードを書くのはやはり難しく、そのノウハウもまだ足りない。
業務知識があるからといっても、システムの実現可能性を考えたり、性能要件や保守性などの品質要件を整合性が取れるように作るのは難しい。

【2】要求工学では、要求仕様の品質特性という概念があり、良い要求仕様を考える時にその観点として役立つように思う。
要求仕様の品質特性には、下記の8つがある。

* 妥当性(正当性、必要性)
　要求仕様に全ての要求が網羅されている
　ソフトウェアが持つべき要求仕様が要求に含まれており、かつ、それ以外の要求を要求仕様に含まないこと

* 非曖昧性(無曖昧性, 明確性)
　すべての要求が一意的に識別できる
　何通りにも解釈できる書き方をしない

* 完全性
　要求仕様に必要な情報がすべて記述されている

* 一貫性(無矛盾性)
　記述されている要求が互いに矛盾しない

* 順序付け
　要求が重要性や安定性について優先順位付けされている

* 検証可能性
　要求仕様に含まれる全ての要求に対し、有限のコストで評価可能な手続きが存在して検証できる

* 変更可能性
　要求の変更に対して、容易かつ完全で一貫性を保って修正可能である
　個々の要求が独立していることが必要

* 追跡可能性
　それぞれの要求について，その背景，理由，意図などが明確で容易に参照できる

要求仕様の品質特性は、ソフトウェアの品質特性(機能性、信頼性、効率性、使用性、保守性、移植性)の概念に似ている。
ソフトウェアアーキテクチャの実現可能性の評価の手法としてATAMがある。
ATAMは、ソフトウェア品質特性の観点からシナリオを作り、そのシナリオを詳細化して検証する方法なのだが、サーバー基盤構築やDB性能の検証など非機能要件の検証で結構有効であるように思う。

アーキテクチャではトレードオフは避けられない: プログラマの思索

同様に、要求の品質特性を使えば、それら要求から作られるソフトウェア製品について、その実現可能性や検証に役立てられるのではないかと思う。

【3】ここで、チケット駆動開発に要求工学の品質特性の観点を入れてみる。
チケット駆動開発は、チケットを起点として作業を開始し、テストしてビルドして順次リリースしていく開発スタイルだ。
基本は、ソフトウェア開発のプロジェクト管理をサポートするものである。

チケットには、ユーザから機能改善の要望、障害報告、問合せなどが起票されるし、開発チームからも保守性や移植性を高めるためにリファクタリングやテスト自動化の作業などが追加される。
つまり、チケットは単なるタスクだけではなく、そのタスクの発生源である要求事項も含まれているし、それら要求からチケットが発生する。
たくさんのチケットが完了するたびに、ソースや設計書などの成果物が作られて、ソフトウェア製品へマージされて反映されていく。
つまり、ソフトウェア製品は、チケットから発生したパッチを当てられていくたびに、機能改善や障害修正の要求が反映されて、成長していくものであるといえる。

すると、チケットを要求仕様とみなした場合、要求の品質特性から、チケットはどんな性質を持っているのか？

* 妥当性(正当性、必要性)

ユーザや開発チームからの要求が全てのチケットに反映されているか？
これはNo。
その保証はない。
チケットの登録漏れの可能性もあるから、手運用でカバーするしか無い。
リーダーにとって、タスク漏れは致命的なリスク要因なので、チーム内で誰も担当していない作業がないか、常に気にしている。

* 非曖昧性(無曖昧性, 明確性)

ユーザからの要求がチケットで一意に識別できるか？
これはYes。
チケット番号で、事象や要求を唯一に識別できる。
チケット駆動開発を実践すると、チーム内の会話には、「チケットXX番の作業は終わった？」「YYのチケットは顧客回答があった？」などのように、どんな人も話している内容を一意に識別できるような雰囲気が生まれる。

* 完全性

要求に必要な内容は、きちんと整理されて、チケットに反映されているか？
これはYes。
チケット駆動開発の基本ルールである「Ticket First」「No Ticket, No Work」のプラクティスでカバーしている。
つまり、チケットを起票する時に、他人が分かるようなチケット内容で記載するように、運用ルールで強制している。
チケットに作業する内容、作るべきアウトプットを明確に書いておかないと、開発者に作業を振りにくい。

逆に言えば、チケットはチーム内の誰でも担当できるように、作業内容をきちんと書いておくべき。
そうすれば、担当者が病欠したり、チーム内のリソースが足りない時に、外部メンバーをヘルプですぐに入ってもらいやすくなる。

* 一貫性(無矛盾性)

チケットの内容やチケット同士の関連に矛盾はないか？　整合性は取れているか？
これは半分Yes。
棚卸しというプラクティスでカバーしようとしている。
例えば、1週間おきに全チケットを整理するイベントをもうけて、重複したチケットは重複の関係で関連付けたり、作業不要となったチケットを却下したり、依存関係にあるチケットを関連付けたり、チケットの内容を最新化する。
でも、棚卸しだけのプラクティスだけでは弱い。
リーダーだけがチケットを最新化していたりして、棚卸しの役割が曖昧な時がある。

* 順序付け

チケットを重要度や安定度で並び替えしているか？
これはYes。
チケット集計機能を使えば、作業の優先度、ビジネス上の重要度だけでなく、色んな観点でチケットを順序付けできる。
例えば、プロダクトバックログは、ビジネスの重要度の観点で並び替えている。

ここで「安定度」とは、Coplienの生成的パターン・ランゲージ「パターン３１：名前が付けられた安定したバージョン」を意味していると思う。

パターン３１：名前が付けられた安定したバージョン

例えば、ある要求をソフトウェア製品に反映させたい時、該当する要求に依存関係や影響があり、既存の機能を大幅修正する必要があったりする。
すると、該当の要求をそのまま反映してしまうと、システムが不安定になってしまう。
例えば、ライブラリのVerUpに伴う変更要求、新規画面を作る追加要求など。

システムが安定するように該当の要求を反映するには、例えば、機能追加のように影響が大きい要求はメジャーバージョンで先に延ばし、障害修正や小さなユーザインターフェイス修正のように影響が小さい要求はマイナーバージョンで早めにリリースしていく戦略がある。
すると、要求を安定度の順序に並び替える作業は、要求のリリース計画を作っているのと同様になる。

安定度の話をチケットに適用した場合、チケットをリリースする単位でグループ化して、順次リリースしていく戦略と同等になる。
つまり、チケット駆動開発ではロードマップというViewでチケットをリリース日ごとに並び替えていることと同じだ。

* 検証可能性

チケットは、有限のコストで評価可能な手続きが存在して検証できているか？
これもYes。
チケットの完了条件によって、チケットに書かれた要求仕様や作業内容を評価・検証している。
アジャイル開発ならば、チケットの完了条件はDoneの定義と同様だ。
開発チームが形成された時、真っ先に決める運用ルールは、何を持って作業を完了とするか、というDoneの定義になる。
開発チームが未熟な場合、チームの開発能力は低いから、Doneの定義の範囲はとても小さい。
リリースを経るごとに開発チームが成長していけば、Doneの定義は広がり、Doneの定義のレベルも上がっていく。
つまり、検証可能となるチケットの枚数が増えていくことを意味している。

* 変更可能性

チケットの変更に対して、容易かつ完全で一貫性を保って修正可能であるか？
これもYes。
チケットは開発状況に応じて変更が簡単だ。
チケットのワークフローが変わればトラッカーを変更するし、チケットの作業内容が多すぎると分かればチケットを分割すればいい。
リリース日が変わるならチケットの対象バージョンを変更するだけでいい。

チケット駆動開発の大きな利点の一つは、開発状況の変化にチケットが適応しやすいこと。
そのおかげで、開発チームはチケットにとりあえず割り込み作業は書いておけば、今の作業に集中できる。

* 追跡可能性

それぞれのチケットについて，その背景，理由，意図などが明確で容易に参照できるか？
これもYes。
「No Ticket, No Commit」の基本プラクティスでトレーサビリティを保証している。
この運用ルールこそが、チケット駆動開発の最大の特徴であり利点になる。
また、チケットには履歴が残るので、最初の要求からどのように変化して現在の複雑な要求仕様に確定したのか、という変更理由を後から追跡しやすくなる。

さらに、Redmineのようなチケット駆動ツールでは、チケットを関連付けたり、チケットの親子関係によって階層化したり、横串で全文検索できるなど、追跡可能性を補強するような機能がふんだんにある。
「No Ticket, No Commit」の運用を徹底できれば、チケット経由で要求仕様からソース、ビルドモジュールに至るまでのトレーサビリティは保証される。

【4】チケット駆動開発を要求工学の品質特性の観点から考えると、8つの特性のうち、ほとんどを満たしていることが分かる。
特に「変更可能性」「追跡可能性」はチケット駆動の利点が生きる品質特性だ。
この部分は、従来の開発プロセスでは見落としがちの大きな特徴だと思う。
しかし、「妥当性」「一貫性」の2つの品質特性は、チケット駆動開発は満たしていないことが分かる。

ここで、チケット駆動開発を運用する場合、普通は、ロードマップをリリース計画として扱い、バージョンをXPのイテレーション、Scrumのスプリントと見なして、小規模リリースを実現する場合が多い。
何故、チケット駆動開発では小規模リリースを重視しやすいのか？

その理由は、イテレーションという期間に収まるようにチケットの枚数を減らし、チケットに書かれた作業や要求仕様の網羅性、整合性を取り計らうようにしているからだと思う。
つまり、チケットの取捨選択によって、チケットの「妥当性」「一貫性」を保証するように運用しているのだ。

逆に言えば、チケットの枚数が多すぎると、どうしても、チケットの「妥当性」「一貫性」を保証する作業に工数がかかるだけでなく、作業の品質そのものも落ちるだろう。
チケットは作業スコープそのものだから、リリース対象のチケットを減らすことで、スコープを狭めて、チケットの「妥当性」「一貫性」を解決しようとしているのだ。

チケット駆動開発を運用すると、どうしてもチケットは大量に発行され、チケットを保守するのがとても難しくなっていく。
いかにチケット管理していくか、という根本問題がいつもチケット駆動開発には存在する。
その解決法の一つは、アジャイル開発における小規模リリースを当てはめることで、作業スコープを狭めて、チケット管理しやすくすることなのだろうと思っている。