« 2007年9月 | トップページ | 2007年11月 »

2007年10月27日 (土)

契約形態と開発手法との密結合

なるほど。そういう視点もありましたか。外部設計書ガイドライン に関して。

進行基準ではプロジェクトの進捗状況に合わせて売上を計上するが、その進捗状況はコストで測る。従って、事前に原価総額を正確に見積もれなければならない。外部設計が確定していないと正確な原価総額なんか出せないから、要件定義や外部設計をいい加減にやっていると、システム開発の売上計上ができないなんていう事態にもなりかねない。

これからは仕様を確定させてからでないとシステム開発は不可能です:東葛人的視点:ITpro

つまり、外部設計書について、”業界標準”を作ろうという動きは、進行基準会計を見据えての動きであるという見方です。

しかし、これで、ウォーターフォール型の開発プロセスと、企業会計が密に結合することになりそうですね。別にこれで、アジャイル開発手法を採用できなくなる、というわけではないでしょうけど。開発プロセスと会計が密接に関係するようになりますから、開発プロセスを変更するということは、SIerの企業会計を変更することにつながり、開発プロセスを変えるのは、ますます難しくなりそうです。

しかし、仕様を確定させてからシステム開発へ、というのが、仮に可能だとしても、契約プロセスの問題は残るでしょうね。

ユーザーが求めたテストの中身は平行本番稼働や、他社システムとの包括的な連携テストなど。システム間のインタフェース周りだけではなく、連携先企業も含めたビジネスサイクルを動かすテストが必要とユーザー側が判断した。TISはこの大がかりなシステムテストを当初の予定にない仕様変更と捉えたが、ユーザー側はTISと結んだ一括請負契約の範囲内と判断。追加テストに必要なコストの負担を断ったという。

TIS、大型案件の開発遅れで業績予想を再度大幅下方修正へ:ITpro

日本のあいまいな契約慣習ですと、仕様を最初は小さめに言っておいて、後から膨らます、というやり口で、ユーザが開発費を安くあげようとすることを防ぐのは難しいでしょうね。

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

2007年10月24日 (水)

「史上最悪のソフトウェアバグ」

”lucille development blog” さんの記事 で紹介されていました。若干古い記事(2005年)ですが。

WIRED VISION / 「史上最悪のソフトウェアバグ」ワースト10を紹介(上)

WIRED VISION / 「史上最悪のソフトウェアバグ」ワースト10を紹介(下)

より。

多くの人は、人命にかかわる事態を起こすバグが最悪のものだと考えている。もちろんその数は少ないが、1980年代後半、放射線治療装置『セラック25』がプログラムミスによる誤動作を起こし、放射線障害で死者が出たケースなどは、安全が非常に重視される用途にやみくもにソフトウェア的手段を用いることへの警告として知られている。

 ただし、このようなシステムを研究する専門家は、あるソフトウェアによりごく少数の死者が出るとしても、こうした危険性にばかり焦点を当てていては、処理能力の向上が切に望まれている分野への新技術の導入が進まなくなる恐れがあると警告する。結局は、ソフトウェアが導入されなかったために命を落とす人のほうが、バグによる事故での死者よりも多くなりかねないというのだ。

”このようなシステムを研究する専門家”というのは、アメリカの方ですかね? テクノロジーに対する楽観といいますか、啓蒙主義的といいますか、あまり日本では、こういった発言をする人というのはみられないように思います。

2000年11月――パナマ国立ガン研究所:
...
技師たちは、真ん中に穴を持つ1個の大きなシールドとして、5個のシールドをまとめて表示させれば、ソフトウェアをだますことができることを発見した。
...
少なくとも8人の患者が死亡し、さらに20人が過剰照射によって深刻な健康被害を受けたとみられている。技師たちは、コンピュータによる計算結果を手作業で再チェックする法的義務を負っていたため、殺人罪で起訴されることになった。

”ソフトウェアをだますことができることを発見した”って...バグを利用しちゃいかんですわな。ハッカー精神も時と場合によりますです。

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

2007年10月23日 (火)

ソフトウエアを機能ごとに縦に分けて開発すること

わたしには、この工程によって作業を分担するという方法が諸悪の根源であるように思えてならない。小さい会社が何十人もエンジニアを集められないので元請けになれないという事情があるというのは百歩譲ってあるとしよう。大規模な開発をするため何社かで共同作業が必要だったとしよう。その場合の分担を工程ごとに輪切りにするのではなく、機能ごとに縦に切る事を提案したい。

つまり、ある機能について、一社ないしは一人が仕様の決定から設計、実装、内部テストまで担当するのである。キモは設計者と実装者は同一人物とするのである。これを分離しない。

ユメのチカラ: 開発工程を別々に担当してはいけない

SI業界で行なわれている、開発の分担が、基本設計・外部設計・内部設計・コーディング...という風に、工程別に分かれているのが、非常に非効率だというのは、同感です。

こうした開発分担というのは、”紙の上でプログラミングする”というのが、暗黙の前提となっているように思うのですよね。内部設計まで紙の上でやってしまうと、後は、紙の上の日本語を、コードに”翻訳”するだけ、という感があります。これは、コンピュータが非常に高価であった時代の、バッチ・集中型のプログラミング・モデルの呪いであるかのように思えます。現代のように、安価にコンピュータが使え、また優れた開発環境をコンピュータ上で使える時代にあって、こうしたものに背を向け、延々と紙の上でプログラミングを行なうというのは、非効率・前時代的である、と思います。

ソフトウエアを工程別ではなく機能別に分割し、各々が機能別に全工程を担当すれば、紙の上でのプログラミング作業を、コンピュータ上でのソースコードに対するプログラミングに、その多くを移すことができるでしょうから、効率化が期待できると考えます。XPなどのアジャイル開発手法は、この”紙の呪い”からの脱却を目指すものでもあるのでしょう。

・・・

その上で、こうした開発手法を実現する上でのハードルをいくつか挙げてみたいと思います。ソフトウエアを機能別に分割し、これを機能ごとに複数の業者に発注することを考えます。

コードの共同所有

業者間で、コードを共同所有する必要があると思います。これは、技術的にはもちろん可能なことですし、OSS開発においては、実際に行なわれてもいるわけですが。

ソースコードのリポジトリを所有し、提供するのは、誰になりますかね。顧客か、あるいは、業者のなかの誰かか?

最終的に仕様を決めるのは顧客

大量の”紙”を用いずに、顧客に仕様を決定してもらうには、どのようにすれば良いか?を考える必要があります。XP開発手法では、オンサイト顧客、各イテレーションに対する顧客自身による受け入れテスト、によるようですけども、一般的な顧客にとって、これはなかなか受け入れがたいのではないかとも思います。

また、顧客は機能別に異なる業者に指示を出さなければならないのか? という問題もあります。顧客としては、指示する相手はひとつに絞りたいところでしょう。

責任は誰が持つのか

ソフトウエアを最終的に期日までに完成させる責任は、誰にあるのか。顧客か、あるいは、業者のなかの誰かか?

また、ソフトウエアに不具合があると考えられる場合に、対処するのは誰か? どの機能に不具合があるかを確定し、その機能を担当した業者に対処を依頼するのは誰か? 2つ以上の機能にまたがる不具合の場合は?

・・・

色々と超えなければならないハードルは出てくるのですが。逆にいえば、SI業界においても、まだやるべきこと・やれることは沢山あるわけでして。業界として努力が足りないといわれれば、その通りのように思います。

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

2007年10月20日 (土)

互いにパラサイトしあえるのなら(パラサイト・プログラマ)

"パラサイト・プログラマ", その様式を "パラサイト・プログラミング" と呼ぶことにしよう. 以下 PP と省略.

PP は仕事がはやく片づく. 検索結果から大量のハズレページを眺める時間, 見当外れのステップ実行をする時間はとても長い. (くたびれてサボる時間も長い.) これらをスキップできるから仕事は速やかだ. 一部には, こうした "ハズレ" の作業を貴重な経験と重視する向きもある. PP の価値観からすると, これは無駄なばかりか悪習ですらある. 10m の距離に音速で到達できる正解があるのに, 何ホップも遠くのサーバや数千数万行のコードを探るのは不合理に思える. 私はそんなスパルタを好まない. ラクできる時はラクをしたい. 同僚が知らないことは結局自分で調べるのだし.

”パラサイト・プログラミング”, steps to phantasien t(2007-04-16)

面白い話だと思います。チーム内で知識を持ち寄り、自分の知らない分野について、互いにコンサルトできるのであれば良いですね。

ただ、誤解を招きそうな記事でもありますね。元記事でも、ちゃんと指摘されていますが。

「助け合う、ってのはお前、最低限のことができる人間同士が集まって、それで初めて意味のあることじゃねえのかい。嬢ちゃんの気持ちはわかるが、できる人間ができない人間をただ助ける一方なのは、助け合うとは言わねえ。荷物を抱えるってんだ」

小野不由美 著, 「図南の翼 十二国記」, 講談社, 1996

また、”教育”という観点では、あえて自分で解決しようとする姿勢も必要だと思います。

ささだ
    後輩の指導は、どんなふうにされてるんですか?

まつもと
    いや、してません。何か聞かれたら、それに答える。

前田
    まつもとさんは、「教育でプログラマーが育つ」っていうことに、否定的ですよね。

まつもと
    うん。自分で勝手にやれ。自分でできない人は、教えてもできるようにはならない。

Rubyist Magazine - Rubyist Hotlinks 【第 1 回】 まつもとゆきひろさん

まつもとゆきひろ氏の意見は、いくらか極論ではあると思いますけどね。

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

プログラマがRDBMSを憎む理由

Complaining about relational databases is a staple theme of programmer blogs. Why are so many programmers irritated and frustrated with relational databases? Why do the perceived intricacies of SQL and the “object-relational impedance mismatch” launch so many rants? Why are DBAs more hated than managers? I have some ideas.

Typical Programmer - Why Programmers Don’t Like Relational Databases

リレーショナル理論というのは、非常に良く考えられたもので、データの操作に関して、高い柔軟性を実現することのできる基盤と成り得るものであると思います。そして、その柔軟性によって、個別のアプリケーションの文脈から、データを独立させることができるわけです。こうして、データを、特定のアプリケーションから解放し、同じデータを様々なアプリケーションで、自由に使いまわせるようにするというのは、データベース管理システムの目指すところであったわけですが。

・・・

柔軟性を最大限に確保した設計というのは、どうしても複雑になってしまうのですよね。小さな大量のテーブルにデータを分割した上で、これらを組み合わせて使わなければならない、というのは、プログラマにとっては苦痛でしょうね。実際、”テーブルが多すぎる(ひとつにまとめてくれ)”という苦情は、良く聞こえてきます。

また、SQL言語の構文の冗長さが、この苦痛を増幅させているように思います。”英語らしさ”を重視しているようにみえるあたり、どこかCOBOLに通じるものがありますね。私も大量のJOIN句やらサブクエリやらをタイプしていて、腱鞘炎になるんじゃないかと思ったことがあります。もっと簡潔に書ける言語にならないものかなあ、といつも思うんですよね。しかし、SQLは標準となってしまっていて、別のより簡潔な言語に変わることはないでしょうね。

そして、データベースの”重さ”と”硬さ”。数千万件、数億件ものデータが格納されている場合、テーブルに”ちょっとした変更”を加えるだけで、半日仕事になってしまいます。このようなデータとなると、ちょっと開発環境でテストに使う、というわけにもいかなくなりますしね。アプリケーションを少ない件数のテスト用データで開発して、それを本番にもっていったら、クエリのレスポンスに数時間かかることが判明したり。しかも、その原因が、SQL構文の”ちょっとした違い”に起因していたりします。

・・・

とまあ、苦情を言いますと、こんなところでしょうか。

しかし、それでも、現実にRDBMSが達成してきたものは、決して小さくはないな、と思うわけでして。アプリケーションごとに、フラットファイルに持っていたものを、DBMS上に載せるようになり、SQLによって、かなり自由に取り出せるようになった、というのは大きいでしょう。色々不満はあっても、RDBMSがないよりはある方が遥かにマシであるのは、認める他ないように思います。

RDBMSよりも優れたデータベース管理システム、となると、正直、あり得るのだかどうだか。。。

SQLよりも使い良い言語をインターフェイスにする、というのは、少なくとも技術的には実現性はあるでしょうけど(社会的にはなさそう)。それ以外については、どうしょうもないかな、という気がします。今後、もの凄いブレークスルーがあって、数千万件だろうが数億件だろうが、お手軽にデータを扱えるようになるかもしれませんけどね。

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

2007年10月19日 (金)

トリクルダウン理論 - 歴史は繰り返すか

昨日のエントリ「格差の大きい国ほど成長率も高い?」 について。

”誰も「格差が大きければ大きいほど成長率が高い」などとは主張していない”との指摘をいただき、格差の大きい国ほど成長率も高い、というのは、元の記事の主張を少々拡大解釈しすぎたかな、と反省をいたしました。

経済成長によって、みんなが豊かになるならば、格差など問題にならない、という主張ととらえるべきでしたかね。まあ、今の日本では、その(高い)経済成長率をどうやって達成するかが大問題ではあるのでしょうけども。

さて、”トリクルダウン理論”なるものがあるそうです。

ヴィクトリア女王統治の19世紀後半。イギリスでは、繁栄する経済が、そのまま永遠につづくと信じられていた。そして多くの者は、成長を牽引する富者たちが一層富めば、その富のしずくが残りの層にもしたたり落ちるために、それでよいではないかという楽観的な考えを共有していた。これと同じ考え方は、後に1980年代のレーガノミックス、特にレーガノミックスにおける税制改革の思想的基盤となり、トリクルダウン理論(trickle-down theory)と名付けられるようになる。この理論が、レーガノミックスと関係があることから推測されるように、トリクルダウン理論は、サプライサイド経済学や新古典派経済学、さらに小さな政府論と強い親和性を持つ。

話を19世紀末イギリスに戻そう。今で言えばトリクルダウン理論に支配されていた楽観ムードの修正を迫った事実が起こった。(ロンドンで造船業を営んで一代で財を築いた)チャールズ・ブーズ(Booth イギリス式発音)、(ヨークでココア製造業2代目を継いでいた)シーボーム・ラウントリーによる<貧困の発見>である。ヘンリー・ハインドマンを領袖とする社会主義運動家たちが、ロンドン大衆の4分の1が深刻な窮乏に陥っていると告発したことに憤りを覚えたブーズは、一面識もなかったハインドマンを訪れ、論争のすえ、彼らの方法の不適切と事実の誇張を私費を投じて論証すると言明して、以後17年にわたるロンドン・サーヴェイに着手する。結果は、ハインドマンたちの訴え以上の惨状を発見することになる。

権丈 善一 著, 「医療年金問題の考え方 - 再分配政策の政治経済学Ⅲ -」, 慶応義塾大学出版会, 2006, p.16

私費を投じて大規模なサーヴェイを実施する、というのは、いかにも実証を重んじるイギリス人らしいエピソードであると思います。この後、イギリスはより所得再分配政策を強め、福祉国家へと進んでいったわけですが。

...そして日本では、バブル崩壊後の税制改革 - 所得税、住民税、相続税、贈与税の最高税率引き下げ - をはじめとして、トリクルダウン理論が勢いをもちはじめて久しい。そのなかで、下層の生活実態や排除(exclusion)、そして格差拡大、階層の固定化を論じる現代のブーズやラウントリーたちが次々と現れ、トリクルダウン理論に沿う政策のみでは政権が不安定化する - すなわち、選挙に勝てない - 雰囲気が生まれようとしている。

同書, p.18

先の参議院選挙の結果からすると、非常に示唆的な記述であると思います。

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

2007年10月18日 (木)

格差の大きい国ほど成長率も高い?

格差をなくすとみんな平等に貧乏になる

こういう話って、私にとっても完全にgiven(大前提)の話で、あえて説明するまでもなく、その大前提の上でどう制度を作っていくかという話だと思うのですが、世の中にはこれが大前提ではない人も多いように思えます

栗原潔のテクノロジー時評Ver2 [ITmedia オルタナティブ・ブログ]

各国別にみると、日本は格差もフランスに次いで小さいが、成長率もブラジルに次いで低い。全体として、格差の大きい国ほど成長率も高い。ありもしない「格差社会」を嘆くより、主要先進国で最低に転落した成長率を上げることが日本の最優先の課題である。

池田信夫 blog ITとグローバル化は格差も所得も拡大する 

所得格差が経済成長をもたらすという仮説は、まったく初耳です。

経済成長は所得格差を縮小する方向に作用する、というのが、日本の高度成長期や、アメリカの”黄金の60年代”における経験則であったと思いますが。であればこそ、バブル崩壊後、深刻な不況に陥った日本はともかく、アメリカの80年代以降の好況が、”雇用なき回復”などと呼ばれ、特異なこととして、所得格差の拡大が話題として取り上げられたのではないか、と思いますけども。

それはともかく。

池田信夫氏のブログで取り上げられているIMFのレポートですけど、概要と結論だけの流し読みではありますが、その内容はというと。

1) 技術の進歩は、貿易よりも不平等を拡大させる要因である。

2) 貿易のグローバル化は、不平等を減少させている。金融のグローバル化 - 特に外国直接投資 - は不平等を増加させている。

3) 教育・金融への人々のアクセス改善は、グローバル化の恩恵をより平等に配分するのに資する。

途上国向けの提言(エクスキューズ?)のように思えますね。

このIMFのレポートに対し、Richard Posner 氏 - ”Senior Lecturer in Law”とのことで、法律がご専門の方のようです - が、以下のように”疑問に思う”と述べているようですが。。。

I want to question three assumptions of the IMF report. The first is that increased income inequality is a bad thing, the second is that an increase in world average incomes is a good thing, and the third is that greater investments in education are bound to reduce inequality.

The Becker-Posner Blog: Globalization and Inequality--Posner's Comment

ニュアンスが随分と違いやしませんかね?

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

2007年10月17日 (水)

財政窮状と”無駄遣い”

財政の窮状は国民は十分に承知していて、それにもかかわらず、相変わらず官僚や役人による無駄遣いが止まない、政治が無駄遣いを止めさせるリーダーシップがないところに国民の怒りがあるのであって、財務省が広報強化に乗り出し、「広報企画調整官」ポストに、17人の応募者の中から電通出身の人を起用したというのは、ご本人がいかに有能な方であっても、的はずれも良いところじゃないでしょうか。

大西 宏のマーケティング・エッセンス:財政の窮状を訴えるために広報強化とは的が外れていない? - livedoor Blog(ブログ)

個人的には”無駄遣い”というのは、あまり本質的ではないなあ、と思います。むろん、過去・現在において、”無駄遣い”があった/あるのは、確かでしょうけど。一般会計に関しては、全体を揺るがすほどの”無駄遣い”がなされているようには見えませんしね。具体的にどこが”無駄遣い”という指摘もあまり聞きません(特別会計では指摘されることはありますね。グリーンピアとか)。

結局、”無駄遣い”というのも価値判断になりますから、ある程度はどうしょうもない面もあるでしょう。つまり、人によって、”無駄遣い”の定義がまちまちなため、特定の人にとっては、”無駄遣い”でも、別の人にとっては必要というのは当然あるでしょうし。例えば、高所得者にとっては、社会保障なんて”無駄遣い”かもしれませんけど、低所得者にとっては、必要であるがごとく。

それよりも、政策が小手先の対策・選挙向けの打ち上げ花火に終始していて、グランドデザインがまったく提示されないことや、税収の根本的な問題を棚上げしているところに問題があるような気がします。

政策面では、現在の日本の歳入構造からすると、アメリカ・イギリスに近い、”小さな政府”へと向かわざるを得ないわけで、政府はまさにその方向へ邁進すべく、社会保障・福祉を削減し続けているわけですが、これは、国民的議論の結果、というわけではないと思います。高度成長が終焉して、低成長期に入った1970年代より、負担と給付はまったく釣り合っておらず、公債依存を強める結果となったわけですが、それも限界に到達した結果ですよね。結局、負担を増やすのか、給付を減らすのか、議論されないままで来てしまった感があります。

また、税収も問題としては、所得の補足率の問題があって、これもまったく論議はなされていない感じです。

勤労者が手にする所得の内、課税の対象となるのは必要経費を除いた残額である。本来課税対象とされるべき所得の内、税務署がどの程度の割合を把握しているかを示す数値を捕捉率と呼ぶ。この捕捉率は業種によって異なり、給与所得者は約9割、自営業者は約6割、農業、林業、水産業従事者は約4割であると言われる。このことを指して「クロヨン」と称する。

"クロヨン," Wikipedia, (accessed 10月 16, 2007).

消費税増税は、国民のより強い反発が予想される、所得税増税を回避して、少しでも取りやすいところからとる、という感が強いです。結局、これも目先のことだけしか考えていないなあ、と思うわけでして。税収が不足して財政窮状に陥った、そんなことは、30年も昔からわかっていたことであるはずなのですけどね。

もちろん、財政窮状の広報などといううのは、もっと小手先・近視眼的であるとは思います。

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

2007年10月16日 (火)

「詭弁論理学」

詭弁論理学 (中公新書 (448))Book詭弁論理学 (中公新書 (448))

著者:野崎 昭弘
販売元:中央公論新社
Amazon.co.jpで詳細を確認する

私がもっているのは、2005年52版(1976年初版)。ロングセラーの本のようです。内容は、詭弁のコレクションといったものではなく、詭弁を糸口にした論理学入門といった感の本ですね。特に後半部分がそんな感じになっています。

とはいえ、前半部分には、詭弁・強弁の分類がなされ、著者の経験した詭弁・強弁の例、古今東西の逸話からとった例などがあげられています。それがまあ、30年も前の話とは思えず、現代の話としても通用しそうなあたり、人間というのはあまり変わらないものだの感を強くします。

二分法とは

人々や考え方などを、ある原理的な基準でふたつに分けてしまう考え方を、二分法という。テレビっ子ならすべての人間を「ワルモノ」と「イイモノ(善人)」に分けるであろう(イギリスの子供は、昔の王さまの話がでるとすぐ、「それ、いい王様? 悪い王様?ときくという)。

同書, p.32

大人でも、短絡的に良し悪しを他人に聞こうとする人はいますね。

個人的に気に入った逸話は、以下のものです。「論点のすりかえ」の例として。

クールリッジは、学校側の証人ミセス・ケネディに、退学させられた少女のどこが悪かったのかとつめよった。するとケネディ夫人は、少女が「いちごを食べた」という例を挙げた。

クールリッジ「へえ、いちごを食べたのですか。どうしてそれが悪いのですか」

ケネディ夫人「禁じられておりました」

「しかし、いちごを食べるとどんな厄介なことが起こるのですか」

「どうか、りんごを食べるとどんな厄介なことが起こるか、きいて下さいませ。ご存知の通り厄介なことが起こっています」

同書, p.76

後半は論理パズルが取り上げられています。長いですが、一番印象に残ったものをひとつ、引用してみます。

仲の悪い四十人の貴族が、それぞれひとりづつの従者と暮らしていた。ところがこの従者どもが悪い奴で、主人に隠れてこそこそ悪いことをやっていた。どの貴族も、他の貴族の従者どもが悪者であることは知っていたが、お互いに仲が悪いので、それを教えてやろうとしなかった。ところが、自分の従者が悪事を働いているかどうかは、誰も知らなかった - 従者たちはずる賢くて、自分の主人にだけはバレないように、工夫していたのである。

この様子を見かねた王様は、ある日、この貴族たちを全員呼びあつめてこういった。

「諸君は、他人の従者のことはよく知っているのに、自分の従者のことを少しもわかっておらぬな。よいか、諸君の従者のうち、少なくともひとりは悪者じゃ。主人たるものは、自分の従者が悪者とわかったら、即刻その首をはねよ。この始末を誤ったものは、自分の首を失うことになろうぞよ」

貴族たちは青くなって、王様に猶予を乞うた。そしてこの日を第一日として、第四十日めまで考えることを許された。

さて、それぞれの家に帰った貴族たちは、次のように考えた。

「王様は嘘をつかない。実際、よその従者は性悪ばかりなのに、肝心のおのれの従者が悪者かどうか、おれにはさっぱりわからんからなあ。王様の話だと、他の奴らもおれと同様らしい。ということは、他のやつらにきけば、おれの従者のことはわかるはずだが、といって、きくくらいなら死んだほうがましだ。さて、どうしたものかなあ」

ところでこの国はたいへん文化程度が高いので、『中央新聞』という日刊新聞が刊行されていた(朝刊だけで、夕刊も号外もない)。土地のニュースは、猫のお産から馬の葬式までのっていた。貴族の家には毎朝無料で配達されるので、他の貴族がどうしたかと目を皿のようにして読むのだが、いたって平穏無事で、誰それが従者の首をはねたというような話はちっとものらない。従者たちは身の危険を感じていたっておとなしく、乗合馬車の中でも、足をなげだしたりしないで、荷物をきちんとひざの上におく、というほどであった。

こうして平穏無事な三十九日が過ぎた。第四十日めの朝の新聞にも特に変わったことはなく、ありふれた婚約記事や広告などで埋まっていた。 - 新聞を呼び終えた貴族は、静かに立ち上がり、従者を呼んで、首をはねた。こうして四十人の従者の首が、いっせいに飛んだ。

自分の従者が悪者だとわかったのは、なぜか?

同書, p.143

私がなぜこの問題を特に印象に残したか。

Joel Spolsky 氏によりますと。

私のささやかな経験から言わせてもらうと、伝統的に大学のコンピュータサイエンスのカリキュラムで教えられているもので、多くの人がうまく理解できないものが2つあった: ポインタと再帰だ。

Javaスクールの危険 - Joel on Software

中間試験の時になって、私は自分で思っているほど頭が良くないことに気付いた。私はいくつかの問題が全然できなかった。私はまだポインタを理解しておらず、再帰も理解していなかったためだ。

試してみよう - Joel on Software

この問題が、まさに再帰を使った問題だと思うからなのです(この問題を解くための推論方法には、もっと立派な名前がついていて、それは高校数学で皆が習うものではあるのですけど)。

| | コメント (0)

2007年10月15日 (月)

世の中には11種類の人間がいる。

世の中には11種類の人間がいる。

1+1=3と言われて、

笑う人と、解説されて「あぁ、そういうことね」と言う人と、最後まで理解できない人である。

Geekなぺーじ : 言葉遊び

”11種類”は「じゅういち/しゅるい」ではなく、「いちいち/しゅるい」ですから、口述ですと、問題が成り立たなくなりますね。

1+1=3 の部分は、どうなんでしょ?
プラス記号を、かなり恣意的に解釈することになるような気がします。
11=3 の方が良いかもしれませんね。

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

2007年10月13日 (土)

自動改札機のシステム障害

私の職場でも、「改札機が全部開放されていた」「改札機のバグらしい」と、ひとしきり話題になっていました。

日本信号によると、現時点で判明しているのはこうだ。原因は自動改札機のICカード判定部の不具合。判定部には毎朝、サーバから起動用データの1つとして、「ネガデータ」(ネガティブデータ)と呼ぶ、旧式カードや不正カードなど、改札を通過できないカードを認識するためのデータを送信している。この朝もネガデータを送信したところ、判定部がネガデータをメモリに読み込む際に不具合が発生。処理がそこでストップし、起動しなかったという。

調べたところ、ネガデータに「ある長さ、ある件数」といった条件が重なった時、データが読み込めなくなるプログラム不具合が判定部側にあることが判明。このため、判定部はエラーを返しながらネガデータ読み込みのリトライをひたすら繰り返す状態に陥り、起動処理が止まった。

260万人の朝の足を直撃 プログラムに潜んだ“魔物” - ITmedia News, 2007年10月12日 20時46分 更新

職場の先輩が、この”ネガデータ”が原因じゃないか、という推測を述べていました。何でも、RFIDの社員証を使った認証システムの案件で、同様のバグでシステムがクラッシュしたことがあるとか、話をされていましたけど。案外、良く知られたバグのパターンではないのかな、という気がします。

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

階層下請け構造はなぜできるか

日本じゃ簡単にクビを切れないから、潰しのきかない技術者はできるだけ雇いたくない。そこのところはSIerに押しつける訳だ。重層的な下請け構造が何故あるかというと、SIerも簡単にはクビを切れないんでバッファを必要とするからで、6次とか7次になれば会社そのものが吹けば飛ぶ世界で、労働基準法なんか形骸化しているしね。

どっこいSIerは簡単になくならない - 雑種路線でいこう

企業内でのシステム開発というのは、毎年コンスタントに発生するわけではなく、結構大きく変動があるように思います。既システムの運用・保守・サポートであれば、コンスタントにありそうですけど。ある程度大きな開発案件というのは、5年に1回とかでしょうね。ですので、特に開発をおこなう技術者というのは、ユーザ企業本体で抱えるのは、難しいでしょう。

日本の製造業労働者の半数近くが、作業員数五〇名以下の工場で働いており、その多くは、夫婦共に日に一〇時間以上働いている低賃金零細工場である。このような零細工場は下請けとして、有名企業が流通経路にのせる製品・部品を作ったり完成品を組み立てるのであるが、低賃金労働力の供給源になり、不況時のショックの大部分を吸収する役目をしている。

カレル・ヴァン・ウォルフレン 著, 篠原 勝 訳, 「日本/権力構造の謎」(上), 早川書房, 1994, p.352

ソフトウエア開発者に限らず、日本企業の賃金テーブルの硬直性、労働力の流動性の低さが、こうした階層下請け構造を作っている、という指摘は、一理あるかと思います。

ただ、これが非常に深い階層構造になるのは、また別の理由があるように思いますね。つまり、多くの企業が人員を別々に抱える必要があるにしても、ジョイント・ベンチャーのごとく、対等なパートナーシップであっても良いはずでしょう。上下関係のある階層になるのはなぜなのでしょうか。

ひとつには、日本的な、責任の所在の曖昧さがあると思います。

以前に下請け構造内での”中間搾取”について、これを、”リスク引き当て金”であると、主張する方がいらっしゃいましたが。責任をどの業者がとるのか、あらかじめ明確に決まっていれば、中間業者のすべてがリスク引き当てを積む必要はなく、1社で十分のはずですよね。まあ、”引き当て金”といいつつも、どうせ売り上げ金に算入しているのでしょうから、欺瞞であろうと思いますけど。

しかし、責任の所在のあいまいさは、責任の分散を困難にしますから、1社に丸投げすることで、とにかく、責任を負う相手を決定する意味はあるのかな、と思います。それが、二次受け、三次受け、...n次受けへと繰り返されます。結局誰が責任を負うのかあいまいなまま ...(そして全員が”引き当て”を積むと)。そして、リスクが顕在化した際には、最も立場の弱いものが責任を負わされることになるわけですね。

もうひとつ、一般論ですみませんが、日本人というのは、協調性というものがあまりないのかな、と。

日本では、”協調性”という言葉は、有無をゆわせぬ同調、上に対する従順・服従を意味していることが多いように思うのですよね。対等なパートナーシップのようなものではなく。私達は、対等な関係を保ちつつ、集団で行動するというのを、非常に不得手としているのかもしれません。学校教育からして、軍隊式の上意下達の風がありますし。ですので、階層型の構造というのを、自然と好む傾向があるのかな、と思ったりします。

”信念”が社会・政治的状況によって変わり、”リアリティ”も操作できるものであるとすれば、多種多様な虚構を維持するのはかなり容易になる。このような虚構によってもたらされる国際的な言語表現上の混乱は、日本の評論家や官僚が”理解”という言葉を口にする時の特別な意味づけによって、さらに複雑になる。”相互理解”をさらに深めることが急務である、という表現が熱意をもって強調されることが多い。ところが、たとえば日本語で「わかってください」というのは、「私の言っていることが客観的に正しいかどうかはともかく、当方の言うことを受け入れてください」という意味の「ご理解ください」なのである。つまりそこには、どうしても容認してほしい、あるいは我慢してほしいという意味が込められている。したがって、このように使われる場合の日本語の”理解”は、同意するという意味になる。

カレル・ヴァン・ウォルフレン 著, 篠原 勝 訳, 「日本/権力構造の謎」(上), 早川書房, 1994, p.59

SI業界では、”外注”というのは差別用語なので、”パートナー”、”協力会社”と呼ぶべき、というようなことを主張する向きがありますよね。しかし、契約上、現実上、階層的な下請けになっているのであれば、あたかも対等であるかのように思わせる言葉というのは、”処遇は変わらないけど、責任だけは対等に負うように”という、ニュアンスを感じさせます。これも、”リアリティ”の操作ではないでしょうかね。

---

日本 権力構造の謎〈上〉 (ハヤカワ文庫NF) Book 日本 権力構造の謎〈上〉 (ハヤカワ文庫NF)

著者:カレル・ヴァン ウォルフレン
販売元:早川書房
Amazon.co.jpで詳細を確認する

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

プログラマ3類型

この種の話は議論され尽くされているのに、話題となるたびホットになるようですね。

本来のソフトウェア作りとは、絵を描いたり、音楽を作ったり、建物をデザインするのと同じ「創作活動」である。ドラッカーが警告したとおり、そこに第二次産業におけるマスプロダクションの手法を取り込んで「ソフトウェア工場」を作ろうとすること事態に無理があるのだ。

Life is beautiful: 「渡された仕様書を実装するサラリーマンプログラマ」の悲哀

誰でもできることをやっているとしたら、それはもう単価勝負にならざるを得ない。自分の仕事がオフショアされちゃったよということになる。

それじゃあだめだろうという事である。

小説家募集、未経験者歓迎。

日本語を書けるからといって、小説が書けるとは限らない。ましてや英語の読み書きができない人が、今から英語を勉強して、英語で小説を書くということを職業としてできるかということである。そんなことがまかりとおっていていいのだろうか。

ユメのチカラ: プロのプログラマ

で、私もつまらない蛇足を足そうとしているわけですけど^^)

ひとくちに”プログラマ”といっても、色々あるでしょう。とりあえず、3つの類型に分けてみます。

1) 芸術家プログラマ

自らの作品が世に認められることを望む。何か新しいプログラムを生み出すべく努力する。

2) 職人プログラマ

自らの技術が世に認められることを望む。より品質の高いプログラムを作るべく努力する。

3) 作業員プログラマ

指示されたとおりに作業をする。”仕様どおり”のプログラムを作るべく努力する。

”芸術家プログラマ”。自らの芸術作品によって生計を立てられる人間というのは、そう多くはないでしょうね。ほとんどの人間は、自分が芸術家として認められるのを夢みつつ、自分の技術を切り売りして食いつなぎ、それでそのままで終わるような気がします。

”職人プログラマ”というのは、両極の中間なのですけど。”自分の作品”を作るわけではなく、他人の注文に答えてプログラムを作る。しかし、ただ仕様書をプログラムに翻訳するわけではなく、自らの裁量と責任で作る、といった感じですかね。

”作業員プログラマ”。SIでのプログラミングというのは、膨大な単純作業であることが多いですから、膨大な人数の”作業員プログラマ”を必要とするわけでして。従って、プログラマの求人のほとんどが、この”作業員プログラマ”の募集であるのは、別に不思議ではないように思います。

ニューヨークの大きな投資銀行は、プログラマにはしんどい場所として知られている。作業条件はひどいもので、長時間騒がしい環境のもと、暴君のボスの下で働かされるプログラマは3級市民だ。そこでは金融商品を売買しているテストステロン溢れるサルが特権階級であり、30,000,000ドルのボーナスをもらい、食べられるだけのチーズバーガーを食べている(たまたま近くにいたプログラマがよく買いに行かされる)。

開発者観察ガイド - Joel on Software

「アメリカではプログラマの地位は高い」と言いますが。。。その人は1級市民のプログラマなのでしょう。プログラマの世界も、#{1級市民}<#{2級市民}<#{3級市民}。下に行くほど数が多くなるのは道理ではございませんか。

P.S
そういえば、「小説家募集、未経験者歓迎」というコピーは見たことがありますね。たしか何かの小説雑誌の新人賞のコピーだったと思います。

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

2007年10月 7日 (日)

応益負担と応能負担

国民は租税を強制的に負担させられているわけですが、その負担の根拠として、租税利益説と租税義務説なるものがあるようです。

租税利益説:国民は政府の提供するサービスの対価として税を払う
租税義務説:国民は国家に属するがゆえに義務として税を払う

ここから、負担のありかたとして、応益負担と応能負担という考え方が出てきます。

応益負担:政府サービスの利益に応じて税を負担
応能負担:納税者の支払い能力に応じて税を負担

もともと、近代国家が誕生した当初は、夜警国家(自由主義国家)思想が支配的で、政府が国民生活に介入するのは、最低限であるべき - 極端には軍事と警察に限定すべき、としていたことから、応益負担の考えが主流であったようです。

その後、二度の大戦を得て、政府の役割は飛躍的に増大し、様々な社会保険制度、社会保障制度が創設され、福祉国家の思想が支配的となります。社会保障というのは、所得の再分配に他なりませんから、ここで応益負担の考えは捨てられ、応能負担の考えが主流となります。

所得再分配というのは、以下のように、高所得層から低所得層へ所得を分配するわけですから、当然のことながら、富裕層ほど”損”になり、受益と負担では説明できない概念かと思います。

低所得層:受益 > 負担
高所得層:受益 < 負担

しかるに、1980年代頃から、財政赤字の増大を背景に、新自由主義の思想が政府内において見られるようになり、再び”受益者負担”が唱えられるようになっています。

実際に、所得税の累進税率が減税され、消費税を増税することで、負担は所得にかかわらず定率、さらには定額へと向かっているようです。一般消費税は主として日用品を対象としますが、日用品の購入額は所得にはあまり関係しないため、税としては所得にかかわらず定額となる傾向があります(消費税の逆進性)。

租税義務説というのは、”国民の義務”だとか、”相互扶助”だとかの、もっぱら、道徳面を強調することになって、いまいち歯切れの悪い、説得力に欠ける面があるのは否定できないですね。租税利益説の方が、利害関係をもとにする分、昨今では説得力を持ちそうです。

しかし、利益説では、国民の受けるサービスが一律である以上、税は所得に関わらず定額とするのが整合性があり、所得再分配を否定することになります。また、税が定額ですと、低所得層が負担できる限度で、税収が決まってしまい、それこそ、政府サービスは、”夜警国家”程度でしか行なえなくなるでしょうね。

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

”効率化”は問題解決には使えない

医療に関して、非効率な部分を改善して効率化すれば、問題は解決する、という向きがあるようですが。まあ、誰かがさぼっているから、誰かが不正しているから、問題がおきている、と考えるのは人の常なのですかね。

 アメリカの医療くらい金がかかるようになると、自然な反応としては、だれか - 保険屋か、民間病院の院長か、製薬会社か - が私腹を肥やしているにちがいないってことになる。そして疑問の余地なく、医療業界には不当に値をつりあげていたり、システムを悪用している人間はいるよ。だってさ、医療はアメリカ経済の13%を占めていて、直接間接に最低でも1400万人を雇ってるんだもん。そりゃ最高から最低まで、ありとあらゆる種類の人間行動が出てくるわな。

 でも、私腹を肥やすのをやめれば、医療問題はかなり解決されるだろうか? いいや。余計な儲けはそんなに多くないし、あってもあまり手のうちようがないんだ。

ポール・クルーグマン 著, 山形 浩生 訳, 「クルーグマン教授の経済入門」, 日経ビジネス人文庫, 2003, p.120

”銀の弾丸はない NO SILVER BULLET ”- 何かプロセスの効率を劇的に改善する方法などは、存在しないし、もしあるなら、とうの昔に実施されているでしょう。

そもそも、”効率化”というのは、全体の十数パーセントも改善できれば、特大ホームランというような世界ですからね。こういうのは、平時において、地道に - 毎年コンマ数パーセントくらい - 改善をしていくものであって、”問題”となっている時点で - それも傾きかけているようなときに、対策として持ち出すようなものではないでしょう。

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

« 2007年9月 | トップページ | 2007年11月 »