こんにちはっ。フィードフォース技術チームの女子力担当、いのうえです！

去る 10月22日 、『エッセンシャルスクラム』『Team Geek』の訳者である角征典さん（ワイクル株式会社）主催の「 LEGO(R)ではじめるスクラム入門」に参加してきましたので、その参加レポートをお届けします！

参加動機について

まず、私をとりまく環境について軽くご紹介します。
- 自社プロダクトチームの開発リーダー（私）
- プロダクトチームの構成は、

• 営業 1名（兼プロダクトオーナー）

• ディレクター 2名（うち1名は他プロダクト兼任）

• エンジニア 5名（私含む）

  • 社内に一人、認定スクラムマスターが在籍している

• 困ったときにはアドバイスをもらえる

• 複数チームをサポートしているため、自分のところばかり支援を受けるわけにもいかない

  • うまく取り入れられているスクラムのプラクティスもあれば、まだまだなものもある

• デイリースクラム、スプリントレビュー、スプリントレトロスペクティブなどは比較的うまくできている

• 各種ロールに基づいた開発推進や、プロダクトオーナーの確立などに課題あり

...というような環境なのですが、私もスクラムマスターに、とまではいかないまでも、支援を受けるばかりではなく、もう少し「支援する側」の知識や技術を身につけ、よりスムーズな開発に繋がれば、という思いが日頃からありました。

そんな中、このレゴスクラム研修というものがあることを知り、またスクラムマスターからも「とても良いらしいよ！」という後押しももらったため、今回の参加となりました！٩(๑❛ᴗ❛๑)۶

弊社ではこういったセミナー参加も応援してくれる制度が整っているので参加がしやすい、というのもあります♪　今回のでいくと開始時間は日中の13:30からだったのですがその間の勤怠は普通に出勤扱いですし、セミナー費用も半額補助が出ます！（今回のように、いちまんえんを超えるセミナーの場合は本当に助かります）

体験してきた内容について

おおまかな流れは下記のような形でした。

1. チーム分け
2. 座学＆プラクティス
3. レゴスクラム
4. クロージング

続いて、それぞれでどんなことをやったか、少し詳し目に書いてみようと思います。

1. チーム分け

この日の参加者は、全部で10名。これで２チーム作りたい、とのことで、「 では、”アジャイル開発に詳しい順”に、一列に並んで見てください 」と、角さん。

「 単にチーム分けのためだけなので厳密じゃなくてもいいです 」「 話し合いながら調整してくださいー 」とのことで、お互い初対面同士でまだおっかなびっくりながらも、「アジャイルサムライ読みました？」「何年くらいアジャイル開発を経験されてます？」なんてコミュニケーションを取りながら、私達は一列に。

並び終わったら、先頭から順に「 いち！ 」「 に！ 」「 いち！ 」「 に！ 」...と点呼をしていって、「チーム１」「チーム２」に別れる、ただそれだけなのですが、チーム分けと同時に ”ツカミ” としてのコミュニケーションが取れるこの方法は、なかなかイイなと思いました(^^)。

2. 座学＆プラクティス

その後、各々着席した状態で1時間ほど、角さんよりスライドを用いての座学をして頂きました。

スライドの流れは以下の様なかんじ。

a. 自己紹介
b. スクラムの基礎知識
c. スクラムとは
d. プラクティス１「最高に美味しい焼きそばを作る手順」
e. ２つのフィードバックループ
f. リレー方式からラグビーへ
g. 「自分たちで考える」組織づくり
h. スクラムの全体像
i. プラクティス２「ユーザーストーリーの練習」
j. プラクティス３「プランニングポーカーの練習」
k. ソフトウェアカンバン

なるほど、という気付きがあったセクションについて、それぞれもう少し詳しく掘り下げてみます。

c. スクラムとは

「複雑で変化の激しい問題に対応するためのフレームワーク」が、スクラムである、として、
- 「複雑」には、実は2種類ある
- それは、「全体＝Σ部分」な複雑さ（complecated）と、「全体≠Σ部分」な複雑さ（complex）である
- 「complex」じゃない問題にアジャイル・スクラムを適用しても、却って失敗してしまうケースが多い

というお話には、はっとさせられました。

なんでもかんでもアジャイル！スクラム！ではなく、まずは「自分たちのプロジェクトの"複雑さ"の性質」について考える必要があるんだな、という新たな視点を得られました。

d. プラクティス１「最高に美味しい焼きそばを作る手順」

このプラクティスでは、掲題のテーマについてまず個人で2分考え、その後チームで3分話し合いました。

脳みそをフル回転させて考えた結果、私の出したアイデアは「 まず、1日絶食する 」でしたヾ(´∀｀)ﾉｷｬｯｷｬ

他のチームメンバーも、「 最高の料理人を探す 」とか「 家族で買い物から一緒にやる 」とか、ユニークな意見がたくさん！同じお題でもいろんな意見・考えがでて面白いなー、と思っていたのですが...

角さん曰く、「たいていの人は一直線で考えちゃうけど、大事なのは フィードバックループ があること。作った焼きそばを食べてみて、最高に美味しくなかったら、 その反省を元にまた準備からやり直す、ということが大事 ！」 ...これと似たような感情を日頃の開発で幾度と無く感じているはずなのに、いやはやお恥ずかしい。。もちろんこれは、プロダクト開発でも言えること、ですもんね。

f. リレー方式からラグビーへ

こちらのセクションでは、
- 日本（ホンダ、キヤノン）などの、「ひとつのフェーズが終わっても、細く長くプロジェクトに関わっていくスタイル」が、フェーズ間での伝達漏れが起きにくいとして注目されている
- 従来までのスタイルが「リレー形式」だったのに対し、このスタイルは「ラグビー形式」に近い

…と仰っておられたのが印象的でした。

そのようなラグビー形式のチームにおいて大事なのが、「 不安的な状態を作り出す 」ことと「 自己組織化 」の2つ、だそうです。

その2点の詳細は、下記の通りです。

• 「不安定な状態を作り出す」
  • マネージャーは、チャレンジングな課題と大きな自由度を、スクラムチームに対して与える
  • スクラムチームとは、「プロダクトオーナー」「開発チーム」「スクラムマスター」全員
  • ホンダでいうところの「2階に上げて、ハシゴを外す」
  • これにより自立が促される
• 「自己組織化」
  • 自己組織化に必要な 3つの要素
  • 自立：自分たちで考えて行動する
  • 成長：自分たちに制限をつけない
  • 交流：みんなで一緒に大部屋で働く
    • 今や「オオベヤ」は世界でも通じる言葉らしい！
  • 複雑な問題にチームで立ち向かっていくのに、必要不可欠

g. 「自分たちで考える」組織づくり

そのような組織に必要な役割として、まずその重要性が述べられていたのが、「プロダクトオーナー」でした。

プロダクトオーナーに求められる役割は、主に下記のようなものです。
- 「何を作るか」の責任者！ビジョンや原要求の作成、プロダクトの検収、リリースの判断。
- 技術的な知識は必ずしも必要ない！（開発チームと協力する）
- でも、命令してはいけない！（＝不安定な状態を作り出す、ために）
- 「ステークホルダー」と「スクラムチーム」との間に立つ、「門番」！

また同時に、「顧客定義価値への理解を深める」この重要性にも触れられました。

価値とは、「顧客が定義するもの」 。我々が定義するのではない。また、 価値とは「ケチャップ」のようなものである 、とも。つまり、たくさんあれば良い、ってものでもないし、あげすぎても拒否されるだけだ、と。

そして、スクラムチームを成り立たせるために必要不可欠なものとして、下記のような「見える化」を挙げられました。
- リーンキャンバス（ビジョンの一覧）
- プロダクトバックログ（要求の一覧）
- ソフトウェアカンバン（作業の一覧）

「自分たちで考える組織」づくりをする、ということの第一歩として、これらが「見える化」できるレベルにまでチームとして取り組めている必要があるのだな、と思いました。

h. スクラムの全体像

続いて、「スクラムの全体像」について、図を交えたスライドを用いて講義をして頂きました。

リストアップすると、下記のようなものになります。
- プロダクトビジョン
- リーンキャンバスとかデザインボックスとか
- プロジェクト憲章
- スクラムガイドの確認とかインセプションデッキの作成とか
- プロダクトバックログ
- 原要求を一覧にしたもの
- 一個一個のアイテムは「プロダクトバックログアイテム」という
- ユーザーストーリーを使うことが多い
- 「（役割や立場）として、（機能や性能）が欲しい。それは（理由や目的）のためだ」
- スプリントプランニング -> スプリントゴールが決まる
- スプリント＝ある短い期間（1〜4週間）
- スプリントゴール＝その期間での達成目標
- スプリントゴールを実行可能なタスクに分割 -> スプリントバックログ
- スプリントを繰り返す
- 24時間ごと（毎日）にデイリースクラムを実施
- 各スプリントを終えるごとに、スプリントレビュー・スプリントレトロスペクティブを実施
- スプリントレビュー＝プロダクトのふりかえり・フィードバックループ
- スプリントレトロスペクティブ＝プロセスのふりかえり・フィードバックループ
- これらの結果として、リリース判断可能なプロダクトが出来上がる

i. プラクティス２「ユーザーストーリーの練習」

ここでは、このあとのレゴスクラムのための準備も兼ねて、チーム内で「家族の役割」を決めました。「役割の属性」（職業とか年齢とか趣味とか）も自由に考える、というものです。

そして、ここで決めた役割・属性になりきって、家族で新しい街に引っ越すと仮定し、引越し先の街に望む施設や建物を書く、という流れです。

私は、おもしろそうだったので「ペット」という役割になってみました...！

波乱の予感。

j. プラクティス３「プランニングポーカーの練習」

続いて、プランニングポーカーを使った相対見積りの練習、ということで、 とある10の都道府県の人口数の相対的なサイズを、「1」「2」「3」「5」「8」の5種類で見積もる！ というプラクティスを行いました。

弊社では、プランニングポーカーを使ったタスクの見積りを日頃から実施しているので、戸惑わずにはできたかなと思いました(^^)。そして見積り結果についても、カンペキではなかったけど、9割方正解！

やっぱり人は、 絶対見積りよりも相対見積りの方がとくい なんですね〜。（って、アジャイルサムライにも書いてありましたしね！）

3. レゴスクラム

さていよいよメインコンテンツ、レゴスクラムの時間がやってまいりました！

まずは、「レゴスクラム」について。

レゴスクラムとは、 レゴブロックを用いてチームごとに街づくりをし、それを通じて、スクラムのほぼ全ての工程のエッセンスを体験できる 、というもの。私達は、「こんな街を作って欲しい」という「要求」を持っている顧客でもあり、相手チームの「要求」を実現するために結成された開発チームでもある、という設定です。

プロダクトオーナーの選出

レゴスクラムを開始する前に、プロダクトオーナーを選出しました。プロダクトオーナーの主な役割は、以下の３つ。
- チームの意見をまとめ、全ての要求に責任を持つ
- プロダクトバックログを管理する
- 各要件そのものや優先順位など
- 成果物を検収・拒否する

思い描いた理想の街（プロダクト）が出来上がるのが一番なのですが、現実には色々な制約があります。また、ステークホルダーが複数いる場合、その中でさえ矛盾する要求が上がることもあるでしょう。かといって、制約を全て受け入れた結果、プロジェクトが立ち行かなくなったり、全く望んでいないものが出来上がってしまっては元も子もありません。その微妙なバランスの上に立ち、街（プロダクト）が、考えられる最高のものとなるよう責任をもって意思決定をしていくのが、プロダクトオーナーの役割と言えます。

ちなみに私も、今回じゃんけんに負けてこのプロダクトオーナーになってしまいました。 ペット（犬）のプロダクトオーナーの誕生です 。

レゴスクラム、開始！

そしていよいよ、レゴスクラムが開始です。

これ以降行うことは全て、通常の開発においての"ひとつのスプリント内"で行われること、になります。

つまり、これらを繰り返し行なっていくことで、プロジェクトとしてのゴールを目指すことになります。

ちなみに、レゴスクラムでは、「今まで座っていた席から相手チームの席に移動＝立場が変わる（顧客→開発）」、というルールになっています。つまり、席の移動後、目の前には相手の要求が広がっている、という状態になるわけです。

- 席を移動し、相手チームの要望をもとにソフトウェアカンバンを作成する
- 作業開始前に、要求を確認して不安なこと（Problem・夜も眠れない問題）を洗い出す
- 各ストーリーの見積りを、プランニングポーカーを使って見積もる
- 「Problem」にあがったことや、どうしても見積もれないときは、相手チームのプロダクトオーナーに相談し落とし所を探す
- 自席に戻る（顧客の役割に戻る）
- 目の前には、自分たちの要求が相手チームによって見積もられた状態で置かれている状態
- 見積もり数値を参考に、各ストーリーを実現してほしい順番に一列に並び替える（＝プロダクトバックログ）
- 席を移動し、開発の役割になり、スプリントプランニングを実施する
- このスプリントで消化できそうな見積り数値を決定する
- 消化＝「相手チームに検収してもらえる」
- たとえ 99.9% 完成していたとしても、検収してもらえなければそれは消化（完成）したとはいわない
- そしてその予想値ぴったりになるように、プロダクトバックログの上から順番にストーリーを選択する
- 順番を並び替えたい・分割したい場合は、開発チームだけで無断で行わず、相手チームのプロダクトオーナーに相談！
- 選んだストーリーからタスクを考える
- 「庭付き一戸建てが欲しい」なら、「屋根を作るタスク」「壁を作るタスク」「庭を作るタスク」とか。
- 各タスクは付箋に書き出し、カンバンにぺたり。
- そして、自分が担当するタスクにサインアップ！
- 「アサイン」ではない ！

- 街づくりを開始！7分間！
- スプリントを終えたら、スプリントレビューを実施！
- プロダクトバックログの上から順番に、相手チームのプロダクトオーナーにデモをする
- プロダクトオーナーはその結果を見て、完成を認めるか、リジェクトする
- あまりにも思わしくない場合は、プロジェクトを中止にすることもできる
- 追加要求をすることもできる
- 「完成」した見積り数値の合計を、開発チームの「ベロシティ」として記録する
- スプリントレビューを終えたら、続いてスプリントレトロスペクティブ
- 開発チーム内での、プロセスの振り返り（KPT）
- 「○○したのは効率良かったよね！」
- 「もっと××しておけば良かったかも。」
- 「次のスプリントは△△してみよう！」
- 今スプリントのベロシティ等を踏まえ、次スプリントの予想値を決定！
- 次スプリントは、もう少し上手くなっているはず？
- 最後に、リファインメントを行う
- 追加されたストーリーを見積る
- 仕掛り途中のものがあれば、見積りの修正（残り作業はどれくらいあるか？）が必要なはず
- 相手チームのプロダクトオーナーによる、プロダクトバックログの並べ直し（優先順位の変更）が起こることもある！ *次スプリントのスプリントプランニング実施。以下、繰り返し！

スプリントを回しながら思ったこと

それは、「 これ、システム開発と一緒や！つまづくポイントがいっしょや！ 」ということ。それに尽きます。笑

そして、 そのそれぞれのポイントに対して打ち手を用意してくれているのがスクラム 、という感じ。困難なプロジェクトにも、立ち向かう勇気をもらえるようでした。
- 広がりがちな要求に対して、 プロダクトオーナー 。
- やり始めてみてわかった、あんなことこんなこと。に対して、 Problemの事前洗い出し ・ 相対見積り ・ スプリントプランニング 。
- 見通しの立った完了予定を立てることの難しさ、に対して、 ベロシティを元にしたスプリントプランニング 。
- こういうふうな順番でやったほうが効率がいいんだけど、了承とらなアカンひと多すぎるで・・・に対しても、 プロダクトオーナー 。
- 何ヶ月も・何年間も苦労を重ねて作り上げてきたシステムを、最後の最後に鶴の一声で白紙に戻された・・・というようなことに対して、 スプリントレビュー ！
- 多分こういうふうにやり方を変えればうまくいくと思うんだけどなぁ・・・という思いに対して、 スプリントレトロスペクティブ ！ 自分たちのやり方をスプリントごとに振り返ることで、どんどん上手な開発ができるようになる！

あとはやっぱり、顧客と開発を入れ替わり立ち替わりやるので、「 なんでこんなのが出来上がるの！違う、そうじゃない！ 」という気持ちも、「 そんなの出来るわけないでしょ、戦わなきゃ、現実と 」というような気持ちも、ほんの短い時間で同時に味わえますね。笑

プロダクトオーナー、超重要！

あと、今回私は幸運？にもプロダクトオーナーの役割を担当することになったのですが、だからこそ、その役割の重要性についても再認識できました。というのも、仕様（今回だとレゴで作る建物などについての）の詳細や要求の順番変更についての開発チームからの問い合わせに対して、「責任をもって」回答しなければならないからです。

オーナーとしては、その確認全てについて、他の顧客メンバーにも「それでいいよね？」と確認したいのですが、その全てをやっていては、時間的にもキリがないし、プロジェクトも立ち行かなくなってしまいます。時には暴走しがちな顧客側の要求をうまくコントロールし、ある落とし所に集約させるのもまた、プロダクトオーナーの大事な役割なのだと感じました。もちろん、このレゴスクラムでも実際に似たようなことがありました。

「え？壁の色、白？」

「スーパーマーケットなので、壁の色だけで作り直しまでしてもらう必要はないと判断して、そうお願いしました！」

プロジェクトをいかに効率よく、なおかつ的を外さずに進行させるか 、は、このプロダクトオーナーに掛かっていると言っても過言ではないなと思いました。

4. クロージング

エキサイティングな時間はあっという間に過ぎ、クロージング。

クロージングでは、角さんが「レゴスクラムでいいたいこと」として、「 Complex な問題はみんなで(楽しく)協力するしかない!! 」と仰っておられました。レゴスクラムを終えた自分には、それはとても説得力のあるお言葉でした。

そして、デイリースクラムは超重要、とも。弊社・私のチームでもデイリースクラムは毎日実施しているのですが、少し「エンジニアからの進捗報告の場」でしかなくなってきている感じもある、今日この頃でしたので、これからはもう少し、 それぞれの役割からの意義ある情報交換の場 に昇華していきたいなー、と思いました。

最後に、受講してみての感想

冒頭でも記述しました通り、今回はエンジニアのリーダーである私が参加したのですが、このレゴスクラム、エンジニアはもちろんのこと、 ディレクターさんにも是非体験してもらいたい な、と強く思いました。というのもやはり、スクラムチームは全ての役割が揃って始めて、「スクラムチーム」だからです。チーム内の一人でも多くの人が「スクラム」という開発手法に対する理解を深めることで、今よりもよりチーム一丸となってプロダクト開発のサイクルを回していけるようになれば、その結果としてより良いプロダクトを生み出して行けるようになれば、と思いました！

おまけ

このレゴスクラムでは、「アンチ認定証」というのを発行してくれるらしいのですが（「アジャイルに認定証はいらない。それは過去の証明でしかない。必要なのは将来につながる 改善マインド だ。 by Jim Coplien」という考えに基づいて）、今回それを頂けないかをダメ元で聞いてみたところ、「 持ってきてはいないのですが、ご希望でしたら後日郵送しますよ 」とのことでした！(∩´∀｀)∩ﾜｰｲ

今後、皆さんもレゴスクラムに参加されたときは、聞いてみても良いかもしれません。笑