藤原大のレビュー一覧
-
Posted by ブクログ
スウェーデン警察のプロジェクトという実在のプロジェクトで、どのようにカンバン・リーン原則を適用したか、これに対して何を学びどのように解決しようとしたか、が書かれた本。
リーンやアジャイルの原則に則り、自分たちでいろいろ試してプロジェクトに合う方法を見つけていった過程は非常に刺激になる。
本に書かれている基本的なやり方だけをやっているだけではだめで、自分たちで何が問題かを考えてそれをどのように解決したらよいかを実践することが大事であることを再認識させられた。
手法としては「因果関係図」が目から鱗だった。なぜなぜで掘り下げるだけではなく、ループ図を作るように事象の関係を結んでいくことで、システム思考的に自分たちの問題点が何かを浮き彫りにしていく手法はとてもしっくりきた。
自然にできるようになるためには相当な数の実践と訓練が必要そうだけど、意識して行うことでなんとかモノにしていきたいところ。
「ループ図」などのバズワードを使わない、といったところもその通りで自分たちのシチュエーションに合わせて言葉を選ぶというのは非常に大切。
訳者あとがきにもぐっときたけど、平鍋さんの解説はほんとに素晴らしい。
リーンの定義もそうだけど、大野さんの「トヨタ生産方式」がアジャイルの源流であることは知っておいたほうがいいと再認識できた。
これから自分が遭遇するコンテキストの中で絶対に失ってはいけないものを再確認できたということで、この時期に出会えたことに本当に感謝。 -
Posted by ブクログ
非常に実践的な内容で学ぶべきところが多かった。アジャイルの難しい所は、どう実践すればよいかが分からない、これに尽きると思う。ここでは実際のプロジェクトでどのように問題を解決してきたかの一端を見ることができる。プロジェクトの規模、内容が違うのでこのまま使えるわけではないが大いに参考になると思う。そして一つのやり方にとらわれることなくプロセスも常にカスタマイズするべきであることもわかる。決まった手順にとらわれがちであるが、組織、チームに合ったやり方というものもあるし、全ての開発フェーズで同じやり方で良いわけではない。プロセスを変えることを恐れてはいけないし、むしろプロセスを適切に変化させることが開発を成功に導くカギであることが分かる。
技法そのものの説明としては「テスト自動化の戦略」「因果関係図」が特に有用だった。「テスト自動化の戦略」はプロジェクトの途中からテスト自動化をするという難しい問題に対する一つの解が示されている。テスト自動化を導入する手順書は多くあるが、プロジェクトの途中から導入するということを扱ったものは見たことがなく、大いに参考になった。また、「因果関係図」はいわゆるトヨタの「A3シンキング」であるが、具体的な例と主に気をつけるべきポイントが端的に示されており、ほんの数ページであるにもかかわらずそれの意味するところ、有効性、やり方までがしっかりと示されており、すぐにでも使えるようになっていた。 -
Posted by ブクログ
デブサミ関西2013にて、本書訳者の藤原大さんのセッションを聞いて以来、発売前から楽しみにしてました。そしたらなんとRakuten Technology Conference 2013で、@jcoplienさんに質問させていただいたのがきっかけで発売直後に頂きました。嬉しすぎてわけわからないです。
で、内容はとても生々しくて良いです。現場で考え続けてきたことを、なぜそのように考えたのか、どんな課題があったのか、つぶさに書かれています。200ページ弱の薄めの本ですが、内容はとても濃かったです。
「スクラムを取り入れたチームに起きる問題は、スクラムを採用したことが原因ではない。むしろ、抱えている問題がスクラムによって掘り起こされたんだ。(p.24)」
「あらゆるキューを制限する(p.57)」この考え方は目から鱗でした。これがないとWIP(Work In Progress)が無制限に増えていき、なおかつその状態が見えないとフォローも不十分になって、デスマに突入するんだろうな。
「プロダクトのバグは、プロセスのバグから生み出される症状だ(p.58)」プロセスのバグをほっとくと、プロダクトのバグが増え、その対応に追われてプロセスのバグを直す時間がなくなり、さらにプロダクトのバグを生み出すってゆう悪循環に陥ってしまう。継続的にプロセスを改善することが重要。 -
Posted by ブクログ
ネタバレカンバンを使うことによる組織のコラボレーションと進化の仕組みであると理解した。
カンバン上に表現することで、コミュニケーションが発生し、問題が可視化され、カイゼンする文化が築かれ、枠を超えた信頼とコラボレーションが発生するのだ。
現在のプロジェクトで利用しているタスクボード上にも、エモーションチケットやKPT、割り込みタスク、やりたいこと、バッファなどが発生している。これもいわゆるカイゼンプロジェクトボードという形でスケールしているんだなぁ。
-引用-
プロジェクトメンバーを集めて、自分たちのコンテキストでの「理想」を見つけよう。...理想の探求は、進むべき道を示すコンパスになるはずだ。理想を達成することが必要なのではない。理想とはたどりつくべき場所のことではなく、ありたい姿に向かい続ける事なんだ。
優れたプロセスは、設計によって生み出されるものではない。進化の結果として表れるだから、現在行っているプロセスが重要なのではない。現在のプロセスを改善するためのプロセスこそが重要なんだ。
本当の失敗はひとつしかない。それは、失敗から何も学ばないという失敗だ。
結果が重要なのではない。人と結果を出せるシステムを育てるのが重要なのだ。
学びとは、ただ知る事ではない。知識は頭の中のものだが、学びとは手の中にあって、熱意によって行動に移されるんだ -
Posted by ブクログ
実際にアジャイル(リーン)プロジェクトを経験した著者が、自身のチームで実施した具体的施策(カンバンの便箋にどういう情報を書き、また逆に何を書かないか、など)を紹介する本。
アジャイルの理念、一般的施策及びその意図に関する記述は薄いので、「そもそもアジャイルとはなんぞや?」というレベルの人間にはおすすめできない。
しかし、アジャイルの入門書を一冊でも読み、上記を把握しているのであれば、アジャイル・プロジェクトの雰囲気や、実際に直面する困難、これに対する具体的対応策を知る上で、参考になる。
ただ、アジャイルとはまさに「あらゆる状況に対応できる銀の弾丸はないのであるから、状況に応じて最適なプロセスを組め」という取組みであるから、本書に紹介されている思索をそのまま自分のプロジェクトに持ってくることはできない(特に、著者のプロジェクトは60人体制という、アジャイルにしては大きめのプロジェクトであり、円滑なコミュニケーションを担保するための施策が多くあったが、大抵のプロジェクトはより少数であり、そうした施策は悪戯に時間を浪費するだけになる可能性が高い)。
要は「ふーん、アジャイル開発って、こんな雰囲気のもとで、こんな感じでやると、こんなふうに成功しうるのか」という感覚値を得る、程度の期待値で読むのが最適。
その意味で、悪くはないが、劇的効果が望める類の書籍でもない。☆3つ。