大規模スクラム導入ぶっちゃけ話、スクラムマスターが語る0→1のスクラム体制構築
前回のnoteではHERPの開発体制やカルチャーにフォーカス。「ユーザーへの価値提供に何よりもこだわる」と語っていた開発チームですが、その過程では様々な困難と変化がありました。
とりわけ体制における大きな変化の一つが、スクラムやLeSS（Large-Scale Scrum）フレームワークの導入です。今回はスクラムマスターの坂田さんと、ソフトウェアエンジニアのまざっちさんのお二人にスクラム導入の背景や、導入にあたっての苦労についてお聞きしました。
（聞き手・執筆：久野美菜子（@nokuuun））
プロフィール
宮崎（まざっち）：
東京大学大学院工学系研究科中退。学生時代にGoogle Japan などでエンジニアインターンを経験。HERP には 2017 年 5 月より長期インターンののち、2017 年 12 月に新卒として入社。 HERP 社内では開発だけでなくCSや採用などにも関わるなんでも屋さんをしている。（@mazamachi）
さかた：
株式会社Leveragesでエンジニア、プロジェクトマネジメントを経験。HERP には2020年8月に入社。HERPでは主にバックエンドエンジニア、プロジェクトマネジメント、スクラムマスターなどを担当している。（@lambda_funtaro）
HERPのこれまでの開発体制の行き詰まり
― まずはスクラム開発を導入した時期と背景について教えて下さい
さかた：
スクラム開発を本格的に始めたのは2020年10月です。私がHERPに入社した3ヶ月後に導入しました。
― むしろこれまでスクラム開発は導入されていなかったんでしょうか？
まざっち：
導入していなかったわけではないです。正確には何度もやろうとしていたけど行き詰まっていた状況でした。
2018年あたりから、スクラムやカンバン導入トライして小さく作るようにしていたのですが、だんだんひとつの機能にかかる検討・実装時間が伸びて、ウォーターフォール的開発になってしまい、それがずっと続いていました。
さかた：
私が入社した当時の開発スタイルは、要件定義はされているものの責任者が不明確だったり、目的やイシューが不明瞭なタスクが多い印象でした。また、実際に開発を進めていくにあたって、プルリクを出してレビューしてもらって、という単調なコミュニケーションが多く、フラストレーションが溜まっていきました。
まざっち：
ウォーターフォール的開発が、よくない状態になっているのが極まってしまっていた時期ですね。
さかた：
もちろん要件をかっちり固めて上から順に開発するやり方が適した場面もあると思うのですが、新しいサービスを作っていくにあたっては、細かいピボットを高頻度で行う前提のアジャイル型の開発に転換した方がよいのでは？と思うようになりました。
もともと前職でスクラム手法を取り入れた開発を行っていたこともあり、私が手を上げてスクラムをやってみることにしました。
スクラムの理論
スクラムは「経験主義」と「リーン思考」に基づいている。経験主義では、知識は経験から生まれ、意思決定は観察に基づく。リーン思考では、ムダを省き、本質に集中する。
スクラムでは、予測可能性を最適化してリスクを制御するために、イテレーティブ（反復的）でインクリメンタル（漸進的）なアプローチを採用している。スクラムを構成するのは、作業に必要なすべてのスキルと経験をグループ全体として備える人たちである。また、必要に応じてそうしたスキルを共有または習得できる人たちである。
スクラム開発立て直しの苦労
― ウォーターフォール型の開発が管理・制御を軸としたプロセスなのに対して、アジャイルは経験に基づき自己管理・自己組織化するプロセスと、ベースの価値観そのものが大きく異なりますよね。こうした価値観をチームにインストールし、実践にもっていくにあたって、苦労した点はありますか？
さかた：
導入時点での反省点としては、スクラムやLeSSのルールを覚えることを重視して進めてしまったことです。そのためスクラムのルールに縛られ、アジャイルの思想をもとに自由に開発者が考えて行動することがしにくくなり、プロダクトの開発がうまく進まなくなりました。
また実践にあたって、ウォーターフォール的に進めていたプロジェクトをそのままスクラムにのせようとした結果、PO（プロダクトオーナー）をウォーターフォールでいうところの下流の開発者のなかで選出してしまい、提供したい価値とエンジニアリングのすり合わせができなかったのも反省点です。
スクラムマスターの資格習得がヒントに
まざっち：
チームの人数も多くコミュニケーション面のコストも高く、目指していた自己組織化がなかなかできずにいました。
こうした状況を変えるきっかけとなったのが、坂田さんのスクラムマスターの資格取得です。1週間ほど仕事を休んでスクラムの研修を受け、その学びをHERPに活かしてもらいました。
さかた：
正直スクラムマスターの資格を取ることでどれくらい改善に寄与できるのかわからなかったのですが、やってみよう精神で快く送り出してもらいました。
― HERPのバリューのひとつにもある「やってみよう」ですね。研修のために時間を使わせてくれるのはとてもよいですね。
さかた：
そうですね、実際に研修を受けてみて、どういう課題のところにどういったスクラム手法が適用できるのか、を具体的に学べたのはよかったです。
何より、スクラムのルール以上に「課題の特定が大事」というのが大きな学びとなりました。まざっちさんに言っていただいたように、チームの大きさがボトルネックになっていると考えたので、LeSSフレームワークを導入することにしました。
LeSS（Large-Scale Scrum）
LeSS（Large-Scale Scrum）は、クレイグ・ラーマンとバス・ボッデによって開発された中規模から大規模スクラムのフレームワークである。（中略）スクラムが基本的に1つのチームでの状況を中心に扱っていることに対して、LeSSはより規模の大きいプロダクトグループでの状況を扱う。
LeSS導入後のチームの変化
― LeSSの導入後、チームはどのように変わっていきましたか？
さかた：
もともと13-4人で開発していたのを、1チーム5−6人に分けてそれぞれの自主性を高める形で開発しました。課題を共有して個々人で解決策を考えることを推奨するカルチャーに変化しましたね。そして何より大きいのは、全体の目線が合わせられたことです。
まざっち：
みんな積極的にアジャイルソフトウェア開発宣言やその原則を引用し、困ったときは立ち返るようになったのは大きな変化ですよね。
開発メンバーに限らず、チーム全体の目線が揃いました。小さくつくってユーザーやステークホルダーにこまめに見せながら進められるようになりましたし、「ユーザーに意味あるものを作ろう！」という意識が高まったのでモチベーションを保てるようになりました。
― リモートワーク中心の働き方の中でスクラム体制に移行していますが、どのような工夫をしましたか？
さかた：
ミーティングの人数はあまり多くせず、もし多くなる場合は文章でも発言できるようにしています。
また、日々のプラクティスとして、開発者をランダムで2チームに振り分けそれぞれの活動状況を共有するデイリースクラムを毎朝やっています。基本的には昨日やっていた大事なこと、やろうと思ってたけどできなかったこと、今日やることを共有します。
― ランダムにチームを振り分けてミーティングしているんですね。
まざっち：
チームが大きいと他の人のタスクを把握しづらいですし、ましてやリモートだと誰が何しているのかわからなくなりがちですが、そういったことが解消されたのはよかったです。
さかた：
心理的障壁も下がりますよね。リモートに限らず、喋る機会が少ないと困っていることを共有しづらくなるのですが毎日挨拶を交わしたりランダムで話すだけで心理的安全性は高まるんだなと感じました。
―LeSSそのものに強いこだわりはなく、状況に応じて変えているとお聞きしてます。現在はどのような開発をされているのですか？
さかた：
プロセス自体もアジャイルに見直しながら、その時ごとの適切な開発スタイル見極めています。その結果として、実は現在はLeSSをやめています。
LeSSは各チームがクロスファンクショナル(開発におけるすべての機能を持ち合わせている状態)である必要があり、それを前提としたルールが多数ありました。しかし現状クロスファンクショナルであることを徹底するのは負荷が高いため、LeSSの活用は一旦休止しつつも、アジャイルやスクラムの思想を軸に開発を進めています。
―最後に、今後どんな人達と開発していきたいですか？
まざっち：
アジャイル開発宣言の価値観で開発するのが好きな人だと、楽しく働けるかと思います。
さかた：
あと、Haskellを使っている会社というイメージを持たれていると思うんですが、他の言語での開発も行っていますしあまりハードル高いなって思わないで欲しいですね(笑)。言語というよりは開発のプロセスにこだわりがある人に来て欲しいなと思います。
カジュアル面談大歓迎！
転職の予定がない場合でも、HERPではカジュアル面談を歓迎しています。
HERPの採用情報
プロダクト開発の求人一覧はこちらから。
採用サイトで、カルチャーデックなど組織の情報を公開しています。
GitHubでエンジニア向けの採用資料も公開しています。