組織パターンを用いたScrumの微調整

組織パターン (Object Oriented SELECTION)

2013-10-30、コプリエンの研修にレポータ枠として参加しました。がんばってレポートします。

本来は組織パターン (Object Oriented SELECTION)を読んだ人、組織パターンやScrumの好きな人、そしてコプリエンファンの人が参加する研修だと思いますが、どれにも該当しないままでの参加となりました。

会場入り

9:45。6Fにつくと喫煙所に角谷さん(id:kakutani)を発見。朝からついてる感じです。会場に入ると裸足のコプリエンと三人の通訳、TAの皆さんが準備していました。

私が面識があるのは、TAの川口さん(id:wayaguchi)、角谷さん、そして自費で参加している翔泳社の岩切さん(id:IWAKIRI)のみ。研修はテーブルごとに分かれた4-5人のグループで行います。(岩切さんと同じテーブルです)
今回はステルス性能を発揮することにして、さりげなく自己紹介はさけてみました。

開始

進行は組織パターン (Object Oriented SELECTION)の訳者、和智さん(@digitalsoul0124)が担当です。和智さんは司会だけでなくコプリエンの発言の補足や、参加者の質問の補足をしてくれてとても心強いです。

全体の流れは次の通りです。

• パターンと組織パターン小史
• Scrumの短い紹介
• パターンの概要
• パターンで障害を解決する
• パターンランゲージ

演習を交えながら進んでいきます。

最初に「組織パターン」と「Scrum」どっちに興味があるの？みたいな問いがありました。（たぶん）
# 私はどちらもよく知らないのでドキドキしました。

アイスブレイキング

参加者を壁の前に立たせ、コプリエンの指定するソート条件に従って並んでみる遊びです。

• なにかの経験年数 (ほんとになんでもいい。プログラミング年数とか）
• 睡眠時間
• 最後にコードを書いた時刻
• Scrumやってる？

などのソート条件が示されました。並べ替えるために隣の人と話す必要があるので、自己紹介になります。

パターン小史

パターンの歴史について簡単な紹介がありました。ちょっとしたエピソードを踏まえてパターン（コミュニティ）の育ってきた様子を伝えてくれます。
「Buffalo Mountain」というパターンが3番目に悪い名前であるというのを知りました。結局どんなパターンだかわからなかったけど。

「パターンはフォーム」というメモが残ってたんだけど、一体なんだったっけ‥

10分でわかるScrum

TAの川口さんとコプリエンからScrum自体の説明がありました。最近（数年前？）にScrumの内容は更新され、リストが三つになったそうで、以前に公認スクラムマスターになったひとは注意とのことです。

• Product Backlog
• Sprint Backlog
• Impediment List

三つ目のリスト「Impediment List」が追加されたリストです。

Impediment List

今までのProduct Backlog、Sprint Backlogは製品の視点から生まれたリストです。Scrumの仕組みの中でそのアイテムが流れていく様子はよく知られてますよね。

Impediment Listはチームの運営を阻害する障害のリストです。

ScrumにおいてImpediment Listについてはそういった「流れ」まではできていないようで、浮いているように見えました。この辺りからだんだんがまんできなくなってしまって、質問することにしました。研修中、日本語で質問すると通訳の人が英語にしてくれます。通訳さんのせいとは思えないのだけど、基本的に質問と答えが噛み合ないことが多くて楽しいです。

私の質問は「Impediment Listはどのくらい滞在するのか？リストにする必要があるのか？」でした。ふたつのBacklogのように流れが感じ取れないことからくる疑問です。どんな風に解消されるのか、解消されるとしたらリストになるほど障害があるのかについて聞きたかったのです。

「おまえのところの障害リストはいくつになるんだ」
「2,3です」
「100個あったらリストが必要だろう」
「きれいにしてたらそんな風にならないよ！」
「本当？」（会場から。自己紹介しなかったおかげでもらえたコメントだと思う）

私の経験では同時に100個のリストができるような状況は異常だと思います。私たちの場合、解消される問題と発見される問題の数はだいたい釣り合っていて（流量はわりとある）、未解決の問題が100もある状況は想像がつきません。

「Impediment Listの要素もSprint Backlogに混ぜるべきだ。うちならそうしてる」

と言ったらチョコレートをもらえました。このネタだけで一時間くらい喋れる気がしたけど、がまん。

すぐ後でわかるのですが、演習はこのImpediment Listを中心に行われました。

演習

演習は主に二つあったように思います。ひとつはImpediment List関連、もうひとつはScrumを構成するパターンのおさらいです。

前者の流れは以下の通り。

• 自分のチームのImpediment Listをあげる。
• それをみんなで分類する ← どんな意味があったんだろう
• 自分のチームのパターンを紹介する
• Impediment Listをパターンで解決してみる

演習の流れを知らずに手を動かすので、フラストレーションがたまります。たとえば「分類しましょう」と言われてもなんのためにやるのかわからず、分類の指針も立てにくいです。言われたことそのままやるのはダメじゃん、と普段行動しているので「ただ言われた通りにやってください」っていうのは難しいです。でも演習の流れを想像して補いながら参加しました。

コプリエンからは参加者の作業について（基本的に）肯定してくれます。そのため、なんとなく自信は残るんじゃないかなあと思いました。

Impediment Listの多くは掘り下げが足りないか、抽象化しすぎたものが多かったように思いました。具体的な不満をきれいな言葉で抽象化してる感じ。その問題が解決されると具体的にどうなるのか、を考えると良いんじゃないかなあ。パターン関係ないけど。

もう一つの演習は、Scrumを構成するパターンを依存関係順にチェックするものでした。チェックがつけばScrumをやっていると言えるそうです。ほぼ全部チェックついたけど、うちはScrumじゃないんだよなー...

パターンとはなにか関係

パターンとはなにか説明があったんだけど正直あんまり腑に落ちなかったです。
でも会場からの質問のおかげでちょっとよい説明を引き出せました。

研修のテキストに「1つのパターンが、いちどに解決する問題は一つだけ」という誤訳があり「一度に一つずつ適用する」が正しかったのですが、これを起点に「一つのパターンが複数の問題を解決するよ、それは...」といった具合にコプリエンが暴走してくれました。

彼の話を全部受け止められた自信はないのですが、がんばって説明します。

まずたくさんのいろいろな向きのフォースが存在する空間があるモデルを考えます。
# ホワイトボード全体にいろんな向きの矢印（フォース）を描いてくれました。だれかホワイトボードの写真残ってない？

つぎにいくつかの矢印を「対象の問題」として選び囲み「それらを解決する、調和させるのがパターンだ！一度に複数の問題が解決されるんだよ！」っぽいことを話してました。

うぉー。なにを問題と思うかも自分たちに任されてる！パターンはきれいに並んでるわけじゃなく重なり合ってる！この説明はいいなあ . . . あ、あれ？
今思うと変だな。あのときは腑に落ちたんだけど...。これってパターンじゃなくてコンテキストとフォース、解決策ですよね。それのカタログがパターンなんだろうか...。

問題すら自分たちで選べるっていうのは自分たちのチームの雰囲気と合ってていいなあと思いました。でもカタログの方はあんまりぐっとこないんですよね...

パターンは形式知にすぎず、実際に手を動かす時には暗黙知になっている必要があると思うんだよな。自分たちのことをずっと考えていたけど、形式知にされたものは少ないけど、暗黙知になってる方の「コンテキストとフォース、解決策」の組はたくさん持ってるみたい。その瞬間瞬間でどのコンテキストにマッチするのかを高速に検索できる仕組みは、きっと製本された一覧表ではなく、脳内のインデックスにある気がする。

そういえば「パターンはコミュニティから生まれるので、一人で書いたものは一人のアイデアに過ぎない」って話もありましたが、これはコンテキストとフォース、解決策よりもカタログとしての意味があるからなんでしょうか。というか何人になったらパターンなんだろう。一人も数人も大差ないぞ。

それから、パターンランゲージはもう全然わかんなかったです。とほほ。

クロージング

角谷さんが「Ruby Guy」って紹介されてて悔しかったです。

懇親会

川口さんや角谷さんが「こいつはXPを十数年やってる。今のチームのイテレーションは500だぜ」みたいなことをコプリエンに教えたのでなんかからまれました。コプリエンはXPのことをよく知らないみたいでした。

「Scrumやれよ」って言われたけど、もちろんやんないよー。

あわせてよみたい

リーン本ください。