リーン開発の現場

トヨタ生産方式をソフトウェア開発に応用した開発手法であるリーン開発を実際に行ったプロジェクトをもとに図やイラスト、写真を駆使して分かりやすく解説した本です。

リーン開発の概要は以下の通りです。

• 全体を最適化する
• ムダをなくす
• 品質を作り込む
• たゆまぬ学び
• 速く提供する
• 全員を巻き込む
• 改善を続ける

この本を見る限り、リーン開発自体に明確に定義されたプラクティスはないようですが、一般的には下記のようなプラクティスを行うようです。

• カンバン
• WIP（仕掛り作業）を制限する

「WIPを制限する」を見える化するための手段が「カンバン」という関係になっていました。

また、この本の中のプロジェクトでは、アジャイル開発である、スクラムからスプリント、プロダクトバックログ、職能横断型チーム、スタンドアップミーティングを、（明確に書かれていないが）XPからテスト駆動開発、継続的インテグレーション（CI）といったプラクティスを拝借しています。

「WIPを制限する」というプラクティスは、予定の機能を開発し終えたら次の開発を進めるのではなく、もし自分の担当ではない後続の受け入れテストが進んでいないのであればそのタスクを手伝うといった開発全体のスループットを良くする活動を行うというのは良いなぁと思いました。（あ、「ザ・ゴール」を思い出しました！）

ウォーターフォール的な考えだと、受け入れテストが進まなくてもどんどん開発を進めて、機能はいっぱいできているけどテストが終わってないのでリリースした機能は少しだけ、そして、ユーザーが使ってみたら改善点が出てきて開発が終わっている機能に作り直しになりムダになる。
ムダになるだけでなくプログラマーも体力的にも精神的にも疲れて開発スピードが落ちて負の連鎖になる。

何はともあれ、リーン開発やアジャイル開発は、パッケージソフトやB2CのWebサイトのような開発では導入しやすいですが、社内の業務システムではユーザー企業にシステムを育てるという考えがないとボトムアップでCIOのような方を説得するのは難しいと感じています。
ユーザー企業の上層部にシステムを育てるという考えがあれば自然にアジャイル開発なものになっていくと思うのだが・・・