沈黙のパレード

 つまらないわけではないが、ちょっと拍子抜けという感じであった。

容疑者Xの献身と比べると、登場人物の切実さにかける行動が目立つ。

トリックありきで、人間模様には薄さを感じた。

リーンソフトウェア開発

 リーン開発の本質の一つ前の本にあたる。

良い本である。順番的にはリーン開発の本質を先に読んで正解だったかもしれない。

こちらの本のほうが具体的で細かいことが書いてあるので。

２２のツールについて話をしてくれている。しかし、本質的には

1. ムダを排除する
2. 学習効果を高める
3. 決定をできるだけ遅らせる
4. できるだけ速く提供する
5. チームに権限を与える
6. 統一性を作りこむ
7. 全体を見る

について書かれている。いわゆる７つの原則であるが、リーン開発の本質に書いてあることと少し違う。リーン開発の本質のほうが後で書かれた本みたいなので、そっちを見たほうがいいかも。

１．ムダを排除するについて

ここだけでもかなり良い内容だと思う。

バリューストリームマップを作成して、とにかくムダを排除すること。

待ち行列が無駄になるので、余裕をもたせて渋滞が発生しないようにすることなどが書かれている。

２．学習効果を高める

品質の作り込みと決定を遅らせるということに関連している。

最初から完璧なものを一発で提供することを目指すのではなく、可能な限り初期の頃から品質チェックを行うということだ。最後の工程で品質チェックをして差し戻されるとムダが多いからである。

ユニットテストも自動化のうちの一つだと言える。可能な限り自動化することで品質の作り込みが前倒しできる。

また、開発の方針決定であるが、いきなり決めるのではなく、広く調べるべきで、段々と選択肢を狭めていく方向が良いと言える。

いきなり決めて、後戻りをせざるを得なくなると無駄になるので、できるだけ広く調べて少しづつ選択肢を狭めていったほうが良い。

ちょっと指摘が足りないと思ったところは２つある。

セキュリティについてだ。セキュリティチェックも可能な限り早期にかつ繰り返し行うほうが良い。

また、いつまで広く調べるべきだろうか？という点については言及がなかった。ただ、スケジュール感覚に優れた人の意見を聞いて決断していくべきだということが書いてあったと思う。

３，決定をできるだけ遅らせる

決めないことではない。

コンカレント開発は、仕様が固まりきらない段階から開発をはじめて、それぞれの工程での制限をフィードバックすることで、無理のない仕様や設計にして製品を作っていくということ。制限を伝えるというのが味噌。

できるだけ決定を送らあせたほうが、情報が揃っているので、良いわけだが、ただ決めずに遅らせるのは良くない。決めるべきタイミングではきちんと責任のある人間が決めて前進させる必要がある。

４．できるだけ早く提供する

早く作れるならギリギリまで決定を遅らせることが出来るから。フィードバックを与えられるから。当然メリットは多い。

５．チームに権限をあたえる

命令して動かすのではなくて、ボランティアの集団を動かすようにマネージメントするのが良い。

６．統一性をつくりこむ

ちょっと次の本では消えた要素では？とか思ってしまう。

リファクタリングは、やり直しではないし、設計コンセプトを保つための方法になるので、最初から工数に積んでおかないとだめだ。

そうしないと全体での統一性が取れなくなる。

実際に、そうなっているプロダクトを見ているので、まったくそのとおりだと思う。

７．全体をみる

局所最適しないように全体を見たほうがよい。

ここでは、リーン開発と協力会社との契約に関して記述されていて、非常に興味深い。

リーン開発の本質と微妙に違う構成になってはいあるが、非常に良い本であったし２２のツールは見直していきたい。