企業規模にかかわらず、アジャイル開発を取り入れようとする企業が増えている。だが、その導入は容易ではない。特に「スクラム」をどのように進めればいいかといった悩みを抱える企業は多いという。本稿では、オンラインイベント「アジャパー・シナジー」のセミナーを基に、スクラムの各要素をどのような順序で導入すべきかについて解説する。
この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
アジャイル開発の認知は進み、自社にも取り入れようと考えている企業も多い。だが、「全面的に導入している」という企業の割合はそれほど高くない。多くのメリットが得られるアジャイル開発だが、導入においては幾つかの課題があるからだ。例えば「チームごとにプロセスの一貫性がない」「メンバーの価値観が異なる」「アジャイル開発に抵抗感がある」など。
「こうした課題は、アジャイル開発の中でも、特にスクラムにおけるフレームワーク運用の難しさを表しています」と語るのは、旭化成でスクラムマスター(SM)やアジャイルコーチの立場でプロジェクトをリードしてきた西野大介氏(デジタルタレント戦略部 企画・推進グループ長/エキスパート)だ。
本稿では、2024年10月23日に開催されたオンラインイベント「アジャパー・シナジー」の西野氏の講演「アジャイル実践、何から始めればいいか悩むあなたへ!」を基に、スムーズなスクラムの導入方法を解説する。
スクラムを成功させるアプローチはさまざまだが、西野氏は「段階的な導入」を推奨する。
西野氏によると、スクラムには「3つの責務(ロール)」「5つのイベント」「3つの作成物(アウトプット)」という“3-5-3の構成要素”がある。だが、これら全てを一気に導入するとつまずきやすくなってしまう。そのため、「少しずつ適用し、徐々に完成形を目指すのがよい」と同氏は説明する。
段階的導入のポイントは3つ。
1つ目は「各要素内の細かい要素を少しずつ取り入れること」だ。3-5-3の構成要素そのものを削ってはいけないが、各要素を1つずつ段階的に導入するということだ。2つ目のポイントは「透明性、検査、適応のサイクルを順守すること」だ。段階的導入でも透明性を確保(つまり、状況を可視化)し、メンバー間でそれを共有、検査、適応するサイクルを回すことが重要だ。3つ目のポイントは「安易なアレンジをしないこと」だ。ただし、アレンジ自体を恐れる必要はない。「アレンジは過剰になりがちですが、手綱を締めつつ、アレンジすること自体を恐れないようにしましょう」と西野氏は説明している。
西野氏は3-5-3の要素ごとに段階導入のポイントを説明する。
まずは“3つの責務”として、プロダクトオーナー(PO)の役割に注目する。
POのあるべき姿で考えると「プロダクト価値を最大化する」が真っ先に挙がる。そのためにPOは明確なビジョンを確立し、チームを導いていく。プロダクトゴール、すなわち目指すべき道しるべを策定し、プロダクトバックログを作成、優先順位を付けて開発を進める。また、POはプロダクトの方向性を調整する責任者でもある。しかも合議体での意思決定は時間がかかり、一貫性も保てなくなるため、1人で担当するのが前提となる。ただし、作業は委任できるものとされている。
こうした“あるべき姿”に対し、実際は幾つかの課題がある。
それは「プロダクト作成をけん引しないPO」の存在だ。プロダクトの価値を最大化させるには、プロダクト作成をけん引するPOが不可欠で、POには事業の専門家である事業部の人間が適任だ。だが、彼らはデジタル開発のプロではない。プロダクト作成をけん引するために必要なビジョンの作成やチーム管理などには詳しくないことが多い。
また、特に日本企業においては「専任のPO」は珍しい存在だ。多くの場合、POは他の業務を抱えていて多忙なことが多く、開発するデジタルサービスに100%コミットできる立場にない。兼務状態では十分な時間を割けず、スクラムにも精通していないケースが多い。スクラムの価値を理解していないため、チームをけん引できないという課題も生まれる。
さらに、「POは1人で担当する」という前提が状況を悪くする。POが1人であることがボトルネックとなり、開発にコミットできないため、作業が遅延する。メンバーは「それはPOが決めるべきことだ」と責任を転嫁し、スクラムを理解しているエンジニアは不満を抱くという悪循環が生まれるのだ。
この課題に対し、西野氏は解決策として「POの段階的参画」を提案する。
段階的参画の鍵となるのが、POをサポートする役割である「PO補佐(PdM)」の設置だ。
POは“あるべき姿”にのっとり、事業部からアサインし、チームに正式に参加してもらう。だが、前述したように事業のプロではあるものの、開発やスクラムのプロではない。そのため、PdMにそうした開発に関する活動をサポートしてもらうということだ。
「SMがPOを補佐することも可能です。ただ、SMとPOはその責務に相反性があることから兼務は避けるべきです。また、プロダクトに着目した活動を補佐するには事業に専念できる人が適任ですが、そもそもSMは工数が不足しがちなので、SMとは別にPdMを設置すべきだと考えています」
では、PdMはどのような役割を担うのか。西野氏によると、「ビジョン策定の枠組みの用意」や「会議への代理参加」「POの意思決定の支援」などが当てはまる。具体的にはホワイトボードツールなどを活用してビジョン作成やユーザーストーリー決定に関する意見を収集、整理、可視化し、最終的にPOに意思決定を促すといったことだ。
一方、西野氏は「PdMに任せきりにならないようにPOが担うべき役割を明確にする必要がある」と指摘している。
「POがスクラムイベントに参加しなくなり、PdMがその役割を担うようになると、SIer(システムインテグレーター)などに丸投げするのと変わりません。POは自身が担う役割を認識する必要があります」
POが担うべき役割の一つとして西野氏は「ビジョンにおける最終的なプロダクト価値を明確化し、その表現を決定すること」を挙げる。ここで言う“表現の決定”とは、メンバーから集めたアイデアを基に「ビジョンを決定する際にどういう文言で、どのような表現でプロダクト価値を定義するかを決める」ということだ。「POがこれを怠ると、プロダクトの価値定義があやふやなものになりかねません」と西野氏は指摘する。
POは他にも、レビューでのプロダクト受け入れ判断やプロダクトバックログの優先順位の決定も担う。プロダクトのデリバリーはスクラム活動の根幹であり、それに直結する事項の意思決定はPOが責任を持つ必要があるからだ。
ここで注意しなければならないのが、「段階的参画」と言っても、POは最初からチームに正式参加するということだ。その理由としては、1つ目に事業側と開発側でチームが分かれているとスクラムが機能しにくいこと、2つ目に、チームに参加することでPOにスクラムの価値、つまり「スクラム活動は、コストに見合うアウトカム(成果)が得られる」という理解を深めてもらう必要があるからだ。
この“POの醸成期間”でチームがすべきこともある。
1つは「スクラムチームのケイパビリティを高めること」だ。スクラム体制が未成熟な段階でPOがフルで参画すると、POから「スクラムの価値」に疑問を持たれる可能性がある。「POが100%コミットしていない間は、スクラムチームのケイパビリティ向上に集中できるチャンスと捉えるべきでしょう」と西野氏は言う。
もう1つは「ウオーターフォール型開発との違いを感じてもらうこと」だ。スクラムでは、レトロスペクティブ(振り返り)などチームの活発な活動を促すイベントを通じて、チームが自己管理型となる。そうした姿を見せることが重要だ。
» トップへ戻る
次に“5つのイベント”としてスプリントのあるべき姿に注目する。
スプリントは、アイデアを価値に変える一定の長さ(1カ月以内)で固定化された期間であり、スプリントゴールの達成を最重視する。スプリントゴールの達成に必要な全ての作業はスプリント内で実施し、一部のスクラムイベントは開催時間、時刻、場所を固定する。
だが、特に事業会社では、複数のプロジェクトを掛け持ちしている場合など、スクラムイベントの日程や参加者を固定できないことがある。中には「全員参加は非効率だ」と感じるメンバーもいるだろう。こうした課題はスクラムチームの成熟度が低いことに起因すると西野氏は指摘する。
解決策として西野氏が提案するのが「スクラムイベントの段階的固定化」だ。
成熟度が低い場合、スクラムイベントの参加者調整においては、失敗が許容される内部メンバーから始めることが重要だ。事業部全体を巻き込むのではなく、内部だけでトライアルを実施し、段階的に固定化していくのがいいだろう。
特にレビューについては、ステークホルダー向けにしっかりと実施することが重要だ。内部で確認後、ステークホルダー向けに別途レビューを実施するのもいいだろう。ここで重要なのは「チーム内の統制を意識してとる」ということだ。事業側がどのような体制であったとしても開発側のメンバーはプロジェクトを成功させられるメンバーをそろえる必要がある。同様にPO、SM、開発者のロールをチーム内で充足できるようにしなければならない。
イベントタイミングは他プロジェクトの状況に合わせて調整する。西野氏によると、タイミングの調整に適しているのはスプリントプランニングのときだ。
「今回のスプリントではどのタイミングでイベントを実施するか、参画工数はどのくらいになるかなどスプリント内の計画をまとめるのがいいでしょう。ただし、“締めるところは締める”ことも重要です」
これは、スプリントのタイムボックスとデイリースクラムは固定化するということだ。スプリント期間は状況によって安易に変更せず、例えば2週間と決めたら毎スプリントを2週間で固定する。デイリースクラムも毎日同じ時間に実施する。「その他のイベントも、プランニングで一度決めた後はタイミングを原則的に変更しません。スプリント内で変更を繰り返すと統制が取れなくなります」と西野氏は指摘する。また、スプリントゴールの追求と、それを繰り返すことによる継続的デリバリーの実践を通して、価値を創出することも“締める”べきポイントとして重要な事項だ。
継続的デリバリーを続け、アウトカムを出し続けることで、チームの成熟度を高め、活動の価値に対するチーム内外の理解を深める。スクラムの導入によってこれまでのプロジェクトとチームの活動プロセスが変化しても、成果を出すことでチームの自信につながり、ステークホルダーの理解と協力を得やすくなる。「重要なのは、成果を出し、プロセス、すなわちスクラムによるチーム活動の価値への理解をステークホルダーに広めることです。それによって、人員や工数、専任体制などを確保できるようになります」と西野氏は言う。
» トップへ戻る
最後は“3つの作成物”としてスプリントバックログのあるべき姿に注目する。
スプリントバックログのあるべき姿は、ゴールを達成するための「なぜ」「何を」「どのように」という情報がまとまっていることだ。“なぜ”は「スプリントゴールという活動の目的を明確化する」こと。“何を”は「どのプロダクトバックログがこのスプリントの対象になるのか」ということ。“どのように”は「実現に向けた作業が明確化されている」ことだ。
では、スプリントバックログにおける課題とは何か。それは、プランニングに時間がかかり過ぎることだ。チームの成熟度が低い段階では、プランニングが終わらずに時間切れで中断したり、積み上がったタスクがカオス状態になったり、毎回作り直す羽目になるチームも多いと西野氏は指摘している。
こうした課題の解決策となるのが「スプリントバックログ要素の段階的記入」だ。プランニングに慣れていない段階では、一部未記入で進め、「タスクの洗い出し」に専念することが重要だ。
「最初のうちはストーリーポイントの記入などは省略してもよいですし、ベロシティもそれほど考慮しなくてもいいでしょう。ただし、『省略している』ということは意識させる必要があります。SMは勉強会などを開催し、適用していないプロセスがあることをチームに認識させることが重要です」
重要なのは、体験させることだと西野氏は話す。最初から全てを網羅しようとせず、核となる体験を通して自ら足りないピースに気付かせる。そうすることで内発的な動機から不足している部分を補う活動を適用し始め、スプリントを徐々に成熟させることができると同氏は説明している。
「未成熟な状態でツールを適用してもうまくいかず、チームの状態が悪くなります。まずは核となる部分だけを実行することで足りないピースに自ら気付き、できなくても挑戦してみるという流れが理想的です」
» トップへ戻る
西野氏はセミナーのまとめとして、スクラムガイドを記述したケン・シュウェイバー氏とジェフ・サザーランド氏の言葉を引用する。
「両氏は『スクラムは経験主義とリーン思考に基づいている』と述べています。これは、知識は経験から生まれるため、まずは経験すること、そして無駄を省き本質に集中することが重要だということを伝えています。これに倣い、経験することで本質を捉えながら、徐々に価値創出の精度を高めていくことが、スクラムを成功させるために有効な手段である、と考えます」
Copyright © ITmedia, Inc. All Rights Reserved.
Coding Edge 記事ランキング