あらすじ
「ともに考え、ともにつくる」――スクラムやアジャイルを導入した現場で
直面する開発チーム・マネジメントの問題に立ち向かうすべ、
チームづくりの要点をストーリーで学ぼう！
【本書の特徴】
・現場のストーリーから、考え方とプラクティスを一緒に学べる
・単一チーム、複数チームなど、様々なチーム・マネジメントの問題を扱う
・日本の現場を前提にしているので、実践しやすい
・アジャイルをこれから始める人だけでなく、もっとうまく実践したい人にも最適
【本書に登場するプラクティス】
出発のための3つの問い ／ 段階の設計 ／ ドラッカー風エクササイズB面 ／ 割れ窓理論 ／
フォーメーション・パターン ／ コンウェイの法則 ／ 越境のデザイン ／ 重奏型仮説検証 ほか
【あらすじ】
チームによるプロダクトづくりができる環境を求めて
“太秦（うずまさ）”が転職した先は、デベロッパー向けのツールを開発、提供する、
小さなベンチャーだった。しかし会社期待のタスク管理ツールを開発するチームに
配属され、いきなりチームリーダーをつとめることに。
……とうていチームとは呼べない“グループ”（個人活動の集合）の状態から、
本当のチームになれたと思ったのもつかの間、経営陣はタスク管理を含めた
3つのツール統合を発表。太秦はそれらプロダクトの統合を行う開発リーダーを
任されたのであった。
チームとは何か？、チームのファーストとは？、分散チームへの適応など様々な
「単一チームの問題」、複数のプロダクト統合に伴うチーム間の断絶や衝突、
チームが上手く連携できないなど様々な「複数チームの問題」……これらを乗り越え、
太秦たちがたどり着いた「ともに考え、ともにつくる」とは？
※本電子書籍は同名出版物を底本として作成しました。記載内容は印刷出版当時のものです。
※印刷出版再現のため電子書籍としては不要な情報を含んでいる場合があります。
※印刷出版とは異なる表記・表現の場合があります。予めご了承ください。
※プレビューにてお手持ちの電子端末での表示状態をご確認の上、商品をお買い求めください。
感情タグBEST3
Posted by ブクログ
チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで
著：市谷 聡啓
出版社：翔泳社
たんなるグループを、変化に強いチームにするための解説書です。
■チームになるための４つの条件
①チームの目標をそろえる
②共通の目標を認識する
③お互いの持ち味を把握する
④協働で仕事するためのやり方を整える
■スクラムの５つのイベント
①スプリント 反復される開発期間
②スプリントプラニング そのスプリントで何を開発するかを計画するためのミーティング
③ディリースクラム 日々の進捗や優先順位、障害などを確認し合う短いミーティング
④スプリントレビュー スプリントの終わりに作成物をレビューしフィードバックするミーティング
⑤スプリントレトロスペクティブ プロセスを検査し、カイゼンするためのミーティング
いくら引き延ばしをしても状況が変わる見込みがないならば、そこにいる人間でどうにかするしかない
待っていても何も変わらない
状況を変えられるのは必要性に気づいている人間だけだ
問題とは、理想と現実との差分にあたる
つまり、理想が描けていなければ問題（＝差分）にはならない
■出発のための３つの問い
①自分はなぜここにいるのか？ 個人としてのＷｈｙ
②私たちは何をする者たちなのか？ チームとしてのＷｈｙ
③そのために何を大事にするのか？ チームとしてのＨｏｗ
ふりかえりとは、過去から現在を正し
むきなおりとは、将来から現在を正す
■タックマンモデル
①形成期：お互いのことを知らない、目的も不明瞭
②混乱期；お互いの役割、考え方で意見が生まれて対立する
③統一期：行動規範や、役割が確立し、他人の考え方が受容できる
④機能期：一体感が生まれ、目標達成に向かう状態
■成長循環モデル
①関係の質⇒②思考の質⇒③行動の質⇒④結果の質⇒①関係の質
■ふりかえりから、カイゼンへ
①チーム仕事を短く、小さく、一巡させる
②小さな成功体験から関係性を高める
③ふりかえりによってさっそく改善を始める
■コルブの経験学習モデル
具体的経験⇒内省的観察⇒抽象的概念化⇒能動的実験⇒具体的経験
■チームの構造：共有ミッション、役割、コミュニケーションの場、ルール
個人商店 ⇒共有ミッションがない
塹壕 ⇒ コミュニケーションの場がない
烏合の衆 ⇒ ルールがない
仲良しこよし ⇒ 役割が不明確
チームのゴールデンサークル
Ｗｈｙ まず、何にファーストを置くのか、そして達成したいミッションはなにか
Ｈｏｗ Ｗｈｙを実現するための作戦、方針
Ｗｈａｔ Ｈｏｗで決めた内容に基づいて具体的にタスクを掲げる
～Ｗｈｙから、Ｈｏｗ，Ｗｈａｔまでの一貫性をもたせる～
■分断
時間の分断
①同期できない
②オーバヘッド
経験の分断
③やり方がバラバラ
場所の分断
④内容分量
⑤異常検知が働きにくい
⑥間違いに気が付きにくい
雁行開発の導入
時間の分断
①同期できない⇒チームリーダが同期をとる
②オーバヘッド⇒独立性の高いバックログを中心に開発する
経験の分断
③やり方がバラバラ⇒背骨を先行させる
場所の分断
④内容分量⇒前衛と後衛とで細かいやりとりをする
⑤異常検知が働きにくい⇒前衛・後衛の分担とリーダによる仲介
⑥間違いに気が付きにくい⇒リーダによる背景・情報補完
■チームの共通理解を得るための手段：仮説キャンバス
目的 ビジョン
実現手段 顕在課題
優位性 潜在課題
提案価値 代替手段
評価指標 チャネル
収益モデル 状況
傾向
想定する市場規模
透明性を高める ⇒ 見える化、場づくり、一緒にやる
■チームに情報が行き渡らないのは？
①経路設計の複雑性
②解釈の多様性
情報が価値を生むフロー
情報⇒学ぶ・理解する⇒知識⇒活用する⇒価値
仮説
情報⇒学ぶ・理解する⇒仮説⇒検証する⇒知識⇒活用する⇒価値
すべての情報を全員で共同所有するという考え方
越境 役割からの越境
チームからの越境
チームの境界を見直す
チーム間の横断チーム
①専門特化型チーム 専門スキルの提供
②状況特化型チーム 共通機能開発、以降など、状況特化対応
■バラバラのユーザを一人のユーザにする
①ざっくりと大まかな行動か、状況を書き出す
②対応する行動を細かく出していく
③行動に伴い発生する問題、不都合を書き出す
④問題や不都合を解消する解決策を挙げる
⑤現状の行動フローから理想的な行動フローを描く
■標準化ではなく共同化、共同化から協働へ
現場に近いほど、詳細が必要
逆に現場から遠いほど俯瞰が必要
現場に立つときほど、外側からどう見えるのか
組織に立つときほど、現場からどう見えるのか
マネジメントリードが心がけるべきタスクに対する指針
①自分の目の前から自分がやらなければならないタスクを一掃する
②チームの目の前からやらなければならないタスクを片づける
■そもそも何を見るか
どこから見るか 視座
どこまで見るか 視野
階段を下りる 現場には、自分たちが気づけていないことがあるという前提に立って問いをぶつける
■ジャーニーのラスト
一人ぼっちにはしない
一人で越えられないなら、ともに越えよう
ともに考え、ともにつくる ⇒ 仮説を立てて、検証する
目次
推薦のことば
・私たちは他者を必要としている｜宇田川元一
・その先へ！Beyond the Agile｜新井剛
はじめに
プロローグ
第1部 僕らが開発チームになるまで─1チームのジャーニー
□単一チーム 基本編
・第01話｜グループでしかないチーム
・第02話｜一人ひとりに向き合う
・第03話｜少しずつチームになる
・第04話｜チームのファーストを変える
□単一チーム 応用編
・第05話｜チームをアップデートする
・第06話｜分散チームへの適応
・第07話｜チームの共通理解を深める
・第08話｜一人の人間のようなチーム
第2部 僕らがプロダクトチームになるまで─複数チームによるジャーニー
□複数チーム 基本編
・第09話｜塹壕の中のプロダクトチーム
・第10話｜チーム同士で向き合う
・第11話｜チームの間の境界を正す
・第12話｜チームの境界を越えてチームをつくる
□複数チーム 応用編
・第13話｜チームとチームをつなげる
・第14話｜クモからヒトデに移行するチーム
・第15話｜ミッションを越境するチーム
・第16話｜ともに考え、ともにつくるチーム
あとがき
付録
参考文献
索引
ISBN：9784798163635
出版社：翔泳社
判型：A5
ページ数：360ページ
定価：2400円（本体）
2020年02月17日初版第1刷発行
Posted by ブクログ
会社の後輩から勧められたチームマネジメントの本。物語＋解説タイプでわかりやすい構成のはずなのに，正直，読むのに時間がかかった。それはこの本が読みにくいからではない。むしろ密度と熱量が高すぎるがゆえに読み解くのに時間がかかってしまう。それだけ価値のある時間だと思うし，得られるものはそれ以上のものがある。話はシステム開発の現場で起こっていることだけれども，そこに限らない話も多いと思うし，一般的に参考になる点も多いのではないかと思う。帯に「ひとつひとつのエビソードが絵空事ではなく，リアリティの持って迫ってくる。」と書いてあるけれど，まさにそのとおりで，プロジェクトの難しさというか深みというか高みというかそういったものが迫って伝わってくる。そこを感じるのも時間がかかっている一因かもしれない。折を見て読み返したい。
Posted by ブクログ
チーム開発で起こるさまざまな問題を物語仕立てで紹介し、それを解決していく「ストーリー」部分と取り組んだ内容をより汎化した「解説」部分の組み合わせ16個で構成されている一冊。
「ストーリー」部分は共感する部分が多く、話は読み進めやすい。「ストーリー」部分の解決のところは「そんなに上手くいかないよなあ」と思うこともあるが、解決策の一事例として捉えておき、それぞれの現場に応じて考えておく必要はあると思う。全くの参考資料がないわけではなく、「解説」部分にて丁寧に問題の本質や解決策の手札について記されているので、都度読み直すと良いかと思う。
個人的には「アジャイル原理主義」みたいなことに出くわすことが多く、その対処を色々と思い悩んでいたので、「ストーリー」で取り上げられていたときには自分だけでなかったんだと安心感と解決策に興味深く読ませていただいた。
もちろん本書もこれが正解と言うわけではないので、これを参考に自分の現場で起きていることに立ち向かうことが必要かと思う。
Posted by ブクログ
プロダクト開発において避けては通れないどころか核であるチームビルディングの指南書。小説と解説が交互に来る構成なので読みやすいんだけど、正直PMやってる今の自分の状況に当てはまりすぎるほど当てはまっていて心が痛くなり読み進めるのが怖い面もｗ新型コロナでリモートワークが普及した今となっては第6話が単一チーム基本編に入ってくるのかな？長くお世話になりそう。
Posted by ブクログ
チームの事を考え始める役割になったタイミングで読ませて頂いたため、とても参考にさせて頂きました。
日々チームに起こる様々な問題。
グループからチームになるまで、発生した（発生しうる）問題を解決まで、解説付きで読む事ができます。
チームのスケール時に起こるストーリーもあるため、1チームの問題だけでなく、複数チームに跨った問題まで読む事ができます。
ストーリー形式なので、イメージしやすく読む事ができました。
実際に、チームメンバーの状態や、プロダクトでやり切らなくてはならない問題にぶち当たったタイミングで、参考にさせて頂きました。
プロダクトファーストという作戦で、スクラムを崩し、雁行陣開発に移し、WFに近い形でやり切る事ができました。
この経験があるから、チーム力も上がったと思います。
「カイゼン・ジャーニー」「正しいものを正しく作る」「チーム・ジャーニー」
プロダクトを作る上での三種の神器だと思います。
そのため、教科書のように参考にさせていただける本にさせていただいています。
Posted by ブクログ
チームが成長し機能する過程をストーリーに落とし込み、手に取った読者が自分のハンドルを自分で握る覚悟を後押しする。チームジャーニーは、そんな本だ。
1つのチームが「グループ」から「チーム」へと成長していく第一部、複数のチームが境界を「越境」しながら本当に必要なプロダクトを探求するジャーニーに赴く第二部の二部構成。
名著「カイゼンジャーニー」と同じく、ストーリーの中でチームを成長させていくためのプラクティスが紹介されるため、現場のどのような状況で適用できるのかがイメージしやすい。
そしてプラクティス以上に、「少しずつ変化する」「1つの正解はない、常に問を投げ続ける」というメッセージが重要であると感じた。
Posted by ブクログ
問題が頻発。
実際の開発もそうだから…
進行のために色々なやり方を採れるのが羨ましい。
人にお願いできない…
スクラムの延長のリーンジャーニースタイルの提案。
買いかもしれん、何度も読むのが良さそう
Posted by ブクログ
物語形式で現場の状況がとてもよく把握できる。そして、本当にありそうな展開です。それゆえに読んでいて、自分がその場にいるような感じがして苦しかった。やってもやってもなかなか状況は改善しない、各部の最後でようやく事態は好転するけれど、身が引き締まるような読書体験でした。巻末の参考文献は1/3くらい読んだことがあるけれど、未読の本は読んでみたい。
Posted by ブクログ
チームビルディングについては興味はなかったが、ソフトウェア開発のことについては学びたいと思っており、会社の先輩などにも勧められたため、読んでみました。
この本は現代のソフトウェア開発におけるチームビルディングのお話で、変化に対応するフレームワークを提唱しています。チーム内の問題をあげているので、自分の現場に紐づくところが何点かあったたり、いくつか参考になりました。
まず、チームの共通理解は常に頭にないと、齟齬が生まれると無駄な手戻りが発生する点です。この点は開発だけの問題はないため、自分の現場でも意識して取り組んでいきたいなと感じました。
そして、目標に向かう段階設計です。この本のメインとも言われるものです。よく会社で段階的に行動をしなさいみたいなことを言われてきてるけど、具体的な方法がわからず、中途半端になっていたので、この本を参考にしてやってみたいと思いました。
この本を一周だけですべて理解できていなかったので、何度も読んで参考していきたいと感じました。
Posted by ブクログ
プロダクト開発におけるチームマネジメントを物語形式で書いている本。章立てでチームに起きる課題をどのように乗り越えていくかの方法が書いてあり、それによりチームが成長する様も面白かったので飽きなく読めた。
Posted by ブクログ
「正しいものを正しく作る」をより実践的に噛み砕いた物語。
チームを作る事は、物語に描かれている通り簡単なことではないし、現実は感情が複雑に絡むのでより難しい事ではあるが、こんなチームを目指したいと思った。
今度チームを作るときは、まずはゴールデンサークルから始めたい。
Posted by ブクログ
# チームの成長に寄り添った、ソフトウェア開発の物語
## 面白かったところ
* カイゼン・ジャーニーの続編という文脈を濃く受け継いでいる点
* チームの運営や雰囲気などに詰まった時、視座を高めてくれる一冊
* ひとえにチームと言っても、様々な段階や顔が存在することを知れる
## 微妙だったところ
* 組織マネジメントではなく、あくまでも「チーム」に特化した一冊であるため、分かりづらい点も少なくないこと
## 感想
エンジニア（開発者）として、チームの一員としてどう振る舞うべきか悩む時がある。
悩むのは悪いことはいいが、無数の答えが存在してメリットやデメリットを測ることも正直難しかった。
この本に出会ってかなりスッキリした点が多かった。リーダーとリードの違いや海星型チームと蜘蛛型チームの違いなど、チームによって様々な段階や形態があることを学んだ。
不明点も少なくなかったため、また読み返したい。
Posted by ブクログ
■チームになるための４つの条件
①チームの目的を揃える
②共通の目標を認識する
③お互いの持ち味を把握する
④協働で仕事するためのやり方を整える
■リーダーとリード
リーダー：組織上の職位として定義され、人に張り付く言葉のイメージ。
リード：ある状況において前進を主導する「役割」。役割なので、他の人に代わる、代えることもある、より動的なイメージ。
■雁行陣開発
…プロダクトリード、チームリードという役割を置く。プロダクトリードは、プロダクトのつくり方、方針、そしてその実装について先導する役割である。一方、チームリードは、チームの運営を担うことになる。その他のメンバーは適宜プロダクトバックログを実装する。それぞれの役割で、それぞれのミッションをつとめる。
このフォーメーションで、前衛にあたるのはプロダクトリード、後衛にあたるのがチームメンバーだ。プロダクトリードが先行してかつプロダクトの中核となるプロダクトバックログを開発する役回りになる。その他のチームメンバーは、その他の必要な機能の開発を受け持つ。
雁行陣開発でのプロダクトバックログの管理については、まずその性質からプロダクトの「背骨」にあたるプロダクトバックログと「お肉」にあたるプロダクトバックログに分けることから始める。背骨バックログとはプロダクトを利用するユーザーの体験上必ず必要となる機能群になる。
…お肉バックログは、背骨があることを前提としてそこにまさに肉付けするようにつくることができる機能群のことである。
■透明性を高め、チームの共通理解を深める３つの原則
１見える化：情報を得られるようにする
２場づくり：情報を伝え合うようにする
３一緒にやる：情報を一緒につくる
■INVEST：プロダクトバックログが開発レディになっているかどうかを判断するモノサシ
Independet お互いが独立している
Negotiable 実現内容について交渉可能である
Valuable 中身に価値がある
Estimable 見積もり可能である
Sized Right 適切な大きさである
Testable テスト可能である
■チームミッションと作戦の流通範囲
・すべての情報を全員で共同所有する
・Why寄りの情報は広めに、How寄りの情報は狭く
■リード・パターン
テクニカルリード
チームの技術方針を決める役割。複数チームの体制の場合、各チームの技術的な窓口にあたる。チーム間での技術的方針のすり合わせや合意を行う。
仮説検証リード
仮説検証の活動を計画したり、その実行を先導したりする役割。仮説検証に必要な様々な道具立てについて実践するための知見を有し、その引き出しに広さが求められる。
テストリード
プロダクトの状態、目的に応じたテストの計画やテスト設計を先導する役割。出荷前に実施するテストや、セキュリティやパフォーマンスなど非機能系のテストなど、必要に応じて企画する。
デベロッパーエクスペリエンスリード
開発環境を中心として、チームメンバーの開発体験を向上させる取り組みを先導する。他のチーム、現場での取り組みについて情報を収集し、自チームに適した形での取り入れ方を検討する。
XXXリード
上記によらず、 特に注力すべき課題に応じて設置するリード。たとえば決済機能の開発およびそれに必要な一連のタスクをぬけもれなく完するために「決済開発リード」を置くなど。
Posted by ブクログ
ソフトウェア開発のことはよくわからないが (自分はハード屋寄りなので)、カイゼンについて知りたかったため前作を読み、さらにチーム運営についても学びたいと思い読んだのがきっかけ。
私が本書から得たキーワードとしては、問うこと、多様性、ともにつくる、の3つ。うしろ2つはセットなので、2つと言ってもよい。
仕事でもなんでも、主体的にものごとを進めようと思うならば、問うことが欠かせない。なぜこの仕事をするのか、なぜ私がやるのか、どうしてこのやり方なのか、あるべき姿はなにか。いくらでも問いは生まれる。問うことを止めてしまえば、目の前の仕事に没頭してしまい、こなしていることで前に進んでいる感覚は得られるかもしれないが、責任感は失われ、大きな間違いに迷い込んでしまう可能性が大いにある。先の読めない時代と言われて久しいいま、よりいっそう問うことが必要。
そして人的多様性も必要だ。それは女性が、とか若手が、とかいう意味ではなく、純粋に別のことを考えている個人が集まる多様性のことを言っている。問答を自分一人で抱えてしまうと、答えを出すのに時間がかかるし、多面的な視点を欠いて見誤る可能性が高い。その際、多数決の民主主義ではなく、意見のぶつかり合いの中で、新たな着想を得ることが大事。つまり多様性+ともにつくることが大事。
言われてみると当たり前というか、いろいろなビジネス本に載っていそうなことではあるが、それを物語を読み進めながら、どういうときにこの考え方が必要になるのかを追体験していくことができるため、より浸透できたきがする。
しかしながら、話が長いのと、登場人物の名前が独特で読み難いのがマイナスポイント。まず、主人公の名前がすんなり読めないので (私の語彙力が弱いせいでもあるが)、最後まで頭の中で変換する必要があった (ふといじゃなくて、うずまきみたいな、そう、うずまさ)。
