チーム開発
アンチパターン
scrum
スクラム
スクラムマスター

ウェブクルー AdventCalendar 1日目の記事です。

今年のウェブクルーアドベントカレンダーは @noko_k からスタートします!よろしくお願いします。

この記事は、株式会社ウェブクルーが スクラムを導入する過程で失敗したこと と、改善に向けて再スタートをしたことの2つについて書いていきたいと思います。まだ改善は始まったばかりですので、「これでうまく行った!」という内容の記事ではありませんのでご了承ください。

スクラムを導入したけどうまく行かなかったチームへ、再スタートを踏み出すヒントや背中を押せるものとなればと思っています。1


背景と私について

ウェブクルーでは、長らく社内受託開発 × ゆるやかな2ウォーターフォール型の開発が行われており、その開発は10〜15人の(非技術者を含めた)チームで進行していました。会社の歴史はそれなりに長く様々なサービスが立ち上がっているのもあり、開発チームのメンバー数よりもサービスの数の方が多いという環境です。そのため、1人が複数のサービスを掛け持ちして担当し、サービスごとに依頼を受けるために複数の作業が並行して行われるということがよくあります。

システムの老朽化等によるメンテナンス難易度が増加する中、サービス要求は高度なものになり複数サービスからのリソースの取り合いに至る...が日常茶飯事となっていました。それらのやりとりに伴う調整コスト等も問題となっており、3年ほど前にスクラムが導入され、少し遅れてカンバンが(追加で)導入されました。

@noko_k は2015年に新卒で入社したバックエンドエンジニアです。今年の10月に担当が変わり、今のチームにJoinしました。

Joinしたまでは良かったのですが、そこにあったのはスクラムのスの字もない開発フローでした。スクラムは崩壊しており、形だけの取り組みが続いてしまっていました(意味のあるものももちろんありましたが)。前に居たチームではスクラムの恩恵をそれなりに享受していたために、「さすがにこの状況はどうにかならないものか?」と考え、行動したのがきっかけです。

メンバーにヒアリングを実施し、整理した結果「ここがダメだったんだな」というポイントが出てきました。


アンチパターン


カスタマイズ済みスクラム


コンテキスト

スクラムを導入しようとしましたが、説明をしても反応があまり良くありません。メンバーに理由を聞くと、「うまく行くイメージがどうも沸かない」、「既存の業務フローからのギャップが大きく、他部署とのやり取りが面倒になる」、「混乱してしまいそうだ」という声も上がりました。そこであなたは、反応があまり良くなかった取り組みをスクラムから取り除いたり、既存フローに合わせた形に変形したりしてスクラムを導入しました。

結果、スプリントを何回か回してみたものの、しばしば「結局これ何でやってるんだっけ?」という声が上がるようになり、改善した感覚や施策の納得感が無いまま進むこととなってしまいました。


解決策

元々達成したかった目的は、「スクラムをスムーズに導入し、無用な混乱を避ける」ことでした。どうすればよかったでしょうか?


1. 丁寧にヒアリング、説明を行う

「イメージが沸かない」というメンバーが居るときは、そもそもスクラムをメンバーにうまく説明できていない可能性があります。この状態のままスクラムを導入することや次のイテレーションに進むことは避けるべきです。皆が納得し、チームが抱えている課題が解決し、希望を持ってスクラムに取り組めるよう行動します。具体的には、どこで理解が出来なかったのかを確認し、ズレてしまったのがどこだったかを把握できるようにヒアリング等を行います。その上で、追加の対策を打つなどをします。スクラムが解決することではない問題が障害となるケースも往々にしてありますが、うまくマネージャーなどと連携を取ることで問題を回避する必要があります。

注意が必要なのは、単にやる気の無いメンバーです。維持するコストは大きく、コストの割にはパフォーマンスが上がらないのは言うまでもありません。このことが分かったら、そのメンバーに対してモチベーションを下げている要因を分析して対処します。スクラムなどとは全然関係ないことの方が多い感覚があります。スクラムやチームだけでの対処が難しい場合は、より上位の職位につく人に相談を行い支援を受けながら行動するなどの別の取り組みが必要です。重要なのは、誰が行動するにしても、丁寧かつ建設的に進めることを心がける必要がある点です。


2. 段階的に変更する

注意深く話し合った結果、認識にズレが無いことがわかりました。そしてあなたは今、既存の業務フローとスクラムをそのまま掛け合わせると問題が生じる可能性が高いことを理解しました。

この場合は、既存の業務フローと照らし合わせて、大きく変わるところは話し合って現時点でのベストな改善を話し合いながら探ります。ここで重要なのはスクラムと既存フローとのギャップを少しずつ埋めていくことを宣言し、より良い方向を探ることです。


とりあえずアサイン


コンテキスト

知識があったり、勤続年数が長いメンバーは、"とりあえず"でデイリースクラムやスプリントレビュー、計画にアサインされることがあります。アサインしてもらった側のメンバーは、そのベテランメンバーがいることで安心しますが、アサインされたベテランメンバーは、チームに対してコミットすることが特に決められておらず、なぜ自分が参加しているのかを理解できません。


解決策

元々の目的は、「ベテランメンバーをアサインすることで安心感を得たい」でした。

そのベテランメンバーが開発チームやプロダクトオーナーとしてアサインされているのであれば問題ありませんが、それ以外の理由で全然関係ないチームのメンバーを「ちょっと話を聞いていて欲しい、なんかあったら突っ込んでほしい」程度の理由でスクラムにアサインすることは避けるべきです。どのように解決したら良いでしょうか?


1. メンバーが抱える不安、得られる安心感の正体をはっきりさせる

そもそもアサインして得られる安心感はどの程度のもので、どのようなものしょうか?具体的にどのような不安に対処出来るかは明確でしょうか?これが説明できれば、少なくとも「とりあえず」では無いでしょう!


2. イベントの目的を明確にする

とりあえずアサインが発生しているイベントがある場合、イベントの目的をはっきりさせると必要なメンバーの取捨選択が行いやすくなります。

目的がぼやけると不安に繋がりやすくなり、結果的にとりあえずアサインが増えます。結果的に本当に必要な数人のコアメンバー + とりあえずアサインされたメンバーにより10人、20人と膨れ上がってしまいます。

ウェブクルーでは、目的の部分がぼやけてしまっていました。数人のコアメンバーと、とりあえずアサインされた数人が合わさり、10人以上の大きなチームで進めてしまったために調整コストはまたも無視できない状況となり、意見を統一する難易度が上がり、小回りが効かずに改善のサイクルを回そうにも回せなかった状況にあったと感じています。


スクラム導入マスター


コンテキスト

スクラム導入を目指したメンバーが、導入と同時に居なくなってしまう(または、発言をしなくなったりして実質的にいないものとなってしまう)ケースです。


解決策


1. 導入をゴールとしない

これはカスタマイズ済みスクラムの一種で、スクラムとしてチームが機能し始める前にスクラムマスターの役割を降りてしまう(=導入するだけでゴールを迎えてしまう(?))状況です。


2. ちゃんとスクラムマスターを立てる(≒役割をはっきりさせる)

責任の回避または分散のためにスクラムマスターを立てないというケースもあるでしょう。うまく働けば、メンバーは安心して働くことが出来たかもしれませんが、ウェブクルーではうまくいきませんでした。スクラムにおいて、導入期のチームは特にスクラムマスターが重要です。スクラムと今の組織を理解し、良い方向へ導けるのはスクラムマスターです。


3. あなたがスクラムマスターになる

スクラムマスターが居ない...このままでは惰性で良くわからない固定化されたフローが続いていくことは容易に想像できるでしょう。解決するには、適切な人にスクラムマスターになってみるよう声を掛けてみるか、この記事を読んで気づいたあなたがスクラムマスターになるしかありません。

スクラムマスターとしてアサインされたものの機能しない状況が続いたり、そもそも不在の場合はいずれスクラムの崩壊に繋がります。あなたが、声を上げることで解決する部分があります。ウェブクルーでは私がスクラムマスターになりました。


私がスクラムを改善するときに気をつけていること

以上3点がウェブクルーが踏んだスクラム開発のアンチパターンです(そして、今は見えてないだけで他にもある気はします)。

ここからは、スクラムを改善するにあたって気をつけていることなどです。


一旦形だけでもやってみる

スクラムはフレームワークであり、スクラムのエッセンスを一部取り入れる、程度では効果を発揮するのは難しいのではないかと考えています。(あなたが使ったことのあるRailsやPlay、Spring等のフルスタックなWebフレームワークをイメージしてください。そのようなフレームワークが備える特定の機能のみを使って幸せにになれる人は相当に限られるのは容易に想像が付くのではないかと思います。きっとメリットよりもフレームワークを維持するコストが目立ってしまうでしょう。)

まずは形だけでもスクラムを取り入れるのも手です。既にミーティングが多く新たにスプリントレビューや計画のミーティングを入れづらい場合は、既存のミーティングに組み込むなどをすることで導入できる可能性があります。


スクラム用語は出来る限り使わないようにした

既に社内へ浸透している用語を除いて、スクラムガイド等に出てくる用語は出来る限り使わないようにしました。

スクラムマスターは「旗振り」に、スプリントレトロスペクティブは「振り返り」に、、、言い換えを行いました。

チームメンバー共通の用語で、心理的な障壁の低い聞き慣れた言葉で説明することで、理解しやすく、結果的に改善に向けて動きやすくなっている考えています。


プロセスやツールよりも個人との対話3

改善の取り組みは、チームメンバーとの面談からスタートしました。メンバーと時間の許す限り(メンバーによっては2時間以上!)話し合い、改善すべき点を見つけてから動き出しました。


独裁者にならない

「こうやります!」と決め、強行突破する必要があるケースはそう多くはないでしょう。


目的は繰り返し説明する

取り組みの途中で「結局は何がしたいんだっけ?」と立ち止まってしまう状況はとても非効率です。

スクラムで発生する各イベントの意義や、そこから作られる成果物については「なぜやっているのか」についての説明は適宜、繰り返し説明していくことで、議論が活発になります。ウェブクルーにあった、より良いやり方が提案されることも多くあります。


まとめ


目の前の課題に正面から向き合い、課題を順番に丁寧に倒していくことが大事

当たり前のことではありますが、この当たり前のことをやり切る事は本当に難しいと思います。うまくなくても良いので、正面から向き合うことで解決する課題があると考えています。

最後に少しだけ宣伝ですが、ウェブクルーは課題が山積みではありますが改善に向けて前向きに動くことができるチームメンバーと環境があります。手を挙げることによって誰でも広い裁量と適切な責任の下仕事をすることができます。

そのようなウェブクルーでの働き方に興味を持ってくださった方は、株式会社ウェブクルー 求人一覧 からエントリー頂くか、Twitter等で@noko_k までDMかメンションを頂ければと思います。

明日の記事は@haruka_kouyamaさんです。よろしくお願いします。

※各アンチパターンに付いている名称は、基本的に @noko_k が勝手につけた名称です。同様の事象に既に別の名前が付いている可能性があります。そのときは優しく教えて下さい。





  1. この記事に記載されていることを読者のみなさんのチームに適用するときは、(当たり前ですが)注意をして適用する必要があります。あくまでウェブクルーのチームに対する処方箋のためです。また、この改善については11月下旬のスプリント時点から見えたことに過ぎません。次のスプリントには、この記事に記載のあるアンチパターンやその改善に関する意見が変わる可能性が大いにあります。 



  2. 前工程に戻ることも許容されており、状況に応じて作業スコープやスケジュールが変化する点でゆるやかと表現しています。 



  3. https://agilemanifesto.org/iso/ja/manifesto.html