今回は、リーンソフトウェアとこれまでの開発手法（ウォーターフォール型）との違いについて考えていきます。
火を噴くプロジェクトの特徴
開発プロジェクトにおいて納期ぎりぎりになってきて火を噴くということは多々あります。原因は色々と考えられますのが、主に以下のような要因が挙げられます。
- 要求定義の漏れやビジネス環境の変化
- 見積もり精度の甘さ
- 情報伝達ミス
- バグフィックスのコスト増
- マネジメントの甘さ
これらの項目について、開発モデルの違いを見ていきます。
要求定義の漏れやビジネス環境の変化
要求定義時にはなかった事柄や、状況の変化によって開発工数が増減する（主に増）ことは多々あります。これを防ぐために、システム開発会社では「契約」「仕様の確定」などを前段階できっちりと行うことが求められています。が、半年や一年後においてビジネスが変化していないと誰が言えるのでしょうか。また、もし状況が変化しているにも関わらずシステムが元のままであった場合、いわゆる使われないシステムができあがることになり、顧客満足度は著しく低いものになります。
ウォーターフォール型の場合、この問題はとても大きいものになります。特にWebシステムの場合は短期間での開発が求められる上に、状況の変化も激しいマーケットです。この場合にウォーターフォール型のような階段を上がっていくような開発手法は問題の火種を常に抱えているようなものです。
さらに契約というのは主に自分たちの身を守る事柄について明記されていることが多く、顧客と自分たちとの間に壁を作る結果につながります。そのため、本来であれば顧客の要望しているビジネスを一緒に成功させるための存在であるシステム開発会社が敵と見なされる場合もあります。この辺りは別途記したいと思います。
見積もり精度の甘さ
見積もり精度があまく、工数が膨らんでしまったというケースもあります。これは実際の見積もりを行う人が現場感がなかったり、必要と思われる機能を予知できなかったりする場合に起こります。そのため、工数の算出は現場と一緒になって行う必要があります。その結果を顧客とすりあわせるのがマネージャの役目と言えます。そして無駄と思われる機能を削ったり、代替え手段を用意することによって、双方の満足いく予算および納期に仕上げていくことが重要です。
また、もう一つのコツとして全てを見積もらないということがあります。状況の変化の件も重なりますが、初期の段階で全てを見積もるのは非常に困難です。で、あればリリースの段階を複数回にわけ（リーンソフトウェアではイテレーションと呼びます）、その段階ごとに見積もりを行っていくという方法です。
情報伝達ミス
メールや電話での言った言わないや伝え漏れなどによって勘違いがおき、開発に戻しや遅延が発生することがあります。リーンソフトウェアでは顧客、開発現場の距離を縮めることを推奨しています。遠隔地でのプロジェクト推進も増えていますが、それでも同じ部屋にいて暗黙知を共有するのには敵わないと書かれています。実際、距離は温度差につながりやすく、お互いのヘッジにつながります。開発をさらにアウトソースする場合においても顧客との打ち合わせに同席したり、密にコミュニケーションをとれる状態にしておくことで仕様には書かれていない情報を知り、品質を高めることができます。
また、開発のマイルストーンをできるだけ小さく、コミットやテストの回数を増やすことで、間違った方向に進んでしまうのを前もって防ぐことができます。できれば毎日状況の確認と現段階でできているシステムのテストを行うといったことが望ましい状態です。
バグフィックスのコスト増
バグを出さないコツは、テストの自動化とコーディング量を減らすことにあります。成果物の規模を極力小さくすることで、1行あたりに含まれるバグの可能性を減らしていくことが可能です。これはフレームワークの活用や、オープンソースの活用で実践することが可能です。
テストの自動化についてはできるだけ初期段階から取り組んでいく必要があります。都度人力でテストを行っているのでは時間も工数もかかってしまいます。できるだけ速い段階でテストの自動化を仕組みづくってしまい、テストされていないコード部分を極力減らすようにしましょう。
マネジメントの甘さ
マネジメントは予想以上にコストのかかる作業です。元来、プロジェクトマネジメントは作業における無駄を省き、作業量を最大化する目的で作られているそうです。その目的から言うと、プロジェクトを円滑に進めるために行うものではないということが分かります。実際、プロジェクト管理を行っている工数があるなら顧客との信頼性を築く、テスト自動化の仕組みを考える、リリース契約を立てるなどの生産性のある仕事に取り組んだ方が良いと考えられます。
ガントチャートをいくら奇麗に仕上げたところで思い通りに運ぶ訳もなく、各人のタスクは一人がトップダウンで進めるのではなく、各人からの申告制に任せる方がスムーズです。ちょっとした状況変化にも対応できないマネジメント手法であれば、元々取り入れない方が良いと言えます。
ウォーターフォール型の問題点
最大の問題点は「前行程に間違いはない」という前提で進んでいる点です。人が行っていることですから、間違いがある可能性はあります。また、間違っていなくとも状況の変化によって前行程の前提条件が変わってきたということも良くあるケースです。
その意味でリーンソフトウェアは、間違いや変化に強くなる開発手法と言えます。もちろん、手法だけで成り立つものではないため、同じ工数をかけるにしても役に立たないもの（無駄なもの）に工数をかけるのではなく、役立つものに工数をかけ、無駄なものは排除して変更する箇所を減らしていく努力が必要になります。
実際に開発の中に取り入れていくには
重要なのは顧客との意識の擦り合わせです。相手がウォーターフォール型で、こちらがリーンソフトウェアでは最初は良いとしても後になってから必ずほころびが生じます。まず相手に理解してもらうことによって、開発プロジェクトを双方にとって良いものにしていこうという意識を共有することが重要です。
まとめ
人月型に代表されるように、ソフトウェア開発の現場は30年以上前からそれほど進化していません。根底に流れるソフトウェアに対する意識や人月の扱い、建設業界のような孫請け/ひ孫請けなどのつながりが解消しない限り、なかなか難しい問題もあります。が、顧客がこれまでに感じてきた問題点（特に前に火を噴いた経験がある企業等）とリーンソフトウェアの利点とがマッチすれば、この新しい開発スタイルはきっと受け入れられるのではないでしょうか。