リーンソフトウェア開発とレスポンスの良いソフトウェア

またしても原書にトライして四苦八苦、七転八倒しております。

Implementing Lean Software Development: From Concept to Cash (Addison-Wesley Signature Series (Beck))

そもそも最初 "Lean Software Development" と聞いたときに「傾いたソフトウェア開発」かと思ったからね。僕の英語力なんてそんなモンです。ちなみに "lean" とは「贅肉のない」「引き締まった」「無駄のない」といった意味だそうだ。

今 Chapter 4 Waste まで読み終わったところで、このまま一気に読んでしまいたいと思うほど面白いのだけれど、英語力の乏しさゆえにそれも出来ずもどかしい思いをしている。今のところ思うのは、この本のキモはサブタイトルにある "From Concept To Cash" であり、要求を受け取ってから顧客に届けるまでの end-to-end のムダをいかにそぎ落とすか、ということだ。この end-to-end のサイクルを出来る限り素早く回すことがムダ取りにつながるのだ。

これは開発プロセスの設計の話だけれど、僕が思うにプロセスの設計というのはプロダクトの設計よりも分かりにくい。デザインパターンの美しさというのは "Aha!" という感覚が得られて分かりやすいのだけれど、プロセスとなると「うーん、なるほど・・・分かったような分からないような・・・、でウチの組織の場合にはどうなるんだ・・・？」と雲を掴むような気分になりがちだ。

そこで、リーン開発のキモをこんな例えで考えてみたらどうだろう。いや、本当に良い例えかは分からないけれど、僕自身は次のような例を考えることで腑に落ちた。

それはGUIアプリケーションにおけるレスポンスの例えだ。GUIアプリではユーザー操作に対するレスポンスは使い勝手を大きく左右する重要なポイントであるが、レスポンスの良いソフトウェアは開発コストも小さく抑えられるのではないか。つまり、ユーザーの操作から応答を返すまでのサイクルを短く設計することで、開発のムダもそぎ落とすことが出来る、と僕は主張したい。

レスポンスの悪いソフトウェアを考えてみよう。まずバッチ処理のダイアログを起動して、色んな設定項目を入力する。最後にポチッと「実行」ボタンを押すと一気に処理が走り始めるのだけれど、やたらと時間がかかってマウスカーソルは砂時計。「あれ？おーい？・・・こいつ動いてるのかな？」なんて思ったり。

こういった場合はやはり、プログレスバーが必要となる。ユーザーへの進捗報告だ。しかし僕の経験では、プログレスバーの実装というのは見かけほど簡単じゃない。今実行した処理が全体の何％に相当するかを算出するというのはなかなか厄介なのだ。この算出はどうしても複数の concern に跨ってしまうことが多く、「関心の分離」の原則を壊してしまう。また、プログレスバーというGUI部品とバックグラウンドの処理という2つのレイヤーの異なるものを繋がなくてはいけない、といのも厄介だ。しかも、ここが重要なのだが、プログレスバー自体はユーザーに Value を届けていないわけで、プログレスバーの開発コストというのは「ムダ」なのである。

次に必要になるのが「中断」機能だ。ユーザーというのは気まぐれなもので、「実行」ボタンを押した数秒後に「やっぱりやーめた」と処理を中断して違うことをやりたくなるものだ。あるいは、「あ、さっき入力した設定項目間違えた！最初からやり直したい」って場合もある。そんなわけで中断機能は必須なわけだけれど、ご存知の通りこの実装もなかなか厄介なのだ。まずユーザーが割り込みで中断ボタンを押せるような工夫が必要となるわけで、スレッドを使うかマイクロスレッドのような機構を考えるかということになるのだけれど、面倒であることに変わりはない。しかも、中断した以上は処理は最初の状態までロールバックする必要がある。そしてプログレスバー同様、この機能もユーザーには Value を届けていない。

もうお分かりだと思うけれど、これらの開発コストはレスポンスが良い機能の場合にはすべて不要なものなのだ。この「良いレスポンス」が "Lean" ということなのだ。

もしあなたが開発プロセスにおいて、顧客に対する進捗報告（プログレスバー）や仕様変更（中断ボタン）の対応に苦慮しているのならば、それは from concept to cash のサイクルタイムを短くすることで改善できるのかもしれない。

・・・あ、ちなみにこの本は和訳が出ていて、僕は英語の勉強のために敢えて原書に挑戦しているだけ。日本語で読みたい方はこちらをどうぞ。

リーン開発の本質