混乱からの脱出 ～ XDDPで現場は甦った ～

(株)デンソー技研センター
古畑 慶次

はじめに

　前号で清水吉男氏よりXDDPの理論が紹介されました。今月号では、(株)デンソーにおけるナビゲーション開発へのXDDPの導入事例を紹介します。
　XDDPの導入を開始して、今年で４年目となります。効果検証の試行プロジェクトから始まり、希望者へのコンサルティング、そして、リーダー育成と一つのコンセプトに従って展開をしてきました。４年という時間はかかっていますが、正しく導入したプロジェクトでは、品質、生産性について確実に成果が出ています。そして、何より大きな変化は、何人かの技術者については、開発への取り組みが確実に“前向きになった”という嬉しい事実です。
　開発で多忙の中、社外発表や論文作成に技術者が自発的に取り組み始めました。今年は、XDDP関連だけで社外発表は3件、論文作成は2件を予定しています。また、コンサルティングに使用する成果物の内容や送られてくるメールの送信時間を見ると、自ら努力を始めた技術者の姿を容易に想像できます。
　まだ、“変化の兆し”というレベルですが、こうした技術者が組織に16％ 出て来れば（後述）、現場は甦り、技術者が本来の仕事を取り戻せると考えています。タイトルは、敢えて“現場は甦った”としました。彼らへの敬意と確信とを込めて、これまでの取り組みを紹介したいと思います。

混乱する開発現場

　XDDPを導入した開発現場は、CMMIのレベル2を達成した組織であり、プロセスは定義され、開発用のドキュメント類は多数作られていました。しかし、結合テストやシステムテストで大量のバグが発見されるのです。これらのバグを修正するには莫大な時間が必要でした。技術者たちは、自分の時間の多くをバグ修正に費やすことで、品質の高いシステムを作り上げていたのです。
　バグが収束しなければ、当然、次の開発に影響が出ます。前機種のバグ対応が終わらないうちに、次のプロジェトがキックオフされるため、技術者は新しい案件に着手できません。結局、新しいプロジェクトでも要件開発や設計の時間が十分とれず、テスト工程でバグが大量に出てしまいます。このように負のスパイラル(デスマーチ)から抜け出せない状態でいました。
　こうした開発の中で、技術者は現場を奔走する毎日を送っていたのです。そして、常に高負荷を強いられ、疲弊していました。繰り返される不具合や仕様変更により、新しい技術の習得や現状の分析をする時間を奪われ、自ら何かに取り組む気力を失っているかのように見えました。
　この状況を打開するには、テストに入る前に、仕様の抜け漏れ等の不具合を“気づく仕掛け”、あるいは、“気づいていないことを気づかせる仕掛け”が必要でした。そんな中、XDDPと出会ったのです。そして、“これなら行ける”と直感しました。

今、着目すべきは“派生開発”

　XDDPは、派生開発（前号参照）用に提案された開発プロセスです。実際の開発における新規開発と派生開発の割合を調べてみると、ほとんどが派生開発であることがわかりました（図：09年度の開発案件）。しかし、XDDPを展開した組織のすべての枠組み（仕組み、プロセス、成果物 等）は、新規開発向けに作られたものでした。確かに、清水吉男氏の本を除いて、ソフトウェアエンジニアリングの書籍は、新規開発を対象に書かれたものばかりです。CMMIのレベル3で必要となる標準プロセスを考えてみても、派生開発用の標準プロセスが存在している組織は少ないのではないでしょうか？
　現実的に考えれば、新規開発よりも派生開発を中心に考えていく必要があります。新規開発と派生開発では、顧客からの要求や制約条件が全く異なりますので、派生開発に新規開発のプロセスを適用するには無理があります。派生開発では、新規開発のように仕様書や設計書を文章として完成させていては、変更点や影響範囲の抽出が難しくなるのです。新規開発のように変更点を考慮して仕様書を作成しても、派生開発では、次の設計のフェーズで、またその変更点を抜き出して設計書に反映させます。こうした作業では、ドキュメントを作ることに注意が払われ、変更点や影響範囲に抜け漏れが出てしまいます。これが、テストでバグが大量に出ていた要因の一つでした。
　新規開発では、要求仕様書や各設計書を完成させて開発を進めます。しかし、派生開発で必要なのは差分情報です。新規開発のプロセスを使って、この差分情報を要求仕様書や各設計書に入れ込み、各ドキュメントを完成させながら派生開発を行えば、時間が足りなくなります。その結果、途中のプロセスを飛ばして、ソースコードの変更に取りかかるようなことが起こるのです。