最近(ようやく)読んだ本

リーン開発の本質 ソフトウエア開発に活かす7つの原則

まとまった時間がなかなか取れなくて、通勤時間にちょっとずつ読んでようやく読み終わった。
電車に乗っている時間が約5分とか短いので1ヶ月以上かかってしまった。。。
前の方を忘れながら読んでるのでもう1回ちゃんと読みたい。

心に一番響いたのは、「人を中心に置く」というところだ。
今、自分が開発をしていて悶々としている部分に答えてくれている。

ちょっと引用する。

リーン活動に乗り出す前に、「人について、何を本当に信じているか？」という問いに答えなくてはならない。プロセスにどのような態度で取り組んでいるか、考えてみよう。きちんとドキュメント化され、誰もが質問することなく従えるようなプロセスが、正しい道だと考えているだろうか？それとも、プロセスを標準化するのは、その作業をする人に、疑問を思ったり変更したりするための土台を与えるためだろうか？リーン原則は確実に、後者の考えに根ざしているのである。

はい、明からに今いる組織は前者ですな。人は中心ではない。
だれでも手順書通りに実施すれば開発できるように、徹底的にドキュメント化していく方向に突き進んでいます。
決められた手順通りに開発しているか各種チェックがあり、守ってないと先に進めない。

しかし、もっと酷いのは、そのやり方に対して疑問を持つことが皆あまりないということ。

• 立場の問題で言いにくい。特に下請けからは疑問に思っても中々言えないだろう。
• 自分たちでプロセスを改善していくという考えが根付いていない(これは、全く開発をしていないチームがプロセスを規定し、周りに押し付けるような形でこれまで来たのが失敗)

そして、一旦決められた「標準」のプロセスはなかなか変えられないような組織になってしまっている。
御偉方はこれまでのやり方でうまく言っている(と信じている)ので、やり方を変えたくないんだよね。

こうなると皆、あきらめムード。言ってもどうせ変わらないのでしょ？という感じ。

ちなみに自分は半年ほど前から、開発の途中からこのプロセスに乗っけられてしまいました。
プロセス改善を提案する時間なぞ確保されていないので、以下のようなやり方でなんとか凌いできました。

• プロセス上必要となるドキュメントは整合性を合わせつつ自分一人で作成
• そして、チームメンバにはなるべくこのプロセスを意識させないようにする
• もちろん、全てが意味の無い作業というわけではないので、有用な部分(コードレビューとか)はお願いする

しかし、そろそろ限界かもしれぬ。。。はっきり言ってこれは自分のモチベーションがかなり下がる。
もともと自分で手を動かすのが好きなので、チームを守るためとはいえ、かなり辛い。

というわけで、根本的なところの改善がそろそろ必要なわけですが、組織が大きい分、人を巻き込んで何かを成し遂げるというところが苦手な自分にとっては、なかなか難しいそうである。どうしたら良いもんかね。