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

投稿元：

レビューを見る

版元の翔泳社の方からいただきました。

本書は、プロジェクトを前に進めるために、さまざまなプラクティスがストーリーの中で紹介されています。

・KPT
・カンバン
・インセプションデッキ
・狩野モデル
・合宿
・期待マネジメント
・ユーザーストーリーマッピング
etc

世のプロジェクト、プロダクトマネージャーで悩みがある人には是非手に取ってもらいたい本です。
自分のもつプロジェクトでの悩みの解決の一歩がかかれてるかもしれません。
私は書かれてました。

投稿元：

レビューを見る

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

投稿元：

レビューを見る

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

投稿元：

レビューを見る

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

投稿元：

レビューを見る

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

投稿元：

レビューを見る

ソフトウェア開発の現場を、一人きりの状態からやがて他組織を巻き込むまでに改善していく物語パートと、その中で使用されたプラクティスなどの解説パートが交互に挟まっている形式。解説は物語の登場人物が行う。

物語部分はザ・ゴールを思わせるが、請負契約など、より日本らしい雰囲気が漂う。また、物語形式は「読みやすいが体系的な知識を得にくい」とという点を、解説パートが補っている。

本書に登場するプラクティスは多岐にわたり、著者らの経験の深さが垣間見える。そして、それらが必ずしも予定調和的に適切なタイミングで使用されている訳でないところも、物語の「それっぽさ」に一役買っている。

よく分からなかったのは、Appendixで「越境」など5つの項目を「価値」として挙げている事。
越境は価値だろうか。価値を得るための手段ではないのだろうか。

投稿元：

レビューを見る

新規事業のシステム開発は要求や仕様が明確でない場合がほとんど。
何を作るか、何故作るかを常に考えるが、
それが正解かどうかは分からない。
分からない中でも前に進んでいくために
アジャイルの考え方は必要だと思う。
ただ、チーム全員がその考えを持っていることは少なく考えを浸透させるのは難しい。

この本ではフィクションとしながらも
事実をベースにしているため
現場の緊迫感が伝わってきて良かった。
自分が一歩前に進むきっかけになりそう。

アジャイルや、事業開発で使うツールや
その使い方が分かりやすく説明されており
解説書としても使えそう。

一人でできること、
チームで出来ること、
チーム外部と出来ること、を
ストーリーと解説を交えて
記載されているのも読みやすい。


それで、あなたは何をしている人なんですか？

投稿元：

レビューを見る

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

投稿元：

レビューを見る

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

投稿元：

レビューを見る

完全にリモートワークでのスタイルとなった今、これを良い機会としてコンサルティングという仕事の進め方を見直したいという問題意識の元、プロジェクトスタイルという仕事の進め方が似ているITシステム・サービス開発から学ぶべきは多いのでは、という仮説から手に取ったのが本書。

ストーリー仕立てでアジャイル開発、特にスクラムの方法論を学ぶことができる。こうした具体的な方法論にちゃんと触れるのは実は初めてであり、具体的かつ様々な失敗も踏まえて改良された方法論のシャープさが非常に面白い。

例えば、コンサルティングという仕事では、クライアントに納品するアウトプットを当然、一定の大きさのモジュールに切り分けて各コンサルタントが分担することが一般的である。その際、分析の手法やスライドライティングのノウハウは、一定のお作法・ルールが決められている。とはいえ、細部になれば個々人の経験による独自のTipsなどがあるわけで、そうしたものの標準化にスクラムの開発Tipsである”モブプログラミング”(複数人で一つの画面を見ながら、ワイガヤ的にプログラミングする手法)を援用するとどうなるだろうか。

このような観点で、自身の仕事の進め方を改善する様々なヒントを得られた気がしており、さらにこの分野を突っ込んでいこうと思った次第。

投稿元：

レビューを見る

自社開発関連でバラバラに作業を行なっているため、どうやればいいのかという足がかりを見つけるために買った。

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

投稿元：

レビューを見る

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

投稿元：

レビューを見る

ストーリー仕立てですごく読みやすい。読み進めていくうちに、アジャイル開発、業務改善の手法から、チームマネージメントまで学べる。
アジャイルをこれから始めたい人も、開発以外にもいろんな現場で、チーム力を向上させていくための参考になりそう。

投稿元：

レビューを見る

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

まずは一人からカイゼンを始めて、それが二人になり、次に数人のチームで、社内の複数チーム、社外のステークホルダー、、、といったように徐々に巻き込む対象がスケールアウトしていく様子が非常に爽快です。