神がシステム開発を変える

昨今ではAjile開発が増えてきているがこれは小規模開発の話だ。大規模開発では依然としてV字モデルが採用されているのが日本の現状である。

V字モデルとは重厚長大なプロジェクトが中心であった時代に登場し日本で最も普及している開発モデルだ。だがQCD*1の点で問題がある。金がかかる、時間がかかる、質が悪い、の3重苦。管理者は納期遅れに頭を抱え、開発者は自分たちの作った品質の悪い成果物にストレスを抱え、顧客は納期の遅れや品質の悪さにクレームを出さずにはいられない。これがV字モデルの末路である。

ではなぜそれが分かっていて大規模開発はV字モデルを採用するのか。それは代替がないからだ。

確かにオブジェクト指向開発にはUP*2というモデルがある。これはAjileモデルとちがい大規模向けといわれている。ところがSIer中心の日本の開発現場にはUPは適さない。V字モデルの工程とあまりに違うためだ。V字モデルしかやったことがない日本のSIerには荷が重い。扱えないのである。

私がかつて居たプロジェクトもV字モデルを採用していたがキックオフ1年てすでに破綻寸前だった。進捗は8か月遅れ(キックオフから1年で!)、その上品質が悪いと顧客からクレーム、開発者は残業と休出で疲弊しBP*3は次々と離れていくという状況だった。そこで私たちはGOD*4モデルへの移行を提案した。GODモデルとはジェネレータを中心に開発を進めるモデルである。V字モデルとほとんど変わらない工程を持つのが特徴だ。

稟議の結果提案は段階的に受け入れられることになり私たちは最初にUMLジェネレータの開発にとりかかることになった。UM図ジェネレータはクラス図やシーケンス図といったUM図を自動生成すツールだが開発のためにはジェネレータ開発の専門知識だけでなくUML図についての知識も必要だった。私たちはその役を買って出た。

ジェネレータにはさまざまな種類がある。UMLジェネレータ、ER図ジェネレータソースコードジェネレータ、機能設計書ジェネレータ、テスト設計書ジェネレータ、テストデータジェネレータ、ドライバコードジェネレータ、スタブコードジェネレータなど多岐にわたる。

ではなぜUMLジェネレータを選んだのか。理由は費用対効果だった。当時のプロジェクトではクラス図とシーケンス図の作成が開発者たちの悩みの種であった。ほとんどがオブジェクト指向開発の経験がなくクラス図とシーケンス図作成に関するナレッジがなかったためそのままでは納期オーバーしてしまうことが予想された。

そこで私たちは開発者にクラス図とシーケンス図を書くことをやめさせ、代わりにクラス図定義申請書とシーケンス図定義申請書を書かせるようにした。定義申請書作成にかかる工数を最初1週間と見積もったが、彼らのスキルを考えリーダーには3週間と提言した。これは本来彼らがクラス図やシーケンス図の作成にかかるであろう工数の3分の1以下であった。開発者が定義申請書を書く隙に私たちはジェネレータの開発に着手し彼らの定義申請書の完了と同時に私たちも完了した。定義申請書を投入するとジェネレータは高い品質のクラス図とシーケンス図を瞬時に生成した。そしてその生成物は高い評価を得た。

納品後に開発者にヒアリングをすると面白いことが分かった。実はジェネレータはベータ版を開発者に配布していた。これは彼らが自分たちの作成した定義申請書が正しいのか同化を確かめたいという要望に応えてのことだった。彼らは最初定義申請書に戸惑ったが、そのおかげでクラス図やシーケンス図を確認しながら定義申請書を書けるようになった。これは、彼らにとってのジェネレータプログラマにとってのコンパイラやデバッガの役割を果たすことを意味していた。プログラムと違い設計書のような文書の作成はその正しさの確認手段がない。そのため間違いに気づきにくいのだがジェネレータは開発者にとってテストツールの役割を果たした。これにより彼らは品質の高い定義申請書をかくことができた。

GODモデルの導入は期間短縮、コスト削減、品質向上という矛盾する3つの要素改善を成し遂げたのだ!

*1:品質、コスト、期間

*2:統一プロセス

*3:ビジネスパートナー

*4:ジェネレータ指向開発