ビジネスチームにスクラムを導入しようとしたら自分の内観が深まった話

これはなに

こんにちは。株式会社SmartHRコミュニケーションデザイングループ、Opsユニットチーフのmikityです。またの名をhase0831と申します。これはSmartHR AdventCalendar 2023、23日目の記事です。

この記事では、ビジネスサイドに所属するわたしのチームで、プロダクト開発の手法である「スクラム」を取り入れるまでの経緯ついて書いてみたいと思っています。

主にビジネスサイド、スクラムについてまったく分からない人向けのお話です。

そもそものきっかけ

わたしがチーフを担当しているコミュニケーションデザイン Opsユニットでは、デザイナーとノンデザイナーの間をつなぎ、クリエイティブ制作の業務スピードの改善や効率化を推進することをミッションとしています。

2023年の5月に立ち上がったユニットで、まだ混沌としているのですが、わたしたちはいくつかの課題を抱えています。

例をあげてみると、

雑多なリクエストが日々絶え間なく入ってくる
ユニットメンバーの得意分野がそれぞれバラバラ
人数が少なく、使えるリソースの総量がめっちゃ限られている
リクエストも短期的・長期的なものが混在している
タスク管理はそれぞれの裁量に任されており、統一されたルールはまだない

つまり、チームを運営する上で効率的なタスク管理をしないと、早晩崩壊することが予測され、立ち上げ当初からかなり焦りを感じていました。

「ゆるふわスクラム」に出会う

どうやら社内では様々なチームで「スクラム」というのにチャレンジしており、ビジネスサイドにも効くらしい……ということがだんだん分かってきました。

note.com

cocoda.design

「アジャイル」「スクラム」というと、プロダクト開発で使用されている手法のイメージがあり、なんとなく敬遠していたのですが、「設定された課題に対して」「最大のアウトプットを目指し」「最適な優先度をつけてタスクを管理するもの」ということがだんだん理解できてくると、これは、取り入れる価値があるのでは？！と感じられてきたので、「とりあえず見よう見まねでやってみよう！と試行錯誤することにしました。

そこで組んだのが以下のスケジュールです。

まず月曜に「タスク確認タイム」を設定し、その週のタスク優先度を議論しながら決定します
そして水曜に「スプリント」としてタスクの進捗やリソースの状況などをすり合わせます
最後は金曜に「振り返り」として今週やったことや感じたことの会話をする場を設けました

やってみて感じた課題

まず月〜金のサイクルを何回かまわしてみながら、メンバーそれぞれが感じている課題を洗い出してみました。出てきた課題感としてはこんな感じ。

本当にこれでいいのか……？
「やるべきこと」はわかったが、「今週やるべきこと」の切り分けが難しい
中長期のタスクが終わらず、マインドシェアを奪われ続ける

つまり、手探りすぎて怖い！

……震えながらも「とにかく現状がベターではないことがわかったので、素早く改善を回していこう！」ということになり、以下のどうなりたいか像を立てました。

全員にとって納得感・腹落ち感のあるタスク管理がしたい
タスクの分類を適切に切り分けられるようにしたい
「終わった！」という実感を得られる管理をしたい

そしてこの「どうなりたいか像」をもとに、社内の相談相手を探ってみたところ、なんと「アジャイル推進室」の存在を知り、toyotaさんにお知恵を借りることを思い立ちました。

toyotaさんについては以下の記事をご参照ください

tech.smarthr.jp

そこで学んだのは、スプリントやバックログ、スプリントプランニングなどについての基本的なこと。そして、「現状の課題に関しては、ちゃんとしたスクラムに寄せていくと解決するかもしれない」というアドバイスでした。

確かに見よう見まねでやり始めたスクラム、誰も正しいやり方を把握できておらず、相談できる相手もいません。とにかくアドバイスをもとに、社内に上がっているスクラムについてのドキュメントを片っ端から読み漁り、参考文書を購入する日々でしたが、ここである出会いがありました。

社内ハッカソンという光明

2023年夏、LLM（Large Language Model）と呼ばれるOpenAIの大規模言語モデルを活用した「LLMハッカソン」が社内で開催されたのですが、そこに参加した際、同じチームになったのがエンジニアの@sushi__melodyさん。「SmartHRがアジャイルになることを支援する」アジャイル推進室のメンバーでした。

社内ハッカソンでわたしたちのチームは惜しくも2位だったのですが、そこでの交流をきっかけに、スクラムなチーム運営のコーチを買って出てくれたのです。

そこで1on1をスタートし、「まずは信頼関係の構築から」といろいろ壁打ちをしていただいて、様々なことを学んでいくのですが、もっとも大きい手応えを感じたのは「不確実性」を怖がらなくなった、ということ。

不確実性 - Wikipedia

よく使われるフレームワークで、「空」「雨」「傘」というものがありますよね。「空（事実）」を見て曇っていたら「雨（解釈）」かな、と予測し、「傘（対策）」を持っていこう、というものですが、ここでいう「不確実性」というのは、「雨が降るかどうかわからない」ということかな、とわたしは解釈しています。

それまでのわたしは「雨が降るかわからない」という「不確実性」のある判断を選択することを恐れるあまり、性急に結論を出したがってしまい、必要以上の対策を取ってしまって無駄なリソースを消費したり、思考停止してしまったりする傾向がありました。

「不確実性」を恐れない

チーフであるわたしがそんな状態なので、チーム自体も結論を急いでしまったり、じっくり仮説を深めることなく短期的な対策を取ろうとしてしまうことにより、手探りでやり方を探ることを避け、インスタントな回答を出そうとしていまったのかなと感じています。

なのですが、sushi__melodyさんとの壁打ちや、アジャイル推進室の活動に触れることで、「不確実性」は恐れる対象ではなく「ただそこにあるもの」という認識に変わりました。

そして「不確実性」を恐れなくなったことにより、事実の解釈には様々なものがあり、どれが正解かは誰にもわからないし、わからないということは「悪」ではない、正解をストイックに求めるあまり、不正解を恐れて思考停止してしまうことのほうが怖い、と腹落ちしたのです。

このきっかけにより、さらにスクラムへの解像度が上がり、「分からないなりに見通しを立てることの重要性」「それを検分し、調整していくことの大切さ」を念頭におきながら再びチームの運営スタイルを見直していくのですが、長くなってしまったので今日はこのへんで。

挑戦はこれからも続く……

そんな感じで取り入れてみたらいきなり自分自身への内観が深まってしまった「スクラム」でしたが、本来は「分からないものに分からないなりに向き合い、攻略していくためのワクワクする手法」だと感じています。

そういう手法について考えている先輩方がたくさんいて、困っても検索すればたくさんのドキュメントがヒントを与えてくれます。営業や企画、チーム運営についてはたくさん経験してきたつもりでしたが、まだまだ知らない手法があると思うと、こんな最高なことはないよな〜と思っています。

そしてアジャイル推進室にお誘いしてくださった@sushi__melodyさんから、ありがたいコメントをいただきました！

こんにちは! sushi__melodyです。
アジャイル推進室はSmartHRがよりアジャイルになることを支援する社内コミュニティです。
スクラム開発に関する講座を行ったり、アジャイルに関することなら誰でも何でも話せるわいわい会を開催したりしています。
(より詳しくはアジャイル推進室メンバーへのインタビュー記事をお読みいただけると🙏)
ただ、どうしてもコミュニケーションがプロダクトサイドのメンバーで閉じてしまいがちというモヤモヤがありました。
なので、今回のmikityさんの取り組みに関われて大変うれしかったです。
mikityさんとの1on1がプロダクトサイドとビジネスサイドの違いを考えるキッカケになったり、逆に、不確実性と向き合いつつ顧客価値を最大化するというアジャイルであることそのものの考え方を学ぶキッカケになりました。

今後もプロダクトサイド/ビジネスサイド関係なくSmartHRがよりアジャイルになれるよう貢献していきたいと思っています💪