ウォーターフォール開発チームを真のアジャイルチームに変革する際にぶち当たった3つの壁

TL;DR

本記事では、社内マーケティング機能を開発しているウォーターフォール開発チームをアジャイルチームに移行した事例を紹介します。ただ単に開発手法を変えるだけでは、アジャイルなチームとは言えません。真のアジャイルを実現するために必要な「考え方」「関係性」「関連性」の移行をどのように行ったかご紹介します。

自己紹介

NTTドコモのデータプラットフォーム部に所属する傍田です。入社以来、約6年間にわたり社内マーケティング機能の開発に携わってきました。最初の3年間はウォーターフォール開発に携わっていましたが、4年目からはスクラムチームのプロダクトオーナー（PO）を務めています。

私が大切にしているのは「楽しくない仕事はしない」という考えです。一見するとわがままのように思えますが、「楽しくない仕事を減らし、意味のある仕事にみんなが注力できるにはどうすれば良いか」を常に意識しながら行動しています。

新チーム立ち上げ前の状態

新チームの立ち上げ前には、すでに3つのスクラムチーム（Aチーム、Bチーム、Cチーム）が存在していました。これらのチームに加えて既存の業務知識を持つウォーターフォール開発に携わっていたメンバーをシフトさせる形で、新たなスクラムチーム（Dチーム）を立ち上げました。立ち上げ時には、成熟した3つのチームの力を借りることで、スムーズな立ち上げを目指しました。

新しいチームを立ち上げる時の体制

変革過程でぶち当たった3つの壁

考え方の移行：慣れ親しんだやり方に引っ張られる

開発体制を変更し、スクラムイベントの流れに沿って進めるようにしましたが、長年の慣れがあったため、すぐに新しいやり方に頭を切り替えるのは難しいと考えていました。そして思っていた通り、発足当初はExcelでガントチャートが作成され、工程ごとの線表が引かれることもありました。

しかし、進め方がアジャイルになっていないことに対する「違和感」に気づけるメンバーがいたことでアジャイルの考え方にシフトしやすい状態を作ることができていたと感じます。

実際、私たちのチームでは、全員を既存のウォーターフォール開発のメンバーにするのではなく、3名をスクラムチームのメンバーとして、残りの2名に新規メンバーを参画させました。そのうち1名は、別のスクラムチームでの経験を3か月間持っていただき、新チームに加わった際にはスクラムマスターとしての役割を担っていただきました。このことにより、違和感に気づける人(＝既存のやり方に引っ張られない人)がチームの過半数を占め、考え方の移行がスムーズに進みました。

新しいチームを立ち上げるまでの変遷

このようなケースでは外部からスクラムマスター経験者を招きコーチをしたり、スクラムフレームワークが上手く回るようファシリテーションをしていただくのが一般的だと思いますが、既に立ち上がっているチームが存在するのであれば私たちのような方法も選択肢の一つになるかもしれません。

関係性の移行：心理的安全性が高まらない

アジャイルチームにおいて心理的安全性は不可欠とされていますが、発足当初はその水準が低かったと感じています。

ウォーターフォール開発時には製造請負の契約体系だったのでチーム変更後も依然としてPOとDevの間は発注側と受注側という意識が強く、何かを質問する際には「今、お時間よろしいでしょうか？お忙しいところ恐縮ですがご確認よろしくお願い致します。」といった敬語が飛び交っており、自己組織化されたチームとはかけ離れた状態でした。

この状態を改善するために、(「敬語禁止」を提案をしましたが、あまりにもハードルが高いと意見をいただいたので、)まずは「丁寧な文章を考える時間がもったいないので、直接話しましょう」「いつでも大丈夫なのでSlackのハドルで気軽に呼び出してください」と宣言しました。 最初は大きな変化は見られなかったものの、徐々にハドルでの呼び出しが増え、呼び出してくれたことに対して感謝を伝えることで気軽に話せる関係性が築かれていきました。この効果もあり、スクラムチームの中にあった対外的には見えていなかったピラミッド構造が、役割が異なるだけでメンバーが気軽に交流できるフラットなチームへとシフトできたように感じます。

チームメンバーの関係性推移

余談ですが最近、チームメンバー全員で焼肉に行った際、「誰かのために」ではなく、交代で「チーム全員が楽しめるよう」に肉を焼いている光景を見て良い雰囲気のチームになったと感じました。

関連性の移行：チームが単独でリリースすることが難しい

心理的安全性が高まることで、チーム内で気軽に「最近の困りごと」や「不満」を話し合う機会が増え、今まで見えてこなかった課題が浮き彫りになってきました。特に、自チーム外への依存関係が強く、コミュニケーションコストが高いことが問題として指摘されました。単に1チームをスクラムチームにしただけでは、他のチームの体制は変わらないため、自チーム単独での改善や機能追加が難しい状態が続いていました。

新チーム立ち上げ時の依存関係

私たちのチームでは機能単位でチームを分けた状態にするため他チームを巻き込みながらリアーキを続けています。 発足直後はどのようなアーキテクチャを構成・実装すべきか不安があったため、高スキルのメンバー1名に参画していただきました。そのメンバーを中心に、他チームへの依存が少ない、かつモダンなアーキテクチャを検討し、自チーム内で完結できるような状態へと徐々に変化させていきました。高スキル者がチームに留まると、チームが1名に依存する状況になりがちなので、基本的な考え方を吸収した後は別チームに移行してもらい、全メンバーのスキル向上を目指しています。

他チームとの関連性推移

今後の展望/最後に

ウォーターフォール開発チームを真のアジャイルチームにするためには

1. 考え方の移行

2. 関係性の移行

3. 関連性の移行

が必要不可欠だと思います。

私たちのチームはこれらを意識して変革を進めることで、チームの自主性・モチベーション、早期の価値提供など効果が現れてきている状態です。 実際にぶつかった障壁は他にもいくつもありますが、特に考え方の方向が一緒で、フラットなチームであればどんな壁でも乗り越えられると考えています。 この経験が皆様に活かされれば幸いです。