「アジャイル開発」は存在しない？ その４ ～　Scrum（スクラム）実践編②　～

今回も大分時間が経ってしまったのですが、前回（ https://base.terrasky.co.jp/articles/Joe6s ）の実践編の続きとなります。前回同様、基礎編のブログでは触れられなかったスクラムの内容について、もう少し踏み込んで解説をしたいと思います。ただその前に、前々回のブログで投げかけた5つの問いかけに関して、前回の内容も踏まえて少し整理しておきます。

「１．スクラムにおいてスプリントレトロスペクティブ（ふりかえり）のイベントは何故外せない一番重要なイベントなのか？」
⇒　こちらは前回のブログの中で説明している通り「このイベントを実施しないとスクラムのフレームワークとして準備されている【適応】の場を失ってしまうことになる」ためです。チームの習熟度が上がってくると、毎日のデイリースクラムでふりかえりが行われるようになったり、さらに進むと常時「ふりかえりしている」ようなチームになったりするかもしれませんが、まずはしっかりとスクラムのフレームワークに則ってやってみることをおすすめします。

「２．スクラムマスターがプロダクトオーナー（以下、PO）と話し合って、プロジェクトを進めるのでなければ、一体誰が責任をもってプロジェクトを進めるのか？」
⇒　こちらは今回の本文で触れたいと思います。

「３．スクラムを実践する上で行われている具体的なプラクティスについて」
⇒　こちらは前回のブログの中でいくつか触れました。何か面白そうなものがあったら追加で紹介したいと思います。

「４．スクラムにおける「完成の定義」とは？」
⇒　こちらは次回以降になりそうです。。。

という所で、（主に筆者の？）ウォーミングアップも終わったと思いますので、本文に入っていきたいと思います。

今回はスクラムチームを構成する3つの役割を解説します。

こちらは前々回のブログで、「スクラムの定義では（設計者や、実装者、テスト担当者等の区分けはなく）あくまでも1つだけ」と紹介していました。スクラムガイドではスプリントバックログの作成、品質の作り込み、スプリントゴールに向けて毎日計画を適応させる、専門家としてお互いに責任を持つ、と定義されています。ポイントは以上のような事柄の「結果に責任を持つ」という点です。

完全に筆者の私見ですが、最新のスクラムガイド（＝近年のスクラム）では、「結果」という点が特に強調されるようになった気がします。これまでのブログでも紹介した通り、元々Agile（スクラム）が生み出されたのは、いわゆるWaterfall型の開発が上手くいかなかったことが発端です。現場で「こうやったらもっと上手くお客さんに価値を届けられるのでは？」ということを試行錯誤（四苦八苦？七転八倒？）しながら、生み出された先人のノウハウ・パターン・知識・経験等の集大成のはずです。ですが「こんな感じでやったらいいんだよね？」という「やり方」に捉われすぎた現場が増えたことに対しての「そもそも何のためにスクラムを取り入れようとしたんだっけ？今の仕事・業務で結果・成果を出したいからだよね？」という作成者からのメッセージの気がしています。

こちらも同じく前々回のブログで、「複数名プロダクトオーナーの合議体制で決定するのではなく、あくまでも　『1人である』という所がポイント」と紹介していました。スクラムガイドにも「プロダクトオーナーは1人の人間であり、委員会ではない」と明記されています。また、私が研修を受けた際もそのように教わっています。ただ、実際の現場ではどうかと言われると、「プロダクトオーナーチーム」という形で企画を担当する人達で（という表現はあまり好ましくないかもしれませんが、実際そうだったので）チームを構成し、各イベントに参加するという形をとっていたチームもあります。

では、なぜ「1人である」ことにこだわっているのか？ということなのですが、それはシンプルに「実施すること（＝プロダクトバックログ）の優先順位を責任を持って決めるため」です。合議制になってしまうと、「これはAさんが必須と言っていて、別のものはBさんが必須と言っていて・・・」という風に、優先順位が決まらなくなる、決まった優先順位に決めた人が責任を持たなくなる・持てなくなるという問題が起きがちなためです。逆に言うとその点に気を付けて「プロダクトオーナーの仕事を分担し、最終的な決断・決定については1名の責任者が実施する」というような形で進められるのであれば、プロダクトオーナーチームのような複数名の形で進めるということも可能になります。（先に紹介したチームはそのように進め、実際に上手く回していました）

スクラムで提供したいプロダクトの質・量にもよりますが、大体の場合においてプロダクトオーナーはかなり忙しい状態になります（なっています）。よって、その負荷分散のため、やむなくチーム化して動く、という戦略は上記の点に十分注意を払った上で進めるのなら、個人的には悪くない戦略だと考えています。

こちらは前々回のブログで紹介した通り、いわゆるWaterfall型の開発に慣れた人にとっては、かなり理解され難い役割になります。ともすれば「朝会の際に、各メンバーから1対1で進捗報告を受ける役割」とか「プロダクトオーナーに要件をヒアリングして、その要件を開発者に伝えて、その開発状況・進捗を管理する役割」といったような、「今までのチームリーダと何が違うの？」というような状態になってしまうことがあります

個人的な経験や、いろいろな話を聞く限りでは、今までチームリーダをやっていた人が、スクラムについてあまり理解しないまま、「スクラムやるんだから早く開発できるんだよね？」といったチーム外からのプレッシャーにさらされてしまうと、こういうことに陥りがちな気がします。もちろん、（チームが出す）結果・成果に責任を持たない「スクラムマスター」というのはよろしくない存在ではあります（一昔前のスクラムガイドには「スクラムマスターは、スクラムチームのサーバントリーダーである」という風に明記されていたのですが、個人的には「サーバントリーダー」という単語が「チームが出す結果に対しての責任感を薄くさせる」というような弊害が出てきたため、最新のスクラムガイドではあえて明記しない形にしたのではないかという気がしています。ただ、明確にその単語が出てこないだけで、実際のところはサーバントリーダーシップが求められる役割であるという点では以前と変わりません）

あえて付け加えると、スクラムガイドにある「スクラムチームの有効性に責任を持つ」という説明は、「スクラムチームが結果（成果）を出すために、スクラムマスターに与えられた役割は」という言葉を補完して理解するのが良いのではないかと思います。

「１．兼任について」
小規模なチームの場合や契約的な都合等で、3つの役割の兼任が発生する場合がありますが、一番のアンチパターンはPOとスクラムマスターの兼任になります。POと開発者の兼任、スクラムマスターと開発者の兼任というのはたまに見かけますが、これらはまだ良いとは言え避けられるのであれば避けておいた方が無難でしょう。では、なぜPOとスクラムマスターの兼任が一番のアンチパターンになるのでしょうか？

いくつか理由はありますが、1つは二つの役割の間で本質的に利害関係が衝突してしまう場合があるためです。「スクラムチームとして一体となって顧客に価値を提供するのが目的なのに、なぜ？」という疑問が生まれるかもしれません。これは簡単な例で言うと「POとしては、このスプリントで●●機能を追加リリースしてプロダクトの価値が上がるかを試してみたい。しかし、スクラムマスターとしてはチームの高負荷が続いている状況を考慮して、このスプリントでは無理な詰め込みは避けたい」というような場合です。

他の理由としては、シンプルに「POとスクラムマスターの兼任は大変すぎる」という理由です。特にPOに関しては、実際にスクラムを始めてみればすぐにわかると思いますが「PO忙しい問題」というものが、いろいろな現場で発生していたりします。
また、POとスクラムマスター両方の役割が1人の人に集中してしまうと、権限が強くなりすぎてしまうことになりかねず、そうするとチーム参加者の自律性が損なわれてしまうという恐れもあります。

というわけで、役割の兼任はなるべく避けるようにしましょう。

「２．プロジェクトを進める責任について」
教科書的には「POと開発者がそれぞれの立場でプロジェクトを進める責任を持つ。スクラムマスターはそのように自律的に動けるようなチーム作り、環境作りに責任を持つ」ということになります。もっと具体的に言うと、例えばスプリントレビューにおいてそのスプリントで作成したインクリメント（成果物）をPOに対して説明するのは開発者になりますし、それに対してフィードバックを行うのはPOになります。スクラムマスターはそのための「場作り」を行うことになります（スプリントレビューで、スクラムマスターがPOに対して進捗報告したり、、、してないですよね？）

　今回、一気に仕上げてしまおうと意気込んでいたのですが、前回のもののようにちょっと長くなりそうだったので、「3つの成果物」「その他のルール」については次回以降に！