連載第2回: ウォーターフォール開発からアジャイル開発へ切替えた際のよくある失敗事象

連載第2回: ウォーターフォール開発からアジャイル開発へ切替えた際のよくある失敗事象

メンバーズエッジカンパニー 社外アジャイルコーチの中野 安美です。ブログを見ていただきありがとうございます。
このブログをご覧になっているみなさんの会社ではアジャイル開発はうまく進んでいますか?「いやいや、中々難しいですね」という会社が多いのではないでしょうか?

今回はウォーターフォール開発からアジャイル開発へ切替えた場合によく起きる事象とその要因、そして成功させるためにはどうすればよいかをご紹介します。

アジャイル開発が失敗した事例

アジャイル開発がうまくいかなかったケースとして次のような例があります。

  • アジャイル開発を試すために、小さなプロジェクトでやってみたが、どうしたらいいのか?何が良いのかわからず止めてしまった。
  • ユーザーからの変更要求が頻繁に発生する業務のため、システムリニューアル案件でアジャイル開発を80人体制でやったが結局はウォーターフォールのようになってしまった。
  • 最初の計画時に要件が決められそうにないためアジャイル開発を選択したが、開発途中で変更が入り続けて開発が中々進まず、途中で一時中断して仕切り直すこととした。

みなさんの会社でもこのような事例はないでしょうか?

アジャイル開発が失敗した要因

残念ながらうまくいかなかったチームの要因としては、次のような5点が考えられます。

1.アジャイルやスクラムを理解しないまま導入している

タイムボックスやデイリースクラムなどスクラムのプロセスだけを取り入れて、単にイベントをやっているだけになり、何のためにやっているかを理解していないケースがあります。また、一部のプラクティスだけを取り入れているケースもよくみかけます。

例えば、レトロスペクティブ(ふりかえり)によるプロセス改善を継続して実施することはスクラムチームにとって重要な取り組みですが、ふりかえりも行っていないチームもあります。

アジャイルやスクラムについてチームメンバーは理解していても周囲のステークホルダー(経営層や組織責任者、品質管理部門など)が理解していないケースも多くあります。アジャイルがうまく回りだすと、社内ルールやサイロ化された組織など会社や組織の課題にぶつかります。周囲の理解がなければ改善が進まず、成果がだせない大きな原因にもなります。

2.プロダクトオーナー、スクラムマスター、チームの役割が浸透しない

「プロダクトオーナー」「スクラムマスター」は、今までのウォーターフォールにはない新たな役割になります。また研修で学んでも実際にやってみると「この場面ではどう動けばいいの?」「何をしなければない?」と悩むことも多くあり、実際に体感しながら理解を深めていくしかありません。

また、スクラムチームは自己組織化したチームにしていく必要がありますが、プロダクトオーナーまたはスクラムマスターがプロジェクトマネージャーのような振る舞いになって細かな支持や管理統制をしてしまい、自己組織化を阻害してしまっている場合もあります。

3.発注者と受注者の意識、関係性が変わっていない

今までユーザー企業が発注者、ITベンダーが受注者だった場合、プロダクトオーナーは発注者企業、スクラムマスターと開発チームはITベンダーのメンバーでチーム構成するケースを見かけます。

この場合、従来は発注者企業が要件を指示してその結果の報告を受ける、そしてITベンダーは指示のもとで開発をするという役割でした。しかし、スクラムチームはプロダクトオーナーも含めてチームの仲間でフラットな関係性となります。スクラムチーム全員一緒になって、プロダクトをよくするにはどうしたらいいか?どうすれば生産性を上げる事ができるのか?チームとしてどのような学習をすればいいか?など長期目線でプロダクトとチームの成長を考えていく必要があります。

4.プロダクトバックログが適切に管理されていない

今までのウォーターフォール開発では、最初にスコープを決めて要件定義を行います。全ての要求事項を開発する前提の考え方です。しかし、アジャイル開発は優先度の高いものから順番に開発し、「価値あるものを届ける」「ムダなものを作らない」ようにしていきます。

今までのウォーターフォール開発では要件を細かく分解して優先順位をつける事をしていないため、最初はどのように要件を分割したらいいか?優先度をどのようにつければいいか?など大変戸惑います。プロダクトオーナーはプロダクトバックログの分解の仕方、粒度、書き方などを実際にやって慣れていく事が必要になります。早く価値の高いものを届けられるようになるためには、プロダクトバックログの管理は非常に重要です。

5.開発チームが指示待ちの姿勢になっている

ウォーターフォール開発では、要件定義→設計→実装→テストと決められた成果物が次の工程に渡されていきます。つまり前行程の担当者に聞くスタンスになりがちです。また、リーダーによりガントチャートが作成されて誰がどのタスクをやるのか割り振られるケースも多いため、チームといえど与えられたタスクを個人作業でこなしていくことが多いように思います。

アジャイル開発を始めて最初のころは、開発チームからの質問や発言が少なく、プロダクトオーナーやスクラムマスターへの依頼事項も少ない傾向があります。これにより、プロダクトオーナーと認識のずれが起こるなど問題事象にもつながります。コミュニケーション量と生産性は比例するという分析結果(※1)もあり、スクラムチーム内でのコミュニケーションを上げていくとチームパフォーマンスによい影響を与えます。

上記のような要因が絡み合うことで、結果的にアジャイルがうまくかない結果となる事が多いのですが、きちんとチームがマスターすれば、高いパフォーマンスを実現でき、メンバーもモチベーション高く働くことができるよいやり方だと思います。

※1 ジェームス・コプリエンがボーランド社のQuattro Proチームの分析結果からコミュニケーションと生産性の相関性を述べており、スクラムチーム内でのコミュニケーションを上げていくとチームパフォーマンスによい影響を与えると言われています。

アジャイル開発を成功させるにはどうすればよいか?

アジャイル開発を成功させるために、まず次のことを試してみていただきたいと思います。

1.アジャイル、スクラムを知る

まずはチーム全員でアジャイル研修を受講して概要を理解しましょう。加えて、プロダクトオーナーやスクラムマスターは認定トレーニングを受けて、更に役割として何をしなければならないか理解を深めましょう。

また、経営層や管理職などステークホルダーにも研修を受けていただき、きちんと理解していただくことも必要です。まずはスタートラインに立つために正しく学ぶことが大切です。

2.実際に学んだことをやってみる

実際にやってみる事で、やり方を体感し、各イベントの目的や効果を実体験で学び、腹落ちしていきます。そして、自分たちの仕事でどう適用させていくのが効果的かを試しながら決めていきます。スクラムはフレームワークが書かれた“ルールブック”です。そこから自分たちの仕事でどういう戦略で戦っていくか“プレイブック”を作ってみてください。

3.アジャイルコーチを活用する

失敗の要因には、そこに関わる人々の考え方と行動を大きく変える必要のあるものがいくつかありました。プロダクトオーナーやスクラムマスターの思考や行動、開発チームメンバーの姿勢、発注者と受注者のマインドチェンジ。それらを変えていくには、当事者だけでなく、第三者が入ってその場の状況、発言内容、行動を実際に見ながら、アドバイスしていく事が効果的です。

本人が気づかないことに気づきを与え、第三者だからこそフラットな立場でアドバイスできます。また、現場に応じたスクラムイベントのやり方のアドバイスなど自分たちにマッチしたやり方を早期に見つけていくことが出来ます。

4.仲間をつくる

アジャイル開発を始めると色々な障害にぶつかります。チームの成長段階を示すフレームワーク「タックマンモデル」では形成期のあと混乱期が訪れますが、どのチームも必ずこの混乱期を乗り越える必要があます。そのためには一人で考えこまず、仲間をつくって相談できる環境があるといいでしょう。

最後に

社外のコミュニティ活動やセミナーも多くありますが、社内で他のアジャイル開発チームメンバーと交流したり、社内コミュニティをつくると社内共有の課題解決につながったり、社内全体としてノウハウの蓄積にも繋がります。

みなさんもアジャイル開発を身に着けて、強いパフォーマンスを発揮できる強いチームをつくっていきませんか?

「アジャイル開発を導入したい」「アジャイル開発がうまく機能していない」とお悩みの企業様向けにアジャイル開発相談会も開催しておりますので、どうぞお気軽にご相談ください。

採用情報

メンバーズエッジで最高のチームで最高のプロダクトを作りませんか?

最高のプロダクトをつくる 最高のチームで働く

在宅でも、地方でも、首都圏でも。多様な働き方で最高のチームをつくり、お客様のプロダクトパートナーを目指します。アジャイル開発を通じ、開発現場の第一線で活躍し続けたいエンジニアを募集しています。