"アジャイル レトロスペクティブズ" Esther Derby & Diana Larsen 著

本屋を散歩していると、ある言葉が目に留まった。Agile Retrospectives...副題には「ふりかえりの手引き」とある。つまり、プロジェクトの事後分析である。全ての道筋は過去を振り返り、自らを評価することから始まるといったところだろうか。不況時に、自らを省みて立ち止まって読んでみるのも悪くない。
最近なぜか？教育係の依頼が多い。教えられることなんて何も無いのに。年寄り扱いされてるってことか？失敬な！ちなみに、夜の社交場では、娘のようなお姉様方にお子ちゃま扱いされている。
今宵は、本書に乗せられて自らの体験談を語ってみたくなった。人生は短い。アル中ハイマーと出会ったがために、無駄な時間を過ごした人も多いことだろう。この場をかりて「深くお詫び申し上げます！」

著者のEstherとDianaは、Norm Kerthとともに、Retrospectivesのファシリテーションにおける世界的な権威者なのだそうだ。ただ、その思想は極めて日本人的であることに驚かされる。組織運営の本質的な思想に国境はないということだろう。プロジェクトは刻々と変化し、チームは生き物のように常にうごめく。どんなにうまくいったチームだからといって、次もうまくいくとは限らない。状況をいち早く掌握するためには日々の観察が大切であり、それを整理するために時々振り返る必要がある。著者たちは「Retrospectives」のことを、仕事が一段落した後にメンバーが集まり、やり方やチームワークを点検し、改善する特別なミーティングに位置付けている。
「チームの問題は、技術的な問題と同じくらい、時にはそれ以上に、手ごわいものだ。」
本書は、具体的な訓練方法まで紹介してくれるので、どこから手を付けてよいか分からない人には参考になるだろう。ただ、それが絶対というわけではない。メンバーや環境など、まったく同じ条件で仕事ができるはずもないので、最適な方法はいつも異なるだろう。重要なのはその根底に潜んだ思想である。くだらないプロジェクトに時間を浪費するほど人生は長くない。目的はただ一つ、人生を楽しもうとしているだけなのだ。
ところで、ベンチャーと称する会社と関わると、いろんな経歴を持った人間が入社してくる。それでも、多くが大企業を経験している。そして、おもしろいことに出身会社によって文化傾向が現れる。自分の哲学に走る傾向や、責任範囲を決めてひたすら自己防衛に走る傾向などなど。こうした傾向が出身会社の文化に反発したものなのか、そのまま継承しているのかは知らない。そこで、まずメンバーの認識合わせから始める必要がある。文化の融合とはおもしろいものだ。

プロジェクトの状態を見るには、本音を言わせることが重要であろう。それには愚痴らせるのが良いと思っている。それも冗談で言える段階から。愚痴が出るということは反発するパワーが残されている証でもある。体制の維持が目的ならばイイ子ちゃんほど都合の良いものはない。だが、改善が目的ならば、むしろ弊害となる。完璧な体制などありえない。もし満足しているならば、宗教化が進み思考停止になっていると見る方が正しいだろう。沈黙の抗議が始まれば手遅れである。そうならないように、笑いながら愚痴れる環境を作ることに専念する。おいらのプロジェクト手法は、これに尽きる。技術的な問題は比較的対応しやすい。もし、メンバーが技術問題を抱えていれば、人前で喋らせればいい。すると、メンバーは自分で喋っているうちに自らの思考を整理して、いつのまにか自ら解決策を見出す。周りはそれを聞いてやるだけでいい。悩み事を相談していたはずが、いつのまにか解決方法を自ら自信満々に語っている。こうした光景がしばしば見られるからおもしろい。ただ、リーダの存在感が薄れてちょっと寂しい。挙句に飲まずにはいられず、場所を変えてそのまま宴会となる。したがって、プロジェクトリーダはアル中ハイマー病患者が多いはずだ。

人の評価は難しい。好き嫌いという感情も介入する。客観的な評価を求めるために、数字で段階評価する光景をよく見かける。これがまったく意味がないとは言わないが、どれほどの効果があるのだろうか？カリスマ性5、技術力3、発想力4、協調性1、まるでシミュレーションゲームだ。評価項目に当てはまらない事象や表現できない事象も多い。評価される側も、売上などの数字で部署や人の評価を求める人がいる。しかし、経営の立場から考えると奇妙な話である。誰が担当してもそれなりに成果の出る仕事と、失敗する可能性は高いが将来を睨んで挑戦したい仕事とでは、どちらに優秀な人材を投入するだろうか？困難な仕事ほど優秀な人材を配置するのが合理性というものである。おいらの評価基準は単純だ。その人が組織にとって居なくなったらどれだけ困るかである。ただ、居なくなって初めて、その人の価値が認識できるから困ったものである。恋愛は別れた時に、その人の良さが見える。

プロジェクト改善のアプローチで全ての問題を列挙して、解決策を見出すべきだと主張する人がいる。そして、一つの問題に一つの解決策を対応つける光景をよく見かける。それも手法の一つであろうが、分析すれば一つの問題から派生していることが多い。何もかも列挙するといきなり挫折が見えてくる。長続きするためには高い可能性を維持することであろう。ただ、目標を視覚化できるチャートは、メンバーの意識合わせに役立つ。少なくとも計測可能で達成可能なものでなければ、メンバーの共通目標にはできない。最初にプロジェクトの方向性を明白にすることが重要で、ここで時間をかけることを面倒だとは思わない。むしろ、ここで時間をかけた分、後で時間が短縮でき、時間的にもエネルギー的にも十分見合うものとなる。また、メンバーの意識が合えば、重要な問題が発生した場面でも少々無理がきく。問題発生は常に想定しておくべきである。チーム内を円滑にするために、笑いネタにできる人間が一人いるとありがたい。馬鹿を演じられる人間は貴重である。実は賢いと認められた人間の成せる技である。リーダ自身の馬鹿げた行動を暴露するのもいい。チーム内には常に笑いを起こせる共通のネタを仕込んでおきたい。おいらのプロジェクトは運良くメンバーに恵まれてきた。それなりに楽しくやれてきたからである。失敗もあるが今では笑い話にできる。

突っ走らないと気が済まない人がいる。全体の方針が決まらないのに、勝手に検証環境を作り始めたりといった行動をとる。自分の仕事が遅れることで、責任を負うのが嫌だと明るみに主張する人もいる。誰も責任を押し付けようなどと思っていないのだが、そのような政治的な体験をしてきた人は多い。部分的に進んでも、足並みが揃わないと、後戻りすることになると説得しても無駄である。あえて、そうした人の行動を止めたりはしない。それでストレスから回避できるのであればそれもいいだろう。こういう人は作業をしていないと落ち着かない。コードを書くことが精神安定剤になっている。無闇にコンピュータに向かっている時間が長い人の仕事量が多いとは限らないのだが。人間を言葉だけで啓蒙することは無理である。新たな思考方法を本に求めるにしても、どこかに興味や共感できる思考の欠片を持っているから、その本を選ぶことができる。むしろ言葉だけで簡単に操れる人間の方が怪しい。事前検討や上流工程を綿密にやれば、日程の精度が高まり、結果的に仕事が加速することを体験させなければならない。それまで我慢するしかない。何事も結果が付いて来ないと説得力はない。
また、仕事のパターンを形式化することを好む人がいる。形式化できるに越したことはないが、できないのが人間社会というものである。また、ワンパターンの仕事スタイルは硬直化の要因にもなる。それに人間であるからには、作業よりも思考することに価値を見出したい。優秀な人ほど事前検討を大切にし、無駄を排除しようと努力しているように思える。彼らは一番大きな無駄は後戻りすることだと知っている。逆に、無駄な努力を多く経験してきたとも言える。世の中は無駄に満ち満ちている。無駄から学ぶことも多い。こうなると無駄は無駄ではなくなる。プロジェクトリーダは、しばしば様々な形の人間関係で衝突することがある。ただ、不思議なのは、最初に苦労した人ほど後々うまくいくケースが多いことだ。また、人間的に合わないという直観は最初に働く。こうした現象を経験から学ぶが、その要因を論理的には説明できない。

本書が推奨するRetrospectivesの手順は、次のようなものである。
1. 場を設定する
2. データを収集する
3. アイデアを出す
4. 何をすべきかを決定する
5. レトロスペクティブズを終了する
おいらは「場を設定する」が一番重要だと思っている。以降の項目はプロジェクトを実施する上で必然だから、ほとんどの人が試行するだろう。それらを有効にするには、いかに場を設定するかにかっていると思っている。

1. 場を設定する
場を設定するとは、議論に適した雰囲気を作り出すことで、最も気を使うのは議論の所要時間であろう。忙しいメンバーにとって、だらだらとした議論はストレスとなる。本書は、最初に所要時間を明確にすることが大切だと述べている。会議の進め方がメンバーに浸透していれば、なおのこと良い。もう一つ気を使うことが、発言に遠慮がちな人が多いことである。エンジニアの中には気難しい人間も多い。実は、おいら自身が人見知りが強く気難しい人間で喋ることが苦手である。と言っても誰も信じてくれない。また、プライドなのか？問題を自分だけで抱え込む人がいる。追い詰められてから公表すると、責任問題にもなり、他のメンバーから批難される恐れがある。事前に問題を明るみにするためにも雰囲気は重要である。議論するからには、全員に喋ってもらはないと意味がない。いかに大人しい人に喋ってもらうかは苦労するが、チームの一員として自覚させるためには必要である。大人しい人を表に出すためには、その人の担当を表に出せば良い。インターフェースを話題にすれば、責任感さえ持っていれば、嫌でも発言せざるをえない。本書は、チームに約束が重要であると語る。約束は、メンバーに協調した振る舞いや、責任を持たせることができるという。ただ、経験的にはチーム内の約束事はいつのまにか暗黙の了解となっている。互いに成長したいという意識が一致していれば、自然とチーム内に規則が生まれるような気がする。

2. データを収集する
本書は、客観的な事実はデータの一部でしかなく、データの半分以上は感情であると語っている。確かに、感情は、事実やチームについて重要なことを教えてくれる。ストレス情報に敏感でなければリーダは務まらない。リーダにとって有用な情報は感情であり、メンバーにとって有用なのは客観的な情報である。所詮、人間は感情の動物だ。論理が万能と信じるのは危険である。論理に一瞬でも隙があると、メンバーは不快になる。それが、感情によって微妙に左右され、更に決断の段階で左右される。ならば、最初から感情の存在を認めた上で、対処する方が現実的である。ただ、エンジニアは感情を表に出したがらない傾向にある。無理に感情を煽るのも逆効果となる。

3. アイデアを出す
アイデアを出す段階では、場が設定できていれば、あまりリーダが積極的に発言する必要はないだろう。後は、自然の成り行きに任せる。ただ、プロジェクトから一歩下がった視点を与えることは重要である。おいらは哲学的な思考を重視する。それは、各メンバーに仕事で何か得るものがあるか、それを実感できているか、を問うことである。どんな仕事でも、その前提にはそれぞれの人生がある。今後も役立つ手法を使うか、一時的なもので誤魔化すかは、モチベーションにも影響を与える。ひょっとしたら、その人は、会社を辞めてもっと良い生き方を見つけるかもしれない。おいらは、組織の枠組みにとらわれない付き合いをしたいと願っている。その延長上に、チームの目指すべきものを見つけたい。

4. 何をすべきかを決定する
プロジェクトリーダの仕事は、何をすべきかを決定することが目的である。本書は、あまり多くの改善項目を試すのではなく、絞ることが重要だと語る。

5.. レトロスペクティブズを終了する
本書の流れで、この項目は少々気になる。文書化、フォローアップ、点検と改善、ここまでは想像がつく。ただ、本書は、最重要なものにこれを挙げている。
「メンバーの作業に感謝することを忘れない。」
プロジェクトリーダは、当然感謝の気持ちを持つだろう。しかし、その気持ちは伝わっているものと考え、しばしば態度に示すことを省く。それが照れくさいところもある。本書は、そうした態度を省いてはならないと主張する。ということで、この場を借りて皆様に感謝致します！
また、リリース後のRetrospectivesでは、チーム外にも招待状を出し、新しい参加者を募ることを薦めている。チーム外の付き合いは、政治的な思惑も絡むから難しい。それが社外となると尚更である。本書は、そうした啓蒙運動を積極的に行うように推奨している。ただ、あからさまに啓蒙して周るのは布教活動のようで肌に合わない。そもそも、それほど自信のあるやり方をしているわけでもない。

6. プロジェクトリーダの役割
リーダもつい議論に参加してしまいがちだ。しかし、リーダの仕事はプロセス管理にある。本書では、それをアクティビティ、集団ダイナミックス、時間の管理であると述べている。そして、自らの強い意見は避け、中立の立場に徹することと、メンバーの感情や反応を管理することで、議論の成果に貢献することが重要である語る。もし、リーダだけが重要な情報を知っている場合は、その役割を一時的に離れる旨を知らせて、議論に参加するのもいいだろう。その立場を明確することに注意を払うのは大切である。頻繁に立場を変えるのも混乱を招くだけである。本書は、一番やってはいけないことは、相手を批難することであるという。これは、場を設定するところで、メンバーの認識合わせができていれば、互いに批難するような場面を事前に回避できるだろう。やたら、技術や戦略を持ち込んで管理しようとするリーダをよく見かける。ただ、管理で一番神経を使うのは感情的なものである。ここが管理できなければ、どんなテクニックを持ち込んでも効果はない。そして、何よりも大事なのが、リーダ自身の自己管理である。これは孤独との闘いでもある。

7. 改善
継続中のプロジェクトを改善するよりも、新規でやり直す方が手っ取り早い。慣習化した行動を改めるよりも、新しい行動を加える方が楽である。チーム改革とは、そんなものだろう。本書は、新しいスキルを身に付けるのに、ミスをしても構わないことをメンバーに伝えることを薦める。改善の責任はメンバーで共有することであって、一人がチームの救世主になると、共同作業を台無しにする恐れがある。また、それに追従するだけで頼りない集団になってしまう。その人の肩にかかるというのは、それだけリスクを伴う。おいらがカリスマ性を信じないのは、このあたりに理由がある。