チームではじめる「アジャイルプラクティス」実践の第一歩 CodeZine Night #3
こんなイベントでした
2023/8/4にCodeZineさん主催の勉強会に登壇し、書籍「アジャイルプラクティスガイドブック」で紹介したプラクティスを実際の事例を交えて紹介させていただきました。 30分の講演のほか、監修の川口さん・松元さんを交えてのQ&Aでは多くの質問をいただけました。多くの参加者に興味を持っていただけたイベントにできたのではないかと思います。
いただいた質問への回答
事前にいただいた分を含め22の質問をいただき、勉強会のQ&A時間では8つを取り上げることができました。 せっかくいただいた質問ですので、この場で22の質問にあらためて回答させていただきます。 当日の触れた内容全てをカバーできていませんがそこはご容赦ください。
Q1 : リファインメントの粒度はどこまでやればいいのでしょうか？
A : リファインメントの段階では実際にスプリントで着手するか決まっていないと思います。ですので時間を長くかけたり、詳細に入り込みすぎることは避け「実装に着手できそう。細かな細部は詰める必要はあるが、おおまかな実現方針は開発チームが見通せている」ぐらいがちょうど良いかと思っています。
タイミングよくryuzeeさんがバックログリファインメントに関する詳細な記事を公開していました。こちらも参考になるかと
Q2 : トップが生半可系でマスターを置いてないので効率が全く上がりません。どうしたらいいでしょうか。
A : マスター = スクラムマスターと解釈し、スクラムがうまくできていないと受け取りました。スクラムはフレームワークとして規定されたイベントや役割が相互に影響しあい、開発チームやプロセスにある問題を炙り出すように設計されたフレームワークだと思います。まずは教科書通りに進め、見つかる問題に愚直に対処していくことをお勧めします。効率(≒チームのデリバリー or 生産性?)が上がらない要因は、トップの理解不足や経験のあるスクラムマスターの不在では無いと私は考えます。経験豊富なスクラムマスターがいればうまく行く確率をあげることができるかもしれませんが、スクラムマスター・プロダクトオーナー・開発チームおよびステークホルダー含めての「スクラムの成熟度」ですので、1箇所強いメンバーを入れるだけでうまく行くことはないでしょう。
Q3 : 開発メンバーのアジャイルマインドの理解度の少なさに困っています。
A : 「XXX(人の名前が入る)はアジャイルがわかっていない」というのは私も聞いたことがありますが、何を指して言っているのでしょうね。「アジャイル」と包み隠さず、どんな開発をしていきたいのか自分たちの言葉で話せると相互理解の一歩目になるかもしれません。
川口さんの「非アジャイルマニフェスト」はアジャイルを考える出発地点として個人的に好きでよく引用しています。
Q4 : アジャイルになりたい人とそうでない人がいることに悩んでいます。
A : そういうもの(なりたい人もそうでない人もいる)だと思います。多くの会社や現場は「アジャイル開発がやりたくて選ばれている」わけではありません。「やりたいことや実現したいことを達成するためにアジャイルと呼ばれるやり方が比較的よさそう。それが組織やチームの決まりだから従っている」という人が一定数います。でも彼らもアジャイルに批判的だったり勉強しないわけでも無いです。「アジャイルになりたい人」以外は必ずしも敵ではありません。
Q5 : TDD、ペアプロ、CI/CDのエンジニアリングのプラクティスをどう適用していけばいいでしょうか。
A : 練習しながら1つずつ導入していくしか無いと思います。最初から上手にはできません。また練習ばっかりしていても現場で使っていかないと上達しません。
Q6 : うまく行かない状態になったときにプラクティスを導入してみるとおっしゃっていましたが、困ったことが顕在化しないと導入しても効果は出ないのでしょうか？
A : プラクティスの実施を忘れてしまうとか・大変なのでやめようという話が出てきた時、やめる方向に引っ張られやすいと思います。プラクティス実践を辞めた時に何が起きるのか、チームで共通認識が持てていないとそうなるでしょう。
Q7 : チームの中は整備できつつあるが、チームの外がそうはいかず限界を感じています。
A : 個人でアジャイル伝道師として渡り歩くのは大変です。チームが本当にうまく回っている(楽しそう、生き生きしている、成果が出ている など)のであれば、チームの外から秘訣を学ぼうと声をかけてくるのではないでしょうか? 手が届きやすい自チームに目を向けつつ、「整備できつつある」が主観だけでなく客観でもそう受け取ってもらえるように注力することをお勧めします。
Q8 : アジャイルの経験がないメンバー・組織職にメリットを伝え、現プロジェクトで採用してもらうことに課題を感じています。
A : 「アジャイルでやりたいです。アジャイルとはこういうものです。」という論法で説得すると2重の説明が必要です。アジャイルとは言わず「こういう進め方が向いていると考えているのでやりたいです」と自分の言葉で説明・説得することをお勧めします。
Q9 : 1スプリント1週間でアジャイル開発をしています。WFであれば単体テスト、結合テスト、シナリオテストとありますが、1週間の中で、テストをどこまですべきか悩んでいます。
収まりきれなかった質問の続き・・・
現在はある程度のテストはCIとして自動テストを組み込んでいますが、 仕様変更があった場合、実コードよりもテストコードの修正工数が多くなり、本末転倒といった感じです。 ユーザストーリーをできるだけ細かい粒度にしていくといったような工夫が必要なのでしょうか？
A : テストコードの修正も1スプリント内で取り組むべきことです。機能開発や修正の工数だけをみてスプリントで取り組むスコープを決めているのであれば、テストやデリバリーに必要な作業まで含めて考えるべきです。機能開発や修正の大きさと、影響範囲・テスト対象の広さは必ずしも比例しません。
Q10 : 途中参加のプロジェクトにはどうプラクティスを導入していけばいいでしょうか？
A : 「新規に始めるプロジェクトなら段取りよくプラクティスが導入していける」ではないと考えます。新規でも途中参加でも、チームが一番困っているところに目を向けて、プラクティスを導入して課題を解消していきましょう。
Q11 : アジャイル開発の知識だけで止まっていて、最新のアジャイルを理解していない人がとても多いことに課題を感じています。
A : 「最新のアジャイル」を私も知りたいですw。「知識ばかり集めていて現場で実践している人が少ない」という課題であれば、あまり気にしなくても良いのではないでしょうか。現場で実践を繰り返し、うまくやれている人が増えてきたら、それをみて実践する人が増えるはずだと考えています。
Q12 : 自動テストを書く文化がなかなか根付きません。どうしたらいいでしょうか。
A : なかなか根付かないものです。根気強く取り組みましょう。自分の経験で思い当たる気をつけるべきポイントは「対象を全部テストすることを優先して、工数をたくさん使ってしまうことを避ける」です。バグが起きては困る・失敗すると大きな問題になるところをテストして、自動テストでバグ・問題を見つけられて助かった経験を増やしていきましょう。自動テスト導入に前向きな人が増えてくれるはずです。
Q13 : WIP制限を最初に作るのはフロー効率を優先して進めるスクラムでは大事だと思います。ただ、気がついたらリソース効率優先になってしまっています。個人が思想を理解していないとこっそりやるみたいな状態になってしまい健全な状態になりません。どのようにするにがよいでしょうか？
A : スプリントの最後に「色々なことに取り組んで、チームは頑張ってくれたけど、デリバリーは出来てないから成果は0だよね」とバッサリ切ったりします。デリバリーできてないことをチームが問題視するのであれば、次のスプリントからは仕掛かりを減らし、一つでも出し切ろうと意識が変わるはずです。
Q14 : スコープと納期の両方大事という幻想をお持ちのお客様に対して、よしなにどう説得すればいいのでしょうか・・・？
A : コストをかけてもらいましょう。
Q15 : タスク分割すると、どうしてもタスク間で依存関係、前後の順番関係がでてきてしまうものがあります。こういった依存関係のあるタスクをどのように管理したらうまくいくのでしょうか？
A : スプリントプランニングで依存関係や順番関係を整理・議論できていますか？ここに困るチームは話していないことが多いと感じています。「考えずに進めていたら依存関係にハマってしまい、今振り返れば計画の時点で気がつけたはずなのに‥」というパターンです。
Q16 : プランニングにおける見積もりはどのように行ったら良いでしょうか？基準を決めたほうが良いでしょうか？
A : 工数や期日の絶対見積もりではなく、開発規模の相対見積もりをしましょう。
Q17 : 「PBI はユーザーに価値があることを担保したうえでスプリント（１週間）内にできる単位で分割する」という定義で運用したいと考えていますが、開発チーム力が低く、１週間でユーザーに価値あるものがなかなか提供できません。
収まりきれなかった質問の続き・・・
ただし、PBI を 1 週間以内に終わらせるレベルまで分割しようとすると、ユーザーに価値がなく、レビューで何を見せればいいのか、、、となります。 また、細かい粒度にしようとすると、リファインメントに時間がかかりすぎ、開発時間が減っていったり、開発者のストレスが溜まっていきます。 こういう状態ではどういったアクションから改善していけばいいでしょうか？
A1 : 「ユーザーに価値があるもの(WF的なゴールが分かっている完成系)」を意識しすぎているかもしれません。何か不確実なことがあって、ユーザーに使ってもらい学びを得たいからアジャイルに進めるのだと思います。減らしたい・学びたいことから考えるとPBIのいい粒度が見直せるかもしれません。
A2 : 開発チームが1週間のスプリントでインクリメントを作り切る力がないことを認めて受け入れて、2週間スプリントに変えることが考えられます。
Q18 : TDDは基本的に開発手法で、テストとして扱うにはテスト技法の理解が必要と考えているのですが、周囲の理解が得られにくいです。どのような伝え方をすると納得してもらえるでしょうか？
A : テスト自動化と、テストファーストと、テスト駆動開発の違いを話すことからではないでしょうか？書籍でも触れている箇所です。
Q19 : 大企業では、開発はアジャイルだが、製品出荷は従来通りの品質監査を受けなければならないケースがあります。その際に、アジャイル開発の特性を活かした効率的な品質監査を進めるための何か工夫があれば、アドバイスください。
A1 : 他部門の品質監査担当の方と仲良くなりましょう。製品出荷までの日数を縮めるためにどんな協力がお互いできるのか話しましょう。
A2 : 開発・テストが終わってもリリースまでに必要な作業が残っていることはよくあります。ドキュメントの更新・関係部門への連絡・全社QA部門による承認など、これら「未完了作業(Undoneワーク)」を認識し、少しずつスプリントに取り込んでいくことを検討しましょう。
Q20 : 品質向上と開発スピード向上を目的にアジャイル開発を導入して半年経ちましたが、成果を感じません。メンバーのアジャイル理解度の問題を感じています。アジャイル開発を導入してどれくらいの期間で定着してくる物でしょうか?
A : 新しいやり方がうまくハマった場合、1スプリント内に成果を感じられます。根気強く継続すればブレイクスルーが訪れるものではなく、チームの取り組みが上手く噛み合っていない要因が必ずどこかにあります。メンバーのアジャイル理解度(の低さ)では無いと思います。メンバーに開発でうまくできてないと思うことを素直に話してもらうことから始める必要があります。
Q21 : スキルマップを試しています。属人化が見えて、チームとしてここの属人化を解消すると決めるところまでは来ましたが、スキルレベルの低いメンバが、一人でやりたがったり、隠れてやっていたりして行動が伴わない状態です。タイミング早すぎたのでしょうか。スキルマップやる前はそうした行動は見られなかったのですが。
A : スキルマップをたくさん埋めることが良いことだと誤解している節があります。1人で自走できる領域を増やすのが大事だと使い方を再確認しましょう。
Q22 : 生産性を求めれることがあるが、何を提示すべきか？ また、Scrumチームの成熟度を測るよいやり方を知りたい。
A : 書籍では4 Keysを紹介しましたが、結局のところ「ステークホルダーが開発チームのデリバリーに納得しているか」が1番の指標だと考えています。数値上どんなにハイパフォーマンスな成果が出ていても、ステークホルダーがビジネス成果に結びついていないと感じているのであれば何か間違った方向に突き進んでいる可能性が高いです。
