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

2008年5月30日 (金)

IPAでの学生討論

この企画って、実は非常に好評(面白いという意味で)なのではないか、と思いました。

CSKの有賀氏は「若い時に一つの仕事をアサインされても全体なんてわからない。同じ仕事している3人に『何をしている?』と聞いたら「石を積んでいる」「門を作っている」「寺を作っている」という別々の答が返ってきたという話があるが,全体をとらえる努力をすることがやりがいにつながる。やりがいは自分で作っていくもの」と話す。しかし学生は「忙しいから教えてやれないという否定的なマネジャと,ビジョンを示すマネジャでは組織のパフォーマンスがまるで違ってくるはず」と反論。有賀氏は「言いたかったのは,自分の回りでやっている自分の担当と関係のないことも勉強しろということ。そうすれば成長する」と補足した。

「IT技術者はやりがいがある仕事か」---学生とIT産業のトップが公開対談 (ITpro)

ちと噛み合っていない感じですね。仕事全体の目的を教えることと、それを自ら主体的に学ぼうとすることとは、両立しますから。有賀氏が語ったのは、おそらく全体の目的を知ることでモチベーションが出てくる、というもので、教えるのか学ぶのか、という話は脇道ですかねえ。

ロスアラモスで仕事につかされたこの若者たちが、まずさせられたことといえば、IBMの機械にチンプンカンプンの数字を打ち込むことだった。しかもその数字が何を表しているのかを教える者は誰一人いなかったのだ。当然のことながら仕事は一向にはかどらない。

【略】

そこで僕が、このグループのとりくんでいる仕事の内容や目的について、ちょっとした講義をすることになった。さて話を聞き終わった若者たちは、すっかり興奮してしまった。「僕らの仕事の目的がわかったぞ。僕らは戦争に参加しているんだ!」

”下から見たロスアラモス”, 『ご冗談でしょう、ファインマンさん 上』, 岩波現代文庫, p.217

以下の箇所は討論中も盛り上がったそうなのですけど。

IPAの西垣氏は「仕事をコツコツ続けていれば見えてくる」と話す。「まず10年間は泥のように働け」という,伊藤忠商事 元社長 丹羽宇一郎氏の言葉を紹介した。丹羽氏が新入社員に語ったという言葉で「まず10年間は泥のように働いてもらう。その中で周囲を思いやる力をつける。次にマネジメントの勉強をして,最後の10年はマネジメントを大いにやってもらう」というもの。

しかし学生からは「10年耐えられる人もいるかもしれないが,心が折れる人もいる」「10年たてば環境や必要なスキルは変わっているのではないか」と反論。「10年我慢して働くという人は挙手して」という司会の呼びかけに,手を挙げた学生はいなかった。

「IT技術者はやりがいがある仕事か」---学生とIT産業のトップが公開対談 (ITpro)

もう少し突っ込んだ内容があってもよさそうですよね。これだけですと、学生たちの考えがよくわかりません。

  1. 10年も馬車馬のように働けない
  2. 下積みで10年は長すぎる
  3. 同じ会社に10年もいられない
  4. そもそも10年も働きたくない

西垣氏の発言内容からすると、10年現場で一兵卒として働き、次の10年で(中間管理層で)マネジメントを学び、最後の10年は経営者(取締役)として働く、ということのようです。まあ、日本企業の会社員の一般的なキャリアパスですよね。こうした日本企業的キャリアパスに対する反発、ということなのでしょうか。

あと、おもしろかったのは東京情報大学の方が質問した「私はずっと技術者のままでいたいのですが、何がおもしろくて経営者になろうとしたのですか?」という質問。産業界側の人たち全員が「おもしろそうと思って経営者になったわけじゃない」と答えていたのがおもしろかった。向さんの「自分でやりたいことをやろうと思ったら経営者になるしかなかった」という答えが多分本質なのだと思う。有賀さんのある意味意地悪い質問も意地悪ジジイぶり全開で素敵だった。しかもそれをかわいい女学生に言うというのがたまらない「技術者のまま行かれたら良いと思いますよ。主任技術者、執行取締役員待遇技術者とね。ただ、技術者であるためには常に最新技術の半歩先にいなければならない。それができるのであれば技術者で一生を通すなんて素敵じゃないですか。」

IPAX 2008を見に行ってきた (発声練習)

日本企業的キャリアパスというのが、「雇用の安定」というドグマの上に築かれている、という点も考えないといけないですね。逆にいえば、雇用の安定を捨てれば、「ずっと技術者」でいることは、今でも可能だと思います。企業に所属せずに、フリーで仕事をすれば良いのではないでしょうか。

話題は,企業が重視するスキルと,学校が重要視して教育しているスキルのギャップに移った。IPAの調査によれば,IT企業が大学教育に期待するものは,1位が「システム・ソフトウエア設計」,2位が「文章力」,3位が「チームワーク」。「1位以外はコンピュータ・サイエンスに関係ない。これは日本の初等教育の失敗を示している」(CSK有賀氏)。

この点に関しては、別にソフトウエアに限った話でもないと思いますけどね。「初等教育の失敗」というのは、ちと違うと思います。

設計者が下す決定のうち、自分たちが膨大な時間を費やして学校で学んだ計算の類に基づいてなされるものはわずかの割合しかないということを知るのは、多くの場合、学生にとっては衝撃的である。

”工学設計に関する報告”(1981), 『技術者の心眼』(平凡社 1995)より孫引き

文書力・コミュニケーション能力が上位にくるのは、そもそもソフトウエアの設計というのが、未だ定式化されていないこととも関係しているように思います。実際、どうやって仕様を伝えるのか、毎回頭を悩ませているのが現状ですからね。

「学生時代に学んでおいてほしいこと」というテーマでは、「よく調査などでは文書作成能力やコミュニケーション能力が上位に上がるが、これはIT業界に限った話ではない。できて当たり前で、それができていないから企業側が苛立っている証拠だ。高校までに学ぶべきことで、どちらかというと日本の教育制度の問題」(有賀氏)と主張。

「10年は泥のように働け」「無理です」―今年も学生と経営者が討論 (@IT)

もちろん、どんな業界であれ、チームで仕事をする以上、”コミュニケーション能力”が要求されるのは当たり前の話ではあるのですが。

鵜飼 ―― Googleは採用時に、チームとして働ける人物かどうかをしっかり見極める会社なんで、「変わった人」はいてもコミュニケーションに困るような偏屈なエンジニアはいませんね。

”Googleの開発現場”, システム開発JOURNAL Vol.1 (2007), p.130

伝え聞くところでは、GoogleやMicrosoftは、採用面接試験で、相当高度なコミュニケーション能力を要求しているみたいですね。

MITに集まっている人たちはとても優秀で、こちらがつたない英語で伝えようとしたことの意図を汲み取る能力に長けています。

【略】

その証拠に街に出て、とくに子どもと話そうとしたとき、通じなくて非常に苦労しました。

畑村洋太郎 著, 『畑村式「わかる技術」』, 講談社現代新書 (2005), p.43

コミュニケーション能力の高さ、というのは、「スマート」であることの要件の一つなのでしょう。

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

2008年5月29日 (木)

年金と保険

素人なりに考えてみました。

ある生命保険を考えます。この生命保険は、ある期間中 a < t < b に、死亡があった場合に、保険金が支払われます。Wikipediaにあった式を流用しますと、保険料と保険金との関係は、以下のような形になるはずです。

P = ω[a < t < b] Z

ω[a < t < b] は、この期間内に死亡する確率です。

期間の上限をはずして、 a より後に死亡した場合に保険金が支払われるとしますと:

P = ω[a < t] Z

この場合に、保険金 Z を、 a より後に、死亡するまで分割して支払うとしますと、この生命保険は、かなり年金に近くなってきますね。年金の場合、 a から死亡までに、保険金 Z が満額支払われるわけではありませんから、 Z も死亡時点 x によって変動します。

P = ω[a < t] E[Z(x)]

かなり適当な話ではありますが、年金は生命保険の変種と考えればよさそうです。

さて、年金が単なる貯蓄よりも、「スケールする」のは、以下のような事象があるためでしょう。

  1. 被保険者が、支給開始時点 a に達せずに死亡する。
  2. 被保険者が受け取る年金総額が、 保険金額 Z に到達する前に死亡する。

被保険者全員が「満額」を受け取るわけではありませんから、貯蓄するより少ない拠出額によって、リスクに備えることができるわけですね。これを「スケールする」といったわけですが。この場合の「リスク」が、 時点 a より「長生きする」ことであるのは、少々複雑な感はありますけどね。

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

2008年5月27日 (火)

「保険」という言葉

”資金を預かって、これを運用して、保険金として返す”、”やがて自分たちに返ってくる保険料”というくだりで、少し引っかかってしまいました。

結論から述べてみよう。国が民間型の保険をやること自体が誤りなのである。1960年代、国民皆年金、国民皆保険ということで、福祉制度の充実のスローガンのもとに現在の制度がつくられたのだが、福祉制度の充実と保険制度の導入とが同じものと考えてしまったことに問題があったのだ。

福祉制度の充実は必要だし、国がそのために大きな役割を果たすことは必要である。しかし、国ができることは、税金を取って福祉にあてること、つまり、福祉サービスのメニューを充実して、そのための税金を取ることなのである。これは、広義の所得再分配であると考えられる。また、税金といっても、所得税や消費税のような一般財源ではなく、例えば、社会福祉税という名の特定財源でもいいわけである。

しかし国には民間のように保険料をとって、これを金融市場で運用する能力はない。つまり、個人から保険料という形で資金を預かって、これを運用して、保険金として返すことはできないのである。

【正論】早稲田大学教授・榊原英資 国は保険業務から撤退せよ (MSN産経ニュース)

ここまで仰る以上、榊原氏が責任を持って、あらゆる社会保障需要をことごとく賄うだけの税金をどこからか取り立ててきてくれるんでしょうね。

それがどれだけの税率になろうが、責任を持ってそれだけの税金を持ってこれると。

市民の皆様は、やがて自分たちに返ってくる保険料だという名目もなく、喜んで山のような税金を払ってくださると。

榊原英資氏の「正論」 (EU労働法政策雑記帳)

Wikipedia では、「保険」の頁には以下のように記述されています。

保険(ほけん 、英:insurance)とは、偶然に発生する事故(保険事故)によって生じる財産上の損失に備えて、多数の者が金銭(保険料)を出し合い、その資金によって事故が発生した者に金銭(保険金)を給付する制度。

"保険" (Wikipedia)

例えば、100人に1人がかかる病気があり、その治療に要する費用が100万円だとします。このリスクを100人でシェアすれば、1人あたりの拠出額は1万円となりますね。1万円の拠出で100万円のリスクに備えることができる、というのが保険の本質であろうと思うわけです。

契約者と保険会社の間に締結される保険契約において、保険金と保険料の間では以下の関係が満たされることが要請される。これを給付・反対給付均等の原則と呼ぶ。

P = ωZ

ここでPは保険料、ωは定量化された保険事故のリスク、Zは保険金を表す。この原則は、保険事故発生のリスクを媒介として保険金(給付)と保険料(反対給付)が等しくなるように要請されていることを示す。

"保険" (Wikipedia)

”自分達が支払った保険料が保険金として返ってくる”という言い方が、確率上の期待値のことを指しているとすれば、それはそのとおりなのかもしれませんが。普通は、リスクが顕在化して発生した損失に対する補填を受けるか、そうでなければ、ただ保険料を支払っただけで終わるわけですから、”返ってこない”のが当たり前のものであろうと思います。民間の損害保険の類は、基本的にそういったものですよね。

社会保険というのは、健康保険と年金とからなるのでしょうけど。

健康保険については、損害保険と基本的な考え方は同じでよかろうと思います。医療保険を国民全てが必要とするのであれば、個々の民間保険会社の被保険者集団でリスクをシェアするよりは、国民全員でリスクをシェアした方が効率が良いでしょう。老人、小児、妊産婦、持病のある人等の「高リスクな」人々が、保険に加入できなくなる、という事態を防ぐだとか、政府が保険者になることで、医療機関に対する価格交渉を有利に進められるだとか、他にも色々とメリットはあります。

年金は損害保険とは性格を異にしている感じですね。とはいえ、積立方式ではなく、賦課方式であるわけですから、もともと、預貯金でもなければ、投資信託のようなものでもないわけですよね。世代間扶助の仕組み、であるとしか私にはわかりません。いずれにせよ、賦課方式であるということは、何十年にも渡る超長期の経済リスクを考える必要もなければ、運用の巧拙を問う必要もない、ということでしょう。

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

エンタプライズ系ソフトウェア技術者の勤務実態

しかし、月平均の就労時間が200時間を超える「長時間労働者」は全体の40.1%おり、「健全な水準とはいいがたい」としている。特に「インフラ構築」「運用構築」「コンサルティング」「プロジェクト管理」「運用」などに携わっている技術者は、長時間労働を行っている率が高いという。

IT技術者の4割は月200時間以上労働―IPAが調査 (@IT)

平均就労時間の中央値は月間180時間だが、平均就労時間が200時間を超える長時間労働者は40.1%に達し、「健全な水準とは言いがたい状況」としている。また、平均就労時間で「300時間以上」も3.5%いた。ただし、平均値は169.5時間で他産業と比較しても特別高い水準にはなく、産業界全体で長時間労働化しているわけではないという。

ソフトウェア技術者の4割が月200時間超の長時間労働 (Open Tech Press)

ニュースソースが行政機関ですと、詳細なレポートがちゃんとあって、有難いですね。

2007年度エンタプライズ系ソフトウェア技術者個人の実態調査 (IPA)

回答者の属性が以下のように整理されています(p.15〜17)。

  1. アンケートでは、85%が男性、15%が女性による回答者からの結果が得られた。
  2. 年齢層では、回答者の30 代と40 代で3 分の2 と30 代〜40 代の回答者が多い。
  3. ユーザとベンダーとの分類では、ほぼ半数ずつの回答者という結果となった。
  4. 経験年数では、「5 年以上10 年未満」がもっとも多く20.3%、 10 年未満が過半数を占める。一方、20 年以上も2 割近くいる。
  5. 本回答者の最終学歴では、情報系の大学卒業者は修士を含めて約15%にとどまり、大学(情報系以外の理系)、および大学(その他)から本業界に入ることが多い。

「ソフトウエア業界の産業階層の位置」(p.18)というのが、載っています。

現行業務もしくは直近1 年間の代表的プロジェクトにおける担当業務を通して、ソフトウェア開発業界の産業階層のどの位置に属している、もしくは属していたか、について調査を行った。

これによりますと、回答者の属性は以下のとおりです。

ユーザー 17%
自社開発 24%
元請 20%
一次下請 13%
二次下請 8%
コンサルタント 7%
パッケージ 7%
その他 4%

 

もうひとつ、私の注意を引いたのは、「システムの利用局面(業種)」(p.27)です。

製造業に係るシステムが23.1%と多く、次に多い金融・保険業の約2 倍の割合にもなる。 金融・保険業、情報通信業、卸売・小売業に係るシステムが多い。

製造業 23.1%
金融・保険業 12.9%
情報通信業 11.2%
サービス業(他に分類されないもの) 9.7%
卸売・小売業 9.5%
建設業 4.4%
複合サービス事業 4.2%
公務 4.1%
わからない 3.7%
運輸業 3.6%
医療福祉 3.3%
電気・ガス・熱供給・水道業 2.7%
その他 2.6%
教育、学習支援業 2.1%
不動産業 1.8%
農林水産業 0.6%
飲食店、宿泊業 0.6%

 

「平均就労時間、ピーク時就労時間」(p.31)は以下のようになっています。

平均値で比較すると平均月とピーク月では、48h のギャップがある。平均就労時間の中央値は180h/月で、組込みソフトウェア産業と同水準となった。また、平均値を産業別で比較すると、製造業よりは高く、建設業よりは低い水準にある。

月間平均就労時間が200h を越える長時間労働者の比率は40.1%で、健全な水準とはいい難いが、組込みソフトウェア産業の実態(48.1%)よりは低い状況にある。

平均就労時間の平均値・中央値:

平均値 170h
中央値 180h

ピーク時就労時間の平均値・中央値:

平均値 218h
中央値 220h

 

ざっと流し読みした程度なのですが、記事とはやや異なる印象を受けました。

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

2008年5月24日 (土)

動的言語 vs 静的言語

海の向こうでも議論が続いているようですね。

Debate and more Insights on Dynamic vs. Static Languages (InfoQ)

思うに、「プログラミングの問題」というのは、基本的に計算機の性能の問題なんですよね。例えば、並列処理は何のためにあるのか? といえば、計算機をより効率的に使うためにあるわけでして。動的言語と静的言語というのも、計算機の性能とのトレードオフというのが、根底にはあるわけです。

コンパイル時に型をチェックして、かつ、記述が煩雑にならないよう、型指定を省略できる、でも指定したいときには指定もできる、というような言語を作ることも理屈上は可能でしょう。それで、かつコンパイル時間と、目的コードの実行時間も、”実用上十分なほど”早くするとなると、実現は難しくなってくるわけで、ここで、言語機能の何かをトレードオフしなければならなくなってくるわけですね。何をトレードオフしたか、ということで”動的言語”と”静的言語”の分類が生じているのでしょう。

実際に色々な言語でプログラミングをしていると、型指定や型チェックが欲しいと思うこともありますし、型をいちいち指定するのが煩わしいと思うこともあります。もちろん、達成したい性能目標との兼ね合いもあります。

These languages are all useful, for different things. A good programmer uses his common sense to provide the best value possible. That includes choosing the best language for the job. If Ruby allows you to provide functionality 5 times faster than the equivalent functionality with Java, you need to think about whether this is acceptable or not. On the one hand, Java has IDEs that make maintainability easier, but with the Ruby codebase you will end up maintaining a fifth of the size of the Java code base. Is that trade off acceptable? In some cases yes, in some cases no. In many cases the best solution is a hybrid one.

両方の特徴を兼ね備えた言語が1つあれば、理想的ではあるわけですが。それがかなわない以上、上の意見が妥当でしょうね。シーンに応じて、言語を使い分けるしかないでしょう。

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

どの登場人物に感情移入するか

ということだと思いますけどね。

また、別の回に、資源の有限性がその合目的的な最適配分を促し、戦略性やリーダーシップや組織内の規範意識も意思決定も価値判断もそこから始まる、ということをわかりやすく説明したくって、四川の震災のニュースを挙げてトリアージの概念を説明した。絶対的に医療資源が不足しているところでは、「もう助かりそうにない患者」と「患者自身が処置したら大丈夫な患者」はカテゴライズして分けて、その間の「治療しなければ助からないが治療すれば助かるかも」というところに有限の医療資源を配分する、というシステムがあるんだよ、ということを説明したら、やっぱり女子学生のかなりの部分から「かわいそうだ」という反応があった。

ケーキ (福耳コラム)

ある種の「物語」を聞いて、登場人物の誰に自分を投影するかによって、違った感想がでてくる、というのは、当然あると思うのですよね。上の災害現場でのトリアージに関していえば、自分の立場を、医師におくか、患者におくかによって、やはり見方は異なるでしょうね。

もっとも、「かわいそう」という感想は医師にしろ患者にしろ、当事者からは出てこないようにも思えますね。むしろ、その場面をみている第三者、傍観者の見方という感じです。モラトリアムという語は、どこか「社会の傍観者」というニュアンスを感じさせますね。まさにモラトリアム期間にある学生達が、そういった実社会で起きている「物語」に対し、傍観者の見方をする、というのは、無理からぬという気もします。

確か実話をもとにした小説で ― 題名も著者名も失念してしまったのですが 、次のような話があったと思います。

さる小さな島で火山が噴火した。火山流が海岸沿いの集落に達する前に、船で島から脱出しなければならない。しかし、島民全員を乗せるだけの船はない。島の人々は船に殺到し、船が満員になっても、とりすがって「乗せろ」という。このままでは、船は出港できず、全員が火山流に呑まれてしまう。そこで、船頭は、とりすがる人々の腕を鉈で次々と切り落とし、船を出港させた。結果、船に乗せることのできた島民は、助かることとなった。

私がこの話を読んだとき、最初に感情移入した登場人物は、船頭氏でした。この切迫した状況下で、こうした過酷な決断を迅速に行い、即座に実行に移す。自分ならできるだろうかと考え込んでしまいましたね。そして、この船頭氏の決断力・行動力に唸ってしまったわけです。

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

2008年5月22日 (木)

スケジュールの重なりを判定する問題

以下のように、作業A と 作業B があり、 それぞれに、開始日、終了日のペアが与えられている場合に、この2つの作業のスケジュールが重なるか否かを判定する問題を考えます。

作業 開始日 終了日
A 5/1 5/20
B 4/1 5/3

 

解答

2つのスケジュールが 重ならない 場合というのは、以下の式になりますね。

終了日B < 開始日A ∨ 終了日A < 開始日B

よって、2つのスケジュールが重なる場合は、上の否定になります。これを Ruby で書いたものが以下です。

def overlapped?(x1, x2, y1, y2)
  not (y2 < x1 or x2 < y1)
end

Aの 開始日, 終了日 を、 x1, x2 、 Bの 開始日, 終了日 を y1, y2 としています。

検証

以前、以下のエントリで作成しました、Rubyスクリプトを使用します。

順序関係列挙と事前条件

まずは、今回の問題で起こり得る論理式を、すべて列挙してみます。

irb(main):021:0> i = 0; apply_cond(gen_norder([:x1, :x2, :y1, :y2]), [:x1, :x2,:y1, :y2], ['x1<=x2', 'y1<=y2']).each {|v| print("#{i += 1}:"); p v }; nil
1:[:x1, :x2, :y1, :y2]
2:[:x1, :y1, :x2, :y2]
3:[:x1, :y1, :y2, :x2]
4:[:y1, :x1, :x2, :y2]
5:[:y1, :x1, :y2, :x2]
6:[:y1, :y2, :x1, :x2]
7:[[:x1, :x2], :y1, :y2]
8:[:y1, [:x1, :x2], :y2]
9:[:y1, :y2, [:x1, :x2]]
10:[[:x1, :y1], :x2, :y2]
11:[[:x1, :y1], :y2, :x2]
12:[:y1, [:x1, :y2], :x2]
13:[:x1, [:x2, :y1], :y2]
14:[:x1, :y1, [:x2, :y2]]
15:[:y1, :x1, [:x2, :y2]]
16:[[:y1, :y2], :x1, :x2]
17:[:x1, [:y1, :y2], :x2]
18:[:x1, :x2, [:y1, :y2]]
19:[[:x1, :x2, :y1], :y2]
20:[:y1, [:x1, :x2, :y2]]
21:[[:x1, :y1, :y2], :x2]
22:[:x1, [:x2, :y1, :y2]]
23:[[:x1, :x2, :y1, :y2]]
=> nil

全部で23個ありますね。

上の論理式で表される、各々のケースについて、 overlapped? を評価した結果を付与したいと思います。

def gen_implication(src_a, cond_a)
  res_a = []
  src_a.each do |exp|
    res_a.push([exp, cond?(exp, cond_a)])
  end
  res_a
end

ついでに、シンボルの配列として表現されている論理式を、文字列に変換するメソッドも用意しておきます。

def print_exp(exp)
  res = ''
  exp.each do |term|
    res += ' < ' if res != ''
    if term.instance_of?(Array)
      res += "#{term.join(' = ')}"
    else
      res += "#{term}"
    end
  end
  res
end

以下を実行して、評価結果を得ます。

irb(main):022:0> i = 0; gen_implication(apply_cond(gen_norder([:x1, :x2, :y1, :y2]), [:x1, :x2, :y1, :y2], ['x1<=x2', 'y1<=y2']), ['overlapped?(x1, x2, y1, y2)']).each {|v| puts "#{i += 1} : #{print_exp(v[0])} : #{v[1]}" }; nil
1 : x1 < x2 < y1 < y2 : false
2 : x1 < y1 < x2 < y2 : true
3 : x1 < y1 < y2 < x2 : true
4 : y1 < x1 < x2 < y2 : true
5 : y1 < x1 < y2 < x2 : true
6 : y1 < y2 < x1 < x2 : false
7 : x1 = x2 < y1 < y2 : false
8 : y1 < x1 = x2 < y2 : true
9 : y1 < y2 < x1 = x2 : false
10 : x1 = y1 < x2 < y2 : true
11 : x1 = y1 < y2 < x2 : true
12 : y1 < x1 = y2 < x2 : true
13 : x1 < x2 = y1 < y2 : true
14 : x1 < y1 < x2 = y2 : true
15 : y1 < x1 < x2 = y2 : true
16 : y1 = y2 < x1 < x2 : false
17 : x1 < y1 = y2 < x2 : true
18 : x1 < x2 < y1 = y2 : false
19 : x1 = x2 = y1 < y2 : true
20 : y1 < x1 = x2 = y2 : true
21 : x1 = y1 = y2 < x2 : true
22 : x1 < x2 = y1 = y2 : true
23 : x1 = x2 = y1 = y2 : true
=> nil

感想とか考察とか

このネタはずいぶん前に仕込んでいたのですが、これって何か意味あるのかなあ、と悩んでしまいまして。つまり、「解答」と「検証」の間に、何か本質的な違いがあるのかと。同じことの、単なる言い換えにすぎないようにも思えるのですよね。

しかしまあ、同じことを違う表現にしてみて、結果が同一になることを確かめる、というのは検証の本質ですかね。例えば、テストなんてのは、抽象化された形で表現されたプログラムに対し、具体的な入力出力の組で表現されたテストケースによって、プログラムの意図と、テストケースが一致するかを確かめるわけですしね。その意味では、上で行なっている検証というのは、具体的な値を使ったテストケースと、プログラムそのものとの中間表現にあたりますかね。

あまり便利という感じがしないのが残念ですが。結局、上のプログラムも検証も、”重なり”という概念の定義を確かめる以上のものではないわけでして、これ以上の簡単化はなさそうにも思えますね。

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

2008年5月20日 (火)

天国と地獄、または、この道はいつか来た道

なんでそんなに医者通いさせるのか不思議に思っていたところ、母親から理由を聞いてちょっと複雑な気持ちになりました。

「練馬区では15才までの子供は医療費が全額助成、つまりタダになったからよ」

老人医療ばかり騒がれているが、子供医療の「不平等」な現実はどう? (木走日記)

それもこれも、無料化が悪いんだと思う。ハンバーガーとステーキがどちらも無料なら、たいていの人はステーキを求める。それが当たり前になれば、無料でフルコースが出ないのはおかしい、となる。そもそも小児科医がいない。なけなしの小児科医を酷使してさらに減る悪循環。

政治の人は現状を見ずに、少子化対策と言って、無料化する。

小児科無料化で起きること (haohao_xの日記)

医療費無料化が利用者のモラルハザードをもたらす、ということは、1973年の老人医療費無料化で、「実験済み」なのですよね。当時、行き過ぎた受診、病院待合室のサロン化、社会的入院など、マスコミに取り上げられて、大々的にネガティブ・キャンペーンが行なわれたようでして。それが、現在の療養病床削減や、後期高齢者医療制度を支持する世論を、いくらか作り上げているようにも思えます。

そうしますと、小児医療無料化の果てには、マスコミが次のようなキャンペーンを行なうかもしれませんね。

「バカ親のあきれた受診実態!! 〜 医療を崩壊させる親たち」

もっとも、小児科というのは、もともと不採算の診療科のようですし、財政に与えるインパクトは小さいのかもしれません。老人医療費無料化のときには、医療費増大が政府に問題視されたがゆえのマスコミのキャンペーンでしょうし、財政的なインパクトが大したものではないのなら、政府も問題視せず、マスコミも取り上げないかもしれませんね。

ただ、医師が去っていくことで、崩壊が進むばかりでしょう。今の子供達が親になる頃には、わが子を医師にかからせたくとも、かからせられなくなっているかもしれません。親の因果が子に報う、というのとは少し違いますが。

昔老人で今小児、というわけですが。もともと、医療を最も必要とするのが、老人と小児・乳幼児ですからね。両者の医療制度が崩壊すれば、国民医療の崩壊といって良いのではないでしょうかね。

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

2008年5月17日 (土)

詳細仕様がどうでも良ければ詳細設計書は要らない

ということなのかもしれないですね。結局。

とくにWebアプリ開発だと、ほんとに「プログラミングレベルの設計書」までくると、一切要らない、と思うことも多い。ので、勘違いがよりいっそう発生しやすそうというか。で、そうであっても、すべての画面設計図にすべてのシーケンス図をつけてすべての入出力値を、みたいな超細かい設計書が要らんってだけで、シーケンスやなんかは絶対絶対、考える。し、紙に書いたりもする、Webアプリであっても最低限の「設計」はしないといけない。

プログラミングファースト開発でも「設計」は必要 (歩きつづける ゆり 咲きつづける)

私は、工学計算的なアプリを手がけることが多いのですが、”プログラム設計書”には、画面、帳票、DBの各項目ごとに、以下のようなことを書いてます。

  1. 単位
  2. 精度
  3. 丸めの方法
  4. 計算式、 計算方法
  5. データの取得方法

項目の数は、”中規模”のもので数百くらいはありますので、設計書の厚みも相当なものになりますね。実際、「これ(設計書)って、プログラムそのものじゃないですか」なんて言われたこともあったりします。

しかしねえ、現実問題、これをやらないと計算結果が正しくならんのですよ。

この手のアプリというのは、あるフェーズで計算した結果を、次のフェーズで使う、という構造を持っていて、入力出力が連なっているんですよね。そうすると、すべての項目の計算がすべて正確に”仕様どおり”でないと、正しい結果は得られないわけです。当たり前の話ですけど。

単位についての思い出

昔、画面作成を外注して、納品されたものを確認していたら、単位の表示に大量の間違いが見つかりまして。

"kl(キロリットル)"と”l(リットル)”を間違えるって... 千円と百万円を間違えて平然と提出してくる、コイツらの神経が信じられん...

という心情でしたねえ。顧客がアプリ使って、計算結果が1,000倍になって出てきたら、仰天しますわな。世の中には、絶対に許されない誤字というのもあるんですよね。数字というのは、まさにそれ。

データの取得方法

これは、計算方法と関係してきます。画面とDBテーブルとに単純に対応が付いたりはしないですね。

「DBのこのテーブルからこうやって取った値を、この計算式のこのパラメータに代入し、計算して画面に表示」

といった感じです。

テーブルからの取り方というのも、一筋縄ではなかったりしてね。

イベント 測定日時 測定値
A 4/1
B 4/2 51
B 4/3 53
C 4/4
A 5/1
B 5/2 62
B 5/3 64
C 5/4

センサーなんかで採った、イベントと測定値が時系列にはいっていて、測定日時が Ai < Bi,j < Ai+1 を満たす、 最も日付の新しい Bi,max の測定値を取得するとか。ある条件を満たす場合には、二番目に新しいものとか、まあ、そんな感じのがあります。

Webアプリって何?

Webアプリというのは、システムの方式であって、アプリの内容を指す言葉ではないですよね。例えば、JAXAのサイトには、軌道計算をしてくれるWebアプリがありますけど。

軌道情報提供サービス (JAXA)

これを、プログラム設計書なしで作れるプログラマって、普通にいますかね?

結局

簡単なアプリ、定番のアプリなら、プログラム設計書がなくても作れる、ということでしょうかね。私はそういったものを手がけたことがありませんので、いまいち、どんなものなのか想像がつきませんけど。顧客がわざわざ高くつくスクラッチの受託開発を依頼してくる、ということは、”簡単じゃない”、”一筋縄ではいかない”ということだと今まで考えていました。

設計書が必要かどうか、というのは、設計書の”粒度”の問題だけでなく、そもそも何のアプリを作るのか、によっても全く話が違ってくるのでしょうね。

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

2008年5月14日 (水)

ATMが多すぎるわけですが

三菱東京UFJ銀行は十二日夜、ゆうちょ銀行など六つの提携金融機関に口座を持つ顧客が、旧東京三菱のATMから入金できないトラブルが二百六十二件起きたと発表した。この日から始まった同行のシステム統合では、セブン銀のATMで引き出しなどができなくなる障害が約二万件起きている。世界最大級の新システムへの移行が初日からつまずき、同行は統合計画の再点検を迫られる。

「三菱UFJ銀 新たに入金でも障害」, 日本経済新聞, 2008年5月13日朝刊4面

セブン銀行に代表される、いわゆる「コンビニATM」ですとか、ゆうちょ銀行、証券会社のATMなど、ATMが多すぎて手に負えない、ということなのかもしれない、と思ったのですが。邦銀はサービス過剰にすぎて、逆にリスクを負っている、なんて。

冷静に考えれば、今はATMなんてどこにでもあるわけですから、一部が使えなくなったからといって、全く銀行取引ができない、などということにはならないですよね。最後は銀行窓口という存在があるわけですし。

重要な社会インフラを担うシステムというのは、たった数秒の停止でも大変な影響を社会に及ぼします。 ATMというのもまさにその一つであり、今回、朝9時から11時55分頃まで復旧できなかったために、2万件以上の取引(預金・引き出し・自動振替等)が成立しなかったことが明らかになっています。

これが鉄道の管制システムであれば、たった数分間システムが止まっただけで、衝突によって多くの人命を失うという事態も十分起こり得えます。これはあってはならないことであり、だからこそ、些細なミスも見逃さないような鉄道各社は手厚い体制を敷いているのです。

障害発生が「当たり前」という銀行システム統合、本当にそれでいいの? (情報インフラ24時 眠らないシステム)

「顧客への影響」という点からすれば、今回のシステム障害は、せいぜい「ダイヤの乱れ」といった程度のものではないでしょうかね。

鉄道が一時的に運行を停止することは、まあ、首都圏では毎日といっていいくらい日常的に起きているわけでして。鉄道の運行停止は、「当たり前」という感覚になってしまっていますよね。鉄道の運行が数秒ても停止すれば、社会に大変な影響を及ぼすので、大問題なのでしょうか? 確かに、朝のラッシュ時に鉄道が止まるのは、銀行のATMが止まるよりも大変かもしれませんけどね。

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

Java言語の位置

もともと、Java言語が狙っているのは、 C/C++ のポジションだと思うのですよね。確か、当初は組み込み分野で使うことを考えていたのではなかったか、と以下の記事を読んでいて思い出したわけですが。

Real-time response is a requirement in Java application domains such as banking, online collaboration, and games development, as well as for safety critical applications used in hospitals, manufacturing, aviation, and emergency response systems. Unfortunately, the Java platform has long suffered from its erratic response time. Java applications are known to freeze because the garbage collector has "stopped the world." Incremental garbage collection (-Xincgc) improves this situation, but it does not completely eliminated the nasty "full GC" pauses associated with the Java platform.

To further complicate things, Java program execution also can suffer from unexpected delays caused by Just-In-Time (JIT) compilation, class initialization, or standard utility collections internally resizing.

Realistically real-time: Real-time Java application development using multicore systems (Java World)

言語設計者の意図に反して、Java言語は、むしろ、エンタープライズ分野やWebアプリで広く使われるようになったわけですが。Java言語が目指している位置は、システムプログラミング言語であって、エンタープライズ分野とWebアプリは、Java言語が目指していた方向とは違うのではないか、と思うわけです。

こんなことは Java ではいたるところに存在していて、たとえばテキストファイルひとつ読み込むのも FileInputStream と InputStreamReader (と BufferedReader) を組み合わせて書かないといけない。だいたい、なんで FileReader では文字コードを指定できないのか、理解に苦しむ。

「怠慢はプログラマの美徳」というけれど (kwatchの日記)

FileReader で文字コードが指定できない理由というのは、 もともと”文字を読む”という発想がなかったからでしょうね。 『プログラミング言語 Java 第4版』 ”20.3.3 文字ストリームと標準ストリーム” によりますと:

標準ストリーム System.in、 System.out、 System.err は、文字ストリームが導入される前から存在しています。したがって、論理的には文字ストリームであるべきですが、標準ストリームはバイトストリームです。

p.448

もともと、Java API には、文字ストリームは存在せず、バイトストリームしかなかったみたいですね。このあたりに、InputStream と Reader との関係が煩雑になった事情がありそうです。 言語設計者の意識は、テキスト・データより、バイナリ・データの方に向いているように思えますね。

Java言語の設計者は、エンタープライズ分野やWebアプリには、あまり興味はなさそうな感じですよね。今後も、Java言語が、エンタープライズ分野やWebアプリに特化する、ということはないでしょうね。やはり、システムプログラミング言語を目指し続けるのではないでしょうか。

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

2008年5月12日 (月)

テストはいつでも不足する

三菱東京UFJ銀行の一部キャッシュカードが、5月12日の午前7時から約5時間セブン銀行のATMで使えなくなった原因が分かった。三菱東京UFJ銀のシステムからセブン銀のシステムに送信する取引結果データの文字コードに誤りがあり、セブン銀のシステムが取引結果を正常に処理できなかった。約2万件の取引が影響を受けた。

【略】

切り替え作業に先駆け、三菱東京UFJ銀は100万件以上のテストを消化している。社外との接続テストも、100以上に及ぶすべての相手先との間で実施した。仮にコード変更の伝達漏れがあったとしても、条件に合うパターンをテストしていれば、そこで不具合が見つかったはずだ。

三菱東京UFJ銀の一部障害、直接の原因は文字コードの設定誤り (ITpro 2008/05/12)

三菱東京UFJ銀行のシステム変更で発生したトラブルについて、セブン銀行・安斎隆社長は「はっきり言うとテスト不足。それだけです。システムを変えた時に、変えたところを明確にしてテストしないと。システムを変えるのは向こう(三菱東京UFJ銀行)ですから」と述べ、三菱東京UFJ銀行側を批判した。

テスト不足...セブン銀社長がトラブルを批判(日本テレビ系) (Yahoo!ニュース 12日21時19分更新)

今度は、100万件という数字が出てきましたね。

log2 1,000,000 ≒ 19.932

8万件でも100万件でも、大きな差はないというところが、恐ろしいわけですが。

別の人(研究者ではなく実務家)の意見書には「 テストでは不具合は防げない 」とあったとのこと。静的検証や形式的手法の研究者は(下っ端の私も含め)よくいうセリフですが、一般的認識になりつつあるのでしょうか...?

テストでは不具合は防げない (sumiiの日記)

テストでは不具合は防げない、というのは、少なくとも技術者の一般的認識としてはあるのではないでしょうか。人力で確認できる範囲というのは、起こり得るケースの母集団に比して、あまりにも小さいですし。テストで確認できない不具合というのもありますから。

では、どうすれば不具合が防げるのか、といいますと、不可能であると答えるしかないわけでして。

今回のシステム障害なんて、ディスコミュニケーションが原因で、そもそも仕様を認識していなかったという話でしょう。であれば、テストを行なうはずもなく、まず見つからない不具合でしょうね。セブン銀行のコメントは、かなり他人事ですから、当事者意識のない相手に、深いところで協力を得るのは難しい、ということなのかもしれません。

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

2008年5月11日 (日)

価格メカニズムによらない市場

何でしょう? ちょっと、意味がわかりませんでした。

市場回すのにどうしても欠かせないのが、「命の値段」。疾患ごと、状況ごとに、病院が患者さん側に支払うべき「標準価格」みたいなもの。こればっかりは、政府の代表者に決めてもらわないといけない。

今はまだ、誰も「命の値段」をつけようなんて思ってないみたいだし、裁判所が決定するそれは、残されたご家族の心情とか、病院側の態度とか、もっと個人的な状況が「価格」に反映されるみたいだから、そんな流れの先に「市場」は見えない。

安全の市場化 (レジデント初期研修用資料)

市場メカニズムというのは、価格決定を通じて、需要と供給が調整される過程をいうのですよね。価格が固定されると、市場は機能しないように思えますね。素直に読むとですが。

この場合、「命の値段」というのは、医療訴訟で賠償額に上限を付けるとか、あるいは、無過失補償制度のようなものを指しているのでしょうか。

また建設業の話になりますけど。例えば、建築基準法ですとか、土木示方書といったものは、建設物が満たすべき最低限の”安全性”というものを決めていますよね。技術者がやるのは、その”安全性”をぎりぎりクリアするような設計を作り出すことであったりします。

当然のことながら、安全性とコストは正比例する関係にあるわけでして、安全性を高くすれば、コストも高くなるわけです。業者は市場原理のなかで、価格競争をやっているわけですから、”安くつくる”が至上命題でして、安全性というのは、最低限でなければなりません。この最低限の安全性を政府が定めるということは、やはり必要なことでしょうね。例え建設物が崩落したとしても、基準をクリアしている限り、業者が法的責任を負うことがない、ということを担保できるわけです。

とはいえ、昨今の耐震偽装騒動をみるに、このやり方も完全ではないですけどね。価格競争が行き過ぎれば、やはり良心よりパンをとる業者は出てきます。また、業者が一定の範囲で免責されるかわり、基準を作る政府が責任を負うことになっていますが、政府といえども負えない責任はあるわけでして。国庫も無尽蔵ではありませんから。政府が到底クリアできないような基準を作る、という事態は起こりえますね。

医療市場を回すのに必要なのは、やはり法的責任が免責されるような基準を政府が作ること、のようにも思えますね。医療という分野でこれが可能なのかどうか、というのはわかりませんけど。建物の強度みたいに、明快な数字は出てこないでしょうし。

まだ東京大学で先生をしていたときのことである。筆者は東京女子医大の先生たちと、鼓膜の力学的特性についての共同研究をしていた。そこでとても驚くことがあった。ナント、言葉が通じないのである。といって、医者は日本語を話さないということではない。「数(かず)」を全然使わないで議論をするのである。

たとえば、人の体を対象として扱うとしよう。こういうとき、筆者たち技術屋はまず、「体温36.5℃」とか、「鼓膜の張力31.3mN(ミリニュートン)」といった「数(かず)」で表わす。「数(かず)」で表さないことには、工学的な思考の対象にならないからである。ところが、医者の世界は違うのである。「温かい」とか「冷たい」、「固い」とか「やわらかい」といった、非常に感覚的な言葉で表現するのである。

畑村洋太郎 著, 『数に強くなる』, 岩波新書(新赤版)1063, 2007

何か、コンピュータ・ソフトウエアの世界とだぶりますけども。個々の事例での違いがありすぎると、使える数字はなかなか出せない、ということかもしれません。数字が出ない、というのは、議論の説得力という面で、なかなか苦しいことになるわけですけどね。

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

SI産業の国際競争力とか

”国際競争力”という言葉は、経済学者のクルーグマン氏が、”空港経済学”と揶揄した、トンデモ経済学で使われている用語のようでして。確かに、何を意味しているのか、さっぱりわからなかったりします。私達の業界では、バズワード buzzword と呼んでいますね。

でね、思うわけさ、世界だ何だっていうけど、いや別に安けりゃいいってわけでもないんだろうけどさ、本気で我々が見積もった数字が一番安い上に提案の内容についても質が一番高かったってことはさ、そんなにいうほど世界は遠くないよね、と。日本でトップレベルになれば十分に世界でも通用するんじゃないのかな。少なくとも我々程度でさえここまでやれるんだから。

世界レベル (はぶにっき 2008-05-10)

日本でシステム開発を行なうのであれば、中国企業、インド企業、どこの国の企業でも、コスト面で大きな差が出るとは思えないんですよね。日本のSI企業というのは、日本市場に過剰適応しているわけですし、まあ、ホームグラウンドで負ける、ということはないんじゃないかと思うわけです。長年の価格競争で、価格も10年前ぐらいから考えると、半値以下くらいにはなっている感じですしね。

日本市場に過剰適応していることの良し悪し、というのはあるでしょうけど。グローバリズムという言葉も、かなり胡散臭いですし。”ガラパゴス鎖国”とかいっても、世界の富の90%を所有する1%の人口のなかで、世界第2位の規模をもつ経済が、”ガラパゴス”なんていえるのかなあ、と思うわけでして。まあ、国内で稼ぐこと自体は、良いとも悪いともいえないことなのでしょう。

”グローバルなベストプラクティス”(笑)が売り文句であった、ERPソフトにしても、欧州と米国では仕様が異なっているようですし、日本でももちろん、”現地仕様”があるのでしょうが。企業システムの場合は、”お国事情”からは逃れられないわけでして、そもそもグローバルたりえない市場のように思えますね。

SAPはドイツで創業した企業らしく、多言語、多通貨に対応したソフトだった為、ヨーロッパ企業を中心に使用され、その中で機能を磨かれた。そして、ヨーロッパに進出していたアメリカの多国籍企業も用いる様になり、創業者の一人がアメリカに駐在し、彼のリーダーシップでアメリカのSAPを現出させた。アメリカで不要の部分は、ばっさり削除。アメリカ人に使いやすい様に作り直したお陰で、アメリカのR/3は他国のR/3と、厳密に見れば、同じものではない(私が知っているのは1998年頃まで)。

日本は、ドイツからの進出で立ち上げたマーケットだったが、ちょっと米欧とは様相を異にした。ヨーロッパでは痒いところに手が届くソフトとして、またアメリカでは今までのソフト(SAPはレガシー・システムと呼んだ。遺産のシステムということで、不遜も甚だしい【笑】)を新世代のハードに対応させるのと較べて圧倒的なコスト・パフォーマンスで売った。しかし、日本では、幻想に過ぎない夢を欧米でのブランド力で販売し、その価格たるや、ライセンス料は欧米と大差なくとも、人件費が欧米に比し、べらぼうな高さだった。機能的に自国に合致していないのに、そのギャップをBPRの名の下に一方的にソフトの方に合わさせ、かつ価格は他国よりも高い。日本仕様の開発費用を賄おうとの意図があったのかも知れないが、多国籍企業として他国企業と競おうとしてR/3を導入した企業は、そのことだけでも他国企業に遅れをとった事を意味した。同じ製品をより高く買ってしまったのだから。

ワークスアプリケーションズとSAP【日本のERP業界】 〜その1〜 (黄色い豚、麗(レイ)豚 @日立柏酒場裏)

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

2008年5月10日 (土)

ソフトウエア工学は工学的になれるか

”ベンチマーク”という言葉につい反応してしまったのは、丁度これについて考えていたからなのですが。タイミングが良すぎるといいますか。

いや、別に「Rubyが遅い(特に1.8が遅い)」って言われても、「はぁ、そうですか」としか思わないんだけど(性能を目指して実装してないし)、パフォーマンスと言うのは非常にFUDに満ちあふれた分野であるので、誰かが「遅い」とか「遅くて使えない」と言った場合には、その真意を見極める必要がある。

Matzにっき(2007-07-07)

ベンチマーク・テストの内容が問題というのは、結局、特定のテストだけでは、ソフトウエアの”一般的な”性能を判断できない、ということなわけですが。仮にソフトウエアの一般的性能を判断することのできるテストがあったとしても、まだその先があるのですよね。

テストでAとBを比較して、Aの方が早い、という結果になったとします。それで、私達の利用目的では、Bは使えないのか、といいますと、必ずしもそんなことはなかったりするわけでして。基本的に、絶対に無理、とはいえないことが多いと思うのですよね。もちろん、極端なケースでは無理というのはわかるでしょうけど。

例えば、建築部材で、木材と鉄筋コンクリートとの性能(強度)を比較して、鉄筋コンクリートの方が優れている、といったからといって、木材は建築部材としては使えない、ということにはならないわけでして。一方で、高層建築を木材だけで建設しようとするのは、無謀ということはわかるわけです。これは、材料の強度というのが一般的な数字で表されていて、構造物の応力を計算すれば、部材が耐えられるかどうかを数字で明確に示すことができるからですよね。

工学的というのは、そういうことだと思うわけですけど。

ソフトウエアに関しては、どう考えても、そのようにはなっていないですし、当分なる見込みもなさそうです。ベンチマーク・テストというのは、そもそもそのような目的で行なわれてはいないのでしょうけど。あるソフトウエアの性能が、利用目的を満たすのか否か、というのを明確にするのが、”使える数字”ですよね。その点からしますと、現場で欲しいのは、最高性能ではなく、むしろ最低性能とか、平均性能の類ですよね。このくらいの性能は見込んでも大丈夫ですよ、という数字かと。どうやって計るのか想像がつきませんが。

現在、ソフトウエアの性能について語ると、大抵不毛な話にしかならないのは、客観的に使える数字が存在せずに、主観的にしか話せないからでしょうね。ある利用目的について、どれだけの性能があれば”十分”なのか、エンジニアの感覚しかない状態でしょう。

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

ベンチマークなんて必要ですか?

適当な意見だなー、そのシンタックスシュガーとやらをなくすとコンパイル時間が何ミリ秒速くなるんだよ。絶対ベンチ取らずに思いつきで言ってる

http://twitter.com/todesking/statuses/806986776

まあ、適当なことを言っている、というのは否定しませんけど。

言語仕様がシンプルな方が、コンパイル時間を短くできる、というのは一般論としてあるわけでして、別に私のオリジナルな思いつき、というものではないですよ。

翻訳過程での込み入った複雑さを少なくできる唯一の方法は、明確に定義され構造が整っているソース言語を選択することである。

二クラウス・ヴィルト 著, 滝沢徹・牧野祐子訳, 『コンパイラ構成法』, アジソン・ウェスレイ, 1997, p.1

原始プログラムを効率のよい目的プログラムに翻訳したいだろうし、翻訳の過程そのものも効率化したいだろう。どちらの場合にも、言語の設計が、それらの計算がどの程度簡単に行なえるかということに影響を及ぼし得る。

A.V.エイホ ・ J.D.ウルマン著, 土居範久 訳, 『コンパイラ』, 倍風館, 1986, P.25

確か、C言語の設計思想について、もっと明確に、コンパイラに楽をさせるためである、としていた本があったと思うのですが。ベル研究所の関係者が書いたもので。すみませんが、何だったか、思い出せないし、今本棚探しても見つかりません。

ベンチマークなのですが。言語設計の違いが、コンパイル時間に有意な差をもたらすかどうか、などというような研究は、私の手には負えません。といいますか、個人の力では無理でしょう。ですので、以下に示すものも”超適当”なもので、何の証拠にもなりませんよ、と前おきさせていただきまして。

Java言語の拡張for文と、従来のfor文で、コンパイル時間に差がつくか、を試してみました。もともと、Java言語には、シンタックス・シュガーなるものはほとんど存在しないわけですが(それが設計思想だと思います)、『Java言語仕様 第3版』によりますと:

拡張for文の意味は、基本for文へと変換することによって与えられる。

p.343

とありますので、拡張for文はシンタックス・シュガーである、と考えて良さそうです。

でまあ、以下のような Rubyスクリプトで、10,000個のソースファイルを2セット作りました。 Test1 は拡張for文、 Test2 は基本for文です。

#genTest1.rb
(1..10000).each do |i|
File.open("01/src/Test#{i}.java", "w") do |out|
out.print <<EOS
public class Test#{i} {

  public void test() {
    int[] a = new int[101];
    for (int i = 0; i < a.length; i++)
      a[i] = i;
    int sum = 0;
    for (int i : a)
      sum += i;
    System.out.println(sum);
  }

}
EOS
end
end

#genTest2.rb
(1..10000).each do |i|
File.open("02/src/Test#{i}.java", "w") do |out|
out.print <<EOS
public class Test#{i} {

  public void test() {
    int[] a = new int[101];
    for (int i = 0; i < a.length; i++)
      a[i] = i;
    int sum = 0;
    for (int i = 0; i < a.length; i++)
      sum += i;
    System.out.println(sum);
  }

}
EOS
end
end

こうやって作ったソースファイルを、Antを使ってコンパイルしてみます。 使った build.xml は以下のとおり。

<project name="MyProject1" default="compile" basedir=".">

<target name="clean">
<delete>
  <fileset dir="bin" includes="*.class" />
</delete>
</target>

<target name="compile">
  <javac srcdir="src" destdir="bin" />
</target>

</project>

javac と ant のバージョンは以下のとおり。

>javac -version
javac 1.5.0_14
>ant -version
Apache Ant version 1.7.0 compiled on December 13 2006

Test1(拡張for文) の結果です。

01>ant
Buildfile: build.xml

compile:
    [javac] Compiling 10000 source files to 01\bin

BUILD SUCCESSFUL
Total time: 1 minute 40 seconds

Test2(基本for文) の結果です。

02>ant
Buildfile: build.xml

compile:
    [javac] Compiling 10000 source files to 02\bin

BUILD SUCCESSFUL
Total time: 1 minute 30 seconds

ということで、拡張for文の方がコンパイル時間が10秒ほど遅くなりました。上の結果を出すのに、一応、”ウォーム・アップ”はしました(つまりそれぞれ2回ずつ実行した)。まあ、統計とって分析したわけではありませんので、この結果にたいした意味はないでしょうけど。

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

2008年5月 8日 (木)

言語の冗長さはコンパイラのためにある

もう、人間が機械にあわせる、という発想は時代遅れなのかもしれませんけど。

冗長さが除去されて言語が簡便になれば大規模開発にも役立ちます (矢野勉のはてな日記)

小クラス主義をとりますと、コンパイル単位を小さく出来る、という利点があります。コンパイル単位が小さくなれば、コードのどこかに手が入った際、他の依存するコンパイル単位も再コンパイルが必要、という事態を最小限に抑えることが期待できます。

コンパイラに型を推測させず、たとえ文脈から明らかな場合でも、型を人間が指示することで、コンパイラの負担を軽くすることができます。シンタックス・シュガーを用意せずに、人間がいちいちその”展開形”のコードを書くことで、コンパイラが余計な処理をせずにすむようになります。

大規模ソフトウエア開発では、ビルド・プロセスに何時間もかかるような、巨大なソフトウエアを開発するわけですよね。ある程度の負担を人間が引き受けることで、コンパイラの負担を軽くして、ビルドにかかる時間を短縮したい、というニーズはあるんじゃないですかね。例えば、JDKなり、Eclipseなりのソースコードを全てコンパイル/ビルドするのは、何時間かはかかる”重い”プロセスでしょうし、コンパイルが早くなれば嬉しいでしょう。

言語処理系の”性能”というのは、コンパイル後コードの実行時の性能だけではなく、コンパイル時の性能というのもありますから。コンパイラにシンタックス・シュガーを処理させるなら、その時間をコード最適化に使って欲しいというプログラマもいるでしょうね。

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

2008年5月 6日 (火)

思考の余剰

これは面白いですね。

思考の余剰の大きさについてもう少し考えてみよう。それはあまりにも大きいため、ほんの小さな変化でも大きな結果を生み出しうる。たとえば99%は変わらず、みんな今までと99%までは同じようにテレビを見るが、1%は何かを作り、公開することに使ったとしよう。インターネットにアクセスできる人々が1年にテレビを見る時間は、おおよそ1兆時間になる。アメリカにおける年間の消費時間の約5倍だ。その1パーセントは年間10,000のWikipediaプロジェクトへの貢献に相当する。

Clay Shirky / 青木靖 訳, 『ジン、テレビ、社会的余剰』, 2008年4月26日

社会が豊かになって、人々が多くの余暇を持つことができるようになった、さてその余暇を何に使っているか? ― テレビを見ている、という話は有名ですね。どこか皮肉な話でもあるわけですが。インターネットによって、もう少しマシなことに余暇を使うようになるのか、興味のある話です。

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

2つの科学

あるものが科学ではないといったところで、そこに何かあやまりがあるということにはならない。単に科学ではないというだけのことである。

坪井忠二 訳, 『ファインマン物理学 Ⅰ』, 岩波書店, 1986, p33

もともと、科学には2つのベクトルが異なる潮流があるようでして、それは、ガリレオが『新科学対話』で対置した、”新科学”と”旧科学”であるようです。”旧科学”というのは、ガリレオの著作では、”アリストテレス主義”と呼ばれているようです。これは、思弁と演繹的論理に重きをおき、実験・観測といった帰納的、あるいは技術的な方法を否定する ―― アリストテレスに言わせると”奴隷の仕事”  ―― もののようです。

レオナルド・ダ・ビンチの『絵画論』には「経験から産み出される知識は機械的 (meccanica) で、精神から生まれた知識は科学的 (scientifica) である」とある。つまり当時は機械的技芸と自由学芸の対比に経験と精神の対比が投影され、「経験」が頭脳の働きをともなわないもの、理論を欠落したものとして、精神すなわち思弁の下位に置かれていた。

山本義隆 著, 『16世紀文化革命 1』, みすず書房, 2007, p.17

同書によりますと、”機械的 (meccanica) ”というのは、 「手でおこなわれる」、「頭をつかわない」といった意味があり、「奴隷のする下賤な仕事」というニュアンスで使われていたとか。

少なくとも、16世紀西洋において、科学という言葉は、アリストテレス的な”旧科学”を指していたわけでして、その内容は、プラトン、アリストテレス、エウクレイデス、プトレマイオス等の、古代ギリシャ・古代ローマのラテン語文献の文献学であったようです。また、当時、教養という言葉の指すものも、こうした文献であったそうで。これは、ルネサンス ―― ”文芸復興”、という名で知られる動きでもあります。

同時期に、印刷技術が発達したことにより、芸術家や職人、技術者といった、”庶民”の人々が、自らの経験から得られた知識を、ドイツ語、フランス語、英語等の”俗語”によって記し、出版して公開するといった動きが起こったのだそうですが、こうした”経験知”の公開が、”新科学”の樹立へと繋がっていったようです。ガリレオが地動説を”発見”する過程というのが、望遠鏡の製作という、当時下賤と考えられていた、”手仕事”に始まったのは、注目すべきことでしょう。

”新科学”では、”旧科学”が軽んじ、蔑んでいた、”経験知”を積極的に取り入れ、仮説を実験や観測によって、帰納的に実証する、といった手法に重きを置くようになります。その後、”新科学”、すなわち近代科学は大きな成果をあげることになり、現代では、科学といえば、こちらを指すようになっているわけです。

我々の見方からすれば、数学は自然科学ではないという意味で、科学ではない。数学の正否をためすのは実験ではない。

坪井忠二 訳, 『ファインマン物理学 Ⅰ』, 岩波書店, 1986, p33

しかし、アリストテレス主義的な考え方というのも、根強く残っているようでして。

それは、たとえば、「問題の純粋に知的な側面よりも視覚的な側面」だとか、「研究者の中には、人間の個性において言葉の側面に匹敵する重みを、知的にはずっと劣る側面に与えたがっている者がいる」とかである。このような表明のあるものは、自信に満ちたお偉い方々のあからさまな言明であり、また別のものは、心眼によるイメージよりも言葉のほうが本質的に優れているという、学者たちの無意識のうちの前提を覗かせてくれる窓になっている。

E・S・ファーガソン 著, 『技術屋(エンジニア)の心眼』, 平凡社, 1995, p.66-67

「言葉による思考」に最高の地位を与えたのは、まさしくアリストテレスその人であったように思います。こうした考え方は、古代ギリシャの哲学から、16世紀の”旧科学”を得て、現代にも受け継がれているのでしょう。

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

2008年5月 4日 (日)

アジャイルコントラクト、系列取引、競争入札

ICSEのセッションの1つで、agile contractsの例としてトヨタとサプライヤの良好な関係について語られていた。トヨタがbest contractorとして挙げられ、サプライヤとのwin-winの関係を築いていること、信頼を基本とした共通のゴールをサプライヤと作れているところ、契約を必要以上に細かく作りこんだり、責任を必要以上に細かく分類していくことは所詮ゲームに過ぎないということを認識しているところ、において優れていると述べられていた。スピーカはMary Poppendieck氏。

アジャイルコントラクト (森崎修司の「どうやってはかるの?」)

トヨタという会社は、日本の伝統的な系列取引から、最大限、利点を引き出しているのかもしれませんね。

私は、いまだ、競争入札というものが、うまく機能するものなのか、疑問に思っていまして。おそらく、ポイントは、”情報”なのでしょうね。発注側が案件について、完全に情報をコントロールできる立場にあれば、競争入札というのは、理想的に機能して、品質はそのままで価格低下という果実が得られるのでしょう。

しかしながら、現実はそうではないわけです。

やはり日本の顧客は特徴的で面白い。

・要求仕様があいまい

・業務分担があいまい

・契約があいまい

・パートナーといいながら、下請け

・発注主は殿様。下請け間でよきに計らえ

である。

日本企業はやっぱり違う (住みたいところに住める俺)

こうしたことを長く続けると何が起きるか? といいますと、発注主の”番頭”的な業者が出現するわけです。その業者は、発注主の様々な案件について、熟知しており、発注主が何もせずとも、案件を取り回せるような存在です。そして、発注主はすべてを”番頭”に委ね、自分では何もしなくなり、また、できなくなります。

こうした業者が、談合組織のリーダーになるまでの過程はだいたい想像ができるのではないですかね?

”番頭”以外の他の業者が、その発注主から案件を受託するとします。案件の仕様詳細等の情報は、発注主からは得ることができません。”番頭”からもらう必要があるわけです。しかし、"番頭”にしてみれば、他の業者に情報をくれてやる道理は何もないわけでして。実際、ライバルに好んで塩を送ったりはしないでしょう。ここで、ある種の”取引”が行なわれるわけですよ。

一方で業者間で競争せよといい、他方で業者間で協力せよというのは、もともと矛盾しているわけでして。競争を最重視するのならば、協力は諦めるしかないのでしょうね。

まあ、どのような契約形態を選ぶにせよ、発注主が情報をコンロトールできるようにしておくことは重要なことでしょう。件のトヨタにしても、”ブラックボックスを作らない”というのが信条であったかと思います。

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

”自然が一番”とか

ある宣言 - 新小児科医のつぶやき のコメント欄より。産科の苦境に関連して、ときどき、出てくる話題のようですが。

日本での分娩はなぜ『手なりでマージャンを打つ』ような自然分娩ばっかりなんでしょうか?シンガポールでは(他の海外でもそうらしい)、計画出産が常識化しています。分娩を9時ー17時のレンジに入れるよう、出産予定日の前日の夜に入院し、翌日全スタッフ(麻酔医などの専門医たち)の揃っている時間帯に出産させています。これだと、万一緊急事態が発生しても、助かるリスクが上がる、というのが理由の一つで、もう一つはお産のために夜中にスタッフを取られない=>他の事故などの対応に人的資源を振り分ける、という意味合いがあるそうです。

tora さん (2008/05/04 17:47)

計画出産はおっしゃるような合理的な思考は無視され、「医者の都合で分娩時間を決められてしまう。赤ちゃんの誕生日が決められてしまう。」とのたまう患者の家族団体がいてこれがねえ 結構世論を引き付けています。産科医個人が疲労困憊の末に起こってしまう不測の事態というのは本邦の国民の理解を超えています。

Bugsy さん (2008/05/04 18:24)

”自然が一番”とかのたまう方々にお勧めの書籍は、文学ですと、『蠅の王』とかですかね。 山本七平氏 『日本はなぜ敗れるのか − 敗因21カ条』 をあわせて読むとベターかもしれません。

... 「餓鬼」の絵に描かれている「者」の、あの独特の目つき、挙止、体形は、すでに人間のものではない。ああいう相貌を描いた人こそ、本当のリアリストであろう。

だが人間はなかなか本当のリアリストにはなれない。そのため、あの「餓鬼」の絵は空想の産物と思い、一方では平気で「自然に帰れ」などといい、そしてそういうスローガンを掲げれば、本当に自然に帰れると思っているらしい。そのくせ、ピアフラの写真を見て、「かわいそうだ」という。これはまことに奇妙で、空想的というより妄想的、支離滅裂的発想である。

そしてそういうことをいう人の話を聞いていると、言っていることは結局、現代の資本主義的生産物の恩恵だけは十分に供与されながら、自然的環境の中で生活したい、簡単にいえば、自然的環境の中で冷暖房つきの家に住み、十分な食糧と衣料がほしい、ということにすぎない。

だがそれは、最も不自然な生活だから、それを自然と誤解しているいまの日本人が本当に自然状態に帰らざるを得なくなったら、おそらく全人口の七割くらいは、生存競争に敗れて死滅してしまうであろう。自然には、人間を保護する義務はない ――― ということは、自然状態にかえった人間も、ほかの人間を保護しないということである。

山本七平氏, 『日本はなぜ敗れるのか − 敗因21カ条』, 角川書店, 2004, p.236

フィリピンはルソン島で、”自然に帰る”ことになった日本軍の兵士たちは、食糧を手に入れるために、現地でありとあらゆる犯罪を犯した末、友軍同士互いに殺し合い、その肉を食うという行動へと追い詰められるわけでして。結局、人間が人間でいられるのは、文明の中にあってこそで、”自然に帰った”人間はもはや人間ではない、ということでありましょう。

人間はもはや自然に帰ることができないことを知っているがゆえに、自然に対し憧憬の念を持つのでしょうけどね。ノスタルジーはノスタルジーのままにしておくべきでしょう。

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

2008年5月 3日 (土)

結局”スクリプト言語”って

メインフレームでいうところの、JCLのことだったり。

Job Control Language(JCL、ジョブ制御言語)とは、IBMメインフレームコンピュータで使われるスクリプト言語である。バッチ処理をどのように動かすか、サブシステムをどのように起動させるかを、ジョブエントリーシステム(Job Entry Subsystem 2/3、JES2 または JES3)に対して指示するものである。

”Job Control Language”,  Wikipedia, (2008/4/24)

昔は、コンパイラとインタプリタというのは、役割が明確に分かれていたのでしょう。最近は、というほど最近でもないかもしれませんが、大抵のプログラミング言語は、コンパイルもできるし、インタプリタとしても動かせるようになっていますからね。

計算機リソースを潤沢に使えるようになって、両者の役割が区別できなくなってきている、ということかもしれません。

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

プログラム仕様書の"あいまいさ"

工学分野の図面は図形による言葉で書かれており、その文法と構文法は実際に使うなかで学ばれる。そこには伝授を受けた者にしか理解できない慣用的表現(イディオム)もある。 ...

図面は正確であいまいなところのないもののように見えるけども、その厳密さの背後には、多くの公式に則らない選択や言葉では表せない判断、直観の働き、そしてあらゆるものの作動の仕方についての仮定が隠されている。設計者と製作者の双方を結びつける、アイデアを人工物に変える過程は、複雑で微妙なものであり、どんな場合でも、科学よりは芸術に近いといえるのではないだろうか。

E・S・ファーガソン 著, 藤原良樹 砂田久吉 訳, 『技術屋(エンジニア)の心眼』, 平凡社, 1995, p.16-p.171

プログラム仕様書というものは、必然的に”あいまいさ”を含むものであるわけでして、”あいまいさ”をなくすことはできないでしょうね。

”あいまいさ”のないプログラム仕様書というのは、プログラム・コードそのものとなってしまうでしょう。そうしますと、そもそもプログラム仕様書を書く意義も失われてしまいますよね。プログラム仕様書に”あいまいさ”があるがために、人間がプログラム仕様書を読んで、解釈を行い、機械可読な形とする工程が存在するわけでして。

プログラム仕様書から”あいまいさ”を排除する、というのは、正しい方向の努力ではありません。”あいまいさ”を許容範囲内に収める、というのが正しい努力であるといえるでしょう。

しかし、”あいまいさ”のレベルというのは、形式的に定義を与えることはできそうにないですね。ソフトウエア開発に携わる人々の間で、暗黙知として、業界の常識として、共有するような方法しかないでしょう。未だにこうしたものが業界内に存在していないのは、要素技術が大きく変わっているからですかねえ。表面的には大きく変わっているように見えますが、本質的には、あまり変わっていないとも思えるのですけど。

例のプログラム・コード”そのもの”の仕様書の話ですが。

確かに、プログラム・コードと完全に同じであるのなら、作る意味は全くないでしょう。私は、そうした仕様書を納品物として求められた経験はありますけど、コーディング工程に先立つ設計工程で作ったことはないです。納品物に必要な場合は、プログラム・コードからツールで自動生成していました。これは、誰も読まない類の、形だけの資料でして、当然レビューなんかしません。

そうした資料を、設計工程で作るようにしているところがあるとしますと。なんとなく、そうなるにいたった経緯は想像がつきます。とんでもなく劣悪なプログラムが業者から納品されたことがあって、それで大変な目にあったことがあるんじゃないですかね。そのときの、業者の言い訳に、”仕様書があいまいだから”というのが含まれていたであろうことは、想像にかたくないです。私も経験ありですが、真に遺憾ながら、そうしたことが往々にして起こる業界ではあります。


1.

技術屋(エンジニア)の心眼 Book 技術屋(エンジニア)の心眼

著者:E.S. ファーガソン
販売元:平凡社
Amazon.co.jpで詳細を確認する

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

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