マジカル仕様書はデスマーチへの片道切符

スキル

» 2010/06/02

　こんにちは。草食系妙齢プログラマ　野口おおすけです。最近、さまざまな大盛りメニューが流行っています。さっそく近所の大盛りラーメンを食べてきたのですが、職業柄あまりカロリーを消費しないのに食べて大丈夫だろうか、と心配になる今日このごろです。

　今回は、前回に引き続き「マジカル仕様書」についてお送りいたします。前回は「仕様書とは～」という話題でした。今回はケーススタディを通して、「マジカル仕様書」がどのようなものか、なぜそのようなものができてしまうのかをご紹介していきます。

■データベースは使いません！？

　どんな言語を使って実装するか、どのようなフレームワークやパッケージを利用して実装を行うか。これらの内容は開発の初期段階で決定されることの1つです。通常のWebアプリケーションであれば、データを保存する技術として必ずと言っていいほど、リレーショナルデータベースが利用されます。最近ではKVS（Key Value Store）という仕組みもありますが、まだまだリレーショナルデータベースを利用する場面の方が多いかと思います。

　Aさんはとある業務システムの開発担当にアサインされました。システムの構成を示す仕様書を見ると、サーバ構成はとても高価で素晴らしいものです。しかし、よくよく見ると、利用されるミドルウェアのうちで何かが足りません。そうです。データベースについての記述が一切なかったのです。実はこっそり裏にかいてあるとか、白文字で設定されているとか、そういう何かでもありません。

　まさか、すべてのデータをXMLに保存するようなシステムなのか？ それとも、CSVに全データをもつという何とも恐ろしいシステムなのか？ 悪い方向に想像は広がるいっぽうです。Aさんは設計者に「この仕様書ではデータベースについて何も触れられていませんが大丈夫ですか？」と尋ねました。

設計者：「データベースは使いません！ Oracleを使います！」

　もはや仕様書が云々というレベルではない会話になってしまいました。このように仕様書を作成する際、そこに書かれるべきことに対する前提知識がまったくなければ、仕様書を作成することはできません。この場合の設計者はOracleはデータベースの一種であるという知識がなかったのです。

　ここで、マジカル仕様書を作ってしまった原因を考えてみましょう。設計者は要件に応じた実現方法が分からなかったのです。今回挙げたケースは極端な例ですが、実際の開発においては大なり小なりこのようなことが起こりえます。TDD（Test Driven Development）では、最初にゴールとなるテストパターンを作成し、それを目指してプログラムを作成します。それと同じように、設計も常にゴールを見失わないように行うことが必要なのです。

■同じ項目のはずなのに？

　データベース周りのでマジカル仕様は、場合によっては「デスマーチへ一直線」という事態を招きます。どのようなシステムを作成する際も、データベース周りの設計は設計者の大きな悩みの種の1つです。経験上、一定の理念のもとにモデリングされたデータベースは多少複雑であっても、想定したデータをすぐに抽出することができます。逆に、行き当たりばったりのモデリングをすると、システムが稼働開始後に何かしらの問題が発生します。運用する人たちの安寧のためにもモデリングは気をつけて行いたい部分です。

　Bさんはとある業務用Webシステムの開発担当にアサインされました。開発工程は順調に進み、間もなくプログラミングを始めるという段階です。この時点で、データベース周りの設計は終了していると聞いていました。先ほどの「データベースは使いません」という設計担当とは違い、滞りなく設計は完了したとのことです。

　さっそく、Bさんは実装にとりかかりました。しかし、実装を進める中で、テーブルレイアウトを確認すると、とあるテーブルではユーザーIDが英数字8桁で設定されていたのですが、別のテーブルでは英数字12桁で設定されていました。また、金額を扱う項目にカンマで3桁ずつ切ったものが入っていたり、普通の数字列が入っていたり……。

　このように同じ項目でも違う型でデータベースに登録されていた場合、プログラム上は別の扱いをしなくてはなりません。多くのデータモデリングツールでは辞書機能（ユーザー型定義管理機能）があり、同一のデータは同じ扱いがされるようにモデリングを行います。ツールやモデリングの基本理念が正しく理解されていたのであれば、先ほどのような設計にはなり得ないのです。残念ながら、このような状態に陥った場合は毎日のようにテーブルレイアウトが変更され、それに対応するためのプログラムの修正やテストなどに大幅な工数を割くことになります。

　画面上では、右詰めにするからデータベース上も右詰めのカラムにする、といったモデリングを行っているものもあります。プログラムのロジック的に有利な場合もありますが、データのメンテナンスを考えると有効な手法ということは難しいでしょう。設計者は、常に複数の視点を持って設計を行わなければなりません。データベース設計はそのなかでも最もそのような視点が求められる部分です。入力・出力をはじめ、他の機能との整合性など常にさまざまな視点をもって設計を行わなければなりません。

　さて、今回は2つのケースを見てきました。両方ともデータベース絡みの問題です。このようなマジカル仕様書を見落とすと根が深く修正するにもコストがかかり、顧客・開発企業にとってどちらも幸せにならない結末となります。マジカル仕様書は、許容量を超えてしまうとデスマーチへの片道切符になる代物です。ゼロにするための対策や発生した時の対策はリスクマネジメントの一環として考えておかなければなりません。

　「設計者や実装者のスキル不足」と言ってしまえば話は終わってしまいますが、それらを発生させないような取り組みはプロジェクト全体で行っていくべきことなのです。

　2回にわたってマジカル仕様書について見てきました。次回は「なにこれ……」と思いたくなる「ミステリアスソース」についてのお話です。

　それではまた次回。