これからスクラムを導入する組織が心得ておくべきポイント
近年、スタートアップだけでなく、さまざまな企業で、プロダクトづくりにアジャイル的な開発手法を取り入れる動きが盛んだ。短期間でリリースと改善を繰り返しながら開発を進めていくアジャイルは、ビジネスの状況やユーザーの要求が変化していくことを前提に、競争力の高いプロダクトを生み出していく上で有効な手法として注目されている。
しかし、実際にアジャイルでの開発に取り組み始めると、多くの課題にも直面する。特に初期には、開発のスピードや成果物の質が思ったほど上がらないと感じることが多いかもしれない。また、ある程度軌道に乗り始めたと感じてからも、チーム規模の拡大に伴い、パフォーマンスに悪影響が出るケースもある。
アジャイルを通じて、プロダクト開発を加速させつつ、関わるチームも成長させていくためにできることは何だろうか。「ゆめみ」では現在、さまざまな規模の企業に対し、デジタルトランスフォーメーションに対応できるプロダクトの開発体制構築を支援する「内製化支援サービス」を提供している。
このサービスは、企業がプロダクト内製化にあたって直面する各種の課題に対し、解決策を提案するもの。解決すべき課題は、技術に関するものに限らず、成長を加速するための組織づくりや、その運用に関わるものなど多岐にわたる。ゆめみ自身が、創業から20年以上にわたって蓄積してきたそれらのノウハウを、同様の課題を抱える企業に対し、伴走しながら転移していくサービスであるという。
ゆめみでは、スクラムの方法論に基づいたアジャイル開発の進め方や、チームのあり方についても、このサービスの中で実践し、ノウハウを蓄積している。今回、ゆめみでスクラムマスターを務める、内藤寛貴氏と恒田響介氏に「これからスクラムを導入しようと考えている組織で、スクラムマスターが心得ておくべきポイント」について聞いた。
クライアントと共に成長させてきたプロダクトとスクラム体制
――お二人のスクラムマスター歴について教えてください。
内藤：20年ほどエンジニアをやっており、その中で、ゆめみでのスクラムマスター歴は3年ほどになります。当社が支援している、生活者向けのECサイト構築に関わる案件で、スクラムマスターとしてチーム全体の統括をしています。
恒田：私は、ゆめみに入って2年です。フロントエンドエンジニアとして入り、現在では内藤さんと同じ案件で、複数あるチームのうち、1つのチームのスクラムマスターを担当しています。
内藤：この案件自体は、5年ほど前から手がけているものです。当初は、AngularJSやReactによるUI開発のスキルを持った開発者の手が足りないということで支援に入ったのですが、その中でスクラムによるアジャイル開発を行っていました。スクラムを円滑に進めながら、プロダクトとチームをスケールさせていくための方法については、クライアントとゆめみが共同で試行錯誤してきました。
内藤寛貴（ないとう・ひろき）氏
スクラムマスター兼フロントエンドエンジニア。 2007年よりゆめみに在籍。デザイナー、ディレクターと経験を積みフロントエンジニアとなる。2016年よりスクラムチームに所属し2019年にスクラムマスターとして活動開始。Licensed Scrum MasterおよびLicensed Scrum Product Ownerも受講し、ゆめみ内でスクラムを推進している。
欲張らずに「チームに最も必要なもの」から段階的に取り入れる
――スクラム開発をスタートした初期のころ、どのような課題がありましたか。
内藤：時期によってチームの人数は変化していますが、当初は、ゆめみ側が約15人、クライアント側が約10人でスタートしました。プロダクトオーナーはクライアント側にいて、スクラムマスターはゆめみ側が務めています。クライアントは、すでにある程度のスクラム経験があるという状況でした。
支援に入ってしばらくしてから、先方より「あまりうまく進んでいないように感じている」というフィードバックをいただいたことがありました。
――それは、どのような理由からだったのでしょうか。
内藤：社外のメンバーと共同でチームを組んでのスクラムについては、互いに不慣れということもあり、最初はどうしてもメンバー間の心理的な距離がありました。コミュニケーションが十分でない状況で、「型どおり」のスクラムをやろうとしてしまったのが、つまずきの原因でした。
当初はゆめみのスクラムマスターが、クライアントとの窓口を一手に引き受けていたため、お互いに開発の状況が見えづらくなっていました。そうなると、うまくいっていない箇所も見えなくなり、短いスパンで改善を繰り返すというアジャイル開発の最も重要な部分が機能しませんでした。結果的に、当初はウォーターフォールとあまり変わらない進め方になってしまっていました。
――それを解決するために、どのような改善をしたのでしょうか。
内藤：最初に手をつけたのは「メンバー間の心理的な距離を縮める」ことでした。双方とも、他社側のメンバーに対してのコミュニケーションは、どうしても「かしこまった」感じになってしまいます。チャットツールなども活用しながら、雑談も含めたコミュニケーションを活性化し、まずは、互いの心理的安全性を高めるところからはじめました。
次の段階として、例えばデザインについては、モックアップを作成しながら、それを互いに見せ合ってフィードバックをもらい、改善していくような形で「ふりかえり」の習慣を根付かせるようにしていきました。
これからスクラムに取り組もうとしているチームには、何はなくとも、まず「ふりかえりを細かく実施する」ところから始めてみることを勧めます。ふりかえりを細かくすることで、大きな課題になる前に発見できるケースが多くなり、問題が発覚したときのチームの動揺も抑えやすくなります。われわれのチームでは、まず2週間（1スプリント）に1回のふりかえりを徹底できるようにしていきました。
恒田：自分にも経験があるのですが、スクラムを学ぶと、その本質を理解しないまま、まず型どおりにすべてを実践したくなりがちです。それは悪手で、重要なのはふりかえりの中で「今、自分たちのチームに何が必要なのか」を見きわめ、最も必要なものから順次取り入れていくことです。
内藤：チームがやり方に慣れてきたところで、次は「ふりかえり」の際に「できる限り自分のことを話さないようにしよう」と提案しました。ふりかえりに不慣れなメンバーは、「自分はこれをやった」とか「自分はこれができなかった」といった形で、自分のことに言及しがちです。そこから「チーム」としての課題や対策を考えられるように、意識を変えていこうということです。
恒田：これは「個人に課題が発生するのは、チームの課題でもある」という考え方への転換です。例えば、あるメンバーが特定のタスクを「できなかった」ときに、「チームとして、どう動いていれば、それができたのか」に置き換えて考えるということですね。これを意識し始めてからは、次第に良いふりかえりができるようになり、成果も上がりはじめました。
――「スクラムがうまくいっている」と判断する基準は、具体的にどのようなものですか。
内藤：まず、メンバー全員が肌感覚として「あぁ、うまく回っているな」と実感できる状況が出てきます。例えば「スプリントが順調に進んでいるな」とか「良いものが作れたな」というような感想が出てくるようになります。
定量的な指標で言えば、仕様を決めるまでの時間が短くなったり、それをメンバー全員が短時間で理解できるようになることで、テストでのバグ報告が少なくなったりといったものがあります。プロダクトオーナーも、そうした指標から「開発スピードが上がっている」「できるもののクオリティが上がっている」といったことを、成果として見られるようになります。
恒田：状況の可視化という観点では、全員のスキルが上がってきた段階で、ストーリーポイントなども導入できると、さらにチーム全体で見えてくるものが増すと思います。
恒田響介（つねだ・きょうすけ）氏
「ゲームアプリが一発当たれば一生うまいメシが食える」と聞き、就活を辞めてプログラミングに挑戦。年間1万円の利益しか出せず、極貧生活を送ることになる。1日2食の醤油パスタ生活に限界を感じ、急きょ会社員に。プログラマーとして紆余曲折する内にゆめみに入社。毎食寿司が食べられるようになりたい。
スクラムマスターが「チームの分割」を考えるべきタイミング
――クライアントとのスクラムをはじめて5年が経過し、現在はチーム内に複数のスクラムを編成されているそうですね。チームのメンバーが増えることで、スピードが落ちてしまう点を課題と感じるケースも多いようですが、ゆめみでは、どのように対応されていますか。
内藤：チームに新しいメンバーが加わる時というのは、課題が具現化しやすいタイミングでもあります。新メンバーが仕様を十分に把握したり、開発環境を構築したりするのに時間が掛かり、それが原因でスピードが落ちてしまうというのは、ある程度は仕方のないことです。
その点では、普段の作業の中で、オンボーディングのためのドキュメントを作ったり、それを見ても分からない場合の相談相手を決めたりといった形で「新しく入ってきたメンバーが困らない仕組み」を作ることを、段階的にやってきました。その仕組みについてもフィードバックをもらい、問題があれば改善を積み重ねている状況です。
そして、さらに人数が増えた段階で、チームの分割を検討しました。開発に関わるメンバーが増えると、会議で話される内容も広範にわたってきます。そうなると「あぁ、自分とあまり関係のないことを話しているな」とか「今日の会議、しんどいな」と感じる人が、どうしても増えてきます。全員が参加しなければならない会議の時間が長くなれば、結果として全体のスピードも落ちていきます。
自分がスクラムマスターをやるようになってから、開発のスピードを落とさず、チームをスケールしていくためには、チームを分割していく必要があると感じていました。幸い、エンジニアの中に、スクラムに興味を持ったメンバーが複数いたこともあり、彼らにチームを任せることにしました。
恒田：そのタイミングで、スクラムマスターになったうちの一人が私です。私は、ある程度人数が増えてからチームに加わったのですが、その時から、すでに会議の時間はかなり増えていましたね。「どうしたら、この状況を変えられるのか」という観点から、スクラムの手法に関心を持ち始めました。
ゆめみでは、社内で定期的に勉強会が行われているのですが、そこで内藤さんがスクラムについて話してくれたことがありました。それをきっかけに「今のチームでは、どういう改善ができるか」と考える中でチーム分割の話があり、スクラムマスターをやってみようと決心しました。
分割したチームは、スクラムマスターである私と、エンジニア5人の編成です。チームの役割は明確に分けられているので、実装にあたっては、どの部分を開発するかといった基本的な部分だけを、全体とすり合わせておけば、集中して作業に取り組めます。元のチームが大規模になって、各メンバーが考えなければならないこともどんどん増えていたのですが、分割をしたことで、それがシンプルになったのは良かったと思っています。コミュニケーションすべき相手や時間が明確になったため、スピード感は確実に増しました。
ツールを駆使して不足しがちなコミュニケーションを補完
――初期は「コミュニケーション」の改善からスタートされたとのことでした。企業間でチームを組織していることに加えて、近年ではコロナ禍の影響もあり、十分なコミュニケーションが難しい状況だと思うのですが、どのような対策をとっていますか。
内藤：冒頭にもお話ししたとおり、スクラム開発において、メンバー間のコミュニケーションは極めて重要です。特に「対面」でのコミュニケーションが効果的なのですが、それが難しい状況もあります。われわれの場合は、複数のツールを駆使して、少しでもコミュニケーションの頻度と質を高めようと試行錯誤しています。
恒田：基本にしているのは、Slackのようなテキストチャットと、Zoomのようなオンライン会議のツールです。あと、新しいところではバーチャルオフィスツールの「oVice（オヴィス）」も使っています。これは、実際のオフィスにいる時のように、ルーム内で別のメンバーが作業していたり、何人かが集まって立ち話をしていたりといった状況をオンラインで生みだしてくれるツールです。近くにいる人に気軽に声を掛けたり、立ち話に何気なく加わったりというのは、いわゆる「オンライン会議」では再現ができないシチュエーションなので、そうした部分を埋めるものとして導入しています。
内藤：そのほかにも、「Miro」というホワイトボードアプリケーションをSlackと組み合わせて使ったり、ゆめみ独自に作ったSlackのアドオンで「ありがとうフィードバック」のようなカジュアルなコミュニケーションができるようにしたりと、いろいろ工夫しています。
恒田：オンライン勤務が中心になって、特に感じるのは「雑談」的なコミュニケーションの重要度が、さらに増しているということです。これについては、体調報告でも何でもいいので、意図的に「雑談」をするように、メンバーに意識してもらっています。雑談の重要性については、クライアント側にも理解してもらえていて、会議の最後に、参加者全員での「雑談タイム」を設けたりしました。
実践で蓄積したノウハウを共有し組織としてのスキル向上を目指す
――この案件での取り組みをきっかけに、今後ゆめみでは、どのような形でスクラムの習熟度を高めていきたいと考えていますか。
内藤：社内外の協力もあり、複数のチームがそれぞれに動きながら、プロダクト全体の質とリリース速度を上げていく体制が、きちんとできあがってきました。今後も、役割をバランスよく振り分けながらチームを分割していけば、プロダクトをうまくスケールさせていけるだろうとの手応えを感じています。
その成果については、社内の勉強会などを通じて、他のクライアントを支援しているチームなどとも共有し、それぞれに、自分たちの案件で応用できるようにしていきたいと思っています。
恒田：私はスクラムマスターをはじめたばかりですが、困りごとが出てきたときに、内藤さんをはじめ、社内にコーチ的な立場でアドバイスをしてくれる人がいて良かったと感じています。また、先輩だけでなく、チームメンバーからのフィードバックも、スクラムの進め方を改善していく上での重要なヒントになっていると感じています。大勢の人に助けてもらったり、逆に助けたりしながら、組織としてのスキルを高めていきたいですね。
