ログイン
ユーザ名:

パスワード:


パスワード紛失

新規登録
メインメニュー
オンライン状況
1 人のユーザが現在オンラインです。 (1 人のユーザが Qアーカイブス を参照しています。)

登録ユーザ: 0
ゲスト: 1

もっと...

Qアーカイブス

Qの全ML(メーリングリスト)を閲覧できます

全体ML(1)

 From: shogowatanabe@

Date: 2001年2月27日(火) 午後1時05分
Subject: 提案− nam プロジェクトの方向性1


    namプロジェクトチーム・メンバーのみなさん


こんにちは,namプロジェクトチーム代表の西部です。

積極的にこのプロジェクトに参加していただき,ありがとうございます。

遅くなりましたが,ようやく以下のメンバーでnamプロジェクトチームを発足することに
なりました。どうぞよろしくお願いします。


今回namプロジェクトチームのMLをeGroupsにnam-projectという名前で作りました。eGrou
psには,通し番号は付いていませんが,フォルダ共有,投票,スケジューラーなどプロジ
ェクトの進行に不可欠な機能が付いているからです。


当MLは,スレッド方式を採用します。タイトルをスレッドごとに分類し,それに通し番号
を付けるというものです。


スレッド分類は,


討議

提案

連絡と報告

自己紹介

質問

チャット


などで,Subjectを「スレッド分類」+「−」+「タイトル」+「通し番号」とします。


たとえば,このメールでは「提案−namプロジェクトの方向性1」となっています。これ
に続けて投稿する場合には,次の人が「提案−namプロジェクトの方向性2」などとして
返信します。


namプロジェクトチームは,NAMにLETSを導入することを目的とします。namはNAMのLETSで
流通する地域通貨の名称ないし通貨単位です。予定では,3月末までにネットワーク型LE
TSを実現するソフトウェアGETSをサーバー上に実装し,NAMの前会員,各関心系,地域系
,階層系,協力団体などの口座を設定するつもりでしたが,スタートが遅れましたので,
もう少し後にずれ込むでしょう。


参加メンバーは以下の通りです。応募していただいたメンバーの他,柄谷NAM代表,高瀬N
AMセンター事務局代表にも参加していただいております。総勢11名です。


◆namプロジェクトメンバー


西部忠nishibe@e... NAM-LETS代表,NAM北海道

鈴木健 ken@s... GETS開発者,NAM-LETS,NAM東京

岡崎乾二郎okazaki-park@j... NAM芸術代表,NAM東京?

鈴木泰生 fwih0677@m...コンピュータ,NAM東京

阪口弘人sakaguchi@h... NAMコンピュータ,NAM東京

穂積一平ipfr_cat@d... NAMコンピュータ,NAM大阪

宮地剛afake908@o...  NAM-LETS,NAM大阪

湯本裕和yumoto@h... NAM教育,NAM名古屋?

渡辺彰吾shogowatanabe@n...
NAM-LETS,コンピュータ,芸術,NAM大阪

柄谷行人 <color><param>0080,0000,0080</param>krtn@b...</color>
NAM代表,NAM大阪

高瀬幸彦 LEQ04254@n... NAMセンター事務局代表,NAM東京


NAM地域系がはっきりしなかった方には「?」を付けています。私の方にみなさんから自己
紹介,プロジェクトへの抱負,可能な貢献などについてメールをいただいていますが,改
めてここで各自で自己紹介していただけますか。いただいたメールの内容+αで結構です
。時間がなくプロジェクトには積極に参加できないが,意見を述べたい,オブザーバーと
して参加したい,という方は,その旨を書き添えて下さい。今後のプロジェクトの進行過
程でメンバーがどの地域に住んでいるかも重要になりますので,加入している地域系をご
確認下さい。


私は,プログラム言語は全くの素人でC++がまあできるくらいですので,あまりソフト開
発のための戦力にはなりません。それに,札幌に住んでいるので,サーバー管理や実際の
運営にも携わるのは難しいと思います。プロジェクト全体のコーディネーターとして,ま
た,LETSの運営や規約づくり,スキームづくりの面で貢献したいと思います。どうぞよろ
しく。


いくつかの提案があります。


1)まず最初に,GETSの開発者鈴木健さんに副代表をお願いしたいのですが,鈴木健さん
,みなさん,いかがでしょうか。


2)namプロジェクトの内容は次のように大きく二つに分けられます。


●技術/管理→GETSのNAM向け仕様開発/実装(サーバー設置)/システム管理/サポー
ト体制


●運営/規約→namに関する当プロジェクトチームにおける意志決定/プロジェクト進行
/運営上規約作成/namファンドなどスキームの検討


スレッドを付けるときには,「技術/管理」か「運営/規約」かを明示するとわかりやす
いでしょう。また,各メンバーをどちらかのプロジェクト内容に主に従事するするように
したいと思いますがどうでしょうか。特に,開発に必要なプログラム言語ができるメンバ
ーは「技術/管理」に入っていただきたいと思います。どちらに主に属したいかも自己紹
介で述べて下さい。


3)運営/規約については,次のように進めていきたいと思います。


・プロジェクトチームとしての意思決定を要する「提案」や「討議」に関しては私が議長
を務めます。意思決定は一定期間(これは随時指定します)をとって特に反論がない場合
には原案(最初の提案)が承認されたものと考えます。

・特に,議論が分かれ,議決を要する場合には投票機能を利用することとします。その場
合,各人が一票を投票し,同数の場合には議長が判断します。

・「連絡と報告」「自己紹介」「質問」「チャット」は自由トークで結構です。

・私も投票機能については詳しくないので,どなたか使い方を解説していただけますか。
ついでに,スケジューラーの使い方,共有フォルダの使い方も教えていただけると助かり
ます。


4)技術/管理については,鈴木健さんから提案していただきたいと思います。よろしく。


みなさん,自己紹介をお願いします。

 

 

*西部さんのパソコンからメッセージを送信するとWeb上では文字化けするので、
代わりに渡辺がWebからメッセージを送信しました。


 5 From: yumoto  <yumoto@
Date: 2001年2月27日(火) 午後1時42分
Subject: 自己紹介-湯本裕和1


    湯本裕和です。

副代表を鈴木さんにお願いすること、賛成です。

(自己紹介)
わたしの所属する関心系は NAM 農業、地域系は NAM 中部に訂正お願い
します。

エディターやリレーショナルデータベースのアプリケーションは使いこん
でいると思いますが、C などを使ってソフトを書く経験はありません。

nam プロジェクトでは、運営/規約 に参加を希望します。今後にむけ、
nam を育て活用していくために必要な、いろいろの工夫をしてみたいと
思います。

メールでの参加が中心になると思います。メールでできる作業は能力の及
ぶかぎり、お引き受けするつもりです。どうぞよろしく。

yumoto hirokazu <yumoto@h...>


 6 From: Makoto Nishibe  <nishibe@

te: 2001年2月27日(火) 午後3時00分
Subject: Re: [nam-project] 自己紹介- 湯本裕和2


    西部です。

早速の自己紹介ありがとうございます。
わたしも名古屋,正確には春日井出身です。
どうぞよろしく。

> (自己紹介)
> わたしの所属する関心系は NAM 農業、地域系は NAM 中部に訂正お願い
> します。
>
> エディターやリレーショナルデータベースのアプリケーションは使いこん
> でいると思いますが、C などを使ってソフトを書く経験はありません。
>
> nam プロジェクトでは、運営/規約 に参加を希望します。今後にむけ、
> nam を育て活用していくために必要な、いろいろの工夫をしてみたいと
> 思います。
>
> メールでの参加が中心になると思います。メールでできる作業は能力の及
> ぶかぎり、お引き受けするつもりです。どうぞよろしく。
>
> yumoto hirokazu <yumoto@h...>
>
>
> Help URL   : http://help.egroups.co.jp/
> Group URL  : http://www.egroups.co.jp/group/nam-project/
> Group Owner: mailto:nam-project-owner@e...

 

***********************************************
  西部 忠 NISHIBE, Makoto
  北海道大学大学院経済学研究科
  e-mail: nishibe@e...
  Homepage: http://www.econ.hokudai.ac.jp/~nishibe/
***********************************************


 7 From: Makoto Nishibe  <nishibe@>
Date: 2001年2月27日(火) 午後3時24分
Subject: 連絡−eGroupsWEB 上の文字化け


    西部です。

私が前回投稿した提案はeGroupsのWEB上で見ると文字化けしています。
原因はまだ不明ですがサーバー側の設定によると思われるので,対応してもらうよう
連絡します。

みなさんのところへ直接配信されるメール自体は文字化けしていないとのことですか
ら,そちらをご覧下さい。


***********************************************
  西部 忠 NISHIBE, Makoto
  北海道大学大学院経済学研究科
  e-mail: nishibe@e...
  Homepage: http://www.econ.hokudai.ac.jp/~nishibe/
***********************************************


 8 From: shogowatanabe@
Date: 2001年2月27日(火) 午後4時30分
Subject: 連絡− eGroupsWEB 上の文字化け 2


    渡辺彰吾です。

「eGroupsWEB 上の文字化け」についてe-groupに問いあわせてみたところ、
eグループ サポートチームの輿水さんから以下のような報告がありました。


eグループ サポートチームの輿水です。
平素はeグループをご利用頂きまして、誠にありがとうございます。

この度は、ご迷惑おかけ致しまして誠に申し訳ございません。

これは、先日のバージョンアップで過去メッセージの表示の高速化を行なった
際の処理に問題があるため発生している現象です。

保存されているメッセージ自体は文字化けしている訳ではございませんので、
近日中に修正を実施する予定です。ご迷惑お掛け致しますが、なにとぞご容赦
くださいませ。


 9 From: ippei hozumi  <ipfr_cat@d5.>
Date: 2001年2月27日(火) 午前11時57分
Subject: Re: [nam-project] 自己紹介-穂積一平


    穂積一平です。

副代表を鈴木さんにお願いすること、わたしも賛成します。

(自己紹介)
小学校の頃から自己紹介というと、とにかく嫌で嫌で、なにを言え
ばいいのかわからない、という経験をしてきましたが、いいおじさ
んになってしまうと、さすがに嫌ということはありませんが、なに
を言えばいいのかわからない状況に変化はありません。

NAMに入って、やたら自己紹介をする機会が多くて困っていますが、
困りついでにというのも変ですが、西部さんに送ったメールで、こ
こはご勘弁のほどを。

-------------------------------------------------
大阪在住の穂積一平といいます。

NAMではNAMコンピュータに参加しています。

NAM事務局のほうでちょっと登録のプログラム作成の手伝いなど
をしています。

自己紹介ということですが、NAMコンピュータの東京の阪口さん
というひとと次のような文章を書いています。いちどご覧ください。

http://home.interlink.or.jp/~ipfr_cat/nam/aboutml.html

これは便宜上わたし個人のサイトですが、とりあえずここにアップ
しています。題名は「サイバースペースとML」というもので、メ
ールなどインターネットのツールについての分析とソフトの提案で
す。NAMに対する考えやわたしの想いや願いといったものは、こ
の文章から読みとっていただけるのではないかと思います。

コンピュータ関係の経歴や技術面での自己紹介は、

http://home.interlink.or.jp/~ipfr_cat/

を見てください。それとすこしまえからLINUX JAPANと
いう雑誌にFPCというフリーのパスカルコンパイラの記事を連載
で書いています。(宣伝です)

よろしくお願いします。

--------------------------------------------------
というようなわけでして、文面中の東京の阪口さんというのは、こ
のMLにも参加している阪口弘人さんのことです。

いちおう、技術/管理ということでお願いします。

------------------------------------------------
穂積一平

mailto:ipfr_cat@d...
homepage: http://home.interlink.or.jp/~ipfr_cat

------------------------------------------------


> わたしの所属する関心系は NAM 農業、地域系は NAM 中部に訂正お願い
> します。
>
> エディターやリレーショナルデータベースのアプリケーションは使いこん
> でいると思いますが、C などを使ってソフトを書く経験はありません。
>
> nam プロジェクトでは、運営/規約 に参加を希望します。今後にむけ、
> nam を育て活用していくために必要な、いろいろの工夫をしてみたいと
> 思います。
>
> メールでの参加が中心になると思います。メールでできる作業は能力の及
> ぶかぎり、お引き受けするつもりです。どうぞよろしく。
>
> yumoto hirokazu <yumoto@h...>
>
>
> Help URL   : http://help.egroups.co.jp/
> Group URL  : http://www.egroups.co.jp/group/nam-project/
> Group Owner: mailto:nam-project-owner@e...
>
>
>


穂積一平
ipfr_cat@d...

http://home.interlink.or.jp/~ipfr_cat/


 10 From: おかざき けんじろう  <okazaki-park@>
Date: 2001年2月27日(火) 午後10時54分
Subject: Re: 自己紹介-湯本裕和


    はじめまして。
 芸術系  地域系 東京 の岡崎乾二郎です。
みなさん よろしく
 
 副代表を鈴木さんにお願いすること、賛成です。

以下西部さんに送付したものと 同内容ですが自己紹介に代えさせていただき
ます。 

 僕がnam(LETS)に期待しているのは、本来、資本制経済になじまない(商品化しがたい)、
 よって現在その活動は実際上、ほとんど国家を中核とした公的な助成金あるいは企業からの援助
 (メセナ!) で支えられていることの多い活動━━具体的には芸術活動や、学術(科学)研究
 という、いわゆる文化消費/生産の形態を、国家でも資本でも、
 共同体原理(モリス以来の芸術家村幻想)でもない、nam(LETS)およびそれが生成するだろうネットワーク
 によって支える可能性 です。
 
 一言でいって
 NAM の活動を通過させることによって、優秀な創造性が国家や資本に回収されることなく、 
 その語の本来的な意味で、自在に多方向に『流出』し、アソシエートしあうような状況が出現させることをめざす。
  
  現在時点での資本制交換に還元されえない先端的活動(未来への投機?)を保護することは、
 そのシステムそれ自体(国家)の正当性(交換不能性)を確保すること と
 密接につながっていると思えます。その意味でそのシステムにとって、未来への投機はその過去(起源)
 からの自己同一性を保持するというのと同じ意味をもっている。ここにおいて
 投機は、保存(伝統)と繋がる(繋げるのは、消費形態の創出=生産となるような、文化と呼ばれるもの
 のきわめて特異な振るまい方です)。
 とくに国家がその存在根拠として『歴史の持続性』を表出し、
 その表出を支配する権利を支配しょうとするとき、芸術と呼ばれる概念に
 付加されてきた『性格』が、もっとも重要な仕掛けとして働きだすことは
 よく観察されることです。

 つまり これらの活動をNAMに 流出させる

 
 賞や、研修、奨学金という名称での、生活援助、研究補助金の給付制度(際たるものは人間国宝、文化勲章ですが)
 など nam(LETS) によって置換できそうな仕組みは多いし、
 美術館や図書館などの公共機関を 個人所有物を連携させたネットワークによって置換することも可能だとも思います
(音楽流通においてNapster,や MactellaのようなP2Pソフトが可能にしたように、個々のメンバーが所有するデータ
 ━━テキスト、芸術品を、メンバー全員が 自由に使用可能になる状況を作り出す)
 アイデア(思い付き)は たくさんあるのですが
 (すでに実験ずみのプロジェクトもあります)、
 
 ともかくも研究、勉強の機会としてもプロジェクトには期待しています。

 岡崎乾二郎


 

 


 


 11 From: おかざき けんじろう  <okazaki-park@>
Date: 2001年2月27日(火) 午後11時21分
Subject: Re: 自己紹介岡崎 


    文字化けがひどいので再送いたします

はじめまして
芸術系 地域系東京の岡崎乾二郎です。
みなさん よろしく

副代表 鈴木氏とすることに同意いたします


 僕がnam(LETS)に期待しているのは、本来、資本制経済になじまない(商品
化しがたい)、よって現在その活動は実際上、ほとんど国家を中核とした公
的な助成金あるいは企業からの援助(メセナ!) で支えられていることの
多い活動━━具体的には芸術活動や、学術(科学)研究という、いわゆる文
化消費/生産の形態を、国家でも資本でも、共同体原理(モリス以来の芸術
家村幻想)でもない、nam(LETS)およびそれが生成するだろうネットワークに
よって支える可能性 です。
 
 一言でいってNAMの活動を通過させることによって、優秀な創造性が国家や
資本に回収されることなく、その語の本来的な意味で、自在に多方向に『流
出』し、アソシエートしあうような状況が出現させることをめざす。

  
現在時点での資本制交換に還元されえない先端的活動(未来への投機?)を
保護することは、そのシステムそれ自体(国家)の正当性(交換不能性)を
確保すること と密接につながっていると思えます。その意味でそのシステ
ムにとって、未来への投機はその過去(起源)からの自己同一性を保持する
(起源を確保する)というのと同じ意味をもっている。ここにおいて投機は、
保存(伝統)と繋がる(繋げるのは、消費形態の創出=生産となるような、
文化と呼ばれるもののきわめて特異な振るまい方です)。

 とくに国家がその存在根拠として『歴史の持続性』を表出し、その表出を
支配する権利を支配しょうとするとき、芸術と呼ばれる概念に付加されてき
た『性格』が、もっとも重要な仕掛けとして働いてきたことはよく観察され
ることです。

 つまり これらの活動をNAMに 流出させる。
たとえば さまざまなる、賞や、研修、奨学金という名称での、生活援助、
研究補助金の給付制度(際たるものは人間国宝、文化勲章ですが)など。
これらはすべてnam(LETS) によって置換できるだろう制度だろうと考えら
れます。
また 美術館や図書館などの公共機関を 個人所有物を連携させたネット
ワークによって置換することも可能だとも思います
(音楽流通においてNapster,や MactellaのようなP2Pソフトが可能にした
ように、個々のメンバーが所有するデータ ━━テキスト、芸術品を、メ
ンバー全員が 自由に使用可能になる状況を作り出す)
 
アイデア(思い付き)は たくさんあるのですが
ともかくは勉強と研究の契機だけ与えられることを期待しています
 


 岡崎乾二郎


 12 From: Makoto Nishibe  <nishibe@>
Date: 2001年2月28日(水) 午前0時30分
Subject: Re: [nam-project] 自己紹介- 穂積一平2


    西部です。

> (自己紹介)
> 小学校の頃から自己紹介というと、とにかく嫌で嫌で、なにを言え
> ばいいのかわからない、という経験をしてきましたが、いいおじさ
> んになってしまうと、さすがに嫌ということはありませんが、なに
> を言えばいいのかわからない状況に変化はありません。

穂積さん,これはきっとみんな同じですよ。

> NAMに入って、やたら自己紹介をする機会が多くて困っていますが、
> 困りついでにというのも変ですが、西部さんに送ったメールで、こ
> こはご勘弁のほどを。

何度も自己紹介をさせてしまい,すいません。
いただいたメールをそのまま張り付けることも考えたのですが,
やはり初めにご自分でなんか書いてもらった方がいいかなと。

技術/管理がメインということでよろしいですね。
有力なプログラマとして。

どうぞよろしく。

> -------------------------------------------------
> 大阪在住の穂積一平といいます。
>
> NAMではNAMコンピュータに参加しています。
>
> NAM事務局のほうでちょっと登録のプログラム作成の手伝いなど
> をしています。
>
> 自己紹介ということですが、NAMコンピュータの東京の阪口さん
> というひとと次のような文章を書いています。いちどご覧ください。
>
> http://home.interlink.or.jp/~ipfr_cat/nam/aboutml.html
>
> これは便宜上わたし個人のサイトですが、とりあえずここにアップ
> しています。題名は「サイバースペースとML」というもので、メ
> ールなどインターネットのツールについての分析とソフトの提案で
> す。NAMに対する考えやわたしの想いや願いといったものは、こ
> の文章から読みとっていただけるのではないかと思います。
>
> コンピュータ関係の経歴や技術面での自己紹介は、
>
> http://home.interlink.or.jp/~ipfr_cat/
>
> を見てください。それとすこしまえからLINUX JAPANと
> いう雑誌にFPCというフリーのパスカルコンパイラの記事を連載
> で書いています。(宣伝です)
>
> よろしくお願いします。
>
> --------------------------------------------------
> というようなわけでして、文面中の東京の阪口さんというのは、こ
> のMLにも参加している阪口弘人さんのことです。
>
> いちおう、技術/管理ということでお願いします。
>
> ------------------------------------------------
> 穂積一平
>
> mailto:ipfr_cat@d...
> homepage: http://home.interlink.or.jp/~ipfr_cat
>
> ------------------------------------------------
>
>
> > わたしの所属する関心系は NAM 農業、地域系は NAM 中部に訂正お願い
> > します。
> >
> > エディターやリレーショナルデータベースのアプリケーションは使いこん
> > でいると思いますが、C などを使ってソフトを書く経験はありません。
> >
> > nam プロジェクトでは、運営/規約 に参加を希望します。今後にむけ、
> > nam を育て活用していくために必要な、いろいろの工夫をしてみたいと
> > 思います。
> >
> > メールでの参加が中心になると思います。メールでできる作業は能力の及
> > ぶかぎり、お引き受けするつもりです。どうぞよろしく。
> >
> > yumoto hirokazu <yumoto@h...>
> >
> >
> > Help URL   : http://help.egroups.co.jp/
> > Group URL  : http://www.egroups.co.jp/group/nam-project/
> > Group Owner: mailto:nam-project-owner@e...
> >
> >
> >
>
>
> 穂積一平
> ipfr_cat@d...
>
> http://home.interlink.or.jp/~ipfr_cat/
>
>
>
> Help URL   : http://help.egroups.co.jp/
> Group URL  : http://www.egroups.co.jp/group/nam-project/
> Group Owner: mailto:nam-project-owner@e...

 

***********************************************
  西部 忠 NISHIBE, Makoto
  北海道大学大学院経済学研究科
  e-mail: nishibe@e...
  Homepage: http://www.econ.hokudai.ac.jp/~nishibe/
***********************************************


 13 From: Makoto Nishibe  <nishibe@>
Date: 2001年2月28日(水) 午前0時51分
Subject: 討議−MLの傍聴


    西部です。

namプロジェクトには参加できないが,ぜひ傍聴させて欲しいという方がいたのです
が,どうしましょうか。もちろん,NAMの会員です。

近々namプロジェクトを開始したという報告とメンバーの紹介のために,センター事
務局から会員全員にメールを送ってもらおうと思いますが,その時,傍聴可と書こう
かどうか迷っています。

傍聴できるということは共有フォルダにもアクセスできるわけですね。今後,そこに
何らかのファイルをおくことを考えると,プロジェクトの情報公開は必要だと思いま
すが,namが稼働するまではクローズでもいい気がします。いかがでしょう。

 

***********************************************
  西部 忠 NISHIBE, Makoto
  北海道大学大学院経済学研究科
  e-mail: nishibe@e...
  Homepage: http://www.econ.hokudai.ac.jp/~nishibe/
***********************************************


 14 From: Makoto Nishibe  <nishibe@>
Date: 2001年2月28日(水) 午前0時51分
Subject: Re: [nam-project] Re: 自己紹介- 湯本裕和


    こんばんは,西部です。

岡崎さんが作ってくれたNAMの図,すごくわかりやすくていいですね。

namの循環やnamファンドなどの図も書いていただけれるのではと期待しています。

技術/管理か運営/規約か,どちらをメインにされますか。
メインといってももちろん全メンバーに両方に関わっていただきますが。

よろしくお願いします。

鈴木健さん,まだ登場してもらえませんか?

At 1:54 PM +0000 01.2.27, おかざきけんじろう wrote:
> はじめまして。
>  芸術系  地域系 東京 の岡崎乾二郎です。
> みなさん よろしく
>
>  副代表を鈴木さんにお願いすること、賛成です。
>
> 以下西部さんに送付したものと 同内容ですが自己紹介に代えさせていただき
> ます。 
>
>  僕がnam(LETS)に期待しているのは、本来、資本制経済になじまない(商品化しがた
>い)、
>  よって現在その活動は実際上、ほとんど国家を中核とした公的な助成金あるいは企業
>からの援助
>  (メセナ!) で支えられていることの多い活動━━具体的には芸術活動や、学術(
>科学)研究
>  という、いわゆる文化消費/生産の形態を、国家でも資本でも、
>  共同体原理(モリス以来の芸術家村幻想)でもない、nam(LETS)およびそれが生成す
>るだろうネットワーク
>  によって支える可能性 です。
>  
>  一言でいって
>  NAM の活動を通過させることによって、優秀な創造性が国家や資本に回収されるこ
>となく、 
>  その語の本来的な意味で、自在に多方向に『流出』し、アソシエートしあうような状
>況が出現させることをめざす。
>   
>   現在時点での資本制交換に還元されえない先端的活動(未来への投機?)を保護す
>ることは、
>  そのシステムそれ自体(国家)の正当性(交換不能性)を確保すること と
>  密接につながっていると思えます。その意味でそのシステムにとって、未来への投機
>はその過去(起源)
>  からの自己同一性を保持するというのと同じ意味をもっている。ここにおいて
>  投機は、保存(伝統)と繋がる(繋げるのは、消費形態の創出=生産となるような、
>文化と呼ばれるもの
>  のきわめて特異な振るまい方です)。
>  とくに国家がその存在根拠として『歴史の持続性』を表出し、
>  その表出を支配する権利を支配しょうとするとき、芸術と呼ばれる概念に
>  付加されてきた『性格』が、もっとも重要な仕掛けとして働きだすことは
>  よく観察されることです。
>
>  つまり これらの活動をNAMに 流出させる
>
>  
>  賞や、研修、奨学金という名称での、生活援助、研究補助金の給付制度(際たるもの
>は人間国宝、文化勲章ですが)
>  など nam(LETS) によって置換できそうな仕組みは多いし、
>  美術館や図書館などの公共機関を 個人所有物を連携させたネットワークによって置
>換することも可能だとも思います
> (音楽流通においてNapster,や MactellaのようなP2Pソフトが可能にしたように、個
>々のメンバーが所有するデータ
>  ━━テキスト、芸術品を、メンバー全員が 自由に使用可能になる状況を作り出す)
>  アイデア(思い付き)は たくさんあるのですが
>  (すでに実験ずみのプロジェクトもあります)、
>  
>  ともかくも研究、勉強の機会としてもプロジェクトには期待しています。
>
>  岡崎乾二郎
>
>
>  
>
>
>
>
>  
>
>
>
>
>
>
>
>
>
> Help URL   : http://help.egroups.co.jp/
> Group URL  : http://www.egroups.co.jp/group/nam-project/
> Group Owner: mailto:nam-project-owner@e...

 

***********************************************
  西部 忠 NISHIBE, Makoto
  北海道大学大学院経済学研究科
  e-mail: nishibe@e...
  Homepage: http://www.econ.hokudai.ac.jp/~nishibe/
***********************************************


 15 From: Ken Suzuki  <ken@>
Date: 2001年2月27日(火) 午後11時48分
Subject: 自己紹介−鈴木健1


    こんにちは。鈴木です。
登場します。>西部さん

ぼくも自己紹介苦手なんで、短めに。
ぼくのコミュニティ通貨やLETSについての思いは、
http://sacral.c.u-tokyo.ac.jp/~ken/gets/tamatebako.html
でまとめましたのでお読みください。4万5千字くらいありますが。
5分の2を削ったNAM editionが
http://sacral.c.u-tokyo.ac.jp/~ken/gets/tamatebakoNAM.html
でよめます。これは4月に出版予定のリーフレットに掲載されるそうです。
たぶん、これが何よりの自己紹介になるでしょう。

リアルな世界では、大学院の博士課程1年です。
研究室は複雑系・人工生命をやってます。
脳や認知の問題(特に自我、自己意識)を力学系でモデル化しようという
あやしい研究に取り組んでいます。目下のテーマはメタ学習ですかね。

さて、副代表とのことですが、恐らくGETSの開発におわれて事務的な作業
はほとんどできないと思います。開発はNAMのみに肩入れするわけにはいきま
せんので中立的にやっていきますよ。みなさんのサポートがあれば可能とは
思いますが、できるだけ早期に他の方(たぶん技術系の貢献をしていただける
方)にお譲りするのが一番でしょう。それまでのつなぎということでしたら、
喜んでやらせていただきたいと思います。


 16 From: SAKAGUCHI Hirohito  <sakaguchi@>
Date: 2001年2月28日(水) 午前1時19分
Subject: Re: [nam-project] 自己紹介-阪口弘人1


    阪口弘人です。

--------------------------------------------
【西部さん提案への回答】
1) 鈴木健さんの副代表就任の件
賛成します。

2) 主に従事するプロジェクト内容
技術/管理

3) 運営/規約の進め方
了解しました。

--------------------------------------------
【自己紹介】

東京から参加してます阪口弘人です。

三年前に自分たちで立ち上げたソフトハウスでシステムを開発していま
す。現在36歳です。
主に関わっている関心系はコンピュータ/インターネットです。


みなさん自己紹介が苦手ということで短めですが、今回私はオブザーバー
的な参加とさせていただきたいと考えていまして、そのため少々後ろめ
たい気持ちを持っています。
その後ろめたさが言い訳を誘発して、長くなってしまいました(^^)
決して自己紹介が得意ということではありません。

オブザーバーとして参加したいと思った理由は二点あります。

まず第一にアップの時期である(あった)3月末までは私の本業が極め
て忙しくなることが確実で、手を挙げたものの、まともに関われない可
能性が高いからです。

次に、私の現在の関心が、namやLETSとは若干ずれた位置にあることで
す。穂積さんの自己紹介にも記載されているサイトをご覧いただければ
大体の関心の中心を理解していただけるかと思います。
要するにNAMのコミュニケーションシステムどうにかしたい、というの
が私の関心の第一になります。
さらにはセンター事務局の会員管理システムや事務処理全般のシステム
化についても関わっているので、本業との絡みもあって、とても手が回
りそうにない、というのが正直なところです。

そんな事情なので、当初はnamプロジェクトへの参加を見合わせていた
のですが、考えてみると、[コミュニケーション・システム]や[会員管
理システム]は、いずれもGETSシステムを無視して考えることができま
せん。

GETSでは、まず確実にユーザー認証の問題やユーザー登録、更新、削除
などのプログラムが実装されると思われますが、将来的にはNAMの[会員
管理システム]と連動してゆくものだと考えています。
現在具体的な像を結んでいるわけではありませんが、[コミュニケーショ
ン・システム]も同様に連動してゆくであろうと思われます。

また、これらのシステムの運用についても、専任スタッフを持たず、輪
番制という形で運用系が移ってゆくNAMにおいては、少ない上に、熟練
があまり期待できない人的資源で、如何に効率的に運用するかが、非常
に重要な問題になると思われます。
その意味でもGETSプロジェクトがどのように設計/実装されるのかを知っ
ておかないと、NAMの各システム間に隙間が生まれる可能性が高いと考
えます。
そしてこれは、すなわち事務作業をする人の負担が増えることを意味し
ますから、看過しずらい問題です。

私もオブザーバーとは言いながら、質問や意見を述べる事があるかとは
思います。そのとき若干みなさんとは方向性が違う可能性がありますが、
基本スタンスは上記のようなものですので、ご理解いただきたいと思い
ます。

(といいつつ仕事が落ち着いたら、首を突っ込んでくるかもしれません。
その時はその時でどうか寛大に受け入れてやってください。)

それでは。

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
      阪口 弘人( SAKAGUCHI,Hirohito )
      関心系:コンピューター/理論/芸術
      地域系:東京
      その他:1964年生まれ/男
      E-mail sakaguchi@h...

 

From: Makoto Nishibe  <nishibe@>
Date: 2001年2月28日(水) 午前4時55分
Subject: Re: [nam-project] 自己紹介−鈴木健2


    こんばんは,西部です。

> 登場します。>西部さん

どうも。

> ぼくも自己紹介苦手なんで、短めに。
> ぼくのコミュニティ通貨やLETSについての思いは、
> http://sacral.c.u-tokyo.ac.jp/~ken/gets/tamatebako.html
> でまとめましたのでお読みください。4万5千字くらいありますが。
> 5分の2を削ったNAM editionが
> http://sacral.c.u-tokyo.ac.jp/~ken/gets/tamatebakoNAM.html
> でよめます。これは4月に出版予定のリーフレットに掲載されるそうです。
> たぶん、これが何よりの自己紹介になるでしょう。

相対値貨幣について,他の人はどういうコメントをするかも楽しみですね。

> リアルな世界では、大学院の博士課程1年です。
> 研究室は複雑系・人工生命をやってます。
> 脳や認知の問題(特に自我、自己意識)を力学系でモデル化しようという
> あやしい研究に取り組んでいます。目下のテーマはメタ学習ですかね。

池上さんは君のことどう見てるのかな。

> さて、副代表とのことですが、恐らくGETSの開発におわれて事務的な作業
> はほとんどできないと思います。開発はNAMのみに肩入れするわけにはいきま
> せんので中立的にやっていきますよ。みなさんのサポートがあれば可能とは
> 思いますが、できるだけ早期に他の方(たぶん技術系の貢献をしていただける
> 方)にお譲りするのが一番でしょう。それまでのつなぎということでしたら、
> 喜んでやらせていただきたいと思います。

ま,つなぎの意識でも構いませんから,副代表をぜひお願いします。
まだ他の方の意見も聞かないといけませんが。
とにかくGETSをNAMの現会員400名のレベルできちんと動かすことがこのプロジェ
クトの最重要の課題です。鈴木さん,よろしくお願いします。

どんな風に技術系のプロジェクトを進めたらいいか,提案してもらえませんか。それ
に現状のGETSがサーバーさえあればすぐに実装できるのかなど,GETSの現状について
も教えていただけるとありがたいです。

ワークショップ前で忙しいでしょうけどね。


***********************************************
  西部 忠 NISHIBE, Makoto
  北海道大学大学院経済学研究科
  e-mail: nishibe@e...
  Homepage: http://www.econ.hokudai.ac.jp/~nishibe/
***********************************************


 18 From: yasuo suzuki  <fwih0677@>
Date: 2001年2月28日(水) 午前8時04分
Subject: 自己紹介-鈴木泰生


    鈴木泰生です。

地域系は東京で33歳です。
仕事はプログラマです。
現在Javaでweb系の開発をやっております。
namプロジェクトに比べれば非常にくだらない仕事
なのですが無茶苦茶な納期設定と、ブラウザベース
とは思えないようなダイナミックな画面仕様のため
大変忙しい状態です。
手短に自己紹介いたします。

使える言語はJava,VB,perlなどです。
namプロジェクトでは、独自サーバで運用する
ということをきいたことがあるのですが、
そのばあい、apache + tomcat + Java + PostgreSQL
みたいなシステムがいいのかなぁと思っています。
そこらへんのプログラミングでお手伝い可能かと思っています。

今後ともよろしくお願いします。

鈴木泰生
fwih0677@m...


 19 From: Ken Suzuki  <ken@>
Date: 2001年2月28日(水) 午前10時09分
Subject: Re: [nam-project] 自己紹介−鈴木健3


    こんにちは。鈴木です。

 >相対値貨幣について,他の人はどういうコメントをするかも楽しみですね。

はは。
西部さんとは大論争ですからね。
編集の倉数さんは「たいへん興味深い」といってました。意味深ですが。

 >> リアルな世界では、大学院の博士課程1年です。
 >> 研究室は複雑系・人工生命をやってます。
 >> 脳や認知の問題(特に自我、自己意識)を力学系でモデル化しようという
 >> あやしい研究に取り組んでいます。目下のテーマはメタ学習ですかね。
 >
 >池上さんは君のことどう見てるのかな。

「おまえ。ちゃんとけんきゅうしろよー」です。

 >ま,つなぎの意識でも構いませんから,副代表をぜひお願いします。
 >まだ他の方の意見も聞かないといけませんが。

何もしなくても抽選でいつか落ちるんでしたよね。


 20 From: go  <afake908@>
Date: 2001年2月28日(水) 午前10時16分
Subject: [nam-project] 自己紹介-宮地剛


    はじめまして。宮地剛です。

地域系は大阪です。
関心系はLETSを中心に投稿しています。

NAMに参加した一番の動機がLETSを実現するためにありましたので、今回のプ
ロジェクトを楽しみにしています。
とは言いましても、コンピュータ関係については、まったくの戦力外と考えてくださ
い。
ぼくになにができるのか、ぼく自身にも、よくわからないんですが、運営/規約がメ
インになると思います。

鈴木さんの副代表の件について、賛成いたします。

それから、いま、ぼくの住む地元の商店街や介護事業所や障害者支援団体と連携した
地域通貨づくりにとりかかっています。その仕掛けとなるホームページを制作してい
ますので、興味のあるかたは、ご覧ください。(まだまだ完成にはほど遠いんです
が…)

http://www.oct.zaq.ne.jp/majonet/


 21 From: yumoto  <yumoto@>
Date: 2001年2月28日(水) 午前10時23分
Subject: 討議−MLの傍聴 2


    湯本です。

共有ファイルや投票機能などと切りはなされた、傍聴専用のMLをあら
たにつくることは可能だと思います。

メンバー専用のMLとはべつに、たとえば、free-ml に傍聴専用のML
をつくることになりますが、そこには一般読者は書き込みができず読む
ことだけができるように設定します。

そして、傍聴専用MLに書き込みができるただ一つのアドレスを用意し、
そのアドレスをメンバー専用のMLに加えておきます。そうすれば、メ
ンバー専用MLの内容が自動的に、傍聴専用MLに流れます。
(以上)


 22 From: Ken Suzuki  <ken@>
Date: 2001年2月28日(水) 午前11時23分
Subject: Re: [nam-project] 提案−技術/管理1


    こんにちは。鈴木です。

実は、ぼくはコンピュータはそれほど得意なわけではなく、
サーバープログラミングもこのシステムを開発するために
覚えたようなものです。
システム管理とかちゃんとできるレベルじゃなくて、UNIXは1ユーザレベルです。
ですから、みなさんの自己紹介を聞いている限り、
ぼくよりもはるかに技術には明るいと思います。
最初の議論のモデレートをしていって、細かい話になったら
詳しい方を中心にやっていくといいと思います。


【GETSの現状】
GETSのHPは
http://gets.sourceforge.net/
開発用のHPは
http://sourceforge.net/projects/gets/
にあります。
技術者用MLは
http://www.freeml.com/ml_mess.php?ml=gets-dev
です。

言語はperlで、システム的には
perl→DBI→PostgreSQL
です。DBI通しているので、トランザクション処理可能なDBなら
一応使えるはずですが、もしかしたらPostgres特有のSQL文つかっちゃってる
かもしれません。

perlで安定版まで開発が進んだら、
現在のところJAVAで次世代バージョンを開発しようと思っています。
とりあえず、NAM、code、東大が4月からということで、
1000人単位のプロジェクトを実現できるようなところまでは
最低perlでもっていきます。
細かいバグや改善点の報告については
http://sourceforge.net/tracker/?group_id=18562&atid=118562
です。手伝ってくれるとうれしいですが。

技術畑のひとは(できればそうでない人も)
http://sacral.c.u-tokyo.ac.jp/~ken/gets/tamatebako.html
の3節はぜったいに読んでください。
もちろん、これが絶対ということではないですよ。
寄付をうけつけて開発者の配分しますので、そのへんのあたり
をなぜしなければいけないのか、どうやるのか(4−3)はおさえてください。
このへんについてはご意見をお待ちしています。

【NAMでの実現】

1.サーバーの選択
貸しサーバーの可能性も考えましたが、現状のNAMの技術陣の能力からして、
おそらくセキュア(RAIDの意味からもクラックの意味からも)なサーバー構築できる人がいるはずです。
そっちのほうがいろいろ融通きくので、どこかのISPかデータセンターにおかしてもらう感じで
どなたかできますでしょうか

2.サーバー管理担当者の選定(複数可)

技術系のひとでMLをたちあげ、細かい話はそこで議論しましょう。

2−1.物理的なサーバー構築担当者の選定

この1ヶ月の間、比較的時間がとれて、技術に明るい方にやっていただきましょう。

2−2.役割分担

非常事態がおきることもありますから、常時ひとつの領域に2人以上を配置しましょう(兼任可)。
現代サッカーと同じですね。

【具体的な仕事】

とりあえずあと一月で400人運用可能なシステムをつくらねばなりません。
ぼくとしては、3月を1週間残すくらいまでにperl版を限りなく安定版にもっていきます。
できたら手伝ってくださいね。

具体的な仕事は、
1.物理的なサーバーの構築
2.NAM用のチューンナップがどの程度必要か検討
3.GETSのバージョンアップに耐えられる形でのソースの書き換え
(逆にGETSをそれに耐えられるようにもっていきます)
4.NAM−LETSシステムの構築
5.運用

となります。

【GETSとしては。。。】

NAMのために偏って開発するわけにはいきませんが、
NAMのような要望に耐えられるような方向で開発していく必要があるので、
対等な関係で意見交換と開発をしていくのがいいと思います。
どうぞよろしくお願いします。

ではでは。


 23 From: shogowatanabe@
Date: 2001年2月28日(水) 午後0時03分
Subject: 自己紹介-渡辺彰吾


    渡辺彰吾です。

GETSの開発者鈴木健さんに副代表をお願いします。

自己紹介
NAM大阪/HPグループの一人です。

プロジェクトへの抱負
作品を交換、公開、収集する場を製作できればと思います。作品と商品の違いは理解できていません。

可能な貢献
プロジェクト内容:「技術/管理」
工程:コーディング
言語:JAVA+SQL+XML+SMIL(スマイル)


 24 From: yumoto  <yumoto@>
Date: 2001年2月28日(水) 午後8時05分
Subject: Re: [nam-project] 自己紹介−鈴木健3


    こんにちは、湯本です。

> 相対値貨幣について,他の人はどういうコメントをするかも楽しみですね。

よけいなことかもしれませんが、わたしのコメントを書いてみます。

(1)  相対値貨幣は、社会からの、ある個人に対する「評判」を数値化す
   ることになる、ということは、その数値が個人を圧殺する力は、教育
   における偏差値よりも、圧倒的だろう。

(2)  社会からの評判という、人間にとって非常にデリケートな問題を、
   単なる貨幣に直接的に結びつけるのは、デリカシーにかけるのではな
   いか。おひねりとか、お布施とか、その場限りのものがよいのではな
   いか。

(3)  相対値貨幣を、それは単なるカネに過ぎないといってバカにするこ
   とは、従来の貨幣よりもむずかしい。すべての人間をまき込み、逃げ
   場を取り上げてしまう傾向があるのではないか。「トマトの赤さやあ
   の人の笑顔」さえあれば、あとはなにもいらない、というような逃げ
   場が消えてしまいそうだ。

(4)  いままでの成功者には、資本と国家の枠のなかでうまく立ち回った
   だけだ、と言って、その成功者からの圧迫から身をかわすことができ
   たけれど、「ひとびとの評判を集めた」成功者からの圧迫感からは逃
   げづらく、やっかみによる社会的緊張は強まるのではないか。いまま
   でよりも貧富の差は大きくなる傾向がある、ということなら、なおさ
   らだろう。

以上、心配な点ばかりになりました。ここであげたようなことは、単なる
わたしの無理解かもしれません。資本に対抗するのに、わたしとしては、
ボイコットによる静かなくらしと、比較的狭い範囲での LETS 、そして
多様な LETS の連合、という方向に魅力を感じるものですから、そんな
先入観からのかたよった印象かもしれません。失礼しました。

それではまた。
yumoto hirokazu <yumoto@h...>


 25 From: Ken Suzuki  <ken@>
Date: 2001年2月28日(水) 午後10時32分
Subject: Re: [nam-project] チャット−相対値貨幣1


    こんにちは。鈴木です。

やってみなけりゃ分からないところがあるので、
ほんとはなんともいえないのですが。

 >(1)  相対値貨幣は、社会からの、ある個人に対する「評判」を数値化す
 >   ることになる、ということは、その数値が個人を圧殺する力は、教育
 >   における偏差値よりも、圧倒的だろう。
 >
 >(2)  社会からの評判という、人間にとって非常にデリケートな問題を、
 >   単なる貨幣に直接的に結びつけるのは、デリカシーにかけるのではな
 >   いか。おひねりとか、お布施とか、その場限りのものがよいのではな
 >   いか。

文章読んでいただければ分かると思いますが、
貨幣評判論はLETSについて導入された議論です。
相対値貨幣は、評判としてのLETSを自然に拡張したものです。

LETSが補完通貨じゃなくなればいつもマイナスの人はでてきてしまうでしょう。
これを防ごうとしたら、タイムダラーのように、時間制にするのが一番ですね。
医者の診察も子供の肩たたきも等価ですから。
それでも働かない人はいつもマイナスかな。

 >(3)  相対値貨幣を、それは単なるカネに過ぎないといってバカにするこ
 >   とは、従来の貨幣よりもむずかしい。すべての人間をまき込み、逃げ
 >   場を取り上げてしまう傾向があるのではないか。「トマトの赤さやあ
 >   の人の笑顔」さえあれば、あとはなにもいらない、というような逃げ
 >   場が消えてしまいそうだ。

相対値貨幣を使わないのも自由ですからね。
あくまでコミュニティ通貨です。もちろん、国が作ることもありうるでしょうが。
文章に書いてますが、複数のコミュニティ通貨の一部としてあればいいと
思ってます。

 >(4)  いままでの成功者には、資本と国家の枠のなかでうまく立ち回った
 >   だけだ、と言って、その成功者からの圧迫から身をかわすことができ
 >   たけれど、「ひとびとの評判を集めた」成功者からの圧迫感からは逃
 >   げづらく、やっかみによる社会的緊張は強まるのではないか。いまま
 >   でよりも貧富の差は大きくなる傾向がある、ということなら、なおさ
 >   らだろう。

http://lib1.nippon-foundation.or.jp/1999/0182/contents/019.htm

にあるように、日本は貧富の差が小さい。
それは企業の持ち合い(法人資本主義)や間接金融、労使協調などで、
個人資本主義が正常に機能をはたしていないからです。
いわば、日本が社会主義だといわれる所以です。
図2でいうとピークより大分左よりにあるわけです。
修正資本主義が成功した証拠なのかもしれません。

日本で相対値貨幣を導入したら、
(自営業者or中小企業)と大企業の社員の収入格差は縮まるでしょう。
大企業の社員同士の収入格差は広がります。
資産家と労働者の賃金格差は縮まります。
たぶんですが。図3をみればそうなることが分かるはずです。イメージつきます?
つまり、すごい稼ぐスーパーサラリーマン(まあ株主ですけど)
がでてくるってことです。系列が解体し、企業組織がフラットな
共有制になります。

その人の市場価値を正当に評価してしまう分だけのこわさがありますね。
逆にいえば、コミュニティへの貢献度に応じない対価のほうが、ほとんど
の人は求めているわけです。文章中にかいたSSM調査にあるとおり、
日本人は実績よりも努力で評価して欲しい。
結果よりも過程をみてほしいんですよね。
(努力ニューロンの発火でもしらべるかな。)

もちろん、相対値貨幣を導入したらかえって貧富の差が縮まるのかもしれません。
そのへんはどうもわからない。ちゃんと調べてみますね。

http://jmm.cogen.co.jp/back/083m.html
にあるとおり、
「 経済企画庁が作成している労働分配率の推移を見ると、日本経済の高度成長が始ま
る70年台以前の分配率は50%以下の水準でした。高度成長が始まった70年代の
中盤以降、分配率は急速に上昇に転じました。そして80年代後半まで、若干の上下
はありましたが、ほぼ60%台の水準を維持してきました。80年代の後半になり、
一時期60%を割って50%台に下落したこともありましたが、90年代に入って再
び上昇に転じ、最高時点では70%台まで到達しました。

しかし、その分配率もここへ来て、企業のリストラ進展に伴い減少傾向を辿りはじめ、
企画庁の試算によると、99年7−9月期には68.3%程度になると見られています。」
ということですが、相対値貨幣では原理的に資本分配率は地代等を除きゼロになります。
この30%がどの程度きくかですよね。


 26 From: ippei hozumi  <ipfr_cat@>
Date: 2001年2月28日(水) 午後1時15分
Subject: Re: [nam-project] 討議−MLの傍聴


    ほづみです。

わたしの意見を述べます。

前提として、NAMの会員はすべての情報にアクセスできるべきでし
ょう。

まず、傍聴したいという気持ちはわからないではありませんね。ぼ
くが参加してないなら、なにやってんだろ、とたぶん思いますから。
ただ、ぼくの場合は参加してないなら途中で熱もさめちゃうので、
傍聴といいながら、なにも聞いてないってことになっちゃいます。

いっぽう、討議している側からすると、黙って聞いているだけなら、
べつに邪魔にはならないでしょうが、そんなことしてどういう意味
があるんだろう、という気もします。

まあ、中をとって、一定期間をおいて過去のログにアクセスできる
ようにするというのがいいと思います。ただ、その共有フォルダと
いうのがそういう芸当できるのかどうか、わかりません。

もひとつの案は、これも一定期間でまとめや報告をなんらかのかた
ちで出すというのがいいんじゃないでしょうか。

まとめると、いちおうクローズにする。ただ、これは隠しているん
じゃなくて、討議の詳細までリアルタイムに報告してもあまり意味
がないから、というアナウンスはしたほうがいいと思います。
その上で一定期間で、なんらかの報告をする。

namが稼働するまで、というのが比較的短い期間であるなら、問題
はないのですが、いまひとつどの程度の期間になるのか、わたしと
してはつかめていません。

それと、報告やアナウンスは、このMLにかぎらず、NAMの全般のプ
ロジェクトでやってほしいという個人的な希望でもあります。

もひとついうと、この報告というか、中間的なまとめみたいなのは、
メールじゃなくホームページでやってほしい、というか、やりたい
と思ってます。なぜかというと、どうも過去のメールをひっくり返
すというのが苦手というのもありますが、スレッドをたどっても、
いっこうに結論が見えてこないという気がするからです。

 

穂積一平
ipfr_cat@d...

http://home.interlink.or.jp/~ipfr_cat/


 27 From: yumoto  <yumoto@>
Date: 2001年3月1日(木) 午前10時28分
Subject: チャット−相対値貨幣2


    鈴木さん、こんにちは、ごあいさつがおくれましたが、湯本ともうします。

鈴木さんのML、gets-* , npo-cap に参加させていただいてまして、
鈴木さんのフレンドリーな文章をいつも拝見しています。そのため、つ
い気安く、勝手なことを書かせていただきました。無礼の段、ご容赦く
ださい。今後とも、フレンドリーなお付き合いをお願いします。

> 貨幣評判論はLETSについて導入された議論です。
> 相対値貨幣は、評判としてのLETSを自然に拡張したものです。

鈴木さんの tamatebako に、つぎの一節があります。
「LETSは一次産品だけで生活できるような素朴な社会には向くが、生産
関係が複雑に絡み合う現在の産業社会には向かない。」

生産関係が複雑に絡み合うすがたを、評価行列、評判ベクトル、として
数値化するのが相対値貨幣ですね。わたしの疑問は、「複雑に絡み合う
すがた」が数値化されることによって、個人の主体性がつよくおびやか
されるのではないか、ということにあります。

この疑問には、二つの方向がありまして、ひとつは、個人の実力発揮を
さまたげるのではないか、ということです。たとえていえば、偏差値を
強調しすぎることで、偏差値にはあまり関係しない能力が抑圧されるの
ではないか、という疑問です。

もう一つの方向は、すべてを投資と考えることから生ずるであろう問題
です。他人の成功にぶらさがることで利益を得ようとする、利己的な動
機の、非主体的な行為を、奨励することになってしまいそうだという疑
問です。


はなしを変えますが、「複雑に絡み合う」ものに自然生態系があります。
わたしが有機農業にひかれるのは、複雑に絡み合う自然生態系に自分を
投入し、自我のカラから自由になることで、安心立命の境地に達する、
そのような方向性を感じるからだと思います。相手が自然生態系なら、
自我のカラを脱ぎすてたいと思うわけです。

しかし、複雑に絡み合う産業社会が相手では、そうはいきません。自分
の主体性の確立こそが大切です。評価行列、評判ベクトルで記述されつ
くした世界に自分を投入するのではなく、ぎゃくにそこから脱出するこ
とが、主体性をいかすことになるのではないかと思います。

以上のような、わたしの個人的な思いからの、勝手な疑問を書かせてい
ただきました。前回も書きましたが、わたしとしては、ボイコットによ
る静かなくらしと、比較的狭い範囲での LETS 、そして多様な LETS の
連合、という方向に魅力を感じます。

それではまた。2001/03/01
yumoto hirokazu <yumoto@h...>


 29 From: shogowatanabe@
Date: 2001年3月1日(木) 午後7時59分
Subject: Re: [nam-project] $BDs0F!]5;=Q(J/$B4IM}(J2


    渡辺彰吾です。

>技術畑のひとは(できればそうでない人も)
>http://sacral.c.u-tokyo.ac.jp/~ken/gets/tamatebako.html
>の3節はぜったいに読んでください。
>もちろん、これが絶対ということではないですよ。
>寄付をうけつけて開発者の配分しますので、そのへんのあたり
>をなぜしなければいけないのか、どうやるのか(4−3)はおさえてください。
>このへんについてはご意見をお待ちしています。

読みました。ユースケース図を書いて理解しようとしています。

>
>【具体的な仕事】
>
>とりあえずあと一月で400人運用可能なシステムをつくらねばなりません。
>ぼくとしては、3月を1週間残すくらいまでにperl版を限りなく安定版にもっていきま
す。
>できたら手伝ってくださいね。
>具体的な仕事は、
>1.物理的なサーバーの構築

ウェブホスティングですが、
「Webhosting.co.jp」http://www.webhosting.co.jp/index.htm
はどうでしょう。
インド人の5人の方がプログラム作成としてかかわっています。


>2.NAM用のチューンナップがどの程度必要か検討
>3.GETSのバージョンアップに耐えられる形でのソースの書き換え
>(逆にGETSをそれに耐えられるようにもっていきます)
>4.NAM−LETSシステムの構築

今、NAMではACCESSのMDBが使われているそうですが、
もしNAMとGETSを会わせる場合、まずNAMのテーブル構造とGETSのテーブル構造の違いを知
っておきたいです。
あと、Perlは書けません。
JAVAは書けます。

>5.運用

参加できないです。


コーディングで参加する希望はありますが、Perlが書けないから困難です。
ごめんなさい。


 30 From: go  <afake908@>
Date: 2001年3月1日(木) 午後8時33分
Subject: [nam-project] 質問−400人か10万人か?


    宮地です。

鈴木さんの『ネットコミュニティ通貨の玉手箱』を、ぼちぼち、読んでいるところで
す。だから相対値貨幣に関しては、まだコメントできないんですが、ふと疑問に思っ
たことがあります。初歩的な質問ではずかしいんですが…。

西部さん。こんにちわ。
これからnamの運営・規約を考えていくわけですね。当面の課題は400人に流通
するnam循環スキームを確立することにあるんでしょうが、どのように考えていく
か?ということで言えば、namの流通スケールをどれくらいの規模に想定しておく
必要があるのか?ということが、よくわからないんです。

現在NAMに参加している人数は400人ほどらしいですが、namの流通圏は、そ
れでよいと考えるのか?
この場合は、ネット上で、既存の地域通貨と同じような発想で考えていけば、循環ス
キームとかの問題も考えやすいと思います。

けれど、いつだったか柄谷さんがメールに書かれていたように「将来NAMが10万
人になったらどうするのか?」という将来的なビジョンも含めて考えていくのでしょ
うか?

この場合、namの口座が10万あると考えるのが妥当でしょうから、個人だけでは
なく、NAM協賛企業や協同組合やNPOの口座もあるだろうと考えるわけです。そ
ういった場合は、namの流通圏は、分業化された産業連関も部分的に包括している
ことになるはずですから、そういったときに、どういうふうに考えていけばよいの
か。鈴木さんの「相対値貨幣」の問題も、そういったスケールで考えるときに、意味
があるようにも思ったりもします。

いまはまだ、そんなことをかんがえなくてもいいのかな?と思ったりしますが、プロ
グラム開発の対応がかなり変わってくるんじゃないかな?と素人ながらに思ったもの
で…。

鈴木さん。
よく分からんのですが、流通圏のスケールによって、GETSのプログラムとかも、
かなり変わるもんなんですか?


 31 From: ippei hozumi  <ipfr_cat@>
Date: 2001年3月1日(木) 午後0時04分
Subject: Re: [nam-project] 自己紹介−鈴木健3


    こんにちわは。ほづみです。

>
> > 相対値貨幣について,他の人はどういうコメントをするかも楽しみですね。
>

せっかくなので、わたしも暫定的な感想を書いてみます。

完全に理解したとは、言い難いですが、まず鈴木健さんの文章には
「悪」がない、という気がしました。これはいいことなのかもしれ
ません。

わたしが貨幣についての定義でいちばん妥当だと思っているのは、
今村仁司「貨幣とは何だろうか」(ちくま新書)で説明されている、
「媒介形式」というものです。
説明は省きますが、これはコミュニケーション一般について拡張さ
れうる議論です。
わたしの「自己紹介」で触れた「サイバースペースとML」という
文章で、「書き込み」ということを論題に載せていますが、これは
「媒介形式」「貨幣」といったものへの含みを持たせたかったから
です。

まあ、今西氏の「貨幣」議論がいいか悪いかは意見のわかれるとこ
ろかもしれません。

それで、ちょっと飛躍しますが、鈴木さんはワルラスの一般均衡理
論は「美しい」と感じられるでしょうか。
こんなことをお聞きするのは、相対値貨幣のところを読んでいて、
数学的な解法が先にあってでてきたんじゃないかな、と下司の勘ぐ
りですが、ふと思いました。

違っていたらごめんなさい。いずれにしろ、「貨幣」の欠乏で困っ
ているわたしとしては、もすこしどろどろとしたところでのたうっ
ているというのが実状ですから。

どうも、まとまりませんで、すみません。

 

穂積一平
ipfr_cat@d...

http://home.interlink.or.jp/~ipfr_cat/


 32 From: ippei hozumi  <ipfr_cat@>
Date: 2001年3月1日(木) 午後0時04分
Subject: Re: [nam-project] 提案−技術/管理2


    ほづみです。

>
> >技術畑のひとは(できればそうでない人も)
> >http://sacral.c.u-tokyo.ac.jp/~ken/gets/tamatebako.html
> >の3節はぜったいに読んでください。
> >もちろん、これが絶対ということではないですよ。
> >寄付をうけつけて開発者の配分しますので、そのへんのあたり
> >をなぜしなければいけないのか、どうやるのか(4−3)はおさえてください。
> >このへんについてはご意見をお待ちしています。
>
> 読みました。ユースケース図を書いて理解しようとしています。

もしよければ、その図ができたらぼくにも見せてください。

NAMでの具体的な作業ですが、個人的にはPerl->DBI->PostgreSQLと
いうのはだいたいわかります。
ただ、物理的にきついという気がしてます。
これは、西部さんにも相談にのってもらって、門戸をもすこしひろ
げて実際に動けるひとを募ったほうがいいのではないでしょうか。


> >
> >【具体的な仕事】
> >
> >とりあえずあと一月で400人運用可能なシステムをつくらねばなりません。
> >ぼくとしては、3月を1週間残すくらいまでにperl版を限りなく安定版にもっていきます。
> >できたら手伝ってくださいね。

現状では、あれしろ、これしろ、とちょっとあつかましいぐらいに
言ってもらったほうが、ぼくは動きやすいです。なんか主体性がな
くて申しわけないですが。
まず、とりあえずソースを見せてもらうところからはじめないとい
けないので、そのへん「3月を1週間残す」というペースは、1日
どのくらいのテンポになるんでしょか。

> >具体的な仕事は、
> >1.物理的なサーバーの構築
>
> ウェブホスティングですが、
> 「Webhosting.co.jp」http://www.webhosting.co.jp/index.htm
> はどうでしょう。
> インド人の5人の方がプログラム作成としてかかわっています。

これ、いま見てたんですが、Servletも使えていいんじゃないでし
ょうか。ただお金のこともありますし、事務局でもサーバーの移転
を考えているというようなことも聞いていますから、そのへんどう
でしょう。

>
> >2.NAM用のチューンナップがどの程度必要か検討
> >3.GETSのバージョンアップに耐えられる形でのソースの書き換え
> >(逆にGETSをそれに耐えられるようにもっていきます)
> >4.NAM−LETSシステムの構築
>
> 今、NAMではACCESSのMDBが使われているそうですが、
> もしNAMとGETSを会わせる場合、まずNAMのテーブル構造とGETSのテーブル構造の違いを知っておきたいです。

これは現在、鈴木泰生さんとぼくとで、ちょっとずつ触っています
が、実際のところほとんどすすんでいません。ACCESSは事務局でた
またま使っているというレベルでテーブルの構造がどうのというレ
ベルの問題以前です。ほんとはこれもきちんと考える必要がありま
す。ということは白紙とみなしていいと思います。

このあたりはぼくは大阪ですが、実状を見ている阪口さんにすこし
報告してもらったらどうでしょうか。
阪口さん、以前の文章でもいいですから、いちど現状報告を。

>
> >5.運用
>
>
>
>
>
>
> Help URL   : http://help.egroups.co.jp/
> Group URL  : http://www.egroups.co.jp/group/nam-project/
> Group Owner: mailto:nam-project-owner@e...
>
>
>


穂積一平
ipfr_cat@d...

http://home.interlink.or.jp/~ipfr_cat/

From: Ken Suzuki  <ken@>
Date: 2001年3月2日(金) 午前0時31分
Subject: Re: [nam-project] チャット−相対値貨幣2


    こんにちは。鈴木です。

難しい問題ですね。

 >鈴木さんの tamatebako に、つぎの一節があります。
 >「LETSは一次産品だけで生活できるような素朴な社会には向くが、生産
 >関係が複雑に絡み合う現在の産業社会には向かない。」
 >
 >生産関係が複雑に絡み合うすがたを、評価行列、評判ベクトル、として
 >数値化するのが相対値貨幣ですね。わたしの疑問は、「複雑に絡み合う
 >すがた」が数値化されることによって、個人の主体性がつよくおびやか
 >されるのではないか、ということにあります。

確かに主体性はおびやかされるでしょう。
コミュニケーションというのはそういうことがおこるものではないかな。

 >この疑問には、二つの方向がありまして、ひとつは、個人の実力発揮を
 >さまたげるのではないか、ということです。たとえていえば、偏差値を
 >強調しすぎることで、偏差値にはあまり関係しない能力が抑圧されるの
 >ではないか、という疑問です。

実力発揮の定義によるでしょうね。
主観としての実力と商品としての実力は違いますし。
相対値貨幣はたかが商品経済のはなしですから。
これだけ円が流通しても円では買えないものは無限にありますし、
逆にLETSは可能な商品を増やしていますよね。

世の中全部相対値貨幣にしようとは思っていませんよ。
世の中全部円でもないし、世の中全部LETSでもありませんから。

ただ、偏差値が関係をかなり正確に記述することで怖さを発揮したように、
相対値貨幣は正確に表現しすぎるところがあるかもしれませんね。

 >もう一つの方向は、すべてを投資と考えることから生ずるであろう問題
 >です。他人の成功にぶらさがることで利益を得ようとする、利己的な動
 >機の、非主体的な行為を、奨励することになってしまいそうだという疑
 >問です。

ぼくは売り手に責任をもつことと理解しています。

 >以上のような、わたしの個人的な思いからの、勝手な疑問を書かせてい
 >ただきました。前回も書きましたが、わたしとしては、ボイコットによ
 >る静かなくらしと、比較的狭い範囲での LETS 、そして多様な LETS の
 >連合、という方向に魅力を感じます。

それはいいことだと思います。
相対値貨幣は資本の本丸を解体するための道具であって、
自給自足できる人や、若干の交換で共給自足できる人には
まったく関係のない話です。いまのところ。


 34 From: Ken Suzuki  <ken@>
Date: 2001年3月2日(金) 午前0時43分
Subject: Re: [nam-project] チャット−相対値貨幣4


    こんにちは。鈴木です。

 >完全に理解したとは、言い難いですが、まず鈴木健さんの文章には
 >「悪」がない、という気がしました。これはいいことなのかもしれ
 >ません。

はは。それはぼくが悪人かどうかとは関係ないですね。
どちらかというと極悪人です。

 >それで、ちょっと飛躍しますが、鈴木さんはワルラスの一般均衡理
 >論は「美しい」と感じられるでしょうか。
 >こんなことをお聞きするのは、相対値貨幣のところを読んでいて、
 >数学的な解法が先にあってでてきたんじゃないかな、と下司の勘ぐ
 >りですが、ふと思いました。

最初のきっかけは、価値が伝播するシステムが作れないかというところです。
それだとループして計算できなさそうだと思ったら、計算できる方法を授業で
習ったのを思い出したのです。そのあと、このシステムが全部投資である
経済を表現していることに気がついて、一般均衡理論と同じだといわれて
ワルラス調べたら、実はワルラスも似たような思考の履歴していたという順序ですね。

オリジナルのワルラスの一般均衡理論はそんなに美しくなさそうですね。
たぶん、ニュートンやマクスウェルの原典がそうなのと同じなのではないでしょうか。

行列から固有ベクトル求めるのはきれいな話だと思います。でも美しいとまでは
思わないですね。もっと美しいと感じるのはありますから。

相対値貨幣は悪人がいる社会で取引するときに適しています。
変なもの売っても、売上につながらないわけですから。
ものを売るときは責任もてよ、ということです。

さっきのはチャット3なので、これはチャット4にします。


 35 From: Ken Suzuki  <ken@>
Date: 2001年3月2日(金) 午前0時52分
Subject: Re: [nam-project] 質問−400人か10万人か?2


    こんにちは。鈴木です。

 >鈴木さん。
 >よく分からんのですが、流通圏のスケールによって、GETSのプログラムとかも、
 >かなり変わるもんなんですか?

インターフェイスは変わるでしょうね。
リストをだらだら流されても10万人じゃついていけないでしょうし。
カテゴリー化はもちろん、財によっては市場をつくってもいいでしょう。
オークションも必要かな。

あとは、人数が増えればサーバー一台じゃ処理できないのでクラスタリングする
必要がでてきます。そうするとコードも書き換えなきゃいけない。
ぼくはやったことないですが。JAVAだとそのへんが大分楽にできるそうですね。

とりあえず、1000人に耐えられるシステムをつくるのがいいと思います。
IDとかそういうのは最初からスケーラブルにしておく必要がありますが。


 36 From: Ken Suzuki  <ken@>
Date: 2001年3月2日(金) 午前1時05分
Subject: Re: [nam-project] 提案−技術/管理4


    こんにちは。鈴木です。

In message "Re: [nam-project] 提案−技術/管理
 >現状では、あれしろ、これしろ、とちょっとあつかましいぐらいに
 >言ってもらったほうが、ぼくは動きやすいです。なんか主体性がな
 >くて申しわけないですが。
 >まず、とりあえずソースを見せてもらうところからはじめないとい
 >けないので、そのへん「3月を1週間残す」というペースは、1日
 >どのくらいのテンポになるんでしょか。

http://sourceforge.net/tracker/?group_id=18562&atid=118562
が全部クリアできれば上出来だと思います。

 >> >具体的な仕事は、
 >> >1.物理的なサーバーの構築
 >>
 >> ウェブホスティングですが、
 >> 「Webhosting.co.jp」http://www.webhosting.co.jp/index.htm
 >> はどうでしょう。
 >> インド人の5人の方がプログラム作成としてかかわっています。
 >
 >これ、いま見てたんですが、Servletも使えていいんじゃないでし
 >ょうか。ただお金のこともありますし、事務局でもサーバーの移転
 >を考えているというようなことも聞いていますから、そのへんどう
 >でしょう。

ここだと、DBMSがmSQL 2.0.3 / mySQL 3.23.24
 Databaseですよね。DBI経由の問題はないのかな。
トランザクションとか大丈夫でしたっけ。

将来的にはJ2EEをいれる必要があります。
JAVA版がほんとに開発されれば。


 37 From: SAKAGUCHI Hirohito  <sakaguchi@>
Date: 2001年3月2日(金) 午前3時11分
Subject: 連絡と報告 - センター事務局の運用についての基礎資料1


    阪口です。

ペース早いっすね。ついていくのが大変です。

> > 今、NAMではACCESSのMDBが使われているそうですが、
> > もしNAMとGETSを会わせる場合、まずNAMのテーブル構造とGETSのテーブル構造の違いを知っておきたいです。
−中略−>
> 阪口さん、以前の文章でもいいですから、いちど現状報告を。

以下は、nam-systemという、まだ非公開のML上で、現状のNAMのセンター
事務局の運用について2001/02/08に報告したものを、現状にあわせて若
干編集したものです。

nam-systemは、NAMのlets以外のシステム化(会員管理、コミュニケーショ
ンシステム等)について議論、実践するためのMLで、私の他に鈴木泰生
さんとほづみさんも参加されています。
事務局からはこのMLに公開しても良いとの許可をもらったので、公開し
ます。


/////////////////////////////////////////
基本的には事実のみを記載しますが、若干意見がまじっています。意見
には括弧付きで氏名を記載します。

------------------------------
【事務局の作業環境】
ハードウェア:COMPAQのPresario3200(Pentium600MHz メモリ128MB
       HD20G)
通信環境:    ISDN(内一本が通信用。一本はTel/Fax用)
バックアップメディア:MO(IO DATA  MOA-AX640SW/USB)
作業環境:    太田出版内の一角

------------------------------
【センターのサーバー環境】
1. NAMセンターのサーバーはsakura.netを使っている。Perl、FTP、
   telnetなどOK!
2. 契約形態はバーチャルドメイン。
   レンタルサーバより機能的には劣るが、メンテナンスをやってくれ
   るので手頃である。(鈴木氏見解)
3. web機能は、web上での会員登録→CSV保存→メール送信、に関しては
   問題なくできることを確認している。
4. テスト用のCGIが稼働中。下記アドレス。
   http://www.nam21.org/test/send_test.html
5. 現在、新しいサーバー環境に移転するための情報を募集中。

------------------------------
【事務局の作業手順】
現在の事務局の作業の流れは以下の通りです。

1.   入会の申請が届く。現在は一週間に10人程度。ほとんどがWebからの
     申請で、一週間に10人中8人から9人。その他に読書会等のイベント
     に参加した人がその場で会員申請するような場合がある。現在FAXで
     の入会は確認されていない。(以下はWebでの入会に絞って手順を説
     明する)
2.   Webより事務局宛てのメールとして届いた入会申請は、メールソフト
     「Becky!」の振り分け機能によって、自動的に新規会員用のフォル
     ダーに格納される。
3.   新規会員用のフォルダーに新着メールを確認したら、該当のメール
     を開いて、その会員情報を「Becky!」のアドレス帳に登録する。こ
     こは手動Cut&Paste。
4.   アドレス帳への登録が終わったメールは、[アクセスへの入力待ち用
     のフォルダー]に移動する。これも手動Drag&Drop。
4.   新規会員に「NAM会員登録のお知らせ」というタイトルで定型
     メールを返信。文書の中身は、事務局からの挨拶(入金の催促含
     む)と、柄谷代表からの挨拶。
     返信したら、手動Drag&Dropで、[返信済みフォルダー]に移動。
5.   MS-Access2000のNAM会員用データベースを開いて、登録用フォー
     ムを起動。その登録用フォームに[返信済みフォルダー]にあるメー
     ルの情報を転記、登録する。
     間違えやすい文字列情報は手動Cut&Paste。
6.   MS-Accessへの登録が終わったメールは、[データ入力済フォルダー]
     に移動する。手動Drag&Drop。以上で一次入力終わり。

7.   郵便局から振替用紙が送られてきて、入金が確認される。
     (入金は郵便振替(圧倒的多数)、銀行振込、現金、その他がある)
     アクセスに入金情報を手入力。マッチングは氏名。さらに[データ
     入力済フォルダー]にためてあった当該会員からの申込みメールを、
     [入金確認済フォルダー]に手動で移動。
8.   freeml(とe-groupe)のWEBページにアクセスして、新規会員をそれ
     ぞれの地域系、関心系のmlメンバーとして登録する。
9.   ML登録が終わったメールは、[ML登録済フォルダー]に移動する。
     手動Drag&Drop。


■現在、もっとも手間がかかるのがmlメンバーの登録。
■郵便振替の確認用紙は、事務局移転の関係で配送が遅れがちである。
■MOドライブを購入してデータのバックアップを行っている。

------------------------------
【現在の会員管理情報】
1.   会員基礎情報(氏名・フリガナ(半角カナ)、住所、電話番号等々)
2.   登録する関心系、地域系情報
3.   入金系情報(入金額、センター会費と地域系会費)
4.   その他情報(賛助会員、その他備考的情報)

■メールアドレスを複数登録している方がいるが、現在のデータベースの
  テーブル構造がそうなっていない。
■会員登録用フォームとDMラベル以外は、良くも悪くもMS-Accessの生の
  データベースなので、簡単にデータを操作できるが、簡単すぎてシステ
  ムとしては脆弱。(阪口)

------------------------------
【課題とその他】
1. 今後、何らかの対外的イベントがあると、その時点でどっと人が登録
   されることが予想される。その処理体制は整っていない。

以下は、センター事務局日向さんからいただいている補足です。
-------------------------------------------------[引用開始]
データベースの設計、HPの設計、両者をいかに連動させるかという課
題があります。
現在、落合と私が、マニュアル本を読みながら、主に「Access」と「ホー
ムページビルダー」について学習中です。
(意気込みとしては)あと1週間以内ぐらいに、少なくとも「Accessで
どんなことが可能か」「HP作成ソフトで何が可能か」について、基本的
な機能についての知識(自由自在な操作とまではいかなくても)を得た
いと思っています。
「どんな機能があり、何が可能か」がわかるようになれば、両者の「設
計案」についても、より適切なものを、事務局側から提案することがで
きるようになると思います。

現在でもHPやデータベースのフォーマットの微調整は、事務局で行なっ
ていますが、近い将来に大胆な修正が必要と思います。その際にはご助
力お願いいたします。
-------------------------------------------------[引用終了]

 

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
      阪口 弘人( SAKAGUCHI,Hirohito )
      関心系:コンピューター/理論/芸術
      地域系:東京
      その他:1964年生まれ/男
      E-mail sakaguchi@h...
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/


 38 From: SAKAGUCHI Hirohito  <sakaguchi@>
Date: 2001年3月2日(金) 午前3時11分
Subject: Re: [nam-project] 提案−技術/管理5


    阪口です。

> > 今、NAMではACCESSのMDBが使われているそうですが、
> > もしNAMとGETSを会わせる場合、まずNAMのテーブル構造とGETSの
> > テーブル構造の違いを知っておきたいです。
−中略−
> 阪口さん、以前の文章でもいいですから、いちど現状報告を。

はーい。
基礎資料として、現在のNAMの事務運用形態について報告しましたが、
以下はnamプロジェクトに関連しそうな部分の説明と見解です。
(データベース用語はここでは通じるのかな?)

現状のMS Accessでの会員管理DBは、まったく正規化されていません。
そもそもMS Excelのワークシートから移植した経緯もあって、その状態
から変わっいません。複数所属が可能な関心系などはベタに横並びの項
目として表現されています。

したがって、本格的な会員管理システムを構築しようとすると、大幅な
変更が必要になると思いますから、先行するnamプロジェクトでは現状
のテーブル構造を気にする必要はないと思います。

ただ気になるのは、会員の特定です。
現在はプライマリーキーとして会員IDを便宜的に振っていますが、プラ
イマリーを意識した運用ではありません。
nam-letsシステムと会員IDが違うとまずいので、取り急ぎここを整合取
らなきゃならないと思います。
また、事務作業の軽減を考えると、会員管理DBで新規会員追加されたら、
それがnam-letsにも反映される、また更新された場合も必要に応じて反
映されるべきと考えてはいます。

このあたりは他にもいろいろあるんですが、現状のgetsシステムを調べ
ている時間が取れなくて、チェックできていません。
もう少し時間をください。(この週末くらいにまとめたいです)


その他にも誰が運用するのか、運用は輪番するのか、ほづみさんがご指
摘のようにNAMのWebサイト並びにML様のサーバー移転の話があるがnam
プロジェクトと別立てで進んでいいのか等の質問事項があるのですが、
これも整理しきっていないので、再度正式にアップすることとして、と
りあえず前フリだけしておきます。

---------
面白そうな議論がありますが・・・現在参加断念。

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
      阪口 弘人( SAKAGUCHI,Hirohito )
      関心系:コンピューター/理論/芸術
      地域系:東京
      その他:1964年生まれ/男
      E-mail sakaguchi@h...
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/


 39 From: go  <afake908@>
Date: 2001年3月2日(金) 午前10時47分
Subject: Re: [nam-project] 質問−400人か10万人か?3


    こんにちわ。宮地です。

鈴木さん、お答え、ありがとうございます。

> インターフェイスは変わるでしょうね。
> リストをだらだら流されても10万人じゃついていけないでしょうし。
> カテゴリー化はもちろん、財によっては市場をつくってもいいでしょう。
> オークションも必要かな。
>
> あとは、人数が増えればサーバー一台じゃ処理できないのでクラスタリングする
> 必要がでてきます。そうするとコードも書き換えなきゃいけない。
> ぼくはやったことないですが。JAVAだとそのへんが大分楽にできるそうですね。
>
> とりあえず、1000人に耐えられるシステムをつくるのがいいと思います。
> IDとかそういうのは最初からスケーラブルにしておく必要がありますが。
>
考えようによっては、1000人のリストってのも大変ですよね。
となると、このくらいのスケールでも、検索機能はいるだろうし、ある程度のカテゴ
リー化は必要ってことでしょうか。
財の提供などが出てきた場合は、市場も必要かもしれませんね。

ところで、以前にLETSのMLで討議されていたことで、こういうのがあります。

ぼくみたいな自営業者、湯本さんのような農業に携わっておられる方、あるいは、こ
こに参加されているコンピュータ技術者の方々は、namが立ち上げられても、リス
トにサービスなり商品(?)とかをリストアップしていくことは比較的たやすいわけ
ですよね。たとえば、ぼくだと『天然酵母パン』を簡単に提供できちゃうわけです。

LETSで話題になったのは、サラリーマンの人たち、とくに営業とか、技術職でも
専門的過ぎて一般に提供しても意味がないといった人たちにとって、サービスや商品
・財を提供するのは難しいんじゃないかってことです。

これが物理的な地域を基盤にしたLETSだと「肩叩き」とか「庭掃除」といった
サービスも可能なんでしょうが、namはバーチャル空間での、しかも全国に渡る範
囲にいる会員間での流通圏なわけですから、そういった種類のサービスは成り立ちに
くい。となると、いったいなにを提供すればよいのかってことになりますよね。

いくらシステムが完璧に出来あがっても、実際にnamが流通しなければ意味がない
んで、この辺のことをどう考えたらよいのか、みなさんのご意見をお聞かせくださ
い。


 40 From: shogowatanabe@
Date: 2001年3月2日(金) 午後3時37分
Subject: Re: [nam-project] $B<ALd!]#4#0#0?M$+#1#0K|?M$+!)(J3


    渡辺彰吾です。

>
> >鈴木さん。
> >よく分からんのですが、流通圏のスケールによって、GETSのプログラムとかも、
> >かなり変わるもんなんですか?
>
>インターフェイスは変わるでしょうね。
>リストをだらだら流されても10万人じゃついていけないでしょうし。
>カテゴリー化はもちろん、財によっては市場をつくってもいいでしょう。
>オークションも必要かな。
>
>あとは、人数が増えればサーバー一台じゃ処理できないのでクラスタリングする
>必要がでてきます。そうするとコードも書き換えなきゃいけない。
>ぼくはやったことないですが。JAVAだとそのへんが大分楽にできるそうですね。
>
>とりあえず、1000人に耐えられるシステムをつくるのがいいと思います。
>IDとかそういうのは最初からスケーラブルにしておく必要がありますが。
>


データのボリュームのことを考えると、
国際化に対応させて、プログラムを書き、システムを構築した方がいいのではないかと思います。
たとえば、JAVAでいうと、地域と言語をワンセットにして国際化対応を考えていますが、
それに対応させてプログラムもリソース文字列をつかい、DBも分ける。


また、以前100万人規模のDBを設計・コーディングしたことがありますが、
ボリュームとスピードをかねそなえるにはユーザー中心のデータ分割を考慮することになりました。
今でいう「マイ・・・」です。


 41 From: shogowatanabe@

te: 2001年3月2日(金) 午後5時21分
Subject: Re: [nam-project] $BO"Mm!](J eGroupsWEB $B>e$NJ8;z2=$1(J 3


    渡辺彰吾です。

「メーセージ」の項目にある「メッセージのまとめ読み」
でメッセージをまとめて読むと、文字化けしていません。


 42 From: shogowatanabe@
Date: 2001年3月2日(金) 午後5時51分
Subject: [nam-project] $BDs0F!]5;=Q(J/$B4IM}(J6


    渡辺彰吾です。

みなさん、ありとうございます。

>> >具体的な仕事は、
>> >1.物理的なサーバーの構築
>>
>> ウェブホスティングですが、
>> 「Webhosting.co.jp」http://www.webhosting.co.jp/index.htm
>> はどうでしょう。
>> インド人の5人の方がプログラム作成としてかかわっています。
>
>これ、いま見てたんですが、Servletも使えていいんじゃないでし
>ょうか。ただお金のこともありますし、事務局でもサーバーの移転
>を考えているというようなことも聞いていますから、そのへんどう
>でしょう。
>
>ここだと、DBMSがmSQL 2.0.3 / mySQL 3.23.24
>Databaseですよね。DBI経由の問題はないのかな。
>トランザクションとか大丈夫でしたっけ。

>将来的にはJ2EEをいれる必要があります。
>JAVA版がほんとに開発されれば。

>ここだと、DBMSがmSQL 2.0.3 / mySQL 3.23.24
>Databaseですよね。DBI経由の問題はないのかな。
>トランザクションとか大丈夫でしたっけ。

実際にそこで運用するかどうかは別にして、上記の条件に適合
するか(できなければ対応してもらえるかどうか)問い合わせてみますが、よろしいですか?


>したがって、本格的な会員管理システムを構築しようとすると、大幅な
>変更が必要になると思いますから、先行するnamプロジェクトでは現状
>のテーブル構造を気にする必要はないと思います。

了解しました。
1対多であること、独立性をもたすことを考慮して、クエリーを作ってみました。
http://shogowatanabe.net/
ご参照下さい。

>
> >技術畑のひとは(できればそうでない人も)
> >http://sacral.c.u-tokyo.ac.jp/~ken/gets/tamatebako.html
> >の3節はぜったいに読んでください。
> >もちろん、これが絶対ということではないですよ。
> >寄付をうけつけて開発者の配分しますので、そのへんのあたり
> >をなぜしなければいけないのか、どうやるのか(4−3)はおさえてください。
> >このへんについてはご意見をお待ちしています。
>
> 読みました。ユースケース図を書いて理解しようとしています。
>
> もしよければ、その図ができたらぼくにも見せてください。

できたら、ご参照下さい。


 43 From: ippei hozumi  <ipfr_cat@>
Date: 2001年3月2日(金) 午前11時21分
Subject: Re: [nam-project] 提案−技術/管理5


    ほづみです。

いろいろ、資料が出てきました。

1) 阪口さんの現状報告。
2) 事務局からは、現在のMLの登録の手順を送ってもらってます。
3) あと、現在事務局で使っているACCESSのフォームも以前送って
   もらったのを持っています。
4) それから鈴木健さんからは、バグリストのアドレスを教えても
   らっています。
5) それと、いちおうcsvでソースをダウンロードしました。

鈴木健さんの「チャット」はすこしお休みして(といっても一回メ
ールを送っただけだけど)、わたしの一番得意な、頭を使わなくて
いい整理なんぞをやろう、思います。

それで、質問および提案ですが、

1) 渡辺さんにはサーバーのこと頼んでいいでしょうか。いちおう
   ある程度独自に動いて見通しをたてるということで。事務局に
   もぼくのほうでメールを出しておきます。
2) それから、鈴木さんの指示のあったページですが、あれをクリ
   アするっていうのは、どういう意味なのか教えてもらえますか。
   そんなこともわかんねえのか、と思われるかもしれませんが、
   ぼくはあまりオープンな開発というのをやったことがないんで
   すよね。ひと世代まえの人間ですから。
3) あと、まえにも書きましたが、このMLには、技術/管理とい
   うことで、なん人かおられますが、やはり、あとひとりふたり
   ほしいという気がしてます。NAM-COMPUTERのほうで、サーバー
   がらみのこととか運営レベル、もちろんコーディングやその他
   いろいろPUSHしてみることはできると思います。いちおう、ほ
   っておくとぼくは勝手に動いちゃうという困ったひとなので、
   この点に関してレスをお願いします。


以上です。よろしく。

穂積一平
ipfr_cat@d...

http://home.interlink.or.jp/~ipfr_cat/


 44 From: 高瀬幸途  <LEQ04254@>
Date: 2001年3月2日(金) 午後9時30分
Subject: Re: 自己紹介


    センター事務局長の高瀬幸途です。

遅まきながら、自己紹介させてもらいます。
関心系は協同組合と第三世界/対抗運動です。
いろんな事情から、センター事務局長を担当しています。
皆さんの議論を、とりあえず、読み続けることだけは、最低限の仕事だと思って
います。よろしくお願いします。

で、本日は早速に事務的なことで西部さんにお願いがあります。
一つは、センター事務局(info@n...)をこのMに加えていただきたいので
すが。私のみならず、事務局メンバーに助力を求める場面が生じるかと思います
ので。
いま一つは、センター評議会へ、適当な段階で、このプロジェクトの進み具合を
お知らせ願いたいのですが。今の時点でいえば、メンバー数など。その際、鈴木
腱さんがNAM非会員であることも案内なさったらどうでしょう。今後の様々なプ
ロジェクトでも、非会員の有力参加者が加わるでしょうし、その先例として意味
のあることだと思います。
ご多忙のところ恐縮ですが、よろしくお願いします。

という次第で、この先も、事務方としての仕事を努める所存です。
以上。


 45 From: Ken Suzuki  <ken@>
Date: 2001年3月2日(金) 午後9時37分
Subject: Re: [nam-project] 提案−技術/管理7


    こんにちは。鈴木です。

 >実際にそこで運用するかどうかは別にして、上記の条件に適合
 >するか(できなければ対応してもらえるかどうか)問い合わせてみますが、よろしいですか?

ぜひよろしくお願いします。

In message "Re: [nam-project] 提案−技術/管理5",
ippei hozumi wrote...
 >それで、質問および提案ですが、
 >
 >1) 渡辺さんにはサーバーのこと頼んでいいでしょうか。いちおう
 >   ある程度独自に動いて見通しをたてるということで。事務局に
 >   もぼくのほうでメールを出しておきます。

渡辺さんにサーバー担当をお願いするのはぼくも賛成です。

 >2) それから、鈴木さんの指示のあったページですが、あれをクリ
 >   アするっていうのは、どういう意味なのか教えてもらえますか。
 >   そんなこともわかんねえのか、と思われるかもしれませんが、
 >   ぼくはあまりオープンな開発というのをやったことがないんで
 >   すよね。ひと世代まえの人間ですから。

ぼくもはじめてなんですよ。
一応、優先順位が色の濃さで表現してあります。(濃いほうが先決)
できればその順で、次々と報告されているバグを解決してほしいです。
それから改善点も。

解決したら、CVSでコミットして
gets-devのメーリングリストで報告し、
問題なさそうならそのまま、問題があればみんなで
また書き直したり、元にもどします。

 >3) あと、まえにも書きましたが、このMLには、技術/管理とい
 >   うことで、なん人かおられますが、やはり、あとひとりふたり
 >   ほしいという気がしてます。NAM-COMPUTERのほうで、サーバー
 >   がらみのこととか運営レベル、もちろんコーディングやその他
 >   いろいろPUSHしてみることはできると思います。いちおう、ほ
 >   っておくとぼくは勝手に動いちゃうという困ったひとなので、
 >   この点に関してレスをお願いします。

1分野2人はいたほうがいいので、確かに必要だと思います。

以下、現時点の僕以外のメンバーの情報をまとめました。

鈴木泰生 fwih0677@m...コンピュータ,NAM東京 忙しい。以下のプログラミングでお手伝い
使える言語はJava,VB,perlなどです。
namプロジェクトでは、独自サーバで運用する
ということをきいたことがあるのですが、
そのばあい、apache + tomcat + Java + PostgreSQL

穂積一平ipfr_cat@d... NAMコンピュータ,NAM大阪 できるけど物理的にきつい。こういうのをして欲しいと言ってほしい
コンピュータ関係の経歴や技術面での自己紹介は、
http://home.interlink.or.jp/~ipfr_cat/
を見てください。それとすこしまえからLINUX JAPANと
いう雑誌にFPCというフリーのパスカルコンパイラの記事を連載
で書いています。(宣伝です)

湯本裕和yumoto@h... NAM教育,NAM名古屋? ソフトはかけない
エディターやリレーショナルデータベースのアプリケーションは使いこん
でいると思いますが、C などを使ってソフトを書く経験はありません。

渡辺彰吾shogowatanabe@n... perlができないので参加できない
NAM-LETS,コンピュータ,芸術,NAM大阪
プロジェクト内容:「技術/管理」
工程:コーディング
言語:JAVA+SQL+XML+SMIL(スマイル)

阪口弘人sakaguchi@h... NAMコンピュータ,NAM東京 オブザーバー
三年前に自分たちで立ち上げたソフトハウスでシステムを開発していま
す。現在36歳です。
主に関わっている関心系はコンピュータ/インターネットです。

渡辺さんはperlができないとのことですが、サーバー全体の管理のほうに
まわってもらうのはいかがでしょう。ここはもう一人は兼任であっても必要です。
鈴木さんと穂積さんがGETS担当ということで、湯本さんはサポート方面でしょうか。
阪口さんはNAMのDBとの統合方面。

GETSそのものの導入はそれほど大変じゃありません。
暇をみつけてちょこちょこやればできる程度です。
NAM用に特別に必要な機能がどの程度なのか洗い出してみましょう。
そこによって大変さが決まってくると思います。
この段階ではperlのできるお二人がお忙しいということで、
perlができて比較的時間のある人がいたほうがいいですね。

あくまで、現時点での情報をたよりにしたものなので、
ご意見をください。それから、各人が互いの得意分野やレベルを理解するために、
ほづみさんのようにこんな仕事しました、というのがあれば紹介しあいましょう。

ぼくは以前お話したように、UNIXの1ユーザレベルです。
関係ありそうなプログラミング言語はC、C++、perl、JAVAです。
サーバープログラミングはこのために覚えたくらいなので、
まあ素人に毛がはえたくらいだと思ってください。
ミッションクリティカルなシステムどころか、業務用のシステムを
構築したこともありません。趣味でCGIをちょこちょこ書いているくらいです。


 46 From: yumoto  <yumoto@>
Date: 2001年3月2日(金) 午後11時40分
Subject: 質問−400人か10万人か?4


    宮地さんこんにちは、湯本です。

> たとえば、ぼくだと『天然酵母パン』を簡単に提供できちゃうわけです。

つは、わたしも天然酵母パンを焼いてます。 二人で同業者組合でもつ
くりましょうか。まだほかにもいらしゃるかも知れませんね。神保町と
いえば古本屋、 NAM といえば天然酵母のパン屋、というぐらいに仲間
を増やして、 NAM 天然酵母、というグループをつくったりして。

さて、本題です。
> いくらシステムが完璧に出来あがっても、実際にnamが流通しなければ意味
> がないんで、この辺のことをどう考えたらよいのか、みなさんのご意見をお聞
> かせください。

このことを、考えているのですが、

システムの問題として
(1)  nam  の通貨としてのデザイン
(2) コンピュータ上の、GETS としてのデザイン

活用の問題として
(3) ひろい意味の商業活動のデザイン
(4) ひろい意味の投資活動のデザイン

というように分けて考えたらどうでしょうか。
活用の問題についていえば、

サラリーマンや家庭の主婦が nam を稼ぎ出すため、
・あたらしい事業やプロジェクトを立ち上げること
・既存の事業体を NAM 的なものに変えること
が必要です。

それは、
ニュースクールがオールドスクールに勝ち、
NAM 福祉が資本福祉に勝ち、
協同組合が資本に勝ち、
リナックスがウィンドウズに勝ち、
有機農業が資本農業に勝ち、
天然酵母パン屋が資本パン屋に勝つ、
 ……
という現実をつくることになります。
個人的には、勝たずとも、なんとか生きていければいいのですが、地球
環境のことなどを考えると、やはり勝たなければいけないと思います。)

れらの活動を支えるには、ひろい意味の商業活動、投資活動によるバッ
クアップが不可欠です。

「namファンドなどスキームの検討」が、この nam プロジェクトの運営
/規約チームの作業として、西部さんがあげておられますので、この作
業の一環として、いまのうちから商業活動、投資活動について、考えて
おいたらいいと思います。)

ままで、 NAM - LETS のMLで、投資のこと、商業活動のことを書きか
けていましたが、わたしの希望としては、西部さんが議長役となる討議
スレッドで、このプロジェクトのメンバーで、議論を積み上げることが
できたらと思います。西部さん、いかがでしょうか。

以上です。それではまた。
yumoto hirokazu


 47 From: go  <afake908@>
Date: 2001年3月3日(土) 午後8時37分
Subject: Re: [nam-project] 質問−400人か10万人か?4


    湯本さん、こんにちわ。宮地です。

NAM天然酵母、面白いですね。

ぼくの理解では、NAMの本来的な活動は、内在的な対抗を可能にするための、
会員による超出的な企業(協同組合・NPO・フリースクールなどのプロジェクトを
も含めた)の創出と、組織としてのNAMによるそれら企業への支援にあると思って
います。(だから湯本さんの言われるNAM天然酵母も、可能性として、考えていけ
るわけですね。)

このnamプロジェクトによるLETS構築は、そのための血流づくりということだ
と認識しています。

> システムの問題として
> (1)  nam  の通貨としてのデザイン
> (2) コンピュータ上の、GETS としてのデザイン
> 活用の問題として
> (3) ひろい意味の商業活動のデザイン
> (4) ひろい意味の投資活動のデザイン
>
> というように分けて考えたらどうでしょうか。

システムが血管で、nam循環スキームが血液なわけですね。

けれど、LETSのMLでも問題によくなることですが、地域通貨は補完通貨と呼ば
れたりす
るように、それだけでは、資本主義に対抗するものとはならないわけです。(nam
をはじめとする地域通貨が円に変わる完全なる決済通貨になれば別でしょうが)

問題は、血の循環をよくする方法ですよね。

> 活用の問題についていえば、
>
> サラリーマンや家庭の主婦が nam を稼ぎ出すため、
> ・あたらしい事業やプロジェクトを立ち上げること
> ・既存の事業体を NAM 的なものに変えること
> が必要です。

ぼくもその必要性を考えています。ただ、これは関心系LETSの守備範囲からは、
少し
ずれていくんじゃないか?とも思います。

だから、NAMの新しい関心系として、起業とかNPO立ち上げの具体的なノウハウ
などの情報を公開していくようなものも必要になってくるんじゃないかな、と思った
りもします。

> それは、
> ニュースクールがオールドスクールに勝ち、
> NAM 福祉が資本福祉に勝ち、
> 協同組合が資本に勝ち、
> リナックスがウィンドウズに勝ち、
> 有機農業が資本農業に勝ち、
> 天然酵母パン屋が資本パン屋に勝つ、
>  ……
> という現実をつくることになります。
> 個人的には、勝たずとも、なんとか生きていければいいのですが、地球
> 環境のことなどを考えると、やはり勝たなければいけないと思います。)
>
> れらの活動を支えるには、ひろい意味の商業活動、投資活動によるバッ
> クアップが不可欠です。
>
> 「namファンドなどスキームの検討」が、この nam プロジェクトの運営
> /規約チームの作業として、西部さんがあげておられますので、この作
> 業の一環として、いまのうちから商業活動、投資活動について、考えて
> おいたらいいと思います。)

そこで、おいそがしいのに申し訳ないんですが、高瀬さんにお聞きしたいと思いま
す。
高瀬さんは、今現在、ペルーでの有機コーヒー豆栽培の協同組合つくりを企画されて
おられれるわけですが、そのプロジェクトに対して、namファンドが、どのように
支援していけるのか、あるいは、どのような形の「投資」(?)が望ましいのか、と
いうようなことをお聞きできればと思います。

あと教育系のフリースクールプロジェクトでのnamファンド活用のお話も聞ければ
いいんですが。山住さんに投稿して頂くと言うのは、無理なんでしょうか。
 

投稿者: Shogo Watanabe  <shogowatanabe@n...>
Date: 2001年2月3日(土) 午後9時28分
タイトル: Re: [nam-project] 提案−技術/管理 8


  渡辺彰吾です。

Ken Suzuki wrote:

>  >実際にそこで運用するかどうかは別にして、上記の条件に適合
>  >するか(できなければ対応してもらえるかどうか)問い合わせてみますが、よろしいですか?
>
> ぜひよろしくお願いします。


問い合わせました。
以下、その内容です。ご確認ください。

 

御社のWebHostingサービスに興味をもっております渡辺彰吾というものでござい
ます。

私が所属しますプロジェクトで御社のWebHostingサービスをできれば利用したい
と考えております。
そこで、実際に御社のサービスでこのプロジェクトが運営可能かどうかを質問し
たいと思い、メールを送らせていただきました。

言語はperlで、システム的にはperl→DBI→PostgreSQLです。
DBI通しているので、トランザクション処理可能なDBなら一応使えるはずですが、
もしかしたらPostgres特有のSQL文つかってるかもしれません。
DBI経由の問題はありませんか、トランザクション処理は可能ですか?

perlで安定版まで開発が進んだら、現在のところJAVAで次世代バージョンを開発しようと思っています。
J2EEです。

ご返事のほどよろしくお願いいたします。

 

>
>  >
>  >1) 渡辺さんにはサーバーのこと頼んでいいでしょうか。いちおう
>  >   ある程度独自に動いて見通しをたてるということで。事務局に
>  >   もぼくのほうでメールを出しておきます。
>
> 渡辺さんにサーバー担当をお願いするのはぼくも賛成です。


了解しました。

> 渡辺彰吾shogowatanabe@n... perlができないので参加できない
> NAM-LETS,コンピュータ,芸術,NAM大阪
> プロジェクト内容:「技術/管理」
> 工程:コーディング
> 言語:JAVA+SQL+XML+SMIL(スマイル)
>
> あくまで、現時点での情報をたよりにしたものなので、
> ご意見をください。それから、各人が互いの得意分野やレベルを理解するために、
> ほづみさんのようにこんな仕事しました、というのがあれば紹介しあいましょう。


あと、業務内容を加えます。
ネットワークデータベース(WebDB、WANDB、LANDB)をおもに担当してきました。
工程は一通り経験してきました。
現在のソフトの内容はインテリアシュミレーションソフトです。以前は、地理情
報システム、販売・製造管理、マルチメディアソフトなどです。また、作品を製
作してきました。

>


49 投稿者: yasuo suzuki  <fwih0677@m...>
Date: 2001年3月4日(日) 午前10時20分
タイトル: RE: [nam-project] 提案−技術/管理7


  鈴木泰生です。

現在J2EEでシステム開発を行っています。

JavaでJ2EEを使うというお話が出ているようなので…。

J2EEを使うには、EJBコンテナを実装したAPサーバが
必要ですが、レンタルサーバ等でこのような環境を実現
するのは現状では不可能ではないかと思います。
自前の専用サーバ上でもデバッグ自体容易なことでは
ありませんし、EJBのインストール及びセッティングは
リモートではできません。

現状で実現可能な選択としては、servletからJDBC直でDB
接続という方法ではないかと思います。つまり、EJBを使わな
いということです。
CGI→servlet+JSPにするだけでもパフォーマンスは大幅に向上
します。セッション管理も楽になりますし。1000人規模のシステム
であれば楽勝だと思いますが、いかがでしょうか。


鈴木泰生
fwih0677@m...


50 投稿者: Ken Suzuki  <ken@s...>
Date: 2001年3月4日(日) 午前11時44分
タイトル: Re: [nam-project] 提案−技術/管理8


  こんにちは。鈴木です。

 >J2EEを使うには、EJBコンテナを実装したAPサーバが
 >必要ですが、レンタルサーバ等でこのような環境を実現
 >するのは現状では不可能ではないかと思います。

最初自前サーバーがいいのではないかと提案したのも
それが理由です。

 >自前の専用サーバ上でもデバッグ自体容易なことでは
 >ありませんし、EJBのインストール及びセッティングは
 >リモートではできません。

OSがNTですか?
UNIXでもリモートが難しいでしょうか。

 >現状で実現可能な選択としては、servletからJDBC直でDB
 >接続という方法ではないかと思います。つまり、EJBを使わな
 >いということです。
 >CGI→servlet+JSPにするだけでもパフォーマンスは大幅に向上
 >します。セッション管理も楽になりますし。1000人規模のシステム
 >であれば楽勝だと思いますが、いかがでしょうか。

EJBを使ったプログラミングと使わないプログラミングの差
がどの程度がまだちゃんと分かっていないのですが、
GETSでJAVA版をつくるとしたら、EJBをかませるのと
かませないのを簡単に切り替えることは可能でしょうか。
EJBを利用すれば環境に依存しないシステムとして
配布しやすいとふんでいたのですが。


51 投稿者: Ken Suzuki  <ken@s...>
Date: 2001年3月4日(日) 午後0時02分
タイトル: Re: [nam-project] 提案−技術/管理9


  こんにちは。鈴木です。

 >EJBを使ったプログラミングと使わないプログラミングの差
 >がどの程度がまだちゃんと分かっていないのですが、
 >GETSでJAVA版をつくるとしたら、EJBをかませるのと
 >かませないのを簡単に切り替えることは可能でしょうか。
 >EJBを利用すれば環境に依存しないシステムとして
 >配布しやすいとふんでいたのですが。

あと、サーバー側の環境だけじゃなくて、例えばGnutellaクローン
にかませるというように、クライアントアプリに組み込んだり、
外部のサイトからロジックをたたくという意味でもEJBを使うのが
いいかな、と思っていました。

ただ、現時点ではフリーでEJB2.0が実装されているのはまだ
ないですよね。おそらくJAVA版が安定して使えるようになるのは、
早くて今年の夏以降になります。

とりあえずJAVA版は考えずに、後からサーバーを移行するという
のもありでしょう。レンタルサーバーはrootを人がもっているという
点で、何か気持ち悪いですよね。みんなレンタルサーバーで
そういう情報を扱う仕事もしているのでしょうか。


52 投稿者: yasuo suzuki  <fwih0677@m...>
Date: 2001年3月4日(日) 午後1時02分
タイトル: RE: [nam-project] 提案−技術/管理10


  鈴木泰生です。

>最初自前サーバーがいいのではないかと提案したのも
>それが理由です。

多分、J2EEを使おうと思ったら、自前サーバしかないと思います。

>OSがNTですか?
>UNIXでもリモートが難しいでしょうか。

現在やっているのはINTERSTAGEという富士通のAPサーバですが
NT,solaris両方でリモートは使えません。
他のAPではできるものもあるかもしれませんが、あまり期待しない方が
良いと思います。
J2EEはあくまで仕様ですから、実装は各ベンダーに任されています。
つまり、IBMならWebSphere + VisualAgeEE のセットでないと開発すら
できないのが現状です。他社も同様だと思います。
雑誌などでは、J2EEによってJavaアプリケーションのポータビリティが
良くなるということが書かれていますが、現状ではとてもそうは思えませんし
開発コストがとてつもなく高くなるだけでメリットは少ないと思います。
とりあえずアプリケーション間の通信に CORBA を使っているということ
だけのことです。

>EJBを使ったプログラミングと使わないプログラミングの差
>がどの程度がまだちゃんと分かっていないのですが、
>GETSでJAVA版をつくるとしたら、EJBをかませるのと
>かませないのを簡単に切り替えることは可能でしょうか。

EJBを使った場合と使わない場合では開発期間、コスト共
に相当の差がでるだろうと思います。
また、EJBを噛ました場合と噛まさない場合の両方を開発
するとなると二度手間になってしまいます。それをやることは
可能ですが、現実的な選択だとは思えません。


鈴木泰生
fwih0677@m...


53 投稿者: Ken Suzuki  <ken@s...>
Date: 2001年3月4日(日) 午後1時25分
タイトル: Re: [nam-project] 提案−技術/管理11


  こんにちは。鈴木です。

 >現在やっているのはINTERSTAGEという富士通のAPサーバですが
 >NT,solaris両方でリモートは使えません。
 >他のAPではできるものもあるかもしれませんが、あまり期待しない方が
 >良いと思います。
 >J2EEはあくまで仕様ですから、実装は各ベンダーに任されています。
 >つまり、IBMならWebSphere + VisualAgeEE のセットでないと開発すら
 >できないのが現状です。他社も同様だと思います。
 >雑誌などでは、J2EEによってJavaアプリケーションのポータビリティが
 >良くなるということが書かれていますが、現状ではとてもそうは思えませんし
 >開発コストがとてつもなく高くなるだけでメリットは少ないと思います。
 >とりあえずアプリケーション間の通信に CORBA を使っているということ
 >だけのことです。

INTERSTAGEはEJB1.1ですよね。
2.0とかなり違うという話を聞いたのですが、どの程度か分かりますか?

オープンソースだと

In message "Re: [gets-dev:0067] Re:Re:今後の短期的展開",
Ken Suzuki wrote...
 >こんにちは。鈴木です。
 >
 > >しかし,このクラスは,EnterpriseJavaBeans(EJB)を使う形で書き直すべき,
 > >と思います.そのほうが,開発と動作の効率が良くなるはずです.
 > >しかし,EJBの仕様には1.1と2.0があって,それぞれ,かなり大きく違います.
 > >また,1.1にせよ2.0にせよ,準拠したのサーバが普及していなくて…という感じ.
 > >悩ましいですな.後日,いろいろ実験しながら,ちょっと考えてみます.
 >
 >2.0ってFinal Draftが10月26日にでたばっかなんだね。
 >enhydraというのがフリーで一番有力なアプリケーション・サーバみたいだけど、
 >これは1.1準拠らしいよ。
 >http://enterprise.enhydra.org/project/aboutProject/EEAS.html#ejb
 >
 >The EJB Container Service provides full EJB 1.1 Container support using the JOnAS 2.0 EJB Server
 >
 >Goal features of this service are:
 >improved CMP support (capability to handle complex O/R mapping, caching, migration towards EJB 2.0 Pluggable Persistence Manager)
 >
 >ということで。

などを待つことになると思います。

 >EJBを使った場合と使わない場合では開発期間、コスト共
 >に相当の差がでるだろうと思います。
 >また、EJBを噛ました場合と噛まさない場合の両方を開発
 >するとなると二度手間になってしまいます。それをやることは
 >可能ですが、現実的な選択だとは思えません。

EJBのほうが開発期間がかかりますか。
それは学習時間ということですよね。
一回覚えたら、かえって楽にならないと、ほんとに使う意味がない。


54 投稿者: yasuo suzuki  <fwih0677@m...>
Date: 2001年3月4日(日) 午後3時31分
タイトル: RE: [nam-project] 提案−技術/管理12


  鈴木泰生です。


>INTERSTAGEはEJB1.1ですよね。
>2.0とかなり違うという話を聞いたのですが、どの程度か分かりますか?

EJB2.0を使ったことがないので何とも言えないところですが、
EJBの中でもDBを担当するEntity Beanに大きな変更があると
聞いています。Entity BeanもCMPとBMPというのがありますが
主にCMPの機能強化が大きいらしいです。それは裏を返せば
EJB1.1でのCMPがあまりにお粗末で使い物にならないためだ
と思います。

>EJBのほうが開発期間がかかりますか。
>それは学習時間ということですよね。
>一回覚えたら、かえって楽にならないと、ほんとに使う意味がない。

学習時間ということもありますが、デバッグやテストが困難であること
も大きいですね。EJBコンテナを媒介することによってポータビリティ
を上げるということはわかるのですが、そのことによって、逆にEJB
コンテナがブラックボックス化してしまうということがあります。
また、EJBだけではほとんどデバッグできませんから、サーブレット
等のクライアントと実際に接続して動かさないとだめということです。
しかも、まめにログを吐かすぐらいしか方法がありません。
とても開発効率が良いとは言えないと思います。


鈴木泰生
fwih0677@m...


55 投稿者: ippei hozumi  <ipfr_cat@d...>
Date: 2001年3月4日(日) 午後1時29分
タイトル: Re: [nam-project] 質問−400人か10万人か?4


  ほづみです。

このメールはここに返信していいのかどうか、わかりませんでした
が、とりあえず・・・。

今日、ちょっと自宅のPCにGETSを入れて動かしたりしていました。

それで気づいたのですが、これはやはり、いちどみなさんにも実際
に試してもらって、NAMでカスタマイズするGETSの仕様として、メ
ンバーの登録画面や売買の登録など、どんな項目が必要なのかチェ
ックしてもらったほうがいいのではないかと思いました。

GETSのお試し版が鈴木健さんのページにあります。

http://sacral.c.u-tokyo.ac.jp/~ken/cgi-bin/gets/demo/gets.cgi

宮地さん、湯本さん、あるいは他のひとも「お試し版」の項目等の
nam対応にするときの過不足、あるいは一般的なことでも気づいた
ことを教えてもらえるといいんじゃないかな。

個人情報の登録は一般的なものなので、ぼくなんかでもわかるんで
すが、取引関係になると結構複雑でいろいろ意見があるんじゃない
かと思います。

それと、やはり取引のときの手順とかやり方が初めてだととてもわ
かりずらいです。そういうマニュアルというか手引きも必要かなと
も思いますが、いかがでしょう。

よろしく、お願いします。

 

穂積一平
ipfr_cat@d...

http://home.interlink.or.jp/~ipfr_cat/


56 投稿者: go  <afake908@o...>
Date: 2001年3月5日(月) 午後5時41分
タイトル: Re: [nam-project] 質問−400人か10万人か?4


  宮地です。

> それで気づいたのですが、これはやはり、いちどみなさんにも実際
> に試してもらって、NAMでカスタマイズするGETSの仕様として、メ
> ンバーの登録画面や売買の登録など、どんな項目が必要なのかチェ
> ックしてもらったほうがいいのではないかと思いました。
>
> GETSのお試し版が鈴木健さんのページにあります。
>
> http://sacral.c.u-tokyo.ac.jp/~ken/cgi-bin/gets/demo/gets.cgi
>
> 宮地さん、湯本さん、あるいは他のひとも「お試し版」の項目等の
> nam対応にするときの過不足、あるいは一般的なことでも気づいた
> ことを教えてもらえるといいんじゃないかな。
>
> 個人情報の登録は一般的なものなので、ぼくなんかでもわかるんで
> すが、取引関係になると結構複雑でいろいろ意見があるんじゃない
> かと思います。
>
> それと、やはり取引のときの手順とかやり方が初めてだととてもわ
> かりずらいです。そういうマニュアルというか手引きも必要かなと
> も思いますが、いかがでしょう。

ということなので、穂積さんの「春の七草」を買うことにしました。

で、ひさしぶりに取り引きをしようとしての感想ですが、確かにわかりにくいです
ね。初めての人だとかなり戸惑うでしょう。

GETSの手順を考えてみると、
「メンバー登録」→「商品取り引き(提供します/求めます)」    ⇒登録作業
→「取り引き申し込み」→「約束成立」→「実際の取り引き」   ⇒取り引き作業
→「取り引き登録」→「取り引き登録成立」→「namの移動」   ⇒nam移動
作業

登録作業は除くとして、GETSにおいて、商品交換は、売り手と買い手との間で
「取り引き作業」「nam移動作業」の二段階の作業が必要だというわけですね。こ
の作業はメールのやり取りで行われるわけですから、どこかの段階で滞ってしまう
と、いつまでも「取り引き」「や「nam移動」が成立しないことになります。

こういったことは、初めての場合、なかなか理解しにくい。実際ぼくもはじめておこ
なったときに、よく理解できずに、鈴木さんにメールを送って教えてもらった覚えが
あります。
だから、穂積さんが言われるように、こういった手順の説明をいかにわかりやすくす
るか、ということが、かなり重要になると思います。

それからリストアップは、メンバリストーの場合、検索機能は必要だと思います。
現在、ぼくはGETSにおいて「−600」です。今日、穂積さんに「取り引き申し
込み」を行いましたが、その場合、穂積さんが、ぼくの取り引き状況を簡単に検索で
きるほうがよいでしょう。400名とはいえ、だらだらと続くリストから探し出すと
いうのは面倒です。

それから「商品・サービス」のカテゴリー化は必要でしょうし、検索機能もついてい
れば便利だと思います。

いまのところ、思いつくのは、これくらいです。


57 投稿者: ippei hozumi  <ipfr_cat@d...>
Date: 2001年3月5日(月) 午前10時55分
タイトル: Re: [nam-project] 提案−技術/ 管理12


  ほづみです。

現在、NAMで利用しているサーバーの乗り換え調査については、事
務局の日向さんが精力的に取り組んでおられます。

簡単に流れをいうと、

2月の初旬にFreeMLのサーバーで何回か不具合が発生し、継続的な
利用に対する不安が発生したことが最初の動機で、日向さんからNA
M-SYSTEMのMLに相談等のメールがありました。

スケジュール的には「できれば3月中に準備を終え、4月から本格
的に稼動できればと、希望しています」([nam-system:0083])との
ことです。

詳細は以下の文面を読んでいただくとして、概括的な意見を述べる
と、

1)日向さん(事務局)が主に想定されているのは、MLと会員登録の処
  理。
2)したがって、nam-projectとしてGETSシステムで必要となる要件
  を、日向さんに提示して、絞り込んでもらってもいいのではない
  か。
3)できれば、GETSでの基本情報と現状動いている会員情報は重複す
  る部分が多いので、処理の流れを整備したほうがいいのではない
  か。
4)最悪、MLとは同一サーバーで運営できなくても、3)の部分は独立
  のDBを構築したほうがいいのではないか。

と思います。個人的な感想では日向さんのサーバー検討案がかなり
進展しているので、それを生かすかたちで動いたほうが効率的だと
考えます。

上の意見、およびGETSシステムで要請されるサーバーの条件を簡略
明瞭に再度、確認報告してもらえれば、ありがたいです。

それと、鈴木泰生さんがいま新規会員の登録のCGIを作成しておら
れますが、そのあたりのかねあいからも泰生さんの意見をいただけ
れば参考になるかと思います。

------------------------------------------------------
事務局の日向さんの中間的なまとめが以下のメールで発信されてい
ますので、それを転記します。関係の薄いと思われるところは削除
しましたが、ほぼそのまま全文です。かなり長いですが内容的には
濃いものなので一読お願いします。

1) Subject: [nam-system:0111] 事務処理−MLシステムとサーバ
   移転について/概況報告
2) Subject: [nam-system:0113] MLシステムとサーバ移転につい
   て/クボタとアイル比較
3) Subject: [nam-system:0116] MLシステムとサーバ移転につい
   て/クボタのサーバ
4) Subject: [nam-system:0118] サーバ移転/クボタとアイル比較
   /訂正


--------------------------------------------------------
Date: Sat, 03 Mar 2001 03:17:52 +0900
Subject: [nam-system:0111] 事務処理−MLシステムとサーバ移
転について/概況報告

事務局の日向です。

ここ1週間ほどの間に、現在契約している

http://www.sakura.ad.jp/

からの移転先サーバ候補について、調査をしましたので報告いたします。

--以下報告-----------------------------------------------

まず、レンタルサーバ情報がまとまっているウェブページを探しま
した。

http://www.rentweb.org/

というところがあるのですが、その後これより数段優れた、

http://www.inter-eye.com/domain/

というページを見つけました。こちらは登録してあるレンタルサー
バの数が前者より圧倒的に多いのが特長です。

また、NAMの場合は、ウェブと並んで、あるいはそれ以上にMLの
機能が充実しているサーバでなければなりませんので、これについ
ては、

http://www.kt.rim.or.jp/~atsato/ml/mlprov.html

をまず参考にしました。

ここはML開設入門書の著者のページですが、ここのサイトの別のペ
ージに「メーリングリスト開設方法一覧」というページがあり、ML
開設のパターンを以下の8つに分類してあって、少なくとも私には、
基本事項の確認に役立ちました。その8つとは、

1)学校/職場のコンピュータによるサーバ立ち上げ

2)サーバを管理している人に開設してもらう

3)レンタルサーバを利用した本格運用

4)OCNを使ったサーバ構築

5)リムネットまたは川崎インターネットを利用して自分でMLを構築

6)契約しているプロバイダのML開設サービスを利用

7)ML開設プロバイダと契約

8)無料ML開設サービスを使う

だそうです。

このうち、現状で採用している8に代わりうる方法を、現在模索し
ているわけですが、とりあえず広く構えて選択肢を、

3) レンタルサーバを利用した本格運用
4) OCNを使ったサーバ構築
7) ML開設プロバイダ(有料でMLサービスを行なう業者)と契約

と考えてみました。

 ただ、このウェブページを読み進めたりして色々考えてみると、
については、高価な専用機材が必要で、その機材がどこまで汎用性
があるかわからない。

1)MLの管理等を結局すべて自前でやらなければならない。

また7)については、

2) ML専門サーバとはいっても信頼性と操作性が高まるだけで、現
   在のFreeMLを使っているのと本質的に変わらない。

3) それどころか当該MLプロバイダが採用しているMLエンジンMajor
   domo等のコマンドメールを覚えないとならないケース等の面倒
   が増える場合すらある。

というデメリットがあることがわかりました。ですので結局、4)と
7)の可能性はこの時点でオミットし、

3)レンタルサーバを利用した本格運用

の方向性で探すことにしました。

またMLについては、

http://msl.to/mail_list1.html

も参考になりました。

こちらは各MLの値段と登録人数制限等が要領よくまとめられていま
す。ここを見て初めてわかったのは、以下のようなことです。

1) 有料でMLを設ける場合、初期費用5000円程度と月々500円〜1000
   円程度がかかる。予想していたよりML開設費用の相場がかなり
   高いこと。
2) 有料MLといっても、別に自社製のMLソフトを使っているわけで
   はなく、結局大元のソフトはMajordomo等のMLソフトを採用して
   いること。
3) おそらく採用している各種MLソフトの機能的な制限によって、
   有料MLでも人数制限を設けているMLがほとんどだということ。
4) 下手な有料MLに引かれて安易に移行するよりは、まだしも現在
   の人数制限のないFreeMLやegroupsを使っていた方が、人数制限
   という点に限れば、問題がないこと。

上記のことがわかったので、まずはMLの人数制限という観点を重視
して、レンタルサーバを洗い出し直しました。すると、以前有力候
補として考えていた、

ファーストサーバーhttp://www.firstserver.ne.jp/

アイルhttp://home.isle.ne.jp/

のいずれもが、MLに1000人という人数制限を設けていることが判明
しました。

この段階ではこれらの2つのどちらかにしようかと思っていたので、
正直、ショックでした。

気を取り直し、別のサーバを探すと、以下の2つがMLの人数制限の
点も含めて良さそうということになりました。

IIJMC http://www.iij-mc.co.jp/

クボタシステム開発 http://www.kubota.ne.jp/

IIJMCの方は、1MLの人数の上限が3000人です。しかも「通知」機
能だけに絞った同報メールサービスだと9000人まで可能とWEBに書
いてあります。これはいいと思い電話取材をしてみると、しかしな
がら以下のデメリットが判明しました。

1) MLと別のホームページサービス(通常呼ぶレンタルサーバにあ
   たるもの)というのもやっていて、それと組み合わせることも
   可能だが、こちらの値段が10MBで月々10000円と、飛びぬけて高
   価なこと。
2) 値段が高い理由について「クオリティが高いということです
   か?」と質問すると「一応そういうつもりでおります」とのこ
   と。
3) 親会社がプロバイダということもあってか、会社側がセキュリ
   ティを優先しているため、用意されたCGIしか使えないこと。何
   か変わったことをやろうとすると、結局先方にお金を払って依
   頼してプログラム作成などをしなければならないこと。
4) IDとパスワードの発行が、10コにつき5万円と高価なこと。こ
   れだとたとえば会員400人それぞれにパスワードを発行した場合、
   それだけで200万円かかってしまうこと。
5) 「ML人数制限は、どうしても上限3000人なのか。それ以上は絶
   対に無理なのか」と聞くと「残念ながら3000人以上は無理」と
   のこと。

上記のデメリットが判明したので、IIJMCの可能性をこれ以上探る
のは、やめることにしました。

次にクボタシステム開発を検討しました。WEBページを見ると、以
前候補に挙げていたファーストサーバーの上級者向けサーバーとい
うことが書いてあります。同じクボタが個人向けにやっているのが
ファーストサーバーで、団体・企業向けがこちらのクボタシステム
開発のサービスとのことです。
コースは色々ありますが、中でも適当と思われるのが以下の2つで
す。

-----------------------------------------------------------
         初期費用   年間    1年目計-
-----------------------------------------------------------
・vServerスーパー  6万円    18万円   24万円
 機能は→ http://www.kubota.ne.jp/service/v_01.html 参照
 メールアドレス 無制限ID
 メールスプール容量 300MB
 コンテンツディスク容量 300MB
 電話サポート 無料

-----------------------------------------------------------
         初期費用   年間    1年目計
-----------------------------------------------------------
・rServerノービス  12万円   36万円    48万円
 機能は→ http://www.kubota.ne.jp/service/r_01.html 参照
 メールアドレス数 無制限ID
  メールスプール容量 ディスク容量の範囲で無制限
  コンテンツディスク容量 ディスク容量の範囲で無制限
  電話サポート 無料
  CPU Celeron 600MHz
  Memory 128MB
  HD 15GB


24万や48万円という数字は高いといえば高いですが、しかし専従の
事務局員を置いた場合の年間の人件費や事務所代を考えれば、けし
て高すぎないと思います。落合も同様の意見でした。

さらにWEBを見てみると、どうやらここはML登録を含めた面倒な操
作を行なう際に使う専用ソフト=[コンフィグレータ]を用意してく
れていることがわかりました。

http://www.kubota.ne.jp/service/config/s_index_full.html

これは助かります。これまでの取材で、MLの登録・解除について専
用ソフトを用意しているところは少ないことがわかっています。取
材した中では、

1) さくら  Majordomoのコマンドメールを覚える必要がある。
2) アイル  同じくコマンドメールでオーナーが行なう。
3) IIJMC ウェブから登録・削除できるが、1件ずつになる。まと
   めて登録削除するにはコマンドを覚える必要がある。

とのことでした。実は、結局コマンドを覚えるしかないのかと半分
以上覚悟を決め、『Majordomo Complete Guide』安田幸弘(毎日コ
ミュニケーションズ)という本も購入していたところでした。しか
しこのコンフィグレータがあれば、コマンドなど覚える必要はあり
ません。少々興奮しつつ電話をかけてみました。

以上を概況報告とし、有力候補であるクボタ・サーバの詳細は、次
のメールに譲ります。

------------------------------------------------------------

Date: Sat, 03 Mar 2001 03:21:06 +0900
Subject: [nam-system:0113] MLシステムとサーバ移転について
/クボタとアイル比較

事務局の日向です。

もう一度、クボタのサービスと料金表リンクを記しておきます。

http://www.kubota.ne.jp/service/v_01.html
http://www.kubota.ne.jp/service/r_01.html
http://www.kubota.ne.jp/charge/index.html

vserver:初年度=24万円 
rserver:初年度=48万円

これならrserverでもなんとかギリギリ出せる線かもしれません
(特にLETSがらみの話が具体化する状況になってくれば)

また、レンタルサーバ情報を検索できる

http://www.inter-eye.com/domain/

から取った、アイルのビジネスプランの表を画像で添付します。

ちなみにアイルのビジネスプラン(ただし容量は100MBしかない)
だと、

初期費用 9000円
基本料7900円×12月=9万4800円
15のML×5000円=7万5000
15のML×1000円×12月=18万円
----------------------------
     35万8800円

という初年度費用になります。

アイルは、ML設定料金が1MLにつき5000円、運営費が1MLについて
月額1000円かかるのが痛いですね。

アイルには、ビジネスプランの上にシルバープランというのもある
のですが、こちらは計算してみると以下のような数字になって、と
ても無理な価格だとわかりました。

初期費用5万円
基本料24800円×12月=41万7600
15のML×5000円=7万5000
15のML×1000円×12月=18万円
--------------------------
     72万2600円

-----------------------------------------------------------

Date: Sat, 03 Mar 2001 03:46:51 +0900
From: HinataYasuhiro <hinata@s...>
Subject: [nam-system:0116] MLシステムとサーバ移転について
/クボタのサーバ

改めて、クボタシステム開発についてレポートします。

最初に候補と考えている2つのコースについての情報を、もう1度
掲載しておきます。
---------------------------------------------------------
           初期費用   年間    1年目計
---------------------------------------------------------
 ・vServerスーパー  6万円    18万円   24万円
  機能は→ http://www.kubota.ne.jp/service/v_01.html 参照
  メールアドレス 無制限ID
  メールスプール容量 300MB
  コンテンツディスク容量 300MB
  電話サポート 無料

------------------------------------------------------------
           初期費用   年間    1年目計
------------------------------------------------------------
 ・rServerノービス  12万円   36万円    48万円
  機能は→ http://www.kubota.ne.jp/service/r_01.html 参照
  メールアドレス数 無制限ID
  メールスプール容量 ディスク容量の範囲で無制限
  コンテンツディスク容量 ディスク容量の範囲で無制限
  電話サポート 無料
  CPU Celeron 600MHz
  Memory 128MB
  HD 15GB


クボタに電話をしてみましたが、どうやら電話による質問等はあま
り歓迎しないようで、先方とひと悶着あった後にやっとテクニカ
ル・サポートができる人が不在なので折り返し電話をくれるという
返事をもらえました。あまり期待せずに待っていると、3分とたた
ないうちに電話が鳴りました。技術的なこともわかる日原さん(男
性)という方からでした。質問をしたところ、以下のことがわかり
ました。

長所:

1)ML設定・運営に追加料金は発生しない。

2)MLの人数制限は設定していない。

3)50アドレス程度の一斉登録も、コンフィグレータからできる。

4) IDやパスワードを無制限に発行できる。
(ただし、それぞれにディレクトリを作らねばならず、容量をもの
すごく食うので、こうした方法は薦めていないとのこと。同種の要
望に対しては、いくつかのIDとパスワードを発行してアクセス権に
よってそれらを使い分けることを推奨しているとのこと。たとえば
一般会員用のIDとパスはすべて共用にして、それとは別にML管理者
用ID&パスや事務局用ID&パスを設定しておくような方法。)

5) MLのLOGはデフォルトでは残らないが、残る設定にはできる。

6) MLの登録は手動モードと自動モードの切り替えができる。
手動モードは、管理者以外はML登録も解除もできない(センター評
議会MLや地域系ML向きと思われる)
自動モードは、MLに送付するコマンドさえ知っていれば、誰でも自
由に登録・解除できる(関心系ML向き。ただしこれは逆にいえば、
コマンドさえ知っていれば誰でも勝手に登録・解除できることにも
なる。この点については後の追加情報を参照しつつ、要検討。)

7)rserver(年36万円の方)なら、専用サーバなので大規模なデー
  タベースを置くことも禁じられていない。

短所:
1)vserver(年18万円の方)は、専用サーバではないので、大規模
  なデータベースをウェブに置くことは禁じられている(後述追加
  情報を参照)。
2)使用しているMLソフトは企業秘密なので教えられないとのこと。
3)コンフィグレータの、WEB上にある以上の詳しい画面は、契約し
  てからでないと教えられないとのこと。
4)全般的にウェブでの説明情報がアイル等に比べると貧弱なこと。
  これらも契約してからでないと詳しくは教えられないとのこと
  (後述追加情報も参照)。・サーバの残り容量は、コンフィグレ
  ータから見ることができるが、要らないLOG等を削除することは、
  ユーザーの知らせを受けて業者がやることになっている。
5)全般的に、IIJMCと同じく、システム構築サービスも込みで儲け
  ていこうという会社の姿勢がうかがえる。これはコンフィグレー
  タをユーザーに提供する姿勢と裏腹でもあり、一概に短所とは言
  えないかもしれないが、最初にこちらからやりたいことを提示し
  て細かいことを詰めておかないと、後々「この部分はユーザーは
  いじれないので、こちらで開発します。料金はいくらです」とい
  うような話の運びになるかもしれないという懸念は持った。


このときの電話取材でわかったのは、だいたい上記のようなことで
すが、同じ日の夜になって、理解できない点が出てきたので、疑問
点をinfo@k...宛に送っておきました。以下、それに対す
る先方からの返信を、追加情報として掲載します。

--追加情報--クボタからの返信--------------------------------

この度は弊社サービスをご検討いただき誠にありがとうございます。

ご質問いただきました件につき下記のとおり回答申し上げます。

> MLを使う場合、登録などについて、手動モードと自動モードが
> あるとのことでしたが、手動モードの場合は問題ないのですが、
> 自動モードにした場合、以下のような問題が生じるのではないで
> しょうか?
> つまり、
> ●たとえば、登録方法が、 
> "subscribe 自分のメールアドレス" というコマンドをMLア
>ドレスに送る、という方法だった場合、
> ●会員以外の人間が、そのコマンドとMLのアドレスを何らかの
> 理由で知ってしまったら、会員でない人間でも我々会員専用のM
> Lに入れてしまうのではないか?

 → ご指摘の通りでございます。

> さらに2点目ですが、もし、上記のケースが十分あり得るという
> 場合、MLを自動モードにしたままで会員以外が勝手にMLに入
> るのを防ぐために、以下のようなことができたらと思っています
> が、可能なのでしょうか?
>
> ●MLは自動設定のままにしておく。
>
> ●会員にはMLコマンドを教えない。
>
> ●会員がML登録(解除)をしたいと思った場合、まず共有ID
> とパスワードによって入れるWEBページに入る。
>
> ●そのページには、会員ならば任意に登録(解除)できる複数の
> MLの名前とチェックボックスがズラっと並んでいる。
>
> ●会員は、自分のメールアドレスを記入した上で、登録(解除)
> したいMLのチェックボックスをチェック。
>
> ●登録(解除)ボタンを押す。
>
> ●すると、自動的にMLにコマンドが送られ、これに伴って当該
> 会員に確認メールが届く。
>
> ●会員はこのメールにOKの手続きをして、ML登録(解除)が
> 完了する。

 → ご指摘のコマンドメールを送出するCGIを作成された場合、
結局は Webサーバーがフロムアドレスを詐称してメールを送出する
ことになりますので、好ましくないと考えます。

   (先程の他人の名前を騙るのと同じ行為ではないでしょうか?)
   また、弊社のエンジンが現行のバージョンで運用し続ければ
実現可能かもしれませんが、弊社のポリシーとして安定稼動を追求
し続けるために安定したバージョンへの移行を行なってまいります
ので保証の限りではございません。(コマンドメールは保証できる
と思われますが、詐称に関しては保証の限りではないという意味で
す。)
   またCGIを弊社で作成した場合は、エンジンとの直接対話が
可能ですので、実現できます。(この場合はエンジン側でコマンド
メールを受け付ける必要はありません。)

> 「vserverの場合は、データベースを置くようなことは遠慮いた
> だいている」といったことをおっしゃっていましたが、これは、
> たとえばCSVファイルを貯めていくよいうなことも禁じられて
> いるということでしょうか?
>
> 具体的には、下記のようなシステムの可能性も考えているのです。
>
> ●新規会員が申し込む
>
> ●定型文書を自動的に新規会員に送付するとともに、その会員の
> 申し込み情報を、テキストファイルやCSVファイル、あるいは
> MicrosoftAccessの形式で、ウェブ上に貯めていく(同時に事務
> 局にも送る)。

 → テキストファイル、CSVファイルは全サービスラインでご利
用いただけます。逆にAccess形式はご利用いただけません。@Seve
r(日向注:rserverより上のクラスの値段が高いサーバ)でご利用
いただけるエンジンはOracle等になります。
   容量の制限はお申込みいただいたサーバーのコンテンツ領域
の上限となります。
   弊社のご提供するサービス上での制限は容量のみですが、CS
VなどをDBの代わりにご利用になった場合、容量の制限の前に性
能面(お客様が期待するWebページのレスポンス)で限界に達する可
能性が高いと思われます。

以上 日原からの回答の下に記載しております。

また弊社Webページよりお問合せをいただきました資料の件ですが、
現時点でお送りできる資料は基本的にWebページの説明に申込書な
どを一式にしたもののみとなります。コンフィグレーターの詳細画
面やMLの情報についてはご契約いただいたお客様にのみご提供す
るマニュアルとなりますのでご理解いただきご容赦願いますようお
願い申し上げます。

今後とも弊社サービスをご検討賜りますよう重ねてよろしくお願い
申し上げます。

クボタシステム開発株式会社
インターネットサーバー ホスティングサービス グループ
info@k...

--以上、返信終わり------------------------------------------

ということでした。

現段階での私の感想としては、「クボタが一番良さそうだが、全権
をこちらに渡さずに、細かいところでお金を取られそうな気もする。
」といったところです。そしてこの感想に基づいて、一応、クボタ
とアイルの2箇所に、資料請求をしてあります(来週中ごろまでに
はセンター事務局に到着すると思います)
以上、現在第一候補かなと思っているクボタのサーバに関するご報
告でした。

事務局日向さんからの報告は以上です。

穂積一平
ipfr_cat@d...

http://home.interlink.or.jp/~ipfr_cat/


58 投稿者: nishibe@e...
Date: 2001年3月5日(月) 午後9時15分
タイトル: Re: 討議−MLの傍聴3


  西部です。

湯本さん,どうも。

> 共有ファイルや投票機能などと切りはなされた、傍聴専用のMLをあら
> たにつくることは可能だと思います。
>
> メンバー専用のMLとはべつに、たとえば、free-ml に傍聴専用のML
> をつくることになりますが、そこには一般読者は書き込みができず読む
> ことだけができるように設定します。
>
> そして、傍聴専用MLに書き込みができるただ一つのアドレスを用意し、
> そのアドレスをメンバー専用のMLに加えておきます。そうすれば、メ
> ンバー専用MLの内容が自動的に、傍聴専用MLに流れます。
> (以上)

技術的には傍聴専用MLを作ることはできるわけですね。

過去ログの整理・公開の時に考えてみましょう。
当面はこのままでいきましょう。

ところで,このメールや鈴木健さんの提案など27日のメールのいくつかが私のところに配信されていませんでした。]
Web上でなんかだ知らない話が出てくるなと思ってweb上で確認しました。他の方は問題ないですか。
大学のサーバーの問題なのかもしれませんが。


59 投稿者: nishibe@e...
Date: 2001年3月5日(月) 午後9時39分
タイトル: Re: 討議−MLの傍聴4


  西部です。

申し訳ないのですが,このメールも届いていませんでした。
FreeMLの方のメールは届いているようなので,これもeGroupsの問題でしょうか。だとすると,
システムの安定性に問題があることになりますね。
通し番号がないので,何番のメールが来ていないというのが一目でわからないのが困ります。

ほずみさんの意見に賛成です。

報告やアナウンスは後でまとめてHPに載せるのがベストです。
それが今は無理なら,中間報告や経過報告だけをセンター評議会に流し,
それを全員に配信してもらうようにしましょうか。

-- ippei hozumi <ipfr_cat@d...>さんのメッセージ
> ほづみです。
>
> わたしの意見を述べます。
>
> 前提として、NAMの会員はすべての情報にアクセスできるべきでし
> ょう。
>
> まず、傍聴したいという気持ちはわからないではありませんね。ぼ
> くが参加してないなら、なにやってんだろ、とたぶん思いますから。
> ただ、ぼくの場合は参加してないなら途中で熱もさめちゃうので、
> 傍聴といいながら、なにも聞いてないってことになっちゃいます。
>
> いっぽう、討議している側からすると、黙って聞いているだけなら、
> べつに邪魔にはならないでしょうが、そんなことしてどういう意味
> があるんだろう、という気もします。
>
> まあ、中をとって、一定期間をおいて過去のログにアクセスできる
> ようにするというのがいいと思います。ただ、その共有フォルダと
> いうのがそういう芸当できるのかどうか、わかりません。
>
> もひとつの案は、これも一定期間でまとめや報告をなんらかのかた
> ちで出すというのがいいんじゃないでしょうか。
>
> まとめると、いちおうクローズにする。ただ、これは隠しているん
> じゃなくて、討議の詳細までリアルタイムに報告してもあまり意味
> がないから、というアナウンスはしたほうがいいと思います。
> その上で一定期間で、なんらかの報告をする。
>
> namが稼働するまで、というのが比較的短い期間であるなら、問題
> はないのですが、いまひとつどの程度の期間になるのか、わたしと
> してはつかめていません。
>
> それと、報告やアナウンスは、このMLにかぎらず、NAMの全般のプ
> ロジェクトでやってほしいという個人的な希望でもあります。
>
> もひとついうと、この報告というか、中間的なまとめみたいなのは、
> メールじゃなくホームページでやってほしい、というか、やりたい
> と思ってます。なぜかというと、どうも過去のメールをひっくり返
> すというのが苦手というのもありますが、スレッドをたどっても、
> いっこうに結論が見えてこないという気がするからです。
>
>
>
> 穂積一平
> ipfr_cat@d...
>
> http://home.interlink.or.jp/~ipfr_cat/


60 投稿者: yumoto  <yumoto@h...>
Date: 2001年3月5日(月) 午後9時48分
タイトル: 質問 - 決済機能と、取り引きを分ける? 1


  穂積さん、こんにちは、湯本です。

hodumi wrote 01/03/04:
> それと、やはり取引のときの手順とかやり方が初めてだととてもわかり
> ずらいです。そういうマニュアルというか手引きも必要かなと
> も思いますが、いかがでしょう。

取り引きの手順がわかりにくいと感じる人はおおいらしいです。商店な
どで買い物をするときと、やり方がちがうからなのだと思います。フリ
ーマーケットのような取り引きが想定されているのでしょうか。

わたしの印象では、取り引きと、 nam での決済とを、ハッキリと分け
たほうが、わかりやすくなると思います。GETS お試し版にある、取り
引きの事後報告、というのが、決済に特化した処理になりますが、これ
なら、だれにとっても、わかりやすいと思います。

nam が将来、さかんに使われる場面を考えると、 nam のgets は、GETS
お試し版にあるような種類の取り引きの手段として使われるケースは少
なくなり、しだいに、多くの場合、決済手段としてのみ使われるように
なりそうだ、というのが私の予想です。

ウェブ上の取り引きでは、売ります買いますのフリーマーケットのよう
なやり方よりも、多くの場合、商店で買い物をするようなやり方、
amazon.com のようなやり方、共同購入のようなやり方、企業が従業員
に賃金をはらうようなやり方、会費や月謝を受け取るようなやり方、な
どが主流をしめるでしょう。そして、将来は、スマートカードに nam
を入れたり出したりするような場面が多くなるかもしれません。そして、
円60%、 nam 40% の比率で決済する、というようなバリエーショ
ンも存在します。

けっきょく、nam のコンピュータシステムは、これら取り引きの個々の
状況には介入せず、決済の場面だけに特化するように使われると思うの
です。その場合、多種多様な、ウェブ上の商店、売ります買いますコー
ナー、塾の月謝支払サイト、などと、 nam のコンピュータ システムを
オンラインでつなぎ、それらサイトの決済機能をはたすわけです。これ
は、現在のGETS で対応可能だと思うのですが、どうでしょうか。

nam を使う取り引きをいろいろな場面に拡大していくために、
(1) nam のコンピュータシステムを決済機能に特化させる
(2) 取り引きサイトは、多くの人が自由に開設できるようにする
という方向を、はじめから明確にしておいたほうがいいかもしれないと
思います。どんなものでしょうか。

それではまた
yumoto hirokazu


61 投稿者: Makoto Nishibe  <nishibe@e...>
Date: 2001年3月5日(月) 午後10時02分
タイトル: Re: [nam-project] Re: 自己紹介2


  西部です。

高瀬さん,センター事務局長としての仕事なにかと大変でしょうがよろしくお願いし
ます。今後どんどん出てくるであろうNAM内のプロジェクトのテストケースになると
思いますので。

> で、本日は早速に事務的なことで西部さんにお願いがあります。
> 一つは、センター事務局(info@n...)をこのMに加えていただきたいので
> すが。私のみならず、事務局メンバーに助力を求める場面が生じるかと思います
> ので。

了解しました。

> いま一つは、センター評議会へ、適当な段階で、このプロジェクトの進み具合を
> お知らせ願いたいのですが。今の時点でいえば、メンバー数など。その際、鈴木
> 腱さんがNAM非会員であることも案内なさったらどうでしょう。今後の様々なプ
> ロジェクトでも、非会員の有力参加者が加わるでしょうし、その先例として意味
> のあることだと思います。
> ご多忙のところ恐縮ですが、よろしくお願いします。

あれ,鈴木君,まだ会員になっていないの?
「なりま〜す」といっていたよね。
登録はNAMのHPでもできますよ。

=============================================
    西部忠 Makoto, NISHIBE
  北海道大学経済学部
  Faculty of Economics,
  University of Hokkaido
    E-mail: nishibe@e...
    http://sun.econ.hokudai.ac.jp/~nishibe
=============================================


62 投稿者: Makoto Nishibe  <nishibe@e...>
Date: 2001年3月5日(月) 午後10時30分
タイトル: Re: [nam-project] 提案−技術/ 管理13


  西部です。

ほずみさん,レスが遅れすみません。

> 3) あと、まえにも書きましたが、このMLには、技術/管理とい
>    うことで、なん人かおられますが、やはり、あとひとりふたり
>    ほしいという気がしてます。NAM-COMPUTERのほうで、サーバー
>    がらみのこととか運営レベル、もちろんコーディングやその他
>    いろいろPUSHしてみることはできると思います。いちおう、ほ
>    っておくとぼくは勝手に動いちゃうという困ったひとなので、
>    この点に関してレスをお願いします。

プロジェクトメンバーを再々募集というのは何ですから,ほずみさんの方で
NAM-COMPUTERからめぼしい人がいたらつれてきていただいて結構です。

=============================================
    西部忠 Makoto, NISHIBE
  北海道大学経済学部
  Faculty of Economics,
  University of Hokkaido
    E-mail: nishibe@e...
    http://sun.econ.hokudai.ac.jp/~nishibe
=============================================


63 投稿者: Makoto Nishibe  <nishibe@e...>
Date: 2001年3月6日(火) 午前0時59分
タイトル: Re: [nam-project] 連絡−不配信


  西部です。

なんだかおかしいなと思い,今日web上で確認したところ,全62通のうち私のところ
には40通あまりしかメールが配信されていないことがわかりました。20通ぐらいが不
配信です。ある一定の日のメールが来ていないのではなく,毎日いくつかのメールが
とびとびで届いていません。私自身が投稿したメールも配信されていませんでした。

渡邊さんが教えてくれた「メッセージのまとめ読み」で一応読むことはできますが,
返信を書くのにとても不便です。

受信サーバー側の問題ということもありうるので,別プロバイダーの自分のメールア
ドレスを登録して,明日以降どうなるか見てみます。他にこういうトラブルを抱えて
いる方はお伝え下さい。様子をみてeGroupsに問い合わせてみようと思います。


=============================================
    西部忠 Makoto, NISHIBE
  北海道大学経済学部
  Faculty of Economics,
  University of Hokkaido
    E-mail: nishibe@e...
    http://sun.econ.hokudai.ac.jp/~nishibe
=============================================


64 投稿者: SAKAGUCHI Hirohito  <sakaguchi@h...>
Date: 2001年3月6日(火) 午前1時09分
タイトル: Re: [nam-project] Re: 討議−MLの傍聴5


  阪口です。

> 報告やアナウンスは後でまとめてHPに載せるのがベストです。
> それが今は無理なら,中間報告や経過報告だけをセンター評議会に流し,それを全員に配信してもらうようにしましょうか。
私も賛成。

先日の3日、センター事務局との打ち合わせもかねて、新東京事務所で
行われた地域系の会合に参加してきました。

その後の懇親会(飲み会)の席で、namプロジェクトの持っていき方や、
実際にいつ頃どうなるのかについて、いくつも質問を受けました。

「namプロジェクト」が、現時点のNAMの中で非常に興味を惹いているの
は間違いありません。

ただ、その日に東京事務所を訪れている方々は、それぞれNAMへのコミッ
ト度が高い方々であるにも関わらず、そのような方々でさえよくわかっ
ていらっしゃらないようです。

アウトラインと目標といったくらいでいいと思いますが、会員向けの広
報活動が必要かな、と思っていました。


_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
      SAKAGUCHI,Hirohito
      E-mail sakaguchi@h...(Private)
      E-mail sakaguti@s...(Office)
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/


65 投稿者: Makoto Nishibe  <nishibe@e...>
Date: 2001年3月6日(火) 午前5時07分
タイトル: Re: [nam-project] 提案−運営/規約


  西部です。

自己紹介いただいたメンバー全員が賛成ですので,鈴木健さんに副代表を引き受けて
いただきたいと思います。もうだいぶ走り出していますが,NAM会員として参加する
ということでよろしいですか。(これはNAMへの肩入れを期待しているからではあり
ませんよ。GETSをどのユーザーに対しても中立的に開発していきたいという趣旨は理
解できます。前に参加意志を私たちに表明していたので確認しているのです。念のた
め。)

技術/管理の方はすごい速度で話が進展しているようなので,私の方からも,運営/
管理についてこれから考えておくべきことについて提案します。一応優先度の高いも
のからあげてみます。

1)参加者の赤字の上限規定について

参加者の口座の赤字に上限が設けるかどうか,設けるとするとどの程度にするかとい
う問題です。

NAM会員はそれなりのハードルを越えて参加しているのですから,高い参加意識やコ
ミットメントを期待することはできます。ただ,まったく赤字の上限を設けないと大
きな赤字を残したまま退会してしまう「ただ乗り」が出てくる可能性はまったく否定
できません。そもそも,LETSでは,売り手はどんな赤字保有者からも黒字をえられま
すから,利己的に見れば,売りを自制させる経済的インセンティヴは働いていません
。評判機能もこの限りでそれほど役にたたないはずです。大量赤字保有者に売ったも
のが回りからの評判を落とすとすれば,それは人々がコミュニティを守ろうという価
値意識が強いからでしかありません。つまり,赤字累積を食い止めるインセンティヴ
はあくまでも経済的動機以外の倫理や規範によるものです。取引情報や口座情報を参
加者全員に公開するので,LETSを崩壊させないようにしようという意識を持つ参加者
は,赤字を大量に持っていれば買うことを控えて減らそうとし,そういう赤字保有者
に売ることを自制することが考えられます。私は,NAMの会員はこういう意識を持っ
て入ってきている人が大半だと信じています。ただ,NAMには基本的には誰でも参加
できますから,NAMを撹乱したり崩壊させようという悪意を持った侵入者,クラッカ
ー,党派性を持った破壊者が入り込むことは十分考えられます。NAMにはそれを事前
にチェックする機構はまったくありません。

現在の会員は386人だそうですが,今後これは増えるでしょう。とすれば,こうい
う問題がこれからますます起きるだろうと考えなければなりません。NAMのような思
想性を核とするアソシエーションは「顔の見える近隣関係」にもとづく町や村ではな
いので,悪意の存在を前提に考えないといけません。これは,NAM会員の行動やMLで
の発言にたいしても罰則規定を設けることになった現在の流れに対応します。

私は,総取引額(売りと買いの総計)に応じて上限を規定しておく,次のような方法
がいいのではないかと思います。

たとえば,赤字上限は総取引額の10%にするという規定はどうでしょうか。ただし
,赤字上限は総取引額10万nam単位ごとにスライドするとします。つまり

総取引額≦10万nam  →赤字上限1万nam
10万nam<総取引額≦20万nam→赤字上限2万nam
20万nam<総取引額≦30万nam→赤字上限3万nam
・・・・・

と赤字上限が取引額が大きくなるにつれて大きくなるというようにします。%はどの
ぐらいがいいかはおそらく経験的にしか決められないですが,一応10%としてみま
した。これは,総取引額を参加者の信頼を表示する情報として利用するもので,クレ
ジット会社の信用設定方法に似ています。ただし,これは個人にのみ適用されます。
地域系,関心系,階層系,プロジェクトはまったく別の規定を考えなくてはなりませ
ん。

2)namの循環について

湯本さんや宮地さんが議論しているように,自営業者(農家やSOHOを含む)をのぞく
,サラリーマン,学生などが何を提供できるのかについてです。これはわれわれがす
べて考えてあげるわけではなく,会員自らが「自分は何ができるか」と,起業者的に
考えてもらうべきことですが,大きな循環をどう形成するかはあらかじめ構想してお
こないといけない。この点について,私に名案があるわけではないのですが,いくつ
か考えたことがあります。

i) 地域系やプロジェクトが仕事やボランティアをつくり出す

大阪の地域系で事務作業のボランティアが大変だという話が出ていました。いわゆる
「青春を返せ」事件もそこからでてきたわけです。いまも東京のセンター事務局が行
っている仕事は大変にちがいありません。これは一見ゆゆしき事態のようですが,逆
に見れば「やってほしい仕事がたくさんある」という状態ですから,こうした事務的
な仕事をやってくれるアルバイトを募集して,多くの会員を集められれば,地域系や
センター事務局が対価をnamで支払うことができます。学生にはこれはNAMの活動に参
加しつつ,namを稼ぐことのできるいい機会になるはずです。失業者も学生と同じよ
うに参加できるだけの時間があるかもしれません。

ii) 円からnamへの交換(コミュニティ・ウェイの応用)

サラリーマンは忙しくて時間がないという場合が多い。彼らはボランティアや労力を
提供できません。これが問題です。しかし,彼らは円は持っているはずです。ならば
,円をnamに交換できればいいのではないか,というのがここでの発想のもとです。
この場合,ただ交換するのではなく,自分が応援したいプロジェクトや自分の属する
地域系を自分で選択して,そこで円とnamを交換してもらう。それは現金による寄付
であると同時に,円とnamの交換でもある。

今のところ,地域系は東京と大阪が会費を取っていますが,地域系は円を支払っても
らう代わりにnamを会員に支払うとすればどうか。また,各プロジェクトも賛同して
くれる会員から円を受取りnamを支払う。こうやって活動・運営資金を集めるわけで
す。この寄付は投票機能を持っています。つまり,NAM会員がどのプロジェクトによ
り多くの支援をあげたいかを見るためのバロメーターでもあるからです。

しかも,かりに湯本さんや宮地さんが天然酵母パンを提供してくれれば,会員はその
代金(の一部)としてnamを使うことができる。namが共同購入や協賛企業・協同組合
への代金として使えるようにすれば,円をnamに交換した人は寄付をしますが,まっ
たくの無償寄付ではなく,交換していることになります。「どこで交換してもらうか
」を選べるというところがミソです。ただし,namの円への換金は認めません。

これで,学生やサラリーマンをも巻き込むnamの循環形成を促進できるのではないで
しょうか。

NAM-LETSでも書きましたが,フィリピンの無農薬バナナへの支援や共同購入も今のと
ころnamで支払うことは無理です。生産性,生活水準,為替格差が大きすぎるし,彼
らがnamを受けとってもそれを使えないでしょうから。その場合も,無農薬バナナ支
援・共同購入協同組合(あるいはプロジェクト)を作り,NAM会員から円のnamへの寄
付的交換を受け付け,円でフィリピンにたいする投資や支払を行い,会員はnamでバ
ナナを買うようにすればいい。こうすれば,第三世界との交易をnamが間接的にでは
あるが,つなぐこともできるはずです。

フリースクール・プロジェクトも同様に,会員が円で寄付してnamで受取り,それを
自分の子供がそこへ通う場合の学費(の一部)として支払えるようにする。その他い
ろいろなプロジェクトへの応用が可能でしょう。これは,コミュニティ・ウェイの
NAM的展開の例です。

この方式では,プロジェクトの口座は一般に赤字になりますが,それは現金に見合っ
ていますから,その上限を決めておく必要はないでしょう。

namで経済全体の産業連関を一挙に覆いうるような流通圏を作ろうとしても不可能で
す。そうではなく,namと円を補完的に使用し,namの流通圏が拡大するにつれてnam
の使用割合を徐々に高めていくという方向が現実的です。同時に,いろんなプロジェ
クト,協同組合,NPOがこの輪の中に入ってこなければなりませんし,そうした新た
な活動へ労働者や失業者が参加していくなら,地域通貨と国家通貨の補完的使用が,
後者を前者で徐々に代替していくための第一歩になるわけです。これが私が考える
LETS=「対抗ガン」的な戦略です。

iii)namの価値基準

こうしたことを可能にするには,namは労働時間に単純にリンクするのではなく,円
と併用できるように円とリンクすべきです。「1nam=1円」とすることの意味がここ
にあります。ボランティアなどインフォーマル経済を媒介するだけなら労働時間でも
いいが,そこから発展させるつもりなら,競争もいれなければなりません。

3)namファンドについて

2)のii)は,プロジェクトやNPOが現金を集めるためのいわば起債型(直接金融型)
ファンド方式です。もちろん,個人が黒字のnamを寄付するようなファンドもあって
いい。namファンドは,これらと違って,namを長期的プロジェクトなどに無利子で貸
し付ける銀行型(間接金融型)のファンド方式です。私は,namファンドの運営母体
はnamプロジェクトとしたいと考えますが,いかがでしょうか。

たとえば,われわれのnamプロジェクトがこのnamファンドから100万namを借りて20年
で返済する契約をします。namプロジェクトは,参加メンバーであるわれわれの貢献
に対する対価として100万namを分配して支払うとしましょう。会員が1000人なら毎年
namの利用料(管理運営費とは別に)として500namずつ払ってもらう。すると,1年
で50万namになるので20年で返済できます。もちろん,会員がもっと増えれば早く返
済することができるでしょうし,利用料を減らすこともできるでしょう。このように
,namファンドはLETSによる長期貸付・返済のためのスキームです。

namプロジェクトについて,こうしたnamファンドを実際に利用してサービス対価を支
払うという方式を採用することができるのではないかと考えています。みなさんの考
えをお聞きかせ下さい。

4)GETSの設計,マニュアル化,試験期間

GETSのいいところは,単なる自動記帳(決済)システムであるだけでなく,それが売
買リストの自動作成システム,リストメールを使った取引成約システムと一体化して
いるところにあると思います。GETSは単なる貨幣システムでも,多角的決済システム
でもなく,LETSによる「市場」を構成しているのです。つまり,GETSは,LETS型決済
システム+相対型取引システム=LETS市場となっているところがおもしろい。だから
,自動記帳システムだけを分離したほうがいいとは思いません。

それにメールでの応諾は双方向コミュニケーションだから,買い手が財やサービスの
説明を売り手から受けることも,買い手が売り手に値下交渉を行うことができるよう
になっています。それに,事後的な価格変更機能はプラスまたはマイナスのチップを
支払うためと考えればいいでしょう。いいサービスにはプラスの,よくないサービス
にはマイナスのチップを上げることで,サービスの質は向上します。

GETSは参加者が自分のモノやサービスをリスト上にずらっとならべて提供しているフ
リマ型の市場(相対型)をシミュレートしていますが,出店機能(地域系,商店,協
同組合のHP上でモノやサービスが定価で買え,LETSで決済),オークション機能(せ
り市場タイプ)なども付けられるならおもしろいと思います。

LETS型以外の地域通貨システム(たとえばWAT)+オークション型取引システムも作る
ことができるでしょうし,鈴木さんはそうしたものも作ろうとしていますが,それは
また別の「市場」システムになりますね。

また,電子マネーにもICカード(スマートカード)を使うものもありますし,そのタ
イプのLETS用システムもありますが,当面,NAMはLETSのアクセス型電子マネーGETS
を中心にやっていきたいと思います。会員が日本全国に散らばっているので,リント
ンが開発したICカード型でやるとすれば,個々の会員が電子ワレットのみならずカー
ドリーダーを買ってPCに接続しなければならないので,かなりの初期投資(円による
)が必要になってきます。ICカード型には個人認証機能,多通貨併用機能など優れた
点もありますが,この場合には,取引メニューや取引成約システムを独立に作らない
といけないので面倒です。

GETSに慣れるには多少大変ですが,マニュアルをきちんと作ればいいでしょう。最初
は管理者が質問を受け付けたり,一定の試験期間をおいて練習してもらう必要がある
と思います。マニュアルというよりも,GETSにヘルプ機能を付けて,全体の取引プロ
セスのわかりやすい解説や,個々のボタンについての説明などが,ポップアップで見
れるようになっているといいと思います。

あまり最初から完全なものを作ろうとせずに,できるだけ早くGETSプロトタイプをサ
ーバーに実装してもらい,2,3カ月位の期間,NAM会員に練習してもらい,その間
のユーザーの反応を見つつ,改良していくというのはどうですか。多分,実際に使っ
てみるといっぱいいろんな意見がでてくるでしょうし,問題点も見えてくるのではな
いでしょうか。GETS練習版はユーザーからのフィードバックかなりありましたか?>
鈴木さん


=============================================
    西部忠 Makoto, NISHIBE
  北海道大学経済学部
  Faculty of Economics,
  University of Hokkaido
    E-mail: nishibe@e...
    http://sun.econ.hokudai.ac.jp/~nishibe
=============================================


66 投稿者: Ken Suzuki  <ken@s...>
Date: 2001年3月6日(火) 午前10時29分
タイトル: Re: [nam-project] 提案−運営/規約2


  こんにちは。鈴木です。

 >。評判機能もこの限りでそれほど役にたたないはずです。大量赤字保有者に売ったも
 >のが回りからの評判を落とすとすれば,それは人々がコミュニティを守ろうという価

トレードオフのある評判オプションを検討中です。
効果のほどが定かじゃないので、シミュレーションして効果がありそうなら
実装しようと思ってます。

 >総取引額≦10万nam  →赤字上限1万nam
 >10万nam<総取引額≦20万nam→赤字上限2万nam
 >20万nam<総取引額≦30万nam→赤字上限3万nam
 >・・・・・
 >
 >と赤字上限が取引額が大きくなるにつれて大きくなるというようにします。%はどの
 >ぐらいがいいかはおそらく経験的にしか決められないですが,一応10%としてみま
 >した。これは,総取引額を参加者の信頼を表示する情報として利用するもので,クレ
 >ジット会社の信用設定方法に似ています。ただし,これは個人にのみ適用されます。
 >地域系,関心系,階層系,プロジェクトはまったく別の規定を考えなくてはなりませ
 >ん。

ぼくもこれは考えたことがあるのですが、空取引によって限度額をどんどん増やす
ことができて、ほんとに悪いやつには通用しません。
現状の規模でスタート時にやるのであれば問題はさほどないかもしれません。
(というよりかえって悪化する)

 >4)GETSの設計,マニュアル化,試験期間
 >
 >GETSのいいところは,単なる自動記帳(決済)システムであるだけでなく,それが売
 >買リストの自動作成システム,リストメールを使った取引成約システムと一体化して
 >いるところにあると思います。GETSは単なる貨幣システムでも,多角的決済システム
 >でもなく,LETSによる「市場」を構成しているのです。つまり,GETSは,LETS型決済
 >システム+相対型取引システム=LETS市場となっているところがおもしろい。だから
 >,自動記帳システムだけを分離したほうがいいとは思いません。
 >
 >それにメールでの応諾は双方向コミュニケーションだから,買い手が財やサービスの
 >説明を売り手から受けることも,買い手が売り手に値下交渉を行うことができるよう
 >になっています。それに,事後的な価格変更機能はプラスまたはマイナスのチップを
 >支払うためと考えればいいでしょう。いいサービスにはプラスの,よくないサービス
 >にはマイナスのチップを上げることで,サービスの質は向上します。
 >
 >GETSは参加者が自分のモノやサービスをリスト上にずらっとならべて提供しているフ
 >リマ型の市場(相対型)をシミュレートしていますが,出店機能(地域系,商店,協
 >同組合のHP上でモノやサービスが定価で買え,LETSで決済),オークション機能(せ
 >り市場タイプ)なども付けられるならおもしろいと思います。
 >
 >LETS型以外の地域通貨システム(たとえばWAT)+オークション型取引システムも作る
 >ことができるでしょうし,鈴木さんはそうしたものも作ろうとしていますが,それは
 >また別の「市場」システムになりますね。

GETSのロードマップとしては、取引システムと決済システムの分離し、
選択肢を増やし任意に組み合わせることは入っています。
(玉手箱にもそう書きましたよね)
ですから、将来的にはみなさんが希望するような形を目指しています。
決済システムの種類がN、取引システムの種類がMなら
N×Mの組み合わせが可能になります。取引システムは複数が共存可能です。
最終的にGETSはそのうちのone of themになるわけです。
もはやGETSでもないので、別の名前になるでしょうが。

ただ、他のサイトやアプリケーションなどから決済をいじれるようになるためには、
JAVA版+EJBが必要なんだと思っています。
というよりGETSにとってEJBはそのために必要なんだと認識しています。

決済システムと取引システムはテーブル上でもプログラム上でもすでに分離
されています。取引システムが存在しないとマッチングができないと思ったので、
約束型という一番開発が楽でシンプルなものを実装しただけだと考えてください。
逆に約束型さえもなかったら、ネット上での取引は困難を極めると思います。

GETS=約束型というのはNAM=柄谷行人と同じくらいの偏見です。
EMACS=EDITORというのと同じくらいの偏見です。
GETS=鈴木健も同様に偏見です。っていうか偏見にしたい。。。

GETSにこういう機能を付け加えないと思ったら、ぜひプログラミングして
CVSにコミットしてください。そうやってどんどん改良していきましょう。

評判のさしてよくない価格変動機能なんかはオプション化しようと思っています。
(玉手箱で書きましたが、情報財などは購入数に応じてキャッシュバックする機能なんかも
つけたいので、この方向性はまげたくない)
ユーザアンフレンドリーなインターフェイスなので改良していきたいですね。

 >あまり最初から完全なものを作ろうとせずに,できるだけ早くGETSプロトタイプをサ
 >ーバーに実装してもらい,2,3カ月位の期間,NAM会員に練習してもらい,その間
 >のユーザーの反応を見つつ,改良していくというのはどうですか。多分,実際に使っ
 >てみるといっぱいいろんな意見がでてくるでしょうし,問題点も見えてくるのではな
 >いでしょうか。GETS練習版はユーザーからのフィードバックかなりありましたか?>
 >鈴木さん

かなりありました。
バグのほとんどは彼らからの報告です。

I18NはJAVA版からですね。perlでもとりあえずリソースの分離はしていきますが。


67 投稿者: Ken Suzuki  <ken@s...>
Date: 2001年3月6日(火) 午前10時33分
タイトル: Re: [nam-project] 提案−運営/規約3


  こんにちは。鈴木です。

 >ぼくもこれは考えたことがあるのですが、空取引によって限度額をどんどん増やす
 >ことができて、ほんとに悪いやつには通用しません。
 >現状の規模でスタート時にやるのであれば問題はさほどないかもしれません。
 >(というよりかえって悪化する)

かっこの場所まちがえました。

 >ぼくもこれは考えたことがあるのですが、空取引によって限度額をどんどん増やす
 >ことができて、ほんとに悪いやつには通用しません。
 >(というよりかえって悪化する)
 >現状の規模でスタート時にやるのであれば問題はさほどないかもしれません。

ですね。


68 投稿者: yumoto  <yumoto@h...>
Date: 2001年3月6日(火) 午後3時22分
タイトル: チャット - プログラミング


  鈴木さんこんにちは、湯本です。

> GETSにこういう機能を付け加えないと思ったら、ぜひプログラミングして
> CVSにコミットしてください。そうやってどんどん改良していきましょう。

わたしはそうとうなオッチョコチョイなので、よし、おれも perl か
java を勉強しよう、などとできそうもないことを、空想してしまいま
す。岩谷宏さんが、だれでもがプログラミングしなければダメだ、と書
いていた影響もあるのでしょう。わたしのばあい、もう無理にきまって
ますが、プログラミングのおもしろさへのあこがれはあります。ボケ防
止を目的にするなら、かじってみるくらいはいいかもしれません。

それでも、すこしはお役に立てるよう、プログラミングしている人たち
の会話をきいていて、なにについてはなしているのかを理解すること、
これをめざすことだけは、がんばらなければと思います。どうぞよろし
く。

それではまた
yumoto hirokazu


69 投稿者: shogowatanabe@n...
Date: 2001年3月6日(火) 午後3時33分
タイトル: [nam-project] $BDs0F!]5;=Q(J/ $B4IM}(J14


  渡辺彰吾です。

サーバーの件、一回整理します。

共通了解としてあると思っているのが以下のことです。

タイトル nam-project
データ  nam-projectのデータとnamのデータ、テキストのみ
ユーザー nam会員(ご助力いただいておられる方々、ありがとうございます。)
メディウム WebDB
システム perl→DBI→PostgreSQL
締め切り 3月末(あと25日 そのうち一週間がテストと配置だがら実質18日)


結構、稼動日まで時間がありません。
対費用効果、人材、保守、管理作業とかを考えるととりあえずレンタルサーバーに決定します。
よろしいですか?>鈴木さん


>個人的な感想では日向さんのサーバー検討案がかなり
>進展しているので、それを生かすかたちで動いたほうが効率的だと
>考えます。

私もそう思います。
とりあえずnam-projectが稼動できるかこのサーバー(クボタとアイル)に問い合わせてみますが、よろしいですか?>鈴木さん

  
以下、今までのサーバーの件のMLのやりとりです。


no36

>> >具体的な仕事は、

>> >1.物理的なサーバーの構築
>>
>> ウェブホスティングですが、
>> 「Webhosting.co.jp」http://www.webhosting.co.jp/index.htm
>> はどうでしょう。
>> インド人の5人の方がプログラム作成としてかかわっています。
>
>これ、いま見てたんですが、Servletも使えていいんじゃないでし
>ょうか。ただお金のこともありますし、事務局でもサーバーの移転
>を考えているというようなことも聞いていますから、そのへんどう
>でしょう。

ここだと、DBMSがmSQL 2.0.3 / mySQL 3.23.24
Databaseですよね。DBI経由の問題はないのかな。
トランザクションとか大丈夫でしたっけ。

将来的にはJ2EEをいれる必要があります。
JAVA版がほんとに開発されれば。

no50
>J2EEを使うには、EJBコンテナを実装したAPサーバが
>必要ですが、レンタルサーバ等でこのような環境を実現
>するのは現状では不可能ではないかと思います。

最初自前サーバーがいいのではないかと提案したのも
それが理由です。

 

no57

個人的な感想では日向さんのサーバー検討案がかなり
進展しているので、それを生かすかたちで動いたほうが効率的だと
考えます。

上の意見、およびGETSシステムで要請されるサーバーの条件を簡略
明瞭に再度、確認報告してもらえれば、ありがたいです。

それと、鈴木泰生さんがいま新規会員の登録のCGIを作成しておら
れますが、そのあたりのかねあいからも泰生さんの意見をいただけ
れば参考になるかと思います。

 

現段階での私の感想としては、「クボタが一番良さそうだが、全権
をこちらに渡さずに、細かいところでお金を取られそうな気もする。
」といったところです。そしてこの感想に基づいて、一応、クボタ
とアイルの2箇所に、資料請求をしてあります(来週中ごろまでに
はセンター事務局に到着すると思います)
以上、現在第一候補かなと思っているクボタのサーバに関するご報
告でした。


70 投稿者: Ken Suzuki  <ken@s...>
Date: 2001年3月6日(火) 午後5時17分
タイトル: Re: [nam-project] 提案−技術/ 管理15


  こんにちは。鈴木です。

 >タイトル nam-project
 >データ  nam-projectのデータとnamのデータ、テキストのみ
 >ユーザー nam会員(ご助力いただいておられる方々、ありがとうございます。)
 >メディウム WebDB
 >システム perl→DBI→PostgreSQL
 >締め切り 3月末(あと25日 そのうち一週間がテストと配置だがら実質18日)
 >
 >
 >結構、稼動日まで時間がありません。
 >対費用効果、人材、保守、管理作業とかを考えるととりあえずレンタルサーバーに決定します。
 >よろしいですか?>鈴木さん

ええ。そのほうがいいと思います。

 >>個人的な感想では日向さんのサーバー検討案がかなり
 >>進展しているので、それを生かすかたちで動いたほうが効率的だと
 >>考えます。
 >
 >私もそう思います。
 >とりあえずnam-projectが稼動できるかこのサーバー(クボタとアイル)に問い合わせてみますが、よろしいですか?>鈴木さん

アイルに関しては知り合い(西部さんも知り合いの渡邉さん)
がホスティングサービスを使っているのですが、
DBIをローカルにインストールすることができて、DBを使える
ところまでは確認してあります。DBMSがPostgresなので、
その辺の心配はないでしょう。

クボタのほうなら、なんかrootくれるような感じの説明ですね。
http://www.kubota.ne.jp/service/v_01.html
これなら何だってできるんじゃないですか?
NTってことはないですよね。

 >ここだと、DBMSがmSQL 2.0.3 / mySQL 3.23.24
 >Databaseですよね。DBI経由の問題はないのかな。
 >トランザクションとか大丈夫でしたっけ。

http://member.nifty.ne.jp/hippo2000/perltips/DBD/mysql.htm
から見る感じ、トランザクションに関する情報がないので、
たぶんだめっぽいですね。

さて、一番の懸念事項が、会員DBとの連携ですが、
ちょっと様子がいまいちわからない。
どうしましょうか。GETSと連携する形で設計しなおすのでしょうか。


71 投稿者: Ken Suzuki  <ken@s...>
Date: 2001年3月6日(火) 午後5時25分
タイトル: Re: [nam-project] チャット - プログラミング2


  こんにちは。鈴木です。

 >わたしはそうとうなオッチョコチョイなので、よし、おれも perl か
 >java を勉強しよう、などとできそうもないことを、空想してしまいま
 >す。岩谷宏さんが、だれでもがプログラミングしなければダメだ、と書
 >いていた影響もあるのでしょう。わたしのばあい、もう無理にきまって
 >ますが、プログラミングのおもしろさへのあこがれはあります。ボケ防
 >止を目的にするなら、かじってみるくらいはいいかもしれません。

はは。岩谷さんは過激で面白いですよね。
過激なんだけど、ちゃんと理は通ってる。

湯本さんてそんなお年だったのですか。
うーむ。メールはこわい。


73 投稿者: shogowatanabe@n...
Date: 2001年3月6日(火) 午後7時15分
タイトル: [nam-project] $BDs0F!]5;=Q(J/ $B4IM}(J16.


  渡辺です。

「アイルについて」の日向さんの引用に間違いがあったので再送します。

「アイルか、クボタか」?

アイルについて

鈴木さん:
>アイルに関しては知り合い(西部さんも知り合いの渡邉さん)
>がホスティングサービスを使っているのですが、
>DBIをローカルにインストールすることができて、DBを使える
>ところまでは確認してあります。DBMSがPostgresなので、
>その辺の心配はないでしょう。
>

日向さん:
>ちなみにアイルのビジネスプラン(ただし容量は100MBしかない)
>だと、
>初期費用 9000円
>基本料7900円×12月=9万4800円
>15のML×5000円=7万5000
>15のML×1000円×12月=18万円
>----------------------------
>     35万8800円
>という初年度費用になります。
>アイルは、ML設定料金が1MLにつき5000円、運営費が1MLについて
>月額1000円かかるのが痛いですね。
>アイルには、ビジネスプランの上にシルバープランというのもある
>のですが、こちらは計算してみると以下のような数字になって、と
>ても無理な価格だとわかりました。
>
>初期費用5万円
>基本料24800円×12月=41万7600
>15のML×5000円=7万5000
>15のML×1000円×12月=18万円
>--------------------------
>     72万2600円
>
>

クボタについて

鈴木さん:
>クボタのほうなら、なんかrootくれるような感じの説明ですね。
>http://www.kubota.ne.jp/service/v_01.html
>これなら何だってできるんじゃないですか?
>NTってことはないですよね。
>ここだと、DBMSがmSQL 2.0.3 / mySQL 3.23.24
>Databaseですよね。DBI経由の問題はないのかな。
>トランザクションとか大丈夫でしたっけ。
>http://member.nifty.ne.jp/hippo2000/perltips/DBD/mysql.htm
>から見る感じ、トランザクションに関する情報がないので、
>たぶんだめっぽいですね。
>

日向さん:
>vserver:初年度=24万円 
>rserver:初年度=48万円
>これならrserverでもなんとかギリギリ出せる線かもしれません
>(特にLETSがらみの話が具体化する状況になってくれば)

というわけで、優先順位をクボタにして、nam-projectの技術的な面から一応問い合わせます。


74 投稿者: ippei hozumi  <ipfr_cat@d...>
Date: 2001年3月6日(火) 午後0時01分
タイトル: Re: [nam-project] 提案−技術/ 管理14


  ほづみです。

ちょっと、バタバタしてますので、とりいそぎ要件だけ書きます。

高瀬さんのメールにあったように、ぼくも事務局のひとに入っても
らうのがいいと思っていたら、そういう方向で動くようです。

わたしがあっちにメール、こっちにメールとやるよりずっと見通し
がよくなるはずです。

それで、サーバーのことはお任せしておいて、いまGETSの仕組みと
データベースを読んでますので、もうちょっとしたら一応まとめれ
る、というか頭にはいると思います。

だいたいわかるんですが、おまえLETSのことよく知らねえだろ、っ
て感じがしております。

では、よろしく。


穂積一平
ipfr_cat@d...

http://home.interlink.or.jp/~ipfr_cat/


75 投稿者: ippei hozumi  <ipfr_cat@d...>
Date: 2001年3月6日(火) 午後0時01分
タイトル: Re: [nam-project] 提案−技術/ 管理13


  ほづみです。

>
> プロジェクトメンバーを再々募集というのは何ですから,ほずみさんの方で
> NAM-COMPUTERからめぼしい人がいたらつれてきていただいて結構です。


了解。こころ当たりがあるわけではないのですが、いちどやってみ
ます。

 

穂積一平
ipfr_cat@d...

http://home.interlink.or.jp/~ipfr_cat/


76 投稿者: Makoto Nishibe  <nishibe@e...>
Date: 2001年3月7日(水) 午前0時47分
タイトル: Re: [nam-project] 提案−運営/規約3


  西部です。

>  >。評判機能もこの限りでそれほど役にたたないはずです。大量赤字保有者に売ったも
>  >のが回りからの評判を落とすとすれば,それは人々がコミュニティを守ろうという価
>
> トレードオフのある評判オプションを検討中です。
> 効果のほどが定かじゃないので、シミュレーションして効果がありそうなら
> 実装しようと思ってます。

「トレードオフのある評判オプション」っていうのはどういうものですか?

>  >総取引額≦10万nam  →赤字上限1万nam
>  >10万nam<総取引額≦20万nam→赤字上限2万nam
>  >20万nam<総取引額≦30万nam→赤字上限3万nam
>  >・・・・・
>  >
>  >と赤字上限が取引額が大きくなるにつれて大きくなるというようにします。%はどの
>  >ぐらいがいいかはおそらく経験的にしか決められないですが,一応10%としてみま
>  >した。これは,総取引額を参加者の信頼を表示する情報として利用するもので,クレ
>  >ジット会社の信用設定方法に似ています。ただし,これは個人にのみ適用されます。
>  >地域系,関心系,階層系,プロジェクトはまったく別の規定を考えなくてはなりませ
>  >ん。
>
> ぼくもこれは考えたことがあるのですが、空取引によって限度額をどんどん増やす
> ことができて、ほんとに悪いやつには通用しません。
> 現状の規模でスタート時にやるのであれば問題はさほどないかもしれません。
> (というよりかえって悪化する)

たしかにこの方式も「確信犯」に対しては気休めにしかならないでしょう。会員にな
る時点でノーチェックなのだから,やらないよりもましという感じかな。むしろ,悪
意はなく,意図せざる結果として赤字が増えてしまったという人にたいして節度を求
めるという程度のものです。

「空取引によって限度額をどんどん増やす」ことができるのは,

1)一人が二つの口座を作ってやる
2)二人以上が結託してやる

のいずれかの場合ですね。

1)は個人認証の問題。一人が入会の時点で二人の名前で加入し,それぞれ別のメー
ルアドレスで登録すると簡単に二つの口座を持ててしまう。今のところ,これを防ぐ
手だてはなさそうが,もう少しましなセキュリティ・システムを作ればなんとかなる
かもしれないですね。

2)は組織的破壊行為の問題。二人だとまだ探知できそうですが,たくさんの人間が
順々に取引を回すタイプのものは探知しにくいでしょう。

いずれにしても,空取引を見破る方法は難しそうです。空取引があるなら取引を評価
する(評価ポイントを付ける)にしても同じでしょう。

もともとLETSは確信犯にたいしてはまったく無防備なシステムです。
もちろん,赤字を作って逃げていっても,それらの赤字を不精算口座に入れておけば
,それですぐ崩壊するわけでもないですが。

 >GETSのいいところは,単なる自動記帳(決済)システムであるだけでなく,それが売
>  >買リストの自動作成システム,リストメールを使った取引成約システムと一体化して
>  >いるところにあると思います。GETSは単なる貨幣システムでも,多角的決済システム
>  >でもなく,LETSによる「市場」を構成しているのです。つまり,GETSは,LETS型決済
>  >システム+相対型取引システム=LETS市場となっているところがおもしろい。だから
>  >,自動記帳システムだけを分離したほうがいいとは思いません。
>  >
>  >それにメールでの応諾は双方向コミュニケーションだから,買い手が財やサービスの
>  >説明を売り手から受けることも,買い手が売り手に値下交渉を行うことができるよう
>  >になっています。それに,事後的な価格変更機能はプラスまたはマイナスのチップを
>  >支払うためと考えればいいでしょう。いいサービスにはプラスの,よくないサービス
>  >にはマイナスのチップを上げることで,サービスの質は向上します。
>  >
>  >GETSは参加者が自分のモノやサービスをリスト上にずらっとならべて提供しているフ
>  >リマ型の市場(相対型)をシミュレートしていますが,出店機能(地域系,商店,協
>  >同組合のHP上でモノやサービスが定価で買え,LETSで決済),オークション機能(せ
>  >り市場タイプ)なども付けられるならおもしろいと思います。
>  >
>  >LETS型以外の地域通貨システム(たとえばWAT)+オークション型取引システムも作る
>  >ことができるでしょうし,鈴木さんはそうしたものも作ろうとしていますが,それは
>  >また別の「市場」システムになりますね。
>
> GETSのロードマップとしては、取引システムと決済システムの分離し、
> 選択肢を増やし任意に組み合わせることは入っています。
> (玉手箱にもそう書きましたよね)
> ですから、将来的にはみなさんが希望するような形を目指しています。
> 決済システムの種類がN、取引システムの種類がMなら
> N×Mの組み合わせが可能になります。取引システムは複数が共存可能です。
> 最終的にGETSはそのうちのone of themになるわけです。
> もはやGETSでもないので、別の名前になるでしょうが。

取引システムと決済システムがモジュール化されてて,両者の組み合わせがたくさん
できるというのは理解してます。

Turmelのはemailで「赤字いくら」「黒字いくら」とか報告しているだけですね。誰
かがもう一度記帳したりしないといけない。これは,電話やファックスが電子メール
になっただけです。リントンのスマートカードは決済システムだけを電子化したもの
です。GETSは取引システムと決済システムの両方を統合して(モノやサービス・情報
の移動は統合されていないけど),ネット上で取引も決済もできてしまう,だからこ
れらよりすごいよって,ほめたつもりなんだけど。

言いたいことは,この二つを最もシンプルに統合したところがGETSの「イノベーショ
ン」として評価したいということです。うまく伝わらなかったのかな。

> ただ、他のサイトやアプリケーションなどから決済をいじれるようになるためには、
> JAVA版+EJBが必要なんだと思っています。
> というよりGETSにとってEJBはそのために必要なんだと認識しています。

技術的なことはわからないけど,JAVA版+EJBでないとN×Mの組み合わせを実現でき
ないのですか。

 > 決済システムと取引システムはテーブル上でもプログラム上でもすでに分離
> されています。取引システムが存在しないとマッチングができないと思ったので、
> 約束型という一番開発が楽でシンプルなものを実装しただけだと考えてください。
> 逆に約束型さえもなかったら、ネット上での取引は困難を極めると思います。

そうそう。マッチングまで半自動化したところがすごいということです(くどいかな
)。プログラムのことはわからないので偉そうなことはいえませんが,これが最もシ
ンプルなんですよね。オークションの自動化のためには,もっとプログラムが複雑に
なるわけでしょう。

> GETS=約束型というのはNAM=柄谷行人と同じくらいの偏見です。
> EMACS=EDITORというのと同じくらいの偏見です。
> GETS=鈴木健も同様に偏見です。っていうか偏見にしたい。。。

だれの偏見ですか?ぼくは「約束型」というタームは使っていませんが。LETSの基本
は「相対型」取引で,GETSはそれを実現しているといっているわけです。GETSは「相
対型」取引のみならず,それ以外の取引システムをも組み込めるということに反対し
ていません。ただ,ぼくは,GETSの名はLETSに由来し,GETSはLETSを実現するソフト
であると理解している(開発者の意図や定義とズレてますか)ので,決済システムを
変えると(たとえばWATに)それが実現するのはLETSではなくなる,だから新しいシ
ステムはGETSと呼べないだろうと考えただけです。

予め取引内容を約束をしているか,いきなりその場で売買して即時あるいは後で決済
するかは当事者間の問題だし,GETSではどちらも可能なので問題ではないはずです。
八百屋が野菜に値札を付けて店頭に並べ,お客さんがそれを買う(値切ってもいい)
というような個々の相対取引(定価販売もこの一種です)の集積として構成される市
場は,取引が逐次的かつバラバラに進行していくので,私は「分散型」市場と呼んで
います。これだと,「一物多価」は頻繁におきます。その対極にあるのが,現実には
およそ存在しないけど,一般均衡理論型の「完全せり市場」で,社会のすべての財・
サービスの価格を同時的かつ一極的に決めるので,「集中型」市場と呼んでいます。
この市場では,すべての人の需要額と供給額は一致していると想定されているので,
貨幣も決済もいらないと考えられているわけです。株式市場やヤフーオークションな
ど現実に存在している不完全せり市場は,逐次的かつ疑似集中的な市場なので「疑似
集中型」です。GETSは「分散型」だけでなく「疑似集中型」の市場も実現できると思
います。

> GETSにこういう機能を付け加えないと思ったら、ぜひプログラミングして
> CVSにコミットしてください。そうやってどんどん改良していきましょう。

したいけど今はできません。プログラミング言語を勉強しないと。
自然言語であれこれ言うというのでは,あんまりコミットにならないかな(というか
,迷惑?)。

> 評判のさしてよくない価格変動機能なんかはオプション化しようと思っています。
> (玉手箱で書きましたが、情報財などは購入数に応じてキャッシュバックする機能なん
>かも
> つけたいので、この方向性はまげたくない)
> ユーザアンフレンドリーなインターフェイスなので改良していきたいですね。

ユーザー・フレンドリーなインターフェイス実現のための辛口テスト・ユーザーには
なれます。


***********************************************
  西部 忠 NISHIBE, Makoto
  北海道大学大学院経済学研究科
  e-mail: nishibe@e...
  Homepage: http://www.econ.hokudai.ac.jp/~nishibe/
***********************************************


77 投稿者: Ken Suzuki  <ken@s...>
Date: 2001年3月7日(水) 午前2時09分
タイトル: Re: [nam-project] 提案−運営/規約4


  こんにちは。鈴木です。

 >「トレードオフのある評判オプション」っていうのはどういうものですか?

もう一次元情報を増やして、赤字に売るとマイナス、黒字に売るとプラスになるような
指標です。取引の分割や集約に関わらず同じ数字にするとしたら、やり方はひとつしか
ないですよね。
ゼロサムになるわけじゃありませんが、長期的にはトレードオフになります。

 >2)は組織的破壊行為の問題。二人だとまだ探知できそうですが,たくさんの人間が
 >順々に取引を回すタイプのものは探知しにくいでしょう。
 >
 >いずれにしても,空取引を見破る方法は難しそうです。空取引があるなら取引を評価
 >する(評価ポイントを付ける)にしても同じでしょう。

ですね。

 >言いたいことは,この二つを最もシンプルに統合したところがGETSの「イノベーショ
 >ン」として評価したいということです。うまく伝わらなかったのかな。

いや、伝わってますよ。
でもイノベーションというほどのことではないです。
ksquareなんかのほうが断然完成度が高いですし。

 >> ただ、他のサイトやアプリケーションなどから決済をいじれるようになるためには、
 >> JAVA版+EJBが必要なんだと思っています。
 >> というよりGETSにとってEJBはそのために必要なんだと認識しています。
 >
 >技術的なことはわからないけど,JAVA版+EJBでないとN×Mの組み合わせを実現でき
 >ないのですか。

そんなことはないです。
全部同じWEBシステムにのっける分には問題なしですが、
アプリケーション(GnutellaだったりメールソフトだったりICQだったりなんでもかまわないでしょう)
にプラグインするとか、他のWEBサイトから使うとか、
そういうのはEJB使うと楽にできるみたいです。

 >そうそう。マッチングまで半自動化したところがすごいということです(くどいかな
 >)。プログラムのことはわからないので偉そうなことはいえませんが,これが最もシ
 >ンプルなんですよね。オークションの自動化のためには,もっとプログラムが複雑に
 >なるわけでしょう。

オークションはちゃんとやろうとすると、約束型の数倍は大変でしょうね。
でも、複雑になるってほどのことでもないです。

 >> GETS=約束型というのはNAM=柄谷行人と同じくらいの偏見です。
 >> EMACS=EDITORというのと同じくらいの偏見です。
 >> GETS=鈴木健も同様に偏見です。っていうか偏見にしたい。。。
 >
 >だれの偏見ですか?ぼくは「約束型」というタームは使っていませんが。LETSの基本

約束型は取引システムと決済システムのかましみたいなやつですね。
取引システムとしてはフリマ型のほうがいいかもしれないですね。
まいったな。別に文面ほど激しいつっこみじゃないのですが。
むしろ、ギャグなんですけど。ちゃんと”落ち”つけてるじゃないですか。

 >は「相対型」取引で,GETSはそれを実現しているといっているわけです。GETSは「相
 >対型」取引のみならず,それ以外の取引システムをも組み込めるということに反対し
 >ていません。ただ,ぼくは,GETSの名はLETSに由来し,GETSはLETSを実現するソフト
 >であると理解している(開発者の意図や定義とズレてますか)ので,決済システムを
 >変えると(たとえばWATに)それが実現するのはLETSではなくなる,だから新しいシ
 >ステムはGETSと呼べないだろうと考えただけです。

ぼくもそう思います。
いま、新しい名前考え中です。
名前考えるまえに仕事しろって日々自分でつっこんでますが。

 >したいけど今はできません。プログラミング言語を勉強しないと。
 >自然言語であれこれ言うというのでは,あんまりコミットにならないかな(というか
 >,迷惑?)。

いや。そんなことないです。ただ、
http://www.freeml.com/ml_view.php?ml=gets-dev&pg=12
みたいに、gets-devかgets-officeかgets-userでなげてくれると助かります。
ぼくだけが持ってる情報だと価値は下がっちゃいますから。
開発コミュニティやユーザコミュニティで共有しましょう。

 >ユーザー・フレンドリーなインターフェイス実現のための辛口テスト・ユーザーには
 >なれます。

はは。よろしくお願いします。


78 投稿者: yumoto  <yumoto@h...>
Date: 2001年3月7日(水) 午前10時27分
タイトル: 提案−運営/規約 5


  こんにには、湯本です。

参加者の赤字の上限規定について、つぎのように考えてみました。

(1) 赤字は、コミュニティ全体として引き受けるので、共有地の悲劇を
抑えるため、参加者の赤字上限を、たとえば、一口座5万 nam に固定
する。

(2) コミュニティ全体では引き受けない種類の赤字を、あらたに導入し、
この赤字の上限については、とくに定めない。(実際には、上限のガイ
ドラインはもうける)

この(2) が、ミソです。たとえばパン屋が、1年後から有効のパンの引
換券を発行するようなケースです。個人が借用書を発行するケースもあ
る。引換券や借用書は、それを引き受ける人が nam で買い取り、すべ
てのリスクを負担する。

赤字を、引換券や借用書の姿に変換することで、リスクをコミュニティ
全体から、引換券などを引き受ける人に移動させることになります。あ
えてリスクを引き受けようとする人は、引換券などの発行者を支援する
ことになります。

これは、円からnamへの交換(コミュニティ・ウェイの応用)とならぶ、
直接金融の手段にもなります。( nam から引換券、借用書への交換。)

森野さんの言われている、借用書を流通させるやり方は、借用書そのも
のを通貨として考えるわけですね。それと違って、通貨はあくまで nam
で一本化し、それを補助する金融的な手段として、引換券や借用書を用
いる、というわけです。

以上です。

それではまた
yumoto hirokazu

投稿者: NAMセンター事務局  <info@n...>
Date: 2001年3月7日(水) 午後0時35分
タイトル: 提案−技術/ 管理17.


  皆さんこんにちは、センター事務局員の日向と申します(所属は東京・第三世界です)。
昨日よりこのMLに事務局アドレスも加えていただきましたので、今後、特にサーバ選定の進捗状況についてご報告していきます。よろしくお願いします。

さっそくですが、サーバ選定について、nam-system(事務処理の効率化等について相談するために立ち上げたML)に投稿したメールを2通、転送します。
穂積さんがこちらに転送してくださったメールへの補足です。


*********************************************************************
**以下、3月4日のnam-systemへの投稿*********************************
サーバ選考について、以下の点に誤認がありましたので訂正します。

●アイルについて
 ・ML登録・解除作業にコマンドメールしか使えない
 とのデメリットを挙げましたが、不確かな情報でした。
 先日電話取材した際には、アイルのバーチャルドメインサービスのビジネスプラン
 http://home.isle.ne.jp/service/service_01a.html
 について主に聞いていたので、先方の担当もそのつもりで、上記のような答えをしたのかもしれません。改めてWEBをチェックしてみると、もっと上のクラスの専用サーバプラン「Cobalt Raq3 GOLD」には、バーチャルサーバドメインに付属してくるウェブマネージャより高機能な、クボタのサーバにおけるコンフィグレータのようなものが付いてくるようです。
 http://home.isle.ne.jp/service/service_03a.html

ただ、ここの画面からMLにアドレスを50個程度登録・解除できるのかどうかは未確認です。月曜日にアイルに確認してみます。

また、同じくアイルについて、
 ・ML設定・運営料金が別途かかる
 とのデメリットを挙げましたが、これも「Cobalt Raq3 GOLD」についてもそうなのかどうかを、再確認する必要があると思っています。こちらも月曜に確認し、追って報告します。
**以上、3月4日のnam-systemへの投稿*********************************
*********************************************************************

 


*********************************************************************
**以下、3月6日のnam-systemへの投稿*********************************

日向です。

クボタとアイルへの追加質問に対する答えが返ってきましたので、報告します。

━以下、クボタからの返信━━━━━━━━━━━━━━━━━
引き続き弊社サービスをご検討賜り誠にありがとうございます。

>追加で2点、確認させてください。
>rserverノービスとパワーのコースについてです。
>1、SQL、JAVA、postgreSQLは、使用できるのでしょうか?

 → 誠に申し訳ございませんが、 perl のみでごさいます。
   上記ご要望が利用可能な環境は@Server サービス シリーズのみで
   ございます。何卒ご了承ください。

>2、コンフィグレータから、たとえばMLに50個程度のメールアドレスを一
>  気に登録・削除したりすることはできるのでしょうか?

 → 現時点では1ユーザー単位の登録・削除機能しかございません。

ご満足いただける内容でないことは重々承知しておりますが、以上が
いただきましたご質問への回答でございます。

何卒ご理解いただきますよう宜しくお願い申し上げます。

--------------------------------------
 クボタシステム開発 株式会社
 インターネット サーバー ホスティング
 サービス グループ info@k...
--------------------------------------
━以上、クボタからの返信━━━━━━━━━━━━━━━━━


SQL、JAVA、postgreSQLのいずれも使用できないとのことで、ここのrserverの利用は難しいかもしれませんね。

ちなみにSQL、JAVA、postgreSQLを使用できる@Serverというのは、クボタの最上級のサーバです。

→  http://www.kubota.ne.jp/service/a_01.html

値段は、

初期費用     70万円より
運用費(年額)  120万円年より
---------------------------------
初年度     190万円以上

ということで、事務局で考えていた予算の3〜4倍です。

また、MLのメールアドレス登録・削除を行なう際に、「コンフィグレータ」から、1アドレスずつしかできないというのも、困る点です。
たとえばML立ち上げのときには、現在ですら100〜200アドレスぐらいを登録しています(FreeMLやe-groupでは50〜100個のアドレスを一気に登録できる)。
これを、1つ1つコピーペーストで登録しなければならなくなるのでは、事務作業がますます非効率になります。
たとえば、ML立ち上げの際だけ先方に以来して一気に登録してもらうことが可能であればいいのですが、この点、明日にでも確認してみます。

 

━以下、アイルからの返信━━━━━━━━━━━━━━━━━
株式会社 アイル・テクニカルサポートです。

此の度は弊社サービスにご関心を賜りましてありがとうございます。

ご返答が遅くなりまして大変申し訳ございません。
お問合せにご返信させていただきます。

なお、大変恐縮ではございますが、Cobalt RaQ2 につきましては、
お陰様をもちまして完売致しております。
その為ご返答内容につきましては、Cobalt RaQ3 でのご案内を
差し上げます。

> WEBを見ましたが、不確かな点があったので、確認のためメールします。
> 以下の点についてお答えいただければ幸いです。
> 1、SQL、JAVA、postgreSQLは、使用できるのでしょうか?

JAVAにつきましては、初期状態にてJava Runtime Environmentが
導入されております。JAVAサーブレットをご利用になられます場合、
必要なサーバウェアを導入して頂ければ、ご利用は可能でございます。

PostgreSQLにつきましても標準で導入されております。

その他のSQLにつきましても、お客様にてご用意頂きました上で、
ネットワーク経由でインストールして頂くことで、ご利用可能で
ございます。

> 2、バーチャルサービスでは、MLについて、
>   初期設定5000円、運営費1000円/月
>   となっていますが、この料金は Cobalt コースでも追加でかかるので
>   しょうか?

コバルトサーバにつきましては、標準でメーリングリスト機能が
準備されておりますので、お客様にてご設定頂くことで、ご利用
可能でございます。
その為、弊社ではコバルトサーバでのメーリングリスト機能ご利用に
つきましては、その初期費用及び月額料金は頂戴致しておりません。

> 3、管理者用のソフトが提供されるようですが、これはMLを開設・運営す
>   る際に、管理者側がML用の(Majordomo等で使われる)コマンドを覚え
>   る必要がないということでしょうか?

コバルトサーバのサーバ管理画面よりメーリングリストの追加や
その購読者の追加を行って頂くインターフェースを備えておりますが、
この画面は、メーリングリストの運営管理用ではございません為に、
お申出頂いておりますような、管理用のコマンドを不要にするもの
ではございません。

> 4、この管理者ソフトから、たとえばMLに50個程度のメールアドレスを一
>   気に登録・削除したりすることはできるのでしょうか?

お客様にて操作して頂く必要はございますが、管理画面上より、
メーリングリストの購読者の追加操作を行って頂くことが
可能でございます。

> 5、現在30のMLを、FreeMLなどの無料サービスを使って運営していますが、
>   これらをすべてサーバ側に移行したいと考えています。この場合、開
>   設するMLの数の制限はあるのでしょうか?
>
> 7、また、1MLあたりの人数制限はあるのでしょうか? バーチャルサー
>   ビスのオプションでMLを開くと、上限1000人という人数制限があるよ
>   うですが。

上限につきましてはmajordomoの仕様に準じます。
大変恐縮ではございますが、専用サーバプランであるコバルトサーバの
管理画面の操作を超えるご案内につきましては、ご容赦下さいます様、
お願い致します。

> 8、たとえば、MLによって、
>   ・管理者しか登録・解除できないML
>   ・会員が(会員専用ページから)任意に登録・解除できるML
>   という使い分けは実現できるでしょうか?
>   (そちらでこうしたモード設定を用意している場合もあるでしょうし、
>    こちらでプログラムを組むことが必要になる場合もあるとは思いま
>    すが)

大変恐縮ではございますが、標準でご用意致しておりますメーリング
リスト機能では、お申出頂いております機能を満たすことが出来ません。

大変お手数とは存じますが、お客様にて必要なソフトウェア等をご用意
頂くことで実現可能かと存じます。

> 9、たとえば、会員が自分の情報を会員ページから変更したり、管理者が
>   会員の情報を変更した場合に、サーバにデータベースを置いておいて
>   各アクションと連動させるということは可能なのでしょうか?

実現なさりたい機能のご説明より逸れておりましたら、大変恐縮では
ございますが、その旨ご指摘頂けますようお願い致します。

会員様のホームページにつきましては、サーバ管理者様にて
各ユーザへの権限を細かく設定して頂くことが可能でございます。
会員様個々のページは会員様のみでなく、その収容ドメイン(仮想
サイトと表現します)の管理者様でも情報の変更は可能で、また、
サーバの管理者様におきましても変更は可能でございます。
ただし、データベースとして何らかの動作と連動させるとなりますと、
お客様にてご用意されますデータベースの動作に依存致します。

なお、ご検討頂いておりますCobaltプランでは、
運用方法に関しましては弊社のご利用規約に反しない限りには
ご自由に設定いただける形となります。
ご利用規約に反するものとして例を挙げさせていただきますと、
アダルトコンテンツのホスティング、反社会的なソース・行為
(クラックシステム等)の公序良俗の範囲を逸脱するもの、

専用サーバーにつきましては、弊社では初期設定、電源投入までの
作業を行い、契約者様に管理者権限ごとお引き渡しいたします。
管理、運用に関しましてはセキュリティを含め、全て契約者様側の
責任におきまして行なっていただく形となりますため、弊社にては
一切のサポートが行なわれません。

お引き渡し後の環境整備、運用管理は全てお客様側の責任において
行なっていただき、サーバーウェアの追加、カスタマイズなどは
サポート対象外となりますのでご了承くださいますようお願い申し上げます。
現行ではお引渡し後のCGI実現等コンテンツへの追加サービスの商品は
ございませんのでご了承下さいませ。
また、お引渡し後追加する内容については、利用されるサーバーウェア
メーカーの方にお問合せ頂く形になります。

また、以下の認定ユーザ会様のサイトでは、コバルト利用における
様々な情報をご確認頂けるかと存じます。
http://cobaltqube.org/index-j.html

取り急ぎご連絡いたします。
宜しく御査収ください。

-----------------------------------------------
株式会社アイル
102-0074
東京都千代田区九段南3-3-6 ニッセイ麹町ビル3階
テクニカルサポート 常名 support@i...
TEL:03-3265-8000  FAX:03-3511-7713
受付時間 月〜金(9:00〜18:00 土・日・祝 除く)
-----------------------------------------------
━以上、アイルからの返信━━━━━━━━━━━━━━━━━

とのことでした。
気が付いたことを書いておきますと、

・MLの初期費用と運営費が追加でかからないことが判明。これだと値段は、

初期費用 8万円
基本料5万4800円×12月=65万7600円
--------------------------
     73万7600円

となる。

・質問3、への答に「管理用ソフトにML追加・MLへのユーザー追加などの画面はあるが、これは管理用のコマンドを不要にするものではない」とあるが、この答えの意味がいまひとつよくわからない。結局、登録・削除する事務局員が、majordomoのコマンドを覚えないといけないということか? 要再確認。

・5と7についての答えに、「1ML当たりの上限人数はmajordomoの仕様に順ずる」とあるが、これは具体的にはどういうことなのか。「majordomoを使っているので1000人以上は無理」ということなのか、あるいは「majordomoでも1000人以上は可能かもしれないが、わからないのでそちらで調べてくれ」という意味なのか……要確認。
(majordomoの人数制限について、ご存知の方がいらしたら教えてください)

 

全般的な感想としては、アイルの方が自由度は高いように感じましたが、これは逆にいうと、アイルからの答えにあるように、「一切のサポートを行なわない」=こちらで管理体制を整える必要がある、ということなのかな、とも思いました。

以上、また追加報告しますが、コメントいただければと思います。
**以上、3月6日のnam-systemへの投稿**********************************
**********************************************************************

以上です。
よろしくご意見お願いいたします。


80 投稿者: yumoto  <yumoto@h...>
Date: 2001年3月7日(水) 午後1時37分
タイトル: 提案−運営/規約 6


  湯本です。

退会時の赤字、黒字の処理ですが、

(1) 赤字は円で相殺してもらう(円は nam ファンドが受け取る)
(2) 黒字は nam ファンドに寄付してもらう

ということを、入会時の契約としておくといいと思います。
(死亡による退会の場合も。)
相当の事情をみとめる場合は、その限りでない、とのただし書きつきで。

以上です。

それではまた
yumoto hirokazu


81 投稿者: shogowatanabe@n...
Date: 2001年3月7日(水) 午後1時53分
タイトル: Re: [nam-project] $BDs0F!]5;=Q(J/ $B4IM}(J18


  渡辺です。

クボタに問い合わせました。
「提案−技術/ 管理17」と鉢合わせになったけど、とりあえずご確認下さい。

---------------------------------------------------------


早い返信ありがとうございます。
渡辺彰吾です。

「業者選定/サーバー選択に必要な質問」をします。
以下が御社の技術的なことに関して、私が得ている情報です。

1.vserver(年18万円の方)は、専用サーバではないので、大規模
なデータベースをウェブに置くことは禁じられている。
(但しテキストファイル、CSVファイルは全サービスラインで利
用可能。)

2.rserver(年36万円の方)なら、専用サーバなので大規模なデー
タベースを置くことも禁じられていない。

以下の要件のもと、プロジェクトが運営可能かご返答下さい。

3月末の立ち上げと、まだ未知数ですが今後の立ち上げの2つを分けて説明します。

3月末
言語はperlで、システム的にはperl→DBI→PostgreSQLです。
DBI通しているので、トランザクション処理可能なDBなら一応使えるはずですが、もしか
したらPostgres特有のSQL文つかってるかもしれません。
WebDBですが、複数のDBが必要になるかもしれません。


将来
perlで安定版まで開発が進んだら、現在のところJAVAで次世代バージョンを開発しようと
思っています。
Servlet、JSP、さらにJ2EEです。他の言語に対応することになるかもしれません。
また、個人的な見解ですが、日本語が読めないユーザーが増加するので国際化対応を考慮
し、DBも言語ごとにわける必要がでてくるかもしれません。


御社のシステムはNTですか?(NTだとしてもPostgreSQLはインストールできます。)
また、rootはいただけるのでしょうか?
将来に関してはまだ未知数ですが、年契約ですので対応可能かご返事下さい。

どちらにしろ、rserverの場合は大丈夫と思います。
しかし、vserverで運営できればと思います。

ご返事のほどよろしくお願いします。


>>はじめてメールを差し上げます。渡辺彰吾というものです。
>>vServerサービスかrServerサービスのどちらかのサービスで私が所属しますプロジェク
トを運営できればと思っております。
>>
>>※技術的なことに関するお問い合せは、
>>こちらではお受けできませんのでご了承ください。
>>
>>とのことですが、技術的なことに関する問い合せができるアドレスを教えてください。
>>
>>御社の日原様が技術的なことを理解しておれると聞いております。
>
>
>この度は弊社サービスをご検討賜り誠にありがとうございます。
>
>いただいたご質問の件ですが、業者選定/サーバー選択に必要なご質問であれば
>このアドレスに連絡をいただければ、技術部門と検討の上で、回答いたします。
>
>尚、弊社がサービスをご提供申し上げるポリシー上、ご満足いただける回答が
>できるか否かは、いただいたご質問の内容によりますのでその点はご了承賜り
>ますよう宜しくお願い申し上げます。
>
>--------------------------------------
> クボタシステム開発 株式会社
> インターネット サーバー ホスティング
> サービス グループ info@k...
>--------------------------------------


82 投稿者: go  <afake908@o...>
Date: 2001年3月7日(水) 午後2時37分
タイトル: Re: [nam-project] 提案−運営/規約 6


  こんにちわ。宮地です。

西部さんの提案について、です。

1)参加者の赤字の上限について

賛成します。

ぼくも、地元の商店街の人と企画している地域通貨の赤字上限について話したことが
あるのですが、そのときは取り引き総額の5%くらいが妥当ではないか、という結論
に達しました。

namとは違って、地元の地域通貨は共有する理念・思想というものを核としない地
域通貨です。だから「ただ乗り」が頻発するリスクもnamよりは多いのではない
か、と思います。が、上限5%設定で、ある程度は抑止できるのでは、ないかと考え
ました。

地域通貨の取り引き総額10万で5%=5千を上限と考えると、地域通貨が、商品交
換の「買い」取り引きのみに使われた場合、支払いは「地域通貨5%+円95%」です
から、
10万÷5%=200万×95%=190万円
となります。つまり、190万円つかってようやく10万円の得になるのですから、
「ただ乗り」を考えるような人にとっては、それほどオイシイ話ではないと思いま
す。

だから、問題は、そういった利益を求める欲ボケの「ただ乗り」よりも、西部さんも
おっしゃっているような「悪意のある破壊者・かく乱者」対策であろうと思われま
す。

2.namの循環について。

湯本さんが提議されたサラリーマン・学生・主婦がnamを獲得する方法に対して、西
部さんの提示された顱万髻万鵝砲砲弔い董基本的に賛成します。

ただ、顱砲両豺隋東京や大阪のような事務局のある地域系や階層系・学生のように
プロジェクトを始動させているところでは、仕事をつくることも可能でしょうが、そ
れ以外の会員数も少ない地域系や関心系では、どうすればいいのか、という問題があ
ると思います。

髻砲和┯性のある方法ですね。プロジェクトの資金集めとしても効果的でしょう。

顱万髻砲箸盍靄榲には賛成なんですが、ただ、ぼくとしては、自分が商売人のせい
か、お金は使わないと回らないと考えてしまいます。そのための仕組みをもっと用意
すべきではないでしょうか?

いまのところ受け取ったnamを使えるのは、NAMの会費やプロジェクトへの寄
付、それから湯本さんやぼくの提供するパン・農産物、批評空間社の書籍などの購入
の支払いの一部、コンピュータ技術者さんたちのコンピュータの指導への報酬くらい
ではないでしょうか?

いろんなサービスをいかに商品化するか、というアイデアを、二・三ヶ月の練習期間
中に会員さんたちに呼びかけて出してもらうという作業も必要なんじゃないでしょう
か?

3・namファンドについて

関心系・教育の山住さんはNAM大阪のMLで、フリースクールプロジェクトでの現
時点でのnamファンドの活用は難しいだろう、と書かれています。詳しいことはわ
からないのですが、たとえば銀行型のnamファンドをフリースクールに融資すると
言うことは可能でしょう。フリースクールプロジェクトが融資されたnamをどのよ
うに使うかはわかりませんが、その場合も、使えないと意味がありませんね。

同じことの繰り返しになりますが、いかに使えるか(稼げるか)のスキームをうまく
作っていくかが、重要になると思います。

次に、namプロジェクトにおいて、サービス対価を支払うという方式についてです
が、その場合の対価支払いの算定基準は、どうなるのでしょうか?

こういったプロジェクトでのサービスは、基本的には労働時間に対応していませんか
ら、参加しているサービスの内容によって対価が決められる、などなどの算定基準
が、オープンにされている必要があるとおもいます。

4.について

試験期間は絶対にひつようだと思います。ぼくもまだ、恥ずかしながら、GETSシ
ステムがよく理解できていないんで…。


83 投稿者: Makoto Nishibe  <nishibe@e...>
Date: 2001年3月7日(水) 午後2時38分
タイトル: 連絡−センター評議会へのチーム結成報告


  西部です。

本プロジェクトチーム結成について以下のようにセンター評議会に報告しました。い
ずれみなさんのところへもセンター事務局から配信されてくるとは思いますが,お知
らせしておきます。

 

       「namプロジェクトチーム」結成のご報告

                     2001年3月7日
                     namプロジェクトチーム代表 西部 忠


以前お知らせしたnamプロジェクトチーム・メンバー募集にたいし,NAM-LETSやNAMコ
ンピュータなどの関心系に属する会員が応募してくれました。積極的な参加の意志と
高い意欲を示していただいたことに感謝します。

namプロジェクトチームは,以下の通り,応募者から選抜した7名を含む総勢11名で
発足しました。2月25日に「nam-project」というML(eGroups)を開設し,プロジ
ェクトの討議と活動を開始しました。プロジェクトチームに関する規定により,発案
者である私(LETS-NAM代表)がプロジェクトチーム代表になりました。副代表には鈴
木健さんが選出されました。

◆namプロジェクトチーム・メンバー

西部忠 NAM-LETS代表,NAM北海道
鈴木健 GETS開発者,NAM-LETS,NAM東京
岡崎乾二郎 NAM芸術代表,NAM東京
鈴木泰生 NAMコンピュータ,NAM東京
阪口弘人 NAMコンピュータ,NAM東京
穂積一平 NAMコンピュータ,NAM大阪
宮地剛 NAM-LETS,NAM大阪
湯本裕和 NAM農業,NAM中部
渡辺彰吾 NAM-LETS,NAMコンピュータ,NAM芸術,NAM大阪
柄谷行人 NAM代表,NAM大阪
高瀬幸彦 NAMセンター事務局代表,NAM東京

namプロジェクトの内容は次の二つに大きく分けられます。

●技術/管理→GETSのNAM向け仕様開発/実装(サーバー設置)/システム管理/サ
ポート体制

●運営/規約→namに関する当プロジェクトチームにおける意志決定/プロジェクト
進行/運営上規約作成/namファンドなどスキームの検討

各メンバーはどちらかのプロジェクト内容に主に従事するかを選択してもらい,討議
を進めています。現在までに,

・自己紹介
・各メンバーの技術/管理部門と運営/規約部門への振り分け
・議事進行規定
・GETSの開発環境,現状,今後の課題に関する説明
・会員データベースとの統合可能性
・サーバーの選定
・想定会員数
・GETSへの機能付加
・GETSのNAM仕様化
・namの規約
・namの循環方法
・namファンド方式

などについて報告,提案,討議がされました。

センター評議会へのnamプロジェクト提案時には,3月末までにNAM-LETSを実現する
プログラムGETSをサーバー上に実装し,NAMの全会員,各関心系,地域系,階層系,
協力団体などの口座を設定し,試験的に稼働する予定でした。しかし,プロジェクト
チームの発足が遅れたので,システムの稼働開始は4月以降になるかもしれません。
ご了承下さい。

教育,法律,農業,芸術,生協,労働,理論,第三世界その他の関心系,東京や大阪
を初めとする地域系,学生など階層系からこのプロジェクトにたいする意見やアイデ
ィアを出してもらえれば,それをできるだけプロジェクトに反映させたいと思います
。また,GETSの試行期間には全会員からいろんな意見を出してもらい,それを参考に
してシステムを改良していくことになるでしょう。ご協力をお願いします。

なお,今のところnamプロジェクトのMLは会員に公開していませんが,今後発足する
他のプロジェクトチームの参考にもなるでしょうから,将来的にはログを公開したい
と考えています。プロジェクトの進行についてはこれからも適宜報告していく予定で
す。

namプロジェクトについてのご意見,ご質問は私宛メールでお願いします。

以上

 

 


=============================================
    西部忠 Makoto, NISHIBE
  北海道大学経済学部
  Faculty of Economics,
  University of Hokkaido
    E-mail: nishibe@e...
    http://sun.econ.hokudai.ac.jp/~nishibe
=============================================


84 投稿者: shogowatanabe@n...
Date: 2001年3月7日(水) 午後2時36分
タイトル: Re: [nam-project] $BDs0F!]5;=Q(J/ $B4IM}(J19


  渡辺です。

アイルについて

鈴木さん:
>アイルに関しては知り合い(西部さんも知り合いの渡邉さん)
>がホスティングサービスを使っているのですが、
>DBIをローカルにインストールすることができて、DBを使える
>ところまでは確認してあります。DBMSがPostgresなので、
>その辺の心配はないでしょう。

日向さん:
>━以下、アイルからの返信━━━━━━━━━━━━━━━━━
>株式会社 アイル・テクニカルサポートです。
>
>此の度は弊社サービスにご関心を賜りましてありがとうございます。
>
>ご返答が遅くなりまして大変申し訳ございません。
>お問合せにご返信させていただきます。
>
>なお、大変恐縮ではございますが、Cobalt RaQ2 につきましては、
>お陰様をもちまして完売致しております。
>その為ご返答内容につきましては、Cobalt RaQ3 でのご案内を
>差し上げます。
>
>> WEBを見ましたが、不確かな点があったので、確認のためメールします。
>> 以下の点についてお答えいただければ幸いです。
>> 1、SQL、JAVA、postgreSQLは、使用できるのでしょうか?
>
>JAVAにつきましては、初期状態にてJava Runtime Environmentが
>導入されております。JAVAサーブレットをご利用になられます場合、
>必要なサーバウェアを導入して頂ければ、ご利用は可能でございます。
>
>PostgreSQLにつきましても標準で導入されております。


というわけで、nam-systemがアイルを選択する場合、nam-projectとしては問題なしということで、
よろしいですか?>鈴木さん


クボタについて

日向さん:

>
>
>*********************************************************************
>**以下、3月6日のnam-systemへの投稿*********************************
>
>日向です。
>
>クボタとアイルへの追加質問に対する答えが返ってきましたので、報告します。
>
>━以下、クボタからの返信━━━━━━━━━━━━━━━━━
>引き続き弊社サービスをご検討賜り誠にありがとうございます。
>
>>追加で2点、確認させてください。
>>rserverノービスとパワーのコースについてです。
>>1、SQL、JAVA、postgreSQLは、使用できるのでしょうか?
>
> → 誠に申し訳ございませんが、 perl のみでごさいます。
>   上記ご要望が利用可能な環境は@Server サービス シリーズのみで
>   ございます。何卒ご了承ください。
>
>>2、コンフィグレータから、たとえばMLに50個程度のメールアドレスを一
>>  気に登録・削除したりすることはできるのでしょうか?
>
> → 現時点では1ユーザー単位の登録・削除機能しかございません。
>
>ご満足いただける内容でないことは重々承知しておりますが、以上が
>いただきましたご質問への回答でございます。
>
>何卒ご理解いただきますよう宜しくお願い申し上げます。
>
>--------------------------------------
> クボタシステム開発 株式会社
> インターネット サーバー ホスティング
> サービス グループ info@k...
>--------------------------------------
>━以上、クボタからの返信━━━━━━━━━━━━━━━━━
>
>
>SQL、JAVA、postgreSQLのいずれも使用できないとのことで、ここのrserverの利用は難しいかもしれませんね。
>
>ちなみにSQL、JAVA、postgreSQLを使用できる@Serverというのは、クボタの最上級のサーバです。
>
>→  http://www.kubota.ne.jp/service/a_01.html
>
>値段は、
>
>初期費用     70万円より
>運用費(年額)  120万円年より
>---------------------------------
>初年度     190万円以上
>
>ということで、事務局で考えていた予算の3〜4倍です。
>
>また、MLのメールアドレス登録・削除を行なう際に、「コンフィグレータ」から、1アドレスずつしかできないというのも、困る点です。
>たとえばML立ち上げのときには、現在ですら100〜200アドレスぐらいを登録しています(FreeMLやe-groupでは50〜100個のアドレスを一気に登録できる)。
>これを、1つ1つコピーペーストで登録しなければならなくなるのでは、事務作業がますます非効率になります。
>たとえば、ML立ち上げの際だけ先方に以来して一気に登録してもらうことが可能であればいいのですが、この点、明日にでも確認してみます。
>
>

というわけで、クボタはムリですね。


85 投稿者: shogowatanabe@n...
Date: 2001年3月7日(水) 午後3時42分
タイトル: Re: [nam-project] $BDs0F!]5;=Q(J/ $B4IM}(J20


  渡辺です。

クボタから返答がありました。いちおう、ご確認下さい。

>(ex.長距離系のキャリア等であれば実現可能かと・・・)
ということでした。


>引き続き弊社サービスをご検討賜り誠にありがとうございます。
>以下にご質問いただきました点につき回答申し上げます。
>
>>1.vserver(年18万円の方)は、専用サーバではないので、大規模
>>なデータベースをウェブに置くことは禁じられている。
>>(但しテキストファイル、CSVファイルは全サービスラインで利
>>用可能。)
>>
>>2.rserver(年36万円の方)なら、専用サーバなので大規模なデー
>>タベースを置くことも禁じられていない。
>
> → 誠に申し訳ございませんが、不可でございます。
>
>>以下の要件のもと、プロジェクトが運営可能かご返答下さい。
>>
>>3月末の立ち上げと、まだ未知数ですが今後の立ち上げの2つを分けて説明します。
>>
>>3月末
>>言語はperlで、システム的にはperl→DBI→PostgreSQLです。
>>DBI通しているので、トランザクション処理可能なDBなら一応使えるはずですが、もし
かしたらPostgres特有のSQL文つかってるかも
>しれません。
>>WebDBですが、複数のDBが必要になるかもしれません。
>>
>>
>>将来
>>perlで安定版まで開発が進んだら、現在のところJAVAで次世代バージョンを開発しよう
と思っています。
>>Servlet、JSP、さらにJ2EEです。他の言語に対応することになるかもしれません。
>>また、個人的な見解ですが、日本語が読めないユーザーが増加するので国際化対応を考
慮し、DBも言語ごとにわける必要がでてくる
>かもしれません。
>>
>>
>>御社のシステムはNTですか?(NTだとしてもPostgreSQLはインストールできます。)
>>また、rootはいただけるのでしょうか?
>>将来に関してはまだ未知数ですが、年契約ですので対応可能かご返事下さい。
>>
>>どちらにしろ、rserverの場合は大丈夫と思います。
>>しかし、vserverで運営できればと思います。
>>
>>ご返事のほどよろしくお願いします。
>
> → DB設置は@Serverサービスのみでございます。
>   しかも開発は弊社が行なう というものです。
>   (これは弊社がサービスをご提供していく上でのポリシーで
>    ございますので何卒ご了承ください。)
>   またrootは公開してございません。
>   (これも弊社がサービスをご提供していく上でのポリシーで
>    ございますので何卒ご了承ください。)
>
>   弊社はASPを指向していますので、ファシリティのみを
>   ご提供するサービス形態は残念ながら提供していません。
>
>   差し出がましい様ですが、ファシリティを提供する形態を
>   主とされている業者にお問合せいただく方が、貴社の
>   ご要望に答えていただけるのではないかと存じます。
>   (ex.長距離系のキャリア等であれば実現可能かと・・・)
>
> ご満足いただける回答でないことは承知しておりますが、何卒
> 弊社状況をご理解賜りますよう宜しくお願い申し上げます。
>
>--------------------------------------
> クボタシステム開発 株式会社
> インターネット サーバー ホスティング
> サービス グループ info@k...
>--------------------------------------


86 投稿者: makoto nishibe  <nishibe@r...>
Date: 2001年3月7日(水) 午後6時28分
タイトル: Re: [nam-project] 提案−運営/規約7


  こんにちは,西部です。

>  >「トレードオフのある評判オプション」っていうのはどういうものですか?
>
> もう一次元情報を増やして、赤字に売るとマイナス、黒字に売るとプラスになるような
> 指標です。取引の分割や集約に関わらず同じ数字にするとしたら、やり方はひとつしか
> ないですよね。
> ゼロサムになるわけじゃありませんが、長期的にはトレードオフになります。

だいたい考えていることはわかりましたが,もう少し展開してくれませんか。

少しし赤字を保有していない者への売りも全部マイナスにしてしまうのはどうでしょ
うか。一定の赤字額(閾値)を超えた赤字を持っている人に対する売りをマイナス,
それ以外はゼロとかできないのかな。まだ理解できていないかもしれません。

>  >言いたいことは,この二つを最もシンプルに統合したところがGETSの「イノベーショ
>  >ン」として評価したいということです。うまく伝わらなかったのかな。
>
> いや、伝わってますよ。
> でもイノベーションというほどのことではないです。
> ksquareなんかのほうが断然完成度が高いですし。

完成度は後から伴ってくると期待してますから。

>  >> GETS=約束型というのはNAM=柄谷行人と同じくらいの偏見です。
>  >> EMACS=EDITORというのと同じくらいの偏見です。
>  >> GETS=鈴木健も同様に偏見です。っていうか偏見にしたい。。。
>  >
>  >だれの偏見ですか?ぼくは「約束型」というタームは使っていませんが。LETSの基本
>
> 約束型は取引システムと決済システムのかましみたいなやつですね。
> 取引システムとしてはフリマ型のほうがいいかもしれないですね。
> まいったな。別に文面ほど激しいつっこみじゃないのですが。
> むしろ、ギャグなんですけど。ちゃんと”落ち”つけてるじゃないですか。

落ちてないと思うけどね。

>  >したいけど今はできません。プログラミング言語を勉強しないと。
>  >自然言語であれこれ言うというのでは,あんまりコミットにならないかな(というか
>  >,迷惑?)。
>
> いや。そんなことないです。ただ、
> http://www.freeml.com/ml_view.php?ml=gets-dev&pg=12
> みたいに、gets-devかgets-officeかgets-userでなげてくれると助かります。
> ぼくだけが持ってる情報だと価値は下がっちゃいますから。
> 開発コミュニティやユーザコミュニティで共有しましょう。

ここでの議論もいずれgets-devやgets-officeやgets-userなどの開発コミュニティや
ユーザコミュニティと共有してもらえばいいと思います。

 

***********************************************
  西部 忠 NISHIBE, Makoto
  北海道大学大学院経済学研究科
  e-mail: nishibe@e...
  Homepage: http://www.econ.hokudai.ac.jp/~nishibe/
***********************************************


87 投稿者: Makoto Nishibe  <nishibe@e...>
Date: 2001年3月7日(水) 午後6時42分
タイトル: Re: [nam-project] 提案−運営/規約 8.1


  こんにちは,西部です。

一カ所訂正です。すみません。

> いまのところ受け取ったnamを使えるのは、NAMの会費やプロジェクトへの寄
> 付、それから湯本さんやぼくの提供するパン・農産物、批評空間社の書籍などの購入
> の支払いの一部、コンピュータ技術者さんたちのコンピュータの指導への報酬くらい
> ではないでしょうか?

namでないと買えないという「一品」をたくさん作っていくことだと思います。
nam用コモディティ開発の担当になっていただけませんか>湯本さん

は,

namでないと買えないという「一品」をたくさん作っていくことだと思います。
nam用コモディティ開発の担当になっていただけませんか>宮地さん,湯本さん

でした。


***********************************************
  西部 忠 NISHIBE, Makoto
  北海道大学大学院経済学研究科
  e-mail: nishibe@e...
  Homepage: http://www.econ.hokudai.ac.jp/~nishibe/
***********************************************


88 投稿者: Makoto Nishibe  <nishibe@e...>
Date: 2001年3月7日(水) 午後6時40分
タイトル: Re: [nam-project] 提案−運営/規約 8


  こんにちは,西部です。

> 1)参加者の赤字の上限について
>
> 賛成します。
>
> ぼくも、地元の商店街の人と企画している地域通貨の赤字上限について話したことが
> あるのですが、そのときは取り引き総額の5%くらいが妥当ではないか、という結論
> に達しました。
>
> namとは違って、地元の地域通貨は共有する理念・思想というものを核としない地
> 域通貨です。だから「ただ乗り」が頻発するリスクもnamよりは多いのではない
> か、と思います。が、上限5%設定で、ある程度は抑止できるのでは、ないかと考え
> ました。
>
> 地域通貨の取り引き総額10万で5%=5千を上限と考えると、地域通貨が、商品交
> 換の「買い」取り引きのみに使われた場合、支払いは「地域通貨5%+円95%」です
> から、
> 10万÷5%=200万×95%=190万円
> となります。つまり、190万円つかってようやく10万円の得になるのですから、
> 「ただ乗り」を考えるような人にとっては、それほどオイシイ話ではないと思いま
> す。
>
> だから、問題は、そういった利益を求める欲ボケの「ただ乗り」よりも、西部さんも
> おっしゃっているような「悪意のある破壊者・かく乱者」対策であろうと思われま
> す。

鈴木さんが考えている方法ももう少し説明を聞いて検討してみましょう。

> 2.namの循環について。
>
> 湯本さんが提議されたサラリーマン・学生・主婦がnamを獲得する方法に対して、西
> 部さんの提示された顱万髻万鵝砲砲弔い董基本的に賛成します。
>
> ただ、顱砲両豺隋東京や大阪のような事務局のある地域系や階層系・学生のように
> プロジェクトを始動させているところでは、仕事をつくることも可能でしょうが、そ
> れ以外の会員数も少ない地域系や関心系では、どうすればいいのか、という問題があ
> ると思います。
>
> 髻砲和┯性のある方法ですね。プロジェクトの資金集めとしても効果的でしょう。
>
> 顱万髻砲箸盍靄榲には賛成なんですが、ただ、ぼくとしては、自分が商売人のせい
> か、お金は使わないと回らないと考えてしまいます。そのための仕組みをもっと用意
> すべきではないでしょうか?

 顱万髻砲読めないのですが。どんな仕組みがあればもっと回りそうか提案をお願
いします。

> いまのところ受け取ったnamを使えるのは、NAMの会費やプロジェクトへの寄
> 付、それから湯本さんやぼくの提供するパン・農産物、批評空間社の書籍などの購入
> の支払いの一部、コンピュータ技術者さんたちのコンピュータの指導への報酬くらい
> ではないでしょうか?

namでないと買えないという「一品」をたくさん作っていくことだと思います。
nam用コモディティ開発の担当になっていただけませんか>湯本さん

> いろんなサービスをいかに商品化するか、というアイデアを、二・三ヶ月の練習期間
> 中に会員さんたちに呼びかけて出してもらうという作業も必要なんじゃないでしょう
> か?

賛成です。こういうことは少数で考えるより,大勢の現場の知識を吸い上げる方が早
いでしょう。

> 3・namファンドについて
>
> 関心系・教育の山住さんはNAM大阪のMLで、フリースクールプロジェクトでの現
> 時点でのnamファンドの活用は難しいだろう、と書かれています。詳しいことはわ
> からないのですが、たとえば銀行型のnamファンドをフリースクールに融資すると
> 言うことは可能でしょう。フリースクールプロジェクトが融資されたnamをどのよ
> うに使うかはわかりませんが、その場合も、使えないと意味がありませんね。

> 同じことの繰り返しになりますが、いかに使えるか(稼げるか)のスキームをうまく
> 作っていくかが、重要になると思います。

そう。すべてそこに帰着します。

> 次に、namプロジェクトにおいて、サービス対価を支払うという方式についてです
> が、その場合の対価支払いの算定基準は、どうなるのでしょうか?

支払い側(プロジェクト,地域系,関心系など)が対価を提示して,提供者と話し合
うことになるでしょう。

> こういったプロジェクトでのサービスは、基本的には労働時間に対応していませんか
> ら、参加しているサービスの内容によって対価が決められる、などなどの算定基準
> が、オープンにされている必要があるとおもいます。

プロジェクトへの貢献の算定に相対値貨幣を応用することはできそうです。


***********************************************
  西部 忠 NISHIBE, Makoto
  北海道大学大学院経済学研究科
  e-mail: nishibe@e...
  Homepage: http://www.econ.hokudai.ac.jp/~nishibe/
***********************************************


89 投稿者: Makoto Nishibe  <nishibe@e...>
Date: 2001年3月7日(水) 午後6時53分
タイトル: Re: [nam-project] 提案−運営/規約 9


  西部です。

At 1:37 PM +0900 01.3.7, yumoto wrote:
> 湯本です。
>
> 退会時の赤字、黒字の処理ですが、
>
> (1) 赤字は円で相殺してもらう(円は nam ファンドが受け取る)
> (2) 黒字は nam ファンドに寄付してもらう
>
> ということを、入会時の契約としておくといいと思います。
> (死亡による退会の場合も。)
> 相当の事情をみとめる場合は、その限りでない、とのただし書きつきで。

死亡による退会時は1)赤字は円で相殺してもらう,は除外してもいい気がするので
すが。そうでないと,相続人がこれを精算しないといけませんね。

namで相続や遺贈をどう扱うか考えておかないといけないですね。
私は,会員間でのnamの贈与は認められていると考えていますが,これについて何か
問題がありますか。


***********************************************
  西部 忠 NISHIBE, Makoto
  北海道大学大学院経済学研究科
  e-mail: nishibe@e...
  Homepage: http://www.econ.hokudai.ac.jp/~nishibe/
***********************************************


90 投稿者: Makoto Nishibe  <nishibe@e...>
Date: 2001年3月7日(水) 午後7時10分
タイトル: Re: [nam-project] 提案−運営/規約 10


  西部です。

まだ不配が続くのでeGroupsに問い合わせ中です。
どうもこれはぼくだけの問題のようですね。

At 10:27 AM +0900 01.3.7, yumoto wrote:
> こんにには、湯本です。
>
> 参加者の赤字の上限規定について、つぎのように考えてみました。
>
> (1) 赤字は、コミュニティ全体として引き受けるので、共有地の悲劇を
> 抑えるため、参加者の赤字上限を、たとえば、一口座5万 nam に固定
> する。

上限固定ですね。私が出した上限可変の案についてはどう思われますか。

> (2) コミュニティ全体では引き受けない種類の赤字を、あらたに導入し、
> この赤字の上限については、とくに定めない。(実際には、上限のガイ
> ドラインはもうける)
>
> この(2) が、ミソです。たとえばパン屋が、1年後から有効のパンの引
> 換券を発行するようなケースです。個人が借用書を発行するケースもあ
> る。引換券や借用書は、それを引き受ける人が nam で買い取り、すべ
> てのリスクを負担する。
>
> 赤字を、引換券や借用書の姿に変換することで、リスクをコミュニティ
> 全体から、引換券などを引き受ける人に移動させることになります。あ
> えてリスクを引き受けようとする人は、引換券などの発行者を支援する
> ことになります。
>
> これは、円からnamへの交換(コミュニティ・ウェイの応用)とならぶ、
> 直接金融の手段にもなります。( nam から引換券、借用書への交換。)
>
> 森野さんの言われている、借用書を流通させるやり方は、借用書そのも
> のを通貨として考えるわけですね。それと違って、通貨はあくまで nam
> で一本化し、それを補助する金融的な手段として、引換券や借用書を用
> いる、というわけです。

「引換券や借用書は、それを引き受ける人が nam で買い取り、すべてのリスクを負
担する。」「通貨はあくまで nam で一本化し、それを補助する金融的な手段として
、引換券や借用書を用いる」

つまり,namを貨幣とする会員個人間の信用(債券・債務関係)をもう一度入れると
いう提案ですね。赤字の上限がないので,自己責任で引換券や借用書をかなりの額発
行できるというメリットが商売側にある,というのが提案の理由ですか。

引換券は将来商品を提供する約束,借用書は将来namを返済する約束ですね。引換券
や借用書を参加者が買うことを一種の「先渡契約」あるいは「投資」とみなすという
ことになると思いますが,これでいいのでしょうか。

商店は円とnamを混合で値段を付けるでしょうが,この方式だと円とnamの関係がどう
なるのかもう少し説明していただけると助かります。

 

***********************************************
  西部 忠 NISHIBE, Makoto
  北海道大学大学院経済学研究科
  e-mail: nishibe@e...
  Homepage: http://www.econ.hokudai.ac.jp/~nishibe/
***********************************************


91 投稿者: Makoto Nishibe  <nishibe@e...>
Date: 2001年3月7日(水) 午後7時30分
タイトル: 連絡ー配信不良


  西部です。

eGroupsより不配にかんする回答が来ました。以下に張り付けました。

2/20以降大学関係の'ac.jp'ドメイン宛てメールの配信漏れが多発しているようです。
原因は不明で調査中,当面ac.jpドメイン以外のアドレスを使って欲しいとのことです。
面倒ですが仕方ありません。ということで,私以外には関係ないようです。

> Date: Wed, 07 Mar 2001 18:03:08 +0900
> From: eGroups JAPAN サポートチーム 関 <akira-support@e...>
> Subject: Re: 配信不良
> To: nishibe@e...
> Mime-Version: 1.0
>
> eグループ サポートチームの関と申します。
> 平素はeグループをご利用頂きまして、誠にありがとうございます。
>
> >お問い合わせ:配信不良
> >種別:【】
> >
> >先ほど送信したとき,正しくないパスワードを入力したので再送します。
> >
> >nam-projectオーナーの西部といいます。
> >
> >上記のメールアドレス(nishibe@e...)には,全72通の内20通ぐ
> >らいが不配になっています。ある一定の期間だけの不配ではなく,とびとびに
> >不配になります。webで確認したところ,本日も二通が届いていません。念のた
> >め,自分のもう一つのメールアドレスを登録しましたが,そちらにはすべての
> >メールが配信されているようです。受信サーバーの問題かと思いましたが,本
> >日はサーバーは正常に稼働しているとのこと。ML内の他のメンバーには同様の
> >症状は現れていないとのことです。
> >
> >サポートをよろしくお願いします。
>
> ご指摘の通り、現在'ac.jp'ドメイン宛てメールの配信漏れが発生致しております。
>
> 以下に挙げるのが、2月中にeグループから'ac.jp'ドメイン宛ての
> メール配信数と、配信不能メール数の一覧表です。
>
> 尚、2月19日以前には配信できなかったメールの数が1日あたり3,500通未満
> だったため、弊社内で利用している「配信不能になるメールが多い
> ドメイン」のリスト中に'ac.jp'ドメインは入っていませんでした。
>
> ------------------------------------------------------------
> 日付   配信数       配信不能数
> 2/01   111178 ac.jp
> 2/02   106729 ac.jp
> 2/03    82870 ac.jp
> 2/04    66634 ac.jp
> 2/05    93343 ac.jp
> 2/06   141849 ac.jp
> 2/07   110962 ac.jp
> 2/08   108501 ac.jp
> 2/09   108613 ac.jp
> 2/10    82924 ac.jp
> 2/11    63559 ac.jp
> 2/12    65046 ac.jp
> 2/13    93814 ac.jp
> 2/14   142348 ac.jp
> 2/15   102331 ac.jp
> 2/16   102624 ac.jp
> 2/17    76220 ac.jp
> 2/18    54059 ac.jp
> 2/19    70733 ac.jp
> 2/20   116356 ac.jp 4614 ac.jp
> 2/21    84418 ac.jp 13939 ac.jp
> 2/22    80942 ac.jp 18211 ac.jp
> 2/23    83215 ac.jp 15229 ac.jp
> 2/24    66445 ac.jp 16070 ac.jp
> 2/25    46163 ac.jp 15643 ac.jp
> 2/26    73582 ac.jp 11053 ac.jp
> 2/27   114634 ac.jp 9710 ac.jp
> 2/28    90127 ac.jp 13047 ac.jp
> ------------------------------------------------------------
>
> この一覧を見ると、2月21日以降この数が急激に増加していることが
> 分かります。発生しているエラーメッセージを見ると、
> 'Mail server for "*****.ac.jp" unreachable for too long'
> というエラーが多数発生していることが分かりました。
>
> 現在確認できている限り、このエラーのほぼ全てが'ac.jp'ドメイン
> 宛てへのメール配信に際して発生しています。但し、全ての'ac.jp'
> ドメインに対しての配信が上手く行っていない訳ではありません。
> 例えば、多数のeグループ利用者がいるwaseda.ac.jp ドメインに
> ついてはこの問題は発生しておりません。
>
> 弊社宛てにお問い合わせを頂いたドメイン(tiu.ac.jp を含む)に
> ついては、全てeグループのネームサーバにキャッシュされており、
> こちらでも何が原因なのか、なぜ'ac.jp'(日本の大学)のドメインに
> おいてのみこのような現象が発生するのか、掴み兼ねている状況です。
>
> 参考まで、2月21日以降、この問題が原因と思われるメールの配信
> トラブルのお問い合わせがあったドメインのリストです。(順不同)
>
> ------------------------------------------------------------
> aitech.ac.jp
> osaka-u.ac.jp
> chiba-u.ac.jp
> kyushu-u.ac.jp
> ims.ac.jp
> tiu.ac.jp
> u-shizuoka-ken.ac.jp
> isas.ac.jp
> tokyo-u-fish.ac.jp
> isas.ac.jp
> kyoto-u.ac.jp
> aasa.ac.jp
> ritsumei.ac.jp
> ------------------------------------------------------------
>
> 大変ご迷惑をおかけいたしますが、問題が解決するまでac.jpドメイン以外の
> アドレスを併用していただくようお願い申し上げます。
>
> 今後ともeグループをよろしくお願いいたします。
>
>
> ------------------------------------------------------------------
> eグループ サポートチーム 関 supportjp@e...
> *eグループ: http://www.egroups.co.jp/
> *ヘルプ・よくあるご質問は: http://help.egroups.co.jp/
> *初心者マニュアル: http://www.egroups.co.jp/local/dekiru/
> ------------------------------------------------------------------
> ★ご返信頂く場合には、引継ぎのため必ず本文の引用をお願い致します。
> ★お送りするお返事の電子メールは、お客様宛てのものであり、
>   許可なく電子メールの一部または全体を転用、 2次使用することは
>   著作権法上認められておりません。
>


***********************************************
  西部 忠 NISHIBE, Makoto
  北海道大学大学院経済学研究科
  e-mail: nishibe@e...
  Homepage: http://www.econ.hokudai.ac.jp/~nishibe/
***********************************************


92 投稿者: go  <afake908@o...>
Date: 2001年3月7日(水) 午後8時55分
タイトル: Re: [nam-project] 提案−運営/規約 8


  宮地です。

>  どんな仕組みがあればもっと回りそうか提案をお願
> いします。
>……
> namでないと買えないという「一品」をたくさん作っていくことだと思います。
> nam用コモディティ開発の担当になっていただけませんか>湯本さん

うーん。難しいですよね。
namが、よく循環するって、取り引きが頻繁に行われることですよね。パン屋の商
売と同じ悩みです、ほんと。それから「一品」を考えるってのも、同じです。難し
い…。

たとえば、こんなのはどうでしょうか?
先日、NAM大阪の定例会合で関心系・芸術に参加している人たちと話す機会があっ
たんですけど、「芸術では飯は食えない」「作品をいかにLETS取り引きに乗せる
ことができるか」、という考えをもっておられる方が、多かったです。

namでないと買えない「一品」を作るときの方向性のひとつとして、そういった
「芸術」を取り引き対象するというふうに考えられるんじゃないでしょうか。

つまり専門領域で、「円」では商品化しにくい、つまり飯が食えない芸術や理論・知
識・技術を、namにおいて重点的に商品化していく。西部さんがGETSの提供し
ますの欄に「経済イソップ物語」を挙げておられるのと同じですよね。(ぼくも「夫
婦漫才」を挙げてますが…。あれは悪ふざけです。スイマセン)

もちろん、需要があるかどうかは別として、そういった方向性を提示することで、n
amの通貨としての性格も提示できるんじゃないでしょうか?

つづきはまた今夜考えます。

投稿者: Ken Suzuki  <ken@s...>
Date: 2001年3月7日(水) 午後9時13分
タイトル: Re: [nam-project] 提案−運営/規約7

 
  こんにちは。鈴木です。

 >>  >「トレードオフのある評判オプション」っていうのはどういうものですか?
 >>
 >> もう一次元情報を増やして、赤字に売るとマイナス、黒字に売るとプラスになるような
 >> 指標です。取引の分割や集約に関わらず同じ数字にするとしたら、やり方はひとつしか
 >> ないですよね。
 >> ゼロサムになるわけじゃありませんが、長期的にはトレードオフになります。
 >
 >だいたい考えていることはわかりましたが,もう少し展開してくれませんか。
 >
 >少しし赤字を保有していない者への売りも全部マイナスにしてしまうのはどうでしょ
 >うか。一定の赤字額(閾値)を超えた赤字を持っている人に対する売りをマイナス,
 >それ以外はゼロとかできないのかな。まだ理解できていないかもしれません。

口座-200の人に400のものを売って、口座が-600になったとすると、
400×{-600+(-200)}/2=-160000が書い手の評判情報に加わります。
この情報をそれなりに下げないようにするために、ひどくマイナスの
人にはモノを売らなくなるはずです。逆に、プラスの人はものが買いやすく
なります。どんな効果があるかまだ不明ですが。

 
94 投稿者: ippei hozumi  <ipfr_cat@d...>
Date: 2001年3月7日(水) 午後0時21分
タイトル: Re: [nam-project] 提案−運営/規約8

 
  ほづみです。

>
> つまり専門領域で、「円」では商品化しにくい、つまり飯が食えない芸術や理論・知
> 識・技術を、namにおいて重点的に商品化していく。西部さんがGETSの提供し
> ますの欄に「経済イソップ物語」を挙げておられるのと同じですよね。(ぼくも「夫
> 婦漫才」を挙げてますが…。あれは悪ふざけです。スイマセン)
>

思いつきなんですが、たとえば、コンピュータの使い方MLみたい
なので、そこに質問したら知ってるひとが丁寧に答えてくれるみた
いなのは、商品にならないのかな。

いつも思うんですが、コンピュータの教材というかHOWTOもの
って、たいてい「帯に短し・・・」で、そのくせちょっと専門的な
MLなんかのぞくと、そんなのも知らねえのか、という輩が多くて、
嫌になるんですよね。

まあ、コンピュータにかぎらず、そういう質疑応答のMLめいたも
のはどうなんでしょう。法律相談とかも思いつきますが・・・。


穂積一平
ipfr_cat@d...

http://home.interlink.or.jp/~ipfr_cat/

 
95 投稿者: Makoto Nishibe  <nishibe@e...>
Date: 2001年3月7日(水) 午後11時13分
タイトル: Re: [nam-project] 討議ー評判値

 
  西部です。

> 口座-200の人に400のものを売って、口座が-600になったとすると、
> 400×{-600+(-200)}/2=-160000が書い手の評判情報に加わります。
> この情報をそれなりに下げないようにするために、ひどくマイナスの
> 人にはモノを売らなくなるはずです。逆に、プラスの人はものが買いやすく
> なります。どんな効果があるかまだ不明ですが。

説明どうも。よくわかりました。

口座0の人が400のモノを買うと,買い手の評判値は400×(-400+0)/2=-80000
口座500の人が400のモノを買うと,買い手の評判値400×(100+500)/2=120000

となると。おもしろいですね。
買い手側の評判値が動くが,売り手側は動かない。

で,この評判値の下限に関するルールを設定するということですか。それともルール
とするのではなく,売り手の自由な判断に利用してもらうということですか。後者だ
とやはり売り手にはインセンティヴが働かないような気がします。

2者間AとBがゼロの口座からスタートし,AがBから400のモノを買い,その後,BがA
から同じ400のモノを買うとすると,口座は(0, 0),評判値は(-80000, 80000)となり
ますね。これをN回繰り返していくと,口座は(0, 0),評判値は(-80000×N,80000×
N)となります。

だから,下限を設けないと,Aの評判値を無限に大きくすることができる。下限を設
けても,一人が2つの口座間でこれをやり,一つを破棄していくと評判値を増やせま
す。

これに同じことを3つ以上の口座間でやると評判値は(-80000, 80000, 80000, ...)
というようにプラスサムになりますから,ループを長くすればするほどますます得に
なっていく。これ自体はおもしろいですね。ループをできるだけ長くするとみんなの
評判値が大きくなる。

空取引や複数口座が防げないと結局うまいやり方が出てきますね。でも,これはこの
方法の問題ではなく,すべてのやり方に当てはまるので,欠陥とはいえない。

気になるのは,最初に買うときに買い手の必ず評判値がマイナスになることです。で
も,買い手が貨幣を発行しないとnamの循環は始まらないので,この人はコミュニテ
ィに貢献しているともいえますね。つまり,LETSは貨幣制約がない(お金のない人も
買える=お金のない人にも売れる)はずだったのが,貨幣制約の代わりに評判値制約
が存在することになる。

つまり,買い手に制約が付くので,買い手と売り手は非対称的になる。これはLETSの
特性の変更につながる重要な問題です。もちろん,赤字に下限を設け,黒字には儲け
ないこともすでに,この非対称性を入れることになりますが,非対称性が大きくなる
のではないですか。

この点をどう考えればいいですかね。

 


***********************************************
  西部 忠 NISHIBE, Makoto
  北海道大学大学院経済学研究科
  e-mail: nishibe@e...
  Homepage: http://www.econ.hokudai.ac.jp/~nishibe/
***********************************************

 
96 投稿者: Makoto Nishibe  <nishibe@e...>
Date: 2001年3月7日(水) 午後11時14分
タイトル: Re: [nam-project] 提案−運営/規約 11

 
  西部です。

> >  どんな仕組みがあればもっと回りそうか提案をお願
> > いします。
> >……
> > namでないと買えないという「一品」をたくさん作っていくことだと思います。
> > nam用コモディティ開発の担当になっていただけませんか>湯本さん
>
> うーん。難しいですよね。
> namが、よく循環するって、取り引きが頻繁に行われることですよね。パン屋の商
> 売と同じ悩みです、ほんと。それから「一品」を考えるってのも、同じです。難し
> い…。
>
> たとえば、こんなのはどうでしょうか?
> 先日、NAM大阪の定例会合で関心系・芸術に参加している人たちと話す機会があっ
> たんですけど、「芸術では飯は食えない」「作品をいかにLETS取り引きに乗せる
> ことができるか」、という考えをもっておられる方が、多かったです。
>
> namでないと買えない「一品」を作るときの方向性のひとつとして、そういった
> 「芸術」を取り引き対象するというふうに考えられるんじゃないでしょうか。

「芸術」はありえますね。どうでしょう?>岡崎さん
それに,コンピュータプログラムも「作品」ですね。

> つまり専門領域で、「円」では商品化しにくい、つまり飯が食えない芸術や理論・知
> 識・技術を、namにおいて重点的に商品化していく。西部さんがGETSの提供し
> ますの欄に「経済イソップ物語」を挙げておられるのと同じですよね。(ぼくも「夫
> 婦漫才」を挙げてますが…。あれは悪ふざけです。スイマセン)

ぼくのも冗談です。経済学の理論や専門知識をいきなり提供してもどうかなとは考え
ました。

「「円」では商品化しにくい、つまり飯が食えない芸術や理論・知識・技術を、na
mにおいて重点的に商品化していく。」という方向性には賛成です。問題はその具体
化ですね。それとともに,パンとか米とか,生活必需品も入れないといけませんね。
いざ会員に声をかければ,意外にこういうものを提供できる人もいるのかもしれませ
ん。

 

 

 

***********************************************
  西部 忠 NISHIBE, Makoto
  北海道大学大学院経済学研究科
  e-mail: nishibe@e...
  Homepage: http://www.econ.hokudai.ac.jp/~nishibe/
***********************************************

 
97 投稿者: Ken Suzuki  <ken@s...>
Date: 2001年3月7日(水) 午後10時15分
タイトル: Re: [nam-project] 討議ー評判値2

 
  こんにちは。鈴木です。

In message "Re: [nam-project] 討議ー評判値",
Makoto Nishibe wrote...
 >西部です。
 >
 >> 口座-200の人に400のものを売って、口座が-600になったとすると、
 >> 400×{-600+(-200)}/2=-160000が書い手の評判情報に加わります。
 >> この情報をそれなりに下げないようにするために、ひどくマイナスの
 >> 人にはモノを売らなくなるはずです。逆に、プラスの人はものが買いやすく
 >> なります。どんな効果があるかまだ不明ですが。
 >
 >説明どうも。よくわかりました。
 >
 >口座0の人が400のモノを買うと,買い手の評判値は400×(-400+0)/2=-80000
 >口座500の人が400のモノを買うと,買い手の評判値400×(100+500)/2=120000
 >
 >となると。おもしろいですね。
 >買い手側の評判値が動くが,売り手側は動かない。

すみません。書き間違えました。
買い手でなくて売り手の数字を動かすのです。

 
98 投稿者: NAMセンター事務局  <info@n...>
Date: 2001年3月7日(水) 午後10時54分
タイトル: 提案−技術/ 管理21

 
  センター事務局の日向です。

nam-systemに先ほど投稿したメールを転送いたします。

-------------------------------------------------------------------
クボタとアイルへの追加質問に対する返事が来ましたのでご報告します。

**以下、クボタよりの返信*******************************************
> > >2、コンフィグレータから、たとえばMLに50個程度のメールアドレスを一
> > >  気に登録・削除したりすることはできるのでしょうか?
> >
> >  → 現時点では1ユーザー単位の登録・削除機能しかございません。
> >


>この点についてですが、大量のメールアドレス(50〜300程度)をいっせいに登
> 録する必要があるのは、
> ・最初のML立ち上げの際
> ・大量の入会があった場合
>なのですが、こうした場合に限って、そちらで登録を代行していただくというこ
>とは可能なのでしょうか? また可能な場合、別料金はかかるのでしょうか?

引き続き弊社サービスをご検討賜り誠にありがとうございます。

さてご質問いただきました件ですが、別途料金をいただくことになりますが
登録の代行は可能です。(ボリュームに応じてお見積り申し上げます。)

今後とも弊社サービスをご検討賜りますよう宜しくお願い申し上げます。

--------------------------------------
 クボタシステム開発 株式会社
 インターネット サーバー ホスティング
  サービス グループ www.kubota.ne.jp
--------------------------------------
**以上、クボタよりの返信*******************************************

 

**以下、アイルよりの返信*******************************************

株式会社 アイル・テクニカルサポートです。
お問合せにご返信させていただきます。


> > > 3、管理者用のソフトが提供されるようですが、これはMLを開設・運営す
> > >   る際に、管理者側がML用の(Majordomo等で使われる)コマンドを覚え
> > >   る必要がないということでしょうか?
> > コバルトサーバのサーバ管理画面よりメーリングリストの追加や
> > その購読者の追加を行って頂くインターフェースを備えておりますが、
> > この画面は、メーリングリストの運営管理用ではございません為に、
> > お申出頂いておりますような、管理用のコマンドを不要にするもの
> > ではございません。

> > > 8、たとえば、MLによって、
> > >   ・管理者しか登録・解除できないML
> > >   ・会員が(会員専用ページから)任意に登録・解除できるML
> > >   という使い分けは実現できるでしょうか?
> > >   (そちらでこうしたモード設定を用意している場合もあるでしょうし、
> > >    こちらでプログラムを組むことが必要になる場合もあるとは思いま
> > >    すが)
> >
> > 大変恐縮ではございますが、標準でご用意致しておりますメーリング
> > リスト機能では、お申出頂いております機能を満たすことが出来ません。
> >
> > 大変お手数とは存じますが、お客様にて必要なソフトウェア等をご用意
> > 頂くことで実現可能かと存じます。
>

> 上記のお答えについてですが、これは、
>  ・MLを立ち上げ、メールアドレスを登録・削除することは管理ソフトからで
> きる。
>  ・しかし、各MLの参加に関する設定(会員なら自由に登録・解除できるとか、
> ML管理者しか登録・解除できないとか)についてはコマンドの知識が必要である。
>  ・また、その他にもmajordomo自体をカスタマイズする必要がある場合はコマン
> ド知識が必要になる。
>  という意味と考えてよいでしょうか?

上記お客様のご返信通りでございます。ML設定についてやカスタマイズに
つきましてはコマンドラインからの操作が必要となります。


> > > 4、この管理者ソフトから、たとえばMLに50個程度のメールアドレスを一
> > >   気に登録・削除したりすることはできるのでしょうか?
> >
> > お客様にて操作して頂く必要はございますが、管理画面上より、
> > メーリングリストの購読者の追加操作を行って頂くことが
> > 可能でございます。

> このお答えは、メールアドレスを1つ1つ登録・削除するのではなく、複数のメ
> ールアドレスを一気に登録・削除できるという意味と考えてよろしいでしょうか? > その場合、20個とか50個とか、一気に登録できるメールアドレスの上限があったら
> 教えてください。

メールアドレスに追加につきましては、一度に登録したいアドレスを
aa@b">a@b...,aa@b...のようにカンマ区切りにて設定頂ければ一度に複数
のアドレスを登録する事も可能でございます。お試し下さいませ。


取り急ぎご連絡いたします。
宜しく御査収ください。
-----------------------------------------------
株式会社アイル
102-0074
東京都千代田区九段南3-3-6 ニッセイ麹町ビル3階
テクニカルサポート 片山 support@i...
TEL:03-3265-8000  FAX:03-3511-7713
受付時間 月〜金(9:00〜18:00 土・日・祝 除く)
-----------------------------------------------
**以上、アイルからの返信**********************************************


nam-projectの観点からも、本日アイルという結論が出ていたようですが、上記の答えをみると、事務処理的な観点からしても、やはりアイルの方がよいようですね。

唯一心配なのは、majordomoをMLソフトに使っているアイルで、1MLに1000人以上の登録が可能かどうかという点だったのですが、先ほど、nam-logにアップするためにコンピュータのログをまとめていたら、[nam-computer:0089] で須栗さんが「FreeMLはmajordomoを使用している」ということをおっしゃっているのを発見しました。
FreeMLは人数制限ナシですから、つまりこれはmajordomoを使ったとしても人数制限ナシにできるということになりますよね。色々カスタマイズの手間は必要かもしれませんけれども。


ということで、クボタの可能性はこれ以上探らずに、アイルのcobalt Rq3コースの最終的な吟味にかかりたいと思います。

それで、さっそくですが、アイルのWEBから請求していた資料が昨日届きまして、そこには、3月15日(木曜)の14時〜17:00までのスケジュールで行なわれ、東京都千代田区のアイルのビルで無料で参加できるという、「コバルトプラン・セットアップ実習のご案内」という案内が含まれていましたので今日申し込んでおきました。
先着16名ということだったので、少々不安だったですが、先ほどOKの返事がFAXで来ましたので、無事参加できることになりました。
参加の案内には、「事前契約されなかったお客様へ」として
「コバルトサーバのWEBからのサーバ設定画面のハードコピーをご用意しておりますので、実習会にてはこちらの紙面に設定方法や内容をお書きとめいただき、ご契約完了後に設定を行なっていただくことが可能でございます」
とあります。

これを読むと、技術がわかる方に一緒に行っていただければとも思うのですが、急な話ですし、おそらく無理ですよね。。
もし一緒に行けるという方がいらしたらおっしゃってください。追加で申し込んでみますので。

また、WEBなどをチェックしてみて、案内の当日に聞いておくべき質問やチェッ
クしておくべきポイントがもしありましたら、おっしゃっていただければ幸いで
す。


以上。

 
99 投稿者: yumoto  <yumoto@h...>
Date: 2001年3月7日(水) 午後10時56分
タイトル: 提案−運営/規約 11

 
  こんにちは、湯本です。

> namでないと買えないという「一品」をたくさん作っていくことだと思います。
> nam用コモディティ開発の担当になっていただけませんか>宮地さん,湯本さん

がんばってやらせていただきます。


> 死亡による退会時は1)赤字は円で相殺してもらう,は除外してもいい気がする
> のですが。そうでないと,相続人がこれを精算しないといけませんね。
>
> namで相続や遺贈をどう扱うか考えておかないといけないですね。
> 私は,会員間でのnamの贈与は認められていると考えていますが,これについて
> 何か問題がありますか。

・会員間の贈与は問題ないと思います。
・相続人が会員でも会員でなくても、建前としては、赤字については精
算を求めたほうがいいように思います。

その場合、老齢をむかえた会員が、相続人に精算という負担をさせない
ようにと、 nam の使用を控えなければならないような状況になりがち
だとすれば、別の手段を講じたらよいと思います。(コミュニティから
の感謝のきもちをこめて、精算不要な赤字枠を贈与する、というような
こと。)


> 上限固定ですね。私が出した上限可変の案についてはどう思われますか。

なるべくなら、上限可変のほうが望ましいと思います。コミュニティへ
の貢献、コミュニティからの感謝が、赤字の上限値として自動的に反映
されることは、とても受け入れやすい、すなおなものだと思います。
(そして、死亡のばあいの赤字精算も求めないほうが、この趣旨には整
合性があると思います。)

しかし、空取り引きなどの不正な手段による攻撃を避けられないのであ
れば、システムの安定をここでは確保したほうがいいと思います。

そして、貢献、感謝、については、コミュニティ全体としての一本化し
た意思表示に代えて、メンバーひとりひとりの主体的判断と行動を個別
に引き出すことで、具体化すればいいと思います。


> つまり,namを貨幣とする会員個人間の信用(債券・債務関係)を
> もう一度入れるという提案ですね。赤字の上限がないので,自己責
> 任で引換券や借用書をかなりの額発行できるというメリットが商売
> 側にある,というのが提案の理由ですか。

nam の赤字上限を変動できず、固定してしまうことで、コミュニティ全
体としての感謝を表現することができにくくなるので、その代わりとし
て、信用、投資、というひとりひとりの主体的な判断による行為を持込
んだらどうかと考えたわけです。


> 引換券は将来商品を提供する約束,借用書は将来namを返済する約
> 束ですね。引換券や借用書を参加者が買うことを一種の「先渡契約」
> あるいは「投資」とみなすということになると思いますが,これで
> いいのでしょうか。

コミュニティ全体がリスクを引き受ける赤字の代わりに、個人ひとりひ
とりがリスクを引き受けるのが、ここでの信用、投資ということだと思
います。

無利子が大前提なので、信用、投資そのものからは利益をあげられず、
リスクだけを負担することになるので、感謝、支援、勇気づけ以外の動
機は入り込めないと思います。株の値上がりのようなこともないわけで
すから。

詐欺師、あるいは、商売人として元気過ぎる人の、利己的な動機に悪用
される心配もあるかもしれませんが、NAM の趣旨に沿った事業やプロジ
ェクトへの直接金融の手段としても、引換券、借用書の有効性はたかい
と思います。


> 商店は円とnamを混合で値段を付けるでしょうが,この方式だと円
> とnamの関係がどうなるのかもう少し説明していただけると助かり
> ます。

(1) nam を使う引換券や借用書は、 nam 100%しかみとめない。
(2) 引換券は、事業キャパシティの30〜50%までの発行しかみとめない。
(3) 引換券は、他の会員に対し、有償、無償の譲渡ができる。
(4) 引換券や借用書の発行はすべて、GETS システムの上で、通常の
nam 取り引きとは別枠でおこない、取り引きの記録が公開される。

このようなルールをつくったらいいと思います。(4) の公開の部分は、
きつすぎるかもしれません。

以上です。

それではまた
yumoto hirokazu

 
100 投稿者: go  <afake908@o...>
Date: 2001年3月8日(木) 午前8時56分
タイトル: [nam-project] 提案−運営/規約 13

 
  宮地です。

「飯が食えない」領域の商品化とは、少し話がずれるんですが、namファンドの活
用法を思いついたので提案します。

namファンドによる奨学金的な制度は考えられないでしょうか?

芸術、理論的研究、コンピュータ・プログラム、音楽、文学といった活動領域で、通
常の市場では商品価値を持ち得ない「作品」に対して、NAMが一定の評価を下し、
その活動を支援する、といった狙いがあるんですが…。

その制度の概略はこうです。
。映に一度か二度、奨学金被受給者を公募する。
対象領域は、芸術、理論的研究、音楽、文学など。
奨学金需給希望者は、自分の研究内容とか作品概要とかいままでの「作品」とか
を、審査委員会に提出し、審査を受ける。
た該紺儖会で、奨学金受給に適していると判断された対象者に、namファンドが
規定の金額を貸し付ける。そのとき受給契約として、返済などについての項目を設け
ておく。
ゼ給者は、契約期間の間に、研究や活動の経過報告を、審査委員会に報告する義務
を負う。もし、その段階で、不適格と判断された場合は、受給を停止する。

細かく考えていかねばならないところは多いんでしょうが、おおよそのところは理解
していただけたでしょうか?

そういった研究や活動のなかで生み出された「作品」が、nam流通圏での「商品」
となりえるような仕組みも、同時に考えておかねばならないでしょう。

 
101 投稿者: go  <afake908@o...>
Date: 2001年3月8日(木) 午前10時23分
タイトル: Re: [nam-project] 提案−運営/規約 11

 
  宮地です。

> 「「円」では商品化しにくい、つまり飯が食えない芸術や理論・知識・技術を、n

> mにおいて重点的に商品化していく。」という方向性には賛成です。問題はその具

> 化ですね。それとともに,パンとか米とか,生活必需品も入れないといけません
ね。
> いざ会員に声をかければ,意外にこういうものを提供できる人もいるのかもしれま

> ん。

パンとか米といった具体的な「飯」は必要だと思います。パン屋が二名いますのでパ
ンはとりあえずOKだろうと思います(他にもいらっしゃるかもしれませんし)。
で、米なんですが、農業/消費者運動の参加者の方々の間では、namへの商品
(米、その他穀物や野菜など)の提供についてはどんなふうな意見が出てるんでしょ
うか?>湯本さん。

で、今回は、提出された商品を購入するときのnam:円の比率について考えたいと
思います。

LETSの場合、基本的には、商品・サービス提供/購入の際のnam:国民通貨の
比率は、当事者間の話し合いで決めるんだと理解しています。基準はもちろんあるけ
れど、変動する。相対取り引きの分散的価格設定なわけですよね。

namの場合はどうすればいいのでしょうか?

あくまでLETS一般と同じような方法で決めるのか。

ひとつの提案ですが、namの循環性を高めるには、namの使用可能比率を高める
という方法もあると思います。つまりnam:円を50:50くらいの比率に決めて
おくわけです。400円のパンを買う場合、200namと200円という支払いに
なりますね。商品・サービス提供側にとっては、仕入れ業者などに支払いできる
「円」の収入が減るのは痛いですが、それは円流通圏でがんばって取り戻すとして、
namの高比率受容は、商品・サービス提供者のNAM=namに対するコミットメ
ントの強さを表すことになるとも思います。

そうすることでnamの貨幣価値が高まり、循環性もあがると思うのですが…。

 
102 投稿者: krtn  <krtn@b...>
Date: 2001年3月8日(木) 午前10時57分
タイトル: 提案−運営/規約 14

 
  柄谷行人です。
宮地さんの意見は、前に、岡崎さんから聞いた案と似ています。岡崎さんは、それを
namではなく、円で考えていたけど。また、この奨学金の審査員は、権威あるものと
するため、(NAM会員でなくても)トップの人間を集める。
もちろん、これは芸術に限らず、どんな学問についてもいえると思う。かりに、奨学
金あるいは賞金がわずかでも、結果として売れる(評価される)ことになるでしょ
う。しかし、特に、批評の乏しい、芸術には大きく影響すると思います。
岡崎さん、もっと説明してください。

》-----Original Message-----
》From: go [mailto:afake908@o...]
》Sent: Wednesday, March 07, 2001 6:56 PM
》To: nam-project@e...
》Subject: [nam-project] 提案−運営/規約 13


》宮地です。

》「飯が食えない」領域の商品化とは、少し話がずれるんですが、namファンドの
》活
》用法を思いついたので提案します。

》namファンドによる奨学金的な制度は考えられないでしょうか?

》芸術、理論的研究、コンピュータ・プログラム、音楽、文学といった活動領域で、
》通
》常の市場では商品価値を持ち得ない「作品」に対して、NAMが一定の評価を下し
》、
》その活動を支援する、といった狙いがあるんですが…。

》その制度の概略はこうです。
》。映に一度か二度、奨学金被受給者を公募する。
》対象領域は、芸術、理論的研究、音楽、文学など。
》奨学金需給希望者は、自分の研究内容とか作品概要とかいままでの「作品」とか
》を、審査委員会に提出し、審査を受ける。
》た該紺儖会で、奨学金受給に適していると判断された対象者に、namファンド
》が
》規定の金額を貸し付ける。そのとき受給契約として、返済などについての項目を設
》け
》ておく。
》ゼ給者は、契約期間の間に、研究や活動の経過報告を、審査委員会に報告する義
》務
》を負う。もし、その段階で、不適格と判断された場合は、受給を停止する。

》細かく考えていかねばならないところは多いんでしょうが、おおよそのところは理
》解
》していただけたでしょうか?

》そういった研究や活動のなかで生み出された「作品」が、nam流通圏での「商品
》」
》となりえるような仕組みも、同時に考えておかねばならないでしょう。




》Help URL   : http://help.egroups.co.jp/
》Group URL  : http://www.egroups.co.jp/group/nam-project/
》Group Owner: mailto:nam-project-owner@e...


 
103 投稿者: yumoto  <yumoto@h...>
Date: 2001年3月8日(木) 午後2時04分
タイトル: 提案−運営/規約 15

 
  宮地さんの、運営/規約 13 を読んで、わたしの考えを修正しました。

借用書のアイディアは引き下げ、かわりの案を考えました。
借用書という、一対一の債務関係をむき出しにする形式は、よくない。

それにかわる案は、ドイツの銀行でやっているというもので、銀行が間
に入って、AからBへの貸しつけをするやりかたです。

nam のばあい、 nam ファンドが間に立って、AからBへの貸しつけを
する。その際、Aは、貸付先をBに指定したうえで、 nam をファンド
にあずける。ファンドは、Bに対し、Bへの貸しつけ希望があるが、う
けるかどうか打診する。受けると返事をすれば、貸しつけは成立する。
Aの名前は匿名にし、Bには知らせない。Bは、ファンドに対し返済義
務を負う。返済不履行のリスクは、Aが負う。

一応、これを、 nam ファンド応援口座、とよんだらどうでしょう。
援助口座、というのは、語呂が悪いですから。

( nam用コモディティ開発については、鋭意検討中です。)

それではまた
yumoto hirokazu

 
104 投稿者: shogowatanabe@n...
Date: 2001年3月8日(木) 午後3時38分
タイトル: Re: [nam-project] $BDs0F!]5;=Q(J/ $B4IM}(J22

 
  渡辺です。

>
>ということで、クボタの可能性はこれ以上探らずに、アイルのcobalt Rq3コースの最終的な吟味にかかりたいと思います。
>

ベストだと思います。よろしくお願いします。

>それで、さっそくですが、アイルのWEBから請求していた資料が昨日届きまして、そこには、3月15日(木曜)の14時〜17:00までのスケジュールで行なわれ、東京都千代田区のアイルのビルで無料で参加できるという、「コバルトプラン・セットアップ実習のご案内」という案内が含まれていましたので今日申し込んでおきました。
>先着16名ということだったので、少々不安だったですが、先ほどOKの返事がFAXで来ましたので、無事参加できることになりました。
>参加の案内には、「事前契約されなかったお客様へ」として
>「コバルトサーバのWEBからのサーバ設定画面のハードコピーをご用意しておりますので、実習会にてはこちらの紙面に設定方法や内容をお書きとめいただき、ご契約完了後に設定を行なっていただくことが可能でございます」
>とあります。
>
>これを読むと、技術がわかる方に一緒に行っていただければとも思うのですが、急な話ですし、おそらく無理ですよね。。
>もし一緒に行けるという方がいらしたらおっしゃってください。追加で申し込んでみますので。
>

「WEBからのサーバ設定画面のハードコピー」はHPからみました。

>また、WEBなどをチェックしてみて、案内の当日に聞いておくべき質問やチェッ
>クしておくべきポイントがもしありましたら、おっしゃっていただければ幸いで
>す。
>
>

以下の2点は私からメールでアイルに問い合わせてみます。
2)は必要にないかもしれません。

1.「Development Environment」
C/C++コンパイラ、gdbデバッガー、X11ライブラリ、PostgreSQL DBMSなどの標準開発ツール
とHPには書いてありましたが、「Development Environment」というのはどういうものか知っておきたいです。

2.実際に必要になるかわかりませんが、WindowsクライアントからLinuxサーバーのPostgreSQLを操作するためにはODBCかフリウェアーなどが必要です。アイルで動作するか知っておきたいです。

ドライバ「PostgreSQL ODBC Driver:日本語版」 http://www.interwiz.koganei.tokyo.jp/
PostStorageからアクセス、エクセルへのデータ交換が可能です。

フリーウェア「Interactive PostgreSQL」閉鎖中ですが、もっています。
PostStorageからアクセス、エクセルへ、アクセス、エクセルからPostStorageへのデータ交換が可能です。

 
105 投稿者: shogowatanabe@n...
Date: 2001年3月8日(木) 午後5時31分
タイトル: Re: [nam-project] $BDs0F!]5;=Q(J/ $B4IM}(J23

 
  こんにちは、渡辺です。

>
>さて、一番の懸念事項が、会員DBとの連携ですが、
>ちょっと様子がいまいちわからない。
>どうしましょうか。GETSと連携する形で設計しなおすのでしょうか。
>

3月末納品、しかし忙しくて会員DBとの連携ができない場合のことを考えて、
その代理案をサーバー担当から思いつきで言わせていただきます。
連携を考えておられる方、ごめんなさい。

ユーザーはNAM会員だけです。
ですから、システムが正常に動作するようにするためには、
1.NAM会員と協力団体に限定する
2.NAM会員の入力ミスをなくす
ことに力点を置く必要があります。
(システムが動作しない原因はむしろ後者の方にあるというレポートがあります。)

1.NAM会員と協力団体に限定する件について

1.フロントページの前に認証機能をつける。
工数的には大丈夫でしょうが、境界は外部にありますから機能するか心配です。

2.メンバー登録を管理者に一任する。
現在FreeMLでは事務局の方に一任していただいておりますが、おなじようにGETのe-mailアドレスとpassword入力を管理者が担当する。
会員マスター入力です。
NAM会員のe-mailアドレスの情報をいただける場合、私が「テストと配置」期間のラスト1週間に入力して後にpasswordを個々人に配布します。
問題は更新ですが、現在のGETSのメンバー登録を別画面にもっておくか、クライアント・サーバーでODBC接続が考えられる方法です。


2.NAM会員の入力ミスをなくす件について

GETSをNAMで改造する場合、赤字の上限問題をどうするかという問題があります。
技術的にはif文を書いて、入力チェックしたらいいと思われますので鈴木さんなら楽勝でしょう。
米をかって時間を入力したら「未来です」と言われました。

「プログラムGETSをサーバー上に実装し,NAMの全会員,各関心系,地域系,階層系,
協力団体などの口座を設定」と西部さんは言っています。
GETをNAM仕様にする場合、「各関心系,地域系,階層系,協力団体などの口座」
をメンバー登録として登録する場合は問題ない。
しかし、個人と系との関係を1対多にする必要がある場合は、やはり会員DBとの連携か
GETのメンバーテーブルの拡張が必要です。

 
106 投稿者: go  <afake908@o...>
Date: 2001年3月8日(木) 午後7時23分
タイトル: Re: [nam-project] 提案−運営/規約8

 
  宮地です。

穂積さんの運営/規約についての提案へのレス、です。

> 思いつきなんですが、たとえば、コンピュータの使い方MLみたい
> なので、そこに質問したら知ってるひとが丁寧に答えてくれるみた
> いなのは、商品にならないのかな。
>
> いつも思うんですが、コンピュータの教材というかHOWTOもの
> って、たいてい「帯に短し・・・」で、そのくせちょっと専門的な
> MLなんかのぞくと、そんなのも知らねえのか、という輩が多くて、
> 嫌になるんですよね。

こういったサービスを、商品化していくほうがいいと思います。
NAMの会議が、MLを中心としたサイバー空間での活動であり、namがネット上
の通貨であるのだから、NAMの会員である限りは、できるだけコンピュータに強く
なっていく必要があると思います。(プログラムできるまでとは言いませんが…)そ
の意味でも、こういったサービスの商品化は必要だと思います。

あと語学に関してのサービスも商品化できるんじゃないでしょうか?
先日柄谷さんがnam−laborで情報提供されたアメリカのHPに行ってみたん
ですが、あまりよく分かりませんでした、というより、ほとんどわかりませんでし
た。ぼくのように、コンピュータにも語学にも弱い人間には、そういった分野での
サービスを商品化して欲しい!という希望を込めましての、提案です。

 


 

プリンタ出力用画面 友達に伝える


投稿された内容の著作権はコメントの投稿者に帰属します。
Qアーカイブス