|
|
|||||||||||||
|
|||||||||||||
|
 |
||||||||||||
|
|||||||||||||
|
|||||||||||||
|
|||||||||||||
|
| |||||||||||||
|
|||||||||||||
|
|
|||||||||||||
|
| |||||||||||||
「こんなシステムが欲しかったんじゃないよ！」－ システム開発にあたって、いきなりユースケースを書こうとして悩む前に、まずは必要となる3つの視点を整理してみよう。弊社より12月2日に発売される書籍『「課題・仕様・設計」－不幸なシステム開発を救うシンプルな法則－』より一部を抜粋して、全6回にわたりお届けします。
（編集部）
1958年生まれ。東京大学農学部獣医学科卒。同大学院修士課程中退。大手SIベンダーにて、開発支援ツールの開発、事務アプリケーション開発、ワークステーションのシステムプログラミングなどを行い、オブジェクト指向言語ならびに開発方法論に出会う。 1996年に独立し、以来コンサルタントとして、リアルタイムシステム、大規模分散オブジェクト指向システム、クライアントサーバーシステムの改善、要求定義、分析、設計、開発、管理、環境構築等に携わる。最近のテーマは形式手法を取り込んだ高信頼性・高生産性開発手法の研究。 現在、有限会社デザイナーズ・デン代表取締役。 システム仕様（System Specification） システム仕様とは 課題探求で分析定義されたモデルは、新しい業務の流れと情報の構造、各業務プロセスで行うべきことなどを定義していました。これに対してシステム仕様は、「ではその問題を解くために何をするシステムを開発すべきか」を定義するものです。 堅苦しく書きましたが、要はこれからどういう「仕掛け」を使って与えられた問題を解くかを定義する作業がシステム仕様です。 たとえば病院の例題では、再診予約を行うと「再診予約」という業務オブジェクトが生み出されるモデルを定義しましたが、この「再診予約」という「オブジェクト」をどのようにシステム化すべきか、つまり実現すべきかは、実はオープンな課題となっています。極端な話、「再診予約」という抽象的なオブジェクトを実現する手段として「手書きのノートを使う」という決定をしても一向に構いません。極端に予約数の少ない病院でしたら、コストの観点から見ても、わざわざ壊れたり電気代を使ったりする計算機を導入するよりも、手作業で全てを進めたほうがましかもしれないからです。 とはいえ、計算機を用いない実現に関してここで延々と議論しても仕方がありませんから、ここではやはり、何らかの計算機を用いたシステム化を前提に議論を進めていくことにします。 なお、ここで考えている前提は「システムとは外から与えられる情報により、ドメインモデルが更新され続けるものである」というものです。こうした考え方は特に目新しいものではなく、事務処理系のソフトウェアを、巨大なデータモデルを更新し続けているものとして捉える見方はむしろ一般的な方法です。 システムとしてのあり方は、どのような対話形式で外界と情報をやりとりするかで決定します。もし人間とシステムのやりとりを考えるなら、具体的には「どのような画面を出して、どのような情報を入力して、その結果どのような情報を外部表示するか」といったものを決めていかなければなりません。 また開発するべきシステムが、既存のシステムとやりとりを行わなければならない場合にも、「どのような情報を、どのようなタイミングでやりとりしなければならないのか」をきちんと決めなければなりません。 さて、このような説明を読んでどこかで聞いたような話だなと思った方もいらっしゃることでしょう。システムとその外界とのやりとりを明らかにすることにより、開発すべきシステムの性質を記述したもの、すなわち「開発すべきシステムの要求」を記述したものは、「ユースケース」という名前で呼ばれるものです。 このような意味で「ユースケース」はシステム仕様の一部を構成するものと考えることができます。対象とする問題領域の性質（業務プロセス、業務オブジェクト、業務ルール）がすでに確立しているなら、システム構築はいきなり「ユースケース」の定義から始めることも可能です。
たとえばユースケースによって導かれるシステム仕様の「妥当性」を検証するために課題探求の成果が必要とされています。本書では、この部分に「問題領域分析＋業務モデリング」と呼ぶ手法でアプローチしてきました。 もちろんこの手法が唯一絶対であるわけではありません。 ほかにもシステム仕様以前の段階へのアプローチとして、ユースケースを課題レベルに引き上げた「ビジネスユースケース」といった呼ばれ方をするものや、ビジネスの収益性に着目した「ビジネスケース」と呼ばれるモデルが使われたりする場合もあります。 ただ繰り返し強調し、理解していただきたいのは、どのようなモデリングアプローチをとるにせよ、またどのような名前で呼ぶにせよ、開発のための記述には「課題」「仕様」「設計」の3つの記述の区分があり、それぞれの果たすべき役割が違うということです。 （書籍 86～89ページより抜粋）
■ ＵＲＬ 「課題・仕様・設計」－不幸なシステム開発を救うシンプルな法則－ http://internet.impress.co.jp/books/1866/ こちらより書籍の購入が可能です
（酒匂 寛）
|
