あらすじ
「日本の現場」に寄り添った、アジャイル開発の実践！
現場のストーリーで、開発の神髄を学ぼう
【本書の特徴】
・現場のストーリーから、考え方とプラクティスを一緒に学べる
・1人でも始められる業務改善の手法から、チームマネジメントの手法まで解説
・日本の現場を前提にしているので、実践しやすい
・アジャイルをこれから始める人だけでなく、もっとうまく実践したい人にも最適
【あらすじ】
ITエンジニアとしてSIer企業に勤務する江島は、
問題だらけのプロジェクト、やる気のない社員たちに嫌気が差していた。
そんな中、ある開発者向けイベントに参加したことがきっかけで、
まずは自分の仕事から見直していこうと考える。
タスクボードや「ふりかえり」などを1人で地道に続けていると、
同僚が興味を示したため、今度は2人でカイゼンに取り組んでいく。
ここから、チームやクライアントを巻き込んだ、現場の改革がはじまる。
チーム内の軋轢、クライアントの無理難題、迫りくるローンチ……
さまざまな困難を乗り越え、江島がたどり着いた「越境する開発」とは。
【筆者コメント（「あとがき」より）】
良い問いは人を立ち返らせてくれます。
そのような問いは人によって異なるでしょう。
読者のみなさんにとっての良い問いと出会えるよう、
江島（本書の主人公）同様、自分がいる場所から外に出て、
いろいろと見聞きしてみてください。
もちろんこの本があなたにとっての
良い問いになることを願っています。
※本電子書籍は同名出版物を底本として作成しました。記載内容は印刷出版当時のものです。
※印刷出版再現のため電子書籍としては不要な情報を含んでいる場合があります。
※印刷出版とは異なる表記・表現の場合があります。予めご了承ください。
※プレビューにてお手持ちの電子端末での表示状態をご確認の上、商品をお買い求めください。
感情タグBEST3
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刷発行
Posted by ブクログ
物語ベースで進むので、非常に読みやすかった。
スクラム開発における、要素で自分が知らないことも結構あったので、参考になりそう。もし、スクラムマスターや、チーム作りの中心となって何かPJに関わることになる時は、この本をざーっと読み返して、使えそうなものを取り入れてやってみたいと思いました。
Posted by ブクログ
アジャイルの進め方を物語風に紹介していてイメージしやすい。
いきなり最初から上手くいくわけではなく、少しずつ改善されていく感じも良い。
ただし、物語風のあるあるだが、難しい調整のところなど、実際にはそんな上手くいかないだろうと思ってしまうところもある。
物語の中で、多くのフレームワークの説明がある。
バリューストリームマッピング等、他ではあまり見ないものもあって参考になった。
「それで、あなたは何をしている人なんですか？」という問いかけが素晴らしい。
自分はまだちゃんとこの問いに答えられない。
そして、自分から始める。ということ。
単なるツールの使い方だけじゃなく、マインド的にも強く心に残る一冊。
Posted by ブクログ
物語に沿ってアジャイル開発・スクラムの考え方とプラクティスを説明しており、頭に入ってきやすい。自分も良い開発手法とかある！ってなっても人に紹介するだけして止まってたタイプ。「他人と過去は変えられないが、自分と未来は変えられる」という名言もありますが、他責にせずまず自分から行動してみる。という基本的なことが大事であることを再認識できました。
Posted by ブクログ
アジャイルの進め方、マインド、ツール、視点を変えるなど、とても参考になる。単なるノウハウではなく、前提条件と人としてのあり方にも根差したカイゼンを学ぶ。
幾つか分からぬこともあったが、ポストモーテムを実際やってみて効果も感じる。開発側の話が中心だが、発注側のユーザーやステークホルダー、POチームのあり方ももっと掘り下げていきたい。
まだまだ、咀嚼して、トライして、やって行こうと思う。私の旅は始まったばかり。
Posted by ブクログ
SIerの働き方が知れて面白かった。
どのチームでも不満があるなら自分が行動するしかない。
開発のスコープだけでなく、ユーザーインタビューとかもやればいい。
Posted by ブクログ
エンジニア向けの本かと冒頭で思いましたが、広く活用できる内容でした。
特に、インセプションデッキ、ドラッカー風エクササイズ、仮説キャンバスが自身にとっては役立ちそうです。
アジャイル開発のみならず、チームで働く上で大切なことをストーリーに沿って学ぶことができます。
Posted by ブクログ
アジャイルとはというよりも
カイゼンとは何か、どういう手法があるか、そしてなによりも自分の考えを向きなおることができる書籍だと思います。
特にですが今に不満がある方にはぜひ読んで欲しいと思います。
Posted by ブクログ
これはサービスなどに関わる人にとって、読むべき本だ。
顧客への価値の届け方、そのための取組み手法が、小説だてて見事に擬似体験出来るように描かれている。例えばDX、サブスクなどのキーワードに関わっていて、でもどうやったら良いのだろうと思っている人なら、皆が知りたいと思っている内容じゃないだろうか。
正直、一部はエンジニア向けの言葉が含まれているので、？と思う箇所がある人もいるかも知れない。でも、そこはサラッと流して、仕事の取り組み方として全体をさらっと理解すれば、物凄く価値がある内容と気づけると思う。
Posted by ブクログ
実際の開発現場を経験したことがある人にはすごく刺さる！
エンジニアじゃない人にもオススメできるような思考フレームワークがたくさんあっておすすめです。
何回か読み返す本になりそう
Posted by ブクログ
システム開発における様々な問題を、主人公が成長しながら解決していく物語。
他の一般的な書籍と違い、物語として読むことができるため、自分の境遇と比較しながら読みすすめることができます。ポイントを逐一紹介しているため、説明はとても分かりやすいです。特に一番最後のあとがきで全てをまとめているのはとてもありがたかった。
主題は物語ではなく、様々な問題をどうやって解決するかを学ぶことなので、物語の全てが
・問題発生
・解説
・解決策を遂行
・うまくいった
という流れで進みます。1〜2章は解決策を他人が提示するので、まるでドラえもんみたいだと感じましたが、学びを得るのが主題なのでやむを得ないかなと思います。
主人公が最初に絶望していた割に、本人も周囲も都合が良すぎると感じることもあるにはありますが、そもそも物語の形をとって解説をしている本なので、出来事にリアリティがないことを責めるのもちょっと違うかなと思います。(リアリティ重視で分かりにくいと本末転倒ですし)
1つだけ不満を言うならば、発生する問題がほぼ全て解決手段の提示ありきで、特にスクラム開発における解決手法を次々と利用していく流れなのですが、手段はともかくなぜその解決策なのか、この問題の本質はどこなのかといった、手段を講じる前の段階を深く掘り下げてほしかったと思います。
とはいえ、全体的にはわかりやすくまとめられており、読後感も良いのでおすすめです。
Posted by ブクログ
新規事業のシステム開発は要求や仕様が明確でない場合がほとんど。
何を作るか、何故作るかを常に考えるが、
それが正解かどうかは分からない。
分からない中でも前に進んでいくために
アジャイルの考え方は必要だと思う。
ただ、チーム全員がその考えを持っていることは少なく考えを浸透させるのは難しい。
この本ではフィクションとしながらも
事実をベースにしているため
現場の緊迫感が伝わってきて良かった。
自分が一歩前に進むきっかけになりそう。
アジャイルや、事業開発で使うツールや
その使い方が分かりやすく説明されており
解説書としても使えそう。
一人でできること、
チームで出来ること、
チーム外部と出来ること、を
ストーリーと解説を交えて
記載されているのも読みやすい。
それで、あなたは何をしている人なんですか？
Posted by ブクログ
版元の翔泳社の方からいただきました。
本書は、プロジェクトを前に進めるために、さまざまなプラクティスがストーリーの中で紹介されています。
・KPT
・カンバン
・インセプションデッキ
・狩野モデル
・合宿
・期待マネジメント
・ユーザーストーリーマッピング
etc
世のプロジェクト、プロダクトマネージャーで悩みがある人には是非手に取ってもらいたい本です。
自分のもつプロジェクトでの悩みの解決の一歩がかかれてるかもしれません。
私は書かれてました。
Posted by ブクログ
開発現場の問題を物語を通して、いろいろな解決手法を用いて、解決していくお話し。
開発現場でよくあるは問題が取り上げられているため、とても実用的な書籍でした。
Posted by ブクログ
技術書を読むのが得意ではないのだけど、物語仕立てで読みやすかった。
主人公がエンジニアで日本が舞台なので、
あるあるとか、さすがにそうはうまくいかんやろとか、
自分と重ねることができるし、
今後いろいろな場面で江島なんかやってたなーみたいなヒントになりそう。
Posted by ブクログ
# SIerのとしての、自分の世界を変えていく、一人の旅人の物語
## 面白かったところ
* アジャイル開発は決まった型はない事が、ストーリーベースだからわかる
* アジャイル開発すらも、プロジェクトに合うのか検討している
* 突然チームで始めるのではなく、個人単位で始めている
## 微妙だったところ
* 主人公が「何をするひと」なのかは読み進めればわかったのだが、一言では名言されていない点がもやもやした
## 感想
「なんちゃってアジャイル症候群」なんて病気もあるくらい、実際にアジャイル開発を手を動かしてみないとどんなものなのかはわからない。
自身も自分で始めたわけではないし、わからないことが多いからこそ、この本を拠り所にしている。
この本に答えが書いてある時もあればそうでないときもある。
だが何かしらの答えやきっかけを与えてくれるこの本は、とても重宝している。
Posted by ブクログ
読み物になっているので読みやすい。ある程度アジャイルやXPの前提知識がある方が読みやすいと思うけど、逆にそのあたりへの取っ掛かりとして読むのもいいかもしれない。
とにかくお手軽なのが本書の素晴らしい点だと思う。
Posted by ブクログ
時間のない中で合宿したりスクラムのフレームワークを使って整理したりする店が実際にやってられるのかと感じた。また、スクラムマスターがあっという間にいなくなったのでスクラムマスターの働きがあまり詳しく理解できなかった。
しかし、さまざまなフレームワークが紹介されていて実際に参考になりそうな知識がたくさんあつた。
もう一度大事な部分は読み返して理解を深めたい
Posted by ブクログ
アジャイルサムライを読んだ後に読むと良さそうな本。
実際の開発現場で起こりそうなエピソードとともに、課題解決に使えそうなプラクティスがうまく紹介されている。立場を超えて問題と向き合う、自分から相手の立場に越境して一緒に難関を乗り越える、それがカイゼンジャーニーというタイトルの意図するところらしい。
開発者から見ると、発注側のリテラシーを責めたくなることも多いけど、発注側は発注側の事情で、予算やリスクと向き合う必要がある。現実には簡単には乗り越えられない問題ばかりかもしれないけれど、いろいろな人の経験から勇気をもらいながら乗り越えていきたい。
ちょっとライトノベル的なノリが苦手な人もいるかもしれないけれど、それゆえの読みやすさもあるし、もしドラよりも共感できる。もっと流行ってほしいなｗ。
Posted by ブクログ
完全にリモートワークでのスタイルとなった今、これを良い機会としてコンサルティングという仕事の進め方を見直したいという問題意識の元、プロジェクトスタイルという仕事の進め方が似ているITシステム・サービス開発から学ぶべきは多いのでは、という仮説から手に取ったのが本書。
ストーリー仕立てでアジャイル開発、特にスクラムの方法論を学ぶことができる。こうした具体的な方法論にちゃんと触れるのは実は初めてであり、具体的かつ様々な失敗も踏まえて改良された方法論のシャープさが非常に面白い。
例えば、コンサルティングという仕事では、クライアントに納品するアウトプットを当然、一定の大きさのモジュールに切り分けて各コンサルタントが分担することが一般的である。その際、分析の手法やスライドライティングのノウハウは、一定のお作法・ルールが決められている。とはいえ、細部になれば個々人の経験による独自のTipsなどがあるわけで、そうしたものの標準化にスクラムの開発Tipsである”モブプログラミング”(複数人で一つの画面を見ながら、ワイガヤ的にプログラミングする手法)を援用するとどうなるだろうか。
このような観点で、自身の仕事の進め方を改善する様々なヒントを得られた気がしており、さらにこの分野を突っ込んでいこうと思った次第。
Posted by ブクログ
主人公の若手プログラマーがひとりで始めた改善活動が、メンターらの導きによって成長し、改善活動が部署で共有され、他部署、他社を巻き込む流れになっていく。
そういうストーリーで読ませつつ、ティップスもしっかり解説されている。
読みやすく、わかりやすい。
Posted by ブクログ
ソフトウェア開発の仕事は大変だ。
毎日夜は遅いし、いつも炎上する。
それをなんとかしたいと思い、たった1人で行動を起こしてみた。しかし周りは誰も協力してくれない。そして挫折。やはり自分1人で開発現場をなんとかするなんて無理なのか？
あなたにも、そんな経験があるだろう。
この本は「ＩＴエンジニアに読んで欲しい！技術書・ビジネス書大賞２０１９」の技術書部門ベスト１０を受賞した人気の本だ。
著者は、ソフトウェア開発のコミュニティ「DevLove」を立ち上げた市谷聡啓氏と運営スタッフでもある新井剛氏。業界では有名なコミュニティだ。システム開発をしている多くのエンジニアが熱心に学んでいる。以前、私も参加して講演を拝聴させていただいたことがある。
・プロローグ
・第1部 一人から始める
第1話 会社を出ていく前にやっておくべきこと
第2話 自分から始める
第3話 一人で始めるふりかえり
第4話 一人で始めるタスクの見える化
第5話 明日を味方につける
第6話 境目を行き来する
第7話 二人ならもっと変えられる
第8話 二人から越境する
・第2部 チームで強くなる
第9話 一人からチームへ
第10話 完成の基準をチームで合わせる
第11話 チームの向かうべき先を見据える
第12話 僕たちの仕事の流儀
第13話 お互いの期待を明らかにする
第14話 問題はありませんという問題
第15話 チームとプロダクトオーナーの境界
第16話 チームとリーダーの境界
第17話 チームと新しいメンバーの境界
第18話 チームのやり方を変える
第19話 チームの解散
・第3部 みんなを巻き込む
第20話 新しいリーダーと、期待マネジメント
第21話 外からきたメンバーと、計画づくり
第22話 外部チームと、やり方をむきなおる
第23話 デザイナーと、共通の目標に向かう
第24話 視座を変えて、突破するための見方を得る
第25話 広さと深さで、プロダクトを見立てる
第26話 チームで共に越える
第27話 越境する開発
・エピローグ
本書は、ソフトウェア開発の現場で起きた様々な改善の様子を、ストーリーと解説という形でわかりやすく紹介している。物語形式なのでとても読みやすく、著者の実体験をベースにしているところが特徴だ。
物語は入社三年目のソフトウェアエンジニアのぼやきから始まる。
『現場のレベル感はひどく低い。いつもプロジェクトは炎上していて、目論見通りに終わることはまずない。メンバーの士気は低くて、プロジェクトの最初からたいていやる気がない。そんな感じだから仕事はうまくいかず、約束されていたかのように燃え盛り、それがまたメンバーの気持ちを挫いていく。ひどい循環だ。』
あなたの現場も、こんな感じではないだろうか。
そんな悩みを抱える主人公が、社外の勉強会に参加する。そしてそこで不思議なセッションに出会い、心を奪われてしまった。
「これは一体何の話なんだ？」
懇親会の席で、そのセッションの発表者に声をかけてみた。すると、逆に質問をされた。その「質問」が、彼の人生を変えることになる。
そして主人公の改善ストーリーは、自分1人でできることから始まり、チームでの取り組みに広がり、他チームを巻き込んだ組織の取り組みへと繋がっていく。
まるで、一本のローソクに灯った炎が、他のローソクに移って、どんどん明るくなっていくようだ。まさに「改善の旅」。KAIZEN JOURNEYだ。
私も、現場で新しいことを始めたり、有志を募って勉強会を開いたり、ささやかではあるが改善の旅を続けているが、本書に書かれていることは、現場で迷ったときに、とても参考になると感じている。やろうと思えば、明日からでも始められるノウハウばかりだ。
しかし実際に、書いてある通りにやろうとすると、なかなか大変なことは事実。「勇気」が必要だからだ。
現場の改善に「正解」は無いだろう。だから迷うし、こんな出すぎたこと自分がやってもいいのだろうか、と悩む。何かを始める勇気、最初の一歩を踏み出す勇気が、なかなか湧いてこないのだ。
著者は言う。
『「今の自分の延長線上に何があるのか」を想像したときに、特に変わりようがないと気づいたとき、行動を起こすことに踏み切れました。』
あなた自身のこれからを大切に思うなら、行動を起こすしかないのだ。
行動を起こすといっても、何もいきなり会社を辞めろと言っているわけではない。ゴミが落ちていたら拾うというレベルでも良い、と私は思う。大事なことは、あなたが良いと思ったことを、勇気を出してやってみることだ。そうしないと何も始まらない。
もしあなたが、現状を変えよう改善を始めてみたが、上手くいかなくて心が折れそうになったなら、ぜひこの本を読み返してみて欲しい。本書の登場人物たちが、あなたの、たったひとりの挑戦を後押しし、力強く応援してくれるだろう。
Posted by ブクログ
リーンでアジャイルなソフトウェア開発の考え方とプラクティスを、日本的な現場のストーリーから学ぶことができる。
ホワイトカラーの現場で起こる諸問題を、スクラムとXPのプラクティスで解決していく。極めてプラクティスが多く出てくるため、一読しただけではどのプラクティスがどの課題に対応するのか整理できない。曼荼羅のごとく、対応付けして整理する。
ーフレーズメモー
・仕事をよりうまくやるために何から始めるか？タスクマネジメント、タスクボード、朝会、ふりかえりの4つがある。仕事のカイゼンはまず状態の見える化から始めるべし。
・ふりかえりの基本。プロセスのカイゼンと不確実性の高い状況で前進することを目的とする。ふりかえりのやり方には、問題発見フェーズ、事実発見フェーズ、対策フェーズがあり、できるだけ可視化する。
・ふりかえりは他人に気づかせてもらう。だからこそチームでやる。
・むきなおり。1.ミッション、ビジョンを点検する。2.評価軸を洗い出し、現状を客観的に見定める。3.評価軸ベースであるべき姿と現状の課題を洗い出す。4.課題解決のために必要なステップをバックログにする。5.バックログの重要度と、一番効果の高いものを決める。6.時間軸を明らかにし、期限も明確に決める。
・バリューストリームマッピング。プロダクトの価値がお客さんの手に渡るまでの仕事の流れを見える化するプラクティス。流れのどこで付加価値が生まれるのか、プロダクトが滞りなく実現に向けて動いていけるのかを確認する。
Posted by ブクログ
ストーリー仕立てで説明されており、とある事例の参照にできる
本書でも触れられている通り、この事例でうまくいったからといって、自分の現場でうまくいくとは限らないというのは、覚えておく
問題は起きるけど、最後はどうにかするのがもやもやした。
Posted by ブクログ
ソフトウェア開発に携わったことがないので、描かれていることのひとつひとつが具体的にイメージできなかったり、共感しにくかったりすることが多かったが、チーム運営については参考になった。
それを一言でいうと、ひとはそれぞれ違うということ。それゆえひとが集まってできたチーム (自社の組織に留まらず、目的を共有する組織) というものは努力しないとベクトルが合わず、前進することができない。しかしその壁を乗り越えることで、違いを多様性として活かすことができる。
Posted by ブクログ
バラバラのチームが、幾多の強敵プロジェクトと戦いながら結束するまで。チームの開発技法を学べる物語
★本の概要・感想
システム・ソフトウェア開発における、チームワークの技法が詰まっている。実際にチームでシステム開発をしているなら、読めば役立つフレームに出会えるかもしれない。また、この本はチームの様々な状況を描いているため、自分たちの開発状況を客観視するのにも役立つ。特にスクラムマスターやマネージャーなどはこれらの本を読むと良いだろう。「こんなもんだ」と思っていた自社の開発環境が、実は時代遅れなものだったり。もっと効率の良い情報共有の仕方があるのに、それに全く気付いていない、というような可能性だってあり得る。私はデスクトップエンジニアであり、一人で業務アプリケーションのカスタマイズや改修を行うことが多い。個人的には直接的に生かせるものが少なかったものの、チーム開発の現場に移ったタイミングでまた読み返したいと思う。
★本の面白かった点、学びになった点
＊分割統治法をすること。大きなタスクを大きな言葉のままで扱うのを辞めよう
・認識の齟齬が発生しやすくなる。できる限り具体的な言葉で。分割して話すように
★本書の紹介しているフレーム
・アジャイル開発、スクラム、カンバン仕事術、モブプログラミング、バリューストリームマッピング、ユーザーストーリー、ゴールデンサークル、学習する組織、朝会、
●本を読んだだけでは応用できない
。物語の形式により、フレームの使用場面を想像しやすく、多くの手法が紹介されていた。
もちろん、その技法を知っているからと言って、すぐさま現場に応用はできない。知った上で、どう自分たちの開発に落とし込むか。そこは読者たちのと努力が必要である。また、多くのフレームが紹介されているがゆえに、各手法の記述は多くない。各技法を一つ一つ学んでいく必要もあるだろう
●学んだことをどうアクションに生かす
＊まぎれの無い明瞭な言葉を用いること
＊カンバン仕事術
＊思いやりを持って仕事する
Posted by ブクログ
自社開発関連でバラバラに作業を行なっているため、どうやればいいのかという足がかりを見つけるために買った。
エンジニアベースの問題解決の方法は物語ベースでわかりやすく書かれており、実践してみたいと思ったが、どちらかといえば開発メンバーというよりも善んたい的な巻き込み術をしりたかったので、私の期待とはちょっと違った。
