NEWS ニュース

【タイトル】ワークショップで体得する、チームビルディング

【日　　時】2020/1/25 (Sat) 13：30-16：00

【場　　所】なごのキャンパス HOMEROOM（コワーキングスペース）

Reported by kei

イベントレポートは参加者の方にリレー形式で担当していただいています。ライターの個性を尊重し、文章のテイストはあえて統一していません。

組織・チームにおけるマネジメントに携わる方であれば、近年「チームビルディング」というキーワードを耳にする機会が増えているのではないでしょうか。

私もそんな1人として「チームビルディング」に関する書籍・記事を漁っていると、システム開発界隈には「スクラム」というフレームワークがあることを知りました。

なごのキャンパスで1/25に開催された「ワークショップで体得する、チームビルディング」。
チームビルディングとスクラムはどういう関係性なのか。
タイトルにある”ワークショップ”とは何をするのか。

イベントに参加して見えてきたものについてまとめていきます。

■講師

うさぎ組　kyon氏　/　なごのキャンパス　シェアオフィス入居者
公式サイト：https://kyon-mm.com/

今回の講師はkyon氏。なごのキャンパスのシェアオフィス入居者でもあり、”うさぎ組”という屋号で社会人・学生・新卒へのアジャイルコーチ(ソフトウェア開発手法の一つである「アジャイル開発」を実践するチームにおける指導者)、会社員として受託開発におけるシステムアーキテクト・テストアーキテクト(※)もされています。
※アーキテクト：IT業界用語で大規模なシステムや製品の全体的な設計を行う技術者

また、スクラムのワークショップも数多く実施しており、スクラムの初心者からエキスパート、ユーザー企業から開発企業、立場の異なる様々な人々が集まるカンファレンス「Regional Scrum Gathering Tokyo」でスピーカーも務めた方です。

チームを組む過程を体験して欲しい

「みんなが知ってる”チーム”を教えて欲しいです。近くの人と2分間話してみてください。ではスタート！」


kyon氏の言葉をきっかけにイベントがスタート。参加者はそれぞれ近くの方に声を掛けはじめ、会場が一気に賑やかになっていきます。

「チーム」について各々が話した後、全体の共有タイムで出てきたものがこちらです。

「スポーツのチーム」「プロジェクト」「アーキテクト」「チームが所属する会社そのもの」「政党」「運営委員会」「esports」……

この話し合いにはどのような意味があったのでしょうか。

「私がこれまでしてきた仕事の6割は、”知らない人と突然チームを組む”という状況でした。今日はみなさん初対面の方が多いと思いますので、同じように”チームを即座に組む”過程を体験してもらいたいと思います」

とKyonさん。

「私を先頭にして、”チームでの作業が好きな人”の順番に並んでください」と続けます。

全員一列に並んだあと、1～6の数字を順に点呼の形で言うように指示が。同じ数字を言った参加者同士で組み、6チームが出来上がりました。

スクラムの由来・流れとは

各チームでひとり30秒の自己紹介（名前・来た理由）をし終えると、kyonさんから「スクラム」についての講義が始まりました。

「なぜスクラムというものが生まれたのかというと。

90年代に、”初めてのこと”や”全貌がよくわかってないこと”をやるときには、チームワークを大切にするとうまくいくことが多いかも、と気づいた人たちがいたんです。

そしてこういうルールがあるとうまくいくぞ、とルールを集めてできたものが、2000年初期に”スクラム”として登場したんです」（kyon氏）


スクラムの流れについて具体的にまとめられたスライドがこちらです↓

kyon氏のスライドより(p11 「スクラムの流れ」)

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
スクラムの流れ

• やることに順番をつける

まずは自分たちが「やろうとしていること」に順番をつけます。

どれも「同じくらい大切」だとして”差”をつけないのはNG。
完全に順番が付いている状態に※。

※”1個”の定義については、ユーザーに届くかどうか、ユーザーに対して変化が起こせるか、という視点で考える。

変化の大きさはできれば小さい方がいい。

• やることを見積もる

どれくらいの大きさにする？どれくらいの時間がかかる？などを決める。

• 1個やって、完成したら次をやる

1個ずつ、決めた順番にやって、完成してから次をやる。同時に複数動かさない。

※もしチームの人数と仮説検証のタスクの数が合わない場合は、最悪２個動かすという選択もあるかもしれないが、原則は1個。

• できたものを、大丈夫そうかちゃんと見てみる

　”できたもの”そのものについてのふりかえり。

• やり方（作るとき、チームワークしているとき）をもっと上手にする方法を考える

　”取り組み方”についてのふりかえり。

これらをワンセットとして一通り実行してから次にやることに着手し、また見積→1個ずつやって→振り返る

というサイクルをどんどん繰り返す。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

これがスクラムの基本的な流れとのこと。

「スクラムの基本となるScrumGuideというペーパーがあります。

そこでは、このワンセットの期間が１週間～４週間と定義されています。ちなみに一番多いのは１週間です。

今の流れをスクラムの用語に落とすとこういう図式になります。」（kyon氏）

kyon氏のスライドより(p12 「スクラムについて」)

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

・ProductBacklog

　これは１週間分ではなく、自分たちが今知っている見えている範囲、将来こうしたいというもの全て。

　特に今すぐやらなければならないものほど詳細に書いて、半年後やるかどうかわからないものは粗くていい。

　そして順番を決める。

・Sprint

　１週間～４週間と決めた期間のこと。

・やることに順番をつける＝SprintPlanning

　このSprint（1週間～4週間）分のプランニング。

　今回のSprint分のやることを決めて、順番をつける。

　これをスクラムのチーム全員（＝ ScrumTeam）でやる。

・やることを見積もる＝SprintBacklog

　そして詳細に見積もる。つまりSprint（1週間～4週間）にやることリスト。

・1個やって、完成したら次をやる＝Sprint

　実際にものを作る。仮説検証をしていく。

　　※その中で、DairyStandUp ：

　　　毎日（Sprintの期間終わってからではなく、本当に毎日）行う。

　　　ゴールに向かって今何ができているか、何が障害になっているのかを踏まえ、再計画を考えるきっかけを持つことを実施。

・できたものを、大丈夫そうかちゃんと見てみる＝SprintReview

　Sprintが終わったら、SprintReview。

　できたものを評価。よかったことダメだったことの確認。

　その内のよかったものだけが、Potentially Shippable Productとしていつかはリリースできるものになる、もしくはよかったものを積み重ねて製品としてリリースできるものとなる。

・やり方（作るとき、チームワークしているとき）をもっと上手にする方法を考える＝Sprint Retrospective

　”進め方”のふりかえりを実施する。 

その後またSprintPlanningに戻り繰り返すというのが始まる。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

というのがスクラムの用語に落とした流れである、と。

本日のメインイベント「ワークショップ」

「では、何をやるか発表しましょう！」というkyon氏の言葉とともにスライドに映し出されたのは。

「紙ひこうきを飛ばしましょう！

　たくさん紙ひこうきを飛ばしたチームが優勝です！」（kyon氏）

進め方は下記ルールをもとに、

計画1分→実行3分→ふりかえり1分の計5分。を4セット繰り返す。

というシンプルな内容ですが、このルールがなかなか曲者です。

Kyon氏はルールについてひとしきり説明し「ルールはこれだけ！」「これ以外のルールは自由です！」と締めくくりましたが、「ひこうきの定義ってありますか？」や、「折り目をつけてから開くのはありですか？」「切る人に制約はありますか？」など矢継ぎ早に質問が飛んでいきます。

質問に対してkyon氏は丁寧に回答をしてくれるものの、やったことがないお題なので全貌はつかめないまま、早速1セット目がスタート！

各チーム一斉に計画の相談が始まります。

しかし、制限時間は1分。本当にあっという間に終了時間を迎えます。

kyon氏が各チームの見積もった機数を確認している間もチーム内では相談が続いています（笑）

続いて実行の3分を終えてみると、数機飛ばせたチームと1機も飛ばせてないチームとで半々。

ふりかえりの1分ののち2セット目へ。とあっという間に進んでいきます。

2セット目を終えると全チームが1セット目よりも飛ばせた数が増えています。

そして3セット目。

「今度はルールを一つだけ変更していいです。」という特別ルールが出現。

各チームで変更するルールを協議し、改めて3セット目のスタートです。

ネックだったルールを一つなくすことで飛躍的に数を伸ばしたチームがいくつか現れてきます。

そして迎えた最終4セット目。

なんと先ほどの特別ルールはなくなってしまい、参加者たちは戸惑いつつも最終セットに突入です。

ルールが元に戻ったことで3セット目よりも数が少なくなったチームもちらほら。しかし、トータル飛ばせた数が一番多いチームが優勝！ということで、優勝チームは主催のなごのキャンパスからお菓子の贈呈！

そして、このワークで気づいた大切なことをチームで話し合い、全員でシェアしていきます。

・課題を全員で共有できたこと

・改善アイディアをどんどん採用して実行した

・見積を適切に設定したこと

・状況把握と声かけ

・ふりかえりの時間

・検証

・発想力の必要性

・ビジョン、目標の設定

・役割分担の明確化

・コミュニケーションの慣れと、スキル（折ること）の慣れ

これらを見ているとその多くが、スクラムの仕組みで発生していることに気づきます。

計画：見積、ビジョン、目標、役割分担の設定

実行：検証

ふりかえり：課題共有、改善アイディア採用

繰り返す：コミュニケーションの慣れと、スキル（折ること）の慣れ

スクラムというフレームワーク、とにかくやってみると発見がありそう、そんな期待感を抱きます。

ScrumGuideの基本用語と質疑応答

最後のプログラムは、Scrum Guideに記載されている基本用語について、kyon氏による補足説明及び質疑応答です。

ここでも、kyon氏の説明をまとめたのがこちら。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

スクラム（名詞）

　「複雑で変化の激しい問題に対応するためのフレームワークであり、可能な限り価値の高いプロダクトを生産的かつ創造的に届けるためのものである。」

　決してシステム開発のためだけのものではなく、旅客機メーカー、自動車メーカーなどの製造業でも取り入れられている。

スクラムとは下記のようなもの

・軽量

　Scrum Guide自体が18pという非常にライトな冊子にまとまっている。

・理解が容易

　前半に説明してもらった通り、やり方が明確。

・習得は困難

　これについてはkyon氏は以下のように指摘していた。

　「社会人には確かに困難だけれど、学生たちは容易に習得して行く。社会人については”習得”が困難というよりも、”変化”が困難である。」と。

３本柱

下記の3つでスクラムは成り立っている。

・透明性

　情報や自分たちの振る舞いについてオープンに。

・検査　

　Retrospaectiveがまさに検査。

・適応

　どうやって変わっていくか。変化して行くこと。

コアバリュー

上記の３本柱だけでは、スクラムを理解できず実現できない人たちがいたため、2016年にコアバリューが途中で追加された。

この5つのコアバリューが実行されないと３本柱は成立し得ない。

kyon氏のスライドより(p47 )

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

そして、Scrumの基本構成（３つのロール、５つのイベント、３つの成果物）についても一通りkyon氏の説明が終わると、質疑応答タイムに突入です。

たくさん出てきた質問の中でも下記の質問・回答が私の疑問を解消してくれることとなりました。

冒頭でも記載したように今回私が知りたかったのはチームビルディングとスクラムの関係性です。

Q：目標にコミットできない人をどうするのか。

Kyon氏：目標にコミットできない人を導くための手法というものはスクラムにはないです。今日説明したものがスクラムの全てです。目標にコミットしてもらうためには他の手法を用いると良いです。

Q：スクラムをやりにくい会社とは？

Kyon氏：プロダクト自体の向き不向きもありますが、スクラムがやりにくい会社としては変化を嫌う傾向があります。アジャイルは変化を登用することを目的としているので。アジャイルは性善説がベースとなっている考え方（スクラムではもう少し整理したものにはなっているが）のため、性悪説で考えがちな組織ではマッチしづらいです。例えばもしスクラムに性悪説に対する手法を追加しようとするならば、18pだったものが300pなど一気にボリュームが増えてスクラム本来の良さを失ってしまうので。

まとめ

・スクラムとは、目標・問題に対して高速で変化を起こすための活動促進に主眼を置いた手法と言える。”チームビルディング”はルールに従って行動する人たちのコミュニケーションの結果によって起きるものであって、”チームビルディング”自体をどうこうしようと考えたものではない。（スクラムに臨むための条件は定義しているものの、その状態にするための手段の定義まではない。）

・コミュニケーションに主眼を置いた”チームビルディング”も多々あり、これらのフレームワークもそのチームの目標達成を目指しているので、スクラム同様目指すゴールは同じである。人と人との関係性に重きを置くのか、そこで扱われるモノゴトに重きを置くのか、という違い。そして、目指すゴールは同じなので両方取り入れたら最強だろう。

・「やってみないと”わからないこと”はわからない」　ついリスクヘッジをしたくなるが、いろいろ考えすぎると時間を浪費してしまうデメリットが。リスクヘッジは考える時間を決めて、それを超えたらまずは実行するというのが目標達成への最速の道である、ということを体感。

スクラムはシンプル故に適用できる範囲も広い印象を持ちました。ただし導入には前提条件があるので、その準備・整え方であったり、様々な適応事例についてシェアできる機会が引き続きなごのキャンパスであるといいなぁという妄想をしつつレポートを締めくくります。