「アジャイルレトロスペクティブズ」書評 -- 社員食堂配膳モデルからヴァイキング食べ放題モデルへ

仕事というものを、社員食堂の日替わり定食のように、ひとつの同じメニューが全員に配膳されるようなイメージでとらえている人が多い。これを、ヴァイキングのように、テーブルに次々と並べられていく作業を、それぞれが食べたい所から好きなように食べていくモデルに変えていくことが必要だと思う。

多様化する社会にこれから入っていく人が、自分の仕事を選択する場合にもこのイメージが有効だと思うが、ソフトウエア開発という職種では、その内部においても、仕事がヴァイキングのモデルのように進むようになりつつある。一つのシステムを開発する為に必要なスキルは、非常に多様なものになっていて、メンバーの持つスキルが分散してそれぞれが得意分野に対応していくことが必要になっている。

定食を残さず食べるには、好き嫌いが無いことが仕事に就く条件になるが、ヴァイキングでは、何かしらの得意分野を持っている個性的な人が集まらないと戦力にならない。肉が好きな人が既にたくさんいるチームにさらに肉好きを追加投入しても戦力にならず、必要なのは少食でもいいから魚が好きな人や野菜が好きな人だ。

チームとして責任を持って仕事をする為には、全員が自分の好物だけを食べていればいいだけではすまされない。誰も食べずに最後に残った皿を始末する人は必要なのだけど、何でも好き嫌い無く食べることができるという能力は、仕事に就く為の必要条件ではなくて、多種多様なスキルや特性の一つである。肉ばかり相当な量食べるけど他のものが食べられない人は、どんなメニューでもそこそこ食べられる人と同等に有用な人物である。そこに無理に優劣をつけて個人を一つの座標軸で評価せず、多様性と組合せを考えることが、機能するチームを作るために必要とされる。

ソフトウエア開発というヴァイキングは、食事がスタートするまで、そこに並ぶ料理の種類も量も出て来る順番も予想できず、出てきた所で瞬間的にチームとして反応して、受け持つ料理の分担を決めていく必要がある。それは非常にダイナミックなプロセスだ。それでいて、配膳が終わった瞬間に全ての皿が片付いていないといけないという厳しい要求もある。なので、これを管理することは社員食堂の定食の世界とは随分違った仕事になる。

アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き

「アジャイルレトロスペクティブズ」という謎めいたとても発音しにくいカタカナ語のタイトルの本が送られてきて、弾さんがそこにケチをつけているが、私もタイトルを見て最初は「何じゃこりゃ」という印象を受けた。

これは、ソフトウエアを開発するチームの管理者が反省会を開くためのノウハウを集めた本だ。

そう言えばわかりやすいのだけど、「管理者」や「反省会」という言葉は、社員食堂配膳モデルを想起させる。だから、「これはファシリテーターがイテレーションごとにレトロスペクティブを行ないプロセスを改善するためのアクティビティを集めた本です」という言い方をする。

カタカナ語が出てくるたびに、読者は「これは定食配膳ではないヴァイキングの本だ、私は今、ヴァイキングモデルで考えるべき仕事をしているのだ」と頭をはたかれ、目を覚まされる。そういう効果があると思う。いっぺん読めばいいという本ではなくて、繰り返し読みながら実践していくべき本である。実際にやっているうちに、だんだんとそれが気にならなくなる。スラスラと「ファシリテーターがイテレーションごとにレトロスペクティブを行ないプロセスを改善するためのアクティビティ」なんて言えるようになる頃には、ヴァイキング形式の仕事に頭が適応している。

だから、弾さんの言うこともわからないではないが、日本語としての読みにくさも含めて、実用書としては、この訳が正解だと私は思う。

もちろん、我々が今大変わかりにくい事態に突入していることを、日本語のわかりにくさで表現するのはベストとは言えない。事態のわかりにくさをわかりやすい読みやすい日本語で伝えることは可能であるし、明治時代にはそういう努力があちこちにあったのだろう。だが、それは漢籍という基礎教養が共通語として機能していた時代だからできたことである。それに、それはこういう種類の本ではなく、他に求めるべきことのように思える。

それはともかく、社員食堂配膳モデルの中では「反省会」が開かれるということは失敗を意味している。ヴァイキングモデルにおける「レトロスペクティブ」はそうではなくて、成功の為に避けては通れない必須の活動である。つまり、ヴァイキングモデルで仕事をうまく進める為には、仕事の途中で、そのやり方を随時変更していくことが当然なのだ。つまり、「反省会」と違い、「レトロスペクティブ」は価値を創造するプロセスである。

その為に、この本では、「レトロスペクティブ」をブレーンストーミング中心に設計している。

データを収集する(ブレーンストーミングの前)
アイディアを出す(ブレーンストーミング本体)
何をすべきかを決定する(ブレーンストーミングの後)

これに入口と出口をつけると、この本の主要部分になる

4章: 場を設定するアクティビティ
5章: データを収集するアクティビティ
6章: アイディアを出すアクティビティ
7章: 何をすべきか決定するアクティビティ
8章: レトロスペクティブを終了するアクティビティ

それぞれの章の中に各論が数個あるが、一つづつ例示していくと

場を設定するアクティビティ→チェックイン(何か質問をして参加者全員が何か一言づつ言葉を発するよう求める)
データを収集するアクティビティ→カラーコードドット(模造紙に書かれたイベント一覧に、色つきのドットを貼って、その時自分が経験した感情を表現する)
アイディアを出すアクティビティ→トークンによるブレスト(ボールを回しながら順番に発言するブレスト)
何をすべきか決定するアクティビティ→レトロスペクティブ計画ゲーム(ペアで付箋紙に項目を書き、全員で議論しながら順序づけて貼っていく)
レトロスペクティブを終了するアクティビティ→感謝(誰かの作業に感謝し、それで良かった点、助かった点を述べる)

ここで注目すべきことは、特定の声の大きい人や、一目置かれている人だけの焦点が当たることが無いような工夫が、あちこちに見られることである。たとえば、全員が一定数のドットを貼るとか、ボールを回しながらブレーンストーミングをするとか、書く時はバラバラで貼る時は全員で、とかである。

「管理者」には、トップダウンで計画やそれぞれの役割や指示を下に間違いなく伝えていくことが求められるが、「ファシリテーター」は、各メンバーのそれぞれの声を、技術を使って吸い上げていくことを求められる。各人のそれぞれ違う特性や性格やスキルに依存する形でチームとしての仕事が回っているので、ここに細心の注意を払うのは当然のことである。また、それは、精神論ではなくて技術、方法論で改善できるものなのである。

また、スゴ本の人も言っているが、感情面への配慮もあちこちに見られる。ただ、どれも漠然として精神論ではなく、具体的なノウハウである。

ソフトウエア開発者は、5人〜10人くらいのチームで仕事をして、二週間に一回、二時間ほど全員で集まりこのような会議をする。現状は、それが標準的とはとても言えないが、こういう方法が有効だということがあちこちで報告されていて、それをまとめたのがこの本である。いずれ広まっていくだろう。

私は、このような最先端の動向について、ひととおりは追いかけているつもりであるが、そういう私でも、本当におかしな時代になったと思う。

「反省会」のやり方がソフトウエア開発の技術書として一冊の本になり(しかもオーム社!)、読んでみて、確かに実用的な価値はある(あえて即物的に言えば、これをやれば同じソフトがずっと安くできる)ということは感じる。このような「ファシリテーター」としてのスキルは、将来、資格試験になるかもしれない。

ただ、これはソフトウエア開発だけのことではないと思う。ソフトでは、背後にコンピュータという機械がいるので、現実に起こっている事態をうまくごまかす手段が無いだけのことだ。それがどんなに自分の信念に反していても、仕事のやり方を状況に合わせて効率化していかなくてはならない。効率化する人とそうでない人が、ごまかしようがなく客観的に測定されてしまうのだ。

他の仕事でも、同じように定食配膳モデルは消滅してヴァイキングモデルに移行しているのだが、まだまだごまかしようがあるから定食配膳モデルが一般的な常識として残っているだけではないだろうか。