業務効率化フレームワークとしてのスクラム導入事例 - 開発以外でのスクラム活用

開発以外へのスクラム導入ガイド

はじめまして！GMOペパボの和島（@wajimaf）です。私が勤務するGMOペパボは「ロリポップ！レンタルサーバー byGMOペパボ」をはじめ、ハンドメイドマーケット「minne byGMOペパボ」、ネットショップ作成サービス「カラーミーショップ byGMOペパボ」、オリジナルグッズ作成・販売サービス「SUZURI byGMOペパボ」など、「インターネットで可能性をつなげる、広げる」をミッションにさまざまなサービスを展開しています。

各チーム、それぞれが最適な開発体制を追求しており、もちろんスクラムに取り組むチームも多いです。そして、弊社ではスクラムやスクラムに含まれるプラクティスに取り組んでいるのは“開発”チームだけではありません。バックオフィスや広報など、“開発以外”の業務でも関わるメンバーたちが朝会や振り返り会といったプラクティスを導入し、効率化を進めているのです。

私自身は2010年にブログサービスのデザイナーとして中途で入社し、デザイナー、スクラムマスター、事業部マネージャー、バックオフィスマネージャーなどの経験を経て、今は社長室でサービス横断型のディレクター・プロジェクトマネージャーとして働いており、ときにさまざまなチームへのスクラム導入支援なども行っています。2022年11月にはホスティング事業部に異動になりました。

本稿では、開発業務以外にスクラムの要素を採り入れるために、私たちが行ってきたことをお伝えします。少しでも皆様のお役に立てたら嬉しいです。

スクラムのはじまり
なぜスクラムが必要だったのか？なぜ開発“以外”にも広げようとしたのか？
スクラム導入の前に大事なこと
- KPTで解決すべき業務課題を抽出する
- 課題解決に向けたTryを設定する
必要なプラクティスだけ「よりぬきスクラム」を形にする
素早く始め、素早く成功体験を得る。スクラム定着に重要なこと

スクラムのはじまり

さて、弊社、そして私とスクラムの出会いは結構前の2013年ごろでした。「全社でスクラムを導入しよう！」という勢いのもと、外部講師を迎えスクラムに取り組んでいったのです。

外部講師を招いた勉強会

こうした全社的な流れの中、私は専任のスクラムマスターという役割につきました。スクラム導入を経験した方には既知かと思いますが、会社に対して貢献するかどうかも分からないスクラムという新たな試みのために、「スクラムマスターを専任で用意する」という判断はなかなかされません。にもかかわらず、私がこの任についたのは、当時所属していた事業部が「スクラムを組成しやすい」体制になっていたからです。

当時の事業部は、社内では珍しい「マネージャーとそのサブとして私がいる」というマネージメント2人体制を採用していました。つまりプロダクトオーナー（マネージャー）とスクラムマスター（私）という、スクラムの役割を採り入れやすい状況が整っていました。このような背景から、私がスクラムマスターを専任で務めることとなったのです。こうした幸運があったおかげで、私は自部署でのスクラム組成に専念でき、スムーズに導入に取り組めました。専任のスクラムマスターが用意できない部署には私が「部署横断スクラムマスター」として導入を支援しました。

2022年現在では会社やサービスの規模も拡大し、「全社でスクラムやるぞ！」という空気は少し形を変え、生産性向上を第一に各部署のチーム単位でスクラムを導入していたり、KPTを使った振り返りやタスクボードで優先順位を管理したり、イベント単位で利用するなど、「自然とスクラムやそのプラクティスを採り入れる」という状況が散見されます。

なぜスクラムが必要だったのか？なぜ開発“以外”にも広げようとしたのか？

当時、私が所属する事業部が運営していたブログサービスは、2013年の段階ですでにローンチから10年近くが経過した老舗サービスでした。長く続くこと自体は素晴らしいですが、その裏側では、サービスの安定運用に関するタスク、新機能追加タスク、サーバーの老朽化対策、脆弱性の対応など、日々何かしらの対応に追われている状態でした。

また、当時は開発環境やリモート体制も充実しておらず、不具合も頻発しており、開発スケジュールや不具合対応の優先順位付けが不明瞭のまま、作業が属人化していく一方、という課題を抱えていたのです。

課題を抱えていようとも、サービスや組織は拡大していく必要があります。人的リソースや設備に投資し、開発メンバー個々のスキルや環境は充実していきますが、それでも根本的な課題が解決されるわけではなく、仕事のやり方そのものを大きく変える必要性を感じていました。2013年の全社的なスクラム導入の取り組みは、こうした開発業務を改善するための取り組みでした。そして、「仕事のやり方を変えなくては」という課題は、私が所属していた事業部のみならず他の事業部やバックオフィスでも顕在化していました。

開発現場以外でもスクラムを導入する決定的なきっかけとなったのが、2014年頃にバックオフィスの責任者から「あるパートナー*1（仮にA氏とします）が日々のルーチンワークだけで業務がいっぱいになってしまうので負荷を軽減したい。スクラムが解決策になり得るか？」と相談があったことです。

スクラム導入の前に大事なこと

KPTで解決すべき業務課題を抽出する

A氏の業務は、ユーザー様から寄せられる声が起点となるため、サービス拡大に比例してタスクは増え、なおかつ対応には専門知識が要求されるものです。こうした業務にどのような改善点を見出すのか。まずA氏とその責任者を交え、「現状の洗い出しとしてのふりかえり」を実施しKPTに落とし込み、「ゴールの設定」を行います。KPTをするなかで、A氏の業務から以下のような課題が抽出されたのです。

組織拡大にともない、ルーチンワークの量が増加しているにもかかわらず、やり方は過去を踏襲したまま
本来、事業部と分担可能な作業も担っている

これら課題を解決した先に、どのようなゴールを設定するべきでしょうか。このケースでは「A氏の負荷軽減」が発端となっているので、ゴールはシンプルに「A氏の業務時間の削減し、専門知識を生かしたより広範囲の業務にアプローチできるようにする」と設定できます。そしてこのゴールに向かうために「来月のA氏のルーチンワークにかかる時間をnn%削減する」といった短期的な定量目標を合わせて設定しました。

A氏のケースは少々古いサンプルですが、最近では広報もタスクの属人化や業務量の偏りが課題になっていると責任者から相談があり、同じように責任者と担当者を交え、「現状（KPT）の洗い出し」と「ゴールの設定」から改善の端緒を探っていたりもします。こちらのケースでもまずは「広報としてのタッチポイント拡大」を中長期目標に、「月末までにメディアアプローチをn件以上、メディアとのアポイントをn件以上獲得する」といった、具体的かつ短期的な定量目標と期限を設定し、スクラム導入前の下地づくりを行っています。

少し話がそれますが、仕事のやり方を変える際、一番大事だと感じるのは、プロダクトオーナーとなる責任者と当事者である担当者を交えて「一緒に考えること」です。どのような業務でも、責任者と担当者に「当事者意識」がなければ改善への取り組みは必ずと言っていいほど失敗します。スクラムも「やらされてる」「用意されたもの」「今のやり方を否定されたようだ」という認識では、成功は決して望めません。まず、共通のゴールをイメージし、自発的にKPTを出すことがなによりも大切です。

ですから、チームにスクラムを導入する際も、メンバーに「今のやり方はよくないのでスクラムを導入します」と、「スクラム」という言葉を旗頭にしたコミュニケーションをすることは、基本的にありません。「目標達成に向けてみんなが抱えている悩みを解決するために、色々なやり方を試していこう」という促し方をしています。

課題解決に向けたTryを設定する

話をA氏のケースに戻します。ゴールが設定できたら、次にそのゴールに達するための改善方法（Try）を導き出します。ヒアリングやKPTによって抽出される課題は、往々にして「業務の見える化」「タスクの優先順位付け」「定期的な振り返り（KPT）」が改善への手がかりになります。A氏ケースでは

デイリースクラム（朝会）→A氏のルーティンワークを可視化し、チームで共有し業務分散できるようにする
看板（タスクボード）→A氏に集約され、属人化している業務を分解 / 可視化する。また、チームで臨むタスクの優先順位を整理する
スプリントレトロスペクティブ（振り返り）→課題解決のための取り組みを評価し、さらなる効率化のための材料を取得。また「チームでやってる」感を生み出すため

といったプラクティスを採り入れ、課題解決に取り組んでいったのです。

必要なプラクティスだけ「よりぬきスクラム」を形にする

本稿をここまでご覧になった方は「それはスクラムではなく、スクラムの一部を切り出しただけ」と思われるかもしれません。その指摘は正しく、私たちが実施したのは、チームの課題にフィットする“都合のいい”プラクティスだけを抜き出した「よりぬきスクラム」です。

スクラムは「理解は容易、習得は困難」と表現されるように、そのフレームワークをまるごときちんと実践するのはとても困難です。また、いきなりスクラムをまるごと導入し、それがチームにフィットしなければ形骸化してしまう可能性もあります。ですから、まずは「できそうなこと、効果がありそうなこと」にしぼり、スクラムを「ひとまず、小さく始めてみる」のが重要だと考えています。

私がスクラムマスターの立場として上述のバックオフィス業務、広報業務、そしてそれ以外の業務で実践してみた汎用的なプラクティスを3つ紹介します。運用のなかで私が心がけているTipsも合わせてお伝えしますので、ぜひ参考にしてみてください。

まずはやってみて、効果が出ればそのチームの「勝ちパターン」になるので、「勝ちパターン」のための必殺カードを増やしていき、チーム全体をパワーアップさせていきましょう。

よりぬきスクラムその1：朝会

朝会、つまりデイリースクラムは「業務の見える化」のほか、メンバー全員に「当事者意識」を持ってもらうためにも有効だと感じています。そのために重要なのは以下のポイントです。

上下関係がない場にする
参加者は必ず自分が発言する（自分が主役になる）場＝にする。最近はオンラインで行うことが多いので「カメラはできる範囲でONにしましょう」という感じで、顔が見えるようするとなおよい

上記に加え、司会進行も大事です。できる限り明るく元気に行い、チームに勢いを与えたいところです。最初は私が司会進行を行ったりしますが、慣れてきたら司会進行もチーム内で持ち回りにした方が新鮮さが保たれ、持続しやすいと感じています。

また、メンバーのタスクに関して質問する際は「困ってることはありますか？」と聞いても言い出しづらいですが「なんか困りそうな事ありますか？」と聞くと、結構「そういえば先方から折り返しの連絡が来てなくて、このままだとやばいかも」といった具合に、火種となりそうなトピックが出てきやすくなる場合がありますので、ぜひお試しを。また、朝会はコミュニケーションの場であることを忘れてはなりません。ですから、「雨が続いて洗濯物が乾かない」などの雑談も重要です。

朝会の場で各々が発言することで「私は何のためにここにいるんだろう」「あの人はなんの仕事をしているんだろう」と悩む人がいなくなったり、朝会をきっかけに「今の状況だと困ったことになりそうなので、朝会の後に別途相談させてください」と自発的に取り組めるようになったら「チームの勝ちパターン」に入ってると思います。

よりぬきスクラムその2：看板・タスクボード

看板・タスクボードは業務が属人化しているチームに有効だと感じています。チーム全体のタスクや優先順位が見えるようになるので、急な差し込み業務や方針変更といった「変化に対応するため」に活用できます。またタスクの偏りも早期に発見できます。重要なのはチーム全体を見えるようにすることと、チームメンバー誰が見てもわかる内容にしておくことです。このためには、タスクの記載の仕方も重要で、以下の資料のように明示的な言葉で記載するように呼びかけます。

書き方だけでなく、「期限を設定する」「無理な内容や願望は書かない」など、事前にルールを決めておき、メンバーには遵守してもらうようにします。ルール通りになっていない場合は逐一確認して修正していく根気が必要です。

また属人化しているチームだとタスクボードの管理自体が負荷になってしまう場合がありますが、「なぜやるのか」の当事者意識を前提にチームにあったやり方を日々模索してアップデートしましょう。

なお、ボード管理は広報の場合、オンライン・オフラインの業務が混在するためNotionを使っています。チームにあわせてツールを選びましょう。

よりぬきスクラムその3：振り返り会（KPT)

KPTは私が一番大好きなプラクティスです。KPTに出会う前はリリース後に「反省会」という名のもとにProblemばかりを出すミーティングを行ってきましたが、せっかくリリースできたのに、なぜ反省ばかりしなければならないんだろうと疑問に思っていたのです。

一方で振り返り会は「反省会ではない」「Problemを1つ出したらKeepも1つ出す」というルールを定めて、「何か新しい行動を生むこと（Tryを出すこと）」を強く意識して実践しています。またできるかぎりメンバーの関係性をよりよくし、楽しく褒めあえる場にできるように心がけています。

振り返り会で重要なのが「実施サイクル（スプリント期間）」です。大型のプロジェクトではなく、日々の業務改善のために行っているのであれば、私は週1回の振り返り会を推薦しています。期間が長くなればなるほど振り返る内容が多くなるので、まとめが難しくなり、またProblemの発見も遅れます。Problemを早々に検知するためにも、週1回など短めのサイクルで会を実施したいところです。実際にバックオフィス、広報、いずれの業務でも週1回行っています。また振り返り会はファシリテーターの力がとても重要です。慣れるまで社内で得意な人に頼むなどしてもいいかもしれません。

主にTryが実践できたか、Problemは解決できたかをディスカッションし、仕事のやり方をブラッシュアップしていきます。何度か振り返りを積み重ねると、具体的なTryがどんどん出てきてProblemを解決していきます。そのTry一つ一つがそのチームの「勝ちパターン」になるわけです。最高。

反対に振り返り会に全然人が集まらなかったり、同じProblemが出続けたり、Tryも「がんばる」とか「時間を作る」とか「来年までに10人増員する」といった漠然としたものや、自分たちではどうにもできないものしか出てこなかったりした場合、まず当事者意識が持てているチームになっているかを見直しましょう。

振り返り会実践例：バックオフィス編

週1で振り返り会を行い、ボトルネックになっている部分の洗い出しから着手しました。そのProblemに対してのTryをみんなで考えて実践してを繰り返して改善していき、結果、担当者の負荷が40％軽減できました。

振り返り会実践例：広報編

Notionでタスクボードを運用し、振り返り会は週1回Jamboardを使って行っています。振り返り会で「週1の振り返り会だけだと共有の時間が足りないので、毎朝カジュアルに話し合える時間を作ろうか」とチーム自体で朝会を行うように活性化しています。すごい。

素早く始め、素早く成功体験を得る。スクラム定着に重要なこと

駆け足でしたが、これらが開発業務以外にスクラムのプラクティスを導入するために実施したことです。もちろん、すべてがきちんとワークしたわけではなく、課題も多くありました。そもそも、仕事のやり方を変えようという試みは、チーム全体がポジティブに取り組めるものではありません。「今までのやり方を否定されている気がする」という意見もあれば、そもそも「なぜ変えなければならないのか」という根本的な目的が共有できない場合もあります。

今まで頑張ってきてくれた人ややり方があったおかげで、会社や仕事の「いま」があるのは紛れもない事実です。変化を起こそうとする際は、旧来の価値観へのリスペクトを大事にしつつ、会社もサービスも人も成長し変化し続けるものである事をみんなで自覚し、「やり方を変える」のではなく「アップデートさせる」という意識を根付かせ、当事者意識を生むことが、ポジティブな変化をもたらすうえで重要です。

もしどうしてもポジティブになれない、あるいはワークしないようであれば、スクラム以外のやり方やチーム再編といったアプローチも視野に入れるべきでしょう。「スクラムを実践する＝仕事のしかたを変える」とは責任者にとってそれほどの覚悟が必要だと感じています。

スクラムという新たな試みを形骸化させず、ワークするものへとするために、どんなに小さくてもいいので成功体験を積み重ねていくのが重要です。成功体験とは、いわばそのチームが見つけた「勝ちパターン」です。チームに新たな課題が見つかっても「我々にはあの勝ちパターンがあるぞ！」とメンバーが思えれば、それはまさしく新たな試みの結実です。そして、勝ちパターンを増やせば増やすほどチームは強くなります。そのためにも振り返り会で褒めあい称えあいましょう。

スクラムのルールに反するかもしれませんが、よりぬきスクラムの1つでもいいので実践してみて、チームにあった「勝ちパターン」をぜひ見つけてください。良い部分だけ、都合よく。