本棚登録 : 
感想 : 
- Amazon.co.jp ・本 (184ページ)
- / ISBN・EAN: 9784274069321
作品紹介・あらすじ
官公庁の大規模システム開発における、カンバンシステムを軸にしたプロジェクト進行の様子を、著者の経験に基づいて描写。「リーンソフトウェア開発」を現場でどのように適用するかを直裁的に解説しています。
感想・レビュー・書評
-
実際にあったプロジェクトのお話ですが、自分にとって胸に響く言葉がありました。特に「僕たちが学んだこと」はとても大切な事が書いてあると感じました。自分の環境や考え方の違いで実現できそうにないこともありますが、そこが逆に羨ましくもあり…何より現場がとても楽しいもところのようにも思えました。実際には辛いこともたくさんあったと思いますが（笑）。今の自分のいる現場は何なんだろうか…？とついつい考えてしまいます。
2
詳細をみるコメント1件をすべて表示-
daipresentsさん私も「僕たちが学んだこと」を翻訳していて「良い文章だなぁ」と思いました。現場ラブイベントも企画していますので、どこかでお会いできることを楽し...私も「僕たちが学んだこと」を翻訳していて「良い文章だなぁ」と思いました。現場ラブイベントも企画していますので、どこかでお会いできることを楽しみにしています。レビューありがとうございました！2013/11/27
-
-
「スウェーデン警察中の、これまで紙ベースで行われていた現場の警官と本部の連携をバーコード＋ウェブでデータ連携する」というプロジェクトに対して行われていた、リーン開発の事例。「リーン開発を適用した」のではなく、「プロジェクトがより上手く回るように改善していった結果がリーン開発だった」という著者の話には、説得力がある。
読む前は「ピーク時で60人」というのは大した規模ではない、なんて思っていたけど、プロジェクトの内容からするに、よくその規模で回せたな、というのが、正直なところ。
アジャイルの教科書的な手法をそのまま適用するのではなく、現場に合わせてよりよいやり方を適用していったところが生々しくてよい。プロジェクトをよくしていく仕組みを作っていく仕組み、それを整えていくことが本質的であり、著者らの行ったことだと感じた。
付録にリーン開発の簡単な解説もあり、親切な構成なのもよかった。最後の日本語版解説がアツ苦しくてゲンナリしたけど。
2
-
私も翻訳しながら「結果がリーン開発だった」という部分を強く感じました。レビューありがとうございます！私も翻訳しながら「結果がリーン開発だった」という部分を強く感じました。レビューありがとうございます！2013/11/23
-
-
プロジェクトを進めるにあたっての考え方を学べる一冊。
アジャイルやXPなどの様々な手法と比較して、how toを伝えるだけにならず、どうやったら継続して改善できるかを書いていて、試そうと思える方法がいくつもあった。
1
-
大規模プロジェクトのアジャイルな、リーンな、スクラムな運用ノウハウをまとめた本。
チームの試行錯誤の結果として成功したノウハウを学べるので、自分のチームの改善アイデアの参考になる。
しかし、ベースとなるチーム文化、メンバーの性格、チームビルティングなど大事な箇所が分からない。
また、こういった本は、チームメンバーや組織文化などが大きく関わるので実際に実施するのが難しい場合もある。
理想として、このようなチームになりたいというあるべき姿を描くために読むという風に読んだらいいと思います。
1
-
実際にアジャイル（リーン）プロジェクトを経験した著者が、自身のチームで実施した具体的施策（カンバンの便箋にどういう情報を書き、また逆に何を書かないか、など）を紹介する本。
アジャイルの理念、一般的施策及びその意図に関する記述は薄いので、「そもそもアジャイルとはなんぞや？」というレベルの人間にはおすすめできない。
しかし、アジャイルの入門書を一冊でも読み、上記を把握しているのであれば、アジャイル・プロジェクトの雰囲気や、実際に直面する困難、これに対する具体的対応策を知る上で、参考になる。
ただ、アジャイルとはまさに「あらゆる状況に対応できる銀の弾丸はないのであるから、状況に応じて最適なプロセスを組め」という取組みであるから、本書に紹介されている思索をそのまま自分のプロジェクトに持ってくることはできない（特に、著者のプロジェクトは60人体制という、アジャイルにしては大きめのプロジェクトであり、円滑なコミュニケーションを担保するための施策が多くあったが、大抵のプロジェクトはより少数であり、そうした施策は悪戯に時間を浪費するだけになる可能性が高い）。
要は「ふーん、アジャイル開発って、こんな雰囲気のもとで、こんな感じでやると、こんなふうに成功しうるのか」という感覚値を得る、程度の期待値で読むのが最適。
その意味で、悪くはないが、劇的効果が望める類の書籍でもない。☆３つ。
1
-
ソフトウェア開発手法を学ぶために一読。アジャイルやリーンなどのバズワードが何なのかをひと通り現場で使われる手法の流れを追いつつ学べる。知識だけではなく、現状の問題を分析し、最適なフローによってプロダクトアウトしていく。
1
-
簡潔なのに、かなり包括的。中心は実例ベースだけど、最後にテスト自動化や因果関係図、プランニングポーカーまで載ってる。
継続的リリースを、警察機関の報告業務アプリで実現させたとのこと。こういう開発を日本でもやらなきゃいけない。
1
-
レビューありがとうございます。翻訳していて1部と2部の構成もいいなぁと私も思いました！レビューありがとうございます。翻訳していて1部と2部の構成もいいなぁと私も思いました！2013/12/20
-
-
-
2013/12/20
-
-
ある現場で改善していく様子、その過程が詳細、かつ、分かりやすく書かれている。
特にカンバンボードの進化の仕方などは、自分もよく使っているだけにすごく参考になる。
アジャイル開発をやっていない現場でも役に立つ事例はたくさん詰まっている良書だと思う。
1
-
-
レビューありがとうございます。「枠を超えた信頼とコラボレーション」というのは翻訳していてすごく感じた部分ですレビューありがとうございます。「枠を超えた信頼とコラボレーション」というのは翻訳していてすごく感じた部分です2013/11/21
-
-
-
レビューありがとうございます。「リーンのお約束」ってのは言い得て妙だと思いました。たしかにそんな感じレビューありがとうございます。「リーンのお約束」ってのは言い得て妙だと思いました。たしかにそんな感じ2013/11/21
-
-
デブサミ関西2013にて、本書訳者の藤原大さんのセッションを聞いて以来、発売前から楽しみにしてました。そしたらなんとRakuten Technology Conference 2013で、@jcoplienさんに質問させていただいたのがきっかけで発売直後に頂きました。嬉しすぎてわけわからないです。
で、内容はとても生々しくて良いです。現場で考え続けてきたことを、なぜそのように考えたのか、どんな課題があったのか、つぶさに書かれています。200ページ弱の薄めの本ですが、内容はとても濃かったです。
「スクラムを取り入れたチームに起きる問題は、スクラムを採用したことが原因ではない。むしろ、抱えている問題がスクラムによって掘り起こされたんだ。(p.24)」
「あらゆるキューを制限する(p.57)」この考え方は目から鱗でした。これがないとWIP(Work In Progress)が無制限に増えていき、なおかつその状態が見えないとフォローも不十分になって、デスマに突入するんだろうな。
「プロダクトのバグは、プロセスのバグから生み出される症状だ(p.58)」プロセスのバグをほっとくと、プロダクトのバグが増え、その対応に追われてプロセスのバグを直す時間がなくなり、さらにプロダクトのバグを生み出すってゆう悪循環に陥ってしまう。継続的にプロセスを改善することが重要。
1
-
ご感想ありがとうございます。デブサミ関西に行ったかいがありましたw またどこかの勉強会でお会いできるのを楽しみにしています！ご感想ありがとうございます。デブサミ関西に行ったかいがありましたw またどこかの勉強会でお会いできるのを楽しみにしています！2013/11/21
-
こ、こちらこそありがとうございます！まさか直々にコメントいただけるとは。。。感激です！もしお会いできたときはぜひ！サインをください！（買って...こ、こちらこそありがとうございます！まさか直々にコメントいただけるとは。。。感激です！もしお会いできたときはぜひ！サインをください！（買ってないくせに厚かましくてごめんなさい。。。）2013/11/21 -
2013/11/23
-
-
リーンとタイトルにありますが、スクラムやアジャイルの守から破る過程にいる人に参考になる良本だと思います。なぜ変化を加えているか、筆者の考えが都度丁寧に説明されており、一緒のプロジェクトで働いたかのような気持ちになりました。
0
-
ページ数は少なめでさらっと読めるけど、中身はかなり重厚でとても参考になった。
大規模プロジェクトでの実践的なカンバン運用について書かれている。１章ごとに役に立つ内容も多いので、目次を見て気になる章を見てみるのも良いかも。
0
-
カンバンを用いた実際の開発の話を、なぜそうしているのか等が書かれており学ぶ点が多い。カンバンだけでなく、アジャイルな開発に対しても示唆に富む本となっている。事例から学べる人に是非オススメしたい。
0
-
遅まきながら手に取り、読了。
何度か自分の事例紹介の発表で表明している通り、自分の持論としては「事例紹介は（失敗例にせよ成功例にせよ）上澄みに過ぎない（から発表で端折られているもろもろにこそ大事なことが含まれている）」と思っているのだけど、本書の著者ヘンリックさんも繰り返し（別の言葉で）それを書いてる（と、私は読み取った）。
そして、本書は多くの人にとっていい上澄み:-)
0
-
スウェーデン警察のプロジェクトという実在のプロジェクトで、どのようにカンバン・リーン原則を適用したか、これに対して何を学びどのように解決しようとしたか、が書かれた本。
リーンやアジャイルの原則に則り、自分たちでいろいろ試してプロジェクトに合う方法を見つけていった過程は非常に刺激になる。
本に書かれている基本的なやり方だけをやっているだけではだめで、自分たちで何が問題かを考えてそれをどのように解決したらよいかを実践することが大事であることを再認識させられた。
手法としては「因果関係図」が目から鱗だった。なぜなぜで掘り下げるだけではなく、ループ図を作るように事象の関係を結んでいくことで、システム思考的に自分たちの問題点が何かを浮き彫りにしていく手法はとてもしっくりきた。
自然にできるようになるためには相当な数の実践と訓練が必要そうだけど、意識して行うことでなんとかモノにしていきたいところ。
「ループ図」などのバズワードを使わない、といったところもその通りで自分たちのシチュエーションに合わせて言葉を選ぶというのは非常に大切。
訳者あとがきにもぐっときたけど、平鍋さんの解説はほんとに素晴らしい。
リーンの定義もそうだけど、大野さんの「トヨタ生産方式」がアジャイルの源流であることは知っておいたほうがいいと再認識できた。
これから自分が遭遇するコンテキストの中で絶対に失ってはいけないものを再確認できたということで、この時期に出会えたことに本当に感謝。
0
-
非常に実践的な内容で学ぶべきところが多かった。アジャイルの難しい所は、どう実践すればよいかが分からない、これに尽きると思う。ここでは実際のプロジェクトでどのように問題を解決してきたかの一端を見ることができる。プロジェクトの規模、内容が違うのでこのまま使えるわけではないが大いに参考になると思う。そして一つのやり方にとらわれることなくプロセスも常にカスタマイズするべきであることもわかる。決まった手順にとらわれがちであるが、組織、チームに合ったやり方というものもあるし、全ての開発フェーズで同じやり方で良いわけではない。プロセスを変えることを恐れてはいけないし、むしろプロセスを適切に変化させることが開発を成功に導くカギであることが分かる。
技法そのものの説明としては「テスト自動化の戦略」「因果関係図」が特に有用だった。「テスト自動化の戦略」はプロジェクトの途中からテスト自動化をするという難しい問題に対する一つの解が示されている。テスト自動化を導入する手順書は多くあるが、プロジェクトの途中から導入するということを扱ったものは見たことがなく、大いに参考になった。また、「因果関係図」はいわゆるトヨタの「A3シンキング」であるが、具体的な例と主に気をつけるべきポイントが端的に示されており、ほんの数ページであるにもかかわらずそれの意味するところ、有効性、やり方までがしっかりと示されており、すぐにでも使えるようになっていた。
0
-
貸し出し状況等、詳細情報の確認は下記URLへ
http://libsrv02.iamas.ac.jp/jhkweb_JPN/service/open_search_ex.asp?ISBN=9784274069321
0
Henrik Knibergの作品
この本を読んでいる人は、こんな本も本棚に登録しています。
