アジャイル開発実践者・経営者の市谷聡啓氏が、「チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで 」と題して、スクラムやアジャイルを導入した現場で直面する開発チーム・マネジメントの問題に立ち向かう術、強いチームづくりの要点をストーリーで解説する一冊。
チーム開発をより良くやれるようにしていきたい、チーム活動の新たな学びを得たい方にオススメしたい本です！
この記事では、「チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで 」の書評＆要約まとめを紹介していきます。
本書を読もうか悩んでいる方は、ぜひチェックしてください。
- チーム開発をより良くやれるようにしていきたい人
- これからチームのリーダーになる人、なりたい人、またすでにリーダーを担っている人
- 今後、複数のチームをマネジメントする人
- チームのリーダーを支援する立場の人、チームメンバーの人
- プロダクトの企画者（プロダクトオーナー）で、開発チームと一緒にプロダクトづくりを行っている人
「チーム・ジャーニー」の内容・目次
この本は、プロダクト開発に挑むチームに向けて書きました。チームといっても、置かれている状況は様々です。まだ結成したばかりのチーム。すでに世の中に向けてプロダクトを提供していて、日々プロダクトの成長に向き合っているチーム。複数のチームで構成され、チーム間での連携が求められるような大きなチーム。チームの状況、段階に応じて直面する課題は様々で、求められることもまた多様です。
市谷 聡啓（「はじめに」より）
（〜中略〜）
この本では、一つのチームの段階的な成長を追うスタイルを取りました。最初は、一つのチームとして成り立つために必要な準備を整えていくところからスタートします。やがて、チームはその機能性を高めていき、問題のレベルも高まっていきます。本書の後半では、複数のチームの運営にも踏み込んでいきます。このように、あるチームの出来事を追い続け、読みながら追体験することで、作中のチームと同様に学びを深めていく構成を取っています。それはあたかも、チームの軌跡をたどる旅（ジャーニー）のようなものと言えます。みなさんがこの本の旅を経て、チーム活動の新たな学びを得られることを願っています。
本書の目次は、以下の通りです。
推薦のことば
・私たちは他者を必要としている｜宇田川元一
・その先へ！Beyond the Agile｜新井剛
第1部 僕らが開発チームになるまで─1チームのジャーニー
□単一チーム 基本編
・第01話｜グループでしかないチーム
・第02話｜一人ひとりに向き合う
・第03話｜少しずつチームになる
・第04話｜チームのファーストを変える
□単一チーム 応用編
・第05話｜チームをアップデートする
・第06話｜分散チームへの適応
・第07話｜チームの共通理解を深める
・第08話｜一人の人間のようなチーム
第2部 僕らがプロダクトチームになるまで─複数チームによるジャーニー
□複数チーム 基本編
・第09話｜塹壕の中のプロダクトチーム
・第10話｜チーム同士で向き合う
・第11話｜チームの間の境界を正す
・第12話｜チームの境界を越えてチームをつくる
□複数チーム 応用編
・第13話｜チームとチームをつなげる
・第14話｜クモからヒトデに移行するチーム
・第15話｜ミッションを越境するチーム
・第16話｜ともに考え、ともにつくるチーム
付録 リーン・ジャーニー・スタイルのプロダクト開発
チームづくりの要点をストーリーで学ぶことができるため、全16話を頭から読み進めていくのが良いでしょう。
10個の要約ポイント
チームとグループの違い
| チーム | グループ | |
| 存在意義 | 一人では不可能な成果をあげる （成果をあげるために必要な学習を自ら取り入れる） | 人の集合を外部から見分けやすくすることができる （つまり内側より外側基準の意義） |
| 主語 | わたしたち | わたし、あなた、彼・彼女たち |
| ミッション | チームの存在意義に直結する ミッションが共有されている | 個々の行動レベルにまで落とし込めるミッションにはなっていない |
| 役割 | ミッション遂行に必要な役割を定義し、お互いに補完しあう | 集団内での相互作用が乏しいため、役割分担を必要としない |
| コミュニケーション | お互いの関係性、個々の振る舞い、考え方が相互作用に与える影響に注意を払う | 相互作用ではなく、相互連絡になっている |
| プロセス | ミッション遂行のための最適化を自分たちで進める | 集団としてのプロセスではなく、仕事を受け渡すワークフローだけがある |
| ルール | 自分たちで決める | 外部から決められる |
はじめに、チームとグループの違いを理解しておくのは、大切。
段階的にグループからチームになり、そして強いチームに成長していくのは、まさにプロダクトの成長と同じですね。
プロダクトづくりと同じように、チームづくりも少しずつ育てていくことが重要。
現状、自分達のチームは本当にチームになっているのかを把握するところからスタートするのが良いですね。例えば、職場で実施しているミーティングのメンバーの話の主語をよく聞いてみる。その際、何か課題があったときに「わたしは〜」「あなた（○○さん）は〜」の主語が多い。自分達でどう課題を解決していきたいかの話まで深堀りができていない時は、グループ止まりの可能性が高いです。
チームになるための4つの条件
＜チームになるための4つの条件＞
（P14より）
①チームの目的を揃える
②共通の目標を認識する
③お互いの持ち味を把握する
④協働で仕事するためのやり方を整える
一人では出せない成果を上げるために、チームをつくりたい。
その際、チームになるための4つの条件と具体的な手法も本書に記載があり、大変参考になります。
私もチームビルディングのワークショップでよく利用している、「インセプションデッキ」や「ドラッカー風エクササイズ」「スキルマップ（星取表）」なども記載がありました。
今後、チームビルディングしたいと思う方は、参考にしてみてください。
ドラッカー風エクササイズ（A面・B面）
＜ドラッカー風エクササイズ（A面）＞
（P17より）
以下の４つの質問に対してチームで答えて、それぞれの得意技や価値観を明らかにするチームビルディングの手法。
①自分は何が得意なのか？
②自分はどうやって貢献するつもりか？
③自分が大切に思う価値は何か？
④チームメンバーは自分にどんな成果を期待していると思うか？
上記のA面は、チームの立ち上がり時期（最初期）に行うことが多い。
一方で、自分の不得意なことや苦手なことについてチームに共有しておくのは、少し仕事を一緒にはじめてお互いのことを知ってから行うことが多い（形成期）。
それが、以下のB面です。
＜ドラッカー風エクササイズ（B面）＞
（P54より）
以下の４つの質問に対してチームで答えて、それぞれの不得意なことや苦手なことについて共通理解し、チームの関係性の質を高めるチームビルディングの手法。
①自分は何が不得意なのか？
②どういう風に仕事をしてしまうか？（他人からも言われていること）
③自分の地雷（踏まれると爆発すること）は何か？
④むかしチームメンバーの期待に応えられなかった事件とは？
人は、期待されると、うれしいですよね。
他のチームメンバーから期待されたり、褒められたりすると、さらにチームに貢献したい！という思いになります。
チーム立ち上がり時期のチームビルディング手法に良いですが、チームがマンネリ化していたり、停滞感があるときは、一度試してみることをオススメします。チームが活気づくことでしょう。
「ふりかえり」と「むきなおり」
ふりかえりとは、チームの活動の「過去」を棚卸しし、そこから気づきを得て、次の行動の仮説を立てる行為のことである。
（P38,39より）
（〜中略〜）
むきなおりは、チームの「未来」に目を向けて、ありたい方向性を見定める。時に、状況が変わっていて向かいたい先が変わることもある。そうした方角を捉えた後、今何をするべきかを洗い直す。方向性が変わればやることの優先度も変わる可能性がある。まさに、ありたい方向に向き直るのがむきなおりという行為である。
「ふりかえり」の言葉は、よく多様していましたが「むきなおり」の言葉は新鮮でした。
チーム開発で、様々な環境変化やチームの状況変化が起きた際に「むきなおり」により軌道修正していくイメージですね。
チームの出発のための3つの問い
＜チームをスタートアップさせるときの3つの問い＞
（P141より）
①自分はなぜここにいるのか？（個人としてのWhy）
②私たちは何をする者たちなのか？（チームとしてのWhy）
③そのために何を大事にするのか？（チームとしてのHow）
＜チームビルドが進んで、むきなおりするときの3つの問い＞
①私たちは何をする者たちなのか？（チームとしてのWhy）
②そのために何を大事にするのか？（チームとしてのHow）
③自分はなぜここにいるのか？（個人としてのWhy）
チームの状態に応じて、問いの順番も意識的に変更されているのは、すばらしいですね！
チームをスタートアップさせるときは、そもそもチームの跡形もまだないため、個人のWhyから出発する。すでにチームのベースができているときは、チームのWhyから出発する。
3つの問いにより、メンバー間の認識の整合が取れます。
目的やゴールを誤解したり、整合取れずにバラバラで進めていくと、最短で成果を上げることができません。常にWhyからむきあうことが大切ですね。
チーム開発での最初の山場
開発チームの中でも、それぞれが自分の役割を小さく狭く捉えてしまうと、分断が起きます。こうした開発チーム内での分断、さらにPOとの分断を乗り越えることが、チーム開発での最初の山場といえます。それぞれの分断を乗り越えるためにチームで問いに向き合いましょう。
（P183より）
役割を越境するためには、そもそも境界があることに気づく必要があります。誰しも、自分で境界を置いているなど考えもしないものです。
向き合う問いは「自分は何をする人なのか？」です。
向き合う問いは、常に自問自答したり、チーム内で再確認するのが必要ですね。
一人では気づけないことも、他者からのフィードバックで気づくことが可能になります。
プロダクトとして成果につなげる３つの計測観点
計測したい観点は2つ。一つは、ある一定の期間あたりに創出できた価値の数。これをスループットと呼ぶ。スループットが低調な場合、チームの活動に何らかの問題が起きている可能性がある。
（P248, P249, P250より）
（〜中略〜）
もう一つの観点は、価値創出までのリードタイム。課題が発見されたり、プロダクトについてのアイデアが生まれたりしてから、実際にユーザーに届くまでの時間を計測しておく。この数字も、チーム活動上ボトルネックの存在を把握するための大事なヒントになる。
（〜中略〜）
最後に。価値の仮説が本当のところユーザーにどう受け止められたのか、利用についての計測を行う必要がある。こうした活動は仮説検証と呼ばれる。
この3つの計測観点は、良いですね。
スループットと価値創出までのリードタイムが良くなっても、本来の目的であるユーザーに価値を提供できていないと何も成果につながらい。
常に意識しておきたいと思いました。
マネジメントリードが心がけるべきタスクに対する2つの指針
①自分の目の前から自分がやらなければならないタスクを一掃する
（P262より）
（〜中略〜）
マネジメントリードは、チームが気づけていないことや直面する障害に先回りするのがその本分だ。自分の手元のタスクで手一杯となり、チームの先を捉えるというその役割を果たせていないとしたら本末転倒だ。まず、その本来の機能を成り立たせる必要がある。
②チームの目の前からやらなければならないタスクを片づける
（〜中略〜）
チームが大変だからといってマネジメントリードが全部タスクを拾い集めていては、そもそもチームに入ってくるタスク、抱えるタスクを誰が減らすのか。自分の抱えるタスクがないからこそ、チームのための活動ができるのだ。
優秀なマネジメントの方は、暇そうにしていながら、雑談の時間をいつも取れるようにしているなぁと思いました。
それを実現するには、チームのための活動ができるように、２歩、３歩先を見越した良い準備ができている。
また、視野が広く、コネクションもあることから、様々な課題に瞬時に適応できています。
標準化ではなく共同化
チームの置かれている状況、これまで積み重ねてきたこと、チームにある考え方や志向性（文化といえるだろう）などをひっくるめてチーム個別の文脈を無視した取り組みを強引に導入したところで、ハレーションを起こすだけだ（一方、まだ文脈が育っていないチームにとっては、自分たちの活動の型を決めていく足がかりになりうる）。
（P266, P267より）
（〜中略〜）
単一のチーム内にせよ、複数チームにせよ、それぞれの自律性を残しながら、標準ほど厳格なプロトコルを課すことなく、お互いの把握と歩み寄りを進めるためにはどうしたら良いか。ともにつくることだ。ともに仕事をする。時間をともにする。それがお互いの理解と、新たな方法の発見につながる。
これが共同化の意味するところだ。
チームは、生物（なまもの）です。
その時、その状況に応じて考え方、やり方を変えて行く必要があります。
まさに、ともにつくることが大切ですね。
本書では「時間と場所をともにする」「仕事をともにする」ことが紹介されていました。
それ以外に「体験をともにする」ことも大事な要素かと考えました。現在リモートワークやオンライン会議の促進により、時間と場所をリアルにともにできない環境にあります。そこで、何か一つのことで成功体験をともにつくることで、共通理解が得られると思います。その成功体験を積み重ねていくことで、さらにチームは成長します。
視座と視野で決まる視点
視座（高さ＝目的）と視野（広さ＝対象）の間で見るべきものを見る
（P278, P283より）
（〜中略〜）
同じ範囲を見ていても、視座が変われば見えるものも変わる（増える、広がる）
目的軸や対象軸によって、視点が変わるというもの。
例えば、ステークホルダーの社長とプロダクトオーナーや開発チームメンバーによって、それぞれの視座と視野があるため、話や認識が合わないことがある。
これは、役割による視座と視野の違いによるもの。
常に、視座と視野を合わせながら考えることが大切だと学びました。
3個の実践ポイント
むきなおりの問い
日々の仕事、活動をより良くしていくことに集中しながら、そもそも「この仕事で何を実現したいのか」そもそも「この仕事は必要なのか」という『むきなおり』の設定が大切だと感じました。
定期的にふりかえりの場を設定しているチームは、むきなおりの場も追加して実践すると良いでしょう。
自分たちに問う
問いの利点は、自分たちの主観や置かれている状況を超越して考えるように促せるところです。
（P288より）
問いに向き合うことで、自分たちが気づいていないことに気づくことができます。
「正しいものを正しくつくれているか？」の問いは、数多くの気づきを得られることでしょう。
絶対的な正しさはないので、自分たちで問い、考え続け、行動する。
これが大切な実践ポイントだと感じました。
仮説を立て、ユーザーを巻き込んで検証する
仮説を立て、検証し、新たな仮説を得る。この繰り返しを行っていく上で大切なのは、ユーザを巻き込むことです。
ユーザーを巻き込んだ検証には、ユーザーインタビューやアンケート、ユーザーテストなどがあります。
想定ユーザーは、正しい答えをもっているわけではありません。
「問題は何か？」について、ユーザーを巻き込みながら検証していくことで、「正しいものを正しくつくれているか？」の問いの答えに近づくことができます。
まとめ
本質は「ともに考え、ともにつくる。そして、ともに超える」こと。
そのために、それぞれの持ち場（役割）で、各自がんばる。
それにより、「私たちは何をする者たちなのか？」「自分は何をする者なのか？」の問いに答えることができます。
チームで新たな旅（ジャーニー）を続ける限り、終わりはありません。
逆境を超える、変化に強いチームをつくりあげるまでの壮絶なストーリーをあなたも作っていきませんか。
この記事を読んで興味をもった方は、ぜひチェックしてみてください！
今回紹介した本は、こちら↓
本書が気になった方は、こちらの本もオススメです！
