あなたのアジャイルにウォーターフォールが忍び込んでいませんか？ 7つのサインを見つけよう！

Agileはビジネスの世界で旋風を巻き起こしています。顧客中心主義、迅速な市場投入、革新を促す環境への注力が、ますます多くの組織をAgileの導入へと駆り立てています。しかし、Scrumや他のAgileフレームワークを使用していても、期待通りの結果が得られなかったり、チームにAgile精神が浸透していないと感じることがあります。

まず明確にしておきたいのは、ウォーターフォール方式そのものに問題があるわけではないということです。実際、一部のプロジェクト（例えば建築プロジェクトなど）には完全に適しています。しかし、Agileを目指しているにもかかわらず、結果的にウォーターフォール的なアプローチになってしまうのは問題です。この「隠れたウォーターフォール症候群」をどう診断し、どのように対処すれば良いのでしょうか？この記事では、その答えを探っていきます。

#1 症状: 機能別チーム構造

それは何か？機能別チーム構造では、プロダクトやその一部を共同で開発する代わりに、各チームが設計、コーディング、テストなど開発プロセスの特定のステップに集中します。それぞれのチームがAgileフレームワークをきちんと実行している場合でも、最終的には他チームに作業を引き渡し、製品を完成させるために絶えず調整が必要になります。

なぜ悪いのか？このアプローチには、いくつかの落とし穴があります。調整が非常に大変で、製品完成のためにガントチャートやプロジェクト計画が必要になることが多く、これは典型的なウォーターフォール的手法です。また、各チームは自分の作業部分だけに責任を持ち、全体的な顧客体験を監督する人がいません。その結果、新しい機能やプロダクトのエンドツーエンドの提供には何ヶ月もかかり、たびたび優先順位が後回しにされます。

どうすれば良いのか？解決策は、製品の提供に必要なすべてのスキルを備えたクロスファンクショナルチームを構築することです。プロダクトが大きすぎて1つのチームでは対応できない場合は、製品の特徴やサービスエリアごとにチームを編成することを検討してください。ただし、機能別にチームを分割することは避けてください。このようにすれば、Agileの中心にある機敏さとコラボレーションを維持し、ウォーターフォール的なアプローチを排除できます。

#2 症状: 横断的な作業の切り分け

それは何か？最終製品をケーキに例えると、デザイン、機能性、テストといった多層構造を持つものだとしましょう。すべての層を顧客に提供するのが難しい場合でも、すべての層とフロスティングが揃ったスライスを提供し、顧客に味見してもらい、フィードバックを得たいものです。この「スライス」が特徴を表し、ケーキのすべての層を縦に切り分けたものとして、顧客価値を提供します。しかし、チームはコスト削減のために作業を横断的に分割することがよくあります。例えば、最初にすべての機能を設計し、その後すべてを実装する、という具合です。

なぜ悪いのか？一見時間を節約する方法のように思えますが、実際には時間の罠です。例えば、何週間もかけて完璧なチョコレートケーキを作ったと思ったら、顧客がチョコレート嫌いだった、という事態が起こるかもしれません。Agileでは、ケーキ全体を作るのではなく、一切れずつ焼いてテストすることを推奨しています。このアプローチは資源集約的に見えるかもしれませんが、仮説を迅速に検証し、柔軟に方向転換する能力を提供します。

どうすれば良いのか？ユーザーストーリーが解決策を提供します。これは作業を構造化する唯一の方法ではありませんが、作業を縦断的に切り分ける際に非常に効果的です。また、各作業項目の顧客価値を明確に表現することを常に心掛けてください。たとえば、「ボタンを設計する」というタスクには明確な価値がありませんが、「退会機能を導入する」というタスクは顧客に明確な価値をもたらします。作業を縦断的に分割することで、すべてのインクリメントが具体的な価値を提供し、真のAgile環境を育むことができます。

#3 症状: 固定されたロードマップと計画

それは何か？四半期内にリリースすべき具体的な機能やその順番が最初から明確に定められており、そのスコープが固定されています。スプリントを計画し、バックログを優先順位付けすることはできますが、チームが特定の機能セットを必ず提供するという期待があります。また、他のチームとの依存関係によって厳密なタイムラインが設定され、柔軟性が制限されることもあります。

なぜ悪いのか？Agileの大きな利点の1つは、状況の変化に適応し、顧客から継続的に学び、改善し、必要に応じて方向転換できる能力にあります。固定されたスコープは、この柔軟性を損ない、実験や環境の変化に対応する可能性を妨げます。

どうすれば良いのか？大規模な計画（年間計画や四半期計画）は重要ですが、それを指針として使用し、絶対的な命令として扱わないようにしましょう。各チームが計画を調整し、外部の依存関係を動的に管理できる柔軟性を持つべきです。私の経験では、OKR（Objectives and Key Results）はこの課題を解決する優れた方法です。具体的な機能（アウトプット）ではなく、ビジネス価値（アウトカム）に焦点を当てることで、Agileの原則により密接に一致する計画が可能になります。

#4 症状: 大規模リリースとマイルストーン

それは何か？機能に柔軟性がある場合でも、マイルストーンやリリース日が設定されている場合、ウォーターフォール的なアプローチがAgileの中に忍び込む可能性があります。管理者が「チームを奮い立たせる」や「早いリリースを促進する」といった理由で人工的な期限を設けることがありますが、皮肉なことに、これらは逆効果を招くことがよくあります。

なぜ悪いのか？締め切りを守るためにチームがプロジェクト管理のトライアングル（スコープ、予算、スケジュール）の圧力にさらされると、スケジュールがタイトになることでスコープに影響が出ます（または予算に影響することもありますが、現実的には予算の調整は難しいことが多いです）。これにより、チームは顧客価値の最大化よりも時間制約を守ることに重点を置くようになります。また、締め切りのストレスはチームの健康や個々のモチベーションに悪影響を及ぼし、革新的なアイデアやソリューションは「余計な仕事」と見なされがちです。

どうすれば良いのか？直感に反するかもしれませんが、期限を廃止し、各チームが独自のスケジュールを決定できるようにしましょう。この点で再びOKRが役立ちます。具体的な成果を達成することに焦点を当てることで、チームは自身のパフォーマンスに責任を持ちながらも、何に取り組むべきか、どの順序で進めるべきかを自由に決められる環境を作ることができます。このアプローチはAgileの精神に一致し、生産的かつストレスの少ない環境を促進します。

#5 症状: メトリクスや調査結果が計画に反映されない

それは何か？Agileフレームワークを実施し、スコープに柔軟性を持たせている場合でも、学んだことを即座に作業に反映していますか？顧客調査やテスト結果を収集しても、惰性で当初の計画通りに進むチームが少なくありません。この「隠れたウォーターフォール」思考の明確な症状は、変化する環境への対応能力の欠如です。

なぜ悪いのか？新しい知見に反応しないことで、大きなチャンスを逃すリスクや、誰も必要としていない施策に時間を費やすリスクが高まります。新たな証拠が示す方向に進まず、初期計画に固執するのは、イノベーションや顧客満足度を妨げる確実な方法です。

どうすれば良いのか？新たな知識はすべて計画プロセスに影響を与えるべきです。予期しなかったチャンスを活用する場合もあれば、顧客に不評な機能を廃止する場合もあります。これらの調整を迅速に行うことが重要です。計画会議は、最新の分析結果を確認し、顧客や市場と一致した製品優先順位を確保するところから始めましょう。つまり、データに基づいてAgileアプローチを推進するのです。

#6 症状: アウトプットがアウトカムより重視される

それは何か？チームが「物事を完了すること」に集中しすぎて、「成果を達成すること」を疎かにしている場合、成功への道筋を外してしまいます。例えば、日本ではこの問題が顕著です。イノベーションをもたらす効率的な解決策を考案した人よりも、日々残業をしている（実際はあまり効率的でない）同僚が「よく働いている」と評価され、昇進することが少なくありません。しかし、Agileでは「よりハードに働く」のではなく、「よりスマートに働く」ことが目指されています。

なぜ悪いのか？アウトプットを優先する文化は、誤ったインセンティブを生み出し、量が質を凌駕する状況を招きます。アウトプット重視の環境では、顧客価値を最大化する創造的なアプローチが阻害されます。「多くの機能を提供する」ことが目標になり、結果として顧客に価値のない一貫性のない製品が生まれることになります。

どうすれば良いのか？再びOKR（Objectives and Key Results）が最も効果的なツールとして登場します。チームメンバーが個別の目標を設定する際、それらがチームの目標と一致し、アウトプットではなくアウトカムに焦点を当てることを確保します。つまり、重要なのは「どれだけやったか」ではなく、「やったことでどれだけの成果を生んだか」です。

#7 症状: 心理的安全性の欠如

それは何か？心理的安全性が欠如している環境では、チームメンバーが自由にアイデアを共有したり、計画に疑問を呈したり、互いにフィードバックを提供したりすることができません。また、失敗のリスクを恐れるあまり、チームは実験を避けます。失敗が「絶対に避けなければならないもの」として扱われているのです。

なぜ悪いのか？心理的安全性の欠如は、多くの素晴らしい機会を失う原因となります。潜在的に素晴らしいアイデアが共有されず、悪い決定が行われても誰も口を挟むことができません。また、実験が妨げられ、学びが限られるため、フィードバックという個人の成長に不可欠なツールが活用されません。さらに、このような環境では、快適で生産的な作業ができるはずもありません。

どうすれば良いのか？心理的安全性の育成はリーダーシップから始まります。リーダーは模範を示し、脆弱性を見せることを恐れず、「失敗しても大丈夫」というメッセージを伝えましょう。実験の成果そのものだけでなく、「試みそのもの」を評価してください。また、失敗をオープンに議論し、それを学びの機会として扱う文化を作り出すことが重要です。

結論

最後にもう一度強調したいのは、適切な文脈で意識的に選ばれたウォーターフォール方式には何の問題もないということです。しかし、意図せずにAgileの中にウォーターフォールが忍び込んでしまうと、それは大きな障害となり得ます。

この記事を通じて、隠れたウォーターフォールがチームにどのような悪影響を及ぼすかを理解し、それに対処するためのツールや方法について学んでいただけたことを願っています。

Agileはゴールではなく旅路です。それは、目標を達成し、より多くの価値を提供するための単なる作業方法です。100%のAgileを目指して執着するのではなく、自分自身とチームにとって最適な方法で効率を最大化しているかどうかを常に問い続けてください。皆さんのAgileジャーニーの成功を祈っています。頑張ってください！