|
|
|||||||||||
|
|||||||||||
|
 |
||||||||||
|
|||||||||||
|
|||||||||||
|
|||||||||||
|
| |||||||||||
|
|||||||||||
|
|
|||||||||||
|
| |||||||||||
「こんなシステムが欲しかったんじゃないよ！」－ システム開発にあたって、いきなりユースケースを書こうとして悩む前に、まずは必要となる3つの視点を整理してみよう。弊社より12月2日に発売される書籍『「課題・仕様・設計」－不幸なシステム開発を救うシンプルな法則－』より一部を抜粋して、全6回にわたりお届けします。
（編集部）
1958年生まれ。東京大学農学部獣医学科卒。同大学院修士課程中退。大手SIベンダーにて、開発支援ツールの開発、事務アプリケーション開発、ワークステーションのシステムプログラミングなどを行い、オブジェクト指向言語ならびに開発方法論に出会う。 1996年に独立し、以来コンサルタントとして、リアルタイムシステム、大規模分散オブジェクト指向システム、クライアントサーバーシステムの改善、要求定義、分析、設計、開発、管理、環境構築等に携わる。最近のテーマは形式手法を取り込んだ高信頼性・高生産性開発手法の研究。 現在、有限会社デザイナーズ・デン代表取締役。 はじめに 「役に立つシステムを手に入れるために」 本書のテーマはソフトウェアによるシステム開発です。書名の「課題・仕様・設計」は、問題解決を行う際にはっきりさせなければならない3つの視点を表しています。 課題 何を解決したいと思っているのか 仕様 問題解決のために、どのようなシステムを用意すべきなのか 設計 求められるシステムを最適な形で構築するにはどうすればよいのか 「課題」は、解かなければならない問題を抱えている人（問題解決者）の視点です。たとえば、新しい商品を開発してそれを世の中に売り込みたい、といった経済的活動や、人々のコミュニティーを形成して情報を交換したい、といった社会活動など、およそ人間が登場して何か行動をおこす場に課題は存在し、その解決を効果的に支援するために何らかのシステムが必要とされます。 「仕様」は、こうして明らかにされたさまざまな課題を、どのようなシステムを用いて解決すればよいかを、問題解決者とシステム開発者が共同して決めていく視点です。問題解決者はシステムの中身そのものにあまり関心があるわけではありません。あくまでもそのシステムが自分の問題解決にどのように役立つのかが第一の関心事です。 「設計」は、システム開発者の視点です。「仕様」で問題解決者とシステム開発者が合意したシステムを、問題解決者のために最も適した方法で提供することが、システム開発者の使命となります。課題は仕様の、仕様は設計のそれぞれ羅針盤の役割を果たします。羅針盤を失った船が難破してしまうように、課題の暖昧な仕様、仕様の暖味な設計はともすればシステム開発の船を嵐の海に放り込むことになりかねません。 本書は、これら「課題」「仕様」「設計」の位置付けと内容、それぞれの関係を説明していきます。 本書が想定する第一の読者はプログラミングには慣れてきて、いよいよこれから設計や、より上位の分析に取り組もうとしている技術者や開発側の管理者です。問題解決者と一緒にシステム開発という作業を行っていくうえで、自分たちがいま取り組んでいるものが、「課題」仕様」「設計」のいずれの視点に属するものなのかを、問題解決者をも巻き込みながら常に振り返るようにしていくことができれば、よりよいシステム、役に立つシステムの構築の役に立つことでしょう。 また、本書は問題解決者側の読者も期待しています。問題解決者側がともすればシステム開発者と一緒になって、設計の領域に踏み込んでしまうということが現実にはしばしば見受けられます。しかし、問題解決者の第一の責任は、システム開発者に対して自分たちが解決したい「課題」をはっきりさせることであり、システム開発者の提示した「仕様」に基づくシステムが、自分たちの問題解決に役に立つのかどうかを厳しく吟味することなのです。 本書が問題解決者とシステム開発者のあいだの架け橋となり、少しでもよいシステムを構築するためのヒントになれば幸いです。 2003年9月 残暑厳しい相模原にて著者 （書籍 3～4ページより抜粋）
この本が目指すもの ソフトウェアを作るのは難しい仕事です。まあ「こんにちは世界」と出力するプログラムを作ったり、簡単な計算を行わせたりするだけならそれほど難しそうではないかもしれません。 思いついたものをすぐにソフトウェアにして、実行しておしまい。こうしたやり方で済んでしまうソフトウェア開発もたくさんあります。作りながら考えるというスタイルと言ってもよいでしょう。 でも実際には、なんらかの形で長期にわたって役に立つソフトウェアを作ろうと思うと、成り行き任せに作ることは多くの問題を引き起こします。あれをして、次にこれをしてという形で成長したプログラムは継ぎはぎだらけになり、やがて手を加えることもできなくなってしまいます。単に改造できないだけならまだしも、そもそも対象のソフトウェアが正しく仕事をしているのかさえ怪しくなってくるのが普通です。この本では、成り行き任せのソフトウェア開発が引き起こす問題を避けるためには、何をすればよいのかについて考えていきます。 また仕事としてのソフトウェア開発は、通常誰かの依頼に基づいてプログラムを行います。でも多くの場合、依頼する側の人は、解くべき問題をそれほどはっきりと把握しているとはかぎりません。「こういう条件の下に、こうした問題を解いて欲しい」とはっきり開発側に伝える代わりに「こうしたプログラムを作って欲しい」という表現で依頼をしてくることが多いのです。 たとえ自分では成り行き任せの開発をしていないつもりでも、解くべき問題の性質を十分に把握しないまま、言われるままにプログラムを作るだけでは、結果として同じことになります。思いついたことをどんどんプログラミングしていって、ちゃんと動作し、それでいて足りない部分や矛盾はシステム側で勝手に検出してくれる、という具合になっていればどんなに楽でしょう。 あと 200 年ぐらいすればそのようなことも可能かもしれないのですが、私たちの世界は残念ながらまだそこまではたどり着いていないようです。 ということで問題解決はしばらく人間の仕事として残りそうです。 ある程度複雑な問題を解決するには、まずその問題をはっきりと捉えなければなりません。これが課題の探求です。 次にその課題を効率よく（あるいは安く）解決するためのシステム（問題解決手法）を考えます。ここで一足飛びに問題解決のための仕掛けをひねり出してもよいのですが、実装には自由度を残しておきたいものです。特に現代のような構築技術の革新が激しい時代にあっては。 そこで、通常はまず問題解決のためのシステムの仕様を考えることにします。この問題解決システムの仕様に則って、実際の設計実装を行えば、ある程度の構築技術革新の嵐に耐えやすくなるでしょう（程度問題ですが）。 こうして課題、仕様、設計を経て提供された解が、新しい課題解決の出発点となります。このサイクルには終わりがありません。個々のプログラムが死滅しても、それを導いた問題解決の仕様はより長生きをする可能性がありますし、そもそもの課題はさらに長い年月を生き延びるのが普通です。 （書籍 12～14ページより抜粋）
■ ＵＲＬ 「課題・仕様・設計」－不幸なシステム開発を救うシンプルな法則－ http://internet.impress.co.jp/books/1866/ こちらより書籍の購入が可能です
（酒匂 寛）
|
