InfoQでは今回，DBmaestro共同創設者でCTOのYaniv Yehuda氏にインタビューして，彼らがアジャイル開発をどのように実行し，DevOpsを利用しているのか，継続的デリバリや困難だと言われるアジャイルプラクティスをどのように実践しているのか，さらにはアジャイルやDevOpsプラクティスを使うことによって得られているメリットについて聞いた。
InfoQ: DBmaestroでどのようなアジャイル開発を行っているのか，これまでの経験をInfoQ読者に説明して頂けますか？
Yehuda: 数年前まで私たちは，ウォーターフォールモデルで開発をしていました。大規模なバージョンを長期の開発サイクルで作り上げて，たくさんの機能を時間を掛けてテストしていたのです。
機能改善を提供するのがとても難しく，“次のリリース”にバンドルされるのが常でした。ユーザとしては，要求した機能や改善点を，何ヶ月も待たなくてはならなかった訳です。リリース期限に間に合わないことも多々ありました。決してやるべき仕事をやっていなかった訳ではありません。何をするにしても，いつも予想以上に複雑で大規模になる上に，事前にブレークダウンしておくのも難しかったからです。
ユーザからのフィードバックを得るのも大変でした。彼らにとって納得できる機能を“紙の上で”提案しても，ユーザには私たちが作るものを“感じる”手段がなかったのです。相当な規模の機能が開発されただけで，まったく使われないことが，少なくとも1回はありました。提案された時点では意味のある機能だったのですが，実現方法が実用に耐えないものだったのです。
私たちはアジャイル開発に移行して，2週間のスプリントを実践することにしました。そうすることで，作業を管理可能なサイズのタスクに分割して，それまでよりも小さな開発単位に集中できるようになりました。メリットは３つの部分ですぐに現れました。
- タイムライン見積能力の向上: タスクが小さく，よりスプリントに関連したものになったことで，重大なミスをする可能性が少なくなったのです。
- テストサイクルと開発者へのフィードバックの大幅な改善: 以前より短いスプリントで効率的なテストが可能になり，動作するものとしないものを素早く判断できるようになりました。さらに問題やバグ，課題に関するフィードバックが比較的早く手に入ることで，修正がそれまでより早くできるようになりました。
- 上記の結果として，製品の品質，開発プロセスの可視性が向上しました。
最終的に私たちは，計画するタスクに従ってスプリントの長さを開始前に決定するという，フレックスタイプのスクラムを実施することにしました。通常は2週間のスプリントを実行しますが，場合によって１週間あるいは3週間に変更するのです。私たちにとっては，固定期間のスプリントよりも効果的であることが分かっています。純粋主義者は“それはスクラムではない”と言うかも知れませんが，それは本質的な問題ではありません。最短の市場リードタイムの達成，大規模な機能開発とのダイナミックなバランスなどを考えた時，私たちにとってはこれがベストなのです。
InfoQ: DevOpsプラクティスを始めた理由は何ですか？
Yehuda: 他に選択の余地がなかったのです。アジャイル開発への移行だけでも改善であることは確実なのですが，それですべて満足できた訳ではありませんでした。
ユーザに対して，短期間の開発サイクルで機能を提供することができなかったのです。 開発サイクル自体は短かくて効率的でしたが，“リリース可能”なものがありませんでした。製品全体を短期間でテストするというのは現実的ではなかったので，結果として，ユーザに対する“製品リリース”のためのスプリントが積み重なったのです。
DevOpsの導入は，２つのカテゴリに分割して行いました。
- 製品面やユーザニーズ，長期的目標といったものに，開発を確実に結び付けるようにすること。会社全体として，ユーザの価値を議論の中心に置くためには，この結び付きが非常に重要です。
- 継続的デリバリの実践。
- 開発プロセス，テストプロセス，最終パッケージングといったプロセスを，基本的には可能な限り自動化します。
- リリース可能な機能の個々が明確に定義されていること。これはすなわち，ユーザ価値の明確な定義があるという意味にもなります。
DBmaestroはデータベースソース管理とデプロイメント自動化のソリューションなので，自分たちの開発したものを利用するチャンスがあります。自社のソリューションを次バージョン開発で使用するのです。そのこと自体が，単に理論上の品質保証時間だけでなく，それぞれの機能が開発された目的に応じた，実践的でエンド・ツー・エンドな利用時間を費やしているという意味を持つことで，品質の水準を可能な限り高められます。
InfoQ: 継続的デリバリの実践方法について，詳しく説明してください。どのようなプラクティスやツールを使用していますか？
Yehuda: トランクベース開発を実践しています。すべての変更を，その時点のトランクに対して行うのです。ブランチは作らないようにしていますが，必要な場合は，最初にすべての変更をトランクに導入した後に，関連するブランチにピギーバックします。
使っているツールはMS-TFSビルドサーバとJenkins，データベース側に関しては，私たちのDBmaestroです。ビルドプロセスが始まると，テストマトリクスが実行されます。すべてが正しく動作すれば，安定版パッケージとしてWebサイトにアップロードします。
InfoQ: 実行してみて難しいと分かったアジャイルプラクティスはありますか？ その中で，実施を断念したものはあるのでしょうか？理由も教えてください。
Yehuda: 自動テストですね。間違いありません。
ユニットテストを試しましたが，あまりにも開発速度を遅めてしまう，という結論に達しました。新しいプロジェクトでユニットテストを作成するのは効果的ですが，私たちの大規模なコードベースを改造するのは，時間やコストの面で合理的ではなかったのです。
テスト駆動の自動化ツールも使ってみましたが，これもプロセスのビルドごとに時間が掛かり過ぎる上に，テストツールでシナリオが正常動作する頃には，その結果が無効になるような変更が加えられる，といった状況でした。重要な期限に間に合わせようとしてテストシナリオ更新を無視すると，後になってそれが致命傷だと分かる，といった有り様だったのです。
結局のところ，私たちの製品はバックエンド処理が中心なのです。GUIはそれ程多くありませんし，変更は専ら”エンジン”に実装されます。そこで私たちは，可能な限り譲歩することにしました。すべてのテストを自動化しようとせず，手動テストの範囲を少なくし，ユーザインターフェースの影響を抑えて，新たな変更によって壊れた部分のないことを確認するための退行テストを重視したのです。非常に大きなシナリオマトリックスを作り，その配列に沿って製品を実行することにしました。このように，最初から最後まで実行可能なテストを構築することで，全体としての成功あるいは失敗という結果が明確になりました。もし失敗したとしても，その原因は非常に明解です。
InfoQ: アジャイルやDevOpsプラクティスを取り入れたことで，どのようなメリットがありましたか？いくつか例を挙げてください。
Yehuda: 私たちは，ユーザ重視のアプローチと迅速な対応に誇りを持っています。拡張，変更，修正を迅速に行うこと，そしてユーザニーズへの対応です。
数週間前にあるユーザから，私たちのアプローチとは違う方法である問題を扱ってほしい，という要求がありました。そのユーザは，次のアジャイルスプリントでその機能を使いたいと思っていたので，自身の望む仕様で実行されることが非常に重要だったのです。タスクに対してアドホックチームが割り当てられ，必要な修正とテスト，全体の退行テストを実施しました。そして翌日には，修正プログラムのパッケージを提供することができたのです。
優れたプロセス，そしてそれを可能にした効果的なオートメーションという，顧客価値重視の明確な勝利でした。
私の見たアジャイルとDevOpsプラクティスのメリットは，単純だが効果的なひとつのエクスペリエンスにすべて集約されます – アジャイル企業になる，ということです。