投稿元:
レビューを見る
ソフトウェア開発の仕事は大変だ。
毎日夜は遅いし、いつも炎上する。
それをなんとかしたいと思い、たった1人で行動を起こしてみた。しかし周りは誰も協力してくれない。そして挫折。やはり自分1人で開発現場をなんとかするなんて無理なのか?
あなたにも、そんな経験があるだろう。
この本は「ITエンジニアに読んで欲しい!技術書・ビジネス書大賞2019」の技術書部門ベスト10を受賞した人気の本だ。
著者は、ソフトウェア開発のコミュニティ「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だ。
私も、現場で新しいことを始めたり、有志を募って勉強会を開いたり、ささやかではあるが改善の旅を続けているが、本書に書かれていることは、現場で迷ったときに、とても参考になると感じている。やろうと思えば、明日からでも始められるノウハウばかりだ。
しかし実際に、書いてある通りにやろうとすると、なかなか大変なことは事実。「勇気」が必要だからだ。
現場の改善に「正解」は無いだろう。だから迷うし、こんな出すぎたこと自分がやってもいいのだろうか、と悩む。何かを始める勇気、最初の一歩を踏み出す勇気が、なかなか湧いてこないのだ。
著者は言う。
『「今の自分の延長線上に何があるのか」を想像したときに、特に変わりようがないと気づいたとき、行動を起こすことに踏み切れました。』
あなた自身のこれからを大切に思うなら、行動を起こすしかないのだ。
行動を起こすといっても、何もいきなり会社を辞めろと言っているわけではない。ゴミが落ちていたら拾うというレベルでも良い、と私は思う。大事なことは、あなたが良いと思ったことを、勇気を出してやってみることだ。そうしないと何も始まらない。
もしあなたが、現状を変えよう改善を始めてみたが、上手くいかなくて心が折れそうになったなら、ぜひこの本を読み返してみて欲しい。本書の登場人物たちが、あなたの、たったひとりの挑戦を後押しし、力強く応援してくれるだろう。
投稿元:
レビューを見る
様々なカイゼン手法が本書では紹介されている。これだけの手法の紹介があれば、とりあえずこの一冊あれば大丈夫だ、と思わせてくれる本である。そして、それらの手法がバラバラになっているのではなく、小説によってうまく接続されていく、そういった本である。
新しい手法を短期間に組織に浸透させていくのは大変なことである。急ぎすぎると、形だけを取り入れて、その目的からそれていったり、うまくいかない状態になりそれを理由に他のメンバーに拒絶されたり、といったことがある。そうならないために、まずは本書で示されているように、一人、または二人で始めて、失敗を経験し、理論武装した上で組織に展開していく、というアプローチが良いのであろう。
投稿元:
レビューを見る
ストーリー付きでイメージしやすくなるのはGood(小説じゃないので当然ながら質はいまいちだが)
フレームワークの辞書として使う形がいいかなと。
投稿元:
レビューを見る
仕事の進め方も参考になりますが、個人的には仕事に対する姿勢の部分が好きです。
転職したことのある身としては、職場への不満がたまる様が共感でき、それでも自分の持ち場で周りを変えようとしていく主人公の姿がヒーローに見えました。本にも書かれているとおり職場はそれぞれ違った制約があるでしょうが、周りのモチベーションを引き出しながら前を見て進むことは、どこでも変わらず大切なことなのだと思います。
投稿元:
レビューを見る
こういう手法あるよなというのはわかったけどチームがどう成長していっているのかがいまいちピンとこなかった。
投稿元:
レビューを見る
# 書評☆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/
投稿元:
レビューを見る
リーンでアジャイルなソフトウェア開発の考え方とプラクティスを、日本的な現場のストーリーから学ぶことができる。
ホワイトカラーの現場で起こる諸問題を、スクラムとXPのプラクティスで解決していく。極めてプラクティスが多く出てくるため、一読しただけではどのプラクティスがどの課題に対応するのか整理できない。曼荼羅のごとく、対応付けして整理する。
ーフレーズメモー
・仕事をよりうまくやるために何から始めるか?タスクマネジメント、タスクボード、朝会、ふりかえりの4つがある。仕事のカイゼンはまず状態の見える化から始めるべし。
・ふりかえりの基本。プロセスのカイゼンと不確実性の高い状況で前進することを目的とする。ふりかえりのやり方には、問題発見フェーズ、事実発見フェーズ、対策フェーズがあり、できるだけ可視化する。
・ふりかえりは他人に気づかせてもらう。だからこそチームでやる。
・むきなおり。1.ミッション、ビジョンを点検する。2.評価軸を洗い出し、現状を客観的に見定める。3.評価軸ベースであるべき姿と現状の課題を洗い出す。4.課題解決のために必要なステップをバックログにする。5.バックログの重要度と、一番効果の高いものを決める。6.時間軸を明らかにし、期限も明確に決める。
・バリューストリームマッピング。プロダクトの価値がお客さんの手に渡るまでの仕事の流れを見える化するプラクティス。流れのどこで付加価値が生まれるのか、プロダクトが滞りなく実現に向けて動いていけるのかを確認する。
投稿元:
レビューを見る
主人公の若手プログラマーがひとりで始めた改善活動が、メンターらの導きによって成長し、改善活動が部署で共有され、他部署、他社を巻き込む流れになっていく。
そういうストーリーで読ませつつ、ティップスもしっかり解説されている。
読みやすく、わかりやすい。
投稿元:
レビューを見る
読書感想文書きました。
https://jumpyoshim.hatenablog.com/entry/book-report-of-kaizen-journey
投稿元:
レビューを見る
開発現場の問題を物語を通して、いろいろな解決手法を用いて、解決していくお話し。
開発現場でよくあるは問題が取り上げられているため、とても実用的な書籍でした。
投稿元:
レビューを見る
カイゼン・ジャーニーの途中で、むきなおる: Meet Up 大阪 @ blog
http://www.meetuposaka.com/article/465462539.html
投稿元:
レビューを見る
新規事業のシステム開発は要求や仕様が明確でない場合がほとんど。
何を作るか、何故作るかを常に考えるが、
それが正解かどうかは分からない。
分からない中でも前に進んでいくために
アジャイルの考え方は必要だと思う。
ただ、チーム全員がその考えを持っていることは少なく考えを浸透させるのは難しい。
この本ではフィクションとしながらも
事実をベースにしているため
現場の緊迫感が伝わってきて良かった。
自分が一歩前に進むきっかけになりそう。
アジャイルや、事業開発で使うツールや
その使い方が分かりやすく説明されており
解説書としても使えそう。
一人でできること、
チームで出来ること、
チーム外部と出来ること、を
ストーリーと解説を交えて
記載されているのも読みやすい。
それで、あなたは何をしている人なんですか?
投稿元:
レビューを見る
システム開発における様々な問題を、主人公が成長しながら解決していく物語。
他の一般的な書籍と違い、物語として読むことができるため、自分の境遇と比較しながら読みすすめることができます。ポイントを逐一紹介しているため、説明はとても分かりやすいです。特に一番最後のあとがきで全てをまとめているのはとてもありがたかった。
主題は物語ではなく、様々な問題をどうやって解決するかを学ぶことなので、物語の全てが
・問題発生
・解説
・解決策を遂行
・うまくいった
という流れで進みます。1〜2章は解決策を他人が提示するので、まるでドラえもんみたいだと感じましたが、学びを得るのが主題なのでやむを得ないかなと思います。
主人公が最初に絶望していた割に、本人も周囲も都合が良すぎると感じることもあるにはありますが、そもそも物語の形をとって解説をしている本なので、出来事にリアリティがないことを責めるのもちょっと違うかなと思います。(リアリティ重視で分かりにくいと本末転倒ですし)
1つだけ不満を言うならば、発生する問題がほぼ全て解決手段の提示ありきで、特にスクラム開発における解決手法を次々と利用していく流れなのですが、手段はともかくなぜその解決策なのか、この問題の本質はどこなのかといった、手段を講じる前の段階を深く掘り下げてほしかったと思います。
とはいえ、全体的にはわかりやすくまとめられており、読後感も良いのでおすすめです。
投稿元:
レビューを見る
自社開発関連でバラバラに作業を行なっているため、どうやればいいのかという足がかりを見つけるために買った。
エンジニアベースの問題解決の方法は物語ベースでわかりやすく書かれており、実践してみたいと思ったが、どちらかといえば開発メンバーというよりも善んたい的な巻き込み術をしりたかったので、私の期待とはちょっと違った。
投稿元:
レビューを見る
バラバラのチームが、幾多の強敵プロジェクトと戦いながら結束するまで。チームの開発技法を学べる物語
★本の概要・感想
システム・ソフトウェア開発における、チームワークの技法が詰まっている。実際にチームでシステム開発をしているなら、読めば役立つフレームに出会えるかもしれない。また、この本はチームの様々な状況を描いているため、自分たちの開発状況を客観視するのにも役立つ。特にスクラムマスターやマネージャーなどはこれらの本を読むと良いだろう。「こんなもんだ」と思っていた自社の開発環境が、実は時代遅れなものだったり。もっと効率の良い情報共有の仕方があるのに、それに全く気付いていない、というような可能性だってあり得る。私はデスクトップエンジニアであり、一人で業務アプリケーションのカスタマイズや改修を行うことが多い。個人的には直接的に生かせるものが少なかったものの、チーム開発の現場に移ったタイミングでまた読み返したいと思う。
★本の面白かった点、学びになった点
*分割統治法をすること。大きなタスクを大きな言葉のままで扱うのを辞めよう
・認識の齟齬が発生しやすくなる。できる限り具体的な言葉で。分割して話すように
★本書の紹介しているフレーム
・アジャイル開発、スクラム、カンバン仕事術、モブプログラミング、バリューストリームマッピング、ユーザーストーリー、ゴールデンサークル、学習する組織、朝会、
●本を読んだだけでは応用できない
。物語の形式により、フレームの使用場面を想像しやすく、多くの手法が紹介されていた。
もちろん、その技法を知っているからと言って、すぐさま現場に応用はできない。知った上で、どう自分たちの開発に落とし込むか。そこは読者たちのと努力が必要である。また、多くのフレームが紹介されているがゆえに、各手法の記述は多くない。各技法を一つ一つ学んでいく必要もあるだろう
●学んだことをどうアクションに生かす
*まぎれの無い明瞭な言葉を用いること
*カンバン仕事術
*思いやりを持って仕事する