はじめに
あなたのチームは、どうやって問題と向き合っていますか？
この記事は、Agile Talks vol.1のセッションで話題に上がった「チームは問題解決を見てはいけない」という命題について、正面から向き合って考えてみるものです。
問い「チームは問題解決を見てはいけない」
Agile Talks vol.1にて、アジャイルコーチ田中さん(@callas1900) のセッション「レトロ・オブ・ザ・デッド ～ゾンビレトロしてたチームを2年間観察していたら、良い振り返りをするようになったので、その活動報告～」の中で紹介された命題です。
このセッションを要約すると、「辛いふりかえり（レトロ）を変えていった軌跡と、変わっていった時のふりかえりのマインドセットの紹介」というものでした。
このセッションの中で、田中さんが発した言葉が次のようなものです（※意訳）。
「あるアジャイルコーチから、『チームは問題解決を見てはいけない』という禅問答のような問いを出されました。私の中では納得する答えは持っているのですが、ここでは伝えません。皆さんも考えてみてください。」
私は、この問いに対しての自分なりの答えはすぐに浮かびました。私も同じような考えを持ち、ふりかえりに臨んでいたためです。ただ、イベント後の懇親会で田中さんと話したところ、少しイメージの違うものでした。
この問いには正解はなく、その人それぞれの答えがあるはずで、そもそも「この考えが間違っている」と考える人もいるでしょう。しかし、非常にいい命題だと思いますので、この場で提起し、アジャイルコーチ・スクラムマスターとしての思考を深めるために皆さんに使っていただければと考えています。
以後、私や田中さんなりの答えを載せておきますが、できれば「自分なりの答え」を少しでも考えてから、読んでみていただけると幸いです。
田中さんの考え方
懇親会で私の考えをぶつけたうえで、田中さんの話を伺いました。
聞いた話から得られたイメージは以下のようなもの。
「すぐそこにある問題と、遠くに見えるゴール、どちらを見たほうがいいと思う？」
それ以上は私も納得して深堀りはしなかったので、あえて解釈はしないでおきます。
皆さんはどう感じましたか？
私の考え方
チームの自己効力感（集団効力感）が成長を加速させる
チームの成長に大事な観点の1つに、「自己効力感（集団効力感）」が欠かせません。「できた」「うまくいった」という経験が自己効力感を高め、新たな実験や挑戦を促します。
ふりかえりの中で、最も陥りやすい問題が「『問題』のみにフォーカスしすぎる」というものです。KPT（けぷと）を行うチームに特に顕著(※)で、Problemばかりに話が膨らみ、Keepは出ていなかったり、最悪の場合Tryにもつながらない。問題のみを話し合い、落ち込んでふりかえりが終了してしまう。そんな経験がある方もいるはずです。
※KPTはしっかり使えれば非常にいいフレームワークです。
問題にフォーカスすることは悪いことではありませんが、「問題のみ」にフォーカスすることはよい状態ではありません。問題のみを見ていると、「ここまで出来た」という自信が持てないため、一段階上のステップに進むための一歩が踏み出せなくなります。
私は、ふりかえりの研修などで以下のように表現しています。
「人は、「ここまでできた」という土台があって初めて、ジャンプする・挑戦することができるようになります。ただ、問題のみを見ていると、自分の真下にあるものは土台ではなく穴です。穴から落ちてしまわないように必死になって、高く飛ぼうということが出来なくなってしまいます。」
自己効力感があってこそ、チームは加速度的に成長していきますが、その自己効力感は、問題のみを見ていると育てることができません。成功を見て、初めて得られるものです。
新しいチームの場合、試行錯誤の連続で、多くの問題が発生します。ただ、その中でも得られた「小さな成功」というものは、試行錯誤の元生まれた貴重なものであり、その成功こそ、多くの問題を解消・ひっくり返しうるものだったりします。「問題」をベースにした解決策は、そもそも成功した試しがないものに対して検討しているわけですから、そもそも改善したとしてもうまくいく保証はどこにもありません。ただし、「成功」という実績をベースにして話をすれば、成功をより増やし、失敗を減らすことも難しくないでしょう。一歩ずつ階段を上っていく、ということができるようになるはずです。
「チームは成功体験をふりかえる」ことが、チームの成長のための第一歩だと考えています。
チームはゴールを見ることで同じ方向を向くことができる
これは、田中さんの考えに近いのでは、と思っています。
直近の問題にフォーカスすると、チームメンバーの視線は様々な方向に向きます。全員が同じ問題を見ているならいいのですが、多くの場合、自分が注力したい（注力しなければならないと感じている）問題に目が行きがちで、チームメンバーそれぞれが見ている方向がバラバラだったりします。
こうした状態で問題解決を行おうとすると、チームは別々の方法でバラバラに動き出します。問題1はAさんが、問題2はBさんが、問題3はCさんが、という風に、別々に対処を始めます。この問題対処の方法は、効率化・分業という観点では短期的にはいいかもしれませんが、長期的な目線で見ると、1つの弊害を引き起こします。それが、属人化の加速です。
問題の解決を最短手で行おうとすると、どうしてもその道が得意な人に任せがちになります。チームの初期のスキルセットに開きがあればあるほど、その傾向が顕著になるでしょう。
この解決の方法に慣れきってしまうと、スキルの開きはさらに大きくなり、自分の得意分野でないスキルを伸ばす機会はどんどん失われ、チームの属人化を加速させます。属人化が進むと、誰か一人が問題解決をしないと進めなくなり、問題解決がボトルネックになり、チームのフロー流動性が失われていきます。
もし問題を見るのであれば、まずはゴールを見るべきです。
チームが目指すゴールに向かっていくために、必要な問題解決を全員で行っていきます。
問題は、小さなものから大きなものまで、チームの周りに無限に転がっています。どんなにうまくいっているチームでも、問題を上げようと思えばキリがないくらい上がるでしょう。
ただ、うまくいっているチームは、問題をすべて解消しようとはしません。
遠くのゴールを見た時に、取り除かなければならない問題を優先的に解決していっています。
そのとき、分業は行わず、全員で問題に取り組みます。全員で問題に取り組んだほうが、その問題解決に携わった人は同様の問題を起こしにくくなりますし、問題解決のためのスキルも向上します。また、問題解決の中で、他の人のスキルを吸収することもできます。さらに、コミュニケーションの向上により、自然と問題が解決しやすい環境が整っていきます。
**遠くのゴールを見据える。**これは、問題解決が、見つかった問題を潰すというネガティブな活動ではなく、ゴールを実現するための活動というポジティブな活動へと変わります。
そのイメージにおいては、チームは「問題解決を見ている」のではなく、「ゴールを見ている」状態になります。
問題解決ではなく、課題創出をする
これは、問題のとらえ方に関するマインドセットです。
上述のとおり、自分たちを取り巻く問題、というのはいくらでも見えてきます。
ただ、エンジニアが本来成し遂げるべきなのは、「市場」にリリースするプロダクトの価値を最大化し、市場に貢献したり、組織に貢献することです。
ITのビジネスモデルには、問題解決型と課題発見型があります。
顧客の悩みを具体化し、システムを作る。ウォーターフォール型で作られる顧客向けの大規模システムの多くが、問題解決型のビジネスモデルです。ERPなどが問題解決型の主な例です。
ただ、昨今の「アジャイル」「スクラム」などで行われるビジネスの多くは、課題創出型です。顧客のより大きな発展のために、顧客に寄り添いながら、少しずつ前に進みながら（漸進的に）課題を見つけていき、企業成長を目指すアプローチ。または、「顧客の顧客」に向けて、市場の「課題」を見つけ、そこに切り込み、大きな利益を生もうとするアプローチ。
この課題創出型のビジネスモデルにおいて、チームの動き方も課題創出型になっていきます。自分たちの成し遂げたい「ゴール」を真剣に考え、それを成し遂げるための道筋である「課題」を自分たちで考え、提案する。自分たちで本気で見つけた課題を本気で解決しようとするとき、チームのモチベーションは上がり、チームの方向性は1つに定まります。
チームの方向性が1つに定まると、大きな爆発力・推進力を生むようになります。バラバラだったチームが1つになり、コミュニケーション・コラボレーションが活発になります。その結果、チームの透明性は上がり、チーム内の中で検査・適応が自然と行われるようになり、自己組織的なチームへと近づいていきます。
まとめ
これが私なりの**「チームは問題解決を見てはいけない」**の答えでした。
決して、問題解決をしてはいけないわけではありませんが、ふりかえり（レトロスペクティブ）の中で、見るべきは過去ではなく未来だと考えます。
皆さんのチームは、いかがでしょうか。
あなたはどう考えたでしょうか。
色々なご意見、お待ちしています。