「それで、あなたは何をしている人なんですか？」ふたたび
一人のエンジニアがアジャイル・スクラムを通しより良い開発へ踏み出していく様を感情たっぷりに描き、大きく反響を呼んだ『カイゼン・ジャーニー』の半続編。今度は個人ベースではなく集団、グループではなくチームとして、また複数チームの集合として、プロダクト開発へ挑む中でのチームのあり方、正解のない世界を進むやり方を描いています。
2020年2月のデブサミでは著者の市谷聡啓さんの講演を間近で拝聴する機会があり、その日に本書も先行販売していました。物理にしようか電子にしようか、そういえば前作は自分もブログに感想を上げたりしたしいっそご本人のサインでも……なんてうろうろ思ってたらサイン会が長蛇の列で、迷ってる間に物理本も売り切れてMyジャーニー挫折。時が経って電子書籍版でじっくり読むことができました。(おっとなお、本エントリでは一部ネタバレありでございます)
チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで
- 作者:市谷 聡啓
- 発売日: 2020/02/17
- メディア: 単行本（ソフトカバー）
- 「それで、あなたは何をしている人なんですか？」ふたたび
- 第1部 : 僕らが開発チームになるまで ― チームのジャーニー
- 単一チーム 基本編
- 単一チーム 応用編
- 第2部 : 僕らがプロダクトチームになるまで ― 複数チームによるジャーニー
- 複数チーム 基本編
- 複数チーム 応用編
- まとめ：これからの時代のチームのあり方を学べる本
第1部 : 僕らが開発チームになるまで ― チームのジャーニー
単一チーム 基本編
第1話 グループでしかないチーム
本作の主人公はちょい名前が読みにくい太秦(うずまさ)君。エンジニアとして既に会社も4社目。人間関係も良好だった1社目、しかしコンフォートゾーンから脱出してさらに成長せねばと前向きな転職理由で外へ行った……という今風の設定です。IT業界内の立ち位置にもよりますが、どんどん転職しちゃうんだな～と思います。そして外へ行ったは良いが、どこもまともにチーム開発できているとは言い難かった……というあたりがリアルです。
前作の『カイゼン・ジャーニー』はAnP社という会社が舞台でいろいろ設定がありましたが、本作の舞台は創業まだ5年、社員も30人程度のベンチャー企業。SI中堅企業の子会社だが中身はほぼ独立。開発者向けの様々なツールを開発していますが、ツール開発の複数プロジェクト群も注力があったり中止があったり、まだまだ試行錯誤している様子が伺えます。
太秦(うずまさ)君はタスク管理ツールのプロジェクトのリーダーを突然任命されますが周囲の反応もバラバラ、前任者も既に不在ということでヤバイ雰囲気が漂っています。
プロダクトオーナーの砂子さんが何気に『カイゼン・ジャーニー』と同じ人。そしてチームのアジャイルの師となる人が蔵屋敷さんで再登場しています！ 相変わらずのぶっきらぼうさで「君は、まだチームとは何かを知らない」とかクールにキマッちゃっています。この人がもっと絡みやすかったら、最初から諸々解決しちゃうんじゃないか……？とつい思ってしまいますが物語の役割上仕方ないですね。(笑)
解説パートではチームとグループの定義、チームになるための４つの条件が解説されています。
- チームの目標を揃える
- 共通の目標を認識する
- お互いの持ち味を把握する
- 協働で仕事をするためのやり方を整える
メンバーがお互いを知るために付箋をペタペタ貼っていく『ドラッカー風エクササイズ』、各自の得意分野を表にする『星取表』はよくアジャイル関連書籍でも見るところ。前作ではAWS上で動くRuby on Railsアプリでしたが、今回はプログラム言語ではGo言語が登場します。前作はフロントエンド周りは曖昧でしたが、本作ではVue.jsが採用されているのが明確に書いてあってオッと思いました。
登場人物では「皇帝」として君臨している嵐山氏がGo言語はエースと書いてありますね。この人がタスク消化率が高かったのは、結局Go言語のスキルが必要なタスクが多かったのかな……？と邪推します。
主人公君の太秦君はエース級の能力はないものの、できることの幅が広く、何気に3社分の広い経験を積んでいるのが分かります。
またチームで起こりやすい問題として、どれも現場あるあるな問題群が最初に言語化してあるのが良いですね。
第2話 一人ひとりに向き合う
さっそくチーム開発を始めるメンバー。しかし実質まだ「グループ」でしかなく、みんな得意分野も違います。タスクをどんどん潰していくだけの日常で「塹壕の中で開発している」というメタファーがリアルです。僕もいつもそんなことしてるわけではないですが、前に炎上プロジェクトに入った時は確かにこんなだったなあ……と思い出します。
例によって蔵屋敷さんのエモワードで、状況を変えられるのは気付いた人間だけだ、ハンドルは自分で握れと言われた太秦君はまず状況作りでミーティングの場を設け、ふりかえりで３つの問を投げかけていきます。
まず状況作り、ふりかえりで3つの問。
解説パートではリーダーシップにも実はいろいろあるということでパターンの特徴を解説。チーム開発の出発のための問として、
- 自分はなぜここにいるのか(個人のWhy)
- 私たちは何をする人なのか(チームのWhy)
- そのために何を大事にするのか(チームのHow)
を深掘っています。
第3話 少しずつチームになる
3つの問の答えもメンバー毎にバラバラだったチーム。体調不調でリタイアして3日経過、課題などの情報共有不足、アウトプットの品質のばらつき、メンバー間の感情的な衝突などなど、上手く回っていないプロジェクトあるあるな現象が噴出します。蔵屋敷さんは「スクラムは早い」と言い出し、チームの機能性向上ということでまずは段階を分けて、短く小さい一巡のサイクルを繰り返していくことに……
解説では理想と現実の差分を取って、段階ごとに到達したい状態を定義し、各段階で振り返りや未来のむきなおりをしながら進めていくやり方を解説。最初に決めた段階ごとの目標は必達でなく、進路調整して後から変えて良いのがアジャイル的ですね。
難しい話として「タックマンモデル」「成功循環モデル」を取り入れた形として、時間とともにチームの機能性・成果が上がっていく様子をチーム・ジャーニーのフレームとして図示しています。形成期～混乱期～統一期という期間があって、子育て世代としては何やら子供の教育の本みたいで面白いです。
またドラッカー風エクササイズで、自分の不得意なこと/仕事のしてしまい方/地雷/昔期待に応えられなかった事件 というネガティブ面の事項も上げることが取り上げられています。最近読んだ「#ここアジャ」本でも出てきました。本書では非公式ながら「ドラッカー風エクササイズB面」というネーミングがつけられています。ふと思いましたがA面/B面とかいまの20代の人にはもう馴染み薄そうですね……
第4話 チームのファーストを変える
ワンマン独裁政権ながらもタスクはバンバン片付けて成果を出していた皇帝氏はここでチームから退場してしまいます。合宿によってリフレッシュしたチームは気持ちを切り替えて再スタート。
しかし今度は、なんでも話し合ったりして速度が落ち、パフォーマンスが出なくなってしまいます。悩んだのちに主人公氏は「プロダクトファースト」への方針転換を決断。しかしメンバーからの声には信頼が見られるようになります……。
解説ではチーム構造の話。「個人商店」「塹壕」「烏合の衆」「仲良しこよし」パターンが同じ図を使ってそれぞれ何が足りないのかを解説しており、これがとても腑に落ちます。
チームでの「ゴールデンサークル」という楕円の図ではWhyでミッション定義、Howでどう実現するか、Whatで具体的なタスク、そして楕円の外側には、Whenで期間のタイムボックスを定義すると良いという話をしています。
関連して世の中のフレームワークでPDCA:Plan-Do-Check-Action、そしてOODA: Observe-Orient-Decide-Act ループについて解説しています。後者のOODAは何が起こるか予測がつきにくい状況向け、空軍パイロットに採用されているやり方とのこと。観察して方向を見定めて、決定してから最後に行動。そして決まった行動を繰り返すのでなく、方向性は適宜修正するというのがポイントですね。
PDCAの図はIT系非IT系問わず会社の教育資料などでもよく見かけるもので、自分的にもお馴染みです。VUCA(変動性/不確実性/複雑性/曖昧性)の時代ともいわれるこの先の2020年代、やはりOODAの考え方が大事になっていくのかなあと思いました。
単一チーム 応用編
第5話 チームをアップデートする
リスタートしてプロダクトファーストで走り始めたチームは開発速度も上がり、状況は好転しました。しかしよく見るとそうではなく、ふりかえりで問題が出ない問題があったり、フロントを突き進んでいるメンバーがバグを軽視していたりと問題が隠れています。書籍でよく見る「割れ窓理論」がメンバーの口からも出ていますね。
新しいCSSフレームワークを導入後共有してないなど、あーこれエンプラ開発だとあまり起こらない状況だな～と思います。技術スタックが古いとメンバーから不満が出る辺りは先進的なプロダクト開発っぽいですね。
ではよそを見ようということで、マウンティング気味(笑)な他のチームを見学した一行はチームの方向を見出し、スクラムに取り組むことにします…
解説では過去の自分達とのDIFF、現在で並行して進んでいる他のチームとのDIFF、未来の理想の自分たちとのDIFFの3種類の差分の取り方について、特徴や差分、観点を詳しく解説しています。他のチームとのDIFFではそのまま取り入れてもうまくいかないので、背景や前提を捉えるようにしよう、というあたりはなるほどと思います。
第6話 分散チームへの適応
チームはスクラムに取り組み始めますが、頼みの綱の蔵屋敷さんが相変わらず冷たいです(笑)。そしてプロダクトオーナーの砂子さんからは新しいバーンダウンチャートの機能を入れたいとの要望が出て、いきなり新メンバーがジョイン。保育園児＋新生児を抱えたリモート勤務の子育てエンジニア、そして開発者コミュニティ経由で連れてきたベテランのフリーランス。増強するのはよいのですがこの砂子氏は「人月の神話」は読んでいるのだろうか…などと思いつつ、案の上タスクの投げ合いが始まったりミーティングの時間で悩んだり、チームは回らなくなっていきます。
わかりにくい褒め方をするツンデレ蔵屋敷さんの助言で面々はチームの分断を考え直し、新たなチームフォーメーションでやっていくことに…
解説では時間の分断/経験の分断/場所の分断の3つについて問題点を語り、分断下の制約を乗り越えるチームフォーメーションとして「雁行陣(がんこうじん)」が紹介されています。テニスの陣形でもあり日本に伝わる戦の陣形でもあり。作中に8つの陣のひとつとして掲載されているのは、どうも武田信玄のもののようですね。
プロダクトの「背骨」とメタファーされる必須の重要機能は設計能力があってレールを決められる「プロダクトリード」が先行する前衛として開発。「お肉」とメタファーされる背骨に付随する一個一個の機能は後衛のチームメンバが開発。コミュニケーションの媒介者としてチーム分断の統合を担う、リーダーとは別に役割として「チームリード」の役割を持たせるというものです。
読み進めながら、このプロダクトリードって開発標準やルールを先行して定めたりする人、アーキテクチャを決めるソフトウェアアーキテクト、重要機能を担うリードエンジニアとかそういう感じかな？と思っていたらだいたいその通りでした。
プロダクトリードは細かいコミュニケーションは不要で突き進むので場所が分断している人向け。チームメンバーは独立した粒度の小さいタスクを開発していくので時間の分断がある人でも大丈夫。そしてチームリードは全体の媒介者なので分断のない人向け、というのは言われてみると納得します。
「背骨バックログ」「お肉バックログ」という言い方も面白いですね。プロジェクト完了時に打ち上げで焼肉を食べたくなりそうです。
第7話 チームの共通理解を深める
社内の他のチームが作っているチャットツールとドキュメント作成ツールの方が人気が出ているとのことで、焦ったPO氏から太秦君のチームにはバンバン機能追加が飛んできて突然ボットツールまで作ることに。頼みの綱の蔵屋敷さんも別チームに移ってしまうことになります。
主人公君は「仮説キャンパス」を使ってチームでプロダクトの価値を再確認しようとしますがあまりうまくいかず、チームはバラバラの危機に……フリーランスの壬生さんの言動が無責任気味に見えますが、社員でなく雇われのフリーランスや外部の会社の人ならまあこうなるよなあという気もします。
解説ではアジャイル関係なくよく起こる分断について解説。仕事の透明性を高め、チームの共通理解を深める原則として「見える化」「場づくり」「一緒にやる」を紹介、それぞれの具体的な作戦を図式化しています。
開発チーム向けの解法としてはインプットとなるタスクはすべてバックログに整理、カンバンやチャートで見える化、場づくりには頻繁な状況同期で頻度が高いほど透明度が高くなる……と、やっぱりアジャイルの基本テクをしっかりやっていくしかないんだなあと思います。プロダクトチーム側でも対になるこれらがしっかり整理してあるのがよいですね。
第8話 一人の人間のようなチーム
迷走するチーム。太秦君は最初に言われた「自分たちのハンドルは、自分たちで握ろう」の言葉を思い出してメンバーを再集結させ、３つの問いへのむきなおりをすることに。そもそも自分たちで使っていなかった開発対象のツールを自分たちでも使い、自分たちが欲しい機能を作っていくことにします。無事に入社して１年も経過。PO代行の仕事も終わったメンバーの有栖さんが初めて笑顔を見せて、ここへ来てヒロイン化の兆しが……じゃなくて、「新たなる希望」作戦で未来が明るくなってきます。A New Hope であればやはりこれはスター・ウォーズのEP6タイトルのネタですね。
解説では再出発のための３つの問いでは「チームとしてのWhy」が最初に来るという話に始まってプロダクトオーナー代行の話、そして一人の人間としてのプロダクトチームの話を解説。プロダクトオーナーが担う仮説検証が人間の頭の部分、アジャイル開発でスクラムチームが担う部分が人間の体……というメタファーは、確かに言われてみると一体感があります。
![スター・ウォーズ エピソード4 新たなる希望 リミテッド・エディション [DVD]](https://m.media-amazon.com/images/I/51F8RPYXDFL.jpg "スター・ウォーズ エピソード4 新たなる希望 リミテッド・エディション [DVD]")
スター・ウォーズ エピソード4 新たなる希望 リミテッド・エディション [DVD]
- 発売日: 2006/09/13
- メディア: DVD
第2部 : 僕らがプロダクトチームになるまで ― 複数チームによるジャーニー
複数チーム 基本編
第9話 塹壕の中のプロダクトチーム
偉い人の鶴の一声でタスク管理/チャット/ドキュメント作成の３つのチームが統合、ひとつのプロダクトとして作っていくことになってしまいます。主人公の太秦君は今までの4thチームのリーダーは続行、ステアリングコミッティに入って全体のプロダクトリーダーになることに。別チームリーダーに同期組もいるものの5thチームと6thチームも個性バラバラ、いきなりこんな役になったら誰でも不安しかない状況でしょう。
「塹壕」というキーワードがまた出てきたのは、一人でなくチームの単位でまたバラバラの先が見えない状況になっているからなんですね……
解説ではこれもよくありそうなチームに状況が行き渡らない話を丁寧に言語化し、情報流通の経路づくりの話をしています。組織論の話でよく出てくる「コンウェイの法則」も出てきます。
- 全体ミッションの情報は全員で共有
- 戦略の情報はマネジメント層(ステコミ＋各チームのリーダーレベル)で共有
- チームのミッションと戦略の話はステコミを除き、チーム間でも共有
- 目的や目標に関するWhy寄りの情報は広く全体に
- 実現手段のHow寄りの情報は狭く開発の当事者メインで
- 最前線の情報をチームから全体にフィードバック
これらの話が図入りで語られるのですが、確かに図で見ると分かりやすいですね。前作『カイゼン・ジャーニー』で印象的に使われた「越境」のキーワードが徐々に重要になってきます。
第10話 チーム同士で向き合う
まったく連携の取れていないチームは互いの壁の向こうの状況が分からないままタスクを投げ合ったり逆に余計な遠慮をしたり、スマホいじりおぢさんが低レベルと評する状況です。
主人公の太秦君はチーム同士の出会いを再設定しようとリーダー同士の会を開き、情報の伝達経路を設定。さらに職能ごとにチームをまたいだリード別同期の集まりを作り、PO同士、テクニカルリード同士も集まるようになります。状況はぜんぜん大丈夫でないという重要情報がやっと行き渡り、しかし太秦君は希望を持ちます……
解説では複数チームでの構成、越境の話。１つのチームに1人のPO、複数のチームに1人のPO、複数のチームにそれぞれPOの構成を解説。
そして「リーダー」は役職としての言葉、状況に応じて行動し前進して先導する役割としては「リード」という言葉を定義してリード・パターンを述べています。「テクニカルリード」は割といそうですが、「仮説検証」「テスト」「デベロッパーエクスペリエンス」「(重要なXX機能)」などにもリードを作れるんですね。こうしてチーム、リード、代表者のそれぞれの集まりでの情報の同期の様子が図で示されており、図で見ると明快に分かります。
エンタープライズな会社だとリーダーやマネジメントする人、キーマンなど各集団の上層の人を集めての会議なんてのはよくやるので、これが本書での「代表者の同期コミュニケーション(リーダー会)」に相当すると思います。しかしリード別の集まりというのはあまり見ないので、これは新しい発見でした。
第11話 チームの間の境界を正す
状況が良くなってきた開発ですが、4thチームは優秀な新メンバーが加わって他チームからのタスクに専念しているのにも関わらず速度が遅くなってきます。メンバーが他のメンバーを称賛し、チームを見渡して自分たちで決めようとする描写があって何気に良くなっていますね。
そこで他チームからの依頼対応の運用班と開発班を別にするかと思いきや……他チームからの依頼対応は時間上限を設け、また役割は交代でやる体制に。SREのような仕事はチームをまたぐのでよそからの依頼が多い……というのはなるほどと思います。
解説ではまず境界の設計で、同時に処理して行けるタスクの上限数(WIP: Working In Progress)を設定するやりかた。そして５つの作戦を解説しています。
- リソース配分に意思を込める：来た順でなくチームの現状に合わせて配分を決めておく
- 番頭の輪番化：交代でやって、あの人しかできない問題(=トラックナンバー１)を減らす。番長と呼ぶやり方も。
- 順序付けの基準を合わせる：メンバーが全体のミッションを踏まえながら優先度を決める。
- チーム外部への表明：やり方を他のチームに宣言しておく。
- チーム間の振り返り：各チームから集まって行う。
第12話 チームの境界を越えてチームをつくる
今度は隣の5thチームが遅れて統合や移行がままならず、リーダー会は険悪な空気です。細かいネタとしては主人公の太秦君のSlackアカウントが @uzuuzu(うずうず) で何気に可愛いのが分かります。(笑
今のチーム構成ではやっていけないことを認識した太秦君は、貴重なメンバーを差し出して横断チームを作ることを決断。他のチームも重要なメンバーをアサインして覚悟を示し、SWATチームが活動することになります。そして4thチームには新メンバーとして……万福寺さん a.k.a. "和尚"がジョイン。
き、き、キター!!（ネタバレですが）前作『カイゼン・ジャーニー』の後半でも登場、その描写から歴戦のプロである様子がビンビンに伝わってきたベテランRubyプログラマーの和尚さんですよ。本書でもブルドーザーのようにタスクを潰しまくっていて、これで勝つる！となります。
残念なのは前作で和尚さんとペアだったマイさんが一緒に出てこないことですが……蔵屋敷さんがようやくデレ期に入るのでよしとします。(違)
解説では通常チームとは別に作られる、こうした横断型チームの話。「専門特化型チーム」がアーキテクトやUXデザイン、SREなど専門技術のある永続的な集団。「状況特化型チーム」が移行や共通基盤部分などの開発というように、状況が終わったら解散する有限の集団ですね。
こうした横断型チームによく起こる問題や結成方法、運用方法まで図と共に詳細に述べられています。こういう状況は実物を見たことがないので、やはり実体験あってこそ書ける貴重な話だなと思いました。
複数チーム 応用編
第13話 チームとチームをつなげる
統合化の大仕事が終わり、横断チームも解散して元通りに進んでいく一同。しかし情報の共有ができていなかったり山積みのバックログが残っていたりで前途多難です。重複した機能を作ってしまったことからリーダー会は険悪な雰囲気になり、あわやという所にまた新たな登場人物が。
キター！（またまたネタバレですが）前作『カイゼン・ジャーニー』でも登場したアジャイルが分かってる人、西方さんがまたまた助っ人として現れます。読者の一部には中途半端な関西弁が気になるという鮮烈な印象を残したお方です。本作での関西弁がどうなのかは標準語圏の自分には分かりません(笑)
KPIに追い立てられていた現象を西方さんは関西弁で一刀両断、面々はプロダクトのユーザの行動フローを全チームで正しく理解して、向き直っていこうと試みます……
解説ではこの行動フローの分析を実例を挙げて説明。ぱっと見開発チームが作業としてやることに誤解しそうですが、開発中のタスク管理ツールを実際に使うユーザーが時の流れと共にどう使うかをかんばん方式で整理しています。状況があってその都度行動し、そこに問題と解決策があり、利用する機能があり、機能を使う上での障害もあれば解決策もある訳ですね。
後半ではよく見る線表を使ってマイルストーンを見える化したり、ユーザーにとっての価値の計測の観点を述べています。観点は２つあって、一定期間で創出できた価値の数をスループット、もうひとつは価値創出までのリードタイムがどれくらいかというもの。
第14話 クモからヒトデに移行するチーム
偉い人の異動があったりする中、本書ではところどころ名前は出てきていたものの実体が謎だった、テスト管理ツールチームの濃いメンバーが明かされます。
なんとなく和尚さんの登場が伏線のような気がしていたのですが、期待に応えてモニョモニョ一同が次々と登場ですよ。なんかもうアベンチャーズが全員集結したところにスパイダーマンまで加わってフォオオ!!!!みたいな感じにエモ度が上がっていきます。(どんなだよ)
そして社長からのプレッシャーが上がってくる中で運営の立て直しとして、別チームでやっている品質向上の施策をそのまま全チームへ適用のお触れが。コードレビューの申請ドキュメントが別途必要になりテストケースもドキュメントが必要になるという……あ～これいかにも旧来型のSI企業の開発できない人が考えそうだな～と残念なお気持ちになります。
復活した蔵屋敷さんがそれぞれの現場の文脈を捉えなければそのまま適用してもダメだ、と一刀両断して他のアイデアを採用。そして今度は太秦君がリーダー解任、泣きそうな主人公。しかしクモ型組織(強いリーダーが引っ張る中央集権型)からヒトデ型組織(それぞれが自律して動く分散協調型)になるまで、もうこのチーム群は成長してきているんだと語られます……
解説ではリーダーやマネージャー層の在り方として、組織全体を俯瞰する観点、チームや現場の詳細を見ていく観点の両方を行ったり来たりしながら、意思決定も時間の観点を加えた立体の中でやっていくとよいという話を例を挙げて解説しています。
また、弊害をもたらす過度な標準化でなく「共同化」がよいという話では、合宿など時間を場所を共にすることを多くすることで互いの理解が深まる、また仕事を共にすることでも理解が深まり、人に説明することで自分の学びも深まる。「共同化」の先には「協働化」、互いを理解してミッションを共有し、一体感の中で進んでいく……と、まさに「ともに考え、ともにつくる」の思想が語られています。
この「標準化」というワードはエンプラ世界の開発でもよく使うし、僕も今まで何度も担当したことがあります。もちろんやる時は現場の視点に立って標準化するしやりすぎのルールは作らないのですが、この標準化が上手く行っていない現場というのも過去あちこちで見てきました。
協働とか協創というワードはあちこちで目にします。既存のやり方に囚われず、既存の名前にも捕らわれず、思考を変えていかないとなと思いました。
そして境界の向こう側にいがちな相手の背景を理解し受け止める越境も「対話」であり、チームや組織を超えて対話できる機会として「ハンガーフライト」の名がまた登場します。イベントや勉強会で事例を共有したりするあれですね。『カイゼン・ジャーニー』のラストのエモ度が高まっているあたりでもこのハンガーフライトが出てきたのを思い出します。
第15話 ミッションを越境するチーム
今度はラスボスのシャチョーさんが自ら登場、既存のプロダクトバックログがバンバン捨てられて社長作成のバックログがどんどん積まれ、たりチーム解散の危機が迫ったり大変なことに。この社長は実際のコードまで覗いて技術的負債も指摘しているような描写があり、社長になる前はエンジニアとしても凄い人だったのかな？と邪推します。
そしてイラストではジャケットを着ているのですが、んん？なんか髪形に見覚えがあるような……と前作の登場人物を確かめると……またやってくれましたねこんなん目から汗が……となります。
太秦君はスプリントを中断し焦りにかられますが、そこで社長との会話が。社長自身にもどうするのがよいか正解があるわけではないこと、持ち場を超えて同じものを見るために、自分から超えていくしかないのだ……という、クライマックスに向けたエモ空間が形成されていきます……
解説では『カイゼン・ジャーニー』でも出てきた視座と視野の話。「視座」は目的に沿った自分の立ち位置のどこから見るかということで、組織だったり事業だったりプロダクトだったり。
「視野」は何をどこまで見るかということで、自分のチーム内だったり他チームだったりユーザーだったり。
この視座×視野の２軸で広げて全部を把握できれば苦労しないですがそうもいかないので、２軸をその都度移動させながら見ていくのがよい。しかし目の前の最適化の視点に集中しすぎていると移動できないので随時見直す。もうひとつは役割が固定化していると移動しにくいので「リーダー」でなく「リード」をチーム内で担当を交代していく、プロダクトオーナーも民主化していくと良いと述べています。
もうひとつ、何かを見る際の観点について。視座の高低や視野の広い狭い、他の要素も多次元にいろいろある。すべてを人間一人で賄うのは難しい、だからこそ二人以上のチームで取り組み、問い続けていくのだ……と述べています。
第16話 ともに考え、ともにつくるチーム
社長の元に乗り込み、疲れた顔で戻ってくる太秦君に対し、他のチーム含めた一同が待ち構えていて出迎えるという最終章のエモ空間が広がっています。やる気を回復した面々は最後のジャーニーとして、大掛かりなユーザ―検証とフィードバックをやっていくことを決意。話を聞いた社長からのどうしてここまで来れたかという問いに、太秦君はチームがいたからこそ、ともに考え、ともにつくることができたのだと答えます……
最後の解説は仮説検証について。仮説キャンパスを作り、立案と検証を繰り返して確認していくものです。アイデアが形になって最低限の機能で公開するまでのリソース横軸、縦軸リアリティのグラフ図が「現実歪曲曲線」という何やらスティーブ・ジョブスっぽい名前についています。
ここで曲線の上側、なるべくリソースを掛けずに現実に動くものを作って使うのが良いということで、ノンコーディングやプロトタイピングツールが出てきます。最近ちょっと触ったのですが、No-CodeやLow-Code系のツールというのはこのへんにも使いどころがあるのかなと思います。
また「重奏型仮説検証」として、仮説検証をリードする人、開発チーム、実際に使う人、様々な人を巻き込んでそれぞれの人が解釈して検証していく民主的なやり方が解説されています。
そしてエピローグでは終わりなきジャーニーとして、ストーリーの方ではまたまた大きな変化と旅立ちが。主な登場人物それぞれが言葉をかけてきてくれるのがエモいですね。
自分たちは何をする人なのか？という問いへの本書のひとつの答えは「ともに考え、ともにつくる」。チームがいて互いに支えあえるからこそ、この永遠の問い、変わり続ける問いにも答えることができ、そして正解のない不確実性の中をジャーニーはどこまでも進んでゆけるのだ……ということでしょうか。
そして読了後にプロローグを見返すと、細かいところではちゃんと「9人」と書いてあるんですね。くっやられた……最初からしっかり計算されとる……今回もエモい締めが決まっとるやないか……
まとめ：これからの時代のチームのあり方を学べる本
ようやく積読になっていた本をしっかり読むことができました。ネットでも大きく反響を呼んだ前作『カイゼン・ジャーニー』は感情への揺さぶりが大きく、2018年に読んだ本の中でMOSTエモい部門の第1位を獲得しています。(自分の中ではｗ)
本作は前作よりは理詰めな、かっちりとシステマティックに作られた印象を持ちました。構成が決まっていて基本編応用編とそれぞれ語りたいことがあり、そこで使える技があり、それに繋がるような事件がストーリーでも語られて……という感じ。
とはいっても本作のストーリーも特に後半ではエモさがどんどん高まっていきます。特にモニョモニョが次々登場してくるあたりは、くは～続編の楽しみと言ったらこれだぜ！となります。けっこう登場人物数が多いので、両書の登場人物をチェックしてから読み進めるとよろしいかと思います。
豊富なご経験に裏打ちされたストーリーの現実味は本作も変わらず。僕もリーダー経験はあるので、あーこういうチーム(というかグループ)間の対立とか、組織や集団をまたがった見えない境界とか、人がたくさん集まると起こる現象とか、癖の強い人とかいらんことを言うエライ人とか、あるよな～と思います。けっこう胃が痛くなりそうな会議シーンが出てきますね。(笑)
本作のストーリーで開発しているのは自社製ツールですが技術的なキーワードはあまり出てこずにチームマネジメント周りの話が主なので、もう自社開発とか受託とかSI事業とか運用とか関係なく、いろんな人にとって真実味があるのではないかな？と思います。
主要なアジャイルプラクティスはさすがに前作でだいたい出てきたので、新しく出てくるキーワードは組織論やリーダーシップ論、チーム論、大規模アジャイル、プロダクト開発などなどが多く、自分の知らない世界が特に２部から見えてきました。
アジャイルやスクラムに興味があったり、TDDの実践やアーキテクチャの改良とかCI/CD環境の整備などなど個人での技術面に主軸を置いている人には前作『カイゼン・ジャーニー』の方が刺さるでしょう。逆に人とのコミュニケーションに悩んだりチームとしての仕事の進め方、リーダーとしての悩みなどなどを持たれている方には本書が刺さるのではと思います。
ストーリーはあくまで架空なので現実とは違う、という声も前作からあり本作も同じなのですが、まあそこはIT小説なのでしょうがないですね。特に後半、複数チームの話になってくると、同じ会社の同じフロアなのかほぼ同じ場所で、複数のチームがそれぞれでアジャイル開発を進めていてあれこれが起こっていきます。
こうした並行アジャイルの風景をもう実現している会社さんはそれはそれで凄いのですが、なかなか羨ましい眺めでもあり、状況によっては実現しづらいことでもあります。僕がいるエンタープライズ開発の現場ではそもそも本格アジャイル導入がまだまだなので、こんな風景の実現は当分先の未来だなーとも思いました。
推敲を重ねたであろう解説の文章、明快な図解は本作でも豊富です。ストーリーや解説の最初を読んでいるとなんとなーく言いたいことは分かるようなぼや～っとした解像度の低い状態の事柄が、クリアな図や説明でスッと解像度の高い状態にピントが合っていきます。
こうした明快な絵にしにくい難しい事柄をきちんと言語化、図解化しているところ。逆に現場で起こりそうなことを抽象化やパターン化して汎用的に落とし込んでいるところはさすがだなと思いました。
巻末の参考文献では名前をよく聞く凄そうな本がずらっと並んでいます。あまり知らない本もけっこうありました。その一方で基本に返って、最近第2版が出た『達人プログラマー』もあったりします。
「それぞれの持ち場で。がんばれ、だよ。」 あのセリフをお互いにかけたくなる、静かに熱量を受け取れる本でした！
チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで
- 作者:市谷 聡啓
- 発売日: 2020/02/17
- メディア: 単行本（ソフトカバー）
ichitani.com teamjourney.link https://kaizenjourney.jp/kaizenjourney.jp
