The Dragon Scroll

Be just and fear not.

Lean Software Development(3)〜決定をできるだけ遅らせる。

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

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

何らかの理由で仕様が決まらない、決められないという事態は
良くあることですよね。
しかし、決めないことには、前に進むことはできない。
だから、暫定的に決める。
当然、顧客のアグリーを得る。議事録も取る。
でも、あくまで、それは仮の決定であるとする
(結局、何にも決まってへんやん、それ)。


そして、その決定が本当に、仮であったことに、
開発者は、随分後になって気付かされる。
仕様変更だと叫んでも、それは、遠吠えに過ぎない。
決定は、あくまで仮だったのだから・・・。
次の日、いやその日のうちから、デスマの行進が始まる。
設計書は書き直され、仕様の展開が急遽行われ、
プログラムの改修が始まり、単体テスト結合テスト
見直される。スケジュールは無理矢理、タスクを押し込まれ、
線表の後ろに溢れることもできず、残業時間が急激に増えていく。
さて、土日出勤の予定を組むか・・・。


コンカレント(平行)開発という考え方があります。
決められないものは、決めない。
決定は遅らせる。予測に基づく決定ではなくて、
事実に基づく決定を行うという考え。
このように、課題に対して解決策を一つに絞らず、
あらゆる可能性を考慮しながら問題にあたる考え方を、
オプション思考と呼びます。


なかなか良いアイディアです。
しかしながら、この考えを現実のものとするためのプラクティスが
必要でしょう。
本では以下の戦略を一例として掲げています。
どれも基礎的なものかもしれませんが、その基礎ができていない
プログラムやプロジェクトを今まで目の当たりにしてきた
のではないでしょうか。


情報隠蔽、振る舞いの隠蔽。
 モジュールの内部設計のFIXを遅らせる。
 インターフェースを実装から分離する。


・重複を避ける。DRY(Don't Repeat Once)の原則。
 ある処理が一箇所に閉じられていれば、処理拡張の仕様変更が
 発生した場合でも、その一箇所の修正で済む。


・将来的な機能の実装は遅らせる。
 「将来必要になるであろう」といった機能は今は盛り込まない。
 必要になったときに盛り込むようにする。


・余分な機能を避ける。
 「もしも」の場合の機能より、必要な機能の実装を優先する。


私は、最近改めて考えさせられたことがあります。
プロジェクトの目標とは何か?という問いです。
それは、デスマにならないこと、でしょうか?
それは、QCDとして成功を収める、ということでしょうか?
それらは、SIerが一方的に定義した"目標"ではないでしょうか。
真の目標とは、
お客様が、新しいシステムを使って、実際に利益や価値を生み出すこと
だと思うのです。


QCDとしては、問題ありませんでした!
でも、顧客は、使えないシステムを抱えることになりました!
というのは、あまりにも本末転倒ではないでしょうか。
そう考えると、この原則、「決定をできるだけ遅らせること」
というのは、顧客視点の原則でもあると、私は思うのです。