「リーンソフトウエア開発」の著者で知られるメアリー・ポッペンディーク氏。ムダを徹底的に排除するトヨタ式改善は，アジャイル開発の源流であるという。リーンソフトウエア開発の利点と現場における実践テクニックを語った。
欧米では今，「リーンソフトウエア開発」と呼ぶ考え方が広がりを見せている。もともと「リーン（Lean）」という言葉は，ムダ取りをベースとした生産管理手法として，1980年代に広く知られていた。そう，トヨタ式改善のことだ。
2000年以降，リーンの考え方がソフトウエア開発にも拡大。ムダを徹底的に排除するソフトウエア開発として注目され始めた。
ただし，リーンソフトウエア開発は開発方法論や開発プロセスではない。あくまで「考え方」を示したものに過ぎない。リーンソフトウエア開発の考え方は，アジャイル開発プロセスである「XP（eXtreme Programming）」や「スクラム」の源流となっていった。
では，リーンソフトウエア開発を実践すると，どんなメリットがあるのか。最も大きいのは，ムダを徹底的に排除することによって生産性と品質の向上を期待できることだ。
JITフローで作業を最適化
生産性向上においては「JITフロー」という考え方を使う。JIT（Just In Time）とは，必要なモノを，必要なときに，必要なだけ作ることを指す。このモノの状況を見える化したものが，JITフローである。
JITフローには「カンバン」という伝票を使って「未着手」「作業中」「完了」を示す。カンバンには厳密な定義はない。例えばXPであれば，「ストーリー・カード」と呼ぶ要件を書いた紙をカンバンとする。スクラムであれば，「プロダクト・バックログ」と呼ぶ実装する機能一覧から一機能を書き出したものをカンバンとする。
実践するときのポイントは，各カンバンをメンバーに選ばせることだ。トヨタ式改善では，次工程からその都度カンバンを渡され，それを確認してモノを作る。いわば「PUSH型」のJITフローである。
これに対して，ソフトウエア開発においては「PULL型」の方がうまくいく。各メンバーは自分の負荷を考えてカンバンを選ぶ。だから，非現実的な作業割り当てになりにくい。
カンバンに記した機能や作業の単位はできるだけ小さくしたい。作業単位が大きいと「必要なモノを」「必要なときに」という柔軟な対応ができない。
フィードバックで品質を向上
リーンソフトウエア開発には「ポカよけ」という考えもある。欠陥を出さないための仕組み作りのことだ。これにはいろいろなやり方があるが，リリースを短い期間で繰り返し，フィードバックを頻繁に行う方法を推奨する。
スクラムを提唱したケン・シュエイバー氏によれば，開発対象における期間の目安は三つに分類できる。
一つ目は，機能の一部をメンテナンスする開発。ちょっとした変更を加えるものだが，この場合は1週間を限度とする。二つ目は既存のアプリケーションに新機能を追加する場合。これは1カ月が限度だ。そして三つ目は，全く新しいアプリケーションを作る場合。これは3カ月が限度だろう。これ以上期間がかかる開発は，フィードバックが遅くなる。そのため欠陥が入り込むリスクは格段に高い。
今の時代，完璧な要件などあり得ない。いかにして短い期間でフィードバックを得て，それを反映するかが重要だ。もちろん，大規模システム開発であれば，3カ月を超える期間もあるだろう。だが，この場合でもサブシステムなどに分割し，あくまで3カ月を超えないようにする。
その点で，ウォータフォール型とリーンソフトウエア開発は相いれない。大きな単位で分析，設計，実装，テストと進んでいくウォータフォール型では，動くモノができるのがずいぶん先だ。これでは有効なフィードバックを得られない。
少しずつ，少しずつ作る――。これがJITを実現するリーンソフトウエア開発の本質と言える。
