【CEDEC 2009】新作より難しい!?「派生開発における2つの問題」〜母体の作り方と派生開発の進め方〜

既に存在するソフトに変更を加えるのが「派生開発」。

新しいソフトを開発するよりは楽そうですが、株式会社システムクリエイツの清水吉男氏によればこれは大間違いとのこと。ソフトウェア開発プロセスのコンサルタントである清水氏は派生開発における危険性を説きます。

清水氏によれば、派生開発は新規開発よりも難しいものの、多くの人はそう認識していないとのことです。派生開発の多くは力業で行われ、スタッフは「全体を理解する必要がある」と認識しているものの、全体とは何か、理解とはどこまで分かればいいのかといった部分が曖昧であり、プロジェクト終了後に「理解が足りなかった」と反省はするものの、同じことが繰り返されるといいます。

派生開発とは「こういう処理が欲しい」という要求から行われますが、これを実現するための手法は様々であり、場当たり的な変更は後々に禍根を残します。間違った手法を使おうとしている所に誰かが指摘するのが理想であるものの、ソースそのものが改変されてしまっており、後でベストな方法が見つかっても変更できないのが現実となっています。後々新たな不具合の原因となる変更を清水氏は「潜在バグ」と呼称。潜在バグは何代か前の担当者が埋め込んだものなので検知もできず、ソフトウェアの全てを理解せずに行っている自らの変更もまた潜在バグの原因となっていきます。実体のないソフトウェアは劣化しないはずですが、派生開発で様々な変更が行われることで既存部分のレスポンスが低下するなどの劣化が発生。これは人が原因だ、と清水氏は指摘します。

追加機能の仕様書は書かれるものの、これを既存部分が受け入れるための仕様書が書かれないことが原因であり、こうした状態では、新たな機能の移植には人間と同様の「拒否反応」が起こるといいます。そもそも新規開発の時点からデータ構造が不適切だったり、複雑な条件分岐が行われたりすることも多々あり、これは潜在バグの原因や保守性の低下に直結しているとされています。

適切なプロセスが適切なタイミングで実行されるところにバグはなく、バグは全てプロセスで説明が付くとするのが氏の持論。派生開発のバグは要求とプロセスのミスマッチ現象であるといいます。氏が提唱する派生開発専用プロセス「XDDP」では変更と機能追加を二本立てとした要求仕様書を作成、要求と仕様を階層構造で表現することで変更のミスが大幅に減少。早い段階で変更の実現法をレビューすることで担当者の思いこみや勘違いを組織で見つけることが可能となっており、ツールや番号を付加して追跡性を確保することでより分かり易い開発が可能となっているとのこと。平均30%の工数が減少、中には60%もの効率化が図れた例もあるといいます。

清水氏はソフトウェアエンジニアリングを「ドキュメントを作るものではなく、品質を織り込むための物を書く」ことであり「ソースコードを読んで理解したことを表現すること」と定義。「XDDP」のような合理的な方法を導入することでゲーム開発が楽しくなることを祈ります、と締めくくりました。

【CEDEC 2009】新作より難しい!?「派生開発における2つの問題」〜母体の作り方と派生開発の進め方〜

関連ニュース

特集

CEDEC 2009

リメイク／リマスター

移植