PR

設計ミスはシステム設計段階にはゼロにすることができない。だが、大規模開発に不慣れなメンバー/利用者に起因する設計ミスや、データベース正規化を追求しすぎた場合、想定外のロスコストにつながる。

 今回は設計起因のロスコストを取り上げます。設計起因といっても多岐にわたります。設計ミスに伴う修正作業は「本来発生すべきでない費用やムダな費用」ですから、広い意味ではロスコストです。ただし、設計ミスは設計段階でゼロにすることはできません。品質マネジメントの世界では通常、統計的に扱われ計画にも織り込まれます。

 この連載で取り上げているのは、レベル2ロスコスト「計画と実績の差」ですから、想定内で、ミスを修正すれば解決する事象は対象外とします。しかし、中には設計方式や設計方針そのものにまずいところがあって、プロジェクト全体に影響が及ぶようなものもあります。今回は、このような設計起因で大きなロスコストにつながるアンチパターンを取り上げます。

パターン1:チームでの開発

 最初のアンチパターンD001を図1に示しました。タイトルは、「データ辞書の統制取れず×データ不整合×対策によるアプリの複雑化→品質対策」です。ロスコストに至る経緯は、以下のような流れです。

図1●チームでの開発経験が少ないメンバーで構成されるプロジェクト
図1●チームでの開発経験が少ないメンバーで構成されるプロジェクト
[画像のクリックで拡大表示]

経緯

 プロジェクトは、チームでの開発経験が少ないメンバーで構成されていた。基本設計でデータモデリングを行い、データ辞書を作成。データ辞書を利用する開発基準はルール化し、詳細設計のキックオフミーティングでメンバーに説明した。

 しかし、仕様統括の意識は薄く、データ辞書へのデータ項目の追加、変更を各自が実施したため、整合性がとれなくなった。また、データ項目の属性の変更をプロジェクト内に通知せず、影響するプログラムのロジックも見直されなかった。

 この結果、テスト段階でデータの不整合による不具合が多発した。データの不整合を解消するために、中間的なテーブルの追加とアクセスを制御するロジックを追加して対処することになった。その結果、データ処理するアプリが複雑化しテストケースが増加した。品質向上のための工数増加によりコストが増加した。

 このアンチパターンでは、データ辞書を使う大規模開発を取り上げています。一人、もしくは少人数で密なコミュニケーションを取りながら開発を進められる小さなプロジェクトなら、全体の整合性を意識しなくても問題は起きません。ところが、開発規模が大きくなり、複数のチームで開発するようなプロジェクトになると、品質を確保しながら効率良く開発するために、データ辞書などの仕掛けや開発基準のようなルールが必要になります。

 図1では「チーム開発の経験がなく仕様統括の意識なし」としていますが、個の力で高い生産性と技術力を発揮してきたメンバーが陥りやすい落とし穴です。特に怖いのが、途中でプロジェクトの規模が拡大したときです。今までの開発スタイルからチームでの開発に適したスタイルに切り替えなければならないのですが、徐々に規模が増えていくようなケースでは、気付くのが遅れます。

 データ項目の追加、変更を各自が行うとデータ辞書の整合性が取れなくなります。不整合には、データ項目へのアクセスを容易にする中間的なテーブルを追加し、これに伴いアクセス順序なども考慮したロジックを追加して対処します。しかし、テーブルが増えるとデータにアクセスするプログラムが複雑になり、不具合も入り込みやすくなります。また、データとプログラムの組み合わせが増えますので、テストケースも大きく増加してしまいます。

対応策

 統制が取れた状態でデータモデルを管理できる体制を作ることが第一です。プロジェクトの開始時点で、データ辞書などの仕掛けや開発基準のようなルールを定めることはもちろんですが、徹底するために仕様統括/標準化責任者を任命します。大規模プロジェクトの場合は、仕様統括/標準化チームを編成します。データ辞書のメンテナンスは、このチームが専任で行い、変更があればプロジェクト内に文書で通知します。

 小さなチームでも、仕様統括/標準化責任者の任命は必要です。専任でなくてもかまいません。データ辞書の変更は日次のミーティングなどで共有します。プロジェクトメンバーが増えて、ミーティングで共有することが困難になってくれば専任化し、コミュニケーションルールを変更します。プロジェクトマネジャーの意識も大切です。参加メンバーが増えると、要求されるマネジメントスキルも質的に変わってきます。その規模に対応できるプロジェクトマネジャーの参画も検討します。

 では、混乱状態に陥った時の対処は、どうすればよいでしょうか。図2を見てください。データ辞書の構造が崩れ、応急処置で何とかカットオーバーしても、システムはつぎはぎだらけという状態になります(ケースA)。この状態で保守を行うと、さらにいびつな状態となり障害が発生するリスクも高まります。

図2●プロジェクトを中断しても再整備
図2●プロジェクトを中断しても再整備
[画像のクリックで拡大表示]

 再整備をしていびつな状態を解消した方が良いとわかっていても容易にはできません。いったん、稼働した後では、手を加えてトラブルにつながると責任問題になりかねないからです。基幹業務になるほどこの傾向は強くなります。建物なら傷んでいたり、汚れていたりする箇所を目にして実感することはできますが、ソフトウエアは目に見えないので、いびつな構造になっていることを利用部門などに理解してもらうことは困難です。

 ですから、カットオーバーする前にプロジェクトを中断してでも、データ辞書を整備することをお勧めします。プロジェクトを中断するのも容易ではありませんが、カットオーバー後の再整備が困難であることを前提として、ライフサイクル全体でロスコストを考慮して判断します。