「スクラムマスターの経験が自律したエンジニアを育てる」“DIGGLE流”スクラム開発の全貌

DIGGLE株式会社でエンジニアリングマネージャー（EM）を務める岡崎に、DIGGLEのスクラム開発について伺いました。スクラムマスターを持ち回りで行うメリットや未経験者へのフォロー、今後の変革など、DIGGLEの開発現場に迫ります。

[参考]
▼EM岡崎のプロフィールがわかる記事
DIGGLE社員インタビュー＃6

“DIGGLE流”スクラムマスターの持ち回り

ーまず最初に、なぜ開発手法としてスクラムを採用したのか教えてください

我々が開発をする上で掲げている原則の1つに「価値提供を滞留させない」という意思があり、スクラムが最も適していたため採用しました。スピード感を持ったSaaSの開発を行う上ではウォーターフォール的な開発よりもアジャイル的な開発が適しており、アジャイル開発の中で最も体系化されていて振り返りや実績との突合がしやすいことからスクラムを採用しました。創業時からスクラムを採用しており、スクラムをベースに開発を細かい単位で区切って行うことでスピーディーなリリースを実現しています。

ー具体的にどのようなフローで実施しているのか教えてください

弊社ではスプリントの期間を2週間としていまして、スプリントの初日にスプリントイベントを行い、その中で、レビュー、レトロスペクティブ（振り返り）、プランニングを行っています。その後は、毎朝デイリースクラムを行い、スプリント終了週の水曜日に、リファインメントを行っています。

ースクラムマスターを持ち回りでされているとお聞きしました。このような制度ができた背景を簡単に教えてください。

元々はマネージャー経験のあるエンジニアが開発業務と兼任する形でスクラムマスターをしていたのですが、兼任でスクラムマスターをお願いしていたメンバーへの負荷が非常に高くなってしまう問題が発生していました。その解決策を検討していく中で、スクラムマスターを持ち回りで行うことで、負荷分散をできないか、という話が挙がりました。

そして、開発メンバー全員でスクラムマスターを回すことで色々な良い効果がでるのではないかという話になり、このような制度ができあがりました。

ー実際どのような効果があったのでしょうか？

弊社のスクラムマスター業務には、大きく「他チームからの問い合わせ窓口」「バグ発生時の一次対応」「打合せのファシリテーター」があります。このような他チームとの調整や、バグの切り分け、ファシリテーターなど、普段の開発業務では経験しづらいことを経験することで、広い視野で相手の困りごとや必要な情報を理解し、行動できるようになるという効果がありました。

特に、他チームからの問い合わせ対応やバグの対応を経験していくと、普段の開発業務からだと見えない部分が見えてくるようになります。例えば、マネージャーの私が感じているチームに対する改善点であったり、カスタマーサクセスやセールスなどが感じているお客様目線での改善点であったり、そういった立場の異なる人が感じている痛みや困りごとが想像できるようになります。それにより、目の前にある自分のタスクだけに囚われず、お客さまの視点や開発プロセスの深いところまで考えられるようになっていると思います。

実際に、メンバー全員がチームの最適化のために動いてくれているので、マネジメントがいらない自律した組織になっていると感じています。

未経験者でも安心。手厚いフォローと好きなだけ転べる土壌

ー未経験の人にはどのようなフォローをしているのでしょうか？

スクラムマスターの持ち回りを開始するにあたって作成した「DIGGLEのスクラムマスターのお仕事」というドキュメントがありまして、そこにスクラムマスターがいつ・何を・どのようにすればいいかまとめてあるので、未経験者でもドキュメントを確認しながら進めることができる状態です。

基本的にやりながら慣れてもらっていますが、未経験者がつまずきそうな部分については、ドキュメントに明記しておいたり、既存メンバーから「最初はここで手こずるかも」とか「これちょっと面倒だからわからなかったら聞いてね」などと声かけをしてフォローしていきます。わからないことがあれば都度Slackで聞いてもらっても構いません。ドキュメント側に過不足がある場合には随時追記や削除を行ってブラッシュアップしているので、また新たに未経験の人が来たときにも以前よりわかりやすく進められる体制になっています。

それでも見落としたり、間違ったりすることもあると思いますが、そういう時も、気付いたメンバーが自発的にフォローをする文化ができているので、まずはやってみて欲しいと伝えています。それで転んだとしても、我々がフォローすれば良いだけですから。

ー現在のチームの現状と、これから目指す姿を教えてください。

現在のチームは社歴の長いメンバーがほとんどで、チームとして成熟しており、スクラムも完成形に近い状態だと思います。

これから目指す姿としては、今後チームメンバーを増員する計画をふまえると、スクラムに限らず今の風土の良いところを引き継ぎつつ、新規メンバーから新しいものをどんどん取り入れて最適化していきたいです。今の開発プロセスであったり、スクラムの進め方であったりといった開発環境は、今のチームにおいては最適な形ですが、新しい人が入ればその形は変わって当然だと思います。1年後も今の形のまま続けていく必要は全くなく、積極的に改善していきたいです。

また、今後メンバーが増えていくと、1つのスクラムチームでは上手く動けなくなってくる可能性もあるので、チーム分けをするなどしてあるべき形を模索しつつ、日々PDCAを回して改善していくべきだと思っています。

個人の成長を全面的にサポート、成長できる環境を用意したい

ーDIGGLEに入ることでどのような成長が望めると思いますか？

今のDIGGLEは、やりたいことはなんでもできる環境です。例えば「今までバックエンドを中心に開発してきたから今度はフロントエンドを中心にやりたい」とか「インフラもやってみたい」という希望があれば、いくらでも機会を提供できます。

要件や基本設計などの上流工程から開発まで一気通貫で携われる環境は珍しく、自分で作り切る経験ができる環境でもあります。また、技術を追及するスペシャリストになりたい、全体を見てチーム作りやプロジェクト推進を行うゼネラリストに興味があるなど、個人個人の進みたい方向を聞きながら、望んでいる環境を提供できるようバックアップします。

DIGGLEのバリューの1つに「自学成長」があります。個人と組織の学びが事業の成長につながるとして、個人の学びや経験の機会を増やすために積極的にサポートしています。弊社はPDCAのサイクルが確立していて成長しやすい環境でもあるので、やりたいことはどんどん主張してほしいです。

ーどんな人にDIGGLEに入ってほしいですか？

1つは、自律した人に入ってほしいです。主体性を持って、自分で考えて最適な行動をとれる人ですね。

もう1つは、自分の力でサービスを良くしたいという気持ちがある人がいいと思います。SaaSの会社なので、サービスに対して当事者意識を強く持ち、主体的に製品のことを考えられる人がDIGGLEにフィットすると思います。

また、スキルとして個別の言語経験はあまり重要視していません。システム開発の基礎の力があれば言語の違いは大きな壁にならないと思っています。現場にあわせて臨機応変な対応ができる普遍的な力がある人が望ましいですね。