無料マンガ・ラノベなど、豊富なラインナップで200万冊以上配信中!
「ともに考え、ともにつくる」――スクラムやアジャイルを導入した現場で
直面する開発チーム・マネジメントの問題に立ち向かうすべ、
チームづくりの要点をストーリーで学ぼう!
【本書の特徴】
・現場のストーリーから、考え方とプラクティスを一緒に学べる
・単一チーム、複数チームなど、様々なチーム・マネジメントの問題を扱う
・日本の現場を前提にしているので、実践しやすい
・アジャイルをこれから始める人だけでなく、もっとうまく実践したい人にも最適
【本書に登場するプラクティス】
出発のための3つの問い / 段階の設計 / ドラッカー風エクササイズB面 / 割れ窓理論 /
フォーメーション・パターン / コンウェイの法則 / 越境のデザイン / 重奏型仮説検証 ほか
【あらすじ】
チームによるプロダクトづくりができる環境を求めて
“太秦(うずまさ)”が転職した先は、デベロッパー向けのツールを開発、提供する、
小さなベンチャーだった。しかし会社期待のタスク管理ツールを開発するチームに
配属され、いきなりチームリーダーをつとめることに。
……とうていチームとは呼べない“グループ”(個人活動の集合)の状態から、
本当のチームになれたと思ったのもつかの間、経営陣はタスク管理を含めた
3つのツール統合を発表。太秦はそれらプロダクトの統合を行う開発リーダーを
任されたのであった。
チームとは何か?、チームのファーストとは?、分散チームへの適応など様々な
「単一チームの問題」、複数のプロダクト統合に伴うチーム間の断絶や衝突、
チームが上手く連携できないなど様々な「複数チームの問題」……これらを乗り越え、
太秦たちがたどり着いた「ともに考え、ともにつくる」とは?
※本電子書籍は同名出版物を底本として作成しました。記載内容は印刷出版当時のものです。
※印刷出版再現のため電子書籍としては不要な情報を含んでいる場合があります。
※印刷出版とは異なる表記・表現の場合があります。予めご了承ください。
※プレビューにてお手持ちの電子端末での表示状態をご確認の上、商品をお買い求めください。
※アプリの閲覧環境は最新バージョンのものです。
Posted by ブクログ
チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで
著:市谷 聡啓
出版社:翔泳社
たんなるグループを、変化に強いチームにするための解説書です。
■チームになるための4つの条件
①チームの目標をそろえる
②共通の目標を認識する
③お互いの持ち味を把握する
④協働で仕事するためのやり方を整える
■スクラムの5つのイベント
①スプリント 反復される開発期間
②スプリントプラニング そのスプリントで何を開発するかを計画するためのミーティング
③ディリースクラム 日々の進捗や優先順位、障害などを確認し合う短いミーティング
④スプリントレビュー スプリントの終わりに作成物をレビューしフィードバックするミーティング
⑤スプリントレトロスペクティブ プロセスを検査し、カイゼンするためのミーティング
いくら引き延ばしをしても状況が変わる見込みがないならば、そこにいる人間でどうにかするしかない
待っていても何も変わらない
状況を変えられるのは必要性に気づいている人間だけだ
問題とは、理想と現実との差分にあたる
つまり、理想が描けていなければ問題(=差分)にはならない
■出発のための3つの問い
①自分はなぜここにいるのか? 個人としてのWhy
②私たちは何をする者たちなのか? チームとしてのWhy
③そのために何を大事にするのか? チームとしてのHow
ふりかえりとは、過去から現在を正し
むきなおりとは、将来から現在を正す
■タックマンモデル
①形成期:お互いのことを知らない、目的も不明瞭
②混乱期;お互いの役割、考え方で意見が生まれて対立する
③統一期:行動規範や、役割が確立し、他人の考え方が受容できる
④機能期:一体感が生まれ、目標達成に向かう状態
■成長循環モデル
①関係の質⇒②思考の質⇒③行動の質⇒④結果の質⇒①関係の質
■ふりかえりから、カイゼンへ
①チーム仕事を短く、小さく、一巡させる
②小さな成功体験から関係性を高める
③ふりかえりによってさっそく改善を始める
■コルブの経験学習モデル
具体的経験⇒内省的観察⇒抽象的概念化⇒能動的実験⇒具体的経験
■チームの構造:共有ミッション、役割、コミュニケーションの場、ルール
個人商店 ⇒共有ミッションがない
塹壕 ⇒ コミュニケーションの場がない
烏合の衆 ⇒ ルールがない
仲良しこよし ⇒ 役割が不明確
チームのゴールデンサークル
Why まず、何にファーストを置くのか、そして達成したいミッションはなにか
How Whyを実現するための作戦、方針
What Howで決めた内容に基づいて具体的にタスクを掲げる
~Whyから、How,Whatまでの一貫性をもたせる~
■分断
時間の分断
①同期できない
②オーバヘッド
経験の分断
③やり方がバラバラ
場所の分断
④内容分量
⑤異常検知が働きにくい
⑥間違いに気が付きにくい
雁行開発の導入
時間の分断
①同期できない⇒チームリーダが同期をとる
②オーバヘッド⇒独立性の高いバックログを中心に開発する
経験の分断
③やり方がバラバラ⇒背骨を先行させる
場所の分断
④内容分量⇒前衛と後衛とで細かいやりとりをする
⑤異常検知が働きにくい⇒前衛・後衛の分担とリーダによる仲介
⑥間違いに気が付きにくい⇒リーダによる背景・情報補完
■チームの共通理解を得るための手段:仮説キャンバス
目的 ビジョン
実現手段 顕在課題
優位性 潜在課題
提案価値 代替手段
評価指標 チャネル
収益モデル 状況
傾向
想定する市場規模
透明性を高める ⇒ 見える化、場づくり、一緒にやる
■チームに情報が行き渡らないのは?
①経路設計の複雑性
②解釈の多様性
情報が価値を生むフロー
情報⇒学ぶ・理解する⇒知識⇒活用する⇒価値
仮説
情報⇒学ぶ・理解する⇒仮説⇒検証する⇒知識⇒活用する⇒価値
すべての情報を全員で共同所有するという考え方
越境 役割からの越境
チームからの越境
チームの境界を見直す
チーム間の横断チーム
①専門特化型チーム 専門スキルの提供
②状況特化型チーム 共通機能開発、以降など、状況特化対応
■バラバラのユーザを一人のユーザにする
①ざっくりと大まかな行動か、状況を書き出す
②対応する行動を細かく出していく
③行動に伴い発生する問題、不都合を書き出す
④問題や不都合を解消する解決策を挙げる
⑤現状の行動フローから理想的な行動フローを描く
■標準化ではなく共同化、共同化から協働へ
現場に近いほど、詳細が必要
逆に現場から遠いほど俯瞰が必要
現場に立つときほど、外側からどう見えるのか
組織に立つときほど、現場からどう見えるのか
マネジメントリードが心がけるべきタスクに対する指針
①自分の目の前から自分がやらなければならないタスクを一掃する
②チームの目の前からやらなければならないタスクを片づける
■そもそも何を見るか
どこから見るか 視座
どこまで見るか 視野
階段を下りる 現場には、自分たちが気づけていないことがあるという前提に立って問いをぶつける
■ジャーニーのラスト
一人ぼっちにはしない
一人で越えられないなら、ともに越えよう
ともに考え、ともにつくる ⇒ 仮説を立てて、検証する
目次
推薦のことば
・私たちは他者を必要としている|宇田川元一
・その先へ!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 ブクログ
チームの事を考え始める役割になったタイミングで読ませて頂いたため、とても参考にさせて頂きました。
日々チームに起こる様々な問題。
グループからチームになるまで、発生した(発生しうる)問題を解決まで、解説付きで読む事ができます。
チームのスケール時に起こるストーリーもあるため、1チームの問題だけでなく、複数チームに跨った問題まで読む事ができます。
ストーリー形式なので、イメージしやすく読む事ができました。
実際に、チームメンバーの状態や、プロダクトでやり切らなくてはならない問題にぶち当たったタイミングで、参考にさせて頂きました。
プロダクトファーストという作戦で、スクラムを崩し、雁行陣開発に移し、WFに近い形でやり切る事ができました。
この経験があるから、チーム力も上がったと思います。
「カイゼン・ジャーニー」「正しいものを正しく作る」「チーム・ジャーニー」
プロダクトを作る上での三種の神器だと思います。
そのため、教科書のように参考にさせていただける本にさせていただいています。
Posted by ブクログ
チームが成長し機能する過程をストーリーに落とし込み、手に取った読者が自分のハンドルを自分で握る覚悟を後押しする。チームジャーニーは、そんな本だ。
1つのチームが「グループ」から「チーム」へと成長していく第一部、複数のチームが境界を「越境」しながら本当に必要なプロダクトを探求するジャーニーに赴く第二部の二部構成。
名著「カイゼンジャーニー」と同じく、ストーリーの中でチームを成長させていくためのプラクティスが紹介されるため、現場のどのような状況で適用できるのかがイメージしやすい。
そしてプラクティス以上に、「少しずつ変化する」「1つの正解はない、常に問を投げ続ける」というメッセージが重要であると感じた。
Posted by ブクログ
チームビルディングについては興味はなかったが、ソフトウェア開発のことについては学びたいと思っており、会社の先輩などにも勧められたため、読んでみました。
この本は現代のソフトウェア開発におけるチームビルディングのお話で、変化に対応するフレームワークを提唱しています。チーム内の問題をあげているので、自分の現場に紐づくところが何点かあったたり、いくつか参考になりました。
まず、チームの共通理解は常に頭にないと、齟齬が生まれると無駄な手戻りが発生する点です。この点は開発だけの問題はないため、自分の現場でも意識して取り組んでいきたいなと感じました。
そして、目標に向かう段階設計です。この本のメインとも言われるものです。よく会社で段階的に行動をしなさいみたいなことを言われてきてるけど、具体的な方法がわからず、中途半端になっていたので、この本を参考にしてやってみたいと思いました。
この本を一周だけですべて理解できていなかったので、何度も読んで参考していきたいと感じました。
※アプリの閲覧環境は最新バージョンのものです。