ふりかえり読本 場作り編をよんで

はじめに

　先日(10/08) 技術書典５で入手した 森一樹さんの「ふりかえり読本　場作り編」（以下、表紙のイメージから「ぐるぐる本」と略）をようやく読みました。
　さすが ふりかえりの第一人者の書いた本とあって、あるあるの共感から何をどうやってのきめ細かいアドバイス、豊富なアクティビティと ページをめくるたびに参考になる情報満載、「さて明日から何ふりかえっていこうか？」とワクワクしていくこと請け合いの本になっていました。
　ただ、一方で「う～ん、ここどうかな？」ともやもやした箇所もあり、そのもやもやが何か ずっと考えさせられたのもまた事実でした。今回、もやもやしていたところが一定の像をむすんできたので、ここで自分の頭の整理がてら Outputしてみます。
　なお迷いましたが、本稿は、「ぐるぐる本」を読んで これから ふりかえりを推進していこう、今のふりかえり自体を改善していこう というリーダさん・エンジニアリングマネージャさんむけに 筆者がつまったところとその理由、今までの経験からえた解釈と留意点、アドバイスという形をとっています。不勉強なのでいくつかの誤認・間違い・違和感などがあるかもしれません。その点は予めご容赦願いたいのと、願わくはご指摘いただけるとありがたいです。¹

一番悩んだところ。チームのふりかえりで立ち止まることって一体なんだろう？

　ぐるぐる本では、ふりかえりの目的として以下の３つの目的と３ステップをあげています（p.19）

１．立ち止まる
２．チームを成長させる。
３．プロセスをカイゼンさせる。

　正直なところ、最初読んでいた時点では、ここでつまりませんでした。筆者は製造業の組み込みエンジニアなので、製造立ち上げ現場のラインストップをイメージしたからです。製造立ち上げ現場では、不良品が発生した際に、無理な組付けがおこらないようにメカ的なフィードバックをすると同時に、無理な組付けをどこでおこっているのか認知しやすいように検査ソフトを充実する活動をします。その契機となるのが、ラインストップでありプロセス改善です。チームのふりかえりもそんなもんだろうと。

　ただ、もう一度 読み進めていくうちにわからなくなりました。
　ラインストップの場合、上述したように目的は製造から設計へのフィードバックです。つまり、設計内容をこれでよしとせずに一度立ち止まって点検することであり、設計者に対するものになります。

　チームのふりかえりの場合、一体、誰に対して何に対して立ち止まろうとしているのでしょうか？

#チームメンバに対するものであるのは間違いない。では、何に対してなのか。
　まず「誰に対して」ですが、チームのふりかえりである以上、チームを構成するメンバに対するものとみてよいでしょう。つまりチームメンバすべてです。

　では、何に対してでしょうか？
　実は、筆者はずっと無意識にプロセスだと思っていました。
　つまり、チームメンバおよびチーム外への成果物定義ふくめたお約束事・ルールです。もやもや・曖昧模糊としているお約束事を特定し、その特定したお約束事を改善すればよいのだろうと。すなわち、フィードバックの対象はルール集となります。

　ところがもう一度 「ぐるぐる本」p.19 をみてみましょう。

１．立ち止まる
２．チームを成長させる。
３．プロセスをカイゼンさせる。

　なんと、プロセスを改善 ² させるのは２番目ではなく３番目となっています。つまり、プロセスに対してではなく「チームの成長」に対してが目的となっているのです。
　では、この「チームの成長」とはどういうことで 何に対してフィードバックをかければよいのでしょうか？一体、どうなっていると「チームが成長」しているといえるのでしょうか？

#チームの成長ってなに？
　「ぐるぐる本」では、「５章　チームのふりかえりの10の流れ」で、まず「目的を考える」をあげ、目的は以下の７つに分類されるとしています。

1.チームビルディングをしたい
2.成功を共有・活かしたい
3.学習を共有・活かしたい
4.失敗を共有・カイゼンしたい
5.課題を共有・対策を考えたい
6.成果を共有・活かしたい
7.過去のアクションができているかを確認したい

　そして、

チームの状況によって、どんなことをしたらチームの成長に結びつくか、は異なります。

　としています(p.35)

　筆者は、ここが「ぐるぐる本」の読者がもやもやする・悩みごとの一つだとおもうのです。

　そもそもチームが今どんな状況になっているか、容易に客観化・認知できるものなのでしょうか？

　チームがどんな状況になっているか はっきり認知できないから、「ぐるぐる本」のいう７つの分類のどこにフォーカスしたらよいかわからない、どんな打ち手をまず打っていったらよいかわからない、なので、まずは世間一般でやっている KPTをやってみましょう、YWTをやってみましょう（あるいは全部やってみましょう）、場作り必要みたい、場作りのためにお菓子はゆるされるのか といった様々な悩みにおちて、結局毎回似たような感じでやることをやるか、たちすくんでしまうか しまいにはやがて立ち消えになるように思えるのです。

#チームの状況を認知するために。あなたのチームは、機能してますか？
　ここからは、少し「ぐるぐる本」から離れ、他の文献（文献リストは参考文献リストの項参照）も援用しながら筆者の個人的な意見をかきます。
　まずは、以下の視点で、一度読者一人でふりかえってみるとよいとおもっています。

1. 自分の第一のチームってなんだろう？
2. 自分の第一のチームは（これから）機能するだろうか？

自分の第一のチームってなんだろう？

　ここでいう第一のチームは、実際に会社組織に認められている公式な集団でも 、変えたいと願っている同志（あるいはこれから誘おうとしている同志候補）からなる非公式な集団でもかまいません。組織の中でいると、様々な関係性をもち複数の集団に属することになります。少し大きな組織となると、部や課のように 大きな集団の中の部分集団に属している場合も多いかとおもいます。
　その中で、自分が一番長時間かかわっている集団、ないしは（非公式な場合は）読者自身が大事に思っている職場の仲間たちを思い浮かべればよいでしょう。
　チームの状況をふりかえろうとした際に、意外と「自分のチームとそのメンバ」のスコープ自体がもやもやしがちです ³ なので、まず自分の第一のチームとそのメンバがなんなのかを一旦仮決めでもよいのでしておくと、次のステップにすすみやすくなります。

自分の第一のチームは（これから）機能するだろうか？

　すでにチームとして動き出している場合は、現在進行形の「機能しているか？」におきかえてもかまいません。いずれにしろこれから不確実なことや困ったことが出てくる中でチームとしてうまく対処できるかどうか。
　常にリアルタイムで情報共有して相談してすすめられるとは限りません。そんな中、お互いの得意・不得意を理解しあっており
　「この人だったら任されたものの弱ったときには話してもよいだろう」
　「この人だったら任せておいて弱ったらすぐ話してくれるだろう」
といった関係になっているかどうか。
　チームの状況として「自分から弱みをみせても相手からたたかれない、悪用されない、誇大に伝播していかない」状況になっているかどうか、そしてお互いが弱みをだしてもチームとして対処できるようになっているかどうか。

　以上のことができそうもない・できていないなぁと感じているなら、まずはふりかえりの場だけでも そういう場にしたいよね と合意してすすめられたらと思うのです。⁴⁵

　その際に、一つ大きな障害・注意点があります。
　今まで、読者のみなさん自身が 過去 相手の弱みをみたらたたいてしまった、（悪気はなかったとしても）悪用してしまった、結果的に誇大に話してしまったことがあるかもしれません。リーダの立場であるとどうしてもそうなりがちですし ⁶、人間である以上、傷つけられたことは憶えていても、傷つけたことはそうそう憶えていません。また、その気がなかったはとしても 相手はずっとそうとらえているかもしれません。長い付き合いになっていればなおさらです。
　なので、この際、場作りの理由と同時に、まず「こういうことしてきてしまったかも。ごめんね。」と一言いっておきましょう。
　自分から過去の過ちという弱みをみせておけば、それ自体が場つくりの保証になりえるし なによりもメンバも弱みをだしやすくなります。

#メンバ間の信頼関係のさらなる醸成のために
　お互いがお互いの自己の弱みにおぎなってチームとして対処できるようになれば、信頼関係の構築の土台はできたも同然です。また、そんなチームって素敵ですよね。なので、このできている点を定期的にふりかえっていくと 自然と感謝の言葉がふえ ふりかえりの場が楽しくなります。

　ただ、これだけではチームの成長としてはあくまでも第一歩です。
　次は、お互いがお互いのやってしまいがちな点を指摘しあう関係に発展させていきたいのです。というのは、自分が自分自身でわかっていない点って多々あり、そのわかっていない点から他のメンバが黙って繰り返し補っているケースがありえます。それが顕在化したらマズイですよね。第一、この他のメンバが何らかのアクシデントでいなくなったら チームは機能しなくなります。
　そこで、「バグを憎んで人を憎まず」と同様、相手の行動のバグや認知・解釈のズレを普段からお互い指摘しお互い是正できるようにもっていきたいのです。お互いに是正を受け入れるようになると、信頼も一層強固になり、チームとして一皮むけた状態になります。
　ここで注意したいのは、あくまでも相手の人格にではなく行動にフォーカスしてフィードバックすることです。そうしないと、受け手はどうしても感情を害してしまいます。たとえば、事実と解釈と感情にわけ 行動を変えた際 どのような好ましい状態になるかに順を追ってフォーカスして話をするとよいでしょう。⁷

#ここまできてやっと プロセスのカイゼン
　チームのお互いが弱みを認め指摘しあうことが継続できるようになってくると、現状のチーム内でのつながりやチーム内外での対処の最適な仕方ができるようになります。
　本稿の読者のみなさんのように チームでふりかえりをやりたい人の中には、自分の見えている地平の中で少しだけ周囲を俯瞰する能力があってプロセスを良くしたいという思いではじめる人もいると思います。その場合、チームでふりかえりをする際、そのプロセス改善の件を早い段階でついつい言いたくなりますよね。「お前ら、ここなおせばぐっとよくなるのに。わかっとるとちゃうんか」と。
　ただ、特に早い段階、そのタイミングで本当に言う必要があるのかは、よく考えたほうがよいとおもいます。たしかにプロセス改善が一時ぐーんとすすむかもしれません。ただ、それによりチームメンバはあなたの指示まちになってしまう可能性があるのです。チームの成長を優先して彼ら自身でカイゼンが導き出せるようになるか、それとも一時の改善を優先するか、
仮に導き出せるのが数か月の先だとしても、やはり我慢したほうが実りが大きいとおもうのです。

#おわりに
　本稿では、森一樹さんの「ふりかえり読本　場作り編」をよんで、筆者が一番認識をあらためたこと・もやもやしていたところを考察し、そこからどうしていくかを述べてきました。

　具体的には、まず、プロセスの改善の前に チームの成長が大事であることを学びました。
　筆者は ISO9000シリーズや CMMになじんできた世代です。
　とかくカイゼンといえばプロセス改善を真っ先に検討・推進してきました（もっというと、ついついしてしまっていました）⁸。
　このプロセス改善の前に、チームの信頼、メンバの間で弱みをみせるなどリスクをとれるように信頼関係を改善すると、それだけでパフォーマンスがあがることを信じれるようになりました。

　つぎに、チームの成長のために、まずチームの状況にむきあうことが非常に大事なことを学びました。一方で、長年蓄積した人間関係・コンテキストの中で チームを再構築することは非常に難題だということも理解しました。
　実は筆者のかかえているチームの中では、新人・2年目を中心に構成されているチームがあります。実のところこのチームが一番成長著しいのです。この理由には、当初「わからないことがわからない（もやもやしている）」から「わからないことがわかる」そして「わかった」の学びがうまく機能しているからとみています。この新人・2年目がゆえに「わからないことがわからない（もやもやしている）があってもよい、わかるようにリスクをとってもよい」という立場の有利さ、それを定期的にふりかえって検証・承認・是正することが急速な成長を促しているようです。
　一方で、長年蓄積してきた人間関係では、上記「わからないことがわからない」「わからないことがわかる」「わかった」という理解度があやふやな上に築き上げてきたうえに、「弱みをみせない・みせれない」「衝突をおそれるがゆえに相手の行動の上のバグを指摘できない」という機能不全がかさなって、チームの成長を阻害していることを理解しました。
　この局面を打開するために、まず自ら過去の信頼関係を損なってきたことを弱みとしてだし、そこからせめて ふりかえりの場からでも信頼関係を構築し、機能不全の解消の第一歩とすることを提案しました。

　また、さらなる信頼関係の醸成のために、信頼関係の構築後のステップとして、やってしまいがちな点を指摘しあう状態を目指すことをあげました。その際、あくまでも行動にフォーカスしフィードバックをかけることが、とても重要と理解しました。
　
　最後に、繰り返しになりますが、プロセス改善をいそぐあまり、チームの成長を阻害し結果的にプロセス改善が形骸化してしまっていたことに思い至りました。
　本来なら、組織のフレームワークと各コンポーネントの期待値は、エンジニアリングマネージャが提示するものの、各コンポーネントの実装方法とパラメータ調整、つまりプロセスの自己組織化はチームに任せる方が理想的です。
　その理想に近づくためには、エンジニアリングマネージャとしての筆者はガマンがたらなかったと、率直に反省しています。

　以上の視点は、自分にとって、今までにはっきりと像を結べていなかったものです。その目を開かせてくれた意味でも この本は控えめにいっても良書だとおもいます。
　「ふりかえり読本　場作り編」の森一樹さんに感謝しつつ、本稿の筆をおきたいとおもいます。ありがとうございました！

##参考文献

パトリック・レンシオーニ、あなたのチームは、機能してますか？
表題からわかるように、理論的な枠組みはこの本によりました。最後に5分で終わるチームの機能不全診断チェックリストもついています。ストーリー仕立てと解説の2部構成になっていますが、解説から読むことをお勧めします（解説部分だけ抜き出した記事と感想を知りたい方は右記の記事参照→『あなたのチームは、機能してますか？』を読んだ）。心理的安全性というもやっとした単語をつかわずに書かれた良書です。

いま話題の「心理的安全性」について、本気出して科学的に分かりやすく説明してみた
チームの心理的安全性の定義として、「メンバーの間でリスクをとっても大丈夫だという信念が共有されていること」が紹介されています。この定義が心理的安全性を語るうえで一番しっくりくると個人的におもっています。

アトゥール・ガワンデ、医師は最善を尽くしているか――医療現場の常識を変えた11のエピソード
この本の中のエピソードの一つに、アフガニスタン・イラン戦争で戦闘で負傷した兵士の死亡率が従来より半減した話があげられています。半減した理由はプロセスがよくなったわけでも技術が進歩したわけでもありません。各プロセスで患者を変になんとかしようとせず、信頼と必要なデータを携えて後工程にわたした点にあるそうです。これこそがチーム（この場合、医療チーム）の成長といえるのではないでしょうか。

1. 現在どんなマサカリがどんでくるか ぷるぷるしております。願わくはゴム製のマサカリであることを。 ↩

2. 筆者の森さんは、改善を単発的なもの、カイゼンを継続的なものと、言葉を使い分けていますが、断りがない限り 本稿では広い意味でまるめてあえて改善としています。 ↩

3. かくいう筆者もそうでした。 ↩

4. 非公式な集団なら合意できそうなより気心のしれたメンバに絞るのも一つの手かもしれません。 ↩

5. エンジニアリングマネージャーの場合、ふりかえりの場だけ という選択でもよいとおもいます。社内政治が複雑な場合、いつでも誰でも弱みをみせるのは現実的ではないとおもうのです。 ↩

6. 初代ガンダムでたとえると「殴ったね！オヤジにもぶたれたことないのに！」になるでしょうか。ブライトさんだってホワイトベース全体を背負い生き残るために必死なんです。そんな中つい手がでたとおもえば。 ↩

7. これは Management3.0のなかにある feedback wrap という手法ですが、本稿では煩雑さをさけるために紹介のみとどめます。 ↩

8. CMMでは IDEALという形でプロセス改善をすすめます。たとえば プロセス改善活動を浸透させていくにはを参照のこと。 ↩