【研修レポート】LEGOで学ぶ!?　変化に強い「スクラムチーム」を目指せ！

こんにちは。Webディレクターの小川です。

冒頭からレゴで遊んでいる楽しげな写真が登場しましたが、実はれっきとした研修風景の一部です。先日、インフォバーンでは、Webディレクターなど数十名を対象に、「スクラム研修」を実施しました。今回はその研修の模様と、研修を通して気づいた点などを紹介したいと思います。

日頃の課題から考える。「変化に強いチームづくり」が必要な理由

「日頃のディレクター業務のなかで困っていることは何ですか？」

研修はこんな質問からスタート。参加メンバーで意見を出し合っていくと、程度の差はありながらも、以下のようなことが共通課題として見えてきました。

（他にもありましたが、なんだか胸が苦しくなってきたので省略いたします……）

私自身を含め、いずれもWebディレクターにとって「あるある」で、皆激しくうなづいていました。しかし研修講師の方いわく、こうした課題にスクラムの考え方を適用すれば、解決につなげやすくなるとのこと。つまり、スクラムとは「変化に強いチームを作り、継続させていくためのフレームワーク」と言えるのだそうです。

LEGOでスクラムチームの運用を体感する

座学を終えると、その内容に基づく形で演習を行います。いよいよ冒頭のLEGOが登場。演習は、具体的に以下のようなルールで進められました。

この演習を通して、チームを回すうえで重要だと感じたことがいくつかありました。それを大きく4点にまとめました。

気づき①：物理的な距離の近さが、コミュニケーションを密にする

まずやってみて重要と感じたのが、メンバー間の「距離の近さ」。「開発者」「スクラムマスター」「プロダクトオーナー」が同じテーブルで、相談しながら進めることで、判断がスピーディーに行われるため、「何をすればいいの…」と手が止まってしまう状態にはほとんどなりませんでした。

実際の業務に置き換えてみると、たとえば「関係者と個別に打ち合わせをやって、そこで出た確認事項を別の人にメールで……」などの調整作業によって、実施までにとても時間がかかります。関係者を集めて、同時に決めることができれば、手を動かす時間も格段に取りやすくなると感じました。

もちろん、普段からそのような環境を整えることは（とくにクライアントもプロジェクトメンバーの一員である以上）難しいかもしれませんが、たとえば

・遠隔でもバーチャルなコミュニケーション環境を整える
・対面が難しくとも、電話やメールなどでこまめに連絡をとる
・定例会を実施し、定期的に顔を合わせるようにする

などで、ある程度カバーできそうです。

気づき②：「見積り」は素早く、正確に

「見積り」と聞くと、「お金」の話を思い浮かべてしまいがちですが、スクラムではそれを試算するための「作業量」をできるだけ素早く正確に見積もれるかを重視します。

たとえば今回の演習では、主に以下の2点にフォーカスしました。

・開発チームのキャパシティ
→どれくらいの期間でどれくらいのものを作成できるのか
・作業量と難易度の洗い出し
→現状の開発チームのキャパで、どれくらいの時間がかかりそうか

これらは今回の演習に限らず、普段の業務を組み立てていくうえでも非常に重要です。ただ、ついつい他の仕事に忙殺され、気づいたら疎かになってしまいがち。個人的にも、スケジュール通りに進まなかったり、タスクが計画通りに終わらなかったりといった経験があり、見積もりの精度が低かった、あるいはそもそも見積もれていなかったなと痛感しました。

また、チームを回していくうえでの稼働把握が目的の場合、まずはスピード重視で数値化を行い、動きながら見積もり作業を繰り返していくことで、徐々に精度を高めていくといったやり方が良さそうです。

気づき③：実施／振り返りを短い期間で反復させる

実際にアクションしたら、それについて振り返ります。スクラムにおいてはその期間が非常に短いのが特徴的。長くとも2週間、必要に応じて毎日などのスパンで振り返りの場を持ちます。

今回の演習では擬似的な体験として、5分間の開発と2分間の振り返りを1セットとして、複数回繰り返しました。振り返りでは、主に以下について確認します。

上記を短い期間で行うことで、チーム内に「今何をやっているのか」「どんな問題があって、どう解決するのか」といった意識が生まれ、「自律的に動く状態」を実感できました。

振り返りを次に活かすことは、PDCAの基本中の基本ですが、これをルール化し運用に乗せていくことで、「数カ月前から同じこと言っているよね……」状態を回避できそうです。

気づき④：「完了」を定義する

これも実際に起きがちですが、完了をきちんと定義しておかないと、作業がずるずると伸びたり、当初予定の作業はとっくに終わっているのに予定外の別の作業をしていたり、ということが発生します。

たとえば、私たちのグループでは、とある建造物（市役所）を作成する計画があったのですが、要件を取り違えていて、開発・修正が二転三転するという事態が発生しました。その際に行ったのは、修正作業を開発の延長線上でなんとなく進めてしまうのではなく、「開発作業」はいったん完了したと定義すること。そして、新たに発生した「修正作業」に必要な作業量と時間を考えながら進めることで、作業量を調整しながら進めることができました。

もちろん要件を取り違えず進めるに越したことはありませんが、実際の業務では要件自体が変化することもしばしば起こりうるため、「完了を定義する」のは非常に有効な考え方だと思いました。

まとめ：自律的な組織運営のためにマインド以外をいかに設計するかが重要

「スクラムチーム」が変化に強い理由として、「自律的な組織として動ける」ことが挙げられます。「自律的」と聞くといかにもマインド面の話になりがちですが、今回の講義やLEGO演習を通して思ったのは、むしろルールやノウハウ、各種フレームワークによって自律性をうまく引き出す方法論がスクラムなのだということ。そうしたチーム運営を設計することも、ディレクターの役割の一つだと思い知らされました。