Lean Software Development(1)〜ムダを排除する。

リーンソフトウエア開発?アジャイル開発を実践する22の方法?

リーンソフトウェア開発は、その和訳が出て以来、
私の中で最も大切な書籍の一冊となっています。

リーン開発では、7つの原則を上げています。
これから、その原則一つ一つについて考えていきたいと思います。

ムダを排除する。

leanとは、「スリムな」という意味を持っています。
リーンソフトウェア開発は、アジャイルな開発手法の一つですが
そのルーツは、TPS(トヨタ生産方式)と言われています。
トヨタ生産方式と言えば、徹底的にムダを省く考えを持っています。
これらの背景から考えてみても、この一つ目の原則が
リーン開発の本質を表わしていることが直ぐに分かります。

本書では、ムダとは「顧客が認める価値を製品に付加しないもの、
全て」と言い切っています。
ソフトウェア開発のプロセスを一つ一つ見直し考えたときに、
見えてくるのは、非常に多くのムダが存在しているという
ことです。

まっさきに上げられるのが、余分なドキュメントの作成ですね。
ドキュメント自体は、ステークホルダーの合意形成のために
必要なものですが、私たちが作っているドキュメント全てが
その役割を果しているとは思えません。

作業とドキュメントが一対一で紐付いている場合があります。
品質管理という錦の御旗の元、全ての行為には、ドキュメントが
必要、という考えが存在します。

例えば、テスタとデバッガのコミュニケーションのために用意された
不具合内容を記載するドキュメント。
たいてい、コミュニケーションをこのドキュメントに頼ろうとするため、
内容についてはかなり詳細なものが要求されます。
（これは重厚なドキュメントの問題というよりは
　コミュニケーションの考え方の問題だと思います。）
このドキュメントのステータスをファイルシステムのフォルダで
管理した日には、かなりのストレスを感じるようになります。
ファイルがどこへ行ったか分からなくなります。
フォルダを開くまでどこにあるか分かりません。
結局、いちいち検索しなければいけない(犬は予め消しておく)。
本当に、このような面倒な仕組みが必要なんでしょうか。
バグトラッキングシステムがあれば、こんなこと不要ですね。
いや、ツール以前に、やり方次第で改善できますね。

コミュニケーションの量と、ドキュメントの量は反比例の
関係にあると思っています。
つまり、コミュニケーションの不足を補うためにドキュメントを
増やさざるを得ない。
しかし、そもそも十分なコミュニケーションが取れていれば
ドキュメントは減らすことができるはずです。
そして、そのコミュニケーション不足は、チームビルディングが
行えていないという別の問題の現れなのでしょう。

本では、バリューストリームマップを書くことを薦めています。
これは、開発プロセスを書き出して、洗い出した各プロセスに
かかる時間を算出していくものです。
作業時間そのものと、その作業にかかるまでの待ち時間を
見える化していきます。
その結果、どのような作業でわれわれが時間を費やして、
待ち時間として時間を失っているかが分かるようになります。

各工程の作業をはじめる前にこのようなマップを、チーム全員で
作ってみると良いかもしれませんね。
そして、工程終了時の振り返りで、結果を確認する。
そこで得たフィードバックを次回に行かせるようにする。
このような学習・成長についても、リーン開発は原則の一つとして
上げています。