|
|
|||||||||||||||||
|
|||||||||||||||||
|
 |
||||||||||||||||
|
|||||||||||||||||
|
|||||||||||||||||
|
|||||||||||||||||
|
| |||||||||||||||||
|
|||||||||||||||||
|
|
|||||||||||||||||
|
| |||||||||||||||||
「こんなシステムが欲しかったんじゃないよ！」－ システム開発にあたって、いきなりユースケースを書こうとして悩む前に、まずは必要となる3つの視点を整理してみよう。弊社より12月2日に発売される書籍『「課題・仕様・設計」－不幸なシステム開発を救うシンプルな法則－』より一部を抜粋して、全6回にわたりお届けします。
（編集部）
1958年生まれ。東京大学農学部獣医学科卒。同大学院修士課程中退。大手SIベンダーにて、開発支援ツールの開発、事務アプリケーション開発、ワークステーションのシステムプログラミングなどを行い、オブジェクト指向言語ならびに開発方法論に出会う。 1996年に独立し、以来コンサルタントとして、リアルタイムシステム、大規模分散オブジェクト指向システム、クライアントサーバーシステムの改善、要求定義、分析、設計、開発、管理、環境構築等に携わる。最近のテーマは形式手法を取り込んだ高信頼性・高生産性開発手法の研究。 現在、有限会社デザイナーズ・デン代表取締役。 仕様と設計 「システム仕様」はシステムが「何」をすべきものかを定義します。システムがある仕事をすると成し遂げられる結果です。 たとえば、簡単ですが目の前に「足し算」をするシステムがあるとしましょう。このシステム仕様は単純で、与えられた2つの数の和を求めるというものです。
これはあまりにも簡単ですね。「足し算」のシステム仕様を受け取った設計者、実装者はあまり悩むことはないでしょう。ここで書いた「仕様」とは、この仕様を設計実装した結果が、式で指定されたものになればよいことを示しています。まあこんな単純な仕様に対する設計実装は、実際に足し算演算子（＋）を用いて実現するのが普通でしょう。 もしC言語を用いて、この仕様を実現せよと言われた場合は、たとえばプログラマーは以下のような設計実装を行うかもしれません。
問題がこのようなものばかりなら、開発者も悩まずに済みそうですが（というより仕事として成立しないかもしれませんが）、実際には多くの問題で仕様とそれを実現すべき設計実装の関係は自明ではありません。 たとえば「ある顧客が登録済みか調べる」というシステムの仕様を考えてみましょう。
ここで示されている仕様は与えられた「顧客」が顧客集合の中に含まれているかどうかで、結果が決まることを示しています。「足し算」の場合は引数を文字通り足し合わせれば済んだのですが、「顧客∈顧客集合」で示される「顧客が顧客集合の中に含まれている」という条件判断の設計実装はどうすればよいでしょう。 実際のプログラミングでは顧客全体の情報はファイルに書かれていたり、メモリの中に格納されていたり、あるいはデータベースから参照しなければならないかもしれません。 ではシステム仕様としてこうした要求（データベースを使う、あるいはファイルで十分など）を指定しなくてもいいのでしょうか。もちろん実際に動作するシステムを作成するには、最終的には「顧客」とその集合をどのように扱うかを決定してやる必要があります。しかし、ここで考えているレベルのシステム仕様は、あくまでも業務上の課題をシステム上の論理的な構成物の関係として写像した場合にどうなるかを記述するものです。 この例で言えば、「システム仕様」を考える人の関心は、顧客がある顧客集合の中に含まれているかどうかを判断できさえすればよく、その実際の実現に関してはさほどの関心がないということになります。いえ、もっと正確に言えば実現の話と業務の写像の話はレベルが違う話なので、それらを混同したくないということなのです。 適切な抽象化が行われていれば、設計実装の自由度が高まり、性能上の改善やいわゆるリファクタリングを行うことが容易になります。リファクタリングとは、既存のソフトウェアの外的な振舞いを変えることなく、内部の構造を改善し信頼性を向上させるような仕事全般を指す言葉です。 こうした問題では「システム仕様」を記述する際には、設計実装に近い語彙を取り除いた「用語」だけで仕様を記述することが大切です。 なおこうした特徴は特にオブジェクト指向言語を用いた設計実装で生かすことができます。たとえば 顧客 ∈ 顧客集合 という表現を、適当なプログラム言語で 顧客集合.includes（顧客） と設計・実装したとしましょう。ここでは顧客集合オブジェクトに、includesというメソッドを適用しようとしています。includesは適用対象のオブジェクト（ここでは顧客集合）に引数の「顧客」オブジェクトが含まれているかいないかを論理値Booleanで返すメソッドです。顧客が集合に含まれていれば真を、そうでなければ偽を返すとします。 オブジェクト指向言語の特徴である「多相性（ポリモルフィズム）」を用いれば、顧客集合オブジェクトには実行環境の要求に最も相応しい実装を選ぶことができます。その場合「顧客集合」がファイルを使った実装なのか、データベースを使った実装なのか、それともほかのシステムに対する単なる問い合わせなのかを、少なくとも仕様レベルでは気にする必要はなくなります。
ここで説明した「仕様」はかなり単純なレベルです。実際のシステム構築を考えた場合には、仕様レベルでももっと複雑な構造と振舞いを扱わなければなりません。この本では主に事務処理システムを考えたシステム仕様のまとめかたも説明していきます。 課題、仕様、設計の関係
右の図はここまで説明してきた課題とシステム仕様、そして設計実装の関係を表したものです。課題を導くのは現実世界の要求です。得られた課題が解くべき問題を表しているので、次にその問題を「いかに解くか」をシステム仕様としてまとめます。仕様を導く際に必要なのがシステム要求ですが、ここにはどのような手段で解を構築したいかの要求が含まれます。 設計実装が実際に動くソフトウェアを作り出すために定義されるものです。普通の開発方法論ならばこの設計を受けてさらにソースコードの作成といった作業について述べるところですが、この本では設計実装というひとくくりにして考えています。 設計実装をして、プログラムが完成したら終わりでしょうか。いいえ、そうではありません。設計実装が行われ、システムが稼動すると、現実世界へ影響が現れます。 この影響はもともと分析された「課題」へと還元されます。こうして次の課題定義は新規ビジネス要求と既存のシステム両方から影響を受けることになるのです。 また図ではいろいろな場所から矢印が入ってきています。これは課題解決のサイクルが必ずしも課題の定義からだけ始まるわけではないことを表しています。 ビジネス要求の変化、システム要求の変化、そして構築技術の変化によっても問題解決のサイクルは駆動されます。 本書には、この図が繰り返し出てきます。 （書籍 28～33ページより抜粋）
■ ＵＲＬ 「課題・仕様・設計」－不幸なシステム開発を救うシンプルな法則－ http://internet.impress.co.jp/books/1866/ こちらより書籍の購入が可能です
（酒匂 寛）
|
