新井剛の作品一覧

カイゼン・ジャーニーたった1人からはじめて、「越境」するチームをつくるまで

ビジネス・実用

IT・コンピュータ / 言語・プログラミング

4.4

Posted by ブクログ

カイゼン・ジャーニー　たった1人からはじめて、「越境」するチームをつくるまで
著：市谷　聡啓
著：新井　剛
出版社：翔泳社

良書、いろいろ、気づきがあり手にしてよかったと感じました。
アジャイル開発のために、指示待ち君ではなく、自分で気づける君を育てるための書だと理解しています。

もっと仕事のやり方をよくしたいと動機から、何に取り組めばいいのかという投げかけから出発します。

■一人からはじめる

４つのタスクから始める
　①タスクマネージメント
　②タスクボード
　③朝会
　④ふりかえり

小さく試みる⇒許可をもとめるな、謝罪せよ
まずはやってみる、何かを始めるときは大事な心構えだ

ふりかえり⇒立ち止まって考える

　ＫＰＴ
　①Keep 続けたいこと
　②Problem 問題点
　③Try 試したいこと

２度目の振り返り

　ふりかえりをテキストでメモで残すこと

　①前回のTryを見る
　ＫＰＴ
　①Keep 続けたいこと
　②Problem 問題点
　③Try 試したいこと

　自分で気づけないこと⇒他人に気づいてもらえる仕組みが必要

問題解決のアプローチ
　①問題発見
　②事実発見
　③対策

１人ではじめる

　タスクを書き出し、見える化する
　どうなったら、このタスクは終わるのか、の答えを用意する
　大きなタスクをそのままにしない⇒問題は分割せよ

　緊急でないが、重要なこと、に時間を配分する
　・人間関係づくり
　・自己啓発
　・カイゼン
　
　１日の初めに、計画をたてる
　・昨日やったこと
　・今日やること
　・困っていること

　リーダ、メンバーと１ｏｎ１で対話する

　タスクボードで、タスクを見える化する

２人ではじめる

　あなたは何をする人ですか？
　いつだってはじめるのは自分、でも、いつまでも一人ではない
　行動を始めるべきと気づいたときが、その人にとって最速のタイミング
　２人だと、疑問背景への質問によって知識に影響をあたえより深い位置に降りることができる

学習する組織（氷山モデル）
　出来事
　（海面）
　パターン
　構造
　メンタルモデル

■チームで強くなる

一人からチームへ

　スクラムとは、ふりかえりながらカイゼンしていく、経験主義に基づく
　経験主義とは、経験した学びを重視し、不確実な状況においても漸進的に物事を進めていく、という考え

　インセプションデッキ　プロジェクトとして、Ｗｈｙ，Ｈｏｗに答える
　＜Ｗｈｙ＞
　①われわれはなぜここにいるのか
　②エレベータビッチ
　③パッケージデザイン
　④やらないことリスト
　⑤ご近所さんを探せ：チームを取り巻くステークホルダー
　＜Ｈｏｗ＞
　⑥技術的な解決策
　⑦夜も眠れない問題
　⑧期間を見極める
　⑨トレードオフスライダー
　⑩何がどれだけ必要か

　ゴールデンサークル
　　中心から、Ｗｈｙ⇒Ｈｏｗ⇒Ｗｈａｔ

　組織の成功循環モデル
　　関係の質：お互いに尊重し一緒に考える
　　思考の質：気づきがありおもしろい
　　行動の質：自分で考え、自発的に行動する
　　結果の質：成果が得られる
　　関係の質：信頼関係が得られる

　２つの期待をマネジメントする
　①チームにおける期待
　②プロジェクト関係者における期待

　ドラッカー風エクササイズ
　①何が得意
　②どうやって貢献
　③大切に思う価値
　④メンバーはどんな期待

　危険なシグナルをキャッチする
　　ファイブフィンガー（個人個人がプロジェクトをどうみているか）
　　５本：とってもうまくやれている
　　４本：うまくやれている感触ある
　　３本：可もなく不可もない
　　２本：不安が少しある
　　１本：全然ダメ、絶望的

　品質に対する考え：狩野モデル、すべての品質が均質である必要はない
　　魅力的品質：充足されれば満足を与えるが、不充分であっても仕方がない
　　一元的品質：充足されれば満、不充分であれば、不満を引きおこす
　　当たり前品質：充足されて当たり前、不充分であれば、不満を引き起こす

　ふりかえり、と、むきなおり
　　ふりかえりは、過去を見て、現在を正す
　　むきなおりは、進むべき先をみて、現在を正す

　スキルマップ
　　★：エース級
　　〇：一人前
　　△：ヘルプ必要
　　↑：習得希望
　　　：できない

　モブプログラミング；みんなで１つの画面をみながら、コーディングする
　①プロセスフロー効率性
　②コミュニケーション改善
　③学習効果
　④達成感

　ＴＷＩ：自分が知っていることを、メンバにつたえる学習方法
　①習う準備をさせる
　②作業を説明する
　③やらせてみる
　④教えた後を見る

　バリューストリームマッピング
　時間的な着地予測を行う手法⇒ムダを発見してカイゼン
　　プロセスタイム：事実上そのプロセスを実行している作業時間
　　リードタイム：プロセスが次のプロセスに移動するための所要時間

　⇒リードタイムを減らすポイント
　　①待ち時間が長く、ボトルネックとなっているプロセス
　　②手戻りが発生していて、その割合が高いプロセス
　　③不安な作業やいつも心配しながら作業しているプロセス

　⇒ＥＣＲＳ：どこからプロセスをカイゼンするのか
　　①Eliminate(排除）必要な業務　
　　②Combine(結合）待ち時間のむだや、過剰な作業分担
　　③Rearrage(交換）順番を変更することで中間生成物、やりとりを削減する
　　④Simplify(簡素化）複雑なタスク⇒単純化できないか

　ポストモーテム（検死）　プロジェクトがおわったら、事後検証を行う

　感謝のアクティビティ：メッセージカード

　タックマンモデル（チームの成長）
　　形成期⇒混乱期⇒統一期⇒機能期

■みんなを巻き込む

　リーダースインテグレーション
　①知っていること
　②知りたいこと
　③知っておいてほしいこと
　④みんなができること

　モダンアジャイル（心理的安全な場）
　①人々を最高に輝かせる
　②安全を必須条件とする
　③高速に実験＆学習する
　④継続的に価値を届ける

　ＣＣＰＭ
　×各タスクでバッファをもつ　⇒　〇全体でプロジェクトバッファを持つ

　むきなおりのフレームワーク（ＹＷＴ）
　　Ｙ：やったこと
　　Ｗ：わかったこと
　　Ｔ：次にやること

　スクラム・オブ・スクラム
　　スクラムマスターを集めた、チーム横断のデイリースクラム

　デザインプロセス
　　①サイトの全体像
　　②ラフ・スケッチ
　　③ペーパー・プロトタイピング
　　④ワイヤーフレーム
　　⑤ビジュアルデザイン
　開発プロセス
　　⑥コーディング　ＨＴＭＬ＆ＣＳＳの実装

　ユーザストーリーを評価する、ＩＮＶＥＳＴ
　　Ｉ：Independent：独立して優先順位がつけられる
　　Ｎ：Negotiable：何をつくるかの案が調整可能である
　　Ｖ：Valuable：価値のある
　　Ｅ：Estimable：見積可能である
　　Ｓ：Small：手ごろなサイズである
　　Ｔ：Testable：テストできる

　ギャレットの５段階　ＵＸを構築するための概念
　　①表面：視覚的デザイン
　　②骨格：インフォメーションデザイン、ナビゲーションデザイン、インタフェースデザイン
　　③構造：インフォメーションアーキテクチャー、インタラクションデザイン
　　④要件：コンテンツ要求、機能要求
　　⑤戦略：ユーザニーズ、サイトの目的

　視座、視点を変える
　　仮説キャンバス
　　ビジネスモデルキャンバス
　　リーンキャンバス

　ＭＶＰ:Minimum Viable Product：ユーザにとって価値があり、かつ最小限の機能性をもった製品
　⇒　ユーザストリートマッピング　で、本当に価値があるものに絞り込む

　リーダシップスタイル
　　Ｓ１：教示的　具体的に指示し、事細かに監督する
　　Ｓ２：説得的　こちらの考えを説明して、疑問に答える
　　Ｓ３：参加的　考えを合わせて決められるよう仕向ける
　　Ｓ４：委任的　仕事の遂行の責任を委ねる

目次

はじめに

プロローグ　終わりなきジャーニー

第1部　一人から始める

・第01話　会社を出ていく前にやっておくべきこと
・第02話　自分から始める
・第03話　一人で始めるふりかえり
・第04話　一人で始めるタスクの見える化
・第05話　明日を味方につける
・第06話　境目を行き来する
・第07話　二人ならもっと変えられる
・第08話　二人から越境する

第2部　チームで強くなる

・第09話　一人からチームへ
・第10話　完成の基準をチームで合わせる
・第11話　チームの向かうべき先を見据える
・第12話　僕たちの仕事の流儀
・第13話　お互いの期待を明らかにする
・第14話　問題はありませんという問題
・第15話　チームとプロダクトオーナーの境界
・第16話　チームとリーダーの境界
・第17話　チームと新しいメンバーの境界
・第18話　チームのやり方を変える
・第19話　チームの解散

第3部　みんなを巻き込む

・第20話　新しいリーダーと、期待マネジメント
・第21話　外からきたメンバーと、計画づくり
・第22話　外部チームと、やり方をむきなおる
・第23話　デザイナーと、共通の目標に向かう
・第24話　視座を変えて、突破するための見方を得る
・第25話　広さと深さで、プロダクトを見立てる
・第26話　チームで共に越える
・第27話　越境する開発

エピローグ　自分の世界を広げる

本書の解説としてのあとがき
付録
購入特典について
参考文献
索引

ISBN：9784798153346
判型：A5
ページ数：280ページ
定価：2300円（本体）
2018年02月07日初版第1刷発行
2021年02月05日初版第6刷発行

0

2025年07月14日

カイゼン・ジャーニーたった1人からはじめて、「越境」するチームをつくるまで

ビジネス・実用

IT・コンピュータ / 言語・プログラミング

4.4

(32)

Posted by ブクログ

物語ベースで進むので、非常に読みやすかった。
スクラム開発における、要素で自分が知らないことも結構あったので、参考になりそう。もし、スクラムマスターや、チーム作りの中心となって何かPJに関わることになる時は、この本をざーっと読み返して、使えそうなものを取り入れてやってみたいと思いました。

0

2025年04月22日

カイゼン・ジャーニーたった1人からはじめて、「越境」するチームをつくるまで

ビジネス・実用

IT・コンピュータ / 言語・プログラミング

4.4

(32)

Posted by ブクログ

アジャイルの進め方を物語風に紹介していてイメージしやすい。
いきなり最初から上手くいくわけではなく、少しずつ改善されていく感じも良い。
ただし、物語風のあるあるだが、難しい調整のところなど、実際にはそんな上手くいかないだろうと思ってしまうところもある。

物語の中で、多くのフレームワークの説明がある。
バリューストリームマッピング等、他ではあまり見ないものもあって参考になった。

「それで、あなたは何をしている人なんですか？」という問いかけが素晴らしい。
自分はまだちゃんとこの問いに答えられない。
そして、自分から始める。ということ。
単なるツールの使い方だけじゃなく、マインド的にも強く心に残る一冊。

0

2025年02月04日

ここはウォーターフォール市、アジャイル町ストーリーで学ぶアジャイルな組織のつくり方

ビジネス・実用

IT・コンピュータ / 言語・プログラミング

4.2

(23)

Posted by ブクログ

「企業体質が根本的に変わらなければアジャイル開発はできない」という考えを改めさせてくれる本。

現場の小チームからでも、アジャイルの理念を少しずつ取り入れて共感者を作っていけば、やがて組織レベルでの改革にも繋がっていくかもしれない。必ずしも0 -> 1ではなく、時には0.5、0.7のアジャイルを目指すような寛容さと柔軟さを持って、チームと向き合っていきたいと思った。

0

2024年10月19日

ここはウォーターフォール市、アジャイル町ストーリーで学ぶアジャイルな組織のつくり方

ビジネス・実用

IT・コンピュータ / 言語・プログラミング

4.2

(23)

Posted by ブクログ

タイトルと帯の文言を見た第一印象は「ウォーターフォールとアジャイルの共存がテーマ」という感じ。

実際の内容は、うまく機能していないプロジェクトをどう改善するかに主眼が置かれ、その過程でウォーターフォール開発を採用しているプロジェクトにアジャイル開発を「いいとこどり」していく方法の紹介、でしょうか。

アジャイル開発教本としては、知識に加えて導入事例を交えての紹介となるので、実践を踏まえた知識を得られるのは良いと思います。

以下2点はあくまで個人的な意見になるのですが……

~~~
1点目は、プロジェクトが機能不全に陥っている要因は、開発手法に問題があるからではない、ということ。

本書の事例でも、機能不全の要因は明らかにコミュニケーション不足（特に部署間）。アジャイル開発はコミュニケーションを重視しており、コミュニケーションをとらざるを得ないやり方が多いため、結果として機能不全解消につながっていったと考えています。

なので、ウォーターフォール開発でも、要件定義や設計を行う場合はその作業担当者だけで考えず、実装担当や運用担当なども巻き込んで要求分析などができれば、本書序盤のような機能不全に陥ることは少ないと思います。

そうしたコミュニケーション活性化を促すスキーム作りも、プロジェクトマネージャの役割の一つなのだと、改めて気づかされました。

2点目は、安易に（特に新規プロジェクトにおいては）ウォーターフォール・アジャイル共存状態から始めない方が良いのでは？という点。

それぞれの開発手法のエッセンスを「なぜそのやり方なのか」を理解せずに導入すると、本質が抜け落ちて結果として「いいとこどり」にならず、むしろデメリットの集合体になるリスクがあります（実際にそうなっていたプロジェクトを経験したことがあります）。

異なる開発手法の一部要素を取り入れる場合は「どういう目的でこのやり方になっているのか」を関係者みんなが正しく理解したうえで、それを取り入れるようにしたいです。
~~~

という感じで意見が分かれる点もあるかもしれませんが、プロジェクト管理について考えさせられるいいきっかけになりましたし、その点を抜きにしても、アジャイル開発導入のテキストとしてはかなりわかりやすい内容と思います。

全体的に表現もやわらかめで難しい言葉遣いも少ないので、新人やこれまであまりプロジェクト管理系の本を読んだことがない人にも薦めやすい気がします。

0

2024年07月26日

作品一覧

ユーザーレビュー