ウォーターフォールからアジャイルに移行する際の10の教訓
ウォーターフォールからアジャイルへの移行は、多くの組織が熱心に取り組んでいます。他の多くの企業と同様に、市場投入までの時間を短縮し、高品質のアプリケーションを提供するために、みなさんの組織でも従来のウォーターフォールからアジャイルに置き換えるために模索中ではないでしょうか。
しかし、アジャイルへの道のりは険しいものです（英文）。そこで、ウォーターフォールからアジャイルへの移行を成功させるために役立つ教訓とヒントをまとめてみました。
1．アジャイル文化を受け入れる
アジャイルはプロセスというよりも心構えです。開発チームがアジャイルを完全に受け入れるには、まずアジャイル文化を受け入れることが不可欠です。成功の鍵は、「関係者全員が何を期待されているかを知ること」、「忍耐強くあること」、そして最も重要なこととして「変化を受け入れること」です。
アジャイルは、ユーザーに最高の価値を提供するために、コラボレーションを重視した（英文）より良い仕事のやり方へとあなたを導きます。しかし、アジャイルのガイドラインをどのように実装するかは、ほとんどの場合あなた次第です。従うべき厳格なルールはありません。そのため、従来のソフトウェア開発スタイルのほとんどのチームは、この点が最も困難であると感じています。
2．役割と責任を適応させる
アジャイルへの移行は、企業内の役割と責任に影響を与えます。確かに、アジャイルは、開発者とテスターがビジネスパーソンと密接に連携することを求めます。しかし、アジャイルが求める変化はそれだけではありません。製品チーム、ビジネスアナリスト、エンジニアリング、ITなど、会社全体で、役割・責任・仕事のスタイルを変える必要があります。トップダウンの指揮命令の文化は、水平方向の会話の文化に置き換えるべきでしょう。
管理職は、阻害要因を取り除く手助けをし、チームを鼓舞し、プロジェクトのビジネスの整合性を確保します。管理職はファシリテーターとなり、チームが成長できるような環境づくりを担います。アジャイル チーム自体が専門家集団であり、誰が何をどのように行うべきかは自分たちが一番よく知っています。彼らは自己組織化（英文）し、自立しています。
3．Whole-Teamアプローチを取る
Whole‐Teamアプローチでは、絶え間ないコラボレーションが必要です。チームは最初から協力・連携する必要があります。要件定義、プロジェクトの範囲、ソフトウェアの品質を保証するために必要なものに関してです。ソフトウェアの品質は継続的なプロセスであり、関係者全員の積極的な貢献が必要です。
アジャイルチームのテスターは、すべての議論、すべてのコミュニケーション、設計の検討、そして文書の共有に関わります。これにより、設計および開発中に機能の複雑さに近づくことができます。
チームメンバー全員が、その役割に関係なく、イテレーション内で約束されたタスクを成功させることに対して等しく責任を負います。そのため、テスト、レビュー、文書化など、どんな仕事でも誰もがすぐに参加できます。
4．早期に頻繁にテストする
多くのチームが「アジャイルを採用したときに生じる最大の変化はテストプロセスである」と主張するのを目にします。テストは継続的に、常に行う必要があるのです。ソフトウェア作成プロセスのすべての段階とフェーズで、何らかのテストを考えて組み込む必要があります。
ソフトウェアはインクリメンタルに開発されるため、コードは常に変化しています。新しいコードをチェックインするたびに、そのコードが要件を満たしているか、既存の機能を壊していないかを確認する必要があります。コードを頻繁にコミットする場合、自動テスト（英文）による迅速なフィードバックが必要であり、これは自動化によってのみ実現可能です。テストを継続的インテグレーションのプロセスに統合（英文）すると、テストの実行頻度、トリガーのタイミング、およびテスト結果の通知先ユーザーを柔軟に決定することができます。目標はほぼリアルタイムのフィードバックであり、これは潜在的なエラーにできるだけ早く対応するのに役立ちます。
5．アジャイルは反復的であることを忘れてはならない
ウォーターフォール型のプロジェクトのチームは、直線的なアプローチでタスクをこなすことに慣れています。要件定義、設計、実装、そしてテストと保守というように、順番に作業を進めることに慣れています。すべてが厳密に計画され、スケジュール化されていたのです。しかし、アジャイルは直線的なプロセスではなく、増分的で反復的な性質（英文）を持っています。アジャイルでは、ソフトウェアは小さな塊 (チャンク) で開発され、提供されます。実際の市場ニーズを確実に満たすために、アプリケーションは、変化する要件に応じるだけでなく顧客・利害関係者からのフィードバックに応じて、継続的に調整されます。
そのため、必要に応じてタスクを選択・実行・手直しする上で、チームは柔軟でダイナミックである必要があります。状況を評価して次の正しい方針を決定するために、ビジネスマネージャー、開発者、テスターは緊密に協力して同期を保たなければなりません。
6．透明性のあるコミュニケーションを奨励する
アジャイルは、すべての人に発言権を与え、すべての人の意見を尊重します。これは、管理者だけが発言し、他の人は一斉にうなずくことに慣れていたチームにとって、最大の変化となりえます。チームメンバーの中には、自分の意見を述べることを求められるようになり、動揺してしまう人もいるかもしれません。
アジャイルチームは、チームが設定した高い目標を達成するために、継続的に明確なコミュニケーションを取る必要があります。アジャイル環境では、コミュニケーションを取りながら効率的に連携する小さなチームが重要です。したがって、透明性が成功の鍵になります。失敗をオープンにし、阻害要因について話し合い、一緒に解決策を考えましょう。そうすることで、チーム内に結束が生まれ、より良い製品へと発展していきます。同時に、個々のチームが孤立しないように、生産性の高いユニット間の交流を促進する必要があります。
7．テスト自動化を味方につける
アジャイルソフトウェア開発は、テストの自動化なしには成功しません。ウォーターフォール型プロジェクトではテスト自動化を余計な代物あるいは贅沢品として扱うことが多かったかもしれませんが、アジャイルプロジェクトでは違います。
アジャイルプロジェクトの各イテレーションでは、機能テストを繰り返し実行する必要があります。回帰テストを手動で実行すると、時間と労力がかかり、結果に一貫性がなく、エラーが発生しやすくなります。市場投入までの時間を短縮し、頻繁なイテレーションでソフトウェアを少しずつインクリメンタルにリリースしたいのであれば、アジャイル テストの自動化はプロジェクトの最初から不可欠な部分でなければなりません。適切に設計された自動テストは高速であり、ソフトウェア品質に関する継続的なフィードバックを提供し、リスク カバレッジを高め、アプリケーションに対する自信を与えてくれることでしょう。
8．早期のフィードバックと再計画にコミットする
アジャイルの基本コンセプトは「早く失敗して、成功するために学ぶ」ことです。そのため、最初のイテレーションで行うことはすべて、最終目標を念頭に置きつつレビューすることになります。このデモとレビューを利用した初期のフィードバックが、プロジェクトをより良く形成するのに役立ちます。
同様に、テスト自動化による早期のフィードバックも、構築中のソフトウェアの品質を示す素晴らしい指標となります。ソフトウェアのバグの発見が早期であればあるほど、その修正は容易になります。
重要なのは、自動テストから質の高いフィードバックを得るために、いつ、何を自動化するかを理解することです。コードの品質に関するフィードバックを早期に得たいのであれば、テストをShift Left (シフトレフト) し、ユニットレベルおよび中間層のレベルでより多くの自動テストを実行する必要があります。反復的なフィードバックによって、透明性を高め、潜在的な問題により早く対応できるようになり、リリースの遅延やソフトウェアの不具合のリスクを減らすことができます。
9．アジャイル変革に組織全体を巻き込む
人々は、最初からそのプロセスの一部であると感じている場合、そのプロセスを受け入れ、採用し、支持する可能性が最も高くなります。管理職とチームの両方を巻き込まずに、アジャイルのメリットを享受することはできません。
関係者全員がコミットし、効果的に参加しなければ、必然的に問題が発生します。だからこそ、アジャイルへの移行が共同作業であることを確認する必要があるのです。すべての利害関係者を巻き込み、チームの運営方法と管理職の運営方法の間に緊張が生じるのを避けるためには、コミュニケーション、関係者全員による効果的な貢献、そして継続的な計画が必要です。
10．チームコラボレーションを可能にするツールを採用する
アジャイルチームが能力を最大限に発揮して共同作業を行うためには、より新しく優れたツールが必要になります。あなたの目的は、チームが新しいプロセスを採用しやすくすること、そしてそのときにメールや文書を絶えず作成したり、変更について話し合うための会議を開いたりするための余分な負担やタスクを増やさないようにすることです。したがって、開発ツール、ソース管理、知識共有、文書化ツール、コードレビュー、テストツールなど、あなたのニーズとチームの関心に合った最適なツールを見つけてコラボレーションを容易にしましょう。
同じことが、アジャイルテスト自動化プロジェクトにおける継続的なテストとチームコラボレーションにも当てはまります。チームのためにテスト自動化ツールを選択するときは、部門を越えたチームのこの協力的なダイナミクスを促進すること、開発サイクルの早い段階でテスト自動化を開始できること、テストの再利用性をサポートすること、そしてコミュニケーションとフィードバックを促進することを実現できるかを必ず確認してください。何と言っても、あなたのチームはあなたの最大の資産の1つです。それを常に念頭に置いてください。
※この記事は、2016年12月にRanorexマーケティング チームによって公開され、2021年6月にNishi Grover Gargによって更新されました。
作者について：
Nishi Grover Gargは、企業トレーナーであり、アジャイル愛好家であり、根っからのテスターです。13 年以上の業界経験を持ち、現在、コミュニティ イネーブルメント マネージャーとしてTrifactaと協力しています。トレーニング、テスト コミュニティのイベントやミートアップの開催に情熱を注いでおり、数多くのテスト イベントやカンファレンスでスピーカーを務めています。彼女のブログ “testwithnishi.com“では、アジャイルとテスト分野の最新の話題を取り上げています。
（この記事は、開発元 Ranorex 社 Blog 「10 Lessons When Moving from Waterfall to Agile」2021年7月2日の翻訳記事です。）
