皆さんこんにちは。DMM.comマーケティング本部データプランニング部 データインフラグループ デベロッパーサポートチームの内藤です。
私は2019年に中途入社後に認定スクラムマスター(CSM)を取得して以降、専任スクラムマスターとして数チームで活動しました。現チームでは2021年3月の立ち上げ時からチームリーダーを担当しています。
突然ですが皆さんにとってチームとはどのような存在でしょうか？気の置けない仲良し？ ちょっとよそよそしい？ 派閥がある？ 頼りになる？ ちょっと怖い？
今回の記事は、私が現在のチームを立ち上げる際にメンバーと共に取り組んだこと、その結果や効果、感じたことについて書いていきます。
私たちもまだ発展途上の取り組みではありますが、チームビルディングに悩みや不安をお持ちの方にとって、参考になれば幸いです。
一番言いたいこと
大事なので忘れる前に先に書きます。
私は、 非プロダクト開発のチームや運用支援のチームであっても、アジャイルな進め方やスクラムチームとして活動することがとても効果的だった 、と感じています。
これから、（チームがアジャイルなチームでいてくれて）嬉しかったなーと感じたポイントを幾つか書いてみます。
アジャイルなチームで嬉しかったこと
- ベクトルが揃いやすい
- みんなが等しくチームに貢献する責務を持つ雰囲気があるため、言いたいこと・やりたいこと・考えていること、が出て来やすい
- レトロスペクティブで定期的なプロセスの見直しをするため、チームとしての価値基準や連続性を維持しやすい
- 皆の血肉となった共通言語を用いることで、同じ文化の「ひとつのチーム」という雰囲気を作り出しやすい
- チャレンジしやすい
- 小さな単位（1週間）で業務するため、ダメなら止めよう・ちょっと直そうがやりやすく、「ちょっとしたカイゼンアイディア」を試しやすい
- デイリーで毎朝TRYを確認するため、「あーこのTRYうまくやれてないかも」とその場でカイゼンに取り組みやすい
- 普段から考えをオープンに出したり感謝しあったりするため、きちんと議論してベターな意見にたどり着きやすい
- チームワークを発揮しやすい
- 自分が今チームにできることは何かを考えてくれるため、メンバー同士の助け合い・高め合いが普段から行われ、できないことへの不安感を減らしやすい
- 自分に期待されていることは何かをそれぞれが理解してくれているため、変な遠慮を減らそうという雰囲気を作りやすい
- 「自分だけができる」から「チームができる」を優先するよう活動してくれるため、知識の属人性が排除させやすい
- 何より「楽しい」
- 日々の業務の中で自分達自身に向き合う機会が多くあるため、自分達の成長や成果（停滞や失敗も）を実感しやすい
- メンバーの価値を探し、認め、尊敬することで、自分自身にも価値があると感じやすい
これらは一朝一夕で得られたものではなく困難もありましたし時間もかかりました。また、まだまだもっと見直していける部分も多く残っています。
やってきたこと
ここからは、サポートチームをアジャイルなチームとするまでに行った、幾つかの事例をご紹介していきます。
学習しようという雰囲気作り
まず自分自身がメンバーに向けて、「私には学習が必要です。皆さん教えてください！」「その代わり、私が知っていることはじゃんじゃん教えます！」というスタンスを打ち出しました。
そもそも私に知識も経験も無かったことは事実なのですが、「教えあい学び合うことが普通なんだ」とするために、まずは自己開示が必要だと考えました。
教え合うことは生徒役の知識底上げになりますが、同時に教師役への尊敬にも繋がりますし、教師役自身の当事者意識や自信も高めてくれます。
当然キャリアによって教師：生徒の割合は異なります。ジュニアクラスの生徒割合が高くなりやすいですが、考え方を変えれば、学んだことをどんどん発揮してくれることが恩に報いるとも言えます。出世払いみたいなもんでしょうか？（違うか？） 生徒のチャレンジ（成果が出なかったら特に）には、教師役がしっかり見て、事実を感謝として伝えることが大事になると思います。
要は、今分からないこと・学ぶ必要があること自体を卑屈に考えなくてもいいんだよ、ガンガンいこうぜ！ ということです。
チームとは何かを学習する
次に「私達はどんなチームになるべきでしょうか？」「そもそもチームとは何でしょうか？」「良いチーム 良くないチーム があるのでしょうか？」といった目線合わせからはじめました。
まっさらから始まる新チームだったことを幸いと考え、 私達の考えたチームとは？ を定義し、そこに今足らないものは何か？ を議論 しました。パッケージソフト導入の要件定義でFit&Gap分析するみたいな感覚です。
チームとしてこれから学び、伸ばすべきことはそのギャップ部分です。
メンバーとしては恐らくこの時、「なんでこんな幼稚な部分から話し合わなきゃならないんだ」と思っていたと思いますが、「まずは私を信じて、ちょっとだけこのアクティビティを一緒にやってみようよ」と拝み倒しつつ進めてみました。
この取り組みの中でメンバーは、自分達にとって良いチームとは何か、自分に何ができるか？ を頭に描き始めることになります。
どんなチームになりたいか？ どうやって近づいていくか？
ここまでで理想のチームが描かれつつあると思うので、ここから自分達の足元や周りに目を向けてみます。
このチームが組織されたのはどんな期待が背景にあるのか？ 自分達のやりたいこととどれほどギャップがあるのか？ を考え、それぞれを Y字の右辺と左辺のように考え、ガッチャンコしてひとつの「想い」 をみんなで描いてみます。私が何度か使ったのはチームキャンバスというアクティビティです。
恐らくはうまく議論が進まなかったり、声の大きな人の意見が通ってしまいがちです。ここでもアジャイルなふりかえりでよく登場する、付箋を使ったアクティビティで小さな声の意見もまんべんなく吸い上げることを目指します。
このあと 目標の細分化 も行います。
例えばチームの目標が「メジャーリーグで優勝したい」であった場合を例に説明します。
- 3年後には地区優勝してたらいいのかな？
- 1年後には上位クラス入りしておきたいよな
- とすると、半年後にはメンバー補強が必要かもしれないぞ？
というように、目標の到達地点を未来側から現在側へと細分化します。
つまり、目標を細分化することで自分達がいつまでに何をやるべきか？ どうやってこの山を登るか？ をイメージしやすくできるようになります。
山の登り方を議論するなかで、自分達の仕事の進め方、すなわちプロセスや約束事についても議論します。
結局我々はコロコロ変わる状況に追随しやすく、事実や挑戦から学習し続けることを希望し、スクラムをやってみよう！ と選んだわけですが、その時点で私以外のスクラム経験者はほぼ無し。
もしかしたらとんでもない楽観主義者の集まりなのかもしれませんｗ
ちなみに私はこの時期によく使った言葉は 「自分達の価値」「介在価値」「価値を届ける」 という言葉です。「我々はなぜここにいるのか？」というタフクエスチョンが有名ですがそれも近いと思います。
我々が介在することで、その左右の人々のどのような「不」が解消できるのか？ 「だからあなた達に頼みたい」と思われるのか？ どうやったらその価値を早く届けられるのか？ ということをみんなで考えていました。
この取り組みの中で、健全なチームなら様々な議論が紛糾するはずです。ここでの衝突は不可避で、タックマンモデルで言うところの混乱期をきちんと通過せずに下手に回避するとあとでしっぺ返しを喰らいます。健全な議論のキーワードとしては、スクラムの祖父である野中先生の仰る「知的コンバット」という言葉もあります。ファシリテーターには、メンバーに議論することの正当性や健全性を持ってもらうような場作りや、メンバーの熱量と集中力を上手く活かす裏回しが求められると思います。
フィードバック
自分自身を客観視するのはとても難しいことです。偉い人でも自分にコーチをつける人がいるのはまさに自己客観視の難しさの現れだと思います。我々も自分たちの行いについて、一方向でもなく、多方向でもなく、双方向にフィードバックし合う仕組みが必要です。また、事実と感想・想像は区別して相手に伝える必要があります。フィードバックする側とされる側、双方にある程度の慣れが必要かもしれません。
良いフィードバックの結果、そのフィードバックがポジティブ／ネガティブいずれであったとしてもチームが得るものは勇気と自信、そして学びや気づきだと思います。閉鎖的・盲目的な思い込みや古びて今に合わない成功体験から抜け出す（アンラーンできる）いい機会になるはずです。
フィードバックと言えば、我々はスクラム・アジャイル初心者が多かったこともあり、チーム立ち上げ最初期、毎日デイリー後15分間のアジャイルやスクラムに関するワンテーマ勉強会を開催しており、テーマは日々メンバーに選んでもらっていました。その日その時の課題感から気になるものを選んでもらう（ときには選ぶよう仕向けることもｗ）ことで、チームの様子を観察した結果を私はチームにフィードバックしていたのかもしれません。
例えば…
「みんなは今これに悩んでいるわけだけど、みんなは今あらためてどう思う？」 「私にはこういう風にも見えたんだよね」 「実はこういう時、アジャイルな考え方では XXXX みたいなことをよく言うんだけど、もし聞いてみたかったら少し説明してみるけど？」 「（説明終わって） ...という話なんだけど。もし気に入ったら今週ちょっと試しにやってみない？ どうかな？」
みたいな感じです。
さも自然に話題を出している（つもり）のですが、実際はめちゃくちゃ事前に準備したりしていました。こういうネタ仕込みはスクラムマスターの腕の見せどころのひとつかもしれません。
その他
ここまで幾つかのポイントをご紹介してきました。
もちろんこれら以外にもチームの気づきやその時の課題感に合わせて問いを投げかけ、チーム自身が自ら気づいて変わっていくことを見守ってきました。
以下はその例です。
- ふりかえり手法（アクティビティ）をいろいろ試してみたり
- チームの心理的安全性を計測してみたり
- 非開発チームにどうやってモブワークやペアワークを根付かせるか苦心したり
- プロダクトを作らないチームのスプリントレビューっていったい何をやるんだろうと悩んでみたり
- チーム活動の数値化に取り組んだり
- ...等
上記のように各種イベントでいろいろ試してきたので話題には事欠かないのですが、これだけでもう一本記事が書けるくらいになってしまいそうなので、また次の機会にしたいと思います。
良かったこと
チーム発足から約8ヶ月ほど、ここまでやってみてホント良かったなーと思えることについて書いてみます。
様々な困難もありましたが、徐々に自己組織化が進みつつあるな、という手応えを感じています。
チームがこのスタイルを気に入ってくれたこと
非プロダクト開発チームに対してスクラムを適用することに最初不安はありましたが、メンバーみんなが思いの外楽しみながらやってくれたのが良かったです。
何か新たに学ぶ新鮮さだったり、経験学習を通じて少しずつでも良くなっていくのを実感できたのが原動力になったのではないか、と考えています。
何より学ぶこと、実践すること、カイゼンすることを楽しんでくれているのが本当にありがたく、私自身も励まされています！
自分達で考え、決断し、行動するようになったこと
手広くとまでは言えませんが、それでも「これ、やっておきました！」的な先回り事例を聞くたび、とても嬉しくなってしまいます。
経験を通じて学んだことがメンバー同士の当たり前となることでメンバー全体に暗黙知として蓄積されていき、それらひとつひとつがまた自信となっていくのだなとも感じます。
すぐに変化に対応できたこと
チーム活動の客観評価指標としてCESを計測しているのですが、そのスコア下落時にみんなで原因が「依頼者への共感不足」だと突き止め、すぐにチームの行動に反映させられたのはすごく良かったと感じます。
KPIの変化を自分ごととして当事者意識を高く持ち、じゃあまずコレを試してみよう！ とすぐ対応に動けるフットワークの軽さや、取り組み方を当たり前に変化させられることには私自身も驚きました。
共通言語が増えたこと
チーム活動を通じて、失敗も成功も同じく経験を重ねたメンバー同士だからこそ生まれる共通言語。パターン・ランゲージもしくは単に内輪ノリかもしれませんが、同じキーワードから同じインスピレーションを得られたり思い出せたりできることが増えました。
アジャイルなチームを作ることとは、組織文化を作ることなんだな、と実感させられました。
うまく行かないこと
現時点で継続対応中の課題たちも挙げてみます。
すぐには成果が出ないこと
これは至極当然のことで単純にいえば練習と上達が必要だということです。
逆に言えば銀の弾丸が無いのだと改めて分かった、ということなのですが、自分もメンバーも粘り強くその時を待つ必要があります。
だからこそ、小さな変化もみんなで喜び合う必要があるのかもしれないです。
不向きなこともあること
なんでもかんでもひとつのやり方に当てはめると失敗するよね、というものです。
成功体験が増えるとより保守的になりやすいというか、すぐに横展開しようとしだします。まったく同じ状況などないはずなのに、あたかも万能なもののように。
もちろん横展開がうまくハマることもあるのですが、失敗しても学ぶことがあればそれもまた良し、と考えていくのが良いのかな、と考えています。
例えば、何でもかんでもペアやモブでやる必要があるか？ 問題です。みんなが既に知っていたり、誰がやってもあまり変わらないようなことはむしろソロワークでも良いと考えます。
私がチームでやることが向いていると感じる（＝フロー効率最適化が良い）のが「初めてのもの」「難しいもの」「不安があるもの」みたいなケースで、向いていない（リソース効率最適化で良い）のが「手順が明確なもの」「パワーや人数で分担したほうがいいもの」みたいなケースです。
| 向き／不向き | ケース |
|---|---|
| チーム作業向きかも | 初めてのもの、難しいもの、不安があるもの |
| チーム作業向きじゃないかも | 手順が明確なもの、パワーや人数で分担したほうがいいもの |
遅く感じること
上2つにも関わる話ですが、チームで対応し学習や同質化することに重きを置いている部分が、何も考えずに全てに適用してしまうと確かにムダに思えるようなことも出てきます。
大事なのはやり方を大事に守ることよりも、チームとしてユーザーに価値を早く届けることなので、変な先入観や勝ちパターンに固執せず、学びあいを忘れないチームで居続けられるようにしたいと思います。
他にも遅く感じるケースとして、思考がリソース効率に引っ張られてしまうことがあります。油断するともっとパラレルに仕事したら早いんじゃ？ と考えてしまいがちです。チーム学習での成果の取り込みや作業内容の同期コスト削減など、ひとつずつ確実に価値を提供し続ける速さ（フロー効率）について丁寧な練習やフィードバックを繰り返すことで慣らしていくことの必要性を痛感すると同時に、難しいなぁと感じる部分でもあります。
個々人の向上が停滞気味なこと
これは、チームでの対応を優先したことと若干の勘違いが合わさり、経験の少ない人が経験の多い人に依存してしまう状況が少なからず発生しがちです。
まずは
- その事実をチーム全体が課題認識したうえで、
- ペアワークにおけるドライバーとナビゲーターの関係性を再度考え直すこと、
- 学びの機会・失敗の機会を増やすため、経験の少ないメンバーが主体的にタスクをサインアップしやすい場作り
が必要だと感じています。
まとめ
いかがでしたでしょうか？
今回は、アジャイルやスクラムという文脈を足がかりに、相互に協力し高め合い、経験から学び、価値を早く提供できるよう学習するユーザーサポートチームを作った、というお話しでした。
プロダクト開発をしないユーザーサポートチームであっても、アジャイルな考えを軸にして自分たちの介在価値やチームへの期待に向き合うことで、機能的で自己管理されたチームとなることができるんだ、と分かったことが収穫でした。判断に迷うシチュエーションで「この価値を早く届けるにはどうしたら良いか」をメンバー自身が考えてくれるようになりました。アジャイルという思考の軸が一本通っていたからこそだと思います。
私たちもまだまだできないことだらけで常に模索中です。小さな実験や「うっ」と尻込みすることへも、メンバーと一緒に勇気出して日々トライし続けています。
そんな我々の取り組みが、同じようにチームビルディングに悩みや不安をお持ちの方へ、微力でもお力になれましたらうれしいです。
最後までお読みいただきありがとうございました。
参考