最近 シドニー とウェリントン で開かれたSDC conference（ソフトウェア開発カンファレンス）でPhilippe Kruchten教授は “あなたのバックログは何色” と題する講演を行った。講演の主眼点は、システムの機能実現とともに、アジャイルプロジェクトにおける、ソフトウェアアーキテクチャ面からの重要性に焦点をあてることである。
Kruchten教授は、アジャイル手法が、YAGNI (You Ain’t Gonna Need It:あなたにそれが必要ない)やリファクタリングに焦点をあて、そして“最後の責任の伴う瞬間” が長期に渡り重要な決断を遅らせるリスクをもたらすまで判断を委ねる姿勢をとった。 どのプロジェクトにおいても 進行中の業務に対して状況を設定するには、主要な一連の決断を早期に決定しておく必要がある。 –これらの決断のため “最後の” の責任を伴う瞬間は、プロジェクトの最初の段階で実際は存在していたことになる。
これらの主要な決断はシステムのアーキテクチャ構造の開発において遂行される。 不適当な選択（もしくは、全く意識しない選択）は、システム進化でビジネスに必要とされるものに適応できない結果となる。 これらは開発過程の初期の段階において考慮が必要となるシステムのアーキテクチャ構造に関するものである。
教授は、多くのアジャイルプロジェクトは、（ユーザーの話しで表現された）機能的な要求に注目し、 “あとでリファクターできる”という無責任な態度で、アーキテクチャ的な面を軽視しており、 “遅い” ではなく遅すぎる状態まで放置されていると主張した。
教授は、アジャイル手法を用いた金融取引システムの例を示した。
ユーザーストーリーが認識され、リリースが計画され開発が始まった。 当初の数回のイテレーションは成功し、その事は知れわたることになった。 – その機能は実現され、顧客の要求は達成され、そして、その機能はまさにビジネスが要求するものそのものであった。 一度 “最小限の項目を伴った有望な製品” を構築するために必要な機能が揃うと、そのリリースは実稼働環境に持ち込まれ、そして、プロジェクトは壁にぶつかる。– 構築された機能は稼働したが、製品は実際の稼働環境で必要とされる処理量には対処できなかった。 顧客は（停止していなかった）古いシステムに戻らざるを得ず、開発チームは実際の稼働環境における需要に対処するために製品をリファクタリングすることに立ち戻ることになった。 – 不幸にもリファクタリングは、なされた全ての仕事の完全な再構築を意味し、唯一残ったのはは画面設計だけである。 プロジェクトは結局中止となり、顧客の組織は、再びアジャイル手法を試みる気がしなくなった。
教授は、重要な事項には進展段階をみせる必要があることを認識している。–我々は、開発チームに“配管作業”に携わるような、使用者にとって視覚的な価値のない最初の2、3の繰り返し作業に時間を費やしてもらいたくない。 教授は、製品の全体リリース計画に構造条件を織り込むことが可能であることを提言し、製品が構造的な基礎や機能特徴が構築中に確保され、確実に機能性の増強や品質目標を達成できる能力を示すようにしている。 例えば、最初のイテレーションが単一の入力スクリーンの結果のみに存在するが、負荷テストは、システム構造が実環境の期待される要求を満たす予想を示すことになる。
彼は、 プロダクトのバックログ中の項目を色分けするという考えを適用し、 目に見える特徴に基づいた作業で優先順位をつけ、取り組まれるという、作業を可視化し、アーキテクチャ的な要求を確かにする技法を提示する。
教授は、バックログ中の作業は4色に分けられる事を提唱する。
- 緑 –機能な使用者の話で実現される特徴
- 黄 – 品質要求を支えるアーキテクチャ基盤/span>
- 赤– 確認され対処が必要とされる欠陥
- 黒– 製品が組み立てられる時に蓄積される技術的な不足、そして、主要な決断を遅らせる、あるいは、出来の悪い仕事がなされること
図: バックログの４つの色
肯定的 対 否定的 と 目に見える・見えない特徴
緑の構成要素は、視覚的な特徴であり、製品のバックログリストで最も頻繁に見る事ができる‐使用者の話（User Stories）は、製品において実現される機能性を定義するものである。これらは、最終製品の使用者が見る事ができるものである。
作業の黄色部分は使用者には見えないが、製品全体にとって重要な価値を提供する。 これらは以下の機能を含む
- アーキテクチャ
- 構造基盤
- 共通要素
- ライブラリィ
- 枠組み
- 再利用可能な要素作成
黄色部分(価値を伴うが見えない作業) は製品のバックログやリリース計画で明確にされる必要があるため、プロジェクトのステークホルダーは、視覚化できる特徴に沿って、その事柄を優先順位を知る。
赤色部分 (見る事が出来る欠陥) は製品が開発された時に挿入される。 – 理想的な状況では、赤い要素は殆どないが、全くないとまでは言い切れない。
黒色部分 (技術的な不足) は、黄色が無視された際に生じる。つまり、技術的不足は、プロジェクトが以前のコードを基に進められた際に、前の仕事の不足が蓄積されているかもしれない。
最初のリリース計画をたてる際には、緑と黄色の要素に対して計画することは重要である。 –目に見える特徴にのみ焦点を当てることは、製品が素晴らしく見えるようにはできるが本番環境への適応は行われず、あるいは、現実のセキュリテイ上の脅威には対処していない。 同様に、黄色のみに焦点を当てることは、BDUF（大きな当初の設計）へ戻ることになり、プロジェクトが遅延し顧客との約束が失われるまで、視覚できる価値の実現に遅延を生じさせることになる。
教授は、リリース計画を構築することは、このイメージの様に –“ジッパーの様に”機能と構造的な要素を一緒に織り込むように 構築することを推奨している。
図:ジッパーの様に、 目に見える価値と見えない価値をマージするようにリリースプランを立てなさい。
赤と黒 (見える欠陥や技術的な不足) は、初期のリリース計画にはあらわれないだろうが、それらは計画に存在する速度（達成された仕事の割合と実現される価値）において重大な影響を持っている。
欠陥は、実用的で実行可能である場合、発見されると同時に取り組む事が必要となる。解決せずに放置すると悪化し、結果として、以後に取り組む場合よりも大きな影響を与えることになる。 数度のイテレーション後、チームは、欠陥発生率がどれほどになるかを理解することになり、そして、欠陥を出来る限り計画された発生率に近づけるような計画された速度へ調整することが可能となる。
計画が既に分かっている技術的な不足を伴って開始される場合、計画を実行する際にはその事が考慮されなければならない。– 古いコードを基にする事は、既に存在する欠陥を隠してしまう可能性があり、それらのコードは容易にはりリファクタリングされず、価値実施率は隠された製品品質によって減少することになる。
新しいプロダクトを作る際には、当初の技術的な不足は存在しないが、リスクを招く可能性が生じる。 欠陥を修正することを遅らせることは、黄色要素を無視することになり 技術的な不足の蓄積の結果として起こる 主要な決断を“最後の責任の伴う瞬間”まで遅らせ そして、価値実施率まで減少させることになる。
欠陥や技術的な不足はプロジェクトの過程で発見され, プロジェクトチームにそれらを見させる事が重要となる。 –従って、その事によってバックログの色コード化のコンセプトにたどり着くことになる。 欠陥を示し、技術的な不足を減らす為に、新しい話を製品バックログに追加される事が必要になる。
彼は、基本計画一覧にどのような種類の作業がなされねばならないか、はっきりさせるために、色コード化する事を強く推奨している。 – 新しいユーザー機能、 構築要素、修正すべき欠陥、あるいは、注意を必要とする技術的な不足などがある
バックログに色を着色し、製品開発の4つの面を明確にすることで、プロジェクトのより現実的な計画と推移の把握が達成可能になるであろう。
あなたのバックログは何色か – 全ての作業を可視化するためにどの技法を用いるか？