リーン開発の現場 書評
優れたプロセスは設計によって生み出されるものではない、進化の結果として現れる。
ソレを体現した本と言えます。
この本には、筆者がぶち当たった壁に対して実践したプラクティスが詰まっています。
なので、ターゲットとして
アジャイル、リーンの基本的な部分は既に分かっている方を対象としており、
理論ベースではなく、わりと実践ベースで語られていることが多いです。
こんな人にオススメ
アジャイル、リーン開発の基本的な方法は分かった、
でも実際のところどうなの？
アジャイルをやってみた。
でも思ったほどの効果が出ない。
こういう悩みを抱えている人には、
この本は一定の回答を出してくれると思います。
刺さった文
管理するバグの数を制限することでクライアントとの間に信頼関係を築ける。
数ヶ月修正するわけでもなく、ただ登録しておくよりかは、短いバグ一覧だが確実に修正されるほうが良い。
修正される見込みがない場合、いつかは修正されるはずというような誤った期待を抱かせないように、はじめから修正する気はないと伝えている。
9.4 バグを可視化する
コレは個人的には盲点でした。
ダラダラと書いてあるだけのバグ票よりかは、確かに確実に修正されるものだけを記載したほうがお互いに良いと思います。
ただし、「直さなければいけないものは直す」のが前提ですけれど。
「ものごとがそうなっているのは、そうなったからだ」
ー ジェラルド・ワインバーグ
「あなたがこれまでにやってきたことをやっているだけならば、これまでに得たものしか得られないだろう」バグの根本原因を分析してみると、バグは本当の問題ではないことに気がつくはずだ。
バグは症状に過ぎない。
プロダクトのバグはプロセスのバグから生み出される症状だ。
9.5 繰り返し発生するバグを防ぐ
バグが発生した時に、バグを（結果的にでも）埋め込んだプログラマを責めるのではなく、
チーム全体の責任と考えるのならば自ずとこうなるのだと思います。
プロセス改善ワークショップには、僕達の仕事のやり方を明確にして改善する狙いがある。
プロセス改善のための意思決定は、変化を起こすことを意味している。
10.2 プロセス改善ワークショップ
振り返りのこと。
何回も振り返りをやっていると忘れがちだけど、振り返りの目的はつまりそういうこと。
完璧な解決策を探そうとしてもムダだ。
その代わりに小さく少しづつ出来る改善点を探して改善を実験だと考えてみよう。
優れたプロセスは設計によって生み出されるものではない、進化の結果として現れる。
16.2 実験しよう
小さく初めて振り返りつつ繰り返す。
リーン・スタートアップにも書いてありましたね。
失敗への恐怖が改善の最大の敵だ。
本当の失敗はひとつしかない、それは失敗から何も学ばないという失敗だ。
16.3 失敗を抱擁しよう
失敗から何も学ばない人や組織って多すぎると思うの。
大抵の人は変化を好む。でも、他の誰かに変えられることは好まない。
あなたからの提案を拒むようだったら、それは問題が何か明確にできていないのだろう。
もしくは、間違った問題を解決しようとしているのかもしれない。変化の提案を自分ではやらない作戦がある。
提案する代わりに、考え認識した問題を可視化する。問題の影響を受ける人を巻き込み、
解決策を提案してもらう。自分自身が出したアイデアなら変化を受け入れやすいはずだ。
16.6 関係者を巻き込もう
提案してナンボだと思っていたのでコレは盲点。
確かに誰かが提案した内容を飲み込むよりも、
自分で提案したものの方が、
問題を把握している文変化も受け入れやすい。
これはおいおい実践してみたいと思います。
