チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで
- 翔泳社 (2020年2月17日発売)
本棚登録 : 348人
感想 : 25件
- Amazon.co.jp ・本 (360ページ)
- / ISBN・EAN: 9784798163635
作品紹介・あらすじ
「ともに考え、ともにつくる」――スクラムやアジャイルを導入した現場で
直面する開発チーム・マネジメントの問題に立ち向かうすべ、
チームづくりの要点をストーリーで学ぼう！
【本書の特徴】
・現場のストーリーから、考え方とプラクティスを一緒に学べる
・単一チーム、複数チームなど、様々なチーム・マネジメントの問題を扱う
・日本の現場を前提にしているので、実践しやすい
・アジャイルをこれから始める人だけでなく、もっとうまく実践したい人にも最適
【本書に登場するプラクティス】
出発のための3つの問い ／ 段階の設計 ／ ドラッカー風エクササイズB面 ／ 割れ窓理論 ／ フォーメーション・パターン ／ コンウェイの法則 ／ 越境のデザイン ／ 重奏的仮説検証 ほか
【あらすじ】
チームによるプロダクトづくりができる環境を求めて
“太秦（うずまさ）”が転職した先は、デベロッパー向けのツールを開発、提供する、
小さなベンチャーだった。しかし会社期待のタスク管理ツールを開発するチームに
配属され、いきなりチームリーダーを務めることに。
……とうていチームとは呼べない“グループ”（個人活動の集合）の状態から、
本当のチームになれたと思ったのもつかの間、経営陣はタスク管理を含めた
三つのツール統合を発表。太秦はそれらプロダクトの統合を行う開発リーダーを
任されたのであった。
チームとは何か？、チームのファーストとは？、分散チームへの適応など様々な
「単一チームの問題」、複数のプロダクト統合に伴うチーム間の断絶や衝突、
チームが上手く連携できないなど様々な「複数チームの問題」……これらを乗り越え、
太秦たちがたどり着いた「ともに考え、ともにつくる」とは？
感想・レビュー・書評
-
読む順番を間違えたらしい。
アジャイルはわからない（知ってるけどルールとか作法とか興味ない）。
ただ、これから先に読んだことでアジャイルを介したいくつかの問いについての重要性を認識できた。
「自分は何をする者なのか」「なぜここにいるのか」「お客様は誰か」「つくるべきものは何か」
それにしても問題が多発するところだな・・身に覚えのある内容も見かけたけど。
改めて自分が移った位置でやるべきことが見えた、気が少しした。
個人的には読む順番は合ってた気がする。
200冊目読了。
2
詳細をみるコメント0件をすべて表示 -
チームが成長し機能する過程をストーリーに落とし込み、手に取った読者が自分のハンドルを自分で握る覚悟を後押しする。チームジャーニーは、そんな本だ。
1つのチームが「グループ」から「チーム」へと成長していく第一部、複数のチームが境界を「越境」しながら本当に必要なプロダクトを探求するジャーニーに赴く第二部の二部構成。
名著「カイゼンジャーニー」と同じく、ストーリーの中でチームを成長させていくためのプラクティスが紹介されるため、現場のどのような状況で適用できるのかがイメージしやすい。
そしてプラクティス以上に、「少しずつ変化する」「1つの正解はない、常に問を投げ続ける」というメッセージが重要であると感じた。
2
-
ソフトウェア開発のことはよくわからないが (自分はハード屋寄りなので)、カイゼンについて知りたかったため前作を読み、さらにチーム運営についても学びたいと思い読んだのがきっかけ。
私が本書から得たキーワードとしては、問うこと、多様性、ともにつくる、の3つ。うしろ2つはセットなので、2つと言ってもよい。
仕事でもなんでも、主体的にものごとを進めようと思うならば、問うことが欠かせない。なぜこの仕事をするのか、なぜ私がやるのか、どうしてこのやり方なのか、あるべき姿はなにか。いくらでも問いは生まれる。問うことを止めてしまえば、目の前の仕事に没頭してしまい、こなしていることで前に進んでいる感覚は得られるかもしれないが、責任感は失われ、大きな間違いに迷い込んでしまう可能性が大いにある。先の読めない時代と言われて久しいいま、よりいっそう問うことが必要。
そして人的多様性も必要だ。それは女性が、とか若手が、とかいう意味ではなく、純粋に別のことを考えている個人が集まる多様性のことを言っている。問答を自分一人で抱えてしまうと、答えを出すのに時間がかかるし、多面的な視点を欠いて見誤る可能性が高い。その際、多数決の民主主義ではなく、意見のぶつかり合いの中で、新たな着想を得ることが大事。つまり多様性+ともにつくることが大事。
言われてみると当たり前というか、いろいろなビジネス本に載っていそうなことではあるが、それを物語を読み進めながら、どういうときにこの考え方が必要になるのかを追体験していくことができるため、より浸透できたきがする。
しかしながら、話が長いのと、登場人物の名前が独特で読み難いのがマイナスポイント。まず、主人公の名前がすんなり読めないので (私の語彙力が弱いせいでもあるが)、最後まで頭の中で変換する必要があった (ふといじゃなくて、うずまきみたいな、そう、うずまさ)。
1
-
ジャーニープランニングとして、チーム結成時に皆で読んで共通認識にしとくと、それぞれのシーンでの行動基準になったり、体験を経験として消化する度合いが爆上がりしそう。理想ではなく、等身大のチームとして進む道の過程と、その先にある希望を先に体験できるので。例えば、もし、この世界にこの本があって、フォースもフィフスもシックスの皆がそれぞれ先に読んでたらどうなっただろう？そういう意味で読書会必須。
また、タイトルから当たり前だけど、他者の存在が終始前提で肯定されてた感。希望を見出して個人になった人にも、あるいは諦めてしまって個人で動いている人にも、チームであることの魅力と必要性を伝えてくれる。
一方で、、、”チーム”が何か、”チーム”である意味を強く考えさせられるきっかけになる。なぜ私たちはこうもチームを求めるのか？チームで在りたいのか？チームに心を惹かれるのか？たぶん、それをともに考えだすのがチームジャーニーの始まり。
1
-
会社の後輩から勧められたチームマネジメントの本。物語＋解説タイプでわかりやすい構成のはずなのに，正直，読むのに時間がかかった。それはこの本が読みにくいからではない。むしろ密度と熱量が高すぎるがゆえに読み解くのに時間がかかってしまう。それだけ価値のある時間だと思うし，得られるものはそれ以上のものがある。話はシステム開発の現場で起こっていることだけれども，そこに限らない話も多いと思うし，一般的に参考になる点も多いのではないかと思う。帯に「ひとつひとつのエビソードが絵空事ではなく，リアリティの持って迫ってくる。」と書いてあるけれど，まさにそのとおりで，プロジェクトの難しさというか深みというか高みというかそういったものが迫って伝わってくる。そこを感じるのも時間がかかっている一因かもしれない。折を見て読み返したい。
0
-
# チームの成長に寄り添った、ソフトウェア開発の物語
## 面白かったところ
* カイゼン・ジャーニーの続編という文脈を濃く受け継いでいる点
* チームの運営や雰囲気などに詰まった時、視座を高めてくれる一冊
* ひとえにチームと言っても、様々な段階や顔が存在することを知れる
## 微妙だったところ
* 組織マネジメントではなく、あくまでも「チーム」に特化した一冊であるため、分かりづらい点も少なくないこと
## 感想
エンジニア（開発者）として、チームの一員としてどう振る舞うべきか悩む時がある。
悩むのは悪いことはいいが、無数の答えが存在してメリットやデメリットを測ることも正直難しかった。
この本に出会ってかなりスッキリした点が多かった。リーダーとリードの違いや海星型チームと蜘蛛型チームの違いなど、チームによって様々な段階や形態があることを学んだ。
不明点も少なくなかったため、また読み返したい。
0
-
物語形式で現場の状況がとてもよく把握できる。そして、本当にありそうな展開です。それゆえに読んでいて、自分がその場にいるような感じがして苦しかった。やってもやってもなかなか状況は改善しない、各部の最後でようやく事態は好転するけれど、身が引き締まるような読書体験でした。巻末の参考文献は1/3くらい読んだことがあるけれど、未読の本は読んでみたい。
0
-
■チームになるための４つの条件
①チームの目的を揃える
②共通の目標を認識する
③お互いの持ち味を把握する
④協働で仕事するためのやり方を整える
■リーダーとリード
リーダー：組織上の職位として定義され、人に張り付く言葉のイメージ。
リード：ある状況において前進を主導する「役割」。役割なので、他の人に代わる、代えることもある、より動的なイメージ。
■雁行陣開発
…プロダクトリード、チームリードという役割を置く。プロダクトリードは、プロダクトのつくり方、方針、そしてその実装について先導する役割である。一方、チームリードは、チームの運営を担うことになる。その他のメンバーは適宜プロダクトバックログを実装する。それぞれの役割で、それぞれのミッションをつとめる。
このフォーメーションで、前衛にあたるのはプロダクトリード、後衛にあたるのがチームメンバーだ。プロダクトリードが先行してかつプロダクトの中核となるプロダクトバックログを開発する役回りになる。その他のチームメンバーは、その他の必要な機能の開発を受け持つ。
雁行陣開発でのプロダクトバックログの管理については、まずその性質からプロダクトの「背骨」にあたるプロダクトバックログと「お肉」にあたるプロダクトバックログに分けることから始める。背骨バックログとはプロダクトを利用するユーザーの体験上必ず必要となる機能群になる。
…お肉バックログは、背骨があることを前提としてそこにまさに肉付けするようにつくることができる機能群のことである。
■透明性を高め、チームの共通理解を深める３つの原則
１見える化：情報を得られるようにする
２場づくり：情報を伝え合うようにする
３一緒にやる：情報を一緒につくる
■INVEST：プロダクトバックログが開発レディになっているかどうかを判断するモノサシ
Independet お互いが独立している
Negotiable 実現内容について交渉可能である
Valuable 中身に価値がある
Estimable 見積もり可能である
Sized Right 適切な大きさである
Testable テスト可能である
■チームミッションと作戦の流通範囲
・すべての情報を全員で共同所有する
・Why寄りの情報は広めに、How寄りの情報は狭く
■リード・パターン
テクニカルリード
チームの技術方針を決める役割。複数チームの体制の場合、各チームの技術的な窓口にあたる。チーム間での技術的方針のすり合わせや合意を行う。
仮説検証リード
仮説検証の活動を計画したり、その実行を先導したりする役割。仮説検証に必要な様々な道具立てについて実践するための知見を有し、その引き出しに広さが求められる。
テストリード
プロダクトの状態、目的に応じたテストの計画やテスト設計を先導する役割。出荷前に実施するテストや、セキュリティやパフォーマンスなど非機能系のテストなど、必要に応じて企画する。
デベロッパーエクスペリエンスリード
開発環境を中心として、チームメンバーの開発体験を向上させる取り組みを先導する。他のチーム、現場での取り組みについて情報を収集し、自チームに適した形での取り入れ方を検討する。
XXXリード
上記によらず、 特に注力すべき課題に応じて設置するリード。たとえば決済機能の開発およびそれに必要な一連のタスクをぬけもれなく完するために「決済開発リード」を置くなど。
0
-
著者の3作目。
前作を読んでいたので途中で同じ著者ときがついた。
この作は生々しいので感情に気ながらチームの移り変わる段階となるジャーニーを追体験できる。
一章までは体験してきたことなので、なるほどの感情だったが、
2章からの視座と視野の高さにまとめ上げた内容の筆を感じる。
我々はなぜここにいるのかという問いはチームがリビルドするたびに産まれる。
その際に標準化より共同化の視点は大事にしたい。
参考文献も辿れるので理解をさらに進める体験も期待できる。
0
著者プロフィール
市谷聡啓の作品
この本を読んでいる人は、こんな本も本棚に登録しています。
