開発の初めから順番に書いていってみる その１：RFP(1)

　開発の初めから順番に書いていくシリーズをやるといった話を以前書きましたので、今日はその話。

　開発の流れに関しては、以前書いたとおり

・RFPを受け取る
・提案書を作る
・要件仕様
　　・ヒアリングをする前にしておいたことがいいこと
　　・ヒアリング
　　・要件仕様への展開

・外部仕様書など
　　・画面定義
　　・テーブル定義（ファイル定義）
　　・フレームワークの決定

・詳細設計

・プログラミング

・テスト
　　・テスト仕様書の作成
　　・テストデータ作成・テスト環境作成
　　・テスト実施

・運用

なので、まずは、「RFPを受け取る」から。

---

■開発の始まり

　システム開発は、まあ、いろんなことで始まるわけです。。

　　戦略的に考えて誰かが掛け声をかけて始まるとか、
　　コンピューターの営業にそそのかされたとか
　　なんか、展示会を見て、とちくるったとか
　　自分はしたくないけど、取引先が電子化したから。。

　などなど。

　で、じぶんのところで作れればいいけど、
　たいていの場合はじぶんのところで作れない。

　なので、どういうシステムを作りたいかというのを書いて、ソフトを作ってくれるところ（メーカーさん、ソフトハウスなど）にわたして、提案してもらう。
　この提案してもらうために、「どういうシステムを作りたいか」というのを書いたのがRFPなわけです。

　でも、こんなまじめな開発じゃなくって、ソフトハウスが持ちかけてきたような案件だと、RFPっていうのが、ないわけです。
　つまり、RFPは、必ずしもあるわけじゃないです。
　ちなみにRFPは、request for proposalの略です。

---

■RFPの内容
　RFPには、決まった内容はありません。
　っていわれても、困ると思うので、どういう内容が書いてあるのが普通かというと、
　ここにある
RFP （request for proposal）
http://www.atmarkit.co.jp/aig/04biz/rfp.html
のによると（以下斜体は上記サイトより引用）


　システムの「概要と目的」「必要な機能」「求められるシステム条件」「サービスレベル」「予算」「納期」「契約条件」「評価プロセスと評価基準」「調達方針」「環境」など具体的な要求を盛り込む必要がある。さらに各要求に優先度を付け、システム導入にあたってゆずれない条件を明記することもポイントだ。またベンダに対して、「提案書の形式」「提出期限」「提出先」「提出方法」などを指定する。


で、どんなものかって言うサンプルは、
ＲＦＰ・ＳＬＡドキュメント見本提供について
http://www.itc.or.jp/foritc/useful/knowhow/rfpsla/rfpsla_main.html
つーものがある。

で、次回は、もうちょっと、RFPの中身について、突っ込んだ話を書きたいと思います。

DomでChildの操作がめんどくさいとき、配列に落としてしまったほうが。。。

やりやすいかもお。。
XMLで、あるタグの下にある子供に関して、いっせいに何かしたいという場合、

　もちろん、firstChildで先頭の子供をとってきて、nextSiblingで、つぎつぎと、子供を処理していくって行くようにして、なんら問題はない。

　問題はないんだけど、１個前に戻りたいとか、１個前と１個先を使ってなんかしたいとか、いろいろなケースがあると、めんどっちい。

　配列に入れちゃって、forループでまわしたほうが、やさしいってこともある。

　その場合のメモメモ。

---

■概要

var 子供のリスト = 元のノード.childNodes;

で、子供のノードリストを、「子供のリスト」にいれる。

そしたら、
for (var i = 0; i ＜ 子供のリスト.length; i++)
{
　　var 子供１個分 = 子供のリスト.item(i);
　　やりたい処理;
}
で、ループをまわして処理できる

---

■サンプル

　いま、select1とselect2という、selectタグで書かれたリストがあり、
select1のオプションをselect2に追加したい場合。

	sl	= document.getElementById('select2');
	motosl 	= document.getElementById('select1');
	var chlist = motosl.childNodes;
	for (var i = 0; i ＜ chlist.length; i++)
	{
		var ch = chlist.item(i);
		if (ch.nodeName	!=	"OPTION")
			continue;

		newop = document.createElement("option");
		newop.id 	=	ch.id;
		newop.value	= 	ch.value;
		newop.appendChild(document.createTextNode
				(ch.firstChild.nodeValue));
		sl.appendChild(newop);
	}

（上記＜は、本当は半角です）

手の付けやすい仕事からやると、結局、問題が最後まで残り、どうにもならなくなる

　で、前に書いた主線について、説明するって書いたけど、その話。

---

　システム開発を進めるにあたり、まず、

　　１．フレームワークを決める
　　２．要素技術（特に困難な部分）を解明しておく
　　３．クリティカルパスになる作業を重要な順に、（とはいえ、順番があるので、
　　　　その順番で）ならべて、こなしていく

というのが、安全な方法になる。

　で、この１、２、３がメインストーリーとなり、これ以外の部分は、間に入れていけばいいっていうことになる（遅れが出た場合でも、１，２，３以外は、たいてい、増員することで対応は可能。逆に１～３の遅れの場合、増員すると、なおさら遅くなる。こちらは、残業でないと対応できない）。

　この１，２，３を主線と表現しました（一般的な用語ではないと思います。なので、言葉自体はどーでもいいです）。
　１，２，３の遅れは、即遅れにつながります（だって、クリティカルパスをつなげているわけだから　＾＾；）。逆にいうと、それ以外の遅れは挽回が可能な場合もけっこうあります。なので、主線がおくれないこと、仕様変更がないこと、バグが収束することが重要になります。そこで、まず、主線にエース級の人を投入してしまい、あとののこりをテキトーに割り振るという感じにするほうが安全です。

　ということは、フレームワークをいじってしまって、それが崩れてしまうと、主線がくるうことになるので結構やばいということです。逆に、主線にのってこない画面変更なんていうのは、変更されても問題ないことが多いです。

---

　ところが、これを、手の付けやすい仕事からやっていく人たちが居ます。
　とりあえず、分かったところからやっていこうと。。
　そうすると、初めのうちは、どんどん仕事が進んでいるように見えるのですが、結局、重要なところが残ってしまいます。
　これだけでも、もんだいなことは、高校講座　数学基礎にあるとおり（ここの「独立した仕事の手順」）なのですが、実際には、後回ししたものが、「うん、できない！」とか言うことになって、いままでやったものの仕様変更が必要になったりして（とくに、このとき、フレームワークを修正されると、最悪になる）泥沼に陥る可能性大です。

---

　うーん、でも、実際には「手の付けやすい仕事からやっていく人」がおおいのよねー。
　学校のテストのクセで（テストは、「手の付けやすい問題からとく」のが鉄則）

　こりゃー、高校講座　数学基礎の秋山大先生（駿台でありえないほどの超人気講師だったあの、秋山先生）にがんばっていただかないと。。。って、最近はハッチー（鉢嶺杏奈さんのこと）と楽しんでるだけだしなあ。。（そーじゃないって　＾＾；）

　うーん、でも、日本の底上げよりも、そっちのほうが、ずっと楽しいだろうけど（＾＾；）

P.S　でも、ハッチーは、歌が下手だと思う（＾＾；）