こんにちは。TPです。
今年の初めから株式会社SODAにFlutterエンジニアとして参画し、5月ごろからスクラムマスターをやっておりました。自分にとってスクラムマスターを担うのは初めての経験になります。
この記事では、約半年程度スクラムマスターとして業務する中で、スクラムについて考えたことをざっくばらんに書き連ねていきます。
自分はまだまだスクラムマスターおよびスクラムの実践者として新米なので、変なことも書いてしまっていると思います。しかし、現時点での考えのスナップショットとして書き残しておきたいと思いました。
前提
-
この記事で言及している「スクラム」は、スクラムガイドで説明されているものを指しています
スクラムは無料であり、本ガイドで提供されるものである。ここで概要を述べたように、スクラムフレームワークは不変である。スクラムの⼀部だけを導⼊することも可能だが、それはスクラムとは⾔えない。すべてを備えたものがスクラムであり、その他の技法・⽅法論・プラクティスの⼊れ物として機能するものである。
-
前職でもプロジェクトマネージャー&エンジニアリングマネージャーを少しやっていました（非スクラム）
-
私はスクラム関連の資格は所持していません
アジャイル開発とスクラム
アジャイル開発はスクラムを語る上で切っても切り離せないものです。
自分としては「アジャイル開発」という言葉を使う時、アジャイルソフトウェア開発宣言を念頭に置いています。この宣言で述べられているような理想像を実現することがアジャイル開発の根底だと思っています。
アジャイル開発という言葉が生まれて以来、アジャイル開発を実現するための様々な方法論が発表されてきました。その中でも特に有名なのがスクラムとエクストリーム・プログラミング（XP:eXtreme Programing）です。
XPについては、自分はまだ原典（「エクストリームプログラミング」
Kent Beck 著、Cynthia Andres 著、角 征典 訳）を読んだことがないので多くは語れません。スクラムよりもプログラミングを伴う開発に特化しており、より具体的な手法に言及されているものと理解しています。
スクラムガイドをよく読んでみると（または、Ctrl+Fで「アジャイル」と検索してみると）わかるのですが、スクラムガイドに「アジャイル」という言葉は一切含まれていません。ですが、スクラムガイド成立の経緯からしてもアジャイル開発は明らかに大きな存在ですし、実際のところ巷でもスクラムといえばアジャイル開発のフレームワークだと認識されています。
おそらく、スクラムガイド側が「アジャイル」という言葉の曖昧性を嫌って意図的に使用を避けたものと思われます。とはいえアジャイルとスクラムの関係は不可分なものと考えていいでしょう。
注意する必要があるのは、「アジャイル＝スクラム」ではないということです。これについては自分も数年前まで混同してしまっていました。アジャイルソフトウェア開発宣言という理念が先にあり、それを実現するためのフレームワークがスクラムということで自分は整理をしています。
スクラムはフレームワークである
スクラムはアジャイル開発を実現するためのフレームワークです。これはスクラムガイドには書かれていませんが、個人的にはそういう整理をしています。
スクラムガイドはアジャイルとの関係性については沈黙していますが、スクラムがフレームワークであるということは明確に述べています。
スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、⼈々、チーム、組織が価値を⽣み出すための軽量級フレームワークである。
ところで、「フレームワーク」とは何でしょう？ビジネスの場でもよく使われる言葉であり、特にプログラミングに携わっていると頻繁に耳にする言葉でもあります。
一例として、KDDIのページにはこう書かれています。
フレームワークとは「枠組み」「構造」を意味する英語で、特定の目的や課題に取り組むための基盤や枠組みを指します。
これを活用することで、課題解決やプロジェクト実施を体系的かつ効率的に進めることができるため、プロジェクトマネジメントやソフトウェア開発など、さまざまな分野で活用されています。
日本語に直訳すると「枠組み」「構造」になるということですが、自分としては武道の「形（カタ）」も近しい概念だと感じます。
日本語で「形」というとき、具体的な空手の所作を指すこともあれば、ある武道の実践体系そのものを指すこともあります。私はフレームワークという言葉を後者に近いイメージで受け取っています。
フレームワークとの付き合い方
スクラムがアジャイルを達成するためのフレームワーク（または「形」）であることを踏まえると、私たちはどのように付き合っていくべきなのでしょう？
「形」それ自体は目的ではない
フレームワークは何かしらの目的を達成するための枠組みであって、それ自体が目的になってはいけません。武道の「形」に例えるなら、空手や柔道はそれ自体が目的ではなく、その実践を通して心身を鍛えたり、生きていく上での何らかのことを学ぶのが目的であるはずです。私たちの目的はスクラムそれ自体でなく、それを通じたアジャイル開発の実現であるということを忘れないようにしたいです。
いつか「形」から離れる時が来る
日本の武道に「守破離」という言葉があります。最初は教えを忠実に守って形を作り、次に教えを応用しつつ形を破る段階があり、そして最終的には独自のスタイルを確立するという修行の段階を言葉にしたものです。スクラムの実践にもこれが当てはまるのではないかと思います。
いわゆるBigTechの企業たちは、現在はスクラムを実践していないようです。しかし、それがすなわちスクラムが不要であることを示すわけではないと思います。BigTechなどの大企業では、既に守破離の「離」の段階に達しているため、独自の社内フレームワークやプラクティスを開発し、メンテナンスしています。一方で、まだ「離」に至れていない組織にとっては、スクラムのような共有されたフレームワークに従うことはメリットがあるでしょう。
フレームワークは補助輪なので、邪魔に感じることもある
スクラムに限らず、フレームワークを実践していると、そのフレームが邪魔に感じることがあります。スクラムを部分的に無視できればもっと早く仕事がこなせそうなのに……、と思うことがあります。しかし、これはフレームワークを実践する上では当然かつ健全な反応でしょう。アジャイル開発が上達し、業務への理解度が上がるにつれて、フレームワークと実際の業務のズレに気づきやすくなるのは自然なことです。
初心者にはサポートとして機能する一方で、上達したら邪魔に感じられるようになる。この意味においてフレームワークは自転車の補助輪に似ていると思います。本当に熟練しているのであれば、補助輪を外してしまっても問題なく、むしろより速く走ることができます。一方で、習熟度が足りていないのに補助輪を外してしまうと、転んで怪我をします。
アジャイル開発は自転車より複雑です。怪我のリスクに気づいた時には、既に転んで怪我をした後ということになりがちです。形を破るには多少の怪我は許容すべきでしょうが、イタズラに補助輪を外すのは組織のためにならないでしょう。
スクラムガイドが関知しない部分
実際の業務のうち、スクラムガイドで直接言及されていない部分があります。それらのスクラムが関知していない箇所のうち、特に気をつけたい点について言及します。
組織設計
スクラムガイドのスクラムチームの章には、こう書かれています。
スクラムチームは、⾃分たちで作業を管理できるように組織によって構成され、その権限が与えられている。
簡単に書いてありますが、この状態を実現するためにはかなりの努力が必要となるでしょう。これは言い換えれば、チームに対して十分で明確な権限移譲が行われているということになります。しかし、それを実現できている組織がどれほどあるでしょうか？多くの場合、チームに何の権限が移譲されているかすら明確にはなっていないのではないでしょうか。
難しいことですが、この前提を満たせなければスクラムは十分に機能しないでしょう。適切な権限移譲がないと、「自己管理型」であるというスクラムチームの根本が覆ってしまうからです。
スクラムガイドには、適切な権限移譲を行うためのノウハウは書かれていません。この部分については、実践する組織でよしなに決めていく必要があります。
リソース効率
スクラムを愚直に実践していると、スプリントゴールに対して担当する作業量が少ない人が出てくることがあります。つまり、リソースの余りが発生します。
この問題について、スクラムガイドには答えが書かれていません。スクラムでは、スプリントごとの成果（プロダクトが実際に提供した価値）に着目しています。これは「フロー効率」と言い換えて良いでしょう。一方で、メンバーごとのリソース効率を改善する方法については、スクラムガイドは沈黙しています。
手が空いている人が出てくると「もったいない！」と感じて、スプリントゴールやPBIを調整して何とかリソース効率を上げたくなるのが人の性でしょう。しかし、このアプローチはスクラムにおいてはアンチパターンだと思います。リソース効率とフロー効率はトレードオフの関係があり、リソース効率を上げようとすると、フロー効率を損なってしまう場合が多いからです。これはスクラムにおいて望ましいことではありません。
人手が余っているからといって安易にリソース効率を上げようとしないことが肝要です。今の自分の考えとしては、人手が余った時には以下の優先度で対処しています。ポイントとしては、目先のリソース効率を上げるのではなく、中長期のフロー効率の改善に余った時間を使うということです。
- 今のスプリントゴールに対して自分が貢献できる部分はないかをメンバーと相談する
- 中期的にフロー効率が上がる改善を実施する（リファクタリング・テストの追加やドキュメントの整備など）
- 学習に時間を使う（特に、技術領域を越境するスキルを身につけることで、チーム全体のフロー効率の向上につながります）
リソース効率とフロー効率を考えるにあたって、以下のブログを参考にさせていただきました
経営層の意思と理解
「組織」の節でも言及しましたが、スクラムチームが機能するには適切な権限移譲が不可欠です。
多くの企業の場合、権限は経営者から各本部、各マネージャーへと分割されて移譲されていきます。メンバーが勝手に権限と責任を主張するのはガバナンス的に問題があります。
すなわち、スクラムチームを機能させるには、経営層が適切に権限移譲を行うことが不可欠です。ところが、スクラムの何たるかをより理解しているのは、経営層ではなく、現場に近いマネージャーやメンバーであることが多いです。アジャイル開発やスクラムが開発者の文化の中で育まれたことを考えると、これは自然なことではあります。
理想的には、経営層がアジャイル開発とスクラムの効能を理解し、意志を持って権限移譲と組織設計を進める方がスムーズにスクラムが実現できるでしょう。しかし、多くの実際の現場ではそうなるケースは少なく、アジャイル開発やスクラムに詳しいマネージャー・メンバーがそれを推進する必要があります。
アジャイル開発とスクラムを実践する上で、この構造が大きな困難になることが多いと思います。それでも現状を変えるためには、やれる人起点でやっていくしかしょうがありません。スクラムマスターがスクラムを成立させることに責任を負っている以上、そういった組織の上下への働きかけもスクラムマスターの責務です。スクラムマスターは、スクラムチーム内のこと以上にチーム外の環境整備に目を向けるべき役割なのかもしれません。
まとめ
スクラムを半年間実践してみて感じたことをざっくばらんに書いていきました。
スクラムについては日本の開発者界隈でも賛否両論、色々な意見があります。また、「スクラム」が何を指すのかについても人によって見解が異なっており、議論の前提が揃っていない場面もよく見かけます。かなりカオスな状況ではありますが、無料で公開されていて十分な採用実績があるアジャイル向けのフレームワークはスクラムの他にはほとんど存在していないのも事実です。歴史の浅い組織がアジャイル開発に至るために、スクラムガイドは依然として大きな手掛かりであると信じたいです。
今後もスクラムマスターとして頑張りたいと思います。読んでいただいてありがとうございました！
株式会社SODAの開発組織がお届けするZenn Publicationです。 是非Entrance Bookもご覧ください！ → recruit.soda-inc.jp/engineer
Discussion