技術書を読むのが得意ではないのだけど、物語仕立てで読みやすかった。 主人公がエンジニアで日本が舞台なので、 あるあるとか、さすがにそうはうまくいかんやろとか、 自分と重ねることができるし、 今後いろいろな場面で江島なんかやってたなーみたいなヒントになりそう。

ストーリー仕立てで説明されており、とある事例の参照にできる 本書でも触れられている通り、この事例でうまくいったからといって、自分の現場でうまくいくとは限らないというのは、覚えておく 問題は起きるけど、最後はどうにかするのがもやもやした。

カイゼン・ジャーニー　たった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刷発行

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

アジャイルの進め方を物語風に紹介していてイメージしやすい。 いきなり最初から上手くいくわけではなく、少しずつ改善されていく感じも良い。 ただし、物語風のあるあるだが、難しい調整のところなど、実際にはそんな上手くいかないだろうと思ってしまうところもある。 物語の中で、多くのフレームワークの説明がある。 バリューストリームマッピング等、他ではあまり見ないものもあって参考になった。 「それで、あなたは何をしている人なんですか？」という問いかけが素晴らしい。 自分はまだちゃんとこの問いに答えられない。 そして、自分から始める。ということ。 単なるツールの使い方だけじゃなく、マインド的にも強く心に残る一冊。

物語に沿ってアジャイル開発・スクラムの考え方とプラクティスを説明しており、頭に入ってきやすい。自分も良い開発手法とかある！ってなっても人に紹介するだけして止まってたタイプ。「他人と過去は変えられないが、自分と未来は変えられる」という名言もありますが、他責にせずまず自分から行動してみる。という基本的なことが大事であることを再認識できました。

アジャイルの進め方、マインド、ツール、視点を変えるなど、とても参考になる。単なるノウハウではなく、前提条件と人としてのあり方にも根差したカイゼンを学ぶ。 幾つか分からぬこともあったが、ポストモーテムを実際やってみて効果も感じる。開発側の話が中心だが、発注側のユーザーやステークホルダー、POチームのあり方ももっと掘り下げていきたい。 まだまだ、咀嚼して、トライして、やって行こうと思う。私の旅は始まったばかり。

# SIerのとしての、自分の世界を変えていく、一人の旅人の物語 ## 面白かったところ * アジャイル開発は決まった型はない事が、ストーリーベースだからわかる * アジャイル開発すらも、プロジェクトに合うのか検討している * 突然チームで始めるのではなく、個人単位で始めている ## 微妙だったところ * 主人公が「何をするひと」なのかは読み進めればわかったのだが、一言では名言されていない点がもやもやした ## 感想 「なんちゃってアジャイル症候群」なんて病気もあるくらい、実際にアジャイル開発を手を動かしてみないとどんなものなのかはわからない。 自身も自分で始めたわけではないし、わからないことが多いからこそ、この本を拠り所にしている。 この本に答えが書いてある時もあればそうでないときもある。 だが何かしらの答えやきっかけを与えてくれるこの本は、とても重宝している。

SIerの働き方が知れて面白かった。 どのチームでも不満があるなら自分が行動するしかない。 開発のスコープだけでなく、ユーザーインタビューとかもやればいい。

エンジニア、プログラマーなど開発視点の構成。 フレームワークの使い方などビジネス、コンサル系にも応用がきく内容あり。 良い本でした。

エンジニア向けの本かと冒頭で思いましたが、広く活用できる内容でした。 特に、インセプションデッキ、ドラッカー風エクササイズ、仮説キャンバスが自身にとっては役立ちそうです。 アジャイル開発のみならず、チームで働く上で大切なことをストーリーに沿って学ぶことができます。

読み物になっているので読みやすい。ある程度アジャイルやXPの前提知識がある方が読みやすいと思うけど、逆にそのあたりへの取っ掛かりとして読むのもいいかもしれない。 とにかくお手軽なのが本書の素晴らしい点だと思う。

個人で、チーム内外で壁が立ち塞がった時に手段やアイデアを得るためにまた読みたい。自分もみんなと越境できたらと思う。

ソフトウェア開発に携わったことがないので、描かれていることのひとつひとつが具体的にイメージできなかったり、共感しにくかったりすることが多かったが、チーム運営については参考になった。 それを一言でいうと、ひとはそれぞれ違うということ。それゆえひとが集まってできたチーム (自社の組織に留まらず、目的を共有する組織) というものは努力しないとベクトルが合わず、前進することができない。しかしその壁を乗り越えることで、違いを多様性として活かすことができる。

時間のない中で合宿したりスクラムのフレームワークを使って整理したりする店が実際にやってられるのかと感じた。また、スクラムマスターがあっという間にいなくなったのでスクラムマスターの働きがあまり詳しく理解できなかった。 しかし、さまざまなフレームワークが紹介されていて実際に参考になりそうな知識がたくさんあつた。 もう一度大事な部分は読み返して理解を深めたい

アジャイルとはというよりも カイゼンとは何か、どういう手法があるか、そしてなによりも自分の考えを向きなおることができる書籍だと思います。 特にですが今に不満がある方にはぜひ読んで欲しいと思います。

アジャイルサムライを読んだ後に読むと良さそうな本。 実際の開発現場で起こりそうなエピソードとともに、課題解決に使えそうなプラクティスがうまく紹介されている。立場を超えて問題と向き合う、自分から相手の立場に越境して一緒に難関を乗り越える、それがカイゼンジャーニーというタイトルの意図するところらしい。 開発者から見ると、発注側のリテラシーを責めたくなることも多いけど、発注側は発注側の事情で、予算やリスクと向き合う必要がある。現実には簡単には乗り越えられない問題ばかりかもしれないけれど、いろいろな人の経験から勇気をもらいながら乗り越えていきたい。 ちょっとライトノベル的なノリが苦手な人もいるかもしれないけれど、それゆえの読みやすさもあるし、もしドラよりも共感できる。もっと流行ってほしいなｗ。

これはサービスなどに関わる人にとって、読むべき本だ。 顧客への価値の届け方、そのための取組み手法が、小説だてて見事に擬似体験出来るように描かれている。例えばDX、サブスクなどのキーワードに関わっていて、でもどうやったら良いのだろうと思っている人なら、皆が知りたいと思っている内容じゃないだろうか。 正直、一部はエンジニア向けの言葉が含まれているので、？と思う箇所がある人もいるかも知れない。でも、そこはサラッと流して、仕事の取り組み方として全体をさらっと理解すれば、物凄く価値がある内容と気づけると思う。

自分はなにをする人か。その問いを常にむねにおいて仕事に取り組みたいと思った。 1人でできるカイゼン活動もあるということが励みになり、さっそく実践している。

完全にリモートワークでのスタイルとなった今、これを良い機会としてコンサルティングという仕事の進め方を見直したいという問題意識の元、プロジェクトスタイルという仕事の進め方が似ているITシステム・サービス開発から学ぶべきは多いのでは、という仮説から手に取ったのが本書。 ストーリー仕立てでアジャイル開発、特にスクラムの方法論を学ぶことができる。こうした具体的な方法論にちゃんと触れるのは実は初めてであり、具体的かつ様々な失敗も踏まえて改良された方法論のシャープさが非常に面白い。 例えば、コンサルティングという仕事では、クライアントに納品するアウトプットを当然、一定の大きさのモジュールに切り分けて各コンサルタントが分担することが一般的である。その際、分析の手法やスライドライティングのノウハウは、一定のお作法・ルールが決められている。とはいえ、細部になれば個々人の経験による独自のTipsなどがあるわけで、そうしたものの標準化にスクラムの開発Tipsである”モブプログラミング”(複数人で一つの画面を見ながら、ワイガヤ的にプログラミングする手法)を援用するとどうなるだろうか。 このような観点で、自身の仕事の進め方を改善する様々なヒントを得られた気がしており、さらにこの分野を突っ込んでいこうと思った次第。

実際の開発現場を経験したことがある人にはすごく刺さる！ エンジニアじゃない人にもオススメできるような思考フレームワークがたくさんあっておすすめです。 何回か読み返す本になりそう

バラバラのチームが、幾多の強敵プロジェクトと戦いながら結束するまで。チームの開発技法を学べる物語 ★本の概要・感想 　システム・ソフトウェア開発における、チームワークの技法が詰まっている。実際にチームでシステム開発をしているなら、読めば役立つフレームに出会えるかもしれない。また、この本はチームの様々な状況を描いているため、自分たちの開発状況を客観視するのにも役立つ。特にスクラムマスターやマネージャーなどはこれらの本を読むと良いだろう。「こんなもんだ」と思っていた自社の開発環境が、実は時代遅れなものだったり。もっと効率の良い情報共有の仕方があるのに、それに全く気付いていない、というような可能性だってあり得る。私はデスクトップエンジニアであり、一人で業務アプリケーションのカスタマイズや改修を行うことが多い。個人的には直接的に生かせるものが少なかったものの、チーム開発の現場に移ったタイミングでまた読み返したいと思う。 ★本の面白かった点、学びになった点 ＊分割統治法をすること。大きなタスクを大きな言葉のままで扱うのを辞めよう ・認識の齟齬が発生しやすくなる。できる限り具体的な言葉で。分割して話すように ★本書の紹介しているフレーム ・アジャイル開発、スクラム、カンバン仕事術、モブプログラミング、バリューストリームマッピング、ユーザーストーリー、ゴールデンサークル、学習する組織、朝会、 ●本を読んだだけでは応用できない 。物語の形式により、フレームの使用場面を想像しやすく、多くの手法が紹介されていた。 　もちろん、その技法を知っているからと言って、すぐさま現場に応用はできない。知った上で、どう自分たちの開発に落とし込むか。そこは読者たちのと努力が必要である。また、多くのフレームが紹介されているがゆえに、各手法の記述は多くない。各技法を一つ一つ学んでいく必要もあるだろう ●学んだことをどうアクションに生かす ＊まぎれの無い明瞭な言葉を用いること ＊カンバン仕事術 ＊思いやりを持って仕事する

自社開発関連でバラバラに作業を行なっているため、どうやればいいのかという足がかりを見つけるために買った。 エンジニアベースの問題解決の方法は物語ベースでわかりやすく書かれており、実践してみたいと思ったが、どちらかといえば開発メンバーというよりも善んたい的な巻き込み術をしりたかったので、私の期待とはちょっと違った。

システム開発における様々な問題を、主人公が成長しながら解決していく物語。 他の一般的な書籍と違い、物語として読むことができるため、自分の境遇と比較しながら読みすすめることができます。ポイントを逐一紹介しているため、説明はとても分かりやすいです。特に一番最後のあとがきで全てをまとめているのはとてもありがたかった。 主題は物語ではなく、様々な問題をどうやって解決するかを学ぶことなので、物語の全てが ・問題発生 ・解説 ・解決策を遂行 ・うまくいった という流れで進みます。1〜2章は解決策を他人が提示するので、まるでドラえもんみたいだと感じましたが、学びを得るのが主題なのでやむを得ないかなと思います。 主人公が最初に絶望していた割に、本人も周囲も都合が良すぎると感じることもあるにはありますが、そもそも物語の形をとって解説をしている本なので、出来事にリアリティがないことを責めるのもちょっと違うかなと思います。(リアリティ重視で分かりにくいと本末転倒ですし) 1つだけ不満を言うならば、発生する問題がほぼ全て解決手段の提示ありきで、特にスクラム開発における解決手法を次々と利用していく流れなのですが、手段はともかくなぜその解決策なのか、この問題の本質はどこなのかといった、手段を講じる前の段階を深く掘り下げてほしかったと思います。 とはいえ、全体的にはわかりやすくまとめられており、読後感も良いのでおすすめです。

新規事業のシステム開発は要求や仕様が明確でない場合がほとんど。 何を作るか、何故作るかを常に考えるが、 それが正解かどうかは分からない。 分からない中でも前に進んでいくために アジャイルの考え方は必要だと思う。 ただ、チーム全員がその考えを持っていることは少なく考えを浸透させるのは難しい。 この本ではフィクションとしながらも 事実をベースにしているため 現場の緊迫感が伝わってきて良かった。 自分が一歩前に進むきっかけになりそう。 アジャイルや、事業開発で使うツールや その使い方が分かりやすく説明されており 解説書としても使えそう。 一人でできること、 チームで出来ること、 チーム外部と出来ること、を ストーリーと解説を交えて 記載されているのも読みやすい。 それで、あなたは何をしている人なんですか？

カイゼン・ジャーニーの途中で、むきなおる: Meet Up 大阪 @ blog http://www.meetuposaka.com/article/465462539.html

版元の翔泳社の方からいただきました。 本書は、プロジェクトを前に進めるために、さまざまなプラクティスがストーリーの中で紹介されています。 ・KPT ・カンバン ・インセプションデッキ ・狩野モデル ・合宿 ・期待マネジメント ・ユーザーストーリーマッピング etc 世のプロジェクト、プロダクトマネージャーで悩みがある人には是非手に取ってもらいたい本です。 自分のもつプロジェクトでの悩みの解決の一歩がかかれてるかもしれません。 私は書かれてました。

開発現場の問題を物語を通して、いろいろな解決手法を用いて、解決していくお話し。 開発現場でよくあるは問題が取り上げられているため、とても実用的な書籍でした。

最近読んだ本で間違いなくナンバーワン！！現状を打破したい人が読めば確実にモチベーションが上がる。新入社員全員に配っても良いと思える本。 より詳細なコメントは下記に記載。 https://fatherofikura.hatenablog.com/entry/本/2019_05

読書感想文書きました。 https://jumpyoshim.hatenablog.com/entry/book-report-of-kaizen-journey

ソフトウェア開発の仕事は大変だ。 毎日夜は遅いし、いつも炎上する。 それをなんとかしたいと思い、たった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だ。 私も、現場で新しいことを始めたり、有志を募って勉強会を開いたり、ささやかではあるが改善の旅を続けているが、本書に書かれていることは、現場で迷ったときに、とても参考になると感じている。やろうと思えば、明日からでも始められるノウハウばかりだ。 しかし実際に、書いてある通りにやろうとすると、なかなか大変なことは事実。「勇気」が必要だからだ。 現場の改善に「正解」は無いだろう。だから迷うし、こんな出すぎたこと自分がやってもいいのだろうか、と悩む。何かを始める勇気、最初の一歩を踏み出す勇気が、なかなか湧いてこないのだ。 著者は言う。 『「今の自分の延長線上に何があるのか」を想像したときに、特に変わりようがないと気づいたとき、行動を起こすことに踏み切れました。』 あなた自身のこれからを大切に思うなら、行動を起こすしかないのだ。 行動を起こすといっても、何もいきなり会社を辞めろと言っているわけではない。ゴミが落ちていたら拾うというレベルでも良い、と私は思う。大事なことは、あなたが良いと思ったことを、勇気を出してやってみることだ。そうしないと何も始まらない。 もしあなたが、現状を変えよう改善を始めてみたが、上手くいかなくて心が折れそうになったなら、ぜひこの本を読み返してみて欲しい。本書の登場人物たちが、あなたの、たったひとりの挑戦を後押しし、力強く応援してくれるだろう。

リーンでアジャイルなソフトウェア開発の考え方とプラクティスを、日本的な現場のストーリーから学ぶことができる。 ホワイトカラーの現場で起こる諸問題を、スクラムとXPのプラクティスで解決していく。極めてプラクティスが多く出てくるため、一読しただけではどのプラクティスがどの課題に対応するのか整理できない。曼荼羅のごとく、対応付けして整理する。 ーフレーズメモー ・仕事をよりうまくやるために何から始めるか？タスクマネジメント、タスクボード、朝会、ふりかえりの4つがある。仕事のカイゼンはまず状態の見える化から始めるべし。 ・ふりかえりの基本。プロセスのカイゼンと不確実性の高い状況で前進することを目的とする。ふりかえりのやり方には、問題発見フェーズ、事実発見フェーズ、対策フェーズがあり、できるだけ可視化する。 ・ふりかえりは他人に気づかせてもらう。だからこそチームでやる。 ・むきなおり。1.ミッション、ビジョンを点検する。2.評価軸を洗い出し、現状を客観的に見定める。3.評価軸ベースであるべき姿と現状の課題を洗い出す。4.課題解決のために必要なステップをバックログにする。5.バックログの重要度と、一番効果の高いものを決める。6.時間軸を明らかにし、期限も明確に決める。 ・バリューストリームマッピング。プロダクトの価値がお客さんの手に渡るまでの仕事の流れを見える化するプラクティス。流れのどこで付加価値が生まれるのか、プロダクトが滞りなく実現に向けて動いていけるのかを確認する。

こういう手法あるよなというのはわかったけどチームがどう成長していっているのかがいまいちピンとこなかった。

# 書評☆3 カイゼン・ジャーニー | ソフトウェア開発のおとぎ話 ## 概要 ネット上での評判がよく，[ITエンジニアに読んでほしい！技術書・ビジネス書 大賞2019](https://www.shoeisha.co.jp/campaign/award/2019/result) にノミネートされていたので興味を持って読んだ。 ソフトウェア開発の現場をよりよくするために，著者の経験を元にしたフィクションのストーリーとその解説を中心とした内容となっている。スクラムやらチームづくりなどについて書かれている。 ただし，自分にはあまり響かなかった。というのも，第一部であるように，結局，自分の考えに賛同する都合のいい人物の登場により状況が改善するからだ。 また，チームづくりに関しても小手先のテクニックな感じがしてならなかった。チームづくりに関しては，チームというよりかは人と人とのコミュニケーションについての本のほうが役に立つ気がした。例えば，デール・カーネギーの名著「人を動かす」であったり，先日読んだ「[ 人を助けるとはどういうことか](https://senooken.jp/blog/2019/02/25/)」などだ。 そもそもスクラムやらこの本で述べられている開発手法については経験したことがなく，おとぎ話のように感じてしまった。一度体験しないと理解できないだろう。 ## 参考 > ### p. 044: タスクボードの基本 > TODOを洗い出すと、すっきりする反面、量が多くなってタスクの全体像が俯瞰しづらくなる。だから、TODOには直近で必要な一定期間分のタスクのみを貼り出すようにして、先々のタスクや気付いたことなんかは、別の場所にためておくようにすると良いだろう。この場所を、Icebox (冷凍庫) といったり、Parking Lot (駐車場) と呼んだりする。優先順位をつけずに、いったん預けておく場所という意味合いだ。 > > タスクには取り組むべき順番がたいていはある。TODOのステージで、上下の並びで優先順位を表現すると良いだろう。 Kanbordというカンバン方式のタスクボードサービスを使っている。カンバン方式のタスク管理はやり方がいまいちよくわかっていなかった。普通に使うと，TODOが大量に出てしまい，縦に間延びしてしまう。ここでタスクボードの使い方が参考になった。 ## 結論 ネット上での評判が良かったので期待していたのだが，自分には合わなかった。こういう開発手法というのは，周りにある程度理解者がいたり，自分が権力を行使できる立場にならなければ，発揮できない。 こうしたことができるような現場に入ることや，もっと根本的には人とのコミュニケーションの取り方について学んだほうが有益ではないかと感じた。 パーマリンク: https://senooken.jp/blog/2019/03/05/

仕事の進め方も参考になりますが、個人的には仕事に対する姿勢の部分が好きです。 転職したことのある身としては、職場への不満がたまる様が共感でき、それでも自分の持ち場で周りを変えようとしていく主人公の姿がヒーローに見えました。本にも書かれているとおり職場はそれぞれ違った制約があるでしょうが、周りのモチベーションを引き出しながら前を見て進むことは、どこでも変わらず大切なことなのだと思います。

ストーリー付きでイメージしやすくなるのはGood(小説じゃないので当然ながら質はいまいちだが) フレームワークの辞書として使う形がいいかなと。

旧来的なシステム開発をどのように変えていくかをストーリー仕立てで記述した一冊。 方法論の解説も分かりやすく、ウォーターホール開発から脱出したいと考えている人にはとてもよいです。 スクラム開発の経験はありますが、それ以外のプラクティスも取り入れていきたいと感じました。 私もシステム開発手法をどうにかしたいと考えているので、非常に参考になりました。

様々なカイゼン手法が本書では紹介されている。これだけの手法の紹介があれば、とりあえずこの一冊あれば大丈夫だ、と思わせてくれる本である。そして、それらの手法がバラバラになっているのではなく、小説によってうまく接続されていく、そういった本である。 新しい手法を短期間に組織に浸透させていくのは大変なことである。急ぎすぎると、形だけを取り入れて、その目的からそれていったり、うまくいかない状態になりそれを理由に他のメンバーに拒絶されたり、といったことがある。そうならないために、まずは本書で示されているように、一人、または二人で始めて、失敗を経験し、理論武装した上で組織に展開していく、というアプローチが良いのであろう。

仕事の現場において現状を変えたい・周囲を巻き込んでカイゼンしたいけれどもどうすれば良いか分からない、と悩んでいる人にうってつけの実践書です。 主人公が様々な壁を「越境」していくストーリー仕立てですが、随所にアジャイル（主にスクラム）のプラクティスが紹介されていて自然と頭に入っていく感覚です。 ITエンジニアのみならず、何らかのプロダクトに関わる人やマネージャー職に就いている人にとっても共感できる部分も多いのではないでしょうか。 まずは一人からカイゼンを始めて、それが二人になり、次に数人のチームで、社内の複数チーム、社外のステークホルダー、、、といったように徐々に巻き込む対象がスケールアウトしていく様子が非常に爽快です。

現場のカイゼンを進めている自分に今までのふりかえりと次の一手を示してくれた。プラクティスがこんなにまとまっている本は他にない。オススメ！

スクラム開発を進める際に、立ちはだかる課題に対して、様々なTipsを提供してくれる本。スクラム以外でもカイゼンをしている人も応用できる役立つ内容が多く、ストーリー仕立てなので楽しく読める。スクラムブートキャンプと合わせて、初めての人に読んでほしい。

プロジェクトの進行について、1人・チーム・外部とまとめた例示を描いた小説。 1ページに占める文字数が多く、ページ数も意外に多い(本自体は薄いように思った)ので、読み終わるまで時間がかかった。もちろん、それだけボリュームも多い。 今自分が関わっているプロジェクトだと、朝会ぐらいはやってるけど、他は全然だなぁ。ペアプログラミングってよく聞くけど、そんなにやってる人って多いのだろうか？　自分もやったことないし、周りでも見たことない。 勉強会だと、最近ちょこちょこうちの会社でもやるようになってきたけど、外部の人を呼ぶのってどういう感じなんだろう。やっぱり、知り合いでもお金を払ってきてもらう感じになるのか？　相場がどれぐらいなのか全然分からない。 それにしても、「サービスを作りたくなったから辞めた」という登場人物がでてきたけど、これってよくあることなんだろうなと思う。こないだ、うちの会社でも、長年勤めていて技術力もあり、社内のイベントもよく参加して社内勉強会主催するような人が、アプリを作りたいとかいう理由で辞めたんだよなぁ。やっぱり、自社開発は増やしたほうが社員は辞めないんじゃないかなと思った(そう単純なことでもないだろうけど)。 モブプログラミングというのはちょっとおもしろそうだなと思った。実際やるとなると緊張しそうだけど。逆に、感謝のアクティビティはやりたいと思わなかった。こんなこと強制されたら嫌だ。ハンガーフライトというのはちょっと面白そうだしやっていいかなとも思った。まあ、イベント行事で集まることもあるし、その時にやればいいだけか。 そういえば、ところどころで「塹壕」という言葉がでてきて、どういう意味なんだろうと思ったら、「戦場で、歩兵が敵弾を避けるために作る防御施設」ということらしい。うーん、なんかよく分からない。これだと、塹壕からでていくというと戦場にいくということになりそうなのだけど、この本では「塹壕をでていきたくなる」というふうに使われてあって、これが戦争のない世界ということなら、「戦場をでていきたくなる」でいいのではないのかと。 ところで、コードを書くと人が変わってしまうキャラがでてきたのだけど、そういう人ってよくいるのだろうか。こち亀の本田を思い出した。

悪くはないと思う。 しかし、好みの問題だと思うが、 自分はふつうのアジャイルの本読んだほうが早いと思った。

物語形式で、開発現場を改善するための手法を紹介していく書籍です。 物語で起こる現場の問題が「あるある」と頷ける内容で、実践に活かしやすいと思います。 物語形式にすることで、単なる手法の解説だけでなく裏側にある人の気持ちや思いを表現されているのがよかったです。テクニックとパッションの両輪があってはじめて現場はカイゼンされるのだと思います。 何度も読み返したい本。漫画化希望。

今まで読んだ「初めてアジャイルに挑戦する」系の本はどれもそれほどギクシャクした雰囲気にならずに済んでいたけれど、本書ではそれがある。個性が強い（個性を強く出す）人が多い職場だとしたら、そのほうが現実に近いかも。それと他書と違う点を上げるとすれば、「一人からでも始められる」というのが示されている点かな。「気づいたときが始めどき、遅すぎることはない」みたいな。

有名どころのプラクティスや著者が試行錯誤されて創られた「仮説キャンバス」がストーリーと調和しながら紹介されており、プラクティスを使う場面のイメージがとても分かりやすく入ってきます。 たくさん勉強会に参加されたり、いろいろインプットしすぎてきた方にもお勧めしたいです。 書籍に紹介されている「ハンガーフライト」。硬く考えずに実際にやってみようと思いました。背中を一押ししてもらえました。ありがとうございます。 ドラマ化？アニメ化？とかされるともっと多くの人の背中を一押しできるかもしれませんね！（妄想）

ソフトウェア開発の現場を、一人きりの状態からやがて他組織を巻き込むまでに改善していく物語パートと、その中で使用されたプラクティスなどの解説パートが交互に挟まっている形式。解説は物語の登場人物が行う。 物語部分はザ・ゴールを思わせるが、請負契約など、より日本らしい雰囲気が漂う。また、物語形式は「読みやすいが体系的な知識を得にくい」とという点を、解説パートが補っている。 本書に登場するプラクティスは多岐にわたり、著者らの経験の深さが垣間見える。そして、それらが必ずしも予定調和的に適切なタイミングで使用されている訳でないところも、物語の「それっぽさ」に一役買っている。 よく分からなかったのは、Appendixで「越境」など5つの項目を「価値」として挙げている事。 越境は価値だろうか。価値を得るための手段ではないのだろうか。

開発の現場にいるわけではないけど、お互いの期待をすり合わせる、目的を共有する、などなど、自分の仕事の中でも使える考え方と仕組みがたくさんあるし、使いこなせるようになりたいなと思った。仕事の仕方や特徴は結構違うので、どう活かすかは、もう少し整理が必要だけど、考え方のベースとしては非ITの仕事の場面にももっと活かせるはずだし、そうなったらすごく良いなぁとも思う。 全体としては「ザ・ファシリテーター」のような印象で、すごく読みやすかった。

ストーリー形式で開発現場を改善していく取り組みが紹介されていて、とても読みやすい。そしてそのストーリーが面白い！まさか技術書読んで泣くことがあるとは思わなかった。 また、「本書の特徴」にあるように、日本の開発現場を前提としているので、共感しやすいし、まず文体からして翻訳されたものより読みやすい。 この本では開発現場を改善するためのプラクティスがたくさん紹介されていて、とてもいきなり全部実践はできない。だからまずは一人でもできるタスクボードを自分の現場で始めてみた。この本のストーリーのようにうまくいくかはわからないが、できることから小さく実践して、少しずつでも自分の現場を改善していきたい。