ITILのエキスパートからアジャル開発へ投げかけられた質問への回答
これからお伝えする内容は、ITILのエキスパートとITIL向けのマガジンに連載していたコラムにQ/Aとして掲載していた内容です。
Q. 改善を繰り返すという反復活動によって品質を上げていくということが言われているが、要件の設定があいまいだったり、テストが不十分な状況で開発を終了させたりしているのではないか？
A.
自律した規律あるアジャイル開発チームでは、品質に拘った行動ができていますので、指摘された状況にはなりません。
Q. テストの準備と判断基準が混乱するのではないか？
A.
全ての作業は開発チーム全員であたります。ゴールイメージを共有しており、開発者個人毎の理解度のギャップが起きないように、様々なフィードバック・サイクルや、スプリント毎に『完了の定義』を開発チーム全員で決めていますので、従来手法より、基準が乱れるという現象を抑制できています。
Q. 実稼働環境へ実装する回数が増え、間隔も短くなると思う。稼働環境が不安定な状態で使い続けることになるのではないか？
環境が安定しないうちに何度も展開が繰り返されると、運用面での対応が都度変わるということで混乱を招くことにはならないのか？
リリースを構築する段階でパッケージの構成が都度変わるという煩雑さで、混乱しないか？
A.
基幹系や大規模システムではリリースや移行フェーズがあり、問題を起こさないように調整可能です。また、継続的デリバリーとImmutable Infrastructureを採用するとこの問題は解消されます。
Q. 従来のリリースポリシーだと、変更の実装頻度、間隔の制約があるがこの変更には組織の抵抗がかなりのレベルであるように思われるが実現可能だろうか？
A.
ユーザー部門にこの様な手法は受け入れやすいです。なぜならば、ユーザーは欲する価値をより早く手に入れる事が出来るからです。大規模システムで運用部門との関係が気掛かりであれば、リリースや移行フェーズを通ってリリースすることで容易に受け入れられると思います。組織のポリシーが壁になるようであれば、組織全体のビジネスの永続性を基本に、各セクションの本来のあるべき姿と価値を明確にして各セクションの振舞、調整を行うべきであり、従来のリリースポリシーを守る事が良いこととは思えません。
Q. 変更の手続きと変更の認可を変えないと現状では困難だと思うだががどうか？
A.
RFC（Request for Change）を変更、改修の要求としてプロダクトバックログに登録し、スプリントレビュー時にリリース承諾を得るように進めれば問題はないです。
Q. 実装後の顧客の評価はどのタイミングでどのように行うべきなのか？
A.
理想は随時ですが、チームの活動はイテレーションサイクルで行われているので、そのサイクルに同期させて実施してください。