|
|
|||||||||||
|
|||||||||||
|
 |
||||||||||
|
|||||||||||
|
|||||||||||
|
|||||||||||
|
| |||||||||||
|
|||||||||||
|
|
|||||||||||
|
| |||||||||||
「こんなシステムが欲しかったんじゃないよ！」－ システム開発にあたって、いきなりユースケースを書こうとして悩む前に、まずは必要となる3つの視点を整理してみよう。弊社より12月2日に発売される書籍『「課題・仕様・設計」－不幸なシステム開発を救うシンプルな法則－』より一部を抜粋して、全6回にわたりお届けします。
（編集部）
1958年生まれ。東京大学農学部獣医学科卒。同大学院修士課程中退。大手SIベンダーにて、開発支援ツールの開発、事務アプリケーション開発、ワークステーションのシステムプログラミングなどを行い、オブジェクト指向言語ならびに開発方法論に出会う。 1996年に独立し、以来コンサルタントとして、リアルタイムシステム、大規模分散オブジェクト指向システム、クライアントサーバーシステムの改善、要求定義、分析、設計、開発、管理、環境構築等に携わる。最近のテーマは形式手法を取り込んだ高信頼性・高生産性開発手法の研究。 現在、有限会社デザイナーズ・デン代表取締役。 課題・仕様・設計 ソフトウェアの作り方という話題だと大抵は「まず要求定義を……」といった上流工程の話から始まることが多いのですが、ここでは開発者にとってイメージしやすい下流工程から話を始めましょう。動くソフトウェアを作るためには、設計と実装を行わなければなりません。どのようなプログラム言語を使うにしろ、ソフトウェアの構造を決め、動作のための環境を決めてやらないかぎり求めている仕事を行うことはできません。 高機能な「ソフトウェア部品」を豊富に持っていれば、いきなり動く簡単なプログラムを作ることもできるかもしれませんが、多くの場合、どのようなシステムを作りたいのかを定義した「システム仕様」を作成する必要があります。システム仕様と設計の違いは「何を作りたいのか」と「どう作るのか」の違いです。たとえば 「ファイルを開いて20バイトごとに書き込まれている整数（4バイト長）を加算した合計値を求めよ。ただしその整数の直前の短整数（2バイト長）の値が25（十進数）の場合だけを集計の対象とする」 というのは、プログラムを「どう作ればよいか」への指示を表していますから「設計」です。これに対して 「これまで商品“A”を注文した顧客の延べ人数を求めよ」 という記述はシステムが「何」をすべきかを表現しているので「システム仕様」と呼ばれます。後者はシステムの目的を表していて、内部の細かい実現方法については特に何も述べていません。まあこの仕様の書き方はあまりにも一般性がありませんから、普通は 「引数で指定された商品を注文した顧客の延べ人数を求めよ」 といったものになるでしょう（これでも相当単純化していますが）。もちろんこのままでは曖昧な部分が多くてそのまま設計することはできません。たとえば「商品」「注文した」「顧客」といった言葉の意味がはっきりわからないからです。また「延べ人数」といっても過去全ての履歴を含むものなのでしょうか。疑問はつきません。 こうした曖昧さは仕様を書くために使ったそれぞれの「語彙」を、より厳密に定義することによってしか取り除くことはできません。しばしば設計した後にこの曖昧さを取り除こうとする開発者がいますが、こうすると「何が正しいのか」が段々と曖昧になり、ソフトウェアの間違いを取り除くことが難しくなってきます。 さてもう一歩遡りましょう。システム仕様というのはある特定の問題の「システムによる解決方法」を記述したものです。ではここで定義された「システムによる解決方法」は、もともとの問題に対して正しい解法なのでしょうか。 しばしば米国の訴訟社会を皮肉るジョークのネタとして使われますが「猫を乾かそうとして電子レンジに入れたら死んでしまった。乾かそうとした人は電子レンジのメーカーを訴えた。なぜなら猫を乾かすなと説明書に書いていなかったからだ」というものがあります。かわいそうな猫のことは、ここでは忘れることにしますが、このジョークは「解くべき問題」とそれに対して「与えられた解」のミスマッチが引き起こす悲劇が書かれています。 もともとの課題：猫を乾かしたい 与えられた解（仕様）：猫を電子レンジに入れる さすがに電子レンジに猫を入れようとする前には、これがよくないやり方だと気付く人は多いと思いますが、これを現実世界の課題とソフトウェアによる解法に置き換えた場合、しばしば間違いに気が付きにくいという事態を見ることができます。もちろんこれはソフトウェアが目に見えないものであるうえに、課題そのものが猫を乾かすよりももっと複雑でわかりにくいものだったりするからです。 「課題に対して正しい仕様」を書くことができなかった場合、知らず知らずのうちに、猫を焼き殺してしまうような悲劇が起きないともかぎりません。 ここまでで、課題、仕様、設計について簡単に説明しました。課題に対して書かれた仕様が正しいことは、しばしば「妥当である」と表現されます。これに対して仕様に対して書かれた設計が正しいことは「正当である」と表現されることがあります。「妥当である」ことと「正当である」ことは別々の概念ですので、「妥当でないけれども正当である」だとか「妥当だけど正当ではない」という組み合わせもあり得ることになります。もちろん目指すべきは「妥当で正当な」システムであることは議論するまでもありません。 なお妥当性の検証を行うことはバリデーション（Validation）、正当性の検証を行うことはベリフィケーション（Verification）と呼ばれます。こうした検証は一口に「テスト」と呼ばれることも多いのですが（さらに単体テスト、結合テスト、総合テストなどという分類もあるので複雑になります）、意味的に異なる2つの見方があることを意識しているか否かはとても大切なことです。 課題と仕様 システムが「何をすべきか」を定義するのがシステム仕様だと説明しましたが、ここでいう「何をすべきか」という定義は、もちろん開発しようとしているシステムが「何をすべきか」を定義するものです。ところで、なぜシステムが「何をすべきか」を決めることができたのでしょう。当然ですが、解くべき課題があるからこそ、それを解決する手段としてのシステムの役割を考えることができるのです。 解くべき課題とは硬い言い回しですが、実社会の中で計算機を含む「システム」の果たすべき役割はどんどん重要性を増しています。システムそのものだけでなく、システム構築作業そのものがどんどん複雑になっている現在、「解くべき課題」をよりよく把握しておくことの重要性はいくら強調しても強調しきれないことです。 システムが何をすべきか、たとえばWebの通販サイトでショッピングカートを提供するとか、会員登録をしなければ使えない、といった話はすべて「システム仕様」のレベルで定義すべき事柄です。ではこの仕様はどこからくるのでしょう。それ以前の要求の源泉を生み出す場所、すなわち実世界からです。 非常に抽象的な段階から話を始めれば、たとえばWebの通販サイトの構築は、ある種の販売管理業務をWebを使ってお客さんの相手をするようにしたシステムということができるでしょう。そこから特定の実現手段を取り除いて考えると、販売管理業務の一番「外側」では、お客さんへの品物や見積価格の提示、受注あるいは予約の受付、製品の出荷、代金の回収といったできごとが起きていることがわかります。 こうした出来事は、計算機を使おうとも、手作業を行おうとも変わらぬ「処理」を行わなければならない基本的な出来事です。もちろん設計実装方法によって事務員が伝票を手書きするのか、電話を聞きながら計算機の画面からデータを打ち込むのか、はたまた注文カタログをバーコードリーダーでスキャンするのか、それともお客さん自身にWebの画面から注文してもらうのかは異なります。しかしそこで「注文」が行われるならば、実現の手段を問わず、「注文」という事実が識別できるようになっていなければなりません。 現実世界で解かれるべき問題を、この本では「課題」と呼んでいます。課題を掘り下げる作業を通してどのような問題を解きたいのかが形作られます。ここで考えている課題をまとめていく視点として2つのものを考えることができます 1.課題を考えている世界で改善することが望まれている項目 2.課題を解くことにより世界で実現される効果 前者は何らかの「不便」や「不満」を解決するための「改善」の視点です。後者は問題解決を行いたい誰か（大概は発注者のはずです）の目的を達するための「構築」の視点です。改善は構築に較べて地味な視点であり、誰しもが新しい問題解決に向かって熱中しがちになりますが、そもそも既存のシステムが埋められた世界に対する不満と不便の改善も忘れてはならない視点です。 もともと改善すべき点は可能なかぎり挙げておき、その手当てを後続の全ての段階で忘れないようにしなければなりません。改善すべき点は業務そのものの流れだったり、システムの振舞いだったり、現実のプログラムそのものだったりします。 簡単なシステムならいきなりシステム仕様を書き始めることができるかもしれません。しかし解くべき課題を十分に分析し、定義せずに始められたプロジェクトの多くは、混乱しがちになります（もちろんプロジェクトが混乱する原因はほかにもたくさん挙げることができますが、解決すべき課題、作るべきシステムが見えているプロジェクトなら、最後はなんとか収束の道を見つけることができるものです）。 この本ではこの2つの視点で課題を整理していく方法を説明します。 （書籍 22～28ページより抜粋）
■ ＵＲＬ 「課題・仕様・設計」－不幸なシステム開発を救うシンプルな法則－ http://internet.impress.co.jp/books/1866/ こちらより書籍の購入が可能です
（酒匂 寛）
|
