2006年10月18日

諏訪圏工業メッセ出展します!

みなさんご無沙汰しております。

突然ですが、弊社「諏訪圏工業メッセ 2006」にブース出展します!
http://www.suwamesse.jp/

で、出展社による製品・技術プレゼンテーションで発表することになり、
受託依頼会社のご厚意により暗号技術について発表します。
10月19日(木) 11:30~11:50 インターブリッジ㈱ 「最先端暗号化技術の紹介」

準備でへとへとです。
来てね!

投稿者 itleader1 : 11:59 | コメント (0) | トラックバック

2006年05月31日

これから京都に行って来ます

京都出張です

京都も天気が良さそうでGoodなのですが、暑くなりそうです。そろそろ出かけます。

というわけで、今日はこれにて

サッカー 惜しかった。やっぱり高さ対策が課題でしょうか?

投稿者 itleader1 : 07:29 | コメント (4) | トラックバック

2006年05月24日

菜の花とふるさと

今年の菜の花は遅れ気味

SNanohana0287.jpg桜の開花は例年より早かったようですが、豪雪に見舞われた北信の菜の花は遅れ気味です。例年だとGWの飯山市の菜の花祭りにあわせて満開となるのですが、今年は間に合いませんでした。

菜の花と言えば小学校唱歌「おぼろ月夜」が思い出されます。最近は中島美嘉も歌っているようですが・・・・

  菜の花畑に入日(いりひ)薄れ
  見わたす山の端(は) 霞みふかし
  春風そよ吹く 空を見れば
  夕月かかりて 匂い淡し

  里わの火影(ほかげ)も 森の色も
  田中の小径(こみち)をたどる人も
  蛙(かわず)の鳴く音も 鐘の音も
  さながら霞める朧月夜


作詞の高野辰之は飯山市の隣の豊田村出身、小学校の教師時代を飯山で過ごしました。その後、東京音楽学校の教授に就任し、「おぼろ月夜」をはじめ、「ふるさと」 「紅葉」 「春がきた」 「春の小川」 などを作詞しました。どの歌の背景にも、雪深い北信濃の自然があります。


ところで、ふるさとの三番はこんな歌詞です。

  志を果たして、いつの日にか帰らん  山は青き故郷、水は清き故郷
昔は立身出世を奨励する歌だと思って聞き流していたのですが、北信濃の風景を目の当たりにしてこの歌詞を読むと迫ってくるものがあります。文学博士の称号を受け、東大で講演するなどの後、高野は野沢温泉の別荘で晩年をすごしたのですが、志は果たせたのでしょうか?


朧月夜といえば、例の
照りもせず、曇りも果てぬ春の夜の、朧月夜に似るものぞなき
という歌も思い出されます。貴重な春の宵に、源氏と朧月夜の君のアバンチュールに思いをはせるのも一興かもしれませんね。


画像はかろうじて咲いている菜の花を探して撮りました。背景は千曲川の流れです。

投稿者 itleader1 : 12:13 | コメント (7) | トラックバック

2006年05月17日

ウェブページに内科的対策を実施する

HTMLの内部要因とSEO

SBasho2.jpg 水曜日担当 アウトドア系中小企業診断士 佐藤です。検索エンジンで上位表示を獲得するためには、適切なキーワードの選定、外部リンク、DMOZやYahoo!ビジネスエクスプレスへの登録などなど、さまざまな対策を施す必要があります。それらをサイトの外的要因=外科的な対策だとすれば、文法に則ったHTMLを書いたり、画像のALT属性をキチンと指定したり、テキストでのリンクを行うなど内科的ともいえる対策も重要となります。どちらかというと外科対策がサイト公開後の対策だとすれば、内科対策はサイト作成時の対策となります。今回はずくだすメンバーのサイトのHTMLを対象にHTMLの文法的、お作法的な問題=内科的見地からの対策を行いました。

写真は北海道や尾瀬ではなく、地元信州の水芭蕉です。いつか紹介した栂池自然園はじめ、信州にも水芭蕉の群落があります。

はじめにHTMLの文法チェックから

正しい(=W3Cの勧告に準拠した)HTMLで書かれたページが検索エンジン対策として有効かどうか?についてはさまざまな議論がありますが、いろいろな環境でキチンと表示されるページを作るという意味からもW3Cに準拠したHTMLを書くことは重要なことです。それがSEO的にも効果があれば、一石二鳥というわけです。

まずはHTMLを文法的にチェックしてみます。こういうとき便利なのが文法チェックサービスです。今回はAnother-Lintさんのサイトで、元になるページのURLかHTMLソースファイルを指定してチェックしました。

結果は・・・・-36点でした。マイナスだからとビックリする必要はありません。よくあることです。減点の要因は、1.テーブルの入れ子に誤りがあった 2.テーブルのsummary属性が指定されていなかった 3.テーブルにbackgroundで背景画像が指定されていた 4.画像にalt属性が指定されていなかった 等々でした。summary属性など指定しているページの方が少ないくらいですから、点が低かったからといって悲観する必要はありません。厄介なのは1番のテーブルの入れ子問題です。

テーブルの入れ子構造を確認する

レイアウトのために使っているテーブルの場合、枠線を表示しないことが多いため、テーブルの入れ子に誤りがあっても気がつきません。HTMLに手を入れていくうちに、tr や /tr、td、/tdが混乱するのはよくあることです。

枠線を表示してやればテーブルの入れ子関係が分かりやすくなります。ただし、ブラウザは入れ子に間違いがあっても強引に表示してしまうので、ブラウザ画面だけではなく、HTMLソースと比較しながらチェックすることになります。たいていは、tdがダブっていたり、tdの前にtrが書かれていたり という単純なミスです。今回も入れ子を修正しただけでプラスの36点まで回復しました。

テーブルのsummaryを書いてソースのドキュメント性を高める

summary属性も減点の対象となります。別に実害はないから、書かずに済ますこともできますが、各テーブルの構造をsummaryとして書くことでHTMLソースの見通しを良くすることにしました。table summary="全体を囲むテーブル" とか table summary="左商品群説明テーブル1"とか、table summary="右メニュー用テーブル"と書いておくだけで、HTMLを変更するときに参考になると思ったからです。さらに table summary="左店舗用黒板紹介テーブル"などと、商品名を入れておくとSEO的にも有利になるかもしれません。

summary属性を入れたら45点になりました。

画像にalt属性を入れるとSEOで有利になる

alt属性は画像の上にカーソルを持っていったりときに表示されたり、画像が表示できないときに画像に変わって表示される説明文です。目の不自由な方にとっては、画像に代わって読み上げられる重要な情報となります。「画像1」や「タイトル画像」というような分ではなく、画像の内容が分かるような説明を書く必要があります。画像を説明するということは、画像が表現している商品や店舗に関する情報が書ける!ということです。検索エンジンはalt属性を読んでいるという説もあり、きちんとしたalt属性を書くということはSEO的にも有利となります。img src=....... alt="ディスプレイ用イーゼルで演出された素敵な店舗の画像" などと書けば、イーゼル・店舗・素敵・演出などというキーワードを散りばめることができますし。

リンクはキーワードを含んだテキストで

リンクも大事です。画像でリンクするのはSEOとしては勿体ない話ですが、テキストならなんでもOKとはいきません。 「詳細はこちら」 でリンクするのではなく、リンク際の内容が分かるようなテキストを書きます。「店舗を素敵に演出するイーゼルの詳しい情報はこちら」などと書けば、飛び先に何があるか明示できるだけでなく、リンクを重視している検索エンジンに対し 店舗。演出・イーゼルなどのキーワードを読ませることができます。画像とリンクでキーワードの二重奏です。

最後にスタイルシートを整理して満点となりました

HTML内からデザインに関する要素を追い出してスタイルシートとして定義することはW3Cの勧告に準拠している対応ですが、SEO的にも検索エンジンが重要視しているHTML上部にキーワードを含んだテキストを配置できるというメリットがあります。

今回は、background や width、height などの定義をスタイルシートに移行しました。これでデザインとコンテンツが分離されたすっきりしたページになりました。文法的にも100点満点となりました。

このようにスタイルシートは便利なのですが、その場の思いつきでスタイルを定義していくと収集がつかなくなります。id で定義するのか、class で定義するのか? 名前をどうつけるのか? 定義する順番は? ・・・・。いったんページが出来上がったら、HTMLだけでなくスタイルシートも見直して、整理しておくことが重要です。名前の不統一や使っていない定義があるかもしれません。それらを整理しておくと、次に変更するときに頭を悩ませずに済みます。明日の自分は他人になります。いつまでも記憶が残っていると思ったら大間違いです。

 

スタイルシートの例

ご参考までに、今回作成したスタイルシートを抜粋して表示しておきます。

/***********************************************/
/* イーショップ クレモナ用スタイルシート      */
/* cremona.css                                 */
/***********************************************/
/***********************************************/
/* HTMLタグへのスタイル                        */
/***********************************************/
/*
body{
	color: #333333;
	margin: 0px;
	padding: 0px;
	width: 740px;
	background-color: #FFFFFF;
}
a:link, a:visited {
	color: #330000;
	text-decoration: underline;
}
*/
/* コンテンツ見出しのリンクには下線を表示しない */
/*
h3 a:hover {
	text-decoration: none;
}
*/
/***********************************************/
/* 画面の構成要素へのスタイル                  */
/***********************************************/
/* 全体テーブル 横幅 */
/*
.all {
	width:740px;
}
*/
/* タイトル 背景画像・文字位置 */
/*
.title {
	height:60px;
 	background-image:url(image/head02.jpg);
	background-repeat:no-repeat;
	background-position:top left;
	vertical-align:middle;
}
*/
/*********    end of cremona.css      **********/

正しいHTMLの効果

W3Cの勧告や文法的な正当性の話については、さまざまな意見や立場があるようです。「別に文法的に間違っていても表示されているから問題ない!」 「文法的に間違いがあるサイトでも検索エンジンの上位にランクされているから関係ない!」

確かにそうかも知れません。でもHTMLの文法を考慮したHTMLを書けば、どんな環境でも製作者が意図した通りに閲覧してもらえたり、目の不自由な人の負荷を軽減したり、検索エンジン対策としても有利となります。さらに、変更作業が楽になります。

そんなに大変な作業ではありませんし、何が何でも間違いは許さない! 絶対に満点を取らないとダメだ! というわけではありません。はじめにチョットした気配りをすればOKです。

投稿者 itleader1 : 00:00 | コメント (5) | トラックバック

2006年05月10日

プログラミングのお作法

プログラムにも作法があった

SSakura0217.jpgプログラムをつくるのに作法が必要だと思いますか?
明日東京でプログラミングの作法について話をするので、改めてプログラムと作法について考えて見ました。

自分で作って、自分で使い、自分で変更するならともかく、お仕事として作るプログラムは、長い期間にわたって使われ、自分以外の人が変更する可能性があるため、お作法が必要となります。数十行のHTMLでさえ適当に書かれたコードは見るに耐えません。時として数千行にもなるプログラムのソースが書き散らされていたら、もうこれは手のつけようがありません。

プログラミング作法のバイブル

C言語の大家であり、C言語を使う人間にとってのバイブルである「プログラミング言語C」の著者であるB.W.カーニハンが「プログラミング作法」という本を書いています(アスキー社刊 R.Pikeとの共著)。これもまたプログラマにとってのバイブルと言える本です。C言語をベースにJava等にも言及しながら実例をあげて作法の重要性を説いた本ですが、教科書的な「こうすべきだ!」という話ではなくて、なぜ作法が必要なのか?カーニハンはどうしているのか?が淡々と書かれています。

大家も実はテストが嫌いなのか?

プログラムの作法というと、変数には説明を入れろ! とか、関数の名前はこう付けろ! とか、ここには改行を入れろ! といった、プログラムを書く際の決まり(コーディング規約といいます)についての話が多いのですが、カーニハンの本には、テストやデバッグ(プログラムのバグ=不具合を探して修正する作業)についての話もあって、こちらの方がタメになります。ともするとプログラマはプログラムを書いたら作業が終了したような気になるものですが、実はプログラムは書く作業より、書いた後の作業、テストやデバッグの方が大変で重要なのです。と、分かっていても、テストとなると、単純で、繰り返しが多くて、ついつい敬遠しがちです。そこで大家カーニハンの言葉

テストでも最も重要なルールは、テストをすることである。

大家であるカーニハンも、本当はテストが嫌いで、できればテストしたくなかったから、こんな言葉が出てきたのでは? そうかんぐってしまいました。しかし、この言葉の通り、テストをすることが良いプログラム作りの第一歩です。テストはしっかりやらなければ!と改めて気を引き締めております。

投稿者 itleader1 : 12:56 | コメント (1) | トラックバック

2006年05月03日

桜の思い出

白馬の桜はまだまだ見頃ですが、今日は今年最高の桜の思い出です

SSakura0191.jpgちょっとしたトラブルで投稿が遅くなってしまいました。天下随一 高遠の桜 今年もこの桜が最高でした

SSakura0213.jpg桜の向こうにはまた桜、織田・武田の古戦場の城跡は桜で埋め尽くされています。

SSakura0225.jpg夕暮れが迫り、桜が妖艶な色に染まります。

SSakura0239.jpg本丸に通じる橋をお堀のしたから見上げると、そこにも桜です。

投稿者 itleader1 : 23:59 | コメント (3) | トラックバック

2006年04月26日

携帯で撮った京都の桜

やっと京都の桜にめぐりあえました

Ninnaji1.jpg 水曜日担当アウトドア診断士 佐藤です。
先々週、週末は京都です!! と浮かれていたら、ドタキャンとなり、落胆のあまり風邪を引いたりしていたのですが、やっと京都の桜を見ることができました。
今回はお仕事優先だったので、携帯で撮影した画像となりました。

Ninnaji2.jpgソメイヨシノはもう終わっていましたが、御室の桜は満開をチョット過ぎた頃でした。御室の桜越しの五重塔、いかにも京都 といった風情です。

Shidare.jpgまだまだ満開で頑張ってくれている枝垂れ桜もありました。コケの上も、頭の上も、桜の花が一杯です。
携帯の画質チェックも兼ねて、敢えてノートリミング・ノーリサイズ・チョイレタッチの原寸大でアップしています。


Arasiyama.jpg打合せの都合?で宿は嵐山になりました。塀越しに竹林と枝垂れ桜、うーん、京都です。

投稿者 itleader1 : 01:19 | コメント (5) | トラックバック

2006年04月19日

無料ショッピングカートを使おう

商品一覧以外、例えばトップページから商品をカートに入れてみる

S0069Kobushi1.jpg ズクダスメンバーの皆さん、一昨日は「何でも座談会」にご参加いただきありがとうございました。風邪気味でご迷惑をおかけしました。まさか、風邪がうつったという方はいないでしょうね。画像は風邪の原因である気の早い花見で撮ったコブシ(モクレン?)の花です。桜はまだ3分咲き程度でした。

座談会で話題になったFC2の無料ショッピングカートを使って、商品一覧以外のページからカートに商品を入れてみました。

「カートに入れる」 をクリックすると、『信州撮っておきショップ』に「浅い春」という商品(上の花の画像)が入ります。

「カートの確認」 をクリックするとカートの中身を見ることができます。

現在は、「カートに入れる」ボタンをクリックすると、画面上部にカートの内容が、画面下部に商品一覧が表示されています。「カートに入れる」でダイレクトにカートの確認に行くには、テンプレートを使い、チョット細工が必要になります。

New! 数量がゼロになっていたのを修正しました。数量1でカートに入ります。

商品一覧のページからカートに入れる例はこちらです。(上の「カートに入れる」をクリックしたのと同じ画面です)

この商品一覧のページもカテゴリに分けたり、画像を複数入れたり、コメントやメッセージが書けたりするので、結構使えると思います。場合によっては、トップページだけをHTMLで作り、商品のページはFC2の無料ショッピングカートで済ませることもできるのでは? と思ってしまいました。

毎週水曜日担当 アウトドア診断士 佐藤

投稿者 itleader1 : 07:26 | コメント (0) | トラックバック

2006年04月12日

全国空港ポータルサイト「えあぽネット」がオープンしました

日本初!全国の空港ビルの情報発信サイト 「えあぽネット」構築のお手伝い

全国55ヶ所の空港の情報をワンストップで提供するポータルサイト えあぽネットが、この4月にオープンしました。

北は千歳・稚内・釧路・女満別から、南は那覇・久米島・徳之島まで、全国の主要空港ビルのお得な情報や役に立つ情報が満載です。もちろん、松本空港改め信州まつもと空港の情報もあります。

この「えあぽネット」の構築に際して、個人情報の取扱いや運営方針立案、SEOといった面でお手伝いさせていただきました。

えあぽネットの特長

えあぽネットには、
   「桜が見ごろになりました!」
   「空港足湯はじめました!」 
   「櫻林(おうりん)の角煮まんじゅうが大人気です!」
などのナマの情報が各空港から直接アップされます。利用者が欲しい情報を検索することもできます。

となると、当然裏ではデータベースが動いています。そのデータベースに登録された情報を元に、トップページには最新情報を、情報検索ページでは利用者が指定した条件に対応した情報を、各空港のページではその空港の情報を抽出して、HTMLを生成しています。

静的なページはSEO的に有利か? を実践的に検証する

ここまでは、よくある動的なサイトですが、えあぽネットが生成するHTMLは動的なものではなく、静的なHTMLです。各空港からアップされた情報を元に、定められた時間間隔で静的なHTMLを生成し直しています。このやり方は、数分間隔でリアルタイムに在庫情報を更新する必要があるサイトや、大量の商品から必要な商品を抽出する必要があるサイトでは無理がありますが、数時間から一日一回程度の更新頻度のサイトでは有効な手法だと思います。

動的なサイトと静的なサイトのSEO面での有利不利については、過去のずくだすブログに投稿しています。はたして、この静的なポータルサイトがSEO的に有利となるかどうかについては、今後の分析を待つことになります。

えあぽネットの今後に注目

えあぽネットはスタートしたばかりですが、全国の空港の情報を一括して入手できるという利便性から多くの利用者が期待できます。また、空港や航空会社・自治体からのリンクが可能であるという優位性もあります。利用者が必要とするナマの情報をアップし続ければ、検索エンジン上位ランクインは十分可能ではないかと思っています。

ただし、開設時期が迫っていたため、静的動的以前に基本的な検索エンジン対策などがまだまだ必要な状況です。という訳で、今週末は関西に行って来ます。東京の桜は散ったようですが、関西の桜はまだまだ見ごろかもしれません。さっそく、えあぽネット伊丹空港の周辺情報を入手しなくては!

投稿者 itleader1 : 12:33 | コメント (1) | トラックバック

2006年04月05日

システムから離れて

S5493AsamaZansho21.jpg 仕事からもスキーからも離れて、軽井沢に行きました。しかし、山からは離れられそうもありません。残照のスポットライトを浴びた浅間山の噴煙です。

S5473John.jpg たまにはホテルでお茶を。ジョンレノンの定宿だったホテルのカフェテラスでティータイム。レノンが見つめています。
オーバーフィフティーズのトンカツ世代はビートルズ世代でもあります。

S5445Roka.jpgさすが老舗ホテル、廊下を撮っても絵になります。こんなホテルに長逗留し、音楽を聴きながら読書して、飽きたら旧軽を散歩・・・・などという生活ができたら最高でしょう。

投稿者 itleader1 : 12:02 | コメント (5) | トラックバック

2006年03月29日

今日はスカッと爽やかに行きましょう

凱風快晴

S5440Mount.jpg 前回はWBCの興奮の最中に、イチローのイメージチェンジにかこつけてシステム屋のぼやき話しを書いてしまいました。今週は明るい話しを・・・と思っていますが、桜の話題とともに雪はどんどん融けていくし、システム関係のことを書くとまたボヤッキーになりそうなので、今回はシステムにはあまり関係のない話題にしておきます。久しぶりにアップした画像は、先週の土曜日の標高2,000メートルの栂池自然園からの白馬三山です。

S5402Ana.jpg春先には珍しく、霞もなく、スカッと晴れた一日でした。夏には遊歩道を歩るかなければならない自然園も、雪に覆われた今は好きなところを歩けます。スノーシューのトレースを辿って、自然園の奥まで足を伸ばしました。

S5432Stock.jpg1時間ほど歩いて休憩です。相変わらず無風快晴の空です。先ほどのスノーシューは先人の足跡、こちらはテレマークスキー&クロカンスキーです。かかとが固定されていない板で雪原を歩き回りました。歩きは快適ですが、滑りはバランスを取るのが大変で、気を抜くと顔面転倒です。

S5442Koya.jpg ミニツアーの終点には、信州に住み着くきっかけを作ってくれた山小屋が村の資料館として残されていました。30年以上も前、ちょうど今頃の春の数週間をこの小屋で過ごしました。懐かしい。古き良き時代の山小屋です。

S5380Buna.jpg 先々週は小谷温泉から雨飾の山ろくのブナの林の中を歩き回ってきました。この日はあまり天気が良くなく、樹木には風で吹き付けられた雪が張り付いています。信州にも春が来て、こんな景色ももう見られなくなります。

今日は冬に戻って雪が降りそうです。スタッドレスを履き替えた皆さん、気をつけて!

投稿者 itleader1 : 05:13 | コメント (4) | トラックバック

2006年03月22日

イメージと違う

日本野球 世界1に

昨日今日のTVはWBCのニュースで持ちきりです。日本野球が世界のナンバー1になったのですから当然かもしれません。何といっても世界でトップです。これは凄いことです。山スキーなどに行かず、家でTVを見ていたほうが良かったかな と少し後悔しています。

世界一の貢献者として、個人的には松中の激走に一票入れたいのですが、やっぱりイチローをはずすわけにはいきません。

いつものイチローとイメージが違う

WBCのイチローは、闘志を全面に出し、マスコミにも頻繁に登場し、30年発言で物議を呼んだように本音に近い発言が目立ちました。クールで優等生的なイチローから、チームを勝利へと引っ張っていく、人間的で熱いイチローへの変身です。これまでの孤高の天才というイメージとは大違いです。

Japanという看板を背負ったことでイチロー自身が変わったのでしょうか? それとも、マスコミや外見を通じて抱いていたこれまでのイチローのイメージが、実際のイチローと違っていたのでしょうか?

システム開発とイメージ

システム開発でも 「イメージと違う!」と言われることがあります。

仕様書をまとめ、製造を終え、納品したあとに、「このシステム(プログラム)はイメージと違う」と言われると、途方に暮れてしまいます。8回に韓国で逆転されたJapanのようなものです。

そもそも イメージとは

goo辞書(三省堂提供「大辞林 第二版」)によると
(1)心の中に思い浮かべる姿や情景。心象。形象。 「美しい―を描く」「インドは暑い国という―がある」
(2)心の中に思い描くこと。 「―していたものと実際は全く違った」
(3)〔心〕 目の前にない対象を直観的・具体的に思い描いた像。 「視覚的―
とあります。

形ではなく、心の中に描いた、感覚的な姿がイメージです。

心の中の姿は他人には分からない、感覚には個人差がある

外からは分からない、個人差のある感覚的な姿を元に、石頭のコンピュータ上で動作するシステムを作り上げるにはイチロー並みの天才が必要です。凡百のシステムエンジニアにはほとんど不可能です。

イメージは変わる

マスコミが取り上げているように、これまのイチローとWBCでのイチローのイメージは大きく変化しています。真実のイチローにイメージが近づいたのか、イチロー自身が変化したのかはともかく、イメージが変わったことは確かです。

イチローのイメージの変化はWBCの数週間で起きました。システム開発は数ヶ月から数年にわたる作業です。この間、当初のイメージが不変であるはずがありません。イメージが変化するとすれば、イメージをお互いが確認できる形に残してしておかなければ、システム開発は蜃気楼を追いかけているようなものです。

イチローはJapanの仲間に別れを告げアリゾナのマリナーズ・キャンプに向かいましたが、システムエンジニアの行く先にはアリゾナの砂漠が待っているのでしょうか?

投稿者 itleader1 : 12:12 | コメント (3) | トラックバック

2006年03月15日

身近なメディア問題

現在の案件も検収段階に入りました

Yadoさん同様2月にピークを迎えていた開発作業がひと段落し、ユーザ検収の時期となっています。開発者としては、ホット一息・・・などと言う訳には行かないところが、システム開発の難しいところです。

仕様書の通りに動作するかどうかをチェックするのが検収ですから、原則としては、仕様に従って作っていればOK! のはずですが、実際は使ってみていろいろな要求、要望が出てくるものです。幸い、今回のお客さまにはシステム作りの難しさを理解していただいているので、そんなに大きな問題は出ない・・・と祈っているのですが、コレばっかりは蓋を開けてみないと分かりません。検収時に問題が出たら、当然お客さまから連絡があります。これがまた問題です。

メールか?電話か?ファクシミリか?

メールであれば即受信が確認できます。電話も会社にいれば対応できます。ところがファックスは・・・・

インターネットの普及に反比例して、ファックスを使う機会は激減しました。この一年間にファックスを送ったことは数回しかないでしょう。受け取った回数も両手で数えられます。つまり通信連絡手段としてファックスにはほとんど頼っていない状況です。従って、ファックスが来ているかどうか?などほとんど確認していません。半日くらいは受信に気がつかないことがあります。これはビジネスの連絡手段としては問題です。

返事はやっぱりメールで

ファックスで受信しても返事はメールで返します。紙では管理が面倒ですし、検索もできません。ファックスの文面を再度メールとして入力して、返事を書き、メールを印刷して、ファックスする。何か手間が増えているような気がします。

ビジネス以外の連絡手段

これまであらゆる悪運と強弁を使って逃れていた町会の役員についに選出されてしましました。アミダクジです。何かアミダは端を選ぶと当たり易いそうです。

役員名簿や連絡網、さっそく開かなければならない役員会の連絡・・・いちいち電話をかけていたらたいへんです。そもそも本人自体、平日は帰りが遅く、休日は朝からお出かけです。いくらなんでも、夜の10時に町会の用事で電話はできません。休日の朝7時に電話したらせっかくのお休みにご迷惑をかけることになります。それに書類は電話では送れません。こんな時、みんながメールを使っていたら・・・とぼやきながら、結局郵便で資料を送ることになりました。IT IT といいながら、あまり代わり映えしない作業です。役員はこれから一年続きます。システム稼業はもっと続くでしょう。

投稿者 itleader1 : 18:12 | コメント (2) | トラックバック

2006年03月08日

一番嫌な日

試験前日

明日は、というより朝になったら、長野県の高校入試です。受験生にとって、この受験の前日が一番嫌な日かもしれません。

さらに今週は国立大学の合格発表の週です。これも結果を知るまでは嫌な日です。

七転び八起き

S5183.jpg人事を尽くして天命を待つ・・・・・結果は後でついて来るものです。結果を考えるより、全力を出し切ることを考えましょう。受験生頑張れ!

七転八倒

今ではインターネットで合格発表を見ることができますが、昔は サクラサク サクラチル の合格電報を家で待つのが一般的でした。待つのが嫌いな佐藤は夜汽車に乗って発表を見に行きましたが、講堂前に受験番号が張り出されるまでの緊張は今でも鮮明に覚えています。

その大学受験より緊張したのはスキーの準指導員検定の急斜面小回りのスタート前です。朝一番のグループでのスタート、斜面はアイスバーン、ゴールでは検定員と他の受験者・サポーターが見守る中での滑走です。転んだらまず指導員にはなれません。今でも時々夢に見ます。

受験のときはそれほど緊張したのですが、今となって考えれば、通った落ちたなどということはそれほど重要ではありません。試験に合格したからといって将来が保証されたわけでもなく、落ちたからといって落伍者になったわけでもありません。合格してもしなくても、七転八倒の人生が待っています。

これはスキーに限った話しではありません。

投稿者 itleader1 : 23:59 | コメント (2) | トラックバック

2006年03月01日

プライバシーポリシーに何を書けばいいか

Webサイトのプライバシーポリシーについて考える

プライバシーポリシーについては、個人情報の保護に関する法律(個人情報保護法)についての経済産業分野を対象とするガイドライン(経済産業省)の中で、個人情報取扱事業者は「個人情報保護に関する考え方や方針に関する宣言(いわゆるプライバシーポリシー、プライバシーステートメント等)を策定し、ウェブ画面へ掲載等より公表することが望ましい」とされています。

ガイドラインの表現をそのまま受け取ると、プライバシーポリシーは義務ではありません。

プライバシーポリシーは必要ないか

個人情報保護法では個人情報の取得に関して、「個人情報を取得した場合は、あらかじめその利用目的を公表している場合を除き、速やかに、その利用目的を本人に通知し、又は公表しなければならない。」とされています。

本人に通知とは、文字通り本人に知らせることですが、これは結構たいへんです。結局、公表することになるのであれば、最初からプライバシーポリシーとして「あらかじめ公表」しておいたほうが賢明ではないでしょうか。

さらにWebの場合、個人情報を取得する手段としてメーリングリストへの登録や通販の購入申込みが考えられますが、この場合は個人情報の直接取得に当たります。

法律では、「本人から直接取得する場合その他本人から直接書面に記載された当該本人の個人情報を取得する場合は、あらかじめ、本人に対し、その利用目的を明示しなければならない。」とされています。

「本人に対し、その利用目的を明示」する事例の一つとしてWebを取り上げ、「ネットワーク上においては、本人がアクセスした自社のウェブ画面上に利用目的を明記すること」とあります。

いずれにせよ、Webサイト上に利用目的を書いておかなければなりません

プライバシーポリシーの必須項目

上記ガイドラインでは、次の事項があげられています。

その他、本人の同意なく第三者提供する場合や共同利用する場合には、データの項目等も公表が必要となります。

プライバシーポリシーをサイトのどこに置くか?

ガイドラインには、「公表」とは、広く一般に自己の意思を知らせること という辞書的な説明の後に、具体的な事例があげられています。その中に 「自社のウェブ画面中のトップページがか一回程度のクリックで到達できる場所への掲載」とあります。トップページの目立つところ、おそらくサイトナビ(グローバルナビゲーション)の中にプライバシーポリシーへのリンクを置いておいたほうがいいでしょう。

Webサイトのプライバシーポリシーとして必要なこと

通販ショップの場合、商品は流通業者を経由して届けることになります。この場合、法律では第三者提供には当たらないとされていますが、利用者に対しては、利用目的として明記しておいたほうが親切です。(藤商さんのプライバシーポリシーにはちゃんと説明されています。Good!)

アクセスしたサイトでログが取られているのに気がついたときは、何となく不安になります。アクセスログを採取していることを明記し、ログの利用目的を書いておくと利用者は安心できます。(加藤先生のサイトには明記されています。やっぱり!)

購入者に販促メールを送ることがあるなら、ご案内のメールを送ることがあることと、申し出によって送信が停止できる(オプトアウト)点も記述する必要があります。(松本ソフト開発センターのサイトにはキチンと書かれています。)

通販を目的とするサイトは利用者に信頼感を与えることが重要です。保有する個人情報の数に関係なく、プライバシーポリシーをキチンと書いて、目立つところに公表するのはWebの基本です。その点、ズクダス関連のサイトはしっかりしていました。さすがです。

以上、毎週水曜日担当 アウトドア診断士 佐藤でした

投稿者 itleader1 : 17:39 | コメント (1) | トラックバック

2006年02月22日

記録は身を助ける

システム屋は記録に救われる

S5283.jpg2月1日に「システムとはアスリートだ!」というタイトルで、システム開発における記録の重要性について書きましたが、今回は本当に記録に助けられたお話しです。それは、今週月曜日の出来事でした。

ハンディターミナルをご存知ですか? バーコードの読取装置にメモリがついた端末機器です。ファミリーレストラン等で注文のときに、ピッピッと入力している器械を見たことがあるかもしれません。あれもハンディーターミナルの一種です。レストランではお客さんの注文を間違いなく厨房に伝える目的で利用されています。スキャナーのついたハンディは棚卸や検品業務で使われています。バーコードをスキャンして入力するので、正確かつ効率的に処理ができるのがメリットです。問題のシステムでも。、部品の入庫入力用にハンディを活用していました。

ハードは修理できてもプログラムは消えたまま

そのシステムは7、8年前に開発し、その後順調に稼働しています。ところが突然ハンディが壊れました。器械だから壊れるのは当然、まして8年近く毎日のように使っていれば壊れて当然でしょう。メーカに修理に出して、器械は戻ってきました。ただ、中に入っていたプログラムはクリアされています。電源を入れても、ピーピーとエラーメッセージを表示するだけで使い物にはなりません。

プログラムを設定しなければならないのですが、8年近く前に開発したシステムですから、当然私の貧弱なメモリ(頭)には記憶は残っていません。ハンディのマニュアルを見ても、記憶はまったくよみがえりませんでした。かすかに、開発時には読取調整のために、何回もハンディ相手にプログラムを調整したなあ ということが思い出されただけでした。

懐かしの出会い

途方にくれて仕様書を探し出して先頭からチェックしていくと・・・。少しづつ記録がよみがえってきます。ハンディ関係の記録も発見できました。そういえばハンディが壊れたときのために、パソコンとの通信設定とプログラムの操作方法についての資料を作ったことがあるような・・・・・

数ページ後に、懐かしい資料がありました。A4で2ページの資料でしたが、その資料を頼りにハンディターミナを復活できました。記録は身を助ける の記事を改めて実感した事件でした。やれやれ。

投稿者 itleader1 : 12:04 | コメント (2) | トラックバック

2006年02月15日

トリノオリンピックを見ながら、失敗と成功について考えた

メダルが取れません

トリノオリンピックも中盤にさしかかりましたが、日本はメダルが取れません。毎晩、今日こそはメダル獲得か?とTVを見ていても、出るのはため息ばかりです。このままメダルゼロ ということにもなりかねません。

注目していたのはモーグルでした

少しかじったことがあるので、競技初日の女子モーグルに注目していました。上村と里谷のどちらかでメダル1個は取れるはず と予想していたのですが、見事に外れました。

二人とも3Dエアーそのものはそこそこ決まったのですが、エアーの前後でのミスや減速が採点に影響した とのこと。確かにDVD録画を見直すと、エアーの前でいつものようなスピードが出ていません。上位の3人と比べると、スピードと迫力に差があります。

少々の失敗を恐れず、もっとアグレッシブに行ったほうが良かったのかもしれません。自ら難度の高い技に挑戦し、「エアーさえ決まればメダル確実!」と言われ、エアーの成功を優先したことが、全体としての失敗(メダルなし)につながったという皮肉な結果でした。

挑戦するから失敗する

結果を出すには挑戦するしかない。しかし挑戦には失敗がつきものである。

失敗を恐れていては結果は手に入らない。しかし、失敗してしまったら、元も子もない。

などと考えていたら、オリンピック中継の間に見るともなく見ていたTVから、「失敗を楽しめ!」 という言葉が聞こえてきました。「プロフェッショナル 仕事の流儀」という番組でした。「新しいことに挑戦すれば失敗するのは当たり前、失敗こそが成功への道だ!」 (同番組での東大工学部助教授の古澤明さんの言葉)

今夜は男子モーグルです

日本がメダルを取れるかどうかではなく、純粋に競技としてのモーグルを観戦したいと思います。コブだらけの急斜面を一気に滑り降り、背丈ほどの台からジャンプする! まさに失敗と成功を分ける一瞬がそこにはあります。失敗を楽しんでいるプロフェッショナルの姿が見られるかもしれません。

投稿者 itleader1 : 19:29 | コメント (3) | トラックバック

2006年02月08日

システムの失敗事例がまた一つ

システム開発の失敗で50億円の損失!

東京ガスが自社システムの開発中止で3月決算で50億円の損失を計上

コールセンターのシステムと関連会社の業務システムを統合し、顧客情報を一元管理するシステム。

経営責任として社長の報酬を2ヶ月20%自主返上、担当部長・マネージャは社長訓戒

以上、東京ガスの発表資料を抜粋

システムは30億円の予算で2003年3月に開発開始したもの。当初の完成予定は2004年10月だったが、完成が遅れ開発コストは予算の倍の60億円に膨らんだ。

運用テストでデータの呼び出しが現行システムより40秒も遅いことが判明。顧客向け施策の変化もあって、中止を決定。

以上、@ITの記事を抜粋

なぜ失敗したのか?

S5167.jpg

さすが大手は開発規模も損失も大きい! というのが最初の感想でした。次の疑問は、なぜ失敗したのか?です。

@ITによると市販の業務システムをベースに自社で開発していたようですが、詳細はネットにも見当たりません。現行より40秒遅い(1顧客データの呼び出し?)ので、使い物にならない!と判断したのでしょうが、プロジェクトはたいへんだっただろうな とSEとしては同情してしまいます。

失敗の原因は公表されていない

S5216.jpg

結局、今のところ失敗の原因は公表されていないようです。真相の解明は日経コンピュータの「動かないコンピュータ」にでも期待するしかなさそうです。

システム開発の失敗を公表するという話はあまり聞いたことがありませんから、公表したことだけでも画期的といえるのでしょう。 これはあくまで勝手な推測ですが、「額が大きすぎて、公表せざるを得なかった」というのが本当のところかも知れません。

失敗の原因を公表すれば、他山の石として今後のシステム開発に役立てることができ、50億円の損失も無駄にはならないのでは? と思うのですが・・・・・

失敗で50億円の損失があっても東京ガスは当期経常利益800億円以上とのことです。失敗の額の大きさ以上にタメ息が出てしまいました。

以上、水曜日担当 アウトドア派中小企業診断士 佐藤でした。
画像は癒し系中小企業診断士 宿澤さんが泊まった松本市美ヶ原温泉にある「松本民芸館」でのスナップ 道祖神と福助

投稿者 itleader1 : 12:40 | コメント (3) | トラックバック

2006年02月01日

システムとはアスリートだ!

2月と言えばトリノオリンピックです

SNorikura1.jpg トリノオリンピックの開幕も間近となりました。昨日から今朝にかけては、ボブスレーとスケートの参加が拒否されたとか、認められたとかの話題で盛り上がっています。そこで、今回のシステムとは何だのテーマは『システムとはアスリートだ!』です。画像は快晴の乗鞍岳、オリンピックとは縁のないテレマークスキーで一の瀬園地を走ったときの一枚

アスリートとは?

Googleで検索結果第三位にランクされているサイト athlete では、『具体的にアスリートという言葉のはっきりとした定義があるのではありませんが、一般にアスリートという言葉から連想される姿にスポーツを競技として取り組む人々があげられるのではないでしょうか。そういった人々に共通して言える事は、自らの限界に挑戦し高い目標に向って惜しみも無く努力を重ねているということでしょう。』とあります。このサイトのサブタイトルの通り、アスリートとは、『自らの限界に挑む挑戦者』のことでしょう。

システムとアスリートのビミョウな関係?

自らの限界に挑む挑戦者とシステムを結ぶつけるのには、チョット無理があるかもしれません。時としてシステム開発者がアスリートのように自らの限界を超えて作業することはあっても、システム自体が常に限界に挑んでいるわけでもありません。

アスリートにはレジャーとしてスポーツを楽しんでいる人は含まないようです。すくなくとも、自らの気力・体力の限界を伸ばそう、超えようとする人こそアスリートにふさわしい人でしょう。つまりスポーツを通じて、自分や他人の気力・体力の限界、つまり記録に挑み、記録を残そうとする人がアスリートです。

この『記録に残すことが大事だ!』という点が、システムとの共通点です。

システムと記録

システム開発では、多くの文書=記録を作ります。提案書>外部仕様書>詳細仕様書>プログラム仕様書>検収仕様書>検収手順書>操作説明書等々、システムの半分は記録でできている といってもいいでしょう。

東証のトラブルも記録の不備が原因だった

しかし、開発作業が切羽詰ってくると、往々にして記録を残すことが後回しになることがあります。かの東証(こちらの藤商ではなく、東京証券取引所のほうです)のトラブル・・・東証もこのところトラブルが多発しているので東証のトラブルだけでは不十分ですね・・・去年の11月1日システム変更に伴う月替わり処理の際にシステムが半日に渡り全面ストップしたトラブルです。システム変更時に作成した作業指示書に記載漏れがあったことが原因だとされています( こちらのサイトを参照させていただきました)。システムの増強に終われ、作業優先となり、何とか納期に間に合わせてホットして、つい記録を忘れてしまった・・・・・・システムの開発者としては、多分こんなところだったんだろうな?などと勝手に想像しています。

何億円かけたシステムであろうと、いかに優秀な人材が手がけたシステムであろうと、記録をキチンと残していなければ、トラブルは防げない という教訓でした。

開発初期段階での記録の重要性

トラブルはシステムのバグだけではありません。バグも怖いのですが、それより恐ろしいのが、言った言わないのトラブルです。

システム開発の初期=クライアントの要望を元に要件定義や基本設計を行う段階では、ユーザとの打合せ内容を記録して確認し、その記録を元にシステムの要件を定義し、その要件定義を元にシステムを基本設計する という作業が主となります。文字通りシステムの基本を決める、極めて重要な段階です。最低でも2,3ヶ月、時として半年や一年もかかることがありますが、この間、自分の言ったことを正確に記憶している人はマレです。ひどいときにはつい一週間前の発言と逆の意見が飛び出したりします。そんなとき頼りになるのは記憶ではなく、記録です。記録を残し、双方の確認がなされていれば、無用なトラブルは防止できます(多分・・・・・)。

開発最終段階での記録の重要性

さらに開発が進み、数ヶ月から半年以上もたって納品するとなると、ほとんどの人は自分の言ったことなど覚えていません。形のないモノについて机上で言ったことと、実際に動くモノを前にして言うことが一致している方が不思議かもしれませんが・・・

『これでは使えない!』『イメージと違う!』『なぜこんな動きをするのか?』

それでも要件定義と同じ人物に納品するのであれば何とかなります。最悪なのは、要件定義で話しをした人とは別の人物が納品段階で登場することです。意外にこれはよくある話で、要件定義ではトップもしくは管理者が自社の理想の姿からシステムの要件を語り、納品になると現場の担当者が現実的側面からシステムへの注文をつける などということは当たり前だと考えていたほうがいいでしょう。

システムの製造とは、仕様書に書かれた要件をコンピュータ上で実現することです。この段階で、上流に遡り、要件や仕様を変更されたら、システム開発は成り立ちません。そんなとき頼りになるのは仕様書です。仕様書がキチンと作成され、双方で承認されていれば、納品の際のトラブルは防止できます(多分・・・・・・・・・)。

信じるものは救われる?

防止できないまでも、記録の有無によって対応は大きく違ってきます。もし記録がなかったら、恐らくは力関係を前提とした対応となることでしょう。そうならないために、記録の重要性を信じて、システム開発者は今日もWordに向かって、モクモクと(ムカムカと)作業を続けるのでした。

投稿者 itleader1 : 12:19 | コメント (2) | トラックバック

2006年01月25日

動的ページはSEO的に不利か? について考える

動的ページで検索エンジン対策は可能か

SGokuraku.jpg先週あたり、動的ページが検索エンジンから嫌われているか? について、ずくだすのメーリングリストで盛り上がっていました。あいにく出張中で、皆さんのお話しには乗り遅れてしまったのですが、チョット考えてみました。
ということで、その出張先、関西のハデハデ看板 追加の一枚。道頓堀極楽商店街の看板です。

XOOPS等のCMSの対策

固定的なHTMLで作成される静的なページに比べ、クライアントからのパラメータによって可変的なHTMLを作成する動的ページは、SEO上不利だといわれています。確かに、数千、数万の商品をパラメータで切り替えて表示するような動的ページは検索エンジンも巡回しきれないと思われます。しかし、サイト更新を簡単にする目的でCMSを採用したサイトであれば、そんなにページ数は多くはありません。数十ページ程度なら、ある程度の対策が取れるのではないでしょうか?

CMSで作成した動的ページの検索エンジン対策

動的ページがSEOで不利な理由としては、 URLにパラメータが含まれること が考えられます。パラメータ付きURLとは http://www.zukudas-m.com/mt/mt.cgi?ID=12345&ITEM=ABC012&KEYWORD=%1%2%3  などというものです。パラメータに何を設定していいかわからないため、さすがのロボットも巡回できません。そこで、先方が分からないのであれば、こちらでパラメータを指定した巡回経路を作ってあげてはどうでしょう。

パラメータを含めたURLを静的なページからリンクすることで、ロボットの巡回を促進できるのではないかと思います。?や&があるだけで嫌うような検索エンジン相手にはどうしようもありませんが、?や&があってもインデックスしてくれるエンジン(GoogleやMSN?)であれば、少なくとも指定したパラメータのページがインデックスされる可能性が高くなるのではないでしょうか。

もちろん、この方法は数千、数万のページには適用できませんが、CMSで作る、ページ番号をパラメータとしているような動的サイトの場合は、使えるのではないか?などと考えています。

データベースが自動生成する大量な動的ページの場合

数の多い動的ページの場合、サーバの設定や特定のソフトを入れることで、検索エンジンに静的ページとして認識させる方法がありますが、いろいろな難しさがあるようです。参考までにXOOPSの該当サイトをみてみたら、『正常に動作しないことがあります・・等』の脅し文句が多く、ビビッてしまいました(高砂さんが断念されたもの無理はありません)。動的ページを静的ページに見せかけるのではなく、生成時に静的ページを作ってしまう という方法もあるようですが、これも数が多いと大変です。

実は関西出張の目的の一つがポータルサイト構築のお話しでした。そこでも動的ページを使うことになりそうです。この件については、お仕事を兼ねて、もう少し研究してみます。

投稿者 itleader1 : 12:25 | コメント (2) | トラックバック

2006年01月18日

目立つが勝ち! 大阪のコテコテ看板を撮る

個人情報保護システムとポータルサイトのお仕事で関西に出張してきました

SKuidaore.jpg今回の出張は京都・大阪でした。大阪は久しぶりなので、仕事を終えた後、帰りの電車までの間に、難波に足を伸ばしました。キタの摂津地域で大学時代を過ごしたので、大阪のコテコテ文化にはある程度の免疫はあるのですが、ミナミのパワーは相変わらず、いや昔を上回る勢いです。最初はあきれていたのですが、街を歩くうちにダンダン楽しくなってきました。そこで今回は、コテコテの象徴、看板の特集です。道具屋筋のイーゼルも撮りました。
大阪の看板?といえば、食い倒れ人形です。

フグの競演。ズボラヤとたよしです。ビミョウにフグの顔形がちがうところがおもしろい。SZuboraya.jpgSTayoshi.jpg

SKani.jpgかに道楽ははずせません。

SEzaki.jpg阪神ファンの飛び込みを阻止?するためにガラス(アクリル?)が橋の欄干に取り付けられています。グリコの看板もガラス越しに見物します。

道具屋筋ではイーゼルがたくさん売られていました。確かにブームです。SMarumitsu2.jpgSMarumitu1.jpg

投稿者 itleader1 : 12:15 | コメント (0) | トラックバック

2006年01月11日

ソフトチーム トップページの構成

ソフトチームが作成した藤商さんサイトのトップページの構成

SAme.jpg 今後の作業のために、ソフトチームの第一作の藤商さんのトップページの構成を解説します。その前に、松本あめ市でデジカメ一眼レフで撮影した画像です。

SAmeTubo.jpgこんな壷?甕?に入れて売られていました。

本題のトップページの構成をテーブルで表すと

pageHead
siteTitle
catchCopy
globalNavi
pageNavi
menu
menu
menu
menu
menu
content
contentLeftcontentRight
contentLeftcontentRight
contentLeftcontentRight
contentLeftcontentRight

こんな感じになります。

投稿者 itleader1 : 16:51 | コメント (0) | トラックバック

2005年12月28日

ずくだすソフトチーム 初仕事

ソフトチーム発足&初仕事

12月12日の講習会で、『ずくだす』内のソフトウェア開発関連有志による『ずくだすソフトチーム』が発足し、さっそく初めての仕事に取り掛かりました。対象は同じ『ずくだす』の藤商さんのページ作成です。

打合せは連射から

14日の夕方に松本ソフト開発センターの一室にメンバーと藤商さんが集結し、写真撮影から始めました。赤羽ウェブプロデューサーと佐藤の二人が、『下手な鉄砲も数ウチャ当たる』理論にのっとって、とにかく写真を取りまくりました。連射連射で、最初は緊張していた藤商さんの表情もダンダンほぐれてきました。結果は藤商さんのサイトでご覧になれます。風景ばかり撮っていた新米カメラマンは、朝から書店でポートレイト撮影の入門書を購入し、付け焼刃で勉強しました。センターの演台の白熱灯をスポットにして、眼に光を入れたかったのですが、ナカナカうまくいきません。もっと勉強します。

SEO的な検討も

その後、SEOの分析結果を元に、ページのキーワードをチェックしました。藤商さんのサイトは Alexaでも上位にランキングされています。検索エンジンでもいいところにランクインしています。検索エンジン上位を獲得するというより、お客さまに信頼され、お客さまが安心して買い物できるページを作ることが目標となりました。そのために、色使いやレイアウトの改善が必要です。色はそれぞれ好みや思い入れがあったので、田中さんにサンプルを作ってもらうことで、その夜はお開きとなりました。

サンプルを元に商品を配置してトップページをアップ

サンプルがアップされた後、色を決めようとしたのですが、ここでも諸説があり、決定に至らず。年末セールの期限も迫っていたので、佐藤の独断でサンプルの色をミックスすることにしました。あとは商品を配置すれば、とりあえずトップページは完成だ! と思ったのですが、これが結構たいへんです。商品を見やすくするために、横2列に配置することになったのですが、横への配置ではどうしてもテーブルを使うことになります。ところがテーブルを使うと、商品の入れ替えの際のHTMLの更新が厄介になります。

テーブルを使った例は、こんな感じです。
1: < table>
2: < tr>< td>商品Aのタイトル</td>
3:    < td>商品Bのタイトル</td></tr>
4: < tr>< td>商品Aのコメント</td>
5:    < td>商品Bのコメント</td></tr>
6: < tr>< td>商品Aの金額</td>
7:    < td>商品Bの金額</td></tr>
8: </table>

商品Aを商品Cに入れ替えようとすると、2,4,6行を変更しなければなりません。

そこで、スタイルシートを使い float と margin で横2列に配置することにしました。
1: < div class="contentLeft">
2: < table>
3: < tr>< td>商品Aのタイトル</td></tr>
4: < tr>< td>商品Aのコメント</td></tr>
5: < tr>< td>商品Aの金額</td></tr>
6: </table>
7: </div>
8: < div class="contentRight">
9: < table>
10: < tr>< td>商品Bのタイトル</td></tr>
11: < tr>< td>商品Bのコメント</td></tr>
12: < tr>< td>商品Bの金額</td></tr>
13: </table>
14: </div>

この後も、印刷するとA4縦からはみだしてしまう! とか、藤商さんのサイトにアップすると左右が離れてしまう! とか、細かなことはあったのですが、何とかトップページがアップできました。

今回の作業を踏まえて

まだトップページだけですが、とりあえず『ずくだすソフトチーム』の初仕事が終わりました。信頼して買い物ができるサイトに近づいたのではないかと思います。この後、ソフトチームがトップページ以外のページのレイアウトを作成し、藤商さんが順次ページに適用していくことになります。商品の入れ替えや商品コメントの改良、より信頼を得るためのページの追加も必要です。まだまだ、藤商さんもソフトチームも、やらなければいけないことはあります。

初回の作業だったこともありますが、ソフトチームとしての役割分担や連絡・コミュニケーションなど、改善していかなければならない点が見えています。今回は年末セールに間に合わせたかったので、強行作業になってしまったことも反省点です。
しかし、何はともあれ、『ずくだす』の中で、お互いが協力分担して、お互いが成果を出すための一歩が踏み出せたのではないかと考えています。皆さん、お疲れさまでした。年が明けたら、また頑張りましょう。

ということで、毎週水曜日 『システムとは何だ!』 2005年は、これが最後の記事となります。お正月の4日はお休みをいただいて、新年は11日から登場します。

ずくだすのメンバーの方、加藤先生、高砂さん、窪田さん。2005年はいろいろとありがとうございました。おかげさまで、一歩踏み出せた年になりました。来年もよろしくお願いします。

投稿者 itleader1 : 14:47 | コメント (4) | トラックバック

2005年12月21日

ブログでお仲間を発見しました

ブログで広げよう友達のワッ +浅間温泉の雪だるま

SAsamaSanta.jpg ブログの効用はビジネスへの展開だけではありません。本来ブログは自分の書きたいことを書き、その記事に共感してくれる人とのコミュニケーションを広げるためのツールでした。ブログをビジネスに活用することばかりに注目していましたが、そんな中で自分と同じような考えを持った人の記事を読むと、何かうれしくなってきます。今日そんな記事を、身近なところで見つけました。


単焦点レンズで頑張ろう

SAsamaOmise.jpg 加藤先生の生徒さん というよりカメラの弟子の一人 新潟のWeb店長さんの記事で、『一度カメラの基礎を勉強し直す為に50mm単焦点レンズを手に入れました。』というものです。うーん、凄い。しかもツアィスレンズですよ。高そう!こちらはPentaxの40ミリ F2.8 ですから、だいぶ見劣りしてしまいますが、考えは同じです。
『ズームに頼らず、足と構図でカメラ道に精進しましょう!』

SAsamaRoji.jpg 佐藤は、ついでにレタッチにも頼らず精進することを決意しました。理由は面倒くさい という軟弱なものですが・・・・。今日の3枚はいずれも、Pentax DS40mm F2.8 Limited ノーレタッチものです。2、3枚目のスナップ的な使い方には理想的なパンケーキ(薄型)レンズです。

ブログのコツは書くこと!

ブログのコツはとにかく記事を書くことです。何かを書けば、誰かが読んでくれます。その記事から意外な展開があるかもしれません。書かなくては読んではもらえません。宝くじも馬券も買わなくては、当たりません。年末ジャンボは昨日が締め切りでしたが、ブログには締め切りはありません。

以上、アウトドア診断士 佐藤 でした

投稿者 itleader1 : 12:42 | コメント (4) | トラックバック

2005年12月14日

ブログで検索一位は夢ではない!

検索ランキングが復活しました。3位入賞です

SDeck.jpg Googleで検索1位を極めながら一時は123位まで下落していた「複眼ブログ」がGoogle3位に返り咲きました。YSTは2位、MSNは1位です。

先週は原因をいろいろと詮索していましたが、どうやら簡単なことだったようです。つまり、ブログで検索一位を獲得するには、毎日更新することが第一歩である ということです。更新しなければ順位は確実に下がります。地道に毎日更新していればロボットが巡回し、ランクインする可能性が生まれます。巡回されなければ上位どころかランクインすらできません。

ロボットが巡回してきているかどうか? アクセスログでも確認できますが、簡単なのは Googleツールバーでキャッシュをチェックすることです。キャッシュされていれば、その日付も確認しておきましょう。おおよその巡回頻度が分かります。どうしても巡回して来なければ、こちらから巡回申請するという手もあります。

実験に使ったサイトは、12月7日までキャッシュされていませんでした。おそらく加藤先生や宿澤先生のトラックバックやコメントによってロボットが来ていただけで、定期的な巡回コースには登録されていなかったのでしょう。そのため、一時的にトップにランクされたものの、時間がたつと急降下してしまったと思われます。キャッシュされたのはHTMLに関する記事ですが、小布施の秋の写真記事のランキングが復活しています。これも興味深いことです。

スパムサイトだとは見なされたワケではないようです。とりあえす順位が復活してほっと一息です。

投稿者 itleader1 : 13:38 | コメント (2) | トラックバック

2005年12月07日

ブログで検索1位は夢だったのか?

先週のブログ作りに参加された皆さん、ありがとうございました。

ブログ 使ってますか?
 (と白々しく書いていますが、実はRSSリーダで皆さんの更新状況はチェック済みです)。せっかく夜遅くまで頑張って作ったブログです。どんどん使って、成長させましょう。使わないと、使い方を忘れてしまいますよ。

ブログで検索一位 その後

先週 『やった検索一位です!』 と豪語していましたが、今日久しぶりにチェックしたら、YST2位、MSN1位は確保しているものの、Googleが何と 123位までダウンしていました。

なぜYST・MSNでは検索上位を維持しているのに、Googleではダウンしたか? その原因は・・・


よく分かりません。想像では、ログインへのリンクを目立たなくするために色を落としていたのがホワイトテキストだと認定されているのか? あるいは新しいテンプレートに問題がありランクを落とされたのか? Googleのロボットが巡回して来ないのか? ヒョットするとGoogleダンスかも? という期待を持ちながらも、ログインへのリンクをなくし、再度Googleロボットの巡回申請をしてみます。結果はまたお知らせします。

無料サービス 恐るべし!

先日トラックバックでお知らせしましたが、FC2のショッピングカートを試験的に作ってみました。なかなか使えます。高砂さん、赤羽さんはすでに試されたようです。SSLにも対応しているし、カード決済のオプションもあるし、時間指定もできるし、かなりの機能です。物販サイトの皆さん、使ってみてはいかがでしょうか? 手始めに、佐藤の試験サイトで試してみてください。中小企業診断士ショッピングカート開設

カートの他に SNS(説明は宿澤さんのサイトにあります)やアンケートも無料で提供されています。これからは、無料や格安のサービスをうまく使って、速く・安くサイトを立ち上げて、無駄な投資や時間をカットする時代になるのでしょう。勝負するのは、アイデアとマーケッティングですね。

システム屋も作るだけではなく、既存のサービスをいかに組み合わせてシステムを構築するかを提案することになるのでしょう。

投稿者 itleader1 : 19:50 | コメント (1) | トラックバック

2005年11月30日

なんでも座談会でみんなでブログを作りました 

毎週水曜日担当ズクダス佐藤です。
なんでも座談会に参加いただきありがとうございました。

いろいろ考えるよりブログを作ってみましょう
ブログを開設し、
思い思いのテンプレートを適用し、
記事を書き込んで、
ずくだすブログにトラックバックをかけました。

結構たいへんだったけど、とにかく全員がブログを作れて何よりです。
いま改めて各ブログを眺めてみると、既に皆さんの個性が出てきています。
これから、ブログを育てていってください。

佐藤は例によって騒ぎすぎたので、お疲れモードです。
みなさんもお疲れさまでした。

本日の成果
http://elife2.exblog.jp/51591
http://sinanowine.blog39.fc2.com/blog-entry-1.html
http://exxx.exblog.jp/51492
http://azuminosanpo.blog39.fc2.com/blog-entry-1.html
http://kmtkyk0384.blog39.fc2.com/blog-entry-3.html
http://matsugura.blog39.fc2.com/blog-entry-3.html
http://mayut.blog39.fc2.com/blog-entry-1.html

宿澤さんも名古屋からライブ参加してくれました。
手を振ったけど見えましたか?


■追記
加藤先生ずくだす会員のブログが7つ、誕生しました。

投稿者 itleader1 : 23:45 | コメント (4) | トラックバック

2005年11月23日

いろいろ考えるよりブログを作ってみましょう

こんにちは、毎週水曜日「システムとは何だ!」ブログ担当のズクダス佐藤です。
加藤先生、写真への暖かいコメントありがとうございます。励みになります。

S051117志賀山文庫S.jpg
志賀高原の麓 上林温泉の紅葉

さて、来週の水曜日 30日は 「なんでも座談会」。
今回のテーマは 「いろいろ考えているより、とにかくブログを作ってみよう!」 です。

まずブログを開設しましょう

どこか、お好きな無料ブログサービスを選んで、自分のブログを開設しましょう。LivedoorでもYahooでもExciteでもココログでもいいんです。

ただ、先週の記事を読んだ方はお分かりでしょう。サブドメインタイプのブログを選んだ方が検索エンジン対策として有利です。アフィリエイトもできた方がいいでしょう。テンプレート(デザインやレイアウトの定義です。スキンとも言います)も豊富な方がいいでしょう。スタイルシートが変更できた方があとあと便利です。アクセス解析も必要です。

ということでFC2をお勧めします。FC2は人気急上昇、アクセス数では2チャンネルを抜いたそうです。その割にはそんなに遅くはありません。30日のなんでも座談会ではLivedoor、Excite等の佐藤の実例を披露いたします。実際に自分の目で見てください。

いろいろなテンプレートから気に入ったデザインを選びましょう

ブログの楽しみは簡単にデザインが変更できることです。テンプレートを変えてみて、気に入ったデザインのブログにしましょう

最近の無料ブログにはプラグイン機能があり、カテゴリーや最近の記事、プロフィールなどの部品を自分の好きな位置にレイアウトできます。まず、おおよそのデザインを選び、そのあとで部品を上下左右に配置してみましょう。

ブログのデザインは「2カラムタイプ」と「3カラムタイプ」が主流になっています。2カラムタイプは、左にナビ、右に本文(左右逆もあり)、3カラムタイプは、本文の左右にナビがあるものです。座談会では、それぞれのメリット、デメリットについてご説明します。

実際に記事を書いてみましょう

開設したら、記事を投稿しましょう。何を書くか? など悩む必要はありません。
「ブログデビューしました。よろしく!」 でOKです。

お互いにコメントやトラックバックしましょう

コメントはズクダスでお分かりですね。トラックバックはブログがないとできないので未体験の方がいるかもしれません。座談会ではお互いにトラックバックをして見ましょう。一回やってみればトラックバックの意味とやり方が簡単に理解できます。

ブログを作っても何を書けばいいかわからない?

ブログは作るのは簡単ですが、続けるのは結構大変です。加藤先生のようにネタが豊富にあれば苦労は無いでしょうが、一般人はそうはいきません。「自分が好きなことを書けばいい」 「日記だと思って書け」 とか、いろいろなことが言われていますが、実際に始めようとすると、そう簡単にはいきません。佐藤もいろいろと苦労しています。

岡目八目

自分自身では苦労していますが、他人のことはよく見えるものです。 『あずみ堂さんはこんなことを書けば』 とか、『藤商さんのブログのテーマはこれしかないのに』 『信濃ワインさんは・・・』 などと勝手に考えています。その道のプロに素人が訊いてみたいこと、素人が知りたいこと をブログに書けば、ヒット間違いなしです。お互いに知りたいことをあげてみませんか? 意外にそんなところにブログのヒントがあると思います。

詳しい話は、来週jの水曜日に。お待ちしています。

投稿者 itleader1 : 23:56 | コメント (0) | トラックバック

2005年11月16日

ブログのURL サブドメイン形式vsディレクトリ形式

こんにちは、毎週水曜日「システムとは何だ!」ブログ担当のズクダス佐藤です。

今週の一枚

S051113Leaf1S.jpg

無料ブログを始める際に、最初に悩むのが ID をどうするか?です。
「さあ、あなたもブログを始めましょう」と言われてその気になって画面を開くと、IDとパスワードの登録が要求されます。この ID が これから作るブログのURLになる場合がほとんどです。どんなIDが良いかイロイロと悩むのですが、もう一つ肝心なことがあります。それは、ブログサービスがつけるURLが、サブドメイン形式か? ディレクトリ形式か? ということです。

サブドメイン形式とディレクトリ形式

サブドメイン形式とは、 「 http://○○○○.blog1.fc2.com 」 のように、に http:// の直後にIDが入る形式です。
ディレクトリ形式とは、 「http://blog1.fc2.com/○○○○」 のように一番後ろにIDがつく形式です(この形式の正式な呼び名は分かりませんが、サーバ下のディレクトリを指定する書式なのでディレクトリ形式と呼ばれることが多いようです)。
さて、この2つの形式には、どんな違いがあるのでしょうか?

サブドメイン形式はSEOに有利?

一般的にディレクトリ形式よりサブドメイン形式の方がSEOに有利だ と言われます。
 → 【無料ブログ比較なら】まあ待て、ブログを借りる前にここを読め。  
 → ページランクマスター実験室 - サブドメイン
等々によると、ディレクトリ形式の場合、  http://blog1.fc2.com/○○○○ の○○○○より前の部分=blog1.fc2.com の上位2つのブログに入っていないと、検索エンジンでの上位表示は望めない ということです。

本当にサブドメイン形式はSEOに有利なのか?

ページランクマスターに従って、「ブログ ネコ」でGoogle検索してみました。
一位が blog.livedoor.jp/noma_neko/
二位が blog.livedoor.jp/nomatako/ でした。LiveDoorブログはディレクトリ形式です。(有料版はサブドメイン)。
以下100位までには blog.livedoor.jp/ のサイトは見つかりません。(2005年11月16日現在)


二位のランクの下に [ 他、blog.livedoor.jp内のページ ] という行が見つかりました。
クリックしてみると、

「ブログ ネコ の検索結果のうち blog.livedoor.jp からの約 62,400 件中 1 - 10 件目」 

として新たなランクが開きます。

つまり、blog.livedoor.jp の下のネコに関する 62,400件 のページのうち、三位以下のページは通常の検索でランキングには入れてもらえない ということです。どうも、「ディレクトリ形式のブログの場合、同一ドメイン内でキーワードの上位2位までに入らないと、検索エンジンからランキング表示してもらえない。」 というのは本当のようです。逆にサブドメイン形式のブログがまとまってランクインしているかを確認しようとしたのですが、ネコに関するブログはいろいろなブログサービスに分散して、3以上のブログがランクインしているかどうか調べきれませんでした(どなたかチェックして結果をお知らせください 追加 検証ページをみつけました Googleはサブドメイン同士を違うドメインと認識するのか?SEO対策)。

サブドメイン形式が有利かどうかは不明ですが、ディレクトリ形式が不利なことはほぼ確実なので、結果としてサブドメイン形式が有利 となります。

SEOを考えるならサブドメイン形式のブログを選びましょう

無料サービスでサブドメイン形式のURLが使えるブログは以下の通りです。【無料ブログ比較なら】まあ待て、ブログを借りる前にここを読め より
SeesaaBlog、FC2ブログ、JUGEM、エキサイトブログ(アフィリエイト不可)、ココログ、アメーバブログ

サブドメイン形式は、独自サーバを立てているという雰囲気が出せるのも魅力かも知れません。

投稿者 itleader1 : 11:35 | コメント (2) | トラックバック

2005年11月09日

システムとは寿司だ 「ホームページのお値段」

こんにちは、毎週水曜日「システムとは何だ!」ブログ担当のズクダス佐藤です。

前回は、寿司の時価とシステムの時価は似ていて異なる。寿司は天候や季節によるネタ価格の変動による時価だが、システムは作業の量り売り価格の時価であるという話でした。 今回はホームページ=ウェブサイトの価格について考えてみます。その前に本日の一枚。

S051109PendS.jpg加藤先生も訪れた町 辰野町小野宿で見つけた紅葉

ホームページのお値段は?

「ホームページ制作 料金」というキーワードでGoogleで検索してみました。(本当はウェブページと書きたいのですが、検索エンジン上もホームページ制作というキーワードで一般化しているようなので、今回はホームページでいきます。)

サイトA
 ・作成初期費用 企画・立案・取材費用  31,500円より
 ・ページ作成費用 印刷時A4/1枚相当量(イラスト作成費用も含む)  21,000円より

サイトB
 ・TOPページ制作 1Pの規模  100,000円
 ・下層ページ制作 1Pの規模   20,000円

サイトC
 ・トップページ      30,000円より
 ・本文(下層)ページ  10,000円より

サイトD
 ・WEBコンサルティング     52,500円より
 ・企画・構成料          52,500円より
 ・トップページ制作料金     21,000円より
 ・トータルデザイン        52,500円より
 ・その他ページ制作料金 円  10,500円より

サイトF
 ・トップページ 1ページ         10.000円より
 ・2ページ目以降のページ 1ページ  9.000円より

サイトG
 ・デザイン・構成 1サイト       84,000円より
 ・TOPページ制作 1ページ      31,500円より
 ・CONTENTSページ制作 1ページ 15,750円より

サイトH
 ・ホームページ企画          105,000円より
 ・トップページ制作(セミオーダー)  31,500円より
 ・トップページ制作(オーダーメイド)  84,000円より
 ・ページ制作A(原稿素材クライアント提供) 15,750円より
 ・ページ制作SS(A4・1ページ程度、原稿作成、素材は素材集より) 26,250円より

ホームページの相場

トップページで 1万円-10万円、トップ以外のページで 9千円から2万5千円といったところです。サイト全体の企画料を含むかどうか(そもそも全体の企画が存在するかどうか?)や、原稿や素材をどちらが提供するか によって価格も変動するのでしょうが、調べた範囲ではトップページ3万円、他のページはその半額以下というのが相場のようです。

中には、価格破壊ともいえる料金を提示している会社?もありました。
 ・TOPページ作成 1,000円 - 30,000円 (最多価格 5,000円以下)
 ・TOP以外のページ 700円 - 10,000円 (最多価格 3,000円以下)
これで採算が取れているのかどうか、他人事ながら心配になります。

ホームページの時価

システム開発のコストの大半は人件費=作業コスト=時間コストでした。いくら原稿や素材をクライアントから提供してもらってもレイアウトや配色・デザインを考えて1ページを作るには半日から一日は最低でも必要になると思います。まあ、あらかじめ用意されたデザインのテンプレートに当てはめていくだけなら1,2時間もあればページは作れますが・・・。

長野県の最低賃金は時間650円(平成17年10月1日現在)です。8時間で制作したとして支払われる賃金は 5,200円になります。偶然にも価格破壊料金と一致します。

同じく長野県の一般職員の平均年収は 27歳で 373万円、37歳で589万、民間企業は 27.6歳 397万円、37.5歳 594万円 です 100人以上の企業男性平均(長野県発表資料よりPDFです!)。ちなみに長野県の公務員給与は全国でも低いレベルだとのことです。仮に年収が500万円、それだけの賃金を払うために必要な売上を800万円だとすると、年間240日で割って一日あたりの売上額は33,333円となります。恐らく1ページ1日計算で3万円という相場はこのあたりから算出されているのではないでしょうか?

ホームページも寿司も活きが大事です

ホームページのお値段を見てきましたが、これは最初に制作する費用です。ズクダスの皆さんならお分かりのように、「ホームページは作っただけではダメ」です。頻繁に内容を更新し、訪問客に最新のコンテンツを提供することが見てもらえるホームペー作りのコツでした。お金をかけて作ったホームページも更新の費用をケチると死んでしまいます。ホームページも寿司も新鮮さが命だということで今日の笑点はこれにてお開き!

投稿者 itleader1 : 12:17 | コメント (3) | トラックバック

2005年11月02日

システムとは寿司だ

こんにちは、毎週水曜日「システムとは何だ!」ブログ担当のズクダス佐藤です。

東証のシステムダウンのことについてもコメントしたいのですが、原因の究明や賠償の行方がはっきりしていないので、もう少ししたら システムと障害 というお題で書くことにします。今回は、「システムとは寿司だ!」です。

その前に、反響が少なかったのでものすごく不安なのですが、デジカメ一眼レフデビュー第二ラウンドをアップしておきます。(コメントやトラックバックがなくても、投資した分は活用して回収するぞ! ゴキューッパ)

S051102BeansS.jpg S051102KareS.jpg

では、本題の「システムとは寿司だ」に戻ります。

寿司は江戸前

寿司は好きです。学生時代を関西ですごしたのですが、「寿司と落語はやっぱり江戸前だなあ」とつぶやいて、東京出身者に「やっぱりそうだよな」と強く同意されたことを思い出します。バッテラもいいんですが、やっぱり江戸前のにぎりのほうが・・・。

加藤先生の地元清水のマグロを食べに三保の松原までキャンプに行きました。築地の場内の行列のできる寿司屋は雨の中の2時間待ちでした。アナゴはうまかった!

寿司の恐怖

行列は嫌ですが、寿司屋にはもっと嫌なもの、というよりもっと怖いものがあります。それは・・・

 「時価」です。時価と書かれたネタは怖くて注文できません。

システムと「時価」

実はシステムも時価です。寿司屋の時価は季節や天候によって価格が変わる という意味での時価ですが、システムは時間がそのまま価格になる という時価です。まさに タイム イズ マネー です。

価格決定の原則

価格を決定する要素として、原価・需要・競争の3つがあります。最低価格は原価で(=赤字にならない限度額)、最高価格は需要で(=消費者が買ってもいいかなと思う限度額)で決まりますが、最終的には競争によって決定されることになります。

システムの価格

パッケージソフトは別としてオリジナル=カスタムメイドのシステムの場合、原価のほとんどは人件費です。人件費は費やした時間によって決定しますから、システムの原価のほとんどは時間で決まるわけです。そして競争によって価格が限りなく最低価格に近づくため、システムの価格は作業した時間で決まるということになります。

人月単価

ソフト業界では開発規模を人月(ニンゲツ)=一人で何ヶ月かかるか?で表すのが通例です。そして、会社ごとに人月単価を決めて時間数に人月単価を掛けて価格を決定します。

プログラマーの人月単価は60万、システムエンジニアは80万、大手ならプログラマで80万、システムエンジニアで120万 という具合です。

人月単価の矛盾

実はこの価格=原価計算には矛盾があります。

優秀な技術者は単価が高い。そうでない技術者は単価が低い。
優秀な技術者は仕事が早い。そうでない技術者は仕事が遅い。

優秀な技術者は単価は高くても時間が少ない。そうでない技術者は単価は安いが時間がかかる。
つまり、この理屈が正しいなら、優秀な技術者でも、そうでない技術者でも、システムの価格=原価にはたいした差はない!ということになってしまいます。

高単価のカラクリ

矛盾はさておいて、技術によって単価の高低が決まるとすれば、大手のソフト会社の方が単価が高い分だけ技術が優秀なのか?というとそうでもありません。大手は下請けに仕事を出すことが多いので、マージンを乗せて単価を決定しないと元が取れないという事情があります。単価は純粋な技術力ではなく、建設業界と同様の多段階的下請けピラミッド構造による中間搾取の分だけ大手の単価が高めになっているというのが現実です。

技術者の引き出しには名刺が一杯

大手の方が優秀な技術がいることも事実です。しかしそんな優秀な技術者があなたのシステムについてくれるという保証はありません。専属で作業してるような話しをしながら、実は外注(協力会社と言い換えることが多くなりました)に作業をさせて、打合せだけには出てくるという優秀な技術者も存在しています。かつては下請けに自社=大手の名刺を作らせて、打合せの席ではあたかも大手の社員であるかのように振舞うという演技力が暗黙のうちに要求された時代がありました。システム開発をやっていると、自分の名前で会社名だけが違う名刺が引き出しの中に溜まったものです。今でもそんな風習は残っているのでしょうか?

中身で勝負

システムは単純労働ではなく知的労働の結果として生み出されるものです。汎用機全盛時代の帳票作成バッチ処理システムならいざ知らず、これだけ多様化したシステムの価格を時間や人の量り売りで決めるのは、いい加減にやめにして欲しいものです。(仮に時間で決めるのなら、実際にかかった分で精算する仕組みがないと不公平でしょう。)

システムがもたらす効果・メリットによって価格が決まるようになれば、大手中小に係らず、提案書=中身で勝負できるのですが・・・・

投稿者 itleader1 : 12:25 | コメント (0) | トラックバック

2005年10月26日

恥ずかしながら、そしてREPのまとめ

こんにちは、毎週水曜日「システムとは何だ!」ブログ担当のズクダス佐藤です。

「山の写真を見せてください」との加藤先生からのリクエストにお応えして、恥ずかしながらデジカメ一眼デビュー写真を公開いたします。今朝、庭で撮ってきたばかりの一枚です。

051026paratri.jpg

あとはエントリの最後にまとめておきます。お時間のある方は見ていってください。
では前々回を思い出しつつ、本題に戻ります。

RFPのまとめ
RFPとは?

RFPとは、Request For Proposal 、提案依頼書です。自分の要求を具体的に文書にまとめたもので、注文を出す側が開発者に対してどんなシステムを造って欲しいのか、システムが実現すべき要件やクリアすべき課題は何なのか を文書化したものです。

RFPの内容

RFPには次のような内容を盛り込むべきだ とされています。

  1. システム概要
  2. 提案依頼の手続き
  3. 提案していただきたい事項
  4. 開発に関する条件
  5. 保証要件
  6. 契約事項
システム概要に書くべきこと

この中でも一番大事なのは、システムの概要です。システム概要には、次のような項目を書くことになります。

  1. システム化の背景
  2. システムの目的
  3. システムの課題と目標
  4. システムに期待する効果
RFPで一番大事なこと

難しそうですが、例の5W1Hを思い出して書けば何とかなります。特に、「Why なぜシステムを作るのか?」 と「What システムに何を求めるか?」はしっかりと考えて書いてください。

RFPで最も重要なことは、システムの目的と課題、そしてシステムがクリアすべき目標を明確にすることです。もちろん提案への手続きや提案してもらいたい事項や契約も重要ですが、まずはシステムの目的と課題、目標を明確にすることがRFPで一番大切なことなのです。

写真にもRFPが必要?

下の恥ずかしい習作を見てください。加藤先生の作品と比べて何か違うなあと思いませんか?

わずか一日の試写でしたが、これまでのように、漫然とカメラを構えて、シャッターを押しているだけでは、良い写真が取れないことを実感しました。つまり、何を撮りたいのか? どう撮りたいのか? を考えてカメラを向けないと平凡な写真しか取れない ということが分かったのです。

青空もきれいだし、ススキも逆行で光っているし、わずかながら紅葉も残っているし、浅間は初冠雪したし、車山のパラボラも見えるし・・・・などと欲張っていると、何を写したのか分からない写真になってしまいます。焦点が合ったらそのままシャッターを切っていると同じような構図になってしまいます。

ファインダーを覗いて露出を計算しピントを合わせる前に、頭の中でテーマを絞りターゲットにフォーカスすることが必要でした。

つまり写真を撮るにもRFPが必要だ!ということです。システムを発注する前に、なぜシステムが必要なのか? システムに何を求めるか? を考える必要があるのと同様に、写真もシャッターを押す前に、 何をどう撮るか?を考える必要がある ということではないでしょうか?

このことを実証するために、敢えて恥ずかしい画像を公開することにしました。 と言い訳しつつ、デジカメ一眼レフデビュー作に続きます・・・
(実は購入するまでデジタル一眼レフもコンパクトデジカメと同じように液晶画面を見て操作すると思っていました。デジタル一眼はフィルム一眼と同じで、ファインダーにしか情報は表示されないんですね)


デジカメ一眼習作 霧ケ峰にて






S051026Me.jpg S051026Shishiudo.jpg
S051026Sky.jpg
S051026KunulpFW.jpg

投稿者 itleader1 : 12:46 | コメント (2) | トラックバック

2005年10月19日

RFPは今日はお休み

こんにちは、毎週水曜日「システムとは何だ!」ブログ担当のズクダス佐藤です。
本当はRFPの作り方 その3 を書こうと思っていたのですが、今日はお休みさせてください。
ネタが切れたのか? まあ、それもありますが、今日はハイなのです。

実はデジタル一眼買っちゃいました。
加藤先生が悪いんです。私の物欲を刺激したのは加藤先生です。

木曜に先生の講習を受け、デジタル一眼に触ったとたん、眠っていた物欲がモクモクと頭をもたげ、日曜日の白馬の帰りにキタムラに寄ったのが運の尽き。店員と話し込み、カタログを手にいったんは家に帰ったのですが、昨日も今日もキタムラ通い。ついに、「あのー これください」という言葉が口から出てしまいました。

あー、買ってしまった。でも加藤先生の画像を見て、感性を刺激する とまで言われたら、買わないわけにはいきませんよね。

もともとモノ好きです。カメラも好きです。年代モノですが、銀塩=フィルムカメラの一眼レフも持っています。オートフォーカスなどという便利なものはなく、リングをくるくる回して、焦点を合わせるという、今となっては旧式なテクニックが必要なカメラです。コンパクトデジカメも持っています。スキーを撮るので、連写無制限の動画デジカメです。

高校時代は地学部で、天体写真を撮って、なぜか写真部ではなく地学部室にあった現像室でUFO写真を捏造していました。カメラ小僧になる下地はあったのですが、その後登山からスキーに移行したため、カメラは遊び程度にたしなんだくらいで、今思えばなぜ年間100日以上も山にこもっていたのにまじめな写真を撮らなかったのか!と反省したこともあります。そして加藤先生の刺激により、よーっし!また写真でも始めるか! という気持ちに至ったわけです。

正直10万円はきついな と思っていたのですが、たまたまフジのデジタル一眼風カメラが¥27,000(アマゾン)というのを見つけ、これは買いかな 乗り気になり、キタムラの店員と話すうちに、やっぱ一眼風
ではなく、一眼でないと と方針を転換しました。(画素数ではなく、CCDの大きさが重要だ!)

本来キャノン派なので、本当はNEW EOS KISS が欲しかったのですが、これは出たばかりでセットレンズつきで10万を超えます。やっぱ10万は無理だとあきらめたのですが、ふと横を見るとSDカードが使え単3電池でも動作するPentaxがセットレンズ付きでゴーキュッパではないですか。アマゾンでは¥97,000、価格コムの最安価格でも¥73,000するのに ですよ。これは買いでしょう。一晩醒まして、それでも欲しいので、今日買っちゃった という次第です。

あとはちゃんと感性を磨いて、加藤先生のようなキレイな写真を取るテクニックを身につけるだけです。でも、これが一番大事なことですね。頑張ります。

投稿者 itleader1 : 20:15 | コメント (3) | トラックバック

2005年10月12日

RFPの作り方 その2

こんにちは、毎週水曜日「システムとは何だ!」ブログ担当のズクダス佐藤です。
出張で投稿が遅くなりました。

金曜日の「なんでも座談会」に出席いただいた皆さん、お疲れさまでした。
マルタカの長谷川さん、丸光の小林さん あたたかい励ましのメール ありがとうございました。
気をよくして、「今度はHTMLこれだけハンドブックでも作ろうか」などと思っております。

さて、今回は 「RFPの作り方 その2」 RFPに何を書けばいいか です。

ITコーディネータ協会の資料によるとRFPの内容として
 1. システム概要
 2. 提案依頼の手続き
 3. 提案していただきたい事項
 4. 開発に関する条件
 5. 保証要件
 6. 契約事項
の6項目があげられています。どれも大事な項目です。でもRFPで一番大切なものは・・・・・・・

RFPを書く上で欠かせない項目
それはは 1のシステム概要 です。一般にシステムの概要には、  システム化の背景  システムの目的  システムの課題と目標  システムに期待する効果  等々を書きます。 既存システムがある場合はそれらとの関連についても書いておく必要があります。もちろん会社の組織とシステムの利用部門も必要です。 なんだか難しそうです。
5W1Hです
システム概要の書くべきことを簡単に言えば、5W1H です。小学校の作文の時間や新入社員研修で聞かされた言葉です。思い出しておきましょう。
     
  • Why なぜ
  •  
  • What 何を
  •  
  • Who 誰が
  •  
  • When いつ
  •  
  • Where どこで
  •  
  • How どうやって
これが5W1Hでした。

5W1Hをシステムに適用すると


  • Why  なぜシステムを作るのか?

  • What  システムに何を求めるのか?

  • Who  誰がシステムを使うのか?

  • When  いつシステムを使うのか?

  • Where どこでシステムを使うのか?

  • How どうやってシステムを使うのか?


となります。
この5W1Hの中でも最も肝心なのは、WhyとWhatの2点です。

「Why なぜシステムを作るのか?」 と「What システムに何を求めるか?」
Whyでシステムの目的を明確にします。そのためには、システム化の背景を説明したり、自社または既存システムの課題を整理する必要があるでしょう。課題が明確になれば、その課題をクリアするための目標が見えてきます。つまりWhat システムに求めるものがはっきりします。

RFPで最も重要なことは、システムの目的と課題、そしてシステムがクリアすべき目標を明確にすることです。もちろん提案への手続きや提案してもらいたい事項や契約も重要ですが、まずはシステムの目的と課題、目標を明確にすることがRFPで一番大切なことなのです。

投稿者 itleader1 : 23:59 | コメント (0) | トラックバック

2005年10月05日

ドンと来い! スタイルシート

こんにちは、毎週水曜日「システムとは何だ!」ブログ担当のズクダス佐藤です。

気がついたら今日は水曜日でした!このところ三連休が続いて曜日の感覚が麻痺しています。今週末もまた三連休ですし・・・・ でも、その連休前に重要なイベントがあることをお忘れではないでしょうね。

ということで今日はこれまでと話題を変えて、今週末の「なんでも座談会」について書くことにします。
スタイルシートが使えるようになりたい方は是非出席してください。出席された方には、豪華特典があります。まずはこの記事を最後まで読んでみてください。

「なんでも座談会」開催のお知らせ
9/22の研究会でみなさまにパソコンを持ってきていただき、実習を行いました。その際の疑問点やまだ完全に理解できない方、スタイルシートをどのようにホームページに生かしていくか等総合的な復習・説明を何でも座談会として行います。

10/7 (金)18:30~21:30 松本ソフト開発センターにお越しください。
パソコンは8台ありますので、ノートパソコンをお持ちくださる方は3名までとします。
お忙しい中ですが、どうぞご参加いただきますようお願いいたします。
(窪田さんの案内メールより)

今回の「なんでも座談会」は22日のフォローアップです
お知らせの通り、10月7日の「何でも座談会」は9/22の復習を中心に行います。 課題は「スタイルシート」です。

 ■22日は落ちこぼれてしまったかも・・・

 ■言われたとおりにやったが、どうも使い方がよく分からない・・・・

 ■使い方は分かったがサイトにどう反映したらいいか分からん・・・・

という方を対象に、
 1.22日にやったことの復習
 2.スタイルシート定義に関する補足
 3.スタイルシートのWebサイトへの適用方法
について、佐藤なりに説明させていただきます。

復習だけではありません。出席者には豪華特典があります!

スタイルシートを使うための分かりやすい資料を作成しました。とにかくスタイルシートを使いたい方をターゲットにした資料です。

1.最初は書き方から
  見やすさに配慮した書き方
2.どこに書けばいいか?
  SEOに有利なリンク方式
3.SEOに有利なリンク方式の見本
4.スタイリッシュなテキスト
  文字のサイズ、太さ
  字体書体、行間、テキストの位置揃え
5.サイズもいろいろ
  絶対指定と相対指定
6.ブラウザでどう見られるか?
7.色と背景
  文字の色、背景色、背景画像
  色もイロイロ
8.余白と境界線を図で理解する
  マージンとパディングの違い
9.余白を制御する
  書き方もイロイロですが・・・
10.境界線を描く
  見出しへの適用例
11.画像とテキストの回りこみ
12.タグがない!
  div と span を使い分ける
13.スタイルを局所化する
  同じタグに違うスタイルを適用したい
  クラスとIDの使い方
14.サイトへ適用する際の注意事項
  トップページと他のページのスタイル
  スタイルは少ないほどいい?
  クラス名の付け方を考える

スタイルシートの書き方から、さまざまな設定方法、イロイロあって混乱してしまう色やサイズの指定方法をまとめました。実は前回の講義で、自分自身がスタイルシートの使い方を忘れてしまったことに気づき、これはヤバイ! というので急遽作成した個人的な資料を再編集したモノです。スタイルシート経験者のノウハウと初心者の疑問が凝縮されています。

さらに、個々のスタイルの書き方は分かったが、自分のサイトに適用するにはどうすればいいか についても言及しています。クラスとIDのどちらを使えばいいか? クラスの名前はどうつけるか? 等々、経験から学んだこともまとめてみました。

出席者にはもれなく、「スタイルシートこれだけ読本」を進呈させていただきます!
書店では絶対に変えない貴重な資料です。なんでも座談会に出席してゲットしましょう。では、金曜日にソフト開発センターで。前回作成したHTMLとCSSのファイルをお忘れなく。

投稿者 itleader1 : 18:32 | コメント (2) | トラックバック

2005年09月28日

RFPに何を書けばいいか

こんにちは、毎週水曜日「システムとは何だ!」ブログ担当のズクダス佐藤です。

素人とプロの共同作業
今月は、プロに対して素人が要求を出してモノを作り上げるという点で共通している、家造りとシステムについて考えてきました。

満足できる家を造るには、どんな家が欲しいのかを設計者にキチンと伝える必要があります。形が見えないシステムの場合、家以上に要求をしっかりと設計者に伝える必要があるのではないか というのが前回の結論でした。さて、どうしたら要求をしっかりと伝えることができるのでしょうか。

RFP=提案依頼書が大事
システムの世界では発注側が自分の要求を具体的に文書にまとめたものをRFPと言います。そもそもRFPとは、Request For Proposal 、提案依頼書のことです。どんなシステムを造って欲しいのか、システムが実現すべき要件やクリアすべき課題は何なのか を文書化したものがRFPです。
RFPから始まるシステム開発
システムの発注者(=SEにとってのお客さんのことです)がこのRFPを作成し、開発者に提示します。開発者はRFPを元に提案書を作成します。発注者は提案の内容を検討して、どの会社に開発させるかを最終的に決定します。うまく自社に決定すれば(受注成立!)、その後はより詳細な打合せを経てシステム仕様書を作成し、発注者から承認を受けて、やっと製造段階へ進みます。 この長い長いシステム開発作業の第一歩がRFPです。

RFP → 提案書 → 受注先決定 → 仕様書 → 承認 → 製造へ

海か山か?
何をしたいのか分からない人には、何をしてあげても無駄です。海で泳ぎたい人を山に連れて行っても満足してはもらえないことははっきりしています。最初から海に行きたいと分かっていれば、誰も苦労して山に登ったりはしませんが、汗を流して山に登った後で、やっぱり海に行きたかったと言われては立つ瀬がありません。
イメージと違う!
RFPなしでシステムを開発することは、本当に行きたいのが海か山か分からないまま旅に連れて行くようなものです。システムが出来上がってから、「これはイメージと違う!」と言われたというような経験はSEなら誰でもあることでしょう。納品直前になってイメージと違うと言われても、もう手遅れです。あとは力関係、海千山千の勝負になります。 そもそもイメージがあるのなら、最初にそのイメージを具体的に伝えて欲しいものです。頭の中のイメージを取り出して具体化することは本人にしかできません。自分の頭の中にしかないことを他人にやって貰って、自分のイメージと一致していることなど奇跡です。
RFPに何を書けばいいか
奇跡にすがるのではなく、頭の中からイメージつかみ出し、RFPを作りましょう。RFPとは言っても難しく考えることはありません。 実は考えると難しいのですが、何といっても、「どんなRFPであってもないよりはまし」です。頭の中からイメージを引きずり出して、他人にも分かる形にしてください。要するに、「何をしたいのか?」をはっきりとした言葉にすることです。自分が何をしたいのか が言葉になればRFPは半分できたようなものです。

RFPの半分は「何をしたいか」でできている

あとの半分は、長くなったので、次回のRFPの作り方 その2 に続きます。

投稿者 itleader1 : 17:11 | コメント (0) | トラックバック

2005年09月21日

毎週水曜日「システムとは何だ!」ブログ

こんにちは、毎週水曜日「システムとは何だ!」ブログ担当のズクダス佐藤です。

町家の話しはほどほどにして、今回はなぜ 「一生に家を3回建てないと満足した理想の家は出来ない」 と言われるのか? について考えてみます。

家もシステムも、プロに対してプロ以外のひと(=素人)が要求を出してモノを作り上げるという点が共通しています。こんな家に住みたい とか こんな家を建てたい と素人が考え、それを要求としてプロに伝え、プロの技術で要求を実現したものが家になります。

素人は自分の頭の中で出来上がった我が家をイメージします。さらには、その我が家で暮らす家族との生活もイメージします。

一方、プロある大工は設計図に従って家を造ります。大工にとって実現すべきは、施主の頭の中のイメージではなく、目の前にある図面です。

そして、素人と大工をつなぐのが設計者です。設計者は素人のイメージを図面という専門用語の象徴に変換するもう一人のプロです。

素人なりに考えたイメージが設計図に反映されていないと、出来上がった家は満足できるものにはならないでしょう。

しかし、いかにプロの設計者でも、素人のイメージが文字通りイメージのままであっては設計図は書けません(多分?)。無理に書いたとしても、結果として満足できる家はできないでしょう。イメージは具体的な要求という形をとる必要があります。イメージを要求としてまとめ、設計者に伝える作業が必要になります。

「一生に家を3回建てないと満足した理想の家は出来ない」理由は、この要求に問題があるのではないでしょうか?

・要求をキチンと伝えていない
・設計者に要求が理解されていない、あるいは誤って理解された
・要求自体に問題がある、要求がバラバラだ
・要求が変化してしまった

もちろん、最初から要求に応える気がない設計者とか、要求を理解する力のない設計者などというケースがあるかもしれませんが、これは悪質業者による欠陥住宅でしょう。

幸いにして、我が家の場合、少々問題はあっても、欠陥住宅ではありませんでした。でも満足できる理想の家か?といわれると首が曲がってしまいます。

「要求はキチンと伝えた」と思います。できる限り要求は具体化しました。打合せはノートに記録しました。
「要求は理解された」と思います。プレゼンの資料も納得できるものでしたし、図面もチェックしました。図面を元に模型も作ってみました。
「要求自体に問題がある」わけではなかったと思います。検討事項はちゃんと家庭内で調整しました。検討しすぎて喧嘩になったことも度々でした。
「要求が変化してしまった」のかも知れません。変化したのは要求ですが、その原因は環境の変化です。10数年前は子供も小学生でした。一人ひとりに勉強部屋が必要でした。運動会でできるくらい広いリビングも必要でした。庭は芝生以外に考えられませんでした。考えてみれば数年の間に子供が家からいなくなることは当然のことでした。という訳で、我が家の場合、家族構成の変化を見通した要求ではなかったために、結果として今の家には満足できなくなったのでした。ローンは30年もあるのに、わずか10年の変化に対応できなかったとは残念なことです。リフォーム業界が賑やかなわけですね。

さて、以上は体験をもとに想像した建築に関する素人とプロの問題でしたが、システムではどうでしょう。
実は形が見えない分、家よりもシステムの方が問題が複雑です。同じイメージでも、家は目に見え、絵に描けるイメージですが、システムの場合は絵にも描けない難しさがあります。工法による制約も家以上ではないかと思います。トップの要求と現場の要求が食い違っていることなどは日常茶飯事です。また、要求を文書にまとめて提示してもらった経験は数えるほどしたありません。一週間前に言っていたことと反対の話しが突然出てきても何の不思議もありません。

愚痴はもうやめましょう。
最後に、「絶対に満足できるシステムなんかできるわけがない」 という条件を挙げておきます。

・要求を文書で伝えていない
・設計者に要求が理解されたかどうかチェックしていない
・要求自体に問題がある、要求が社内でまとめられていない
・要求が変化してしまった、変化を予測していない

満足できるシステムが欲しいのなら、要求は社内で取りまとめ、文書化して、提示するべきでしょう。


IT用語辞典 e-Words によると、「これまで情報システム業界では、口約束やあいまいな発注による開発現場の混乱や紛争の発生、納期の遅れやシステム障害などに悩まされてきた。事前にRFPを通じて調達条件や契約内容を明らかにしておくことで、こうした混乱を未然に防ぐことの重要性が注目されつつある。」 そうです。
IT用語辞典 e-Words RFPの説明へ

投稿者 itleader1 : 18:23 | コメント (0) | トラックバック

2005年09月14日

毎週水曜日「システムとは何だ!」ブログ

こんにちは、毎週水曜日「システムとは何だ!」ブログ担当のズクダス佐藤です。

京都から無事に帰ってまいりました。暑かった!です。でも8月に比べると、陽が落ちると少しはすごしやすく、京都も少しづつ秋に向かっていることが感じられました。次は、紅葉の頃に行きたいものです。

お約束の町家にも行ってきました。今回は祇園にしました。やっぱり、京都の町家で一杯やると落ち着きます。支払のときだけは、落ち着かなくなりましたが・・・

町家造りについて、あるいは最近ブームの町家でごはんについて興味のある方は、マピオントラベルl をご参考に。昨年の記事のようですが、「町家徹底解剖!」 「町家でごはん!」などの特集記事があります。「町家でごはん」は LeafMookの同名のムック本からの引用のようです。ちなみに、私は和食創作料理の26店中7軒に行きました。

さて本題の建築=家とシステムについてです。@ITにも “建築”と“システム構築”の類似点・共通点 というページがあります。そちらは、建築工法とシステム工法について、建売=パッケージと注文住宅=開発システム、さらには都市計画についての考察です。

確かに、家造りとシステム造りはどちらも無形から有形を作り上げる点では似ています。特に、工業製品や工芸製品などの「モノつくり」とは異なり、家もシステムもプロに対してプロ以外のひと(=素人)が要求を出してモノを作り上げるというが共通しています。そして、プロと素人による開発作業ならではの問題も共通しています。

問題として最初にあげるべきは専門用語でしょう。
プロの使う用語は素人には理解できないものがほとんどです。システムやコンピュータの用語については、花の金曜日担当の宿澤さんの「7割以上が「理解していない IT 用語使う」に書かれている通りです。

建築でも多数の専門用語が使われています。大学で土木工学をかじり、見よう見まねでハンドメイドハウスを建てたことのある私も、分からない用語がたくさんがありました。切妻、寄棟、火打ち、垂木、棟木、大引き、軒げた、小屋梁、破風、鼻隠しなどは工法関係の用語ですが、いくつ分かりましたか?

これらの用語が打合せの中で出てくると、頭が止まってしまいます。もちろん改めて説明してもらうのですが、意味が分かっても納得できていないことが多く、戸惑いは残ります。


専門用語の問題はプロと素人の間にある重要な課題です。でも、用語問題だけなら、「一生に家を3回建てないと満足した理想の家は出来ない」などというコトワザ?は生まれなかったでしょう。実際今になってもう一度家を建てるられるなら・・・・と思うことはいろいろあります。
 ・部屋が狭い
 ・収納が少ない
 ・ヘンなモダン風の家ではなく、町家造りにしておけばよかった
 ・庭に池が欲しい、露天風呂も欲しい!(これは一生無理か?)
 ・白樺なんか植えなければよかった 等々
中でも最大の失敗は「窓」です。それまで県営住宅の3階に住んでいた経験から、窓のたくさんある、明るい家に住みたい!という思いが強く、出来る限りの壁に窓を作りました。ところが敷地には限りがあります。はっきり言って狭い土地です。当然のことながら、窓の外には隣の家がありました。建てるときは自分の家のことだけを考え、周りのことを忘れていました。今となっては壁にしておけば、家具も置けるし、暑さ寒さも防げるし、と悔やまれます。

『その薄暗い光線の中にうずくまって、ほんのり明るい障子の反射を受けながら瞑想に耽り、また窓外の庭の景色を眺める気持ちは、何とも言えない』
と語っている谷崎潤一郎(『陰影礼賛』)も、京都の町家のほの暗い部屋は日本人に落ち着きを与えてくれることを知っていたのでしょう。実際京都には谷崎がひいきにした茶屋が数々あります。やっぱり京都に行ったら町家で一杯 です。

というわけで、町家に憧れつつ、家では「窓」に悩み、仕事では「窓=Windows」に悩んでいる毎週水曜日のズクダスでした。

投稿者 itleader1 : 14:00 | コメント (5) | トラックバック

2005年09月07日

毎週水曜日 「システムとは何だ!」ブログ

こんにちは、毎週水曜日「システムとは何だ!」ブログ担当のズクダス佐藤です。

前回まで、「誰にでも使えるシステムはあるのか?」という課題について、「システムとは車だ!」というテーマで進めてきました。月も変わったことだし、テーマも変えて、9月はシステムとは建築だ!というテーマでいきます。建築とってもいささか広いので、一般住宅に絞った話しを進めることにします。

12年ほど前に、家を建てました。「一生に家を3回建てないと満足した理想の家は出来ない」と言われていますが、まったくその通り。今となっては、ああして置けばよかった、何でこうなんだ と思うことばかりです。

今日も会社から帰るのに、一番心配だったことは、庭の白樺が倒れていないか? ということでした。新築と同時に植えた白樺は今や8メートル以上?に成長し、ご近所では一際高く聳え立っています。でも、カミキリ虫は来るし、アメシロにはやられるし、結構弱ってきています。だいたい庭に白樺など植える物好きはこの界隈にはいませんよね。

というところで時間が迫ってきました。明日から京都に出張です。もう準備しなくては。明日の夜は、祇園か先斗町の町家で一杯やって、建築とシステムについて考えてきます。ということで今回はここまで。あしからず。

投稿者 itleader1 : 21:18 | コメント (0) | トラックバック

2005年08月31日

毎週水曜日 「システムとは何だ!」ブログ

こんにちは、毎週水曜日「システムとは何だ!」ブログ担当のズクダス佐藤です。

システムとは車だ!」というテーマで、「誰にでも使えるシステムはあるのか?」という課題ついて考えています。前回までの結論は、「車には免許が必要だが、車を使いこなすのに必要な基本的な技術は免許を取得する過程で習得できる。システムやコンピュータには免許は必要ないが、使いこなす技術はどうやって習得すればいいのか。」というものでした。今回は、コンピュータを使いこなし、情報を活用する技術=コンピュータリテラシ、情報リテラシーについて考えてみます。

「コンピュータリテラシー」とは、コンピュータを使いこなして、読み書きする能力=キーボード・マウスを使って文字を入力し、プリンターに出力したり、CDを焼いたりする技術力=コンピュータを操作する能力であり、「情報リテラシー」とは、コンピュータだけでなく紙媒体等を含めた情報を使いこなす能力=情報を収集し、整理し、評価し、分析し、活用し、公開する力である と前回定義してみました。詳細については、IT用語辞典 e-Words  や ウィキペディア で調べてみてください。

では、コンピュータリテラシーとは具体的に何を指すのでしょうか?
コンピュータリテラシー + 小学校 をキーワードにした検索でGoogleで一位に表示された 新潟市立総合教育センター・視聴覚センターPDF資料から引用してみます。小学校のコンピュータリテラシーの指導案です。(学年で重複している内容はカットしてあります)
小学生に期待されているコンピュータの使いこなしレベルを見てみましょう。
1年
・コンピュータを起動、終了することができる。
・お絵描きソフトを使って、思い思いの絵を描くことができる。
・マウス操作をして簡単なソフトを動かすことができる。
2年
・お絵描きソフトで必要に応じて文字を入れたりすることができる。
3年
・デジタルカメラで撮影し、カメラやテレビで見ることができる。
・デジタルカメラの画像を取り込み印刷して活用することができる、。
・簡単なキーボード操作ができる。
・絵や文字を組み合わせた作品を制作することができる。
4年
・ローマ字で文字を入力することができる。
・インターネットを使ってホームページを開くことができる。
・CD-ROMを使って調べたいものを調べることができる。
・フロッピー、MOにデータを保存したり、呼び出したりすることができる
5年
・インターネットを使ってホームページを開き、必要な情報を得ることができる
 (検索エンジンの活用) スタディーノートとができる。
・絵や画像、文字を組み合わせた作品を制作することができる。
・フロッピー、MOにデータを保存したり、呼び出したりすることができる
 (フォルダ操作でデータを整理することができる。)
6年
・学習のまとめをコンピュータを使って表現し、その情報を発信したり受信したりすることができる。

皆さんは何年生までクリアできましたか?指導案とはいえ、小学生でここまでコンピュータが使えるようになれば立派なものです。

大学はどうでしょう。コンピュータリテラシのカリキュラムを検索してみました。
東邦学園大学
コンピュータリテラシー1
第1回 起動と終了、Windows入門
第2回 キーボードの使い方、タイピング練習
第3回 英文入力
第4回 日本語入力
第5回 文書作成の基礎 (1)
第6回 文書作成の基礎 (2)
第7回 電子メールの基礎 (1)
第8回 電子メールの基礎 (2)
第9回 電子メールの基礎 (3)
第10回 ちゅっと進んだ文書作成
第11回 WWWによる情報検索 (1)
第12回 WWWによる情報検索 (2)
第13回 テキストファイルと互換性
第14回 ファイルの整理
第15回 まとめ

コンピュータリテラシー2
第1回 Windowsオペレーティングシステム (復習)
第2回 ネットワークと電子メール (復習)
第3回 表を含む文書作成
第4回 ドロー図形の作成
第5回 ペイント図形の作成
第6回 文章への図形の貼り付け
第7回 表計算の基礎 (1)
第8回 表計算の基礎 (2)
第9回 グラフの作成 (1)
第10回 グラフの作成 (2)
第11回 グラフの作成 (3)
第12回 文章へのグラフの貼付け
第13回 HTML文書の作成(1)
第14回 HTML文書の作成(2)
第15回 まとめ

法政大学
前半
ネットワーク・エチケット,
電子メールの送受信,
Wordによる文書の作成(自己紹介,自宅周辺の地図など),
Excelによるグラフを作成とシミュレーション.
PowerPointによるプレゼンテーション
与えられたテーマについて発表(1人5分)
後半
Linux(ログインとログアウト,コマンドラインの操作,エディタ,ファイルとディレクトリの操作,アクセス制御,ユーザとグループ管理,ファイルシステム,シェル操作,ヒストリ操作,エリアス操作,リダイレクト操作,パイプとフィルタ機能,
LaTeX(フォント作成,文章作成,式,表作成,スタイルファイル作成,図作成(tgif),編集

少し実践的になってきました。Linixの操作が入ってくるのが大学らしい点でしょうか。

以上、長々とネットからコンピュータリテラシーの具体的内容を参照してきました。
こんな授業を受け、コンピュータを使いこなす技術をマスターした、あるいはマスターはしないまでも使ったことがあるよ という児童・生徒・学生がゾクゾクと社会に出てきたら、コンピュータが操作できることは当たり前のことになるでしょう。

もちろん今のコンピュータ教育にも、技術偏重であるとか、新しい技術についていっていないとか、教師の技術力に問題があるとか、コンピュータだけでなく情報を使いこなす技術=情報リテラシー教育こそが必要であるとか のさまざまな課題が指摘されています。しかし、少なくともキーボード入力するたびに、神経衰弱をやっている大人たちよりは有利であることははっきりしています。

今、車を運転している人は、かつて教習所に通い、少なからぬ費用と時間をかけた結果として運転ができるようになったはずです。車と同様にコンピュータは現代社会に欠かせないものになっています。車にはお金と時間をかけたはずなのに、なぜコンピュータにはお金も時間も惜しむのでしょう?

世間には多くの入門書があり、松本ソフト開発センターや松本情報創造館等の機関では、パソコン講習会が開かれています。後輩たちが学校で学んでいるように、書籍や講習会を使って、コンピュータの操作技術を習得してみてはいかがでしょうか?

投稿者 itleader1 : 14:24 | コメント (1) | トラックバック

2005年08月24日

毎週水曜日 「システムとは何だ!」ブログ

こんにちは、毎週水曜日「システムとは何だ!」ブログ担当のズクダス佐藤です。

システムエンジニアとして、「つまり、お兄さんの言いたいことは、こういうことじゃないでしょうか?」というフーテンの寅のヒロシ的な立場から、システムとは何か? システム開発の留意点や問題点について考えてみます。

システムとは車だ!」というテーマで、「誰にでも使えるシステムはあるのか?」という課題ついて考えています。

前回の結論は、「車には免許が必要だが、システムやコンピュータを使うには、何の資格も、免許も必要ない。従って、誰にでも使える車は存在しないが、誰にでも使えるシステムは存在する。」というものでした。

でも、本当に車よりシステムの方が誰にでも使えるものになっているのでしょうか?

車を使うのには免許が必要です、免許を取得していれば車を使うために最低限の技能を習得していると思われます。
もちろん、個々の車ごとの違いに慣れる必要はあります。最近の車はシフトレバーの位置もいろいろです。フロアシフトやコラムシフト、さらにはインパネシフトも流行のようです。サイドブレーキも運転席の左だけでなく、右側にあったり、足元にあったりします。でも、これらの違いに戸惑うのは最初のうちだけです。
さらに、若葉マークのドライバーは、車の流れに乗って運転するテクニックや、違反をせずに(切符を切られずに)運転するテクニックを修得する必要がありますが、一応、車を使うための基本的な技能は身についていると考えられます。細かな差異や実践的テクニックは追加して学習する必要があるにしても、免許を取得する過程で、車を使うための力は身についているということです。

では、システムとその主要な構成要素であるコンピュータについてはどうでしょう。
確かに、電気店でお金を払えばコンピュータを持つことはできます。会社で命ぜられれば情報処理システムの担当者にはなれます。でも、それは、単にコンピュータを所有した、あるいはシステム担当者の肩書きを得た ということであって、コンピュータやシステムを使うための必要条件・十分条件を満たしている訳ではありません。

コンピュータを使いこなす力を「コンピュータリテラシー」と言います。「デジタルデバイド」という言葉とともに、2000年問題の騒ぎが終わり無事21世紀を迎えた頃に話題を集めました。
「デジタルデバイド」とは、情報技術を使えるか、使えないかによって生じる社会的・経済的・地域的な格差とその格差が拡大・固定化すること を意味します。
「コンピュータリテラシー」のリテラシーとは、「識字力=読み書き能力」のことです。コンピュータリテラシーとは、コンピュータを使いこなして、読み書きする能力=キーボード・マウスを使って文字を入力し、プリンターに出力したり、CDを焼いたりする技術力=コンピュータを操作する能力のことです。
同じような用語に、「情報リテラシー」があります。こちらは、「コンピュータリテラシー」より広範囲・高度な意味で、情報を使いこなす能力=情報を収集し、整理し、評価し、分析し、活用し、公開する力のことです。

「コンピュータリテラシー」や「情報リテラシー」を身につけた人材と養成しないと、「デジタルデバイド」が拡大して、社会問題や経済問題、地域間の問題に発展してしまう! ということが問題視されたのです。デジタルデバイドについては、社会的・経済的・地域的な格差のことなので話しが少し大きくなるため置いておくとして、2000年から5年を経た現在、「コンピュータリテラシー」や「情報リテラシー」はどうなったのでしょう。システムの担当者になったり、コンピュータを購入したりするだけでは、「コンピュータリテラシー」はもとより、「情報リテラシー」が身につくわけではないことは昔も今も同じです。

次回は、「コンピュータリテラシー」と「情報リテラシー」について考えることにします。

投稿者 itleader1 : 10:28 | コメント (0) | トラックバック

2005年08月17日

毎週水曜日 「システムとは何だ!」ブログ

こんにちは、毎週水曜日「システムとは何だ!」ブログ担当のズクダス佐藤です。

システムエンジニアとして、「つまり、お兄さんの言いたいことは、こういうことじゃないでしょうか?」というフーテンの寅のヒロシ的な立場から、システムとは何か? システム開発の留意点や問題点について考えてみます。

今回のテーマは、「システムとは車だ!」 です。

システムと車は良く似ています。
今や、車のない生活は成り立たないことは明らかです。同様に、システムのない社会も成立しないでしょう。このブログで言うシステムとは、情報処理システムとその主要な要素であるコンピュータのことですが、これらがなくなった場合にどうなるか、21世紀が無事迎えられるかを世界中で心配した西暦2000年問題の騒動を思い出してください。

社会にとって重要であり、必須であるという共通点を持つシステムと車ですが、「誰にでも使えるシステムはあるのか?」という疑問はあっても、「誰にでも使える車は存在するのか?」という疑問はあまり聞いたことがありません。車は誰にでも使えるものになっているのでしょうか?

いえいえ、車は誰にでも使えるわけではありません。

車を使うには免許が必要なことは常識です。免許にもいろいろあり、お花の免許や調理師の免許もあるのに、免許といえば自動車免許を意味するほどです。免許を得るには、最低でも2週間の期間と30万弱の費用がかかります。自動車学校に通い、教官の暖かい指導に耐えて、免許を手にしたときの喜びを思い出してみてください。車を使えるようになりたい!という一心で、あの苦労を乗り越えたはずです。

一方、システムはどうでしょう。電気店でコンピュータを買ってくればコンピュータは使えます。情報処理システムも、会社から配属を命じられれば、あるいは配属を希望して受け入れられれば、今日からでもシステムの操作員です。何の資格も、何の免許も必要ありません。システムやコンピュータこそ、誰にでも使える道具なのです。

今日の結論
「車には免許が必要だが、システムやコンピュータを使うには、何の資格も、免許も必要ない。」
「従って、誰にでも使える車は存在しないが、誰にでも使えるシステムは存在する。」

何か、ちょっと違うような気がしますが、それは、また、次のお話し・・・

投稿者 itleader1 : 12:04 | コメント (0) | トラックバック

2005年08月10日

毎週水曜日 「システムとは何だ!」ブログ

こんにちは、ズクダス佐藤です。
今日から毎週水曜日の フロム「ずくだす」を担当することになりました。よろしくお願いします。

本業は、システムエンジニアとしてシステムの企画・設計・開発から製造まで担当しています。システムを開発していく中で、自分の作ったシステムは本当にお客さまの役に立っているのか? お客さまの要望どおりに作ったシステムが最高のシステムなのか? という疑問にぶつかり、経営的な視点からシステムの提案をするために、中小企業診断士の資格も取得しました。

このブログでは、仕事上の経験を元に、

つまり、お兄さんの言いたいことは、こういうことじゃないでしょうか?

というフーテンの寅さんのヒロシ的な立場から、システムとは何か? システム開発の留意点や問題点 について書いていきたいと思います。題して、「システムとは何だ!」ブログです。

 「わが社もシステムを導入して業務を効率化したい!」
 「古いシステムをそろそろバージョンアップしようか?」
 「どうしてウチのシステムは使いづらいんだ!」
 「システムエンジニアはいったい何を考えているんだ!」
などとお考えの社長さん、システム担当者の方は、よりよいシステムを構築するために、あるいは後悔しないために、またシステムとシステムエンジニアを理解するためにも、是非毎週水曜日の「システムとは何だ」ブログをお読みください。

さて、システムエンジニアとして打ち合わせの席でお客さまから最初に言われることが、「使いやすいシステムにして欲しい」 「すぐに使えるシステムが欲しい」 ということです。
どうもシステムは使いづらく、使えるようになるまでに時間がかかる という定説があるようです。逆に言うと、誰にでも、すぐ使えるシステムがあれば、ソフトハウスとして売上倍増、収益増大が実現できるわけです。

そこで次回からのシリーズとして、「誰にでも使えるシステムは本当にあるのか?」について考え、売上倍増、収益増大の可能性を探ってみることにします。 

次回水曜日のテーマは 「システムとは車だ!」 です。

投稿者 itleader1 : 17:22 | コメント (1) | トラックバック