「LEGOブロックで街づくり」 実体験型スクラム入門をのぞいてみた：理屈より実践で学ぶアジャイルの方法論
LEGOブロックを使った街づくりでアジャイル開発の実践を学ぶ半日のコースを見学してみた。効果のほどは？
「新しい街を作るんだから、当然家も作ってもらえるものと思っていました……」「えっ!? 仕様に書いてありせんよね？」。
「動物園って、何があれば動物園ですか？ 何を作ればいいですか？」「うーん、ゾウがあればいいです」「えっ？ それだけですか？」
依頼側と依頼される側のすれ違い――。開発プロジェクトでビジネス側と開発側の行き違いを経験したことがある人であれば脇の下に嫌な汗をかきそうな会話が次々と飛び出す。
子どもの頃に誰もが遊んだであろうブロックを使って街づくりをする。そんな一風変わった題材で、アジャイル開発の方法論「スクラム」を、体験を通して学ぶというワークショップをのぞいてみた。
十数人がLEGOブロックを使って全工程を体験
ソフトウェアの開発手法としてアジャイル開発が注目を集めている。アジャイルと総称される実践には、さまざまな方法論が含まれるが、チーム開発で最も知られたアジャイル方法論の1つは「スクラム」だ。
このスクラムを学ぶワークショップとしてワイクル株式会社が提供しているのが「LEGOではじめるスクラム入門」（申し込みページ）という半日の入門コース。座学とワークショップの組み合わせだ。講師は同社取締役プログラマで、アジャイルやRuby関連の翻訳で知られる角征典氏と、同様にアジャイル関連の訳書も多い永和システムマネジメントの角谷信太郎氏が務める。毎回、8人から15人程度の参加者を募り、数チームに分かれて「スプリント」と呼ばれるスクラムの開発サイクルを数回まわす。資格認定などがあるワークショップではないが、短時間でスクラムの全工程を体験できるのがウリだという。
開発者でなくても参加できるワークショップ
2013年5月13日に東京・渋谷で行われたスクラム入門には13人の参加者が集まった。現場のエンジニア、リーダーのほか、管理職やディレクター、人事担当者や学生もいるなど、参加者のバックグラウンドはさまざまだ。参加動機もさまざまで、自己紹介の時間には、こんな発言が聞こえてきた。
「今度、組織でスクラムを取り入れようと思っているので勉強に来た」
「スクラムに惚れ込み始めているので、それが本物かどうかを確かめに来た」
「本当は形式ばったことは嫌いで、スクラムですら好きじゃない。本当に好きじゃないのかどうか、確かめたい。あるいは好きじゃない理由を知りたくて参加しました」
自己紹介に続いて1時間ほどの座学が始まった。
角氏はまず、スクラムが生まれてきた背景から説き起こし、「スクラムとは複雑で変化の激しい問題に対応するためのフレームワークである」という定義を紹介した。氏によれば、日本語でいう複雑さには2種類ある。それぞれ英語ではcomplicated、complexに相当する。前者は「入り組んだ」システムのことで、全体を部分に分割することで、1つ1つ把握、分析、対応が可能なもの。後者のcomplexは「複雑」に相当し、全体を分割して考えることが難しく、できるところから探索を始めて、ボトムアップ的、経験主義的に少しずつ解決していくことが求められるような問題を指す言葉という。
complexに相当する複雑なシステムやソフトウェアの開発でこそ、スクラムのようなアジャイル開発が適するという。「スクラムは変化の激しい複雑なものに対応するフレームワーク。complexなものがスクラムの対象。スクラムには批判もあるが、それは『複雑』の種類が違うからだろう。ビジネスの仕組みが必要以上にcomplicatedになっていたり、解くべき問題がカンタンだったりすることが多いのではないか」（角氏）
ゲームで体感する「自己組織化」の意味
スクラムの重要な側面に「自己組織化」がある。ワークショップではまず、これを体感するために、十数人の参加者たちを誕生日の月順に一列に並べ替えるというゲームが行われた。
自己組織化の反対は、誰か1人のリーダーが指揮を取り、指示を出すというものだ。ゲームはまず、このトップダウンのアプローチで行われた。まず参加者の1人がリーダーとなる。次に、このリーダーが一列に並んだ残りの参加者たちに対して、質問をしたり、指示を出したりする。記者が参加した回のリーダーは、エンジニアらしく二分探索のアルゴリズムを適用するかのような凝ったアプローチを取ったものの、結局のところ最後は1人1人に誕生月を確認するほかなく、並べ替え完了までに、ほぼ2分もかかってしまった。
続いて自己組織化に相当するアプローチで同じゲームをやる。今度は誕生「月」ではなく、誕生「日」で並べ替える。ただし、今度は全員が自由に手順を考えて、その場その場で隣り合う人と並び順を入れ替えたり、自ら列の反対へ歩いた行ったりする。すると、相互にコミュニケーションが可能なこともあってか、整列はわずか17秒で終了した。
このゲームは、どういう手順で解決すれば良いか事前に分からない問題の場合にはボトムアップの自己組織化が有効であることを示している、という。スクラムが適しているのも、こうした「解き方の分からない」ような問題に対処するケースだ。角氏が釘を差すのは逆のケース。「手順が決まっている仕事もたくさんある。そういうものは、自分たちで考えるよりも優秀なリーダーが指示を出したほうがうまくいく」という。
スクラムの6つの特徴
自己組織化のほか、スクラムには6つの特徴があるという。
- 不安定な状態を作り出す：これはマネジメントの役割。自由度をチームに与えて任せる。ホンダでは、チームを2階に上げて梯子を外すという表現をしていた。チームは、自分たちで降りることを求められる
- 自己組織化：自分たちで考えて行動する。成長、交流を促す
- 開発フェーズの重複：リレー形式ではなく、ラグビーチームのようにみんなで協調する
- マルチレベル学習：専門領域にとどまらず、各参加者は隣接領域についての知識を深める
- やわらかなマネジメント：失敗を受け入れ、適切なチーム作りを促す
- 学びの共有：組織や業界全体で学んだことを共有する
これらはホンダやキヤノン、エプソンといった成功している日本の会社の特徴を抽出して論文としてまとめたものをソフトウェア開発に適用したものだという。論文とは、1986年にハーバード・ビジネス・レビューに掲載されたもの。筆者は2人の日本人だ。スクラムの起源は「The New New Product Development Game, Hirotaka Takeuchi and Ikujiro Nonaka, 1986」という論文。つまり日本の製造業の試行錯誤のイノベーションの方法論が、1990年代から2000年代にかけて米国のソフトウェア産業で受け入れられたという流れがあるという。
成功した組織の方法論を真似るだけで、成果物や、その生産性が変わるのだろうかという疑問も湧くが、この点について角氏は、「アーキテクチャは組織に従う。組織はアーキテクチャに従う」としたコンウェイの法則（コンウェイ氏が書いた1968年の論文）や、自然物を人工的に再現する「パターン・ランゲージ」という考え方を紹介した。「プロダクト」と「プロセス」と「ピープル」の3つは密接に結び付いていて、抽出したパターンを適用することでソフトウェア開発は改善できるという。
隣チームの要求を、開発チームが実現
座学の後、LEGOブロックによるワークショップが3時間半にわたって行われた。はじめにスクラムの全体像の解説があったが、ここではワークショップの具体的手順と、その様子をかいつまんでレポートする。
13人が4チームに分かれて4つの街を作る。各チーム3、4人といったところ。これはスクラムに適した数で、通常スクラムでは成果物に寄与する開発チームは3〜9人が良いとされているという。数が少なすぎると自己組織化が起こらず、逆に多すぎるとコミュニケーションが難しくなってしまうからだ。
このワークショップのポイントは、依頼、開発の両方を、それぞれの立場で体験できることだ。各チームは要求を出してまとめる「依頼側」と、それを受けて実際に開発をする「開発チーム」の両方の役割を担当するが、開発（ブロックで家や病院を作ること）するのは自分たちがほしいものではなく、隣のチームが要求する街だ。
チームには、それぞれプロダクトオーナーが1人いる。ソフトウェア開発においてプロダクトオーナーは起業家的な存在で、「何がほしいか、何を実現するか」をまとめる役割を担う。プロダクトオーナーは「原要求」と呼ばれる「街づくりのリクエスト」を一覧にした「プロダクトバックログ」を管理する。ワークショップでは、これをホワイトボードに貼りつけた付箋紙で行なっていたが、ここはデジタルツールでもWebサービスでも同じことだ。
原要求のスタイルとして良く使われるのが「ユーザーストーリー」だという。ユーザーストーリーというのは、例えば「父親として、公園がほしい、なぜなら家族で散歩がしたいからだ」といったセンテンスで、実際の利用者、要求、その要求の背後にある理由を、一定のフォーマットに従って書き留めたメモのことだ。
街づくりを依頼するチームは、まずこのユーザーストーリーを思いつく限り出し合い、それを駅、公園、病院、学校、海岸などの単位でグルーピングする。ここで重複や類似をまとめていくことで、街づくりの原要求、つまりユーザーストーリーのリストがまとまってくる。それぞれのユーザーストーリーには「あったら嬉しい度」も数字で書き込む。後に開発の優先順位を、実装難易度や工数とバランスして考えるためだ。ユーザーストーリーのリストであるプロダクトバックログは、1度作成したら終わりではなく、定期的にレビューして順序を入れ替えたりする。
開発サイクルの「スプリント」を実際に回す
ユーザーストーリーが出揃ったら、いよいよ開発だ。
テーブルを取り囲んでいたチームは、それぞれ別のテーブルへ移り、隣チームのバックログに対面する。現実の開発でも恐らくそうであるように、ワークショップの場では、他のグループが作ったユーザーストーリーの意味が分からずに困惑する声や、依頼者の思わぬ発想に笑う声も聞こえてきた。
ワークショップでは、実際の開発現場に似せるために、コミュニケーションのチャンネルは「プロダクトオーナー ←→ 開発チーム」に限定される。もし要求の曖昧なユーザーストーリーがあって開発チームが工数を見積もれないとか、そもそも何が要求なのか分からないということがあれば、プロダクトオーナーを呼んで話を聞くことができる。
「サッカー場って柵は必須ですか？ 広い場所ならゴールネットだけで柵は不要では？ 工数がかかるので、柵なしでもいいですか？」「いや、子どもたちにサッカーを教えたいので柵は大事です」
「犬の散歩は公園じゃなくても近くの海岸でもできますよね？ 砂浜がありますよ。遊具作りは大人の事情で最小にしたいのですが」「いや、子どもたちも遊ぶので遊具が大事なんです！」
「動物園って、何があれば動物園でしょう？ この動物全部は作れません」「うーん、何でしょうね……」「じゃあ、これがないとダメだというのは？」「うーん、ゾウとか……。いや、ゾウがあればいいです！」「えっ？ あ、そうなんですか、了解です」
ゾウ1頭で動物園だと名乗るのは現実味に欠けるが、ブロック工作として十分な見栄え、というのがプロダクトオーナーの判断らしかった。
プロダクトオーナーとのこうした対話を通して、開発チームは徐々にユーザーストーリーを実際の実装タスクに落としこんでいく。ユーザーストーリーが書かれた付箋紙を、開発サイクルの1単位である「スプリント」へ移して当てはめていく。このとき、作業量や具体的な作業を考えながらチームメンバーに役割を割り振っていく。
LEGOブロックを使ったワークショップでは、7分間が1回のスプリントだ。各開発者は自分が担当するタスクを頭から実装していく。この時、自分の担当タスクが全て完了したからといってボンヤリするのではなく、時間が余ったら隣の人を手伝う、あるいは次のスプリントで実装予定のものを繰り上げて取り組むのが重要だという。目的は上から順に全てのストーリーをチームとして完了することだからだ。
工数の見積もりは「プラニング・ポーカー」で
「3階建てのビルを建てる工数が3としたら、10階建てを建てる工数はどのぐらいになると思いますか？」
ワークショップの一部として行われた上記の質問に対する答えは、かなりばらついた。
「基礎工事が全体の工数の大部分を占めるはず。だから3階建てと10階建てはさほど工数が変わらないので工数を5とした」
「階が増えるにつれてリニアに工数が上がるわけではない。高くなれば構造自体が変わるし困難が増すだろう。だから13とした」
これはある意味で真逆の見積もりだが、両方とも説得力がある。このように、開発チームでそれぞれの経験や知識を持ち寄って、見積もりの精度を高めようというのが「プラニング・ポーカー」と呼ばれるツールであり方法論だ。
プラニング・ポーカーはトランプのカードのようなもので、「1、3、5、8、13」などと書かれたカードを各開発者が持つ。数字は相対的な工数を示してあって、それが1時間なのか1日なのかはプロジェクトやチーム次第だ。このカードを開発チーム全員が持ち、個々のタスクに対して見積もりをした数値を、一斉にテーブルの上に出す。食い違いがなければ、それをそのまま見積もりとして採用し、もし大きな違いがあれば、それぞれの見積りの理由を述べて、再度同じプロセスを繰り返す。
ソフトウェア開発では、特定のライブラリや機能の存在を知っているとか、使ったことがある人と、そうでない人との間で見積もりが大きく違ってくることはあり得る。こうしたケースでは、話し合いによって認識の差が埋まり、精度が高くなるだろう。それがプラニング・ポーカーのポイントという。慣れてくれば、実際にカードを使うのではなく、指の本数で工数を示す、ジャンケンのようなやり方もありだそうだ。
素材集めの方法で自己組織化
LEGOブロックをソフトウェア開発の素材に使う狙いは、誰もが経験したことがあって、誰もがエキスパートではないという、ほどよい難しさだからだという。実際、家や公園を作れと言われて手が止まる人はいなかったが、屋根の形状やドアの開閉の有無など、実装者が決めなければならないことは意外に多い。素材の調達可能性や、そもそも素材の形状から決まってくる実現可能な屋根というのがどういうものであるのかといった、それなりに頭を使う課題が次々と出てくるのだった。
開発チームを見ていると、自己組織化を思わせる動きも出てくる。スプリントを振り返る4分間のレビュー時には、意外な場所で手戻りが発生していたことを認識し合ったり、うまく行った方法論を共有するという情報交換が行われた。
例えば、赤い屋根を作りつつある開発者に対して、ほかの人が「同じようなパーツを集めてきましょう」と申し出る。そして素材集めの上手な人が現れる。「あと必要なのは3のやつ？ 4のやつ？ 良く見ると同じ4でも高さが2種類あるけど、どっちがいいですか？」「4のやつって、2かける4？」
ブロックの呼び方が自明ではないために、コミュニケーションの失敗が起こる。
「そうだ、プロトコルを決めよう」。エンジニアらしく、ブロックの縦、横、高さを、どういう順で数字で呼ぶかを統一しようという動きが、あるチーム内に現れた。実際にはその後、さほどプロトコルは活かされなかったようだが、一筋縄で把握できない素材群と、まだ見ぬ完成形の間で起こった多くの試行錯誤の1つには違いなく、こうした気付きは自己組織化の一例と言えるのかもしれない。
デモで発覚するコミュニケーションの行き違いも
実際のスクラムによるソフトウェア開発では、1回のスプリントは1週間から4週間とするのが一般的。「1つの理由はリズムを生むため。どのぐらいの期間でどのくらいできるかという感覚をつかむことができる。もう1つの理由はビジネスカレンダーとの兼ね合い」（角氏）
スプリントに続いてワークショップでは成果物を依頼者に見せるデモを行った。スクラムでは、成果物とは目に見えるもので、リリース判断が可能なプロダクトでなければならないという。いくらコード行数を積み重ねもダメで、LEGOでいえば家の柱だけを作るのはダメということだ。
実際のデモでは、期待はずれのデキや、注文と違う完成形に思わずプロダクトーナーが沈黙して周囲が笑い出すケースもあれば、注文以上の成果物に満足するプロダクトオーナーの姿も見られた。たかがブロック遊びと言えばそれまでだが、成果物を出す側と見る側には意外なほどの緊張感と遊び心が感じられるのだ。
「えっ、家は作っていただけてないんですか？ 新しい街を作るんだから、当然家も作ってもらえるものと思っていました……」「えっ!?」
「おっ、この公園、いい感じですね」「はい、結構鉄棒なんかも頑張りました！ デートのための公園でもあるので花壇も作っておきました。これはサービスです！」
デモを見たプロダクトオーナーが成果物を気に入り、リリース可能だと判断したら、そのユーザーストーリーは完結する。例えば、ネット上のサービスで言えば新機能を一般公開とするべくゴーサインを出すことに相当する。
完結したユーザーストーリーには、見積もりの数値が書かれている。これを合計すれば、そのスプリント内で完了したタスクの分量をざっくりつかむことができる。これがスクラムで言う「ベロシティ」（Velocity：速度）で、このチームごとのベロシティをもとに、おおよその実装スピードと一定期間内で完了可能なタスク量を把握しながらビジネス判断が行えるのがスクラムの特徴だ。
3回のスプリントで疑似体験、その効果と感想は？
午後の半日を使い、「座学＋ワークショップ」で学ぶスクラム入門。参加者たちは、合計3回のスプリントを行い、和気あいあいと街づくりを楽しんでいたようだ。終了後の参加者たちからは、「短時間で改善を重ねるスクラムがイメージできた」「目的が明確なので自然とチームが学習して成長していった。それを体験できたのは大きかった」「作業中よりも見積もりのときのほうが意見の食い違いが起こりがちという気付きがあった」「職場で実践したい」「これまで理解できていなかったことが体験を通して納得できた」「顧客側が体験できたのが新鮮だった」といったコメントが寄せられた。
すでに書いたようにスクラムのスプリントは短くても1回が1週間という単位だ。これを不慣れなままに現実の開発現場の導入して、試しに回してみるというのはなかなか難しいだろう。また書籍を読んで理解した方法論を実践に投入するのは躊躇するかもしれない。LEGOブロックを使った半日の体験コースは、作業こそブロック作りだが、エッセンスとしてはスクラムによるソフトウェア作りの縮図と言える雰囲気が感じられた。こうしたハンズオンのセミナーが増えてくれば、アジャイル開発の普及に弾みが付くのかもしれない。
Copyright © ITmedia, Inc. All Rights Reserved.