リーンソフトウェア開発 アジャイル開発を実践する22の方法を読了。
個人的には、先に読んだリーン開発の本質のほうが面白かった。
リーンソフトウエア開発～アジャイル開発を実践する22の方法～
posted with カエレバ
メアリー・ポッペンディーク,トム・ポッペンディーク 日経BP社 2004-07-23
以下、気になった言葉。
- リーン製造を成功させるには、何が価値を生み出すか、どうして円滑フローが不可欠なのか、そして、その作業を行う人たちの知力をどうやったら発揮させられるかを、きちんと理解していなくてはならない。
- 藤原：うまくいく方法を伝えるだけではなく、なぜうまくいくかを理解してもらわないと失敗する
- （CMMやPMIについて）学習と革新が成功の鍵となる製品開発事業では、このようなプログラムは使わないほうがいい
- 新しい考えが組織に定着するためには、二つの前提条件がある。
- その考えが、実務的に成功するものであると立証されていなくてはならない
- その変化を採用しようと考えている人たちが、どうして成功するのかを理解していなくてはならない
- ソフトウェア開発の7つのムダ
- 未完成の作業のムダ
- 余分なプロセスのムダ
- 余分な機能のムダ
- タスク切り替えのムダ
- 待ちのムダ
- 移動のムダ
- 欠陥のムダ
- コミットメントを遅らせるためのその他の戦略
- 重複を避ける
- 関心を分離する
- バリエーションをカプセル化する
- 将来的な機能の実装を遅らせる
- 余分な機能を避ける
- 多くのコンサルティング企業では、稼働率を、重要な経営指標として採用している。（中略） 稼働率を重要視する人たちには、「稼働率を100％に近づけても、全体的なバリューストリームにはなんの価値もあたえない」ということが理解しにくい
- 藤原：稼働率はスピードに直結しないと考えていいのかな。稼働率が経営指標だと、スピードが相殺されれる可能性がある
- ISO9000はプロセス改善プログラムと考えるべきではない。なぜなら、ISO9000はドキュメント化へ偏向しており、プロセスの改善ではなく、現在のプロセスの標準化を重視しているからだ
- 藤原：ドキュメントを作ることによってプロセス改善されることもあるかもしれないけど、本来は手順の標準化や情報共有メインになるはず。今、そういった知識の共有がされていないなら改善になるが、知識共有がそれ以外の方法（Wikiとかデイリースクラムとか）でできるようになっていたら、ドキュメント作成自体が無駄になってしまう
- これらのプログラム（ISO9000やCMM）を導入する際、プロセスの設計や決定の権限を開発者から取りあげ、その権限を中枢組織の管理下に置く
- 藤原：開発プロセスなどは、マネージャが考えるのではなく、本来は開発者が作り上げるものだと思う
- モチベーションをくじかせる、最も簡単な方法の一つは、アメリカ軍で「ゼロ欠陥精神」と呼ばれているものだ。ゼロ血管精神は、絶対にミスをゆすさない雰囲気のことである
- アジャイルマニフェストは、プロセスから人へ、ドキュメントからコードへ、契約から協調へ、そして、計画から行動へと、認識をシフトさせるのに大いに役立つ
- 生産性、とくに、知識労働者の生産性を測定しようとするのは、自ら間違いを招いているようなものだ by トム・デマルコ、ティモシー・リスター
- 藤原：生産性を知りたい経営者がいる限り、生産性の測定はなくならない。だとすれば、生産性の代わりになり得る指標の認識を、経営層、マネージャ層、開発者層であわせて、価値を揃えることが必要だと感じた。生産性じゃなければならない理由はないはず。
