« 2008年2月 | トップページ | 2008年4月 »

2008年3月29日 (土)

建設業の現状 − 談合の話じゃなかったりする

興味深い記事なのですけど。

問 最初に談合組織が解体した民間建築では1990年代後半以降、工事単価は低下し続けています。公共工事でも、受注のために予定価格を大幅に下回る金額で落札する業者の存在が問題になりました。過当競争にある建設業界ではダンピングが起きやすい。

答 単価の下落もそうだが、私らにとってきついのは工期。液晶工場などは典型だが、グローバル競争に勝つために、一日でも早う造れと。発注者から見れば、工事単価と工期がすべて。ゼネコンにしてみたら売り上げのために受注がほしい。2つの要素が絡み合うたわけや。そのしわ寄せが下請けに来とる。

談合消滅後の建設業界で何が起きているか (ニュースを斬る) NBonline(日経ビジネス オンライン)

”民間建築で談合”って、あまり聞きなれないですね。民間建築で談合摘発っていうのは、耳にした覚えがないですねえ。談合が問題にされるのは、民間工事ではなくて、公共工事ではないのでしょうか。民間工事で談合って、あるんですかね。価格カルテルってことになるのでしょうか。

”民間建築では1990年代後半以降、工事単価は低下し続けてい”るのは、公共工事での談合とは、直接には関係ないように思いますけどね。民間工事と公共工事では、話が違うでしょうから。民間工事に関しては、主としてバブル崩壊後の不景気とデフレのせいではないかと。

問 談合組織が消滅したことで、ダンピングが激しくなったと。

答 違う、勘違いせんといて。談合がなくなったからダンピングが起きたわけではないよ。ただ、発注者の力が強くなりすぎているのは確か。ゼネコンがお施主さんに何も言わへんねん。言うと嫌われるから。仕事欲しさに安値で受注して、そのしわ寄せは現場の職人や。

インタビューアーは、公共工事の談合と、その業界への影響について聞きたかったのでしょうけど。話はもっぱら、民間工事での価格下落と、工期の短期化の話になっていますね。談合の話は、最初の問答だけで、終わっているようです。

| | コメント (0) | トラックバック (0)

機会の平等と結果の平等

私も、”機会の平等”、”結果の平等”という言葉の意味について、いろいろと疑問に思っていまして。続きの気になる記事です。

格差に関して,多くの論者が用いる整理は「結果の平等と機会の平等」という二分法です.例えば所得に関して,実際の実現所得が小さい(大きい)ことが結果の平等(不平等)なのに対し,より多くの所得を稼ぐ機会が誰に対しても開かれている(いない)ならば機会の平等(不平等)というわけです.

機会の平等ってそんな簡単な話じゃないんです (WIRED VISION)

”機会の平等”を確率的に公平なゲームのことであるとするならば、ゲームの参加者全員の利得の期待値は同じになるはずでして。この場合、ゲームを十分な回数繰り返せば、ゲームによって得られる利得は参加者全員が同じとなるのですよね。そうしますと、機会が平等であるというのは、すなわち結果が平等となることになるわけでして、両者を区別するものは何なのか、そもそも区別する必要はあるのか、という疑問が出てきます。

一対一の賭,じゃんけんで負けたら,相手に100円払うというゲームについて考えます.じゃんけんそのものは公正で,支払いも約束通り履行されることがわかっているとしましょう.つまりは参加者双方にとって平等なルールで行われる賭というわけです.

【略】

仮にAさんは100円しか持っていないのに対し,Bさんは300円もっているとしましょう.この時,Aさんは始めの1回で負けてしまえば破産し,これ以上ゲームにとどまることは出来ません......全財産である100円を取られてお終いです.1回勝ってはじめてAさんとBさんは五分の勝負になるわけですから,Aさんの勝利確率は1/4,Bさんのそれは3/4ということになります.ちなみに,このゲームでの勝利確率の比は当初の手持ち金額の比そのものになります.ひとつひとつのゲームに不平等がない一方で,ゲームが繰り返されたときにその勝敗を決めるのは初期条件である手持ち現金額なのです.

さて,このゲームでは機会の平等は保証されているのでしょうか? それともされていないのでしょうか?

何をもって”勝ち”、”負け”とするのかが、あまりはっきりと書かれていませんが。

おそらくこれは、ゲームを繰り返し、 A, B いずれかの所持金がゼロになった時点でゲームが終了し、所持金ゼロとなった方が”負け”、ならなかった方が”勝ち”と定義するのだと思います。

Aさんについて、このゲームを考えてみますと、以下のようになります。

回数 事象 所持金
1回目 勝ち 200円
   負け ゼロ
2回目 勝ち ⇒ 勝ち 300円
   勝ち ⇒ 負け 100円

Bさんについて、このゲームを考えてみますと、以下のようになります。

回数 事象 所持金
1回目 勝ち 400円
   負け 200円
2回目 負け ⇒ 勝ち 300円
   負け ⇒ 負け 100円

1回目でAさんが勝ち、Bさんが負けると、両者の条件が同じになります。つまり、所持金が同額となります。以降のゲームで、Aさんが勝つ確率は 1/2 であるとしますと、ゲーム全体でAさんが勝つ確率は、 1/2 ・ 1/2 = 1/4 である、ということなのでしょうね。そうしますと、Bさんが勝つ確率は、 1 - 1/4 = 3/4 です。

| | コメント (0) | トラックバック (0)

2008年3月28日 (金)

教える側のインセンティブが問題

教育というのは、手間・時間と、忍耐が必要な仕事だと思います。

SEマネジャが入社2・3年生までの若手SEに何かやらせる時は,段取りを教え,手取り足取りして正しいやり方を教えることが重要だ。単に「あれをやっておけ,これをやっておけ」などと言うたぐいの,指示だけするのは厳禁である。

若いSEには段取りを教え,手取り足取り指導せよ 馬場史郎のITプロに贈る"今日の一言" (ITpro)

口で言えば30分で済むことでも、教えないと本人が気づくまで2・3日かかることもあります。でも自ら気づき、学んだことでないと身につきません。教えてもらおうと思うのが間違い。言葉や頭で、分かった気になるのが一番ダメです。教えずに耐える方も大変ですわ

教えるためには、教えてはいかん(INSIGHT NOW!)

学生はできるだけ自分自身で問題を解く練習をしなければならない。しかしもしもここで彼が充分助けて貰わないですてておかれるならば、殆ど進歩しないであろうし、又教師が助けをしすぎるならば学生は何も得るところがないであろう。教師は手を貸さなければならないが、それは多すぎても少なすぎてもいけない。学生はいつも自分で 適当な仕事の分け前 を果たさなければならない。

G.ポリア 著, 柿内賢信 訳, 『いかにして問題をとくか』1, 丸善, 1954

ナレッジ・マネジメントや、情報共有の案件での、定番の問題として、いかにして情報を出すインセンティブを与えるか、というのがあります。職場での教育に関しても、同じ問題があると思います。教える側のインセンティブの問題というのが。

教える側としては、もともと、教育を行なうインセンティブというのは、薄いです。”長い目でみれば”、つまり、超長期的には、大きなリターンが期待できるかもしれませんが。この場合、リターンは計れるようなものでもありませんので、現在価値 − 100年後の100万円と明日の1万円 − という問題は別にしましても。超長期の投資を、何の保証も担保もなく、リターンが得られる見込みもなく行なう者は稀であろうと思うわけです。

伝統的な徒弟制度では、”弟子”は”師”に絶対の忠誠を近い、懸命に奉仕を行なうことで、自分が必ずやリターンをもたらす人間であることをアピールしている、という見方もできます。自分は長期にわたって信用できる人間であるから、ぜひ投資をお願いします、というわけです。

こうした徒弟制度は、古臭いもの、今の時代にそぐわないものとして、長らく否定される傾向にありました。しかし、その代わりに、教える側、教わる側の両者でインセンティブのバランスをとる方法があるかといえば、ないわけです。結局、各自が自己責任で学ぶべし、で終わってしまった感があります。

これでは、技術の伝承はできず、また、組織として知識や技術を蓄積していくこともできない、ということで、最近になって色々と模索を始めているわけなのですが。

アメリカから、コーチングとかいう概念が日本に輸入されていますが、これなどは、”師の心得”のごときもののように思えるわけでして、現代に徒弟制度を蘇らせようとする試みにも思えますね。ソフトウエア開発の世界では、もっと直接的に、”徒弟制度に回帰すべし”と主張される方2もいらっしゃるようです。

”徒弟制度”なのか”自己責任”なのか、別の方法があるのか、暗中模索は続きそうですね。


1.

いかにして問題をとくかBookいかにして問題をとくか

著者:G. ポリア
販売元:丸善
Amazon.co.jpで詳細を確認する

2.

ソフトウェア職人気質―人を育て、システム開発を成功へと導くための重要キーワード (Professional Computing Series)Bookソフトウェア職人気質―人を育て、システム開発を成功へと導くための重要キーワード (Professional Computing Series)

著者:ピート マクブリーン
販売元:ピアソンエデュケーション
Amazon.co.jpで詳細を確認する

| | コメント (0) | トラックバック (0)

2008年3月26日 (水)

成功を重ねるほどハードルは高くなる

困ります、ファインマンさん (岩波現代文庫)Book困ります、ファインマンさん (岩波現代文庫)

著者:R.P. ファインマン
販売元:岩波書店
Amazon.co.jpで詳細を確認する

ファインマン氏のスペース・シャトル チャレンジャー号爆発事故調査の報告書について、以前とりあげたのですが。

リチャード・ファインマンのエンジニアリング考

事故調査のいきさつは、『困ります、ファインマンさん』(大貫昌子 訳, 岩波現代文庫, 2001)で、日本語訳が読めます。例の”確率10万分の1”についても、ずいぶんと憤慨されている様子が描かれています。

「HPHTPパイプが破裂する確率は一〇のマイナス七乗」などと書いてあるが、そんなことが簡単に計算できるはずがあるものか! 一千万に一つなどという確率を概算するのは、ほとんど不可能に近いはずだ。エンジンの一つ 一つの部分につけた確率の数字は、あとで全部を足せば一〇万に一の確率になるように、はじめから細工してあるのは見えすいていた。

同書 p.264

この一編の”あとがき”の部分で、ファインマン氏が後に振り返っての感想がありまして。

NASAでなければできない計画があるといって議会を説得し、予算を獲得しなくてはならないし、そのためには少し大風呂敷を広げる必要が出てくる(少なくとも今度のシャトルの場合は、それが確かに必要だったようだ)。

同書 p.312

開発の初期には、大いなるチャレンジであったものが、成功を重ねるうちにいつしか当たり前のこととなり、目新しさに欠けるがゆえに、”売り込み”に苦慮するようになってしまうわけですね。その結果、幹部は外部に対し誇張した説明を行なうようになり、それに反する現場の技師の意見は省みられなくなる、”知らなかった””聞いていない”ということになる、という考察がなされています。

どんな仕事でも、成功を重ねるほどに、その仕事に求められる要求水準というのは、とめどなく上がっていくものですが。成功が当たり前とみなされるようになったとき、人々が考える水準と現実に現場の人間が知る水準との間には、大きな乖離が存在するのかもしれませんね。そう、およそ300倍以上もの。

「やっぱり技師連と管理側の間にはだいぶギャップがあるようですな。三〇〇倍以上のギャップがね。」

同書 p.263

こうしたことは、ある程度成熟した組織では、どこにでもみられる光景なのでしょう。

だから、僕はしばしば、高潔さと宮仕えとはどんな関係にあるのだろう? と考えずにはいられないのだ。

同書 p.263

難しいですね。企業に勤める身としては複雑なところです。

| | コメント (0) | トラックバック (0)

2008年3月24日 (月)

順序関係列挙と事前条件

さらに続きです。

4変数の順序関係はいくつあるか?

順序関係を列挙する

順序関係の列挙に、事前条件の加味を加えます。以下のように、事前条件を満たさないものを、列挙から除きます。

irb(main):002:0> i = 0; apply_cond(gen_norder([:x1, :x2, :x3, :x4]), [:x1, :x2,:x3, :x4], ['x1<x2', 'x2<x3', 'x3<x4']).each {|v| print("#{i += 1}:"); p v }; nil
1:[:x1, :x2, :x3, :x4]
=> nil

apply_cond メソッドは、第1引数に順序関係の配列、第2引数に結果に必ず含まれるべき変数の配列、第3引数に事前条件の配列を指定して呼び出します。

def apply_cond(src_a, req_a, cond_a)
  res_a = []
  src_a.each do |exp|
    if required_exist?(exp, req_a) &&
      cond?(exp, cond_a)
      res_a.push(exp)
    end
  end
  res_a
end

required_exist? メソッドは、順序関係 src_exp の中に、配列 req_a のシンボルがすべて存在するかをテストします。

def required_exist?(src_exp, req_a)
  target_a = src_exp.flatten
  req_a.each do |v|
    if !target_a.include?(v)
      return false
    end
  end
  true
end

cond? メソッドは、ちょっと強引ですが。まず、順序関係 src_exp の各変数に、配列の添字 + 1 を、 eval で代入します。その後、与えられた条件の配列 cond_a を順に eval します。

def cond?(src_exp, cond_a)
  init_exp = []
  src_exp.each_index do |i|
    v = src_exp[i]
    if v.instance_of?(Array)
      init_exp.push("#{v.join('=')}=#{i+1}")
    else
      init_exp.push("#{v}=#{i+1}")
    end
  end
  eval(init_exp.join(';'))
  cond_a.each do |cond|
    begin
      if !eval(cond)
        return false
      end
    rescue NameError
    end
  end
  true
end

事前条件 x1 < x3, x2 < x4 を与えてみます。

irb(main):003:0> i = 0; apply_cond(gen_norder([:x1, :x2, :x3, :x4]), [], ['x1<x3', 'x2<x4']).each {|v| print("#{i += 1}:"); p v }; nil
1:[:x1, :x2, :x3, :x4]
2:[:x1, :x2, :x4, :x3]
3:[:x1, :x3, :x2, :x4]
4:[:x2, :x1, :x3, :x4]
5:[:x2, :x1, :x4, :x3]
6:[:x2, :x4, :x1, :x3]
7:[[:x1, :x2], :x3, :x4]
8:[[:x1, :x2], :x4, :x3]

...

44:[:x1, :x2]
45:[:x2, :x1]
46:[[:x1, :x2]]
47:[:x4]
48:[:x3]
49:[:x2]
50:[:x1]
51:[]
=> nil

大体、条件をつけない場合の3分の1くらいでしたね。

| | コメント (0) | トラックバック (0)

2008年3月23日 (日)

エンジニア「超」促成栽培

@IT の記事です。

あるとき、某メーカーが「社内向けの技術研修を実施したい」というので、中根さんは友人を伴って詳細を聞きにいった。その際、応対したのはメーカーの管理職者だったが、その要望は 「仕様が決められて、プロトコル設計ができて、信号をオシロスコープで見て理解ができて、ソフトウェアの設計ができて、ハードウェアも作れる人材を育てたいんです」 というとてつもないものだった...。

 中根さんたちはその時点で開いた口がふさがらないという感じだったが、一応どれぐらい時間をかけてそうした人材を育成しようと考えているのか尋ねてみた。すると今度は、 「現場にいる人間はそんなに時間が取れないので、できれば3・4日で」 という答えが返ってきたそうだ。

技術伝承の現状とモノづくり大国ニッポンの明日 (@IT)

知識だけなら2・3年あれば、何とか詰め込めるでしょうけど。技術となると、やはり 10年 は必要でしょうね。もちろん、専門分野はある程度狭める必要があり、ソフトウエアでもハードウエアでも、何でもできる技術者なんてのは、無理でしょう。ソフトウエア/ハードウエアというくくりでも大きすぎます。

かっては、職人を育てるには、 15歳以上ではもう遅く、7・8歳から仕込まないと使い物にならない、などといわれていたわけでして。今でも伝統工芸の世界では、中学卒の15歳から修行を始めるようですけども。人に技術を身につけさせるには、とてつもない時間がかかるということは、そうした世界では常識でしょう。

技術者の場合、職人ほどには手技は必要なく、どちらかといえば知識を使うのが主になりますから、職人と同じくらい長期にわたる修行が必要、というわけではないとは思います。とはいえ、1年やそこらで”促成栽培”できるようなものでもないでしょう。にもかかわらず、こうした”促成栽培”を本気で考える人間が後を絶たないですね。

”人手不足”になるのは、技術の変化が早すぎて、それに人の育成が全く追いついていないからですかね。ですから、技術者の”促成栽培”を夢想する人間は絶えることはないのでしょう。

技術者が不足するのには、社会構造の変化もあります。”脱工業化社会”なんて言われて久しいですけど。日本の産業構造が2次産業から3次産業へとシフトしていっているのは確かですから。”理科離れ”なんてのは、もっぱら”工業離れ”であって、若い人たちは、単によりよい仕事を求めているだけではないかと思うんですよね。技術者というのは、若い人たちにとって、”よりよい仕事”ではないのでしょう。古臭いイメージは否定できませんからね。

「日本人は、突飛(とっぴ)なものとか、すごく個性の強いものを生み出すのは苦手です。イタリアの車や家具のデザインなどを見ると、あれを日本人が思い付くのは難しいなと思います。しかし、まじめだから地味な仕事をコツコツやるのには向いています。それはアジア全体を見渡しても、日本人が一番だと思います。粘り強く、しつこく仕事ができる。知恵を出すこともできる。そうしたことを考え合わせると、日本はまだまだ組み込みの世界で強みを発揮し続けることができるのではないかと思いますね」(中根氏)。

日本は個性的な国であるし、日本人は個性的な発想をすると思いますけど。日本人には日本人の発想というのがあって、イタリア人と同じ発想は、当然しないでしょう。イタリア人と同じ発想をするのなら、それはイタリア人のまねであって、個性的とはいわないでしょうし。

今や日本も先進国になってしまいましたから、「まじめだから地味な仕事をコツコツやる」だけでは、難しいかな、と思います。今の日本人よりは、途上国の人間のほうが、そうした仕事に向いているでしょう。そうした特性は、人種・民族によるのではなく、社会の発展段階や産業構造によるのではないかと思います。

「そして」と中根さんはさらに付け加えた。 「日本人には農耕民族としてのDNAがあるから」 と。日本人は伝統的に米を作って生きてきた。米は1人では作れない。チームを組んでともに助け合い、それで長い工程を乗り切って確かな収穫を得る。中根さんによれば、ある一定のレベルのものを組織的に作るということに、これほど向いた国民はないのだそうだ。モノづくりができる、それもいいものが作れる人種や国民はほかにもあるが、個人主義やスタンドプレーに走りがちで、自らを押し殺して組織を優先させるという考え方が根付かないという。

「伝統的に米を作って生きてきた」のは、日本人に限らず、アジア諸国なら、だいたいはそうではないかと。ついでに申せば、日本人も一万年以上前、大陸から農耕が伝わるまでは、”狩猟採取民族”だったわけですが。また、ヨーロッパであっても、文明の基礎には農耕があるわけでして。どんな文明であっても、農耕は発展段階として存在すると思いますけどね。

| | コメント (0) | トラックバック (0)

2008年3月22日 (土)

順序関係を列挙する

先日のエントリ 4変数の順序関係はいくつあるか? の続きです。

順序関係を列挙するプログラムを、Ruby で作成してみます。

順列と組合せ

教科書のタイトルみたいですが。これが基本操作になりますので、初めに作成します。

順列を作るメソッド permutate を定義します。このメソッドは、配列 src_a と整数 rib_i を受け取って、順列の配列を戻します。これは、src_a から rib_i 個をとる順列を作ります。順に要素をひとつ取得し、取得した要素を除いた配列からまた取得、とすればよろしいかと思います。

def permutate_it(src_a, dst_a, rib_i, res_a)
  if rib_i == 0 || src_a.size == 0
    res_a.push dst_a
  else
    src_a.each do |src|
      permutate_it(
      src_a - [src], dst_a + [src], rib_i - 1, res_a)
    end
  end
  res_a.size
end

def permutate(src_a, rib_i)
  res_a = []
  permutate_it(src_a, [], rib_i, res_a)
  res_a
end

以下のように実行します。

irb(main):007:0> permutate([:x1, :x2, :x3], 2)
=> [[:x1, :x2], [:x1, :x3], [:x2, :x1], [:x2, :x3], [:x3, :x1], [:x3, :x2]]
irb(main):008:0> permutate([:x1, :x2, :x3], 2).size
=> 6

組合せを作るメソッド combine を定義します。順列メソッドとほぼ同じですが、組合せの場合、取得した要素よりも前の位置にある要素からは取得しません。常に次以降の要素から取ります。

def combine_it(src_a, dst_a, rib_i, res_a)
  if src_a.size < rib_i
    # nothing.
  elsif rib_i == 0 || src_a.size == 0
    res_a.push dst_a
  else
    src_a.each_index do |i|
      combine_it(
      src_a[i + 1, src_a.size - i - 1],
      dst_a + [src_a[i]], rib_i - 1, res_a)
    end
  end
  res_a.size
end

def combine(src_a, rib_i)
  res_a = []
  combine_it(src_a, [], rib_i, res_a)
  res_a
end

以下のように実行します。

irb(main):009:0> combine([:x1, :x2, :x3], 2)
=> [[:x1, :x2], [:x1, :x3], [:x2, :x3]]
irb(main):010:0> combine([:x1, :x2, :x3], 2).size
=> 3

不等号、等号、不存在

それぞれのメソッドを定義します。不等号の場合 case_inequal は、単に順列を作成するだけです。等号の場合は case_equal は、2個以上の組合せをまず作成し、元の配列からその要素を除き、1要素として追加した後、不等号の場合を適用します。不存在の場合 case_exist は、1個以上の組合せを作成し、元の配列から除いた後、不等号の場合、等号の場合をそれぞれ適用し、足し合わせます。

def case_inequal(src_a)
  permutate(src_a, src_a.size)
end

def case_equal(src_a)
  res_a = []
  (2 .. src_a.size).each do |r|
    combine(src_a, r).each do |c|
      p_a = [c] + src_a - c
      res_a += case_inequal(p_a)
    end
  end
  res_a
end

def case_exist(src_a)
  res_a = []
  (1 .. src_a.size).each do |r|
    combine(src_a, r).each do |c|
      p_a = src_a - c
      res_a += case_inequal(p_a)
      res_a += case_equal(p_a)
    end
  end
  res_a
end

すべてを列挙

等号、不等号、不存在の各メソッドを順に適用し、足し合わせます。

def gen_norder(src_a)
  res_a = case_inequal(src_a)
  res_a += case_equal(src_a)
  res_a += case_exist(src_a)
  res_a
end

以下が実行結果です。

irb(main):012:0> gen_norder([:x1, :x2, :x3, :x4]).size
=> 144
irb(main):013:0> i = 0; gen_norder([:x1, :x2, :x3, :x4]).each { |v| print("#{i += 1}:"); p v }
1:[:x1, :x2, :x3, :x4]
2:[:x1, :x2, :x4, :x3]
3:[:x1, :x3, :x2, :x4]

...

133:[[:x1, :x4]]
134:[:x1, :x3]
135:[:x3, :x1]
136:[[:x1, :x3]]
137:[:x1, :x2]
138:[:x2, :x1]
139:[[:x1, :x2]]
140:[:x4]
141:[:x3]
142:[:x2]
143:[:x1]
144:[]

配列の中に配列があるものは、その要素が”等しい”の意になります。

| | コメント (0) | トラックバック (0)

2008年3月15日 (土)

4変数の順序関係はいくつあるか?

4つの順序を持つ変数に関して、以下の条件 X があるとします。

 x1 < x2 < x3 < x4

X が 真とならない 4変数の関係はいくつ考えられるでしょうか?

X を二項ずつに書き直します。

 (x1 < x2)
  ∧ (x2 < x3)
  ∧ (x3 < x4)

X の否定 not X をとります。

 (x1 ≧ x2)
  ∨ (x2 ≧ x3)
  ∨ (x3 ≧ x4)

不等号と等号を別にします。

 (x1 > x2)
  ∨ (x2 > x3)
  ∨ (x3 > x4)
  ∨ (x1 = x2)
  ∨ (x2 = x3)
  ∨ (x3 = x4)

4変数のいずれかが存在しない場合も考慮することにします。 ここでは、 "is null" と表記しておきます。

 (x1 > x2)
  ∨ (x2 > x3)
  ∨ (x3 > x4)
  ∨ (x1 = x2)
  ∨ (x2 = x3)
  ∨ (x3 = x4)
  ∨ (x1 is null)
  ∨ (x2 is null)
  ∨ (x3 is null)
  ∨ (x4 is null)

突き詰めますと、この10個の条件のいずれかになるわけですが。全部の数が知りたいので、不等号の場合、等号の場合、変数が存在しない場合、各々について、順に考えてみます。

不等号の場合

不等号をそのままにして、4変数の場所を並べ替えることを考えますと。

 P4 = 4! = 24

4つをとる順列を考えればよく、全部で24個の並びが存在することになります。うちひとつは、 X そのものですので、 X が真とならないものは 23個ですね。

0 x1 < x2 < x3 < x4
1 x1 < x2 < x4 < x3
2 x1 < x3 < x2 < x4
3 x1 < x3 < x4 < x2
4 x1 < x4 < x2 < x3
5 x1 < x4 < x3 < x2
6 x2 < x1 < x3 < x4
7 x2 < x1 < x4 < x3
8 x2 < x3 < x1 < x4
9 x2 < x3 < x4 < x1
10 x2 < x4 < x1 < x3
11 x2 < x4 < x3 < x1
12 x3 < x1 < x2 < x4
13 x3 < x1 < x4 < x2
14 x3 < x2 < x1 < x4
15 x3 < x2 < x4 < x1
16 x3 < x4 < x1 < x2
17 x3 < x4 < x2 < x1
18 x4 < x1 < x2 < x3
19 x4 < x1 < x3 < x2
20 x4 < x2 < x1 < x3
21 x4 < x2 < x3 < x1
22 x4 < x3 < x1 < x2
23 x4 < x3 < x2 < x1

等号の場合

4変数のうち2変数が等しい場合は、

 4C2 = 4 ・ 3 / 2 ・ 1 = 6

4つから2つをとる組合わせの数で6個あります。

4変数のうち3変数が等しい場合は、

 4C3 = 4C1 = 4

4個あります。

4変数のうち4変数が等しい場合は、1個あります。

さらに、等号を不等号を組み合わせるわけですが。これは、等しい変数を1変数にまとめ、その並べ替えを考えれば良いかと思います。

例えば、4変数のうち2変数が等しいとしまして、これが、

 x1 = x2

であるとしますと、これを X12 とまとめまして、3変数の並べ替えを考えます。

 P3 = 3! = 6

6個あります。

1 X12 < x3 < x4
2 X12 < x4 < x3
3 x3 < X12 < x4
4 x3 < x4 < X12
5 x4 < X12 < x3
6 x4 < x3 < X12

まとめますと、

 4C2 ・ P3 + 4C3 ・ P2 + 4C4 ・ P1
  = 6 ・ 6 + 4 ・ 2 + 1
  = 45

45個となります。

変数が存在しない場合

4変数のうち1変数が存在しない場合、4変数のうち2変数が存在しない場合、4変数のうち3変数が存在しない場合、4変数のすべてが存在しない場合、各々の場合を考えます。

 4C1  4C2  4C3  4C4

4変数のうち3変数が存在しない場合、4変数のすべてが存在しない場合、については、順序関係が成り立ちませんので、これ以上を考える必要はありません。

4変数のうち1変数が存在しない場合、4変数のうち2変数が存在しない場合、については、それぞれ、3変数の順序関係、2変数の順序関係がありますので、これを考えます。

4変数のうち1変数が存在しない場合(3変数の順序関係):

 P3 + 3C2 ・ P2 + 3C3 ・ P1
  = 6 + 3 ・ 2 + 1
  = 13

4変数のうち2変数が存在しない場合(2変数の順序関係):

 P2 + 2C2 ・ P1
  = 2 + 1
  = 3

従いまして、

 4C1 ・ 13 + 4C2 ・ 3 + 4C3 + 4C4
  = 4 ・ 13 + 6 ・ 3 + 4 + 1
  = 75

75個となります。

まとめ

以上の結果から、 X が真とならない関係は、

 23 + 45 + 75 = 143

全部で143個となります。

この問題は、コンピュータ・ソフトウエアの仕様を考えるものとしても良いですし、プログラムのテストケースを考えるものとしても良いかと思います。詳細仕様の1つの条件について、143個のケースを顧客と打ち合わせる、というのはかなり困難かもしれませんね。プログラムのテストケースであれば、このぐらいはやることもあるでしょうが。

現実には、なんらかの事前条件が使えると思いますので、ここまでケースが膨らむことはないでしょう。典型的には、 x1 < x3, x2 < x4 などが事前条件として与えられることが多いと思います。4分の1くらいには減らせますかね。

| | コメント (0) | トラックバック (0)

2008年3月12日 (水)

フォーマル・メソッドと日本語プログラミング

フォーマルメソッド(形式手法)をご存じだろうか。これは,ほとんどの場合日本語で記述される「要求仕様」を,プログラミング言語によるコーディングと同じように,厳密に「仕様記述言語」で定義する手法のことである。

 要求仕様を仕様記述言語で厳密に定義(モデリング)することで,要求仕様のあいまいさがなくなるほか,ライブラリを作成しておけば「要求仕様の再利用」も可能になる。構文チェックや型チェック,インタプリタによる動的テストにより,要求仕様の正しさもツールで検証できる。結果的に,要求定義フェーズの欠陥を大幅に減らせる。

「拒否反応」がなくなり実用段階に入った「フォーマルメソッド(ITpro)

モバイル FeliCa IC チップ ファームウェアの開発で使われて話題になった1、仕様記述言語ですが。

  • ”普通の”プログラミング言語と詳細度(抽象度)があまり変わらないようにみえるが?
  • これは結局、証明のためのプログラミング言語?

疑問は疑問としまして、それとは別に思ったのが、仕様記述言語としての日本語プログラミング言語2、というのはアリかもしれない、ということです。

業務アプリケーション開発といいますか、エンタープライズ系の世界では、英語で仕様を書く、というのは考えにくいわけでして。実務上、やはり仕様は日本語で書くことになるかと思います。現在、開発工程で大量に書かれている詳細設計書のごときドキュメントというのは、プログラム・コードの”日本語訳”として使われている面があるようにも思いますね。つまり、日本では、仕様からプログラム・コードへと落とし込む過程というのは、日本語から英語(のようなもの)への翻訳でもあるわけでして。

こうした面から考えますと、プログラム・コードはともかく、仕様記述では日本語を使いたい、というニーズは当然出てくるでしょう。日本語じゃないと、日本語圏の人間は読んでくれないでしょうからね。そうすると、日本語をベースに、フォーマル・メソッド的な記述を可能にする言語、というのは使えるかもしれないですね。

まあ、日本語の文法で記述する必要はなく(かえってややこしくなりそうです)、単に、日本語の文字セットが使えれば、それでいいような気がしますけどね3 4 5



1. "モバイル FeliCa IC チップの開発に おける形式仕様記述手法の導入" (PDF)

2. ”日本語プログラム言語「なでしこ」” など

3. "日本語でおk"(増井俊之の「界面潮流」 WIRED VISION)

4. ”Ruby もいいけど Smalltalk でも、おk。"(sumim's smalltalking-tos)

5. "日本語プログラミング言語Scala"(inforno)

 


| | コメント (0) | トラックバック (0)

2008年3月 8日 (土)

ソフトウエア開発を効率化するには

抽象度をより引き上げていく以外にないのでしょうけど。

On the one hand, you may hear about that things have never looked brighter: We have better tools, better testing, better languages, and better methods than ever before! On the other hand, you will also hear that we haven't really made much headway since the dawn of the computer era.

Scott Rosenberg, "Dreaming in code", Crown Publishers, 2007, p.9

ソフトウエア開発について明瞭であったことはないかもしれない。プログラマ達は言うだろう。ソフトウエア開発には、かってないほどに、良いツール、良いテスト手法、良い言語、良い方法論があると。またプログラマ達は、こうも言うだろう。コンピュータの黎明期から、ソフトウエア開発には、本当の進歩はほとんどないと。

抽象度を引き上げる手段としては、ライブラリ的なアプローチと、言語的なアプローチがあり、”部品化”というのは、どちらかといえば前者になるかと思います。

ライブラリ的なアプローチというのは、ボトムアップにソフトウエアのスタックを、より抽象度の高い方向へと積み上げていくやり方です。コンピューティングの”How”に関する詳細な部分を、スタックの下部へと押しやり、”What”な部分をスタックの上部に持ってくることで、ソフトウエア開発の効率化を図ろうとするわけでして。スタックの下部が安定していれば − つまりあまり仕様変更がなければ、スタックの下部はテストの積み重ねで、品質が向上していき、その結果、スタックの上部にだけ注意を払えばよくなるので、効率化できるわけですね。

言語的なアプローチというのは、より抽象度の高い、メタなレベルでソフトウエアを記述して、トップダウンでソフトウエアのスタックを、抽象度の高いレベルから、抽象度の低いレベルへと落とし込むアプローチです。つまり、新しいプログラミング言語を用意するわけですが。これも、翻訳の機構が安定すれば、品質の向上と効率化を図ることができます。

ソフトウエア開発の進化の歴史というのは、このボトムアップ・アプローチとトップダウン・アプローチの積み重ねだと思います。両者は相互に影響し合って進歩してきたわけです。

ただ、残念ながら、”革新的”というほどの進歩ではないんですよね。

1954年、世界初のプログラミング言語 FORTRAN が生まれて、プログラマは”普通の数式”でプログラムを書くことができるようになりました。足し算や掛け算を機械にどうやらせるか、なんてことを考える必要はなくなったのです(ただし、十分な計算機リソースがあれば)。

1960年、 ALGOL 60 が提唱され、プログラムを構造化して記述することができるようになりました。プログラマは、巨大な一枚岩のプログラムを、サブルーチンに分割できるようになったのです(ただし、十分な計算機リソースがあれば)。

1972年、 C言語 が生まれました。この言語は、コンパクトで効率がよく、ミニコン上でも、コンパイラを動かすことができたのです。プログラマは、貧弱な計算機上でも、まともなコンパイラが使えるようになったのです。また、標準ライブラリ他、プログラムのライブラリの蓄積が始まり、同じコードを何度も再発明する必要も多少は薄らぐようになってきました。

1983年、 C++言語 が生まれました。プログラマはオブジェクト指向でプログラムを記述できるようになったのです。リスト、マップなどのコンテナ、ソート、サーチのようなアルゴリズムなど、以前はライブラリ化の難しかったものもライブラリ化できるようになりました。

1995年、 Java言語 が生まれました。プログラマはソースコードの再コンパイルを行なわなくても、プラットフォーム間で同じプログラムを使うことができるようになったのです(ちゃんと互換性に気をつけていれば)。また、ガベージコレクション機能によって、プログラマはメモリ・リソースの管理を行なう必要もなくなりました(ある程度は)。

プログラミング言語の簡単な歴史です。この数十年で、コンピュータの利用形態は劇的に変化していますが、それはハードウエアの価格性能比面での進歩に負うところが大かと思います。”ソフトウエアの開発”という面だけをみると、思ったほどには進歩していないと言うべきでしょう。ブルックス氏のいうとおり、今のところ”銀の弾丸”はなさそうです。

| | コメント (1) | トラックバック (0)

2008年3月 7日 (金)

SIビジネスの規格化

そのカギが「ソフト産業の近代化、工業化にある」とし、山下氏は手始めに「規格型SIを推進すべきだ」と主張する。プレハブ住宅のように規格化した柱や窓、壁などをトラックに積み込み、1日で家が建つような感覚でシステムを構築する。工場で設計図通りに複数の部品を組み合わせて作り上げるので、現場でカンナを磨いて、木を削り始めるわけではない。

 マフラーだけを作るソフト部品会社、タイヤだけを作るソフト部品会社と、システムインテグレータと呼ぶシステム組み立て会社に分業化することで、インテグレータはソフト部品会社から調達した部品を組み合わせてシステムを構築する。インテグレータは国内中心に競争するが、ソフト部品会社はグローバル展開も図れる。もちろん工業化には品質や信頼性に関する基準も必要になる。

黒船の大砲がソフト業界に構造改革を迫る(ITpro 田中克己の針路IT)

ソフトウエアの”部品”ということであれば、オペレーティング・システム(OS)、DBMSなどのミドルウエア、標準ライブラリ、フレームワークと、昔から着々と積み上げられて来てはいます。そうした”部品”を”組み立てる”ための統合開発環境(IDE)も色々とあります。”部品”だけでなく、ERPのように、一般的な企業の業務に、必要な機能を一通り揃えているものもありますし。現在でも、可能なところは”規格化”しているとは思います。これからもこの方向での努力は続けられると思いますが。それと、ここでいう”規格化”が、どう異なるのかが、よくわからないですね。

SIで行なわれている、大量の単純作業を人海戦術でこなすような、”大規模ソフトウエア開発”というのは、非効率・前近代的であるとは思うのですけどね。企業で必要とする大量の機能があって、それを集めて、ひとつひとつ具体的仕様を決めて、コードにして、検証する。こういったプロセスを、一般化できるメタなアルゴリズムがあれば良いのですが。仕様を決めるところまでは、本質的に人間がやるしかなさそうですが、コード化と検証の部分なら、まだ可能性はありそうだと思います。

| | コメント (0) | トラックバック (0)

2008年3月 5日 (水)

再分配所得のジニ係数

税・社会保障の再分配によるジニ係数の改善度は、近年、調査毎に大きくなっており、26.4%で過去最高。なお、世帯単位でみたジニ係数は、当初所得では0.5263 、再分配所得は0.3873 。(高齢者世帯の増加等により当初所得のジニ係数は年々大きくなっているが、再分配所得のジニ係数は平成11年調査以降0.38 台で推移している。)

平成17年 所得再分配調査 (厚生労働省) 結果の概要 p.2

この「再分配所得のジニ係数」というのが、よくわからないのですよね。

一世帯当たりの平均当初所得は465.8万円であり、この当初所得から税金(45.4万円)、社会保険料(52.2万円)を差し引き、社会保障給付(181.4万円)を加えた再分配所得は549.5万円となっている。

平成17年 所得再分配調査 (厚生労働省) 所得再分配調査結果 p.7

調査結果の p.9 に「世帯類型別所得再分配状況」というのがありまして、「一般世帯」(世帯数 4,373)、「高齢者世帯」(世帯数 1,233)、「母子世帯」(世帯数 83)のそれぞれについて、内訳が載っています。 「一般世帯」の社会保障受給の内訳は以下のとおりとなっています。

受給合計額 145.2
年金・恩給 71.6
医療 54.3
介護 11.3
その他 8.0

「一般世帯」は、平均で年間145.2万円の社会保障給付を受けているということですかね。ジニ係数は、当初所得 0.4252、 再分配所得 0.3873。

調査結果 p.7 「当初所得階級別所得再分配状況」をみると、当初所得50万円未満〜1,000万円以上までで、50万円刻みで階級分けされた値がありますけど。すべての所得階級で年間100万円以上の社会保障受給がありますね。何でしょうかね、これは。こういうものなのでしょうか。

| | コメント (0) | トラックバック (0)

2008年3月 4日 (火)

IT企業の教育費

インドのIT大手インフォシスの教育費は売上高の 5% に達するのだそうです。

興味を持ったのは、その教育費。なんと、売り上げの5%、200億円を投じている。この200億には、企業内大学のキャンパスの建築費などは含まないそうだ。  スリラムさんによると、「IT企業は結局人しかない、だから我々はこれに投資する他はない」

 おそらく日本のIT企業で、売り上げの5%という数字を教育にあてている企業は、そう多くないのではないだろうか。通常は1%、ないしは、ゼロケタ台というのも関の山だと思う。いかに、教育のために投資されている予算が少ないか、この数値である程度は推察できる。

企業内教育とお金(NAKAHARA-LAB.NET 東京大学 中原淳研究室 : 「大人の学び」を科学する)

確か、日本のIT企業の教育投資は、売上高のゼロ点何パーセントとかでしたね。

「先進のソリューションによる経営効率の改善」。このお題目が最も遅れている産業、それが情報サービス産業だ。事実、「JISA基本統計調査  2006」によると売上高情報化投資率は平均で0.79%、中央値で0.58%しかない。これに対して「国内IT投資動向調査報告書 2004」(ITR)によれば、国内平均の情報化投資率は平均1.9%(同報告書の『2006』では2.8%、『2007』では3.2%)で大きな開きがある。

 さらに、情報サービス産業の「売り上げ研究開発投資率」は平均1.02%、中央値0.01%。人材育成の要となる教育投資率は平均で0.38%だ。

あらためて衝撃 日本のソフト産業を統計分析する(@IT)

JISA(社団法人 情報サービス産業協会)基本統計調査 2007年版 概要 をみますと、売上高投資率は加重平均 0.37 %、中央値が 0.26% となっていますね。 5% 以上というのは、回答企業のなかではゼロ。1%未満が全体のほぼ 90% みたいですね。

売上高規模を見ると、平均値 209億46百万円、中央値 54億68百万円。確かに、売上高4000億のグローバル企業と、日本国内オンリーのローカル企業の差というのはありそう。しかし、日本国内だけの調査対象企業の売上高を合計すると約8兆円あるわけでして、”腐っても鯛”。中小企業の多い日本の産業の特性もありそうですね。

思うに、「日本ほど、教育に多くを期待しながら、そこにお金をかけない国は珍しい」。一言でいうと、「やい、教育、この問題何とかせい!、金は出さないけど、頑張れ」。そうした風潮は企業内教育であろうと、公教育であろうと、そう変わらない。

 たとえば、日本の教育への公財政支出は、年間国家予算の3.5%である。これは、OECD加盟国30ヵ国最下位(2003年)。  もっとも公財政支出の大きいアイスランド7.5%は別格にしても、フィンランド6.0%、米国5.4%、にも間をあけられ、スロバキア4.3%、チェコ4.3%、アイルランド4.1%、にも負けている。

 それなのに、教育に対する社会的期待は、日に日に増大するばかり。何か問題が起これば、「やれ教育は何をやっている」「やれ、教育のせいだ」という風に「教育」に原因帰属が行われる。「やい、教育、しゃんとせい、何とかしろ」ということになる。

教育への公的支出も先進国中最下位でしたか。

 アメリカでは、教育はどのくらい重要視されてるんだろうか? ああそうだ、財政のリストを見りゃいい − なるほど、だいぶ下の方の、労働安全衛生局と食肉検査の間か。俺たちの子供の面倒を毎日見てくれている人の収入は、平均年収で4万1351ドル。今日のディナーに連れてってくれるのはどこのタバコ会社のロビイストかなってことだけを気にしている下院議員は14万5100ドルももらってる。

【略】

だが何と言っても一番傑作な皮肉は何かというと、アメリカ人の教育に十分な財源を割くことを拒否した当の政治家たち本人が、アメリカの子供たちのデキの悪さにむかっ腹を立てたりしていることだ。ドイツや日本は言うに及ばず、まともな水道と経済力のある国の中でアメリカ以上に成績の悪い国なんてどこにもないってんで、突如として政治屋どもは説明責任を求め始めた。教師に責任を押しつけ、資格試験をしろなんて言い出したんだ。もちろん、子供たちにも試験をやれと − 何度も何度も何度もだ。

マイケル・ムーア著, 松田 和也 訳, 『アホでマヌケなアメリカ白人』, ゴマブックス, 2008年, p.152-157

”教育に対する社会的期待”に関しては、どの国でも同じようなものかもしれません。

・・・

アホでマヌケなアメリカ白人 (ゴマ文庫)Bookアホでマヌケなアメリカ白人 (ゴマ文庫)

著者:マイケル・ムーア
販売元:ゴマブックス
Amazon.co.jpで詳細を確認する

| | コメント (0) | トラックバック (0)

2008年3月 2日 (日)

リチャード・ファインマンのエンジニアリング考

ソフトウエア・エンジニアの Gustavo Duarte 氏のブログで、スペース・シャトル”チャレンジャー”の事故調査委員会に寄せられた、物理学者 リチャード・ファインマン氏の論考が取り上げられています。

Richard Feynman, the Challenger Disaster, and Software Engineering (Gustavo Duarte)

原文はこちらにあります。

Feynman's Appendix to the Rogers Commission Report on the Space Shuttle Challenger Accident

個人的に興味深い点について、引用したいと思います。

It appears that there are enormous differences of opinion as to the probability of a failure with loss of vehicle and of human life. The estimates range from roughly 1 in 100 to 1 in 100,000. The higher figures come from the working engineers, and the very low figures from management. What are the causes and consequences of this lack of agreement? Since 1 part in 100,000 would imply that one could put a Shuttle up each day for 300 years expecting to lose only one, we could properly ask "What is the cause of management's fantastic faith in the machinery?"

事故によってシャトルと人命が失われる可能性を、エンジニアとマネジメントとに見積ってもらったそうです。エンジニアは100回に1回程度だろうと答え、マネジメントは10万回に1回程度(!)と答えた、とあります。10万回に1回ということは、毎日シャトルを打ち上げて、300年に1度しか、そのようなことは起きない、ということで、一体このファンタスティックな信頼はどこから来ているのか、と問うています。

おそらく、NASAのマネジメントの見積もりは、多分に政治的なもので、つまり、

”スペース・シャトルは絶対安全です!!”

ということなのだと思います。

個人的には、NASAの”ロケット・サイエンティスト”達がこうした発言を行なうというのは、少々意外ではありますね。NASAといえども、政府の一部門であり、お役所の論理があるのは当然のことなのでしょうが。アメリカにもホンネとタテマエがあるんですねえ。

The Space Shuttle Main Engine was handled in a different manner, top down, we might say. The engine was designed and put together all at once with relatively little detailed preliminary study of the material and components. Then when troubles are found in the bearings, turbine blades, coolant pipes, etc., it is more expensive and difficult to discover the causes and make changes.

スペース・シャトルのメイン・エンジン − 液体燃料エンジン、のようなものは、通常は”ボトム・アップ”で設計されるのだとか。つまり、エンジンを構成する個々の部品について、単体で設計とテストを行い、不具合が見つかった場合には、修正を行ないながら、部品を順次よりおおきな構成物へと組み上げていき、最終的な構成物、 エンジンを完成させるそうです。

しかし、NASAでは違ったやり方で行なわれており、それは”トップ・ダウン”と呼ぶべきものであると。材料・部品の予備調査を行なった上で、一度にそれらを設計して組み上げてしまうのだそうです。このため、どこかにトラブルが見つかった場合には、原因調査をして設計変更を行なうのが、より高価になり困難になってしまう、とあります。

これは、確かにソフトウエア開発プロセスに関して語られていることに通じますね。ハードウエアであっても、スペース・シャトルのメイン・エンジンのような”1点もの”の開発の場合には、そのプロセスはソフトウエアを開発するのとあまり違いはない、ということでしょうか。

| | コメント (0) | トラックバック (0)

« 2008年2月 | トップページ | 2008年4月 »