カイゼン・ジャーニー の商品レビュー

市谷聡啓(著者),新井剛(著者)

2019/03/02

# 書評☆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/

2019/02/15

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

2019/02/09

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

2019/02/03

旧来的なシステム開発をどのように変えていくかをストーリー仕立てで記述した一冊。
方法論の解説も分かりやすく、ウォーターホール開発から脱出したいと考えている人にはとてもよいです。

スクラム開発の経験はありますが、それ以外のプラクティスも取り入れていきたいと感じました。

私もシステム開発手法をどうにかしたいと考えているので、非常に参考になりました。

2019/01/01

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

2018/11/18

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

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

2018/10/15

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

2018/09/29

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

2018/09/16

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

2018/04/23

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