「チーム・ジャーニー」の第1部を読んだ

カイゼン・ジャーニーを読んだ中で気づいたこと、やろうと決めたことがしっかりできるようになってから本書を読もうと思っていたが、第1話のタイトル「グループでしかないチーム」というタイトルに強烈に惹かれて、それほど間を空けずに読むことにした。
ただ、各話の内容をかみ砕き言葉にするのに結構な時間を要しているのと、複数チームでの開発に直近で携わることが無いので、ひとまず第1部だけの感想をまとめた。

チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで

第1部を通して今の自分では、アジャイルを導入すれば一気にチームの理想の姿近づくことができると考えがちだが、そんなことは決してなくて、「ありたい姿」と「現状の姿」、「中継地点の姿」を把握して、その差分を地道に埋めていくしかない。アジャイルはそのための手段の一つであって、結局は広い視野で現状を把握して、それを元にどうアクションを起こすかということが根幹という結論に至った。

第1部 僕らが開発チームになるまで ― チームのジャーニー

第1話　グループでしかないチーム

本章の「グループでしかないチーム」という題に惹かれて、カイゼン・ジャーニーからほぼ間を空けずにチーム・ジャーニーも読み始めることにした。自分の考えとしてチームは1つのミッションに向かって自分たちで考え行動する集団で、グループは目標のために集まってはいるがそれぞれがバラバラに動いている集団、という感じ違いがあるがそれをうまく言葉にできていなかったがそれが表としてまとめてあり、違いを明確に認識することができた。
また、本章ではチームになるための4つの条件が挙げられているが、なぁなぁで済ませてしまいがちだなという印象。チームの目的・共通の目標はマネージャーから降ってきたものをそのまま利用して済ませがちだし、お互いの持ち味は普段のやり取りからぼんやりこんな感じだろうという感じで済ませがち。仕事のやり方については、やり方と約束は増えていく一方で棚卸があまりされず形骸化しているものも多い。それを防ぐためにミッションや約束を降ってきたもの（押し付けられたもの）とするのではなく、自分たちで考え言語化することが重要ということなのだろう。
本章で印象に残っているのが、「チームづくりも適当にやっていれば適当にしかならない。プロダクトづくりと同様だ。」という言葉で、プロダクトづくりについてはメンバー全員が様々なアプローチをとって良くしていこうとするのに、チームづくりにはそこまで力を入れていない（入れなくてもなんだかんだ仕事が回ってしまう）。チームづくりがおざなりでもある程度仕事が回っている状況なのであれば、チームとしてミッションに立ち向かうことができれば更に大きな成果を出せ、プロダクトにもより良いインパクトを与えられるのになぁ・・・

第2話　一人ひとりに向き合う

どうしても組織の中の1チームという立場だと、まずチームの目的ひいては組織の目的・目標があって、それを踏まえて個人のミッションがあるという形になるように思う。その形だと個人は組織のミッションを達成するための駒になってしまい、自分のWhy（なぞここにいるのか？）を見失ってしまう。見失わないにしても、個人のWhyとチームのWhyが一致せず仕事をこなしているだけという状況になるのだと思う。
1話であったチームのミッションを自分たちで言語化する際にも個人のWhyをチームとして認識していれば、より解像度高く言語化できるような気がする。そうすることで個人とチームのWhyがつながり、 今まで、チームや組織のミッションを自分事として捉えるようにと幾度も言われてきたが、正直その意味がよくわからなかった。人から（言い方は悪いが）押し付けられたものを自分事として捉えるなんて無理だと。本当はミッションを自分事と捉えられるように再定義しろということだったのかなと考えることができた。ミッションを自分たちで再定義すれば、そこには少なからず自分たちのWhyが入ることになり、個人のWhyとチームのWhyをつなげられることになると。
この辺り、どちらが先か問題が起こりそうだが、どちらが先にしても自分のWhyを念頭に置くことを意識し続ければ何とかなる気がする。

第3話　少しずつチームになる

1つの目標に対して複数の問題があると一気に対応しようとして破綻してしまいがち。そして、失敗したという経験から動くことに億劫になるということにつながる。
スクラムを導入すればチーム開発がうまくいくという幻想にとらわれてしまい、いきなりスクラムを始めると変化が大きすぎて、開発が大きく遅延してしまう。そうなってしまうとチーム外からも詰められるし、チームにスクラム導入は失敗だったという経験となってしまう。「自分たちはできる」感を演出することがチームの関係性を高めることにつながるのであれば、「自分たちはできない」と認識してしまうとチームの関係性が低まってしまうことにつながるように考えられる。
小さなステップを踏んでいくことが重要ということは耳にタコができるほど聞くが苦手だった。別件でコーチングを受けたときにその手法を一度経験したので、少しは苦手意識が変わったように思うし、それを思い出しながらやっていけば何とかなるかも？ 小さなことからコツコツと。

第4話 チームのファーストを変える

チームごっこに陥るチーム、耳が痛い。チームだからと全員の合議制で決めようとして結局なにも決まらないということは何度か経験してきた。責務がはっきりしないせいで“仲良しこよし”状態になっていたのだと思う。
もしかすると昔はチームの練度が高く、それでうまく行っていたのかもしれないが、時間の経過（メンバーの入れ代わり）によってその時とヒカクすると練度が下がってしまっているが、昔はこれで良かったという成功体験に引きずられて何も手をうたず、少しずつ腐敗していったのかもしれない。
自分たちの現在地を定期的に見つめ直す場が必要と言うことなんだろう。それをもとに必要な方向性を見定め行動に移す、言葉にすると簡単だが現在地を正確に把握することはトレーニングが必要な気がする。

第5話 チームをアップデートする

問題がないのが問題。以前いかにして振り返りは死んだかというようなブログを読んだ。手を付けやすくて成果が大きいものをあらかた退治し終えたために振り返りで問題が出なくなり形骸化してしまい、振り返りは不要という空気になっていったという流れだった。似たようなことを経験したことがある。その時のことを思い出すと、目の前に出てきた問題を都度都度対応するという感じだった。
今になった思うと、その時のチームの方向性・ミッションがブレていて、ミッションを達成するための問題ではなく、各々が思い思いの問題を上げていったために、解決したところで進んだ実感を得にくかったのかもしれない。
メンバー全員が今の方向性・ミッション（なぜここにいるのか？）をこたえられる状態で差分を取ることで、実りあるふりかえりを続けられるんじゃないかなぁ・・・と思う。

第6話 分散チームへの適応

リモートワークが浸透してきて、この章の話の重要性が増したように思う。チームの状況がこれまで以上に大きく、そして早く変化するとともに、これまでになかった分断（時間・場所・経験）と直面することになる。
個人的には、「分断も1つの制約と考える」ということにハッとさせられた。普段開発するときもどういった制約があるかを考えるが、分断もそのうちの1つでしかないとすることで感情論抜きに対応を考えることができる。状況や制約を把握（観察）したうえで対応方針とフォーメーションを考え行動に移す。これは障害対応では自然とやっていることだ。何故、通常時にはそれができないのか？障害対応は断続的な変化なため意識的に状況を観察しなくても、変化を認識できるからなのだろう。日常の変化は連続的なため、意識して観察しないと変化を認識できず、フォーメーションを変える必要があるということに気づくことすらできない。
思い切って「実験」という形で適当にフォーメーションを変えて簡単なプロジェクトをやってみても良いかもしれない。かなり無茶苦茶な感じはするが、意図的にチームにインパクトを与えることで普段の状況を違った目線から見ることができ、課題が見えることもあるんじゃないかと思う。

第7話 チームの共通理解を深める

必要なコミュニケーションがとれていれば分断は発生しない。そうした状態を作るためにはチームの透明性を高める必要がある。言葉にすれば納得できるし、単純そうに思うがよくよく考えると「透明性が高い」と自分では思っていても実際には高くないということがありそうだなと感じた。
必要な情報に誰でもアクセスできる（見える化）=透明性がたかい、というわけではない。ついつい、アクセスできるのであれば行動に移さない個人の問題と考えてしまいがちだが、誰しも最初から情報への感度が高いわけではないので、「場づくり」と「一緒にやる」ということが必要になるということなのだろう。
チームに新しくジョインしたメンバーが情報を探すのに時間がかかっていたり、そもそも情報が公開されていることを知らなかったり、ということが何回か発生するのではあれば、個人の問題として切り捨てるのではなくチームの透明性（情報へのアクセスのしやすさ、情報の解像度）に問題があると考えた方がいいのかもしれない。

第8話 一人の人間のようなチーム

プロダクトバックログに積まれたタスクを消化するだけという受け身な仕事のしかただと、どうしても開発チームとしての目線に偏ってしまう。PO側もプロダクトバックログを積んで出来上がったものの検証だけをするという仕事のしかただと目線が偏ってしまう。そうなると、考える（仮説検証）と動く（開発）が分断されて、仮設から開発まで時間がかかってしまうし、考えたことがうまく伝わらず変なものができるなんてことにもつながってしまう。
お互いが共通認識を持っていたとしても目線が固まってしまうと、結局分断が起きる。ベストを言えばお互いの目線（考え方）を自由に行き来できるのがよいはずだが、それは現実的ではないように感じる。お互いが少し目線を相手側にずらすということだけでも分断を乗り越える力になると思う。
前章で出てきた「一緒につくる」で得られる共通理解にはこういった相手の目線を理解するということも含まれているのだなと、この感想をまとめている中で気づいた。 現職では幸運なことに利用している人から直接話を聞く機会が年に数度あるが、自身のモチベーションアップが主の目的となっていて、聞いた意見は「こんな話が出てました」という報告だけになってしまっていた。これが自分の視座の低さであり、今後は自分がPOの立場だったらこの意見を聞いてどうアクションを起こすかということまで考えるようにしていきたい。