- カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで 単行本（ソフトカバー） – 2018/2/7
- チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで 単行本（ソフトカバー） – 2020/2/17
この本を読む前、なんとなくタイトルからチームリーダーとはこうあるべし、チームはこうマネジメントすべし、といった要素を、カイゼンジャーニーの延長線として語っているものだと勝手に思っていた。 すこし言い換えると “チーム” にフォーカスしたもので、チームのよくある問題との向き合い方のようなものだと思っていた。
ところがまず1周読んでみて、そうではないことがわかった。 これはプロダクト開発をチームでやっていくことにフォーカスしたものだ。
確かに、チームのよくある問題との向き合い方のようなガイド・プラクティスもあるが、それが主ではなく、こうすれば成功できる、というものでもない。 その段階での問題は解消されるが、そのうちに次の問題へと直面する。プロダクト開発は問題だらけだ。 もちろん、その知識や経験を持っていたほうがいいのはそうだろう。似たような問題に遭遇したときに、どのように切り抜けたかを参考にして、戦っていくことができる。 問題と戦っていくのはリーダーだけじゃない、チームだ。問題に気づいた人が行動を起こして、チームで問題と戦っていくんだ。
多くのソフトウェア開発現場において、スクラムあるいはそのような何かをやっていると思う（私の環境でもスクラムをしている） あれが解決できるのはプロジェクトの進め方で、プロダクト開発は解決しない。 例えば、大きなソフトウェアを作っていて、複数チームに渡って機能を作ろうとしたときに同期を取ったり、共有をしたりすることが難しい。 大規模スクラム、LeSSを取り入れることで解決するかもしれないが、プロダクトとしてはそれでいいのだろうか。
これはこの本を読む以前からの個人的な考えではあるが、チームや機能が分かれているからといって、想定されるユーザが違うとは言い切れない。一つのプロダクトをやっている複数チームなのであれば、まずは一貫してひとりのユーザを見るべきだ。 その上で各チーム・機能が詳細にするのは構わないと思う。ただ、詳細を決めて、そこに向きすぎるとやはりそこで分断がされてしまうので、ある程度のタイミングで、ふりかえり・むきなおりが必要だろう。
本書では、プロダクト開発の一連の流れとして、リーンジャーニースタイル、というものを提唱している。
具体的にはこのようなものだ。
- 目的地を定める
- ジャーニーを設計する
- ジャーニーでのミッション、チームのファーストを決める
- ジャーニーのバックログを整理する
- チームのフォーメーションを決める（プロダクトオーナー, 各種リード=先導役などを設ける）
- ジャーニーの遂行 = スプリントの実施
- ふりかえり、むきなおりをしてジャーニーを考え直す → 3へ
ジャーニーは旅路だ。少し大きな規模の旅行では様々に計画をすると思うが、それと置き換えても同じことが言えるだろう。
本書の中で、蔵屋敷、という名前のコーチポジションの人が登場する。 この人が仕事を始めるときには、型を使うことはあっても、型にハマった最適化をせず、状況に応じて、型や自分たちの動きを変えていく、という様子には私の背中も押される。
特にこの一言はとても印象強く残っている。
「俺たちはなぜここにいるのか？スクラムをするためか、それともプロダクトを世の中に届けるためか？」
本書で出てるプラクティスもそのまま同様に使おうとしてもチームによってうまくハマらないだろうと思う。 背景的な状況はもちろんのこと、登場人物の性格や考え方、動き、役割、またはやっているプロダクト構成も違う。成功体験とまったく同じ状況のチームなんて存在しない。 道具や考え方は共有して使えるだろうが、こうやったからうまく行った、は基本的には通用しないものだと思いたい。
本書の最後にもあるが、現代において、プロダクト、ソフトウェアは様々な分野に広がり、高度で複雑化している。 そこにはこうやるといいといった万能な正解はないし、正解に向かう状況も道具も異なるし変化している。 高度で複雑なものを正しくつくり、その価値を提供していくためには「ともに考え、ともにつくる、そしてともに超える」を現場でやっていくことが大事なのだろう。