電子申請１件１５００万円も。。日本の電子政府戦略は正しいのか？

ここのニュース
＜電子申請＞１件１５００万円　５官庁でＩＴ予算むだ遣い　
http://headlines.yahoo.co.jp/hl?a=20070329-00000072-mai-pol
によると（以下斜体は上記ニュースより引用）


国民が国への届け出をインターネットで行う電子申請のうち、外務省など五つの官庁のシステムで利用が極めて少なく、申請１件当たり約７０万～約１５００万円のコストがかかっていることが、毎日新聞の調べで分かった。


１件１５００万円（＾＾；）
うーん、無駄遣い（＾＾；）

で、実際電子化したものの中には。。。

「検定済み教科書の訂正の申請や届け出」「核燃料関連のトラブルの届け出」の電子申請も扱っている。

って、そもそも、利用する人が、何人いるんだ（＾＾；）
ってものも、あるらしい。。

---

その問題に対して、

官庁側からは「どの手続きを電子申請にする必要性が高いのか、事前にもっと検討すべきだった」（外務省幹部）との声も出ている。

そうだ。もちろん、その検討も重要。

だけど、

　外務省の「汎用受け付け等システム」は、海外在留邦人の「在留証明」「出生証明」など、電子申請しても結局、本人が現地の大使館を直接訪ねる必要があるものを含んでいる。


っていうように、（行くのと、電子申請するので）結局２度手間になってしまうようなものは、システム自体問題ですよね。。

---

結局こういう問題が起きたのは

　政府のＩＴ戦略を担当する内閣官房ＩＴ担当室は「ニーズの高い申請を重点的に電子化するという選択肢もあったはずだ。ただ、当時はＩＴの基盤づくりに（国の）主眼が置かれていたため、仕方がなかった面もある」としている。


っていうように、Ｅ－Ｊａｐａｎ構想が、電子政府は善というので、なんでも電子化しようとしたことに間違いがあるわけで、たんに、電子化率の数字を追いかけてしまったがゆえに、コストパフォーマンスの検討をせずに、税金の無駄づかいになってしまったり、逆に２度手間になって、利用者が不便してしまったりしている。

　で、さらに問題は、このＥ－Ｊａｐａｎ構想が、いまだに続いていて、電子政府のシステムが、どんどんできているということだ。。

　どこかで、ちゃんと考え直さないと、たんなるコンピューター会社が儲かる公共工事になってしまい、税金がむだに流れてしまう。
　道路なら、将来にためにっていうのはあるけど、コンピューターシステムは陳腐化する（たとえば、昔のＯＳベースに作ってたら、１０年もしたら時代が変わって、そんなＯＳ自体売ってないので動かない、ゴミになってしまう）ので、本当に無駄遣いになってしまう。。。

　。。。ってことを、だれか、ＮＰＯ団体とか、調査しないといけない気がする。。

ＤＴＰの構造を考える－その１：物理的構造。

　いままで、土日シリーズで、土曜日にデータベースからＷｅｂや本、雑誌などを自動生成するＤＢ編集の考え方というのをやってましたけど、今回からその範囲をすこしひろげて、ＤＴＰソフト全般の業務知識について考えてみたいと思います。

---

■ＤＴＰソフト全般の業務知識とは？
　っていうと、その「ＤＴＰソフト全般の業務知識」とは？ということになりますが、業務知識というと、
１．そこに登場するひと、もの、かね
２．その人たちがやりとりする情報
３．そこで行われるプロセス

っていうことになります。
で、まず、そのモノの中心といえる、ＤＴＰで表現される、レイアウト部分について考えてみたいと思います。

---

■レイアウトの構造

　ＤＴＰソフトでは、文字、線画（ベクトル表現された絵）、イメージデータ（ドットで表現されたイメージ）を扱うわけですが、これを配置するために枠という概念をもちいます。そのため、こんな感じになります。

　　　本
　　　｜
　　ページ
　　　｜
　　　枠－－－－－－－－－－
　　　｜　　　　　　　　　　｜
　　　｜－－－－－－－－－－
　　　｜　　　｜　　　　｜
　　文字　　線画　　イメージ

ちょっとわかりにくいのですが、本のなかに、ページがあって、ページのなかに枠があって、枠の中に文字、線画、イメージ・・・にくわえ、枠がある（枠の中に枠がある）ってことになります。
　枠の中に枠があるため、作る気になれば永遠に枠を中に作り続けることはできますが、それは無意味なので、そんなことはしないです。
　ただ、複数の枠をまとめて操作したほうが楽なため、いくつかの枠をまとめて、１つの枠とすることがあります（ワープロソフトでは、グループ化というやつ）このまとめた１つの枠が小組になります。

　実際には、枠の中に、段と行を持ちます。
　あんまり、段を枠にするというのは聞かないのですが（あるのかも）
　１行そのものを枠にすることはあります。（行が移動すると、枠もそれにつれて移動する）。１文字が１つの枠っていうこともあります（割注など）。

　そーやって考えると、こんな図になります。

　　　本
　　　｜
　　ページ
　　　｜
　－－枠－－－－－－－－－－
｜｜　｜　　　　　　　　　　｜
｜｜　｜－－－－－－－－－－
｜｜　｜　　　｜　　　　｜
｜｜　段　　線画　　イメージ
｜｜　｜
｜　－行
｜　　｜
　－－文字

なにが、なんだか、わかんない図になってきてしまいました（＾＾；）
で、これらは、エンティティなので、属性値をもちます。

---

■レイアウトのエンティティと属性値とクラス

　つまり、

　本、ページ、枠、（段、行）、文字、線画、イメージ

は、エンティティであり、ってことは、クラスになります（段と行はクラスにしないことアリ）。エンティティは属性値をもちます。
　枠も、属性値として、Ｘ座標、Ｙ座標、傾き（傾斜、回転できる枠というのがある）などなどありますし、文字は、位置（Ｘ座標、Ｙ座標の場合もあるし、枠の先頭から何文字目とかのときも）文字コード、フォント、文字飾り（下線など）、色。。。などなどあります。ＤＴＰソフトの「書体」でやるようなところですね。
　枠などの属性値は、プロパティに相当しますね。

　なお、クラスの場合、派生クラスとか、汎化とか、そーいうお話があるけど、ＤＴＰにもあって、文字の場合、英字、日本語の文字（漢字カタカナひらがな）のほか、タブなどの機能的な文字、記号などがあります。

　枠には、いろんな枠があります。

　線画なのですが、これは線画といったとき、イラストレーターのデータのことにとらえるか、ＤＴＰソフトで作った、四角形とか円とかの意味に捉えるかで違ってきます。
　一般的には、後者で捕らえます。したがって、図形の分だけあります。

　で、イラストレータのデータは、イメージなどと同様に扱います。
　イメージにはjpeg,gif,などありますね、（イラストレータのデータはaiってことになる）

　で、これらの関係ですが、たとえば、本のクラスの中（メンバー）に、ページをもって、ページの中に。。。ってクラスの１つの要素として持ってしまえばいいです。
　Ｃの場合は、リンクを持ちます（Ｃの場合は、クラスでなく、構造体になります）

---

で、これで話終了。。

って、実はなりません。

このように見えるのですが、これは、物理構造で、実は、論理構造というのがあります。
このシリーズの次回に、その論理構造って何？っていうところから書きます。

関西テレビに総務相が「警告」、電波停止の行政処分に言及

ここのニュース
＜番組ねつ造＞関西テレビに総務相が「警告」
http://headlines.yahoo.co.jp/hl?a=20070330-00000038-mai-soci
によると（以下斜体は上記ニュースより引用）

　関西テレビが制作した「発掘！あるある大事典２」のねつ造問題で、菅義偉総務相は３０日、同社の千草宗一郎社長を総務省に呼び、行政指導で最も重い「警告」を伝えた。「放送法違反を再度生じた場合は、法令に基づき厳正に対処する」とし、放送局に発動されたことがない電波法に基づく電波停止の行政処分に言及した。


ひえー（＠＿＠）

でも、その先よんだら、


放送局への警告は今回で３回目。番組内容に関しては、０６年６月に白インゲンのダイエット効果を番組で紹介して健康被害を出したＴＢＳのケースがある。


って書いてあったけど、TBSは？？

画面定義をHTMLで行い、呼び出しWebAPIを求める設計手順の試案１

　これ、自分に対するメモです。
　多分話が進んできたら、いつか、まとめて書くと思うんですけど、
　そのときまでに忘れないためのメモなので、意味通じないと思うんですけど、
　ごめんなさい。

---

■やろうとしていること

　Webアプリで、HTMLで画面定義を書いてしまっている状態において、
　サーバーアクセスするCGIやサーブレットの一覧を
　できるだけ、自動的にというか、作業が流れるようにする方法。

---

■試案中の手順

（１）画面をHTMLで作成する（ここがスタート）

　　　　↓

（２）アクション（ボタン）と画面表示、リストの値の変化、ロード時など、
　　　値を設定したり、次の画面に行きたいと思うところのイベントを、
　　　とりあえず、

　　　　　　onイベント名=適当な関数

　　　にして、とにかく、適当な関数を作ってしまう

　　　　　↓

（３）作った関数について
　（３－１）値をセットするだけなら、（サーバーアクセスにいかない）
　　　　　　適当な値をセットする

　（３－２）次ウィンドウを出すだけなら
　　　　　　window.openを呼び出し、表示する

　（３－３）サーバーアクセスしてXMLを取得するなら
　　　　　　(その後、値取得、次ウィンドウ呼び出しするなら）
　　　　　後述するダミーモジュールのファイルを読み込み、
　　　　　そのダミーモジュール(sv_access)を
　　　　　　　sv_access(呼び出し元、呼び出したいサーバーアプリ）
　　　　　見たいなかんじで書く

　　　↓

（４）画面をびしばし開くとかして、sv_accessを呼び出している箇所を
　　　全部開いて、呼び出しサーバープログラムを全部まとめる

（４）’別にそんなことしなくても、grepで一覧で見ればいいのか。。。
　　　sv_accessを。。

---

■呼び出すダミーモジュール

sv_access(呼び出し元,よびだしたいサーバーアプリ,メモ）

これがよびだされると、呼び出し元,よびだしたいサーバーアプリ,メモをログみたいにどっかに書き出す。

---

長いメモですみません。

開発の初めから順番に書いていってみる その１８：要求分析（４）ヒアリング

　シリーズ「開発の初めから順番に書いていってみる」の続きです。
　現在、要求分析フェーズに入っています。
　その手順としては、

・ヒアリング前の準備をする
・ヒアリングする
・ヒアリング内容をまとめる
・要求仕様書にまとめる

　とあるわけですが、前回は、「ヒアリング前の準備をする」だったので、
今回は「ヒアリングする」という話です。

---

■ヒアリングの内容(機能要件）

　で、要求仕様が、機能要件と非機能要件と分かれる以上、ヒアリングの内容も、そのように分けられるはずです。

　で、機能要件に関して考えると、業務を説明してもらうわけですが(現場などを観察？しながら）。。。

　さあ、話せ、業務の内容を。。

といわれても、相手も困るわけで。。
ってことで、前回、ヒアリングのポイントを出すまでの事前準備について書きました。

　こういう準備をしていくのがいいかどうかっていうのは、まあ、その人の判断によります。

---

■ヒアリングの内容(非機能要件）

　これ以外の、レスポンス等の要件についても、聞き出すわけなんですけど、
　これも、

　さあ、話せ、システムの条件を。。

　といわれても、ユーザーも困るので、こういう場合にチェックシートを用意して。。
　っていう考えがあるみたいです。

　以下のURLに、その話が載っています。

非機能要件を見極める【前編】
http://itpro.nikkeibp.co.jp/article/COLUMN/20060822/246123/?ST=enterprise

非機能要件を見極める【後編】
http://itpro.nikkeibp.co.jp/article/COLUMN/20060822/246152/?ST=enterprise

---

　ってことで、ヒアリングも終わったことにします。

　で、次は、ヒアリングの内容をまとめて、DOAなら、DFDとER,オブジェクト指向なら最終的にユースケース図などを出してくる話になるのですが、これについては、昔書きましたので、このシリーズの次回は、どこに書いたかって言う話とかのまとめについてです。

WebAPIでXMLで返すようにすると、画面部分が完全分離できる:その１－方法１（１６時修正）

（１４時１０分の修正を変えて、１６時に修正し、表題を変えています）

　POSTあるいはGET型のHTTPプロトコルを使ってサーバー側のアプリを呼び出し、その結果をXMLで返す（サーブレットでももちろんOKだし、StrutsでもXMLで返せる）っていう話を、前に書いて、そこで、


標準があって、カスタマイズをかけるようなシステムの場合、ラップしたりマッシュアップして加工しやすかったり、画面を自由に変えやすいＡＪＡＸとＷｅｂＡＰＩの組み合わせがいいのかもしれない。


って書いた。

で、最近、業務知識として、標準的な交換メッセージなどのエンティティやプロセス（メソッド）の知識はもつべきと書いた。

　この2つの話、結びつくのかというと。。。むすびつくんだけど、その具体例を、これから書いていきたいと思います。ただ、何回かに分けて書くのですが、今回はその１回。
　そこまで行かない、前提となるお話。

---

■POST,GET型で呼び出し、XMLで受け取ると、画面部分が分離できるわけ

　まず、「POST,GET型で呼び出し、XMLで受け取ると、画面部分が分離できる」というカラクリを説明しないといけないと思う。今回はそのお話で終わりそうだ。

　その方法、AJAXでサイトをで呼び出す場合、

function httpRequest(target_url,msg,method)
{
	try
	{
	      	if(window.XMLHttpRequest)
		{
			httpObj = new XMLHttpRequest();
		}
		else if(window.ActiveXObject)
		{
			httpObj = new ActiveXObject("Microsoft.XMLHTTP");
		}
		else
		{
			alert('エラーです');
			return;
		}
	}
	catch(e)
	{
		alert('エラーです');
		return;
	}

	//	タイマーセット
	timer = setInterval("timeout()",60000); //60秒にセット

	//	データを取得する
	httpObj.open(method, target_url, true);
	httpObj.onreadystatechange = DataRead;
	httpObj.send(msg);

	return;
}

(上記＜　＞　￥がある場合、本当は半角）

こうすると、
　　target_urlに表示したいURL,
　　msgに送りたい内容（GETの場合は””）
　　methodに"Get"か"Post"
を設定すると、target_urlに設定したプログラム(CGIやサーブレット等）をよびだし、
httpObj.onreadystatechangeで設定した DataReadという関数に入る。
(上記はプログラムの一部を切り出しています。実際には、他の関数、変数をかかないと呼び出せませんが、それは、省略します。いつか、全貌を書く予定です）。

---

　で、そのとき、サーバーからは結果をXMLで返すと、
　その結果が、DataReadという関数にはいるわけなのですが、
　その結果を、

function DataRead()
{
        if ( httpObj.readyState == 4 )
	{
		clearInterval(timer);	//	タイマーとめる
		if ( httpObj.status == 200)
		{
			xtree = httpObj.responseXML;
			//帰ってきた値で判断していいけど
			window.open("tugi_no_gamen.htm","_top");
		}
       	}
}

(上記＜　＞　￥がある場合、本当は半角）

ってやると、サーバーのCGI等はXMLを返しただけ
　　＝どんな画面が表示されるかわかんない。

でも、

window.open("tugi_no_gamen.htm","_top");

で、"tugi_no_gamen.htm"という画面を表示するってことになります。

---

（１６時修正）
■POST,GET型で呼び出し、XMLで受け取ると、画面が完全分離できる

　つまり、これにより、サーバーのCGIやサーブレットが返す値は同じでも
　違う画面が表示できるってことです。
　CGIやサーブレットはそれを意識しないで

　上記の例だと、WebAPIのパッケージみたいなのを提供して、同じCGIやサーブレットを呼び出しながら（httpRequestのtarget_urlは同じでも）、クライアントに表示する画面は、各社各様、カスタマイズされて全然別（tugi_no_gamen.htmは各社各様）でもかまわないってことです。

　逆に、各社各様、カスタマイズされて全然別の画面から、同じCGIやサーブレットを呼び出してもかまわないことになります。

　また、サーバアクセス中に、クライアントのほうで動画を流すとかも可能になってくるし。。

　さらに、上の例では、tugi_no_gamen.htmと固定値を入れてましたが、ここを変数にして、子供の場合は、子供向けの画面、大人の場合は大人向けの画面が作れるってことです。

---

■さらにIEでファイルから起動した場合は、クライアント側に画面を置くことも可能

　さらにIEでファイルから起動した場合や、Javaからサーバーのアプリを呼び出すような形式の場合、BREWでHTTPアクセスして呼び出すような場合、画面をクライアント側に置いてしまうことが可能です。

　そこまでいくと、上記の例だと、tugi_no_gamen.htmは、クライアントごとに違ってもかまわないってことになるので、
　OSとか、画面サイズとかによって、違う画面を表示できるってことです。
　サーバーは、それを意識しないで。

　たとえば、BREWで呼び出し、その内容に応じてIHTMLViewerでHTML画面に値を設定して表示する場合と、IEでファイルをダブルクリックして表示する場合で、同じサーバーのCGIにアクセスしながら、クライアントにあるtugi_no_gamen.htmがまったく違うので、違う画面を表示することが、できるってことです。
（BREWの場合、HTMLファイルを表示するのではないが、ここでは、そのHTMLファイルを読み込み、値をセットして、IHTMLVIEWERで表示するものとする）

---

■ただし。。

　ただし、これはIEでファイルダブルクリックならできますが、FireFoxやIEでHTTPを経由すると、その画面もとのサーバー以外にアクセスできないみたいなので、そーなってくると、サーバーに画面を置かないとダメ。。みたいだけど、回避策とかあるのかも（＾＾；）

（１６時修正ここまで）

---

　とはいえ、次の画面に変数をわたすには、どーするの？
　サーバーならセッションに入れるという手があるけど、
　クライアント側で変わった場合。。
　クッキーでもつかうの？

　って言う話は、このシリーズの次回に書きます。

開発の初めから順番に書いていってみる その１７：要求分析（３）事前調査。

　シリーズ「開発の初めから順番に書いていってみる」の続きです。
　現在、要求分析フェーズに入っています。
　その手順としては、

・ヒアリング前の準備をする
・ヒアリングする
・ヒアリング内容をまとめる
・要求仕様書にまとめる

　とあるわけですが、今回は、「ヒアリング前の準備をする」という話です。

---

■ヒアリング前の準備をする（事前準備）

　すでに、RFPは受け取っています。
　また、ここまで来る前に、事前に帳票などを受け取っている場合が多いです。
　少なくとも会社の名前は分かってて、業種はわかってて、たいてい、何をシステム化するかも漠然と分かっています。

　っていうことは、これらの資料から、その会社において、今回のシステムに関係する人や会社等の組織（すべてでなくてもいい、この人は出てきそうという人や会社等の組織）、モノやサービスについては、わかります。

　できれば、その業界の標準フォーマット（統一伝票とか）や、規制などもわかるはずです。これも調べておいたほうがいいです（その伝票を使うかどうかは関係ないです。標準的な方法を知るために調べます）

　それらのまとめ方に関しては、
必要な業務知識とは？
http://blog.goo.ne.jp/xmldtp/e/df8025d175eb65e943956ac59f33b1ea
に書きました。

ま、事前調査ってことですね。

---

■質問する内容をまとめる？

　ここで、「質問する内容をまとめたほうがいい」という意見と、「いや、相手にいいたいように言わせるべきだ。そもそも、事前調査は、絶対すべきではない、先入観をもってしまい、正しく聞きだすことが不可能になる！」という意見があります。

　ま、どっちをとるかは、その人次第です。

　今の風潮では。。あんまり事前調査はしない気がする。。

　ただ、ヒアリングできない場合、調査紙を使うしかない場合は、質問する内容をまとめざるを得ないですよね。

---

ということで、ここで書く話は、必要な業務知識とは？に大体書いているので、今回はこのくらいにして、次回、「ヒアリング」の話しに行きましょう。

要求仕様がまとまらない→見切り発車でプログラム→アジャイル→デスマーチへ

　昨日、アジャイルで開発すると品質は高くなるのか？という話を書いた。

　そこで書いた話は、

・仕様がまとまっていない段階でも、アジャイルでは開発に入れるが、
・そうすると、度重なる仕様変更がおこり、
・プログラムが崩壊し、
・デスマーチ化する

という話だった。
　で、今日は、その「仕様がまとまっていない段階で」どうして、開発に入らないといけないか？っていう話です。

---

■要求仕様がまとめられないから

　この理由は、一言で言うと、

　「要求仕様がまとめられないから」

　この結果、要求仕様の段階で、結構月日がたってしまう。
　そーすると、後工程が遅れてしまうので、最悪の「できたところからやろう」という発想になる（＝できないところはいつまでたってもできない。それをやるとき、大幅仕様変更になり、無駄になるかもしれないけど、ともかく、やってしまう）。

　そのため、わかんないところをブラックボックス化して開発してしまう（とりあえず、クラスとメソッドを作って、ダミーを返す）。もう、要求仕様の段階で時間が足りないのだから、テストも、単体は省略となる（というか、アジャイルでやっていて、とくにJUnitでやっている場合、青くなっているのでコーディング完了と判断したわけだから、その時点で単体テスト完といわれても、まあ、間違いじゃない）。

　で、結合に入るが。。
　そもそも、要求仕様がまとまらないのであれば、要求仕様に矛盾があって当たり前で、そうすると、結合でその矛盾は露呈し。。仕様変更となる。。そのうち仕様変更が何回もおこり、崩壊していく。。。

　つまり、要求仕様がまとまらず、開発期間を押してくるので、見切り発車せざるを得なくなるが、それにアジャイルは向いているということです。でも、要求仕様がまとまってないんだから。。。品質は低いですよね。

　なお、開発期間を押さないケースでも、要求仕様をあいまいに定義するという場合もあります。この場合も、アジャイルは向いているということです。でも、要求仕様があいまいだから。。。品質は低いですよね。

---

■要求仕様がまとまらない理由

　では、問題は、要求仕様がまとまらない理由です。
　で、この前書いたとおり、もし、完璧なヒアリングができているのであれば、その後工程というのは、もはや、述語をどうする、名詞句をどうするというレベルで、ER、DFDないしはUMLの図やクラスに展開できます。

　ってことは、完璧なヒアリング（にかぎらず、業務の情報収集）ができないってことです。あともうひとつのケースがあって、無茶なことを要求するって言う場合もあります。そのフレームワークでそれはできないってっていうかんじ。。

まとめると、こんなかんじ

（A)無茶な要求
　　→そもそも、できないってことを営業が気づかない(気づいていてもあおる）
　　　新しい技術で本当はできるかどうかわからない(実はだれも成功してない）
　　　そのSE、営業自体、本当は知識がない（会社や業界には成功事例はある）
　　　可能だが、期間的、予算的に無理！
　　　　：

（B)完璧な情報収集(ヒアリング、帳票分析ふくむ）ができない（業務も要望も）
　　　B-1、SEに、情報が伝わらない、情報収集できない
　　　　　→ヒアリングで言ってる内容をSEが理解できない
　　　　　　関連業務などをSEが知らない

　　　B-2、会社が業務を表現できない
　　　　　→業務は、矛盾なく、滞りなくできているが、それを言葉で的確に
　　　　　　表現できない。要望も、的確に表現できない

　　　B-3、会社自体、本当は業務をちゃんと行ってない
　　　　　→適当なローカルルールや臨機応変という名の恣意的な判断で
　　　　　　どうにかこうにか回っているので、業務自体、決まったやり方がない
　　　　　→新規事業で実は、だれもやったことはない。
　　　　　→改善案なのだが、それでできるかどうかわからない。

　この場合、B-2,B-3の場合、誰がやっても、ユーザー自体が言葉にできないのだから、それをヒアリングしても、要件はまとまらない。
　で、会社の業務スピードが上がり、十分な引継ぎもできず、専門外でもやらなければならない昨今、ユーザー企業は、B-2,B-3のケースに陥っているケースが多いと思う。

---

■もはや業務すべてを言語化できない

　つまり、ユーザーは「もはや業務すべてを言語化できない」状態に陥っている。
　したがって、SEのほうで、業務をみきって、まとめる力がないと、要件はいつまでたってもまとまらない。
　でも、SE自体も業務知識を軽視し、UMLなどの技術論に向かう傾向にある。
　ここで、UMLをどんなにやっても、ユーザーが、「業務すべてを言語化できない」のだから、システムには仕様漏れがでる。
　
結果として
ユーザーは「もはや業務すべてを言語化できない」
　　　　↓
SEも、業務知識は軽視しているので、業務をみきって、まとめる力はない。
　　　　↓
その結果、言語化されない仕様漏れ、
　　　　　言語化しなかったことによる論理矛盾や勘違いが生まれ
　　　　↓
それを見切り発車すると
　　　　↓
どっかで矛盾が発覚し
　　　　↓
仕様変更となり（仕様変更が続発し）
　　　　↓
そのうち、プログラムが崩壊し、単体レベルのバグが多発してきて
　　　　↓
システムが崩壊し
　　　　↓
デスマーチ化する

　っていう構図になっていると思う。

---

■つーことは

　すんげー単純な話、各業界の業務を標準化し、明確化(言語化）し
　自社はどこが違うかだけを明示すればいいようにすればいいんだよね。

　そのためには、いままでの技術中心から、業界知識中心(中心までしなくていいけど、多少重視）に方向転換すればいいんだけど。。

　それをしてないってこと。。

必要な業務知識とは？

　最近のブログの中で、業務知識が、要求仕様の品質に左右し、要求仕様の品質（仕様漏れや勘違いの少なさ）が、開発全体の品質に影響するということ、そして、現在は、この業務知識を重視しない（形式化されてない割には、形式化しようという研究も少ない）ため、要求仕様の品質が低く、仕様漏れや勘違いが多く、それがデスマーチを招いていると書いてきた。

　で、ここで問題になるのは、「じゃあ、業務知識って？どんなのがあればいいの？」ってことになる。これを形式化して、標準的な業務知識というのを定めないと、これから開発しようとしているシステムと比較できないので、あんまり、効果的でない。

　ってことで、必要な業務知識の枠組みを形式化してみよう

---

■まず、登場人物

　はじめに抑えたいのは、その業界の業務において、どのような登場人物が現れるのかということだ。人物といっても、ヒトとは限らない。会社や組織っていうこともある。

　たとえば、訪問介護業界なら、介護される人と、介護するヘルパーさん、その内容を決めるケアマネージャーは、すぐ出てくる（あとで、国保連とか、お金を払う人とかも登場する）。

---

■そして、そこに流れるモノ

　そのつぎに、出てくるのは、人がやり取りする、モノについて。
　これは、販売する商品や製品、サービス、製作する部品はもちろん、そこに行き交う書類や電子媒体も含まれる。たとえば、EDIなどでネット上に流れるデータやXMLなども含まれる。

　訪問介護業界なら、ヘルパーさんが行うサービスはもちろんだが、ケアマネージャーが作成するケアプラン、国保連に送る伝送データなどもはいる。

---

■そして、カネ

　そして、お金。これは、キャッシュ、現金の場合もあるが、最近は集金代行やクレジットカードなどもある。この集金代行やカードの知識は、どんな業界でも使えるので、基本的に覚えておくべきっていうか、エンティティとそこで行われる業務内容、また伝送データや書類（新規のときに送るもの）などは、ソフト会社で（いや、ソフト業界で。。中小企業庁あたりで？？）まとめておいたほうがいい気がする。。

　訪問介護の場合も、集金の問題はある。

---

■これらが、エンティティとなる

　そして、これら、ヒト、モノ、カネはエンティティとなる。

　とくに、業界標準の伝送データがある場合、こういうエンティティを必要とするという制約がでてくるので、そこは、あらかじめ抑えておく必要がある。
（伝送データを帳票分析の手法で分析すれば、エンティティは出てくる）。

---

■エンティティの必要な属性も抑えておく
　そして、業界標準の伝送データがある場合は、エンティティに必要な属性もきまってくる（その属性がないと伝送できない）。それらは、抑えておく。

---

■業界に共通した手順があれば、それも抑えておく

　あと、手順について、標準的なというか、不可欠な手順があればおさえておく。

　訪問介護の場合、

１．ケアマネージャーがケアプランを作成する

２．ヘルパーを割り当てる

３．ヘルパーが介護する

４．介護した内容を集計して

５．国保連(公費分）とお金を払うヒト（自費分）を請求する
　　→お金を払うヒト＝介護されるヒトではない。
　　　認知症で禁治産者は？

６．国保連からおかねもらう

７．自費分のお金をもらう。

という手順はかならずある。このやり方が、訪問介護の事業所によって、各種バリエーションがあったり、この間に、各社ごとに、いろんなことをしたりする。その内容をヒアリングすることになる（上記のプロセスにおいて、入出力は決まっている。それは業界知識としてあらかじめ分析しておくべき。ただし、ここでは、省略する）

　なお、訪問介護は、サービスを提供するので、サービス業の側面もある。
　そこで、サービス業の業務である、「クレーム処理」っていうのも、当然ある。
　これはこれで、標準的手法を分析しておく必要がある。

　また、訪問介護の事業所は、会社であり、ヘルパーは従業員である。
　会社は平均的な会社業務である「会計処理」が存在し、従業員には「労務管理」が存在する（給与、採用などなど）。これも、標準的手法を分析しておく必要がある。

　標準的手法とは、上記のヒト・モノ・カネのエンティティ分析及び標準業務、あと、後述する関連法規をさす。

---

■関連法規なども、抑えておく必要がある

　そして、関連法規。
　たとえば、介護保険は、何年ごとに大きな見直しがあり、小さい見直しは何年ごとにあるかなど、業界関連法規は抑えておく必要がある。

---

■こんなことで、ERと、基本的プロセス、基本用語はまとめておいたほうがいい

　そーすると、エンティティとその関係（属性ふくむ）、基本プロセス（入出力も含む）と、基本用語、共通的な帳票（小売なら統一伝票）、データ（EDIデータや国保連の伝送データ）などは、まとめておいたほうがいい。

　ちょっと書いたけど、こーいうの、中小企業の場合はたいへんだから、診断士の研究会あたりでまとめて、それを中小企業に対してセミナーみたいな形で公開して、そーしたら、診断士の更新研修の点数になるとかするべきだと思うんですけどお。。。

　中小企業庁さまあ。。

アジャイルで開発すると品質は高くなるのか？

　コメントやトラックバックは一切受け付けない仕組みになっているので、せっかくだから、他の人は書かない危ない話題について書いてみたいと思う（もし、受け付けたら炎上だよね　＾＾；）

　最近のソフトウエア工学や開発方法論では、アジャイル開発の話題が花盛りになっている。

　この前提として、

　　・要求仕様は完全なものは出ない
　　・なので、どんどん作っていって、スパイラルで開発していき
　　・仕様をつめていく

　というのが、前提にあると思います。
　で、問題なのですが。。。

　要求仕様が完璧でない場合、何度も修正かけると、どうして品質がよくなると
　いいきれるのか？

---

　
　要求仕様が完璧だったとしたら、アジャイルで開発する必要はないです。
　仕様変更がほとんど入らないことになるので、この場合、ウォーターフォールでもOKで、仕様変更を障害の一環として処理すれば、問題ないです（２０年位前の汎用の開発はこれに近かったと思う）。

　なので、アジャイルで開発するというのは、そうじゃゃないとき＝要求仕様が完璧じゃないから、アジャイルで開発して、どんどん目に見える形で確認し、修正していこうということだと思います。

　でも、ってことは、どんどん修正していけば、プログラムはよくなるって言うことが前提にあります。でも、この前提成り立ちますか？

　要求が完全でないって言うことは、部分的です。
　したがって、修正も部分最適になります。これは全体最適とは限らないので、部分最適のつぎはぎだらけのプログラムになって、ぐちゃぐちゃになり。。。
　そのうち保守できなくなり、崩壊するっていうことはありませんか？

　つまり、昨日書いた
仕様漏れ、勘違い→仕様変更→プログラムが崩れる→結合テストで破綻→デスマーチ
って話で、プログラミングレベルで修正を繰り返すと、プログラムが破綻しなければいいけど、破綻してしまったら、もう、手が付けられなくなります。

　破綻しないといえますか？？っていうか、

　破綻することのほうが多い＝作り直したほうがいい、ってことが多いと思うけど。。

---

　で、作り直すって言うのであれば、何回も作り直すよりかは、ある程度精度を高めて、そしてから、プログラム工程に流したほうがいいってことになります。

　つまり、要求仕様の精度を上げるため、プログラムを作らないでもいいシュミレーション方法（決まりきった処理と入出力から、それができるかどうか検証するみたいなかんじの話）を研究したほうがいいのに、後工程に話をすすませて、それでどうにかしようという形に、今の学会、企業、開発者は進んでいませんか？

　でもね、むかーしむかし、上流工程のミスを下流で発見する場合、下流工程に行けば行くほど、修正はたいへんになるっていう話しがあったと思うのね。だとすれば、プログラム工程で矛盾を発生させるアジャイルより、上流工程でシュミレーションをきっちりやる、さらには、ヒアリングがきっちりできる手法を考えたほうが。。品質上がりませんか？

---

　なーんてかいたら、アジャイルまんせーの人から、
　非難のコメント、トラックバックごうごうだよね。
　
　おまえは分かってないっていって。。

　よかった、コメントトラックバック禁止にしておいて（＾＾）ｖ

開発の初めから順番に書いていってみる その１６：要求分析（２）要求分析手順（１５時追加）

（１５：００に一部追加しました）

　シリーズ「開発の初めから順番に書いていってみる」の続きです。
　前回から、要求分析フェーズに入っていて、前回は、その成果物である、要求仕様書について書きました。
　今回は、要求分析の手順についてです。

---

■要求分析の手順

　要求分析の手順としては、大まかに書くと

・ヒアリング前の準備をする

・ヒアリングする
機能仕様部分
非機能仕様部分

・ヒアリング内容をまとめる
DOA、オブジェクト指向などで、方法論は違う

・要求仕様書にまとめる

ということになります。

---

■公開されている開発標準における要求仕様手順
（ここ、１５：００追加）

　要求仕様書のとき、公開されている富士通の開発標準
1.ComponentAA開発標準
http://segroup.fujitsu.com/sdas/technology/develop-guide/1-caa.html
について、触れたので、今回も、そこから、要求仕様の手順について。

上記サイトからダウンロードできる
ComponentAA開発標準 Method編シリーズ ドキュメント標準編(一般公開用）
の、「1.6作業フロー図」に書かれている要求仕様の手順は、こんなかんじ。

SA:(1) 業務要件定義
	→要件の要望をまとめる

SA:(2) 業務機能分析、データ分析
	→業務を分析する（DFD,ER図の世界）

SA:(3) 分析検証
	→データとユースケースのマッチング

SA:(4) 用語・データタイプ・コードの定義
	→用語集など

これらは、主に、「ヒアリング内容をまとめる」の具体的な手順になります。

　（１５：００追加：いったんここまで－もう一つ追加箇所あり）

---

■一番の勝負は、ヒアリングになる。

　ここで問題は、世間一般的には、

　　　DOAの場合DFD、ER図への落とし方、
　　　オブジェクト指向の場合は、アクティビティ図から、ユースケース図、
　　　　　ER図に相当する部分のクラス図の作り方までの落とし込み

　についてが話題になっています。
　（１５：００追加）
　上述の富士通の開発標準でも、まさに、このヒアリングの落とし込み、まとめ方の手順が書かれています。
　（１５：００追加：ここまで）

　しかし、これらは、本も出ていますし、手法としても、ある程度見えています。。

　問題は、ヒアリングです。ここで、聞き出せなかったり、
　間違ったことをきいてしまうと、
　以降の過程は、ぼろぼろになります（要求仕様以降も、ぼろぼろになります）

　なので、ヒアリングが大事です。

---

■でも、ヒアリングしてもユーザーがしゃべってくれるとは限らない

　でも、「さー、はなしてください」っていってら、すべて話してくれるとは限りませんよね。何から話していいか。。

　っていうことで、聞きもれが出てきます。

　そうすると、たいへんです。あとで、聞きもれ！って分かったら、仕様変更です。
　そうなると、品質が下がって。。。(途中省略）。。。デスマーチになるって言う話は
　昨日書きました。

　だから、ヒアリングの精度を上げないといけません。

---

■なので、ヒアリング前の調査が大事

　なので、ヒアリング前の事前調査が大事になります。
　ここで、うまくヒアリングができるように、事前調査が行けば、
　ヒアリングでの仕様漏れがすくなくなり、

　仕様変更が減り

　そうすると、品質はあがります。

---

■ところが、現在のソフトウエア工学は、ここに力を入れてない

　したがって、効率的な開発や、品質向上のための鍵は、要求仕様のとき、いかにシステムを正しく反映したヒアリングができるかどうかです。

　ここの研究を多くしない限り、品質は上がらないで、デスマーチが続き、情報化投資の成果は上がらず、結果として「ITの投資は一通り終わりました」となり、学生も寄り付かなくなり、衰退します。

　ところが、最近は、プログラミングに関しての研究は盛んなのですが、大量な業務情報をいかに正しく引き出すか(間違いを分かる＆足りない部分を見つける）という研究は、あまりされていません（情報処理学会論文誌などで、見ることはない。情報処理(学会の雑誌。表紙派手なほう）でもみません。

　なお、大量でなければ、論理的に考えればできるのですが、実際には、論理的に追っていけない場合に、問題が出ます(ユーザーの言葉を信じて破綻する）。

　現在の情報処理学会の研究は、（わざと？）大量の業務情報を扱わず、ある程度の情報量を用いてUMLのモデリングとか、形式仕様の話をしたりして、それ以降の作業に関して、とくにプログラミング部分に関して、話を発展させています。

　つまり、ゾウを冷蔵庫に入れる方法が知りたいのに、アイスクリームを華麗に冷蔵庫に入れる方法を議論しています。いや、アイスクリームなら、どうやっても、冷蔵庫に入るって（＾＾；）

---

　ってことで、次回は、要求分析について、ヒアリング前の事前調査を、現状はどうやっているか（いや、問題はあるんだけどね）っていう話を書こうと思います。

　

ファイルのアップロード(CGI,PHP,サーブレット,Struts）。

自分へのメモ

ファイルのアップロードをする方法について書いたもの

CGIは、前に取り上げた
HTMLでファイルをアップロードする書き方と、そのとき、サーバーにどう送られているか？ http://blog.goo.ne.jp/xmldtp/e/ebcabd358239818b03200f2abe0d1618


PHPの場合
第 38章ファイルアップロードの処理
http://php.s3.to/man/features.file-upload.html

サーブレット
ファイルアップロード処理を簡単にする（Commons活用）
http://www.atmarkit.co.jp/fjava/javatips/106jakarta018.html


Struts
●Struts－１８．ファイルアップロード
http://www.javaroad.jp/opensource/js_struts20.htm
もひとつついで
Strutsを使用したファイルアップロードのサンプル
http://struts.wasureppoi.com/util/01_upload.html


（あくまでも、自分へのメモで、CGI以外は、ためしてません）

水に落とした携帯電話を救う方法

ここのブログ
水に落とした携帯電話を救う方法
http://www.msng.info/archives/2006/11/how_to_save_a_wet_cell_phone.php

で、「水に落とした携帯電話を救う方法」の１つ（他にも方法は載っています）として
(以下斜体は上記サイトから引用）

アルコールに浸す


理屈はわかるのですが、ちとこわい。。

っていうか、素直に防水のケータイを買えばいいってこと（＾＾；）

仕様漏れ、勘違い→仕様変更→プログラムが崩れる→結合テストで破綻→デスマーチ

　まえに、トップダウンアプローチとボトムアップアプローチによる違いというのを書いて、さらに、業務知識を持っていればトップダウンアプローチが利用できるので有利！というところで、

　トップダウンアプローチでないと、ユーザーが話さなかったり、間違えたところに気づかないで、仕様漏れや、勘違いになることがあるよ

　というのを書きました。
　今回、この仕様漏れ、勘違いがおこると、どうなるのか？ということを書きます。

　結論から言うと、この結果が、デスマーチになり、現在のコンピューター業界の悲惨な現状になって来るんだと思うけど。。

---

■仕様漏れや、勘違い→結合テスト（IT）で発覚する

　まず、仕様漏れや勘違いは、実は、プログラミングで発覚するとは限らないことです。
　プログラミングできちゃうケースがあるんです。

　もし、仕様を切っている人が、気がつかない仕様ミスがあったとします。
　プログラマも、気がつかない可能性は大きいです。同じ人間ですし、プログラマは、全体を知りませんから。そーすると、プログラミングの単体テストはうまくいきます。

　でも、結合テストがうまくいきません。

　たとえば、冷蔵庫に、ゾウを入れるとします。

　このとき、

・冷蔵庫クラスを作り、出す、入れるというメソッドをつくる
・画面から入力されたものを、どんどん冷蔵庫にいれ、
　画面に表示、取り出せるようにする

　という仕様になるかもしれません。

　これなら、作れます。たぶん、テストする人は、アイスクリームとか、野菜とかのデータをいれて、単体テスト終わりにするでしょう。

　で、IT2。ゾウって、画面から入れたら。。入らない（＞＿＜！）

　ここまでおばかな例は、まずないですけど、仕様漏れや、仕様ミスとなるような条件は、プログラマのほうでも、想定していないで、そのままテストを通してしまい、いきなり、結合で問題発覚、そんなの、想定外だよ！っていうことが、良く起こります。
（ただし、プログラム最中に、つじつまが合わなくなることも、良く起こりますし、仕様作成中に気づくこともありますけど）

---

■仕様変更を起こすと、プログラムが崩れる。

　プログラム後に仕様漏れが発覚すると、すなわち結合テストやプログラム中、単体テストで仕様漏れ、勘違いが発覚すると、仕様変更しないといけなくなります。

　ところが、システムっていうのは、一度作ってしまうと、それを修正したとたんに、崩れていってしまいます(崩さないように修正しようと思っても、崩れます）。
　ある程度なら、システムは大丈夫なんですけど、ある一定を超えると（たいてい、プログラマのキャパによるのだが）システム＝ここではプログラムは、発散して、壊れてしまいます。こうなると、作り直しが一番手っ取り早いのですが、たいてい、それは許されません（人が変わると許される場合がある。そのためSEやプログラマを変えることもある）。はてしなく、壊れていきます。

---

■プログラムが崩れると、単体テストで品質低下が落ちたように見える

　で、プログラムが、こんなかんじで崩れると、あっちをなおすと、こっちでバグとなりますので、まるで、単体テストレベルの品質の悪さにみえてきます。
→いったん、単体テストは通っています。だからITにいってるんですが、
　仕様変更で、システムが崩れ、デグレードして、前のテストが通らなくなります。

　そこで、エラーイ人は、単体のプログラムを作っている人に文句を言います。
　単体テストができてないとか、プログラムの品質が低いとか。。。

　しかし、本質的な問題は

・仕様漏れ、勘違いがある

・それらを修正するには、実は設計からやり直したり
　フレームワークから変えるべきって言うことも多い

・たいていプログラムは作り直したほうが速いけど、
　おかしな仕様でつくったプログラムをそのまま永遠直させられる

　っていう、設計の問題です。ここには、問題が言及されないので、悪い事態（仕様変更がつづき、プログラムがどんどん崩壊し、発散していく）はどんどん続くっていうか、加速していきます（問題点は、足し算でなく、組み合わせ的に悪くなっていくので）。

　かくして、デスマーチとなります。設計、なおさないんで。。永遠に終わりません
　(実際には、人海戦術で、とめます）

---

　つまり、この事態をよくするには、ある程度、仕様漏れや勘違いをなくす必要があります。そのひとつの手法として、

・業界の標準的なシステムモデルを確立し、
・それをどのように変えるのかといったフィットギャップ分析の手法を確立して
・トップダウンアプローチを取り入れる

っていうことが、考えられる（これだけではないけど）んだけど。。

非常に望み薄なのだ。。

ま、なぜ望み薄なのかは、またこんどの機会に書くことにしよう。

開発の初めから順番に書いていってみる その１５：要求分析（１）要求仕様書

　シリーズ「開発の初めから順番に書いていってみる」の続きです。
　前回までで、立ち上げの成果物にあたる「プロジェクト計画書」について書き、その中で、スケジュールの元となるアクティビティは、開発標準に基づくことを書きました。

　で、開発標準は、各社各様ありますが、初めに、要求分析が来るっていうことは書きました。つまり、次にやることは、要求分析です。

　ということで、今回は要求分析についてです。

---

■要求分析とは

　これからシステム開発を行うにあたり、何をつくるのかを定義することです。
　何の部分が、要求に当たります。

　この要求には２種類あります。
　１種類は、システムっていうのは、情報処理、すなわち、何かのデータを入力し、処理を行い、出力を出すことです。
　この入出力(データ）と、処理＝業務について、なにを行って欲しいかを出す部分があります。
　つまり、本システムで行う業務について定義する部分で、これを、機能要件といいます。

　もうひとつは、見た目はこうして欲しいとか、何秒以内に帰ってきて欲しいという、業務そのものではなく、業務を遂行するに当たっての要求があります。これが、非機能要件にあたります。

　つまり、要件には、機能要件と、非機能要件があります。
　これらを分析していくのが、要求分析になります。

---

■要求分析の成果物－要求仕様書

　要求分析を行ったら、それを成果物の形にまとめる（ドキュメント化）しなくてはいけません。その成果物が、要求仕様書ってことになります。

　要求仕様書には、したがって、機能要件と、非機能要件を書くことは当然なのですが、それ以外にも、機能要件や非機能要件を読む上で、知っていなければいけない用語の定義や、どーして、そんなことが出てくるのかといった、目的などについても、書かないと意味通じません。これらをまとめて、「要求プロセス完全習得法」という本の中では、「システム制約」という言葉で書いています。

---

■要求仕様書の書き方－その１：IEEE 830

　要求仕様書の書き方には、IEEEで決めたやつ（IEEE 830）があります。
　それでは、以下のように定義しているようです（言うまでもなく、実際の仕様は英語です）。

１．はじめに 　１－１．目的 　１－２．範囲 　１－３．用語定義 　１－４．参考文献 　１－５．概要 ２．要求仕様の一般的な説明 　２－１．製品の背景 　２－２．製品機能 　２－３．ユーザー特性 　２－４．制約 　２－５．仮定および依存性 ３．要求仕様の具体的な説明 　３－１．外部インターフェース 　３－２．機能 　３－３．性能要求 　３－４．論理データベース要求 　３－５．設計の制約 　３－６．ソフトウエアの属性 　３－７．要求仕様の段落構成 ４．付録 ５．索引

（「ビジネスコミュニケーション」の要求工学 ＞ 第3回 要求仕様より引用）

　で、これに基づいて書いたサンプルとしては、
SEのための仕様の基本　山村吉信著　翔泳社　2005 ISBN4-7981-0803-0
の６２ページから６７ページにあります(その前の部分は説明になっています）。

---

■要求仕様書の書き方－その２

　っていうと、さっきの機能要件、非機能要件、システム制約が良くわかんなくなってしまいます。実際これらの定義は別々に行うので、章立てとしても、別々のほうが書きやすいです。
　という場合、「要求プロセス完全習得法」のボレーレテンプレートを使うっていうことになります。
そこのシステム制約、機能要件、非機能要件のみを抜き出すと、こんなかんじ。

１．システム制約
	１－１．システムの目的
	（１－２．依頼主、顧客、その他の決定権者）
	１－３．システムのユーザー
	１－４．要求制約
	１－５．命名法と定義
	１－６．関連事実
	１－７．仮定
２．機能要件
	２－１．システムの範囲
	２－２．機能およびデータ要件
３．非機能要件
	３－１．ルック・アンド・フィール要件
	３－２．使用性要件
	３－３．パフォーマンス要件
	３－４．運用・操作要件
	３－５．保守性および可搬性要件
	３－６．セキュリティ要件
	３－７．文化的および政治的要件
	３－８．法的要件

（「要求プロセス完全習得法」１５４，１５５から引用、数字は通し番号をウィリアムのいたずらが、章ごとに振りなおしています）。

　ただし、１－２は、要求仕様書には、書かないほうがいいと思います。
　ちなみに、このあとに、ボレーレテンプレートでは、「４．プロジェクト課題」という、以下の項目が続きます。

４．プロジェクト課題
	４－１．未解決課題
	４－２．既製品による解決策
	４－３．新たな問題
	４－４．必要作業
	４－５．本番稼動（カットオーバー）
	４－６．リスク
	４－７．コスト
	４－８．ユーザー向け資料の作成
	４－９．要件予備軍

（「要求プロセス完全習得法」１５４，１５５から引用、数字は通し番号をウィリアムのいたずらが、章ごとに振りなおしています）。
でも、これを要求仕様書に書く必要はないでしょう。
かきかたについては、「要件プロセス完全習得法」の３８７ページからに載っています。

---

■ 要求仕様書の書き方－その３

　いままで、富士通の公開されている開発標準（ComponentAA開発標準）を書いてきたので、ここでも書いてみましょう。要求分析はSA工程にあたります。SA工程でのドキュメントは、以下のとおりです。

	SA01 業務要件定義
	SA02 業務機能概要定義
	SA03 業務運用要件
	SA04 システム間インタフェース概要
	SA05 概念ＥＲ図
	SA06 ユースケース・エンティティマトリクス
	SA07 業務用語定義

富士通関係の人なら意味通じるけど、それ以外の人は、なんじゃそりゃ（＾＾；）
ですよね。
この実物を知りたい人、書き方を知りたい人は、
1.ComponentAA開発標準
http://segroup.fujitsu.com/sdas/technology/develop-guide/1-caa.html
の、表の上にある
ComponentAA開発標準 ドキュメント標準編1.0a版ダウンロード
をクリックして、アンケートに答えるとダウンロードできます。そのドキュメントに書いてあります。

---

　ということで、今回は要求仕様の内容と、その成果物である、要件仕様書について、書いてみました。次回は、要求仕様書を作成するための手順について書きたいと思います。