最初からクライマックス！デプロイから始めよう〜テスト駆動開発をやめて、なお残すべき習慣とは(5)
イマドキの開発に不可欠な早期・頻繁なデプロイによるフィードバックの仕組みづくり
前々回にアジャイルテスト４象限で盲点を探すお話をしました。前回にフィードバックの基礎を解説しました。アジャイル４象限の肝は、複数の視点でテストを計画・実施してバグを発見し対処することです。フィードバックの肝は結果を入力に戻し循環を通じて目標に到達すること、予期しなかった障害物を発見し対処すること、前提や目標の誤りに気づき目標やゴールを変更することにあります。
今回は、実践テスト駆動開発の４章の「サイクルに火を入れる」を参考にソフトウェア開発のコンテキストでのフィードバックサイクルをスタートの切り方を解説します。
書籍４章によれば、プロジェクト開始直後に、まずやるべきことはデプロイとエンドツーエンドテストに取り組むことです。いきなりクライマックスですね。
１．プロジェクト開始直後に本番に近い環境にデプロイする
”プロジェクト開始直後からデプロイとテストを行うことで、チームはシステム全体をどうやって実際の世界に適合させていくか理解しなければならなくなる。
プロジェクト初期段階に、会議室や机上だけでの何を何故つくるべきかどうやってつくるべきかの判断は、たいてい間違いや抜け漏れが含まれています。大事なことを知らないことすら気付いていないこともあります。ソフトウェア開発において、その間違いや知らないことに手っ取り早く、具体的に気付く方法は、早期に小さくつくってデプロイし動かしてみることです。動かそうとすれば仕事のフローのエンドツーエンドが明らかになります。
”デプロイしようとしてみれば、そのためには誰と連携しなければならないかを理解できる。連携すべき相手には、システム管理者や外部のベンダーなどがあるだろう。相手がわかれば、人間関係を早い段階から築き始めることもできるだろう
デプロイして動かそうとしてみれば、個人やチーム間のコラボレーションの仕事のすすめ方の課題を早期に発見し対処できます。後からキーマンを見つけることもあるでしょう。また、個人やチームのコラボレーションだけでなく、机上ではわからなかったアーキテクチャの要素間のコラボレーションの設計判断の妥当性を、実際に動かすことで理解することができます。想定外の技術課題が見つかることもあるでしょう。
２．動くスケルトンをエンドツーエンドでテストをする
デプロイして動かすといっても、すべての機能を実装してデプロイして動かすでは数ヶ月と時間がかかりすぎます。そこで、プロジェクト初期段階ではアーキテクチャの骨組みとなる「動くスケルトン」に注目し、小さくつくって、デプロイし、疎通して機能するかをテストします。
”「動くスケルトン」とは、実際の機能をできる限り薄くスライスしたものの実装だ。そのスライスは、ビルドやデプロイ、エンドツーエンドのテストを自動化できなければならない。
もしスマホアプリ−バックエンド−外部ベンダーのコンポーネント-データベースの4要素が連携して動作するプロダクトをつくっているのであれば、その４要素を通る薄くスライスしたフィーチャを作り、本番に近い環境にデプロイし、エンドツーエンドで疎通して機能するか否かをテストします。「動くスケルトン」の構成要素は、ホワイトボードでアーキテクチャをざっくりと設計しチームでシェアします。ホワイトボード設計は細かいアルゴリズムレベルまで分解する必要はありませんが、機能だけでなく非機能もおおよそを明らかにします。求められるパフォーマンスや認証認可周りの設計判断は、システム全体に影響することが多々あります。
３．フィードバックの源泉を構築する
不確実性が高い領域では、何故つくるのか、何を作ればよいか、どう作ればよいか、そして根拠とした前提について、初期に判断したことが常に正しいとは限りません。私達にできることは、学びのためのフィードバックづくりに早期に取り組み、早期に抜け漏れや課題を発見し対処すること、思い込みに気付いて前提を見直し目標やゴールを変更をすることです。
デプロイやテストは１回だけでなく、頻繁にデプロイして評価し舵取りできるように、ビルドやデプロイやテストの仕事をソースコードで管理します。DRY原則を破っての繰り返し作業をソースコードで記述しバージョン管理すれば、デプロイやテストの自動化よって頻繁に素早く確実に実行できる効果のほか、仕事内容を明文化する効果があります。ソースコードを読めば誰でも仕事内容や仕事の期待結果がわかります。コンピューターで実行可能なので曖昧さはありません。DevOpsが広まりつつあるイマドキの開発であれば、デプロイやテストだけでなく環境構築もソースコードを使って行うでしょう。
下記は、実践テスト駆動開発に記載されたフィードバックの源泉の全貌です。
上のフィードバックのループがうまく機能していれば、個人やチーム間のコラボレーションの仕事のすすめ方の改善も、ソフトウェア要素間のコラボレーションの設計改善も要素内の設計改善も進みます。途中段階のプロダクトを通じて顧客との信頼関係を深めることもできます。ユーザニーズに適合したプロダクトに軌道修正し、事業として成功するように目指すことができます。また、ユーザニーズの変化にエンジニアが自信を持って応え続けるため、技術的負債を一定に抑えるように調整を図ることができます。
まとめ
暗黙的になりがちなデプロイやテストの作業をソースコードで管理し、頻繁に実行するようになれば、ソフトウェアの設計上の課題も、チームや組織の運営上の課題も、プロダクトが市場に適合しない課題も明らかになり対処できるようになります。
仮にドグマ的な信仰によるTDDサイクルをやめたとしても、早期のデプロイ、頻繁なデプロイのフィードバックの仕組みづくりはあらゆる課題を顕在化し対応するため重要な活動です。プロジェクト後期にビックバン結合失敗の苦い経験したことがあるなら、早期にデプロイとテスト、頻繁にデプロイとテストによって課題をあぶり出し対応するはオススメです。
次回は、実戦テスト駆動開発における、受け入れテストのループ、ユニットテストのループについて触れます。
