Author: Naofumi Kagami

“What are Chinese Tables?”

ローマ字に比べて漢字がコンパクトに言葉を表現できるおかげで、表の活用の仕方が豊かだという話。

表の中の斜線など、中国の表によく見られるものが、CSSやOOXML、ODFにインパクトを与えるかもしれないということです。

オブジェクト指向プログラミングのインスピレーションは生物学でした。ここまで言い切れるかどうかわかりませんが、かのAlan Kayは学部学生のときに生物学を勉強し、生物のコンセプトを頭に描いていたと自分で語っています。

昨日、ふといろいろなブログを読んでいるときに、Windows 95のインタフェースデザインに関わった日本人、Nakajima Satoshi氏のブログに行き当たりました。題名は「日本語とオブジェクト指向」。日本語は語順的に、名詞（オブジェクト）を先に指定し、そのあとに動詞（メソッド、メッセージ）を指定する構造になっていることから、頭を使わなくてもしゃべりやすいという主旨だと思います。酔っぱらってもタクシーの運転手に道順を指定できるのは、日本語のオブジェクト指向のおかげという感じです。オブジェクト指向の中でも、これはPolymorphismというコンセプトです。

僕自身はこのブログの見解には必ずしも賛同しません。しかしPolymorphismの大きな効果が、「動詞」（プログラミングで言えばメソッド）のボキャブラリーを大幅に減らしたとしても、表現力を落とさないで済むことだというのには全く同感です。

そして高等な多細胞生物は、限られた種類のシグナリング分子、サイトカイン、ホルモンしか持たないにも関わらず、多様な機能をコントロールする必要がありますが、これができるのはこのPolymorphismのおかげだと私は感じています。

僕がシグナル伝達を勉強していた頃（90年代）は、rasだとかMAPKのような少数のタンパク質が、多様なシグナルの伝達に関わっていることが明らかになってきていた頃です。どうして互いに全く関係なさそうなレセプターの下流に、同じrasやMAPKが関係してくるのであろうか。そんなことを不思議だなぁと議論していました。もっともほとんどの人は生物をシステム的に考えるのではなく、新しい遺伝子や新しい相互作用を発見することばかりに興味を持っていましたが。

ぼくは最近はちゃんと勉強していないので、これに対する一般的な考え方がどう変化したのかはわかりません。恐らく細胞の環境や分化状態が重要だという考え方に向かったと思います。しかしオブジェクト指向プログラミングのpolymorphismの考え方からすると、これは全然不思議なことではなく、省力化を考えればむしろ当たり前な手法を生物を採用したことがわかります。

生物学とプログラミングの関係についての、僕の意見の一つでした。

私はアメリカの大統領選挙をかなりこまめにフォローしています。インターネットを介して、CNN, Time, CBS, MSNBCの報道を見ています。

残念ながら、日本では「黒人として最初の大統領」であるとか、「最初の女性副大統領候補」だとか、全くどうでも良い報道ばかりが見られます。情けないです。

さて、今日はTimeのウェブサイトに掲載された”Why Barack Obama is Winning”という記事を紹介します。

この記事が真実であるならば、今後４年間もしくは８年間はアメリカ大統領は安泰です。なぜならBarack Obamaは自分と意見の異なる他人との対話の中から学習して、じっくり考えをまとめて、自分を成長させられる人間だからです。

本当は要点を日本語で書き上げたいのですが、残念ながら時間がありません。

一つだけ紹介します；

one of the benefits of running this 22-month gauntlet is that … you start realizing that what seems important or clever or in need of some dramatic moment a lot of times just needs reflection and care.

この22ヶ月間もの戦いの長所の一つはこうです。重要だとか適切だとかに見えることや、なにかドラマチックなアクションが必要に見えることであっても、たいていはそうではないと理解できるようになるのです。多くの場合は注意深くじっくり考えてから対応するだけで良いのです。

僕の前の上司の一人は、売上が下がるとすぐに「どうなっているんだ！アクションは！アクションは！」と騒いでいました。MBAを持っている割には、モノをじっくり考えて、分析する力がゼロの人でした。そういえばMinzbergは”Managers, not MBAs”という著書で、MBA教育の弊害として、即断即決の習慣を挙げていたような記憶があります。

僕が前の会社で作成したウェブサイトを、僕の退職を機に保守管理を外部委託して、そして１年後に様々な問題が噴出してしまっている件については、すでにブログに何回か書きました。

僕は自分で開発してしまうので、IT系の外部委託はあまり経験していないのですが、バイオの研究受託（研究者に依頼された研究を行う業務）を担当していた時期がありますので、外注の仕事の危なさは肌で知っているつもりです。製薬企業によっては結構えげつないところもあるので、本当にヤバいことになって、大変な思いをしたこともあります。

実はウェブサイトの保守管理を外部委託した１年前から、自分の経験と照らし合わせて、この外部委託は危険だと感じた点は何点かありました。ちなみに外注プロジェクトの失敗ポイントをシリーズ化したウェブサイトがありましたので、ぜひ読んでおくことをお薦めします。

これは失敗するなと思ったポイント；

1. 向こうは赤字プロジェクトのつもりでいました。僕が所属していた会社は600人規模の結構大きな会社でしたので、担当の営業は、目の前のプロジェクトをまとめることよりも、その先の商機に興味を持っていました。
2. 現状のシステムについてのヒアリングをしないうちから見積書が出てきました。その見積書は当然ながら、猛烈におおざっぱなものでした。しかも見積もり金額は、われわれがなんとなしに話した予算とぴったり一致していました。あやし〜〜〜。もっとひどいことに、要求仕様書を書いて渡しておいたにもかかわらず、それを読んだ気配すらありませんでした。
3. 当然ながら、契約も非常におおざっぱでした。
4. 我々の技術力は非常に不足していました。僕はウェブ開発ができましたが、僕以外にウェブ技術に詳しい人は誰もいませんでした。したがって僕が退社すれば丸投げ状態になってしまいます。プロジェクトの進捗を理解できるだけの技術力がありませんでした。
5. マイルストーンが決まっていませんでした。管理を委託するというだけで、それが具体的にどのような作業を指すのか、そして各作業がどのようなスケジュールで行われるべきかが決まっていませんでした。
6. 契約後に一回担当者と電話で話をしましたが、僕が書いたソースコードをほとんど見ないうちから、僕にいろいろ相談していました。しかもちょっときつく言ったら、もう二度と電話してきませんでした。全く骨のない奴でした。

これは失敗するなと思いながらも、僕自身は1月もすれば退社する身分でしたので、事を荒立てても後始末ができるわけでもなく、できるだけ引き継ぎをがんばるしかありませんでした。僕には外注先を選定する際に意見する権限は無く、外注先の管理は他部署が担当することになっていました。

しかし、やはり1.と2.に関係するのですが、僕が引き継ごうとしても、向こうは内容を理解することにあまり熱心ではありませんでした。

かくして、当然の帰結としてウェブサイト管理委託は大変なことになってしまったのでした。

以前に勤めていた会社のIT部門からまた連絡がありました。僕が作ったウェブサイトの管理を委託していた会社が、実はもっとひどいこともしていたらしいのです。これも完全な手抜き。

僕自身はITは外部に委託するよりも自分で作ってしまうので直接は知りませんが、外部委託している様子を何回か横から見ていたことはあります。今回のケースを含めていずれも失敗です。

• PriceWaterHouse Coopersに社内のITインフラ構築を委託した例：どうもこれは担当部長の以前のコネクションで決まった話だったらしいのですが、数千万円と半年以上をかけたあげく、成果物はLotus Notesを会社のパソコンとサーバにインストールするだけだったという、本当にびっくり仰天の、嘘のような本当の話。担当者は毎日うちの会社に来ていましたが、どうも他の仕事をしていたらしい。
• 今回の話第一弾：僕が作ったウェブサイトのPHPのプログラムを、PHP4からPHP5に移植する際に、オブジェクトキャッシュをオフにしてしまった話。オブジェクトキャッシュのコードがPHP5と相性が悪かったので、消しちゃったのです。それでサーバへの負担が（当然）重くなって、断続的に動かなくなりました。会社名は出しませんが、それなりに名の知れた会社らしいです。
• 今回の話第二弾：僕が作ったウェブサイトの管理を委託していた会社が、予防的な管理を全くしなかったために問題が発生したという話。これ以上紹介すると危険なので、ここまでにとどめておきますが、本当に情けない話です。

もっと関わりが薄かったものまで含めれば、まだまだあります。

いずれもクライアントの技術力不足、管理能力不足が大きな原因であるとはいえ、もうちょっと何とかならないかなと思います。こう失敗が多いと、小さい会社などは怖くて最新のIT技術を導入できません。日本の企業のITは遅れているとときどき聞きますが、この状況ではそれも仕方ないでしょう。

もちろんちゃんとしたソフトハウスが多いのも事実だと思います。でもどれがちゃんとしていて、どれが駄目なのかは素人目にはわかりません。実績を見ても何の指標にもならないので、なおさらです。

弁護士や弁理士、医者とか建築士だと免許制ですよね。その他にも免許制の仕事はたくさんあります。免許制にすればいいってものではありませんけれども、IT受託も免許制にしたら良いのではないでしょうか。

日本国が世界での競争力を維持するためには、政府が何らかの形でIT業界の品質向上に手を打っていくべきだと思います。

ソフトウェア開発・保守の委託で失敗した例を昨日ブログに書きました。

問題はPHP4からPHP5にアップグレードする際、委託した先が勝手にオブジェクトキャッシュを外していたというものです。その結果、MySQLサーバへの負荷が増えて、ちょっと重たいページをアクセスするとすぐにパンクするようになってしまったのです。

委託先の担当者の技術力が無かった（アホだった）ということではありますが、よく考えてみるとRuby on RailsだとデフォルトでSQLをキャッシュするので（Rails 2.0以降）、何も考えていないアホ担当者をつかまされたとしてもMySQLサーバへの負荷は増えないんですよね。
（アホ，アホって繰り返しますが、どんなに優れたソフトハウスでも必ず担当者ごとの能力のばらつきがあります。悲劇はアホ担当者をつかまされたクライアントです。実績が立派な会社でも必ずアホはいますし、むしろ規模が大きい会社ほどアホはいますので、実績だけで外注先を選ぶと、こういうアホにあたります。）

Ruby on Railsだと非常に優れたフレームワークが既にあるので、独自に書くソースコードが圧倒的に少なくてすみます。自分が書いたPHPを一年ぶりに見ましたが、たいしたことをやっていない割には本当にソースコードが多いと感じました。それもRuby on Railsだとフレームワークがやってくれることがほとんど。今回問題になっているキャッシュもRuby on Railsなら全部フレームワークがやってくれます。

他人や他の会社に保守してもらう可能性があるのであれば、PHPはやめた方が良さそうですね。Ruby on Railsで行きましょう。

しかもRuby on Railsをやっている人は、一通りフレームワークの勉強をしているでしょうし、新しい開発手法に興味のある勉強家でしょうから、キャッシュの有効性を知らないなんてアホなことはないでしょう。

まだ怒りが静まらなくて、他の仕事に影響が出てしまっています。

昨日、以前に勤めていた会社のIT部門から電話がかかってきました。ウェブサイトを載せているレンタルサーバをアップグレードした際に問題が発生したというのです。

ウェブサイトのオンラインカタログは私が開発し、PHP4上で動いていました。そして私が退社したのを機会に、ソフトハウスに管理を委託したのです。

レンタルサーバをアップグレードするとPHP5しか使えないので、オンラインカタログプログラムに若干の変更が必要でした。具体的にはこちらでも紹介されているように、”Fatal error: Cannot re-assign $this”のエラーが出るという問題があったのです。スピードを上げるためにオブジェクトをキャッシュするようにしていましたが、キャッシュにヒットした場合は、コンストラクタで$thisにキャッシュ中のオブジェクトを代入していたのです。

しかしこの単純なPHP4からPHP5への移行作業も、委託先のソフトハウスは見事に失敗してくれたようです。まだ100%の確証はありませんが、たぶん”Fatal error: Cannot re-assign $this”が出ないようにするために、キャッシュの部分を削ったのだと思います。おかげで、負荷がかかるとサーバがダウンするようになってしまいました（負荷が少ないときはおおむね動くので見過ごしたのでしょう）。コードを見ればキャッシュしていることは明白なので、おそらく「キャッシュしなくてもバレないだろう」という気持ちで、安易に削除したのでしょう。許せない手抜きです。

しかもPHP4からPHP5への移行作業で、1人月相当の金額を要求していたようです。むむ。許せない。

もちろんすべてのソフトハウスがこんなにいい加減だとは思いませんし、内部の人の問題も大いにあるのですが、僕が見聞きした開発外注はほぼこのような情けない結果で終わってしまっています。

ソフトウェア開発外注は難しい。そのことを経験的に知っていて、素人ながら自分でオンラインカタログのプログラムを開発したのは、実は大正解だった。改めてそう思いました。

私はいまはむしろ逆の立場になりました。主に自分のためにプログラムを開発していますが、部分的に外注も受けようと思っています。こう言う情けない話にならないように、くれぐれも気をつけなければならない。自分が怒りを買う側になっては絶対にだめだ。そう強く思いました。

それにしても、ソフトハウスの人って、他人のソースコードを読むのが苦手なのですか？

データベースにこまめに問い合わせると遅いから、まとめてバッチでオブジェクトを作っているのがわからないのか？(Railsでいうと:includeを使うように)
お前のところはそうやっていないのか？
いくらコードにコメントが少ないからって、’cache’っていうような名前の変数が使われている箇所を削除するのなら、負荷試験ぐらいしろ！！

爆発