2009年4月25日 (土)

RDBMS の制約の使い方

制約というのは、一意性制約、参照整合性制約、チェック制約などのことです。

個人的には、 RDBMS の制約の典型的な使い方は、 トランザクションの並行実行によって発生する、競合状態 ( race condition ) の検出に使う、というものだと考えてまして。アプリケーション側で、レコード・ロックだの、テーブル・ロックだのやるくらいなら、 RDBMS に任せてしまうが良い、と考えています。

簡単なので、一意性制約の例を挙げますと。単に、テーブルに、値が重複してはならないフィールドの集まりがあるわけですな。

そうすると、2つ以上のトランザクションが、この制約を満たすために、テーブルに既に値があるかどうかを、 SELECT で確認して、それからレコードを INSERT するなり、 UPDATE するなりする、という状況が起きる。 いわゆる、 check-then-act な競合状態が起きるわけです。

ここで、アプリケーション側で RDBMS のロック機能を使って atomic にするというのは、あまりよろしくない。 RDBMS にこんな地雷を埋め込んでいると、新しくリリースされたアプリケーションが、同じ RDBMS を使って、デッド・ロック起こしたり、パフォーマンス障害を起こすのは時間の問題と考えて良いでしょう。

ですので、素直にテーブルのフィールドに一意性制約をつけて、 RDBMS に重複を検出させるのがよろしかろうと思います。 もちろん、アプリケーションのデータ・チェックで、重複回避のために値の存在確認はさせるべきです。RDBMS の制約は、あくまで競合状態の検出にのみ使います。

当然のことながら、 制約を安易に多用しますと、RDBMS 内でロックを多発させることになって、パフォーマンス劣化を引き起こします。 RDBMS の制約は、並行処理の設計の問題であって、単なる RDBMS の便利機能ではありません。アプリケーションのデータ・チェックの代用にはなりませんので、悪しからず。

制約違反が大量発生して RDBMS がとてつもなく遅くて困るって?

アプリケーションが、データ・チェックをさぼってないか、確認してください。本当にそれらの制約が必要なのか、もう一度よく検討してください。

もしそれが、競合状態の多発を意味しているのであれば、根本的にシステムの設計がまずい可能性があります。非同期にして直列処理することを考慮しましょう。ハードウエアのキャパシティ不足であるなら、ハードウエアの増強を検討しましょう。

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

2009年4月14日 (火)

ソフトウエアの「消費コスト」

というのか、何かそんな概念について。

「ソフトウェア工場はうまくいかないんですね。なぜなら部品の組み立てに相当するものが、アップロードとかDVDに焼くといった工程ぐらいしか存在せず、効率化しようないからです」。

「ソフトウェアは工業製品ではない」 Rubyのまつもと氏が講演 @IT

確かに、計算機プログラムの「製造」工程というのは、ソース・コードのビルドであり、サーバへのアップ・ロードであり、 CD/DVD への書き込みであったりして、製造コストは限りなくゼロに近い − 少なくとも「設計」にかかるコストに比べれば − とは思うのですが。

しかし、計算機プログラムには、「設計」以外にも大きなコストが存在すると思うのですよね。

例えば、計算機プログラムを音楽 CD のようなものと比較した場合、大きな違いがあって、それはユーザの「消費コスト」というのか、「使用コスト」のようなものの存在だと思います。つまり、計算機プログラムの入った CD を買ってきて、 PC の CD-ROM ドライブにセットして、「再生」ボタンを押せば、即座に「消費」可能 − ユーザがその製品の付加価値を得ることが出来る − かといえば、否なんですよね。

ユーザが計算機プログラムを入手してから、ユーザがそのソフトウエアの付加価値を享受するまでには、通常、長い道程があるわけです。何百ページだか何千ページだかあるマニュアルと格闘しつつ、ソフトウエアをインストールし、ソフトウエアの使い方を学び、様々な設定をほどこし、データを入力し、そして、ちょっとしたプログラムを書く必要があったりするわけです。

かくして、この大きな労力を必要とする仕事を、ユーザの代わりに行い、ユーザがソフトウエアを使えるような状態にまで持っていく(ターン・キー)、というビジネスが生まれたわけでして。いわゆる SIer と呼ばれる産業です。

こうした、ソフトウエア・ベンダー、ハードウエア・ベンダーから、ユーザまでの「ラスト・ワン・マイル」 − 現状はワン・マイルどころではなさそうに思いますが − を担当する仕事というのが、それなりに大きな産業として存在しているわけです。

そこで感じたのは、現場の科学者が「明日にでも計算したい問題を抱えている」ということは、観念として理解されることはあっても、実感としてはわかってもらえないらしいということであった。彼の答えは、逆に、私の専用機を作るという火に油を注ぐことになった。やはり、自分でやるしかないのである。

杉本大一郎, 『手作りコンピュータへの挑戦 テラ・フロップス・マシンをめざして』, 講談社 ブルーバックス B-956, 1993

上に引用したのは、かの GRAPE 計算機の開発話ですが。著者が、計算機メーカー、計算機科学者への愚痴(?)のようなものを書いています。それは、計算機メーカーや計算機科学者は、「汎用」の問題を解くことにばかり熱心で、科学者の抱えている個別の問題には関心を持ってくれない、といったことです。

これは、計算機ビジネスの構造的要因から来ていると思うのですよね。つまり、ソフトウエアにしろ、ハードウエアにしろ、ベンダーは可能な限り多くのユーザを獲得しなければならないわけでして(業界では「ユーザ・ベース」とかいってますね)。そうすると、システムは可能な限り「汎用」に作る必要が出てきます。特定の問題にフォーカスしても、それこそ、特定の少数のユーザしか得られませんからね。

しかし、「汎用」なシステムを、ユーザが自分の問題解決に使おうとすると、あれこれと自分で作業をする必要が出てくるわけです。このジレンマが解消する日が、いつかは来るのでしょうかね?

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

2009年2月23日 (月)

基本設計と見積もり

基本設計というのは、費用・工期を見積もることができるレベルの設計といいます。 が、なぜか IT システムの世界では、基本設計の前に顧客に見積もりが提出され、「一括請負契約」が締結される、という不可思議なことが行なわれていたりします。「一括請負契約」が締結された後で、基本設計作業に入ることになるんですよね。

プラント・エンジニアリング業の方が書いた、プロジェクト・マネジメントの本を読むと、基本設計作業と並行して契約交渉が行なわれ、基本設計完了後、競争入札等で、契約が締結される、などと書かれています。基本設計の費用は、全部ベンダーの営業経費になるのかしら、と少し疑問に思っていたのですが、以下の話を読む限り、基本的にはそういうことみたいですね。

見積が無償なのは、むろん日本だけのことではない。しかし、私は海外で、ある欧米系石油メジャーに対する見積業務に従事していたときの経験を覚えている。案件は競争入札だった。大型プラントの見積作業は、それ自体が億の単位の費用を要する。ところで、その顧客は、応札者に対して、「入札要求仕様書(基本設計書)のベリフィケーション費用」という名目で、かなりの金額を支払う約束をした。

それだけではない。経済状況の乱変動に伴って、見積期間中に顧客の要求事項もあれこれと変化して、ついていくのがひどく大変な状況になった。すると、入札締切の直前に、顧客はベリフィケーション費用を50% 増額する、と宣言し、そのとおり実行したのだ。この時以来、見積はいつでも無料であるべしという感覚が、自分の中から抜け落ちてしまった。

お見積りは無料です (タイム・コンサルタントの日誌から)

IT システム業界の場合、売り手と買い手の同床異夢になっているように思います。

買い手は、「見積もりは無料」だと思っているし、売り手もそう思わせている。しかし、基本設計どころか、要求定義もろくにおこなってないわけですから、その見積もりは、極めて粗悪な代物です。

売り手としては、買い手から早く現金を引き出したいものですから、粗悪な見積もりでも、とにかく契約を結んでしまおうとするわけです。工期は短ければ、短いほど良い。今期の売上ノルマに追加できますからね。

買い手からみた場合は、おそらく、早くベンダーに責任を「丸投げ」してしまいたい、というのがあるのでしょう。見積もりが粗悪であろうがなんであろうが、「一括請負契約」である以上、ベンダーは「最後まで」責任を負うはず、ほぼ無限責任に近い責任が生じるはずだ、というところですかね。

これは、実のところ、買い手の幻想にすぎず、「請負」の対象が明確に定まらなければ、つまり、基本設計が完了していなければ、請負契約は法的に成立しないわけでして。契約を結んだと思っていても、法的には契約は成立していない、という奇妙な状態となります。

このような不安定な関係で、仕事が曲りなりにも成り立つのは、売り手と買い手との間に、一定の信頼関係がある場合だけなのでしょう。結局、長期の取引関係を前提に、ということになります。実際、「一見さん」との取引は、 9 割くらいの確率でトラブルに発展しているような感がありますね。

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

2009年2月22日 (日)

ソフトウエア工学とは何ぞや

私にとって、「ソフトウエア工学的なもの」の代表例は、オブジェクト指向だったりします。

オブジェクト指向は、少なくとも、「計算機科学的なもの」ではないと思いますね。計算機科学者がアルゴリズムを研究したり、定理を証明したり、学術論文を書いたりするのに、オブジェクト指向が役に立つとは思えませんし。

Wikipedia の Software engineering のページを見てみます。

Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches. That is the application of engineering to software.

Software engineering (Wikipedia, the free encyclopedia)

"Sub-disciplines" のところから少し辿ってみますと、 "agile or waterfall" (Software development process) 、 "versioning and source control”(Software configuration management) 、 "Refactoring tools" 、 "Source code generation tools"、 "Unified Modeling Language" (Computer-aided software engineering) などが挙がっていますね。

「ソフトウエア開発に関する何か」であれば、それは、計算機科学というよりは、ソフトウエア工学ではないですかね。従って、ソフトウエア開発の生産性が云々というのも、ソフトウエア工学でしょう。ソフトウエア開発の生産性を議論すること自体が無駄である、というのなら、それは確かにソフトウエア工学の否定かもしれません1


1.「生産性についての議論は非生産的である」という至言

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

2009年2月19日 (木)

「更新系」はどこへ?

正直、何を根拠にAPサーバで処理した方が良いなどと言ってるのか、いまだに分かりません。私がアホなんでしょうが、口汚く罵って煽ってみても、そういう主張の方のコメントが得られなかったのは残念です。炎上もさせられなかった(笑)。

炎上までいかなかったけれど、たくさんのご意見ありがとうございました(ベンチャー社長で技術者で)

私も「APサーバで処理した方が良い」という話はよくわからないのですが。

一連のお話を読んでいて、少し思ったのは。

ユーザーインターフェイスに必要なパラメータと戻りはダミーのストアドプロシージャの中に含まれています。更新系では、画面側の項目と、セッションIDやログインIDなどが必要になるかもしれませんが、戻りはエラーコードやエラーメッセージを返せば済みます。

更新系に必要なものは、システムの共通仕様として、あらかじめ、まとめておけばよいことです。

テーブル設計は実装の後に! (ベンチャー社長で技術者で)

と、当初は「更新系」、OLTP系の話が少し出ているのですけど。

当たり前ですが、

(クライアントへ)データ転送 > データスキャン >>>> 四則演算

つまり、DBで1回テーブルスキャンするのと、そのときに集計処理をついでに行うのはパフォーマンスには差が出ませんから、DBサーバにとって四則演算をどこかで肩代わりしても意味がないのです。

SQLを使うとスケーラビリティの問題が起きる? それはエコじゃないね (ベンチャー社長で技術者で)

後半では、完全に集計処理、OLAP系だけの話になってしまっている、というところです。

大量のユーザが、大量の更新をかけるような、OLTP系のシステムの場合、 DBサーバをスケール・アウトしたい、ということはあるのではないですかね。

Article_20090218

こんな感じで、OLTP系処理に対しては、DBサーバを複数台用意して、DBサーバ1台あたりの書き込み負荷を下げる。OLAP系処理に対しては、もう一台、集計用のDBサーバを用意して、そこで集計をすると。

まあ、別にOLTP系処理で、 テーブルを直接書きにいかずに、ストアド・プロシージャー経由でも、全く問題ない と思います。ですので、別に結論は変わらないのですけどね。

ただ、OLTP系の場合は、「スケーラビリティをあげるために、処理は極力DBサーバで行うべき」は言いすぎかもしれません。当たり前ですが、 DBのデータ使わない処理まで、DBサーバでやる必要はないですから ね。 「生の入力データ」(例えば、HTML)を、そのまま DBサーバに渡して、DBサーバで解析・バリデートとか。

結局のところ、 データに対する処理は、そのデータのある場所に近いところで行なうのが良い、という話でしょう。昔から言われていることですが。

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

2009年2月11日 (水)

顧客とリスクについて話すのは難しい

見積もり2億のIP電話が820万円で構築できたという話について。

「年に1日コケても良ければシステム価格は1/10になります」とか「システムがコケても〜〜とやれば問題は起きません」ということが提案出来るベンダーは素晴しいし、それを受け入れることが出来るユーザは賢いだろう。でも、それはベンダーにとっては「ビジネスチャンスと信頼の両方を失なう」ことになりかねない。

おごちゃんの雑文 「2億円が820万」

ほぼ同じ感想を持ちました。

丁度、システム一式移設という話が来ていて、見積もりを作っていたのですけど。見積もり依頼は、「一枚ペーパー」すらなく、口頭で営業担当者が、ひとことみことで言われただけらしい。顧客側は、具体的なことは何も考えておらず、「とりあえず概算が知りたい」のだそうで。

実際の発注は、競争入札になるのでしょうけど。その前に、顧客側内部の手続きで、企画・稟議を書く必要があるので、予算がいくらになるか知りたい、という話でしょう。で、現システムの担当である私に、「ざっくり」教えてくれ、というわけです。

まずは、考えうるすべての可能性を考慮しつつ、可能な限り、必要な成果物・作業を洗い出しします。いわゆる、 WBS と呼ばれるものを作るわけです。

WBS が出来上がれば、次は、顧客側作業・ベンダー側作業、顧客が負うリスク・ベンダーが負うリスク、と項目を顧客とベンダーに振り分けて、ベンダー(つまり自社)に振り分けた項目に、見積もりの数字を入れていくわけです。見積もりの「前提条件」というやつですね。

いつものことながら、「前提条件」をどうするかで、頭を悩ませていました。システムの停止期間はどのくらい許されるのか、顧客側作業としてどこまでお願いできるのか、移設後の動作確認・検証はどこまでやるのか、などなど。

この辺は、顧客の事情・懐具合を探りつつ、数字を入れるわけです。

私の段階では、「見積もり」には、顧客側作業、顧客の負うリスク等の「顧客側負担」は、書かれているのですが。おそらく、部門上長・営業を経由して、顧客の手に渡ったときには、消えているでしょうね。「そんなことはとてもお客様にはいえない」、つまり、「ビジネスチャンスと信頼の両方を失なう」ことになる、というわけです。

顧客・ベンダー双方で、リスク負担と責任分岐点、それとコスト負担とのトレード・オフについて、冷静に話し合うことができれば、建設的なんですけどね。それが本来の契約交渉というものの姿であろうとも思うわけですが。これが、日本ではなかなか成り立たないのですよね。

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

2009年2月10日 (火)

DBサーバの性能

昨年末、約10年前のノートパソコンに、Vine Linux をインストールしていたのは、 OSDL Database Test Suite の Database Test 1 (DBT-1) を試してみようと思ったからだったりします。

テストデータベース (PostgreSQL 7.4) は出来上がったのですが。

DBT1=# \timing
Timing is on.
DBT1=# select count(*) from orders;
  count
---------
 2593048
(1 row)

Time: 31606.238 ms

260 万件程度の集計で、 32 秒かかるという遅さ。

ちなみに、某 Oracle データベースのサーバ機で、似たような集計を試してみますと。

SQL> set timing on
SQL> /

  COUNT(*)
----------
   3128119

経過: 00:00:00.17

まあ、10年前のノートパソコンと、最近のサーバ機を比べても勝負になるわけないのですけどね。

メモリ搭載量が、 192MB 対 5GB ですからね。 Oracle のサーバ機の方は、ディスクアクセスがほとんど発生していないのではないですかね。ディスクの性能も全然違うでしょうけど。おまけに、サーバ機の方は、 RAID 1 構成ですし。

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

2009年2月 8日 (日)

APサーバ追加でスケール・アウトできるのはユーザ数では?

以下の一連の話を、面白いと思いながら、読ませていただきました。

スケーラビリティが上がるというのは、「APサーバの増設が簡単」ということになろうかと思います。確かに簡単に追加できますが、それはエコじゃないね〜。

SQLを使うとスケーラビリティの問題が起きる? それはエコじゃないね (ベンチャー社長で技術者で)

クライアント・サーバ・システムで、「パフォーマンスがでない」という相談を受けて、プログラムを見せてもらうと、アプリケーション側で、データベースからフェッチしてきたレコード 数百万件を集計していた、というのはよくありますね。 SQL でやれば、 数秒で終わるような処理の典型例です。

毎回、DBサーバから、ネットワーク越しにレコードを受け取りつつ、アプリケーション側でループまわして集計してたら、そりゃ遅いですよね。

また、こうした集計処理というのは、単純に「APサーバの増設」では、スケール・アウトできないですよね。それこそ、 Google の MapReduce のように、集計処理を分散して実行する仕組みがないと。

よくある、 Web(AP)サーバ ・ DBサーバ での、Webアプリケーション構成では、Webサーバ、 APサーバ の増設でスケールアウトできるのは、 同時接続ユーザ数 であろうと思うわけです。

しかし、企業内システムで、 Google や Yahoo! のように、 数千万人のユーザ がアクセスしてくる、なんてことはないわけでして。大企業でも、システムのユーザ数は、せいぜい 1万人 くらいですからね。

私も SQL という言語自体はあまり好きではなかったりするのですが(CODASYL 風味なところが)。企業内システムでは、強大な威力を発揮するというのは、確かです。仕事では、 SQL (と Oracle PL/SQL) ばかり使っていますしね。

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

2008年12月10日 (水)

何回目のITシステム統合?

現在、ばらばらに管理されている ITシステム を XXX で統合して、バラ色の未来、みたいな話は昔から繰り返されていますね。

To the CIO, CEO, CFO, CTO and shareholders,

As a result of the following I can now only deduce that SOA is a failure and any attempts at SOA will result in failure.

Ahh Shucks, SOA Is A Failure

SOA は失敗だった、という記事。

まあ、この種の試みというのは、大抵は失敗に終わってきたわけでして。

そもそも、統合=善と短絡に考えるのもどうかと。そりゃ、ITだけみていれば、よさげに思えるかもしれませんけど。組織が分散されているのにも、それなりの理由があるわけですからね。

I firmly believe that SOA is nothing more than fancy CORBA or COM.

しかし、この手のITシステム統合のための技術というのは、 RPC 以来、IT技術者のトラウマ量産技術になっているような気がしますね。ディレクトリ・サービスも、流行期にはトラウマ発生装置と呼ばれていたような。

Thanks for understanding and I'd like to declare in advance that Cloud Computing, Virtualization and SaaS will be failures under my direction as well.

クラウド、仮想化、SaaS も失敗に終わるであろう、と。セールス・トークに「統合」が入っていたら、そしてそれを真に受けるとそうなる確率は高いでしょうね。

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

2008年11月26日 (水)

自動化できないシステム

例えば、銀行の公共料金自動引き落としの処理1とか。絶対に時間内に終えなければならない、クリティカルな処理がある場合、処理を全部自動でやるのは無理でしょうね。システムに 100% の信頼性がなければ。宇宙線でメモリの内容が書き換わる、なんてことも − 極めて低い確率ではありますが − 起きるわけですし。2

我々の仕事は、開発部署が構築したシステムの下で正しく処理が動いているかを日々監視することにある。

監視する中でトラブルがあれば開発部署に問い合わせ、対応を要請する。

我々は次に動く処理を監視しなければならないので、対応はあちらに任せるのが常である。

後輩を育てることは難しいです

とはいえ、基本、処理は自動で動いて、処理の成功/失敗を待機要員(オペレータ)に伝える、という形になっているのが普通ではありますかね。

Aという業務があって、それを終えるためにa,b,c,dという作業を順にこなす必要がある。

だが、a->b->d->cとなったり、a->b->cで止まったり、時にはa->c->dとなったりした。

人間がひとつひとつプログラムを起動し、確認しなければならないのは、

  1. ひとつひとつのプログラムの信頼性が極めて低い
  2. 基本的なフォールトトレランスが実現されていない

といった理由があるのではないですかね。

1 は、頻繁にプログラムが処理を失敗するので、はじめから人間が関与したほうがよい、という運用になってしまっている状況。 2 は、それに輪をかけて、処理が失敗したときに、データベースの一貫性が破壊されてしまうというもの。単純に失敗したところから処理再開、とできないわけです。「基本的な」とつけているのは、つまり、データベースのロールバック/ロールフォワードが、ろくに考えられていないということですね。

私が見たことがあるケースですと、例えば、互いに関連するテーブル A, B, C がありまして、バッチ処理が以下のように組まれている、というのがあります。

for a in A
  A を処理

for b in B
  B を処理

for c in C
  C を処理

commit/rollback

巨大なひとつのトランザクションになっているわけですね。で、これが 2 時間かかる処理だとして、1時間50分くらいで、処理が失敗して、ロールバックに 2 時間、はじめからやりなおして 2 時間、などという楽しい運用になるわけです。 Oracle データベースですと、ロールバック・セグメント/UNDO表領域を使い切って処理が失敗する、というのが典型。

これは到底運用に耐えられないわけですが、さりとて、プログラムを直すとなると、全面的に制御構造を書き直しとなるわけでして。応急策として、以下のようになったりします。

for a in A
  A を処理
  commit/rollback

for b in B
  B を処理
  commit/rollback

for c in C
  C を処理
  commit/rollback

当然、この処理が途中で失敗しますと、テーブル A, B, C 間の整合性が崩れるわけです。で、どこで失敗したかによって、色々なリカバリ処理が運用現場でできあがっていくわけですね。

かくして、運用現場のオペレータは、プログラムをひとつひとつ手で起動し、どこで失敗したかを適宜確認し、状況に応じて回復/再開を行なうこととなるわけです。

トランザクション単位で、テーブル間の整合性を維持しつつ、漸次処理を行なっていけば、回復/再開は、 RDBMS のトランザクション機能だけで簡単にできるわけですけどね。

for x in トランザクション単位
  A を処理
  B を処理
  C を処理
  commit/rollback

信じがたいほど馬鹿げた − でも現実にあった − 話。

確か、 P.J. Plauger 氏だったかが、浮動小数点のバグで アリアン・ロケットが爆発した話で、「そのプログラムを書いた人間をロケットに乗せて打ち上げろ」などと、のたまっていたと思いますけど。開発志望の人間に運用をやらせるのは、そういった「含み」があったりするのかも、と思ったり。


1. 処理が失敗するとこういうことになるという例。数億円の損害賠償を払ったそうで。

みずほフィナンシャルグループ大規模システム障害 JST失敗知識データベース

http://shippai.jst.go.jp/fkd/Detail?fn=0&id=CA0000623

2. 半ば以上冗談ですけどね。

アルファ線によるLSIエラーの発見 マイコミジャーナル

http://journal.mycom.co.jp/articles/2008/08/22/dsn/

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

2008年11月20日 (木)

”ユーティリティ・コンピューティング”について思う

冒頭の台詞は単なる例示かもしれないけど、一度真剣に電気や水道などと情報やサービスの違いや共通点を考えてみるべきかなぁ、なんてそんなことを思ったりしている。

"電気や水道のように"って (ナレッジ!?情報共有 … 永遠の課題への挑戦)

"ユーティリティ・コンピューティング"のコンセプトというのは、私の知る限り、もっとも古いものは、 Multics プロジェクトですね。最近、オープンソース化されて話題になりましたけど。

Since it was designed to be a utility, such as electricity and telephone services, it had numerous features to provide high availability and security.

History of Multics (Multics)

ここでは、"電気や電話のように"とありますね。このサイトによると、コンセプトが提出されたのは、1969年のことだとか。Multics は、巨大なタイム・シェアリング・システムを構想していたわけですが。このプロジェクトのアンチ・テーゼとして開発されたのが、 Unix タイム・シェアリング・システムであるのも有名な話ですね。

この後、コンピューティングの歴史はむしろ分散化へと向かっていったわけでして、その極限が、"パーソナル・コンピュータ革命"、コンピュータの個人所有、というものでしょう。それを実現したのが、コンピュータの低価格化であったわけです。どうも、昨今の"ユーティリティ・コンピューティング"の話では、この点が過小に評価されすぎているきらいがありますね。

まあ、つまらない話ではありますが、結局、"設備"の所有形態として、集中か分散か、というのは、コストで決まるのではないでしょうかね。情報システムの所有コストが、発電設備のそれに匹敵するのであれば、より集中へと進むでしょうけど、現にそうではないわけでして。

発電設備が個人で所有できるほど低価格になったことは未だないのではないでしょうか。だからこそ、"分散型電源"というコンセプトが新しいのでしょう。

近年、技術革新や環境問題と相まって、電力を必要とする場所の近くに小型発電機を設置し発電する試みが行われています。この場合、発電機が電力を必要とする場所ごとに分散して設置されるので、ここで使われる発電機は「分散型電源」と呼ばれます。また、この分散型電源を用いてエネルギーを供給するシステムを、「分散型エネルギーシステム」と呼びます。

分散型エネルギーシステム 技術解説 (独立行政法人 新エネルギー・産業技術総合開発機構)

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

2008年10月 8日 (水)

工事完成基準でも同じです

工事進行基準では、ベンダの恣意的な売上計上がいくらでも可能である、といった話。

... そもそも工事進行基準は会計操作の余地がてんこ盛りの危ない会計処理方法だ。ITベンダーの事業実態を決算書に正確に反映するために、そうしたリスクを背負い込んだ。その分、他業種以上に堅牢な内部統制制度が要るし、会計士や監査法人のチェックも厳しくなると覚悟しなければならない。

工事進行基準の売上計上でSI料金を請求できますか (東葛人的視点 ITpro)

いくらなんでも、受注額を超える売上高を計上する、なんてことはないでしょう。すると、「会計操作」として現実に可能なのは売上計上の時点を「操作」することでしょうね。

極端な例を考えます。たとえば、契約締結の翌日が決算締め日で、その日に受注総額の半額に相当する売上高が計上されている、とかですかね。

工事完成基準で売上高を計上している場合でも、似たような例は考えられますよね。

たとえば、開発現場に契約書が営業から渡されて、みると納期が明日になっている、なんて話です。で、なぜか、一週間後に検収書が発行されて、顧客から入金がなされている...

工事完成基準というのは、システムが現実に完成した時点をもって売上を計上するわけでして、検収書発行時点でもなければ、顧客から入金があった時点でもないのですよね。書類上、システムが完成していることになっているだけではだめでして、現実にシステムが完成したといえる状況になければなりません。

企業会計原則では、売上高は、実現主義の原則に従うこととされており、通常、実現主義とは、(1)商品等の財またはサービスの提供、(2)その対価の獲得という2つの要件を満たしたときに収益を計上することとされています。

太陽ASG監査法人編, 『ソフトウエアビジネスの会計実務』, 中央経済社, 2008, p.133

実現主義の原則というそうです。

同書では、受注制作のソフトウエアに関しては、以下の3点の要件を満たしたときに、売上高を計上するのが適切である、としています。

(1) ソフトウエアの完成

 ソフトウエアの受注制作を請け負った企業における品質管理上のルールに合致したソフトウエアとして完成していることが確かめられていること。

(2) ソフトウエアの納品・検査

 完成したソフトウエアを顧客に納品し、顧客の検査を受けることによって実際に稼動し機能することが確かめられていること。

(3) ソフトウエア成果物の検収

 契約書によって顧客への引渡しが定められているソフトウエア成果物(例えば、設計書、仕様書、マニュアル、プログラムを記録したCD−ROM等)が引き渡され、その内容が顧客によって確かめられていること。

同書, P.136

日本公認会計士協会 が、平成17年に出した、「情報サービス産業における監査上の諸問題について」という報告書では、「収益の認識時点の問題」として、「我が国の会計基準では明確ではなく」とした上で、米国基準を紹介しています。この報告書が、前年のIT業界の一連の会計不祥事を受けて出されたものであることは周知のとおりと思います。

こうした流れからしますと、受託ソフトウエア開発に対する、工事進行基準の適用は、工事完成基準を厳格に適用することで、売上高を計上できない事態に陥る、ということに対し、逃げ道を用意した、とみることもできるのではないですかね。

工事進行基準ばかりがクローズアップされていますが、つまるところ、IT業界が会計処理を適切に行なうよう求められている、ということでしょう。この点、工事完成基準を使う場合でも同じことだと思います。

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

2008年10月 7日 (火)

請負契約の成立するとき

深沢隆司氏の『SEの教科書2』(技評SE新書017, 2008) を読みました。システム開発について、おおよそ以下のような主張がなされていまして、興味深いと感じたのですが。

営業段階・受注段階で作成されたスケジュール(初期計画)に従っていては、システム開発プロジェクトを成功させることはできない。 業務分析、要求定義が完了した段階で、開発計画を改めて作成する必要がある。にもかかわらず、ベンダは初期計画を絶対視して変更をしようとせず、そのままプロジェクトを進めようとしている。だから、システム開発のほとんどは、失敗に終わる。

ソフトウエア受託開発では、受注金額と納期だけが決まっていて、開発要件は不明確、という形で、「請負契約」が締結され、契約書が交わされる、ということが往々にしてありますね。

しかし、法的には、請け負う仕事の内容が不明確な状態では、請負契約というのは成立しません。何を請け負うのかわからないのに、請負契約が締結される、というのは奇妙な話です。契約書の内容にもよるでしょうが、開発計画がまともに立てられないような契約書というのは、紙くずでしかないわけです。

名古屋地裁平成16年1月28日判決

本件総合システムの導入に際して締結されるような,業務用コンピューターソフトの作成やカスタマイズを目的とする請負契約は,業者とユーザ間の仕様確認等の交渉を経て,業者から仕様書及び見積書などが提示され,これをユーザが承認して発注することにより相互の債権債務の内容が確定したところで成立するに至るのが通常であると考えられる。

システム開発をめぐる法律問題(3)個別契約で上流工程の不払いリスクを回避する (ITPro)

日経BP社 ITPro の連載記事『システム開発をめぐる法律問題』では、名古屋地裁の判例をひいて、「外部設計相当の内容について合意が得られている」時点を請負契約成立の時点と考えるのが良い、と提示しています。

ベンダの営業、経営層が、受注時点の「初期計画」をもって、「請負契約成立」とみなそうとするのは、売上を早期に計上したいというインセンティブがあるからでしょう。

深沢隆司氏によれば、

たいていの場合、開発計画は初期計画の2・3倍程度になる

とのことですが、これは、ベンダの営業・経営層にとっては都合がよいわけです。本来必要な工期の 1/2 ・ 1/3 の時点で、キャッシュが手に入るわけですから。

顧客側は、契約書にある納期に従って入金の事務処理を進めたいでしょうから、実態としてシステム開発が完了していなくとも、検収書発行、入金が行なわれる可能性が高いです。また、顧客も初期計画の予算・納期で開発を進めてもらいたいわけでして、そこをベンダに付け込まれている面もあるでしょう。

もちろん、これらは開発現場にとっては最悪なわけでして。もともと達成不可能な計画を押し付けられ、最後はプロジェクト失敗の責任を負わされますからね。

上の名古屋地裁判例の判決文は、裁判所の判例データベース内に登録されていて、読むことができるのですが、読んでいると、こうした構図が透けてみえます。顧客側(原告)敗訴の判決ですけど、少々この顧客には同情してしまいますね。顧客の契約管理が甘かったのは確かのようですが(契約書すら存在しない)、ベンダにうまくやられた、という印象も受けます。

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

2008年10月 5日 (日)

工事進行基準の対象となる会社

「上場企業だけの話」という声もありますが。ソフトウエア受託開発を業務としている、全ての株式会社が対象じゃないですかね。

第四百三十一条  株式会社の会計は、一般に公正妥当と認められる企業会計の慣行に従うものとする。

会社法(平成十七年七月二十六日法律第八十六号)

会社法431条にいう、「一般に公正妥当と認められる企業会計の慣行」というのは、企業会計基準委員会の定める会計基準のことを指すのだそうですから(微妙なところもあるらしいですが)、 企業会計基準第15号「工事契約に関する会計基準」 もこれに含まれるのでしょうね。

4 本会計基準は、工事契約に関して、施工者における工事収益及び工事原価の会計処理並びに開示に適用される。

 本会計基準において「工事契約」とは、仕事の完成に対して対価が支払われる請負契約のうち、土木、建築、造船や一定の機械装置の製造等、基本的な仕様や作業内容を顧客の指図に基づいて行なうものをいう。

5 受注制作のソフトウエアについても、前項の工事契約に準じて本会計基準を適用する。

「工事契約に関する会計基準」 4, 5

請負プロジェクトの収益計上については、工事完成基準または工事進行基準の選択適用となっています。どちらを選択するかについて定めがありまして。

 工事契約に関して、工事の進行途上においても、その進捗部分について成果の確実性が認められる場合には工事進行基準を適用し、この要件を満たさない場合には工事完成基準を適用する。

 成果の確実性が認められるためには、次の各要素について、信頼性をもって見積もることができなければならない。

 (1) 工事収益総額

 (2) 工事原価総額

 (3) 決算日における工事進捗度

「工事契約に関する会計基準」 9

「成果の確実性」がある場合には、工事進行基準を適用する、となっています。通常のプロジェクトでは、成果の確実性がない、とするのは説明が難しいでしょうね。プロジェクトが期をまたぐ場合、工事進行基準で売上と費用を計上する、ということになりそうです。

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

2008年9月26日 (金)

技術の問題ではない

ところが,待てども待てども検収結果が届かない。お客さんの立場もあることだし,「いつごろ終わりますか」なんて切り出せない。契約上のプロジェクトの完了は,ほぼ1年後の年度末になっている。長谷川さんは待つしかなかった。うわさでは一部の業務で,納めたシステムが利用され始めたと聞き,検収してOKが出たものだと思い込んでいた。

IT業界の弱者 非常識な「検収」で大赤字 (ITPro)

納期より早く納品物件が完成したからといって、発注主が早く検収作業を行なわなければならない、という法はないですし、もちろん、入金しなければならないということもないですよね。記事を読む限り、発注主は契約どおりに検収作業を実施したのでしょうから、「非常識」でも何でもないと思います。

この場合、「非常識」なのは、納期設定の方でしょう。工期が一年も余るというのは、異常です。

納期設定は早すぎても遅すぎても、ベンダが大きなリスクを負うことになります。早すぎる場合には、納期までに物件が完成しないというのがリスクとなります。遅すぎる場合には、物件を仕掛品としてベンダが抱え込むことがリスクになりますね。このケースは、まさに後者でしょう。入金も遅くなるわけですから、サブベンダに発注を行なえば、プロジェクトのキャッシュ・フローが悪化することになりますね。

適切な納期設定を怠ったがためにこうした事態を招いた、と私は読みましたが。物件の完成時期に対し、納期を適切に設定する、というのが正面からの答えでしょう。客側の予算執行上の都合で、納期がこのように設定され、動かせないのであれば、着手時期を遅らせる手もあります。特に、サブベンダへの発注時期については、慎重に考えるべきでしょう。

このプロジェクトの後,長谷川さんは考え方を変えた。営業活動の時間を減らし,最新の開発技術を必死に習得し始めた。「あのプロジェクトでは,自分のスキルの低さを他人のスキルでカバーしようとして失敗した。人に頼らなくても自分だけで問題を解決できるようになる必要がある」。今では技術に対する自信も深まった。

自社のリソースで賄える仕事だけを受注する、というのもひとつの方策ではあるでしょう。しかし、サブベンダのリソースを購う必要のある仕事は、やはり多いわけでして、サブベンダへ発注することのリスクから逃れることは難しいと思います。

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

2008年8月30日 (土)

「社内人件費単価」

SIer のソフトウエア受託開発での会計処理というのは、「請負工事の会計処理に準じて処理する」とされているわけですが。これは、プロジェクトごとに、直接材料費、直接労務費、直接経費、部門間接費、補助部門費を集計するというものです。社内エンジニアの人件費は、エンジニアのプロジェクト稼働時間によって、プロジェクトの直接労務費として計上することになっています。

実際、 SIer では、プロジェクトに番号を振って、エンジニアの稼働時間を把握しているはず。私の勤務先でも、自身の稼働時間とプロジェクトコードを報告しています。

直接労務費には、社内人件費、具体的には、給与、賞与、退職給付費用、法定福利費、福利厚生費などが考えられます。これらの社内人件費を各プロジェクトに直課するには、ソフトウエア開発を行う人員の稼動時間をプロジェクト別に集計し(稼動管理)、この稼働時間を基準として各プロジェクトの人件費を計算する必要があります。稼動時間単位当たりの人件費を算定する方法としては、人件費の実際原価を利用する方法と予定原価を利用する方法があります。

太陽ASG監査法人 編, 『ソフトウエアビジネスの会計実務』, 中央経済社, 2008, p.117

プロジェクトの「稼働時間単位あたりの社内人件費」、ということで、「社内人件費単価」という語を使うのは、別におかしくないのではないですかね。 SIer に勤務する者として違和感はありません。

一般的企業では、社内人件費は間接費として処理するものなのですかね。メーカーや小売業が、製品単位に社内人件費を原価として計上、というのは想像しずらいですし。

社内人件費が直接費になる、というのは、特殊な業界だけなのかもしれません。とはいっても、建設業、プラントエンジニアリング業など、請負工事を業としているところでは、同様にしているはずですが。

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

2008年7月24日 (木)

正規化は正しくない、かもしれない

「ノーマライゼーションはノーマルじゃない」の方が語呂が良いですね。

Never, never should you normalize a database out of some vague sense of duty to the ghosts of Boyce-Codd. Normalization is not magical fairy dust you sprinkle over your database to cure all ills; it often creates as many problems as it solves.

Maybe Normalizing Isn't Normal (Coding Horror)

データベースの正規化は、データベースの非正規化と同じくらいには、問題を引き起こすので、無分別に行なうべきではない、という論旨のようです。データーベースの正規化は、クエリのパフォーマンスを低下させ、理解しやすさを損ね、データベースを使いにくくすると。

私も同感です。何であれ、設計というのは、形而上学的に正しい解を求める過程ではなく、目的に手段を適合させる過程であると思います。データベース設計においても、ユーザが何を求めているのか、ユーザにどのような価値を提供しようとしているのかを、よくよく考えて行なうべきでしょう。自動的に解が見つかることはないでしょうね。

以下に、コメント欄を含めた、まとめがあります。

The Mother of All Database Normalization Debates on Coding Horror (High Scalability)

いくつか気に入ったものを意訳してみます:

Normalization is about optimizing large numbers of small CrUD operations, and retrieving small sets of data in order to support those crud operations.

...

Denormalization is about optimizing retrieval of large sets of data. Choosing an efficient database design is about understanding which of those operations is more important. (RevMike)

正規化は、大量の小さな挿入・更新・削除操作を行なう場合に使う。非正規化は、巨大なデータを取り出す場合に使う。データベース設計を効果的に行なうには、どういった操作が重要なのかを理解しなくてはならない。

Is my Site OLTP? If the answer is yes then Normalize. Is my site OLAP? If the answer is yes then De-Normalize! (WeAreJimbo)

OLTPなら正規化、OLAPなら非正規化が答えだ。

Be careful not to confuse a denormalised database with a non-normalised database. The former exists because a previously normailsed database needed to be 'optimised' in some way. The latter exists because it was 'designed' that way from scratch. The difference is subtle, but important. (Bob)

非正規化(denormalised database)と、無正規形(non-normalised database)を混同しないように。前者は既に正規化されたデータベースを「最適化」する。後者は初めからそのように「デザイン」される。違いは微妙だが、重要だ。

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

2008年7月22日 (火)

検証と証明

もし我々の考えている定理が、すべての数について真であることを示すかわりに、たとえば 6 なる数について真だということだけを示したいとすれば、段々になって流れている三段論法の滝のうちから最初の五つだけを証明すれば十分である。 ... もっと大きい数についてならば、もっとたくさんとらなければならない。しかしその数がどんなに大きくても、いつでも我々はいつかはそれに到達し得るから、それで分析的検証が可能である。

しかしながら、こうしてどこまで行っても、我々は決してすべての数に適用をみるような一般的な定理までにのぼることはできまい。 ... 形式論理だけに頼っている分析論者の忍耐によっては、いつまでたっても満たすことのできない深淵をとび越さなければならない。

ポアンカレ著, 河野伊三郎訳, 『科学と仮説』, 岩波文庫, 1959, p32-33

結局のところ、計算機プログラムを計算機上でいくら実行し、その結果が正しいことを 検証 したところで、そのプログラムが正しいことの 証明 とはならないでしょうね。現実の計算機は、有限のリソースによって制約されますから、計算機プログラムの取りうる状態は有限であるとはいえるのでしょうが、しばしば、全てを検証するには一万年あっても足りないというような大きさであったりします。

チューリング・マシンのような、概念上の計算機は、無限のリソースを持っているわけですが、計算機プログラムも概念的には、無限の状態を取りうるものであると、少なくとも、アルゴリズムの設計段階では考えるものでしょう。この段階で計算機プログラムの取りうる無限の状態に対して、計算機プログラムが正しいことを証明できなければ、計算機プログラムの正しさを保証するチャンスはないのかもしれませんね。

概念上、計算機プログラムの正しさを証明することができたからといって、現実の計算機プログラムの正しさまで保証されるわけではないわけですが。概念上、正しくない計算機プログラムは、現実にも正しくない、ということはいえますね。

計算機プログラムの正しさというのは、それが、現実に計算機上で実行される前には既に決まっていて、 その後、いくら計算機上で実行し検証したところで保証できないものである といえるのではないでしょうかね。

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

フローチャート不要論

を主張する人の、フローチャートの定義がいまいちよくわからなかったりしますが。

フローチャートというのは、状態遷移図の一種ですよね。この場合、プログラムカウンタ、あるいは、それを抽象化したものが状態変数になっていて、現在実行中のプログラムの「位置」が代わるごとに、状態が遷移していく様子を図式化したものだと思います。

フローチャートというのは、バッチ入力のコンピュータ・プログラムを記述するために、状態遷移図を「カスタマイズ」したのでしょうね。プローチャートと一言にいっても、実際には色々な形式があるようですが、基本的には、バッチ型の単純な逐次実行で行なわれる処理を記述するものだと思います。

フローチャートというのが、オンラインが主流の現在では、時代おくれなのは確かでしょうね。結局、イベント駆動型の非同期処理やら、並列処理やらを記述する必要性が出てきて、再び「ただの」状態遷移図へとかえったとみるべきかと。

とはいえ、バッチ的な処理がなくなったわけでもありませんので、そうした場合には、フローチャートは使いますけどね。フローチャート的な状態遷移図といったほうが良いかもしれませんけど。一種類のボックスと線しかなかったりしますから。

入力データチェックのシーケンスを書くことが、一番多いですかね。 x < a なら、 エラーXXX で、そうでなければ、 y < b をチェックして、等と延々と連なっているような処理。こうした処理では、チェックの順番が意味を持つことは多いですから、フローチャートですと表現しやすいですね。

ちなみに、状態遷移図といいますか、状態マシン/オートマトンは、近年、なかなか面白い展開を見せていて、モデル検査という分野に発展しているようです。2つ以上の異なるプロセスを表現したオートマトンを、「掛け合わせ」て、ひとつの巨大なオートマトンを作り、この全ての状態遷移をチェックすることで、デッドロック等の並列処理のバグを見つけ出そうというもの。2007年の ACM チューリング賞は、この分野の研究者が受賞していますね。


SPINモデル検査―検証モデリング技法 Book SPINモデル検査―検証モデリング技法

著者:中島 震
販売元:近代科学社
Amazon.co.jpで詳細を確認する


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

2008年7月18日 (金)

信じること、疑うこと

表面だけしかみない観察者にとっては、科学の真理は疑いの余地のないものである。科学上の論理は誤ることはないし、学者がときおり思いちがいをすることがあっても、それは論理の規則を見そこなったためである。

【略】

少しでも反省したものは、仮説の占める領分が、どんなに広いかということに気がついた。数学者は仮説なしではすまされないし、実験科学者はなおさらだということがわかった。そこで、はたしてこれらのすべての構築が極めて堅固なものであるかどうかが疑われ、わずかの微風にあっても打ち倒されてしまうと信ずるようになった。こういうふうに懐疑的になるのは、これもまた表面的な考えである。すべてを疑うか、すべてを信ずるかは、二つとも都合の良い解決法である、どちらでも我々は反省しないですむからである。

ポアンカレ著, 河野伊三郎訳, 『科学と仮説』, 岩波文庫, 1959

統計データの場合、真偽といいますか、妥当性はもっと微妙になるわけですけど。

調査会社出身の私が、WEB上の数字について一言 (Out of Order)

このソースで統計を語るのは (文系大学的IT系の悲哀)

「出典が営利企業だから」というのと、「統計でウソをつく法」の一般論だけで、妥当性を否定してしまうのは、あまりに「表面的」ではないですかね。具体的にデータのどこがおかしいかを指摘できなければ、反証とはならないでしょう。

すくなくとも、以下の主張は、データから語りうる範囲で、妥当なところだと、私は感じましたけどね。

見ていただいたらとおり、 日本IT業界が、日本他業種に比べ労働条件が劇的に悪いという統計は、あまり見つけることが出来ません。 むしろあったら教えてください。

この状況では、 IT業界の人が「僕たちの仕事は泥に塗れている!」などといっていては、他業種でがんばっている人たちに恥ずかしすぎて顔向けできません。

「日本IT業界」は比較的泥ではない事を統計的に検証 (西岡Blog)

平均賃金 (あるいは収入でも資産でも) というのは、確かに「統計でウソをつく法」の類で、必ず出てくる例ではありますけどね。

というようなわけで、平均賃金の数字を見たら、まず、質問することである ― 平均の種類は? その数字に含まれている人は?

ダレル・ハフ著, 高木秀玄訳, 『統計でウソをつく法』, 講談社ブルーバックス, 1968, p.22

まあ、サラリーマンの収入なんてのは、だいたい業種と企業規模で決まってくるわけでして、そんなに大きな変動はないでしょう。経営者なら、大きく変動するでしょうけど。情報サービス産業で、30〜35歳の平均年収が、400万〜500万円程度、というのは、妥当なところではないですかね。情報サービス産業内での賃金状況は以下にあります。

2007年版 情報サービス産業基本統計調査 「概要編」 (社団法人情報サービス産業協会)

おそらく、水準的には、小売業よりは高いが、製造業よりは若干低い、といったところでしょう。

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

2008年6月15日 (日)

ブロートウエアの法則とか、バッチ処理とリアルタイム処理とか

「100のうち50」でいいと言うと、大半のユーザにとっては「ほとんど全部」なんですね。

たとえば、あなたの会社のパソコンに誰かがイタズラをして、MS-Officeをアンインストールして、代わりに「100のうち50」のExcelやWordをインストールしておいたとしたら、あなたは気がつきますか?

たぶん、「100のうち50」のレベルでExcelを使っている人は、相当なパワーユーザです。職場では「Excelの達人」とか呼ばれて、「困ったことがあったらとりあえずあいつに聞け」と言われているような人で、ほとんどユーザはそれ以下でしょう。

だからMS-Officeは「100のうち50」で充分。

予告.inをSaaSワールドの予告として見る (アンカテ)

実際のところ、「100のうち50」どころか、ほとんどのユーザは、「100のうち20」のくらいの機能しか使わないでしょう。しかし、問題は、 ユーザによってその20が異なる、ということではなかったかと。もっと言えば、各ユーザにとっての「必須の機能」が、ユーザによって違っているわけですよ。

多くのソフトウェア開発者は昔ながらの「80/20」ルールに魅了されている。80%の人々は20%の機能しか使わない、というのは大いに意味があるように 見える。それであなたは20%の機能だけ実装すればよく、それでも80%は売れると思い込む。

残念ながら、それは決して同じ20%ではないのだ。みんな 異なる 機能セットを使っている。過去10年間、互いに学ばないと心に決めた 何ダース もの会社が、20%の機能だけ実装した「ライト版」ワードプロセッサをリリースしようとしたのを聞いてきた。

【略】

あなたが「ライト版」の製品のマーケティングを始めて、「どうです、軽いでしょう。たった1MBだ。」と人々に言い、彼らはとても喜んで、それが彼らにとって必須の機能を持っているか聞くが、それがないと分かると彼らは買わない。

ストラテジー・レターIV:ブロートウェアと80/20の神話 (Joel on Software)

「ExcelやWord」といったソフトウエアは、全世界に一億近いユーザがいて、そうしたユーザがそれぞれ異なる 20% の「必須の機能」を持っているわけですね。

ついでに、もうひとつ。

障害があって止まることは許されても、トランザクションの途中経過を外に見せることは許されません。上記の送金の処理中、口座Aから引いた直後にシステムが止まってそのまま復旧したら、私は無一文になってしまいます。

この「トランザクション」という制約の為に、単純な足し算引き算のプログラムを作るのに、凄く高度な技術が必要になります。

ところが、グーグルはこれを捨てています。

グーグルの「計算」は何がこれまでと違うのか (アンカテ)

トランザクション処理に、「凄く高度な技術が必要」になるのは、リアルタイムに応答しなければならないから、だと思います。

利用者がデータを入力したら、1秒以内に応答しなければならない、とかですよね。レスポンスタイムを短くするために、色々と複雑な仕組みが必要になってくるわけでして。そのために、スループットは犠牲とならざるを得なくなっています。

例えば、1,000人分のデータを処理する場合、レスポンスタイムが問題ではないのであれば、直列に処理すれば、スループットは最も高くなるでしょう。”1,000人分のデータを処理する時間”というのは、それが一番短い、ということです。その代償として、個々の利用者は、1,000人分のデータ処理が完了するまで待たされることになりますけどね。

GoogleがWebページをクロールし、検索インデックスを作る処理の場合、 レスポンスタイムよりも重要なのは、スループットであるはず です。巡回先の全Webページをインデックス化するのにかかる時間が問題のはず。

つまり、これは本質的にバッチ処理でしょう。 Googleのインデックス化は、相当高速には実行できるようになっているのでしょうが、それでも、(レスポンスの)リアルタイム性は要求されていないわけです。処理としては、大規模な科学技術計算などが近いのではないですかね。地球シミュレータでやっているような。

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

2008年6月 5日 (木)

プログラマの採用

PHPプログラマが見つからない、とお嘆きのようです。

We've been through all job sites, newspapers, local and foreign forums, and recruiting agencies, trying to find the candiate. We haven't found even one. At least three are needed right now. More will be needed in the nearest future.

Where did all the PHP programmers go? (Blog of Leonid Mamchenkov)

エントリ後半では、例のごとく、PHPという言語を攻撃し始めるのですが...

それよりも、”市場”で見つかる候補者の”質”についての部分が本質的のように思います。

What I cannot understand is why people with more than one Bachelor Degree in Computer Science recommend using bubble sort.

曰く、コンピュータサイエンスの学位を持っている人達が、バブルソートを使うことを薦める理由がわからない。

And what I don't understand is why technical people with years of team work, get pissed off or burst into tears when you ask them a technical question, and a simple one at that, during the job interview.

If you are wondering what sort of questions I've been asking, here is an example. A simple questions would be something like: "What is the difference between the stack (also known as FILO) and the queue (also known as pipe, also known as FIFO)?". Most of the answer is already in the questions, isn't it?

曰く、「スタックとキューの違いについて説明してくれ」 といったごく簡単な”技術的な質問”に答えられない。

アメリカでも、まともなプログラマが”市場”にいない、という話はときどき聞こえてきますよね。

どうしてプログラマに・・・プログラムが書けないのか? (Jeff Atwood / 青木靖 訳)

優れた開発者を見つけるには (Joel Spolsky / 青木靖 訳)

Joel Spolsky 氏の以下の見解には、私も賛成します。

優れたソフトウェア開発者というのは、実際のところ他の分野でも最高の人材というのは、単に マーケットには出てこない ものなのだ。

優れたソフトウェア開発者は、その全職歴を通して、 たぶん 平均で4回くらいしか職に応募しない。

【略】

数値的に言えば、優れた人々はごく少なく、彼らは決して求人市場に現れない。無能な人々は、たとえ彼らが 同じように数少なかったとしても、 その職歴を通して何千という職に応募する。だからねスパーキー、Craigslistの履歴書の山を見直してごらん。そのほとんどが雇う気にならないような人だったとしても、それは驚くようなことだろうか?

日本の場合は、もっと雇用流動性は低いわけですが。この辺の事情は同じだと思います。

優れた人は、責任のある仕事を任されるわけで、そうした仕事は一年や二年で終わったりはしませんし。普通、仕事が一区切りつくまでは、会社を辞めたりはしないでしょう。会社の側も、そうした人を簡単に手放したりはしませんしね。どこも、優秀な人は囲い込もうとするはず。私も基本そうします。

それに、優秀な人というのは、自分で動かなくても、色々なところから声がかかるでしょうから、そもそも、”市場”を通らずに、コネで職場から職場へと動くんじゃあないかとも思います。

プログラマを雇おうとする側からみると、雇用流動性などというようなものには全く期待できない、と思います。結局、”市場”よりコネじゃないですかね。

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

2008年6月 4日 (水)

自社開発でノンプログラミングを実現

『システム開発 JOURNAL Vol.4』(毎日コミュニケーションズ, 2008.5) の特集「作らない開発」で、NECビッグローブの事例が取り上げられているのですけど。

曰く、

  1. 機能を徹底してAPI化
  2. 独自の ESB (Enterprise Service Bus) を構築
  3. API呼び出しのための、独自の言語(マッピング言語) を作成
  4. 画面構築には、 Visual Frame を採用

によって、ほぼノンプログラミングを実現したとか。

最初に全体を見通してユースケース分析を徹底的に行います。そして、必要な機能や画面の分析を詳細に行い、その結果を図表形式で書くことが、NECビッグローブの社員の仕事です。

でまあ、「実際の開発はパートナーに任せています」ということだそうで。

一方で、

自社のシステムを自分たちで作っているため、ノウハウを蓄積して部品などを用意できました。外部に委託した開発ではこうした動きをとることは難しいでしょう

ともおっしゃっているわけでして、何だか矛盾している感じではあるのですけど。この場合、システムのアーキテクチャやコアコンポーネントについては、自社で開発したということなのでしょう。一度出来てしまえば、拡張は容易なため、拡張モジュールの開発、画面構築は外注している、となりますかね。

プログラミングの理想というのは、”一度作ったら同じものは二度と作らない”というものでもあるわけでして、自社に理想的なソフトウエア・アーキテクチャを開発することができれば、プログラマは不要になる、ということなのかもしれません。ある意味では、プログラマの仕事というのは、プログラマを不要とするための仕事、ということでもあるような。

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

2008年6月 3日 (火)

三菱東京UFJ銀の障害は切り替えミス?

『日経コンピュータ』(2008.6.1) 「ニュース&トレンド」に1ページの記事が載っていました。何でも、「未来バージョン」のモジュールを誤ってリリースしてしまったとか。

今回の障害で、セブン銀ATMで使えなくなったキャッシュカードは、旧東京三菱銀のものなのだそうでして、旧UFJ銀のものは問題なく使えていたとのことです。もともと、統合前にはセブン銀との接続は以下のようになっていたとか。

  • 旧東京三菱銀 : NTTデータのCAFIS 経由で接続
  • 旧UFJ銀 : 「直結方式」で接続

システム統合では、旧東京三菱銀のシステムを、旧UFJ銀の方式へと、変更することになっていたそうで、旧東京三菱銀のカードについては、以下のように段階的リリースの計画となっていたそうです。

  • 5月 : 従来どおり、CAFIS経由で統合システムに接続
  • 6月 : 直結方式で統合システムに接続

5月の統合作業で、電文中の案内文部分を設定するモジュールを、6月リリース予定のものにしてしまったのが、今回の障害の原因となったとあります。

この話のとおりであるとしますと、もともと、セブン銀のATMというのは:

相手先 接続方式 案内文の設定
旧東京三菱銀 CAFIS経由接続 半角カナ
旧UFJ銀 直結方式接続 かな漢字

と、相手先によって異なる仕様を持っている、ということになりそうなのですけど。利用者からみると、使うキャッシュカードによって、利用明細の案内文が半角カナで印字されたり、かな漢字で印字されたりする、ということになりますか。そういうものなんですかね?

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

汎用機からPCへ、バッチからオンラインへ

汎用機上に作られたシステムのほとんどは、以下のようなものであろうと思います。

  1. バッチ処理のシステム
  2. COBOLで書かれている
  3. フラットファイルをプログラムからプログラムへと順に受け渡して処理が進む

一方で、汎用機でもオンライン・トランザクション・システム(OLTPシステム)というのは、存在していたわけでして、有名なところでは、旧国鉄・現JRの マルスシステム(予約・発券システム) ですとか、銀行のオンラインシステム といったものがあります。

第1次オンライン化は、1960年代後半から70年代前半にかけて推進された個々の銀行の本支店をオンラインで結ぶというエレクトロニクス化である。第1次オンライン化では、金融機関のコンピュータ・センターと本支店の端末が結合され、当座預金、普通預金などの勘定科目ごとのオンライン処理がすすめられた。このような勘定系のオンライン化は1960年代後半から都市銀行を中心に始まった。この第1次オンライン化により金融機関の事務コストが減少しただけでなく、同一金融 機関内であればどの店舗でも預金の預入、引出ができるようになった(経済 企画庁総合計画局(1991)による。)。今日では当たり前の、このようなサービスもコンピュータの導入により、即時に他支店にある勘定の残高が判明し、そこから引き落しなどができるようになったため、初めて実行可能となった。また、現金自動支払機(CD、Cash Dispenser)の使用や公共料金の自動引き落し、給与振り込みなどのサービスが普及したのも第1次オンライン化の推進と並行している。今日では自動引落は当然のごとくうけとられているサービスであるが、アメリカのように自動引落が行われていない国もある。わが国では、電話料金(昭和30年)などの公共料金に始まり、税金(昭和42年)や各種会費,クレジットカードの支払いにまで普及している自動引落はこの第1次オンライン化によって利用可能になったのである。

銀行の第1次オンラインについて

1960年代後半から1970年代前半にかけては、OLTPシステムの基礎技術を確立した時期であるとされており1、この時代、日本の情報システムは、世界的にも最先端のレベルにあったのであろうと思います。また、この時代は、データベース・システム、トランザクション処理システムといった、”ミドルウエア”は当然存在していなかったわけでして、このレベルのソフトウエアから、手組みで開発していたのではないでしょうか。

OLTPシステムの標準化・オープン化が始まったのは、1980年代末から1990年代にかけてとされています1。この時期は、情報システムの”ダウンサイジング”が始まった時期とも一致していたわけでして、汎用機からUNIX機、さらにはPCへとシステムのハードウエアが変わり、また、汎用機上のシステムをUNIX機、PCへと移行することになったわけです。このときに、単に汎用機上のバッチ処理システムをそのまま異なるハードウエアへと移行するのではなく、クライアント・サーバ(C/S)型のシステムへと”再構築”して移行したのです。つまり、バッチからOLTPへと処理形態も変わったわけでして。

もともと、汎用機の時代から、OLTPシステムというのはプログラム開発の難度が高いとされていたのですよね。特に初期のオンラインシステムでは、データベースやトランザクション処理からスクラッチ開発していたわけですから、当然でありましょう。C/S型システムが主流になったときには、すでにRDBMSパッケージが存在していたわけで、一番難しい部分をスクラッチする必要はなくなってはいたわけですが、それでもバッチ処理に比べれば難しいのは当然であったと思うわけです。

その後、C/S型システムから、Webアプリケーションへと、システムの主流は移り変わってきたわけですけど、OLTPシステムという処理形態は変わっていないのですよね。変わったのはフロントエンドなわけですけど、この面では、むしろ汎用機時代の中央集中処理へと回帰しているともいえるわけでして。実際、 タンデム・コンピュータ の NonStop システムなどは、現在の Enterprise Java のアーキテクチャにかなり似ていて、フロントエンドに”スクリーンCOBOL”なる言語を使うのはご愛嬌というものですが、フォールトトレラントの部分なんかは、今でも先進的に感じますね。

最初のシステムは T/16(後に NonStop I と改称)である。システム設計は1975年に完了し、最初の製品は1976年にシティバンクに売られた。

【略】

NonStop I は、システムのフェイルオーバモード実現の鍵であった独自オペレーティングシステム Guardian を搭載していた。他社はフェイルオーバーを実現する際に他のCPUでプログラムを再始動させていたが、Guardian では全ての処理はメッセージパッシングを使い、全ての操作でチェックポイントが設定された。結果として Guardian ではプログラム中の任意の位置から処理を再開することができる。これにはスタックベースのプロセッサがほとんど内部状態を持っていないために、プロセスをCPUからCPUに移動しやすいという点も影響している。全ての命令はスタックからデータを取り出し、演算結果をスタックに戻す。演算中に障害が発生したら、スタックを他のCPUにコピーして失敗した命令から処理を再開することができる。

タンデム・コンピュータ (Wikipedia)


1. 渡辺榮一、J・グレイ他著, 『OLTPシステム』, 近代科学社, 1995

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

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月27日 (火)

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

しかし、月平均の就労時間が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月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)

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日 (日)

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)

2008年5月 4日 (日)

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

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

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

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

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

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

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

・要求仕様があいまい

・業務分担があいまい

・契約があいまい

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

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

である。

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

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

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

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

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

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

| | コメント (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月25日 (金)

「約8万ものテストケース」

はてなブックマークで人気エントリーに入っているこの記事。みなさん、それだけ注目しているということでしょうか。

例えば最終確認テストにおいては約8万ものテストケースをこなし,本番に向けては200のサブシステムについてそれぞれ232項目の移行判定基準を確認する。単体テストが終了してから8カ月もSE集団を抱え込んでテストと確認を繰り返す姿は鬼気迫るものがある。だが,それでも「必ず動く」とは言い切れないのがシステムの世界である。

6000人が作ったシステムは必ず動く (ITpro)

テストケース8万は少ないな、と感じたのですけど。”最終確認テスト”ですから、一つのテストケースの粒度はかなり大きいと考えるべきなのでしょうね。全サブシステムを横断して、かつ、最重要なケースに絞り込んだようなものを考えれば良いのですかね。サブシステムの網羅は当然やっている前提でしょう。

例えば:

2n = 80,000

とします。対数をもち出すまでもなく、プログラマであれば:

216 = 65,536

がすぐに出てくるでしょう。8万のケースというのは、2値状態を持つものが約16個程度あれば、全網羅で到達する数なのですよね。

また、6,000人という数字がありますから:

80,000 ÷ 6,000 ≒ 13

一人当たり13ケース程度しかできないとしますと、ひとつひとつのケースは相当大きいのでしょう。

しかし、”人力テスト”というのは、母集団に対してごく少数のケースしかカバーできないのですよね。そろそろ限界に来ている感はあります。

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

2008年4月19日 (土)

データベース正規形とSQL

データベース設計でテーブル正規化を行なう理由のひとつは、リレーショナル演算をスムーズに行なえるようにしたいからですね。つまり、データ処理を、もっぱらSQLを使って行なう、という設計戦略になるかと思います。

しかしながら、リレーショナル・データベースのテーブルをフラットファイルや、あるいは、索引付きファイルとして扱っても、それはそれで、ひとつの設計の考え方といえます。この場合、SQLの力を有効に使うことは難しくなりますので、データ処理は、もっぱら、ホスト言語となっている、なんらかのプログラミング言語を使って行なうことになるでしょう。テーブルは、リレーショナル・モデルではなく、本当に単なる”ファイル”である、というわけです。

正規化したテーブルが、プログラマに嫌がられるのは、リレーショナル・モデルが敬遠されているということであり、ひいては、SQLを使ってデータ処理をするのを嫌がっている、という見方ができます。

プログラマがSQLを嫌う理由は、本質的には、SQLが逐次実行型のプログラミング言語ではないから、かもしれませんね。メジャーなプログラミング言語のパラダイムとは、大分異なっているのは確かです。SQLというのは、”集合型言語”とでもいうべきものでありまして、独特のパラダイムを持っています。集合演算を中心とした言語、というのは、他にあまりないような気がしますね。関数型言語のリスト処理などは、近いとは思います。こちらもあまりプログラマには親しまれてはいませんね。

リレーショナル・モデルを使わないのなら、 RDBMSを使うのは、選択ミスともいえるわけですが。 RDBMS が一番入手しやすいという現実がありますからね。リレーショナル・モデルを使わなくても、トランザクション管理、メタデータ管理、 バックアップ、 レプリケーションなど、 DBMSで使いたい機能というのはあるわけでして。昔のように、TPモニタ(Transaction Processing Monitor)と、索引付きファイルとでOLTPを実現する、なんていうのはないでしょう。

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

2008年4月15日 (火)

プログラム設計書を書く目的

例えば、誰が書いても同じコードにするために、プログラム設計書(内部設計書)を今、書かせているとしたら、そんな無駄なものはやめたほうがいいと思う。

浜口さんに贈るSI業界を良くする方法 (ひがやすを blog)

プログラム設計書を書く目的というのは、”仕様の確実な伝達”ではないですかね。"誰が書いても同じコードにするため”ではないように思います。結果として、誰が書いても同じコードにはなるでしょうけど。設計書にある擬似コードをそのままコーディングすれば、同じになりますからね。

設計書の擬似コードと異なるプログラム・コードを書いても、別にかまわないはずです。

ただし、

設計書の擬似コード ≡ プログラム・コード

であることを、プログラマ自身が証明しなければなりません。表現の異なる2つのプログラムが、equivalent であることが、常に証明できるものなのかどうか、私は知りませんけど。

結局のところ、プログラムの仕様とは何で、それを伝えるためには、どうすればよいのか、というのが問題なんですよね。抽象的な文言というのは、その背後にあるコンテキストを共有していなければ、”正しく”解釈ができないわけでして。コンテキストを抜きにして、仕様を伝えようとすれば、結局、仕様とコードは表現が限りなく近くなってしまう、というジレンマがあります。プログラム・コードというのは、コンテキストのない表現の見本みたいなものですから。

プログラマに、システム化対象の専門領域について、コンテキストを共有してもらう、というのは、確かにひとつの手段なのですが。私には、プログラマがそれを望んでいるか、確信がもてなかったりします。プログラマは、プログラミングのために、”必要最低限の情報”を求めているようにも思えます。それが擬似コードであるというところが、なんだか、皮肉な感じではあるのですけどね。

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

2008年4月12日 (土)

コミュニケーション・コストを減らす方法

だからプログラマが仕様を決めちゃえばいいんだよ。そのほうがいいに決まってる。マネージャはユーザーの立場に立って要件を抽出しそれを固めていくことに邁進すればいい。プログラマはその要件を元に「それならこれで出来ます」という仕様を決めて、後は全部自分が実装までやればいい。本来、システム開発は要員が少ないほうがいいと思う。多すぎるとコミュニケーションコストが高すぎて死ねる。

プログラマが仕様を決めればいい (GoTheDistance)

システム開発を行なうのに、こうしたコミュニケーション・コストの高い方法が使われているのはなぜか、ということを考えますと、本質的には、システム開発に必要な情報量が膨大であるから、ということになるかと思います。この膨大な情報量を持つ”仕様”を、コンピュータに入力するため、”高すぎる”コミュニケーション・コストを支払っているのでしょう。

開発体制

システム開発というのは、典型的には、以下のような階層型の体制で行なわれます。

Article_20080411_01

顧客、SE(システムエンジニア)、PG(プログラマ)の3種類しかありませんが。SEのところは、マネージャーなり、コンサルタントなり、適当に読み替えても変わりません。要は、ドキュメントを書く人: SE、コードを書く人: PG という分け方です。

顧客と開発側の階層トップに位置するSEとが、仕様について打ち合わせ、決定した仕様を、下の中間層SEへと、担当別に分配して流します。さらに、中間層SEがその下のPGへと、各自の担当分に分配して流します。仕様は、上から下へと流れるだけではなく、各階層で概要から詳細へとより具体化され、情報量が増やされていきます。また、そうして各階層で作成された成果物は、階層を下から上へと上り、顧客の手に渡ります。

さて、上の図からSEをすべてはずし、顧客とPGだけを残しますと。

Article_20080411_02

顧客は、膨大なコミュニケーション量の前に押し潰されてしまいますね。このような多数と、コミュニケーションをとり、膨大な情報量を処理していくのは、不可能でありましょう。

結局、膨大な情報量のコミュニケーションを処理するために、間に入る人間が増えてしまうわけでして。SEがPGになったところで、本質は変わらないでしょうね。コーディング作業と、他とのコミュニケーションのための作業(結局はドキュメント書きになりそうですが)を両方やるということにはなりますけど。

仕様の情報量を減らさないことには、根本的な解決にはなりそうもありません。

仕様の抽象度

以下のように、顧客とPGとが、1対1で開発する体制を仮定しまして。

Article_20080411_03_3

要件として、弾道計算を行なうプログラムを考えます。仕様としては、以下の4段階とします。番号の大きなものほど、より具体性のある仕様、ということになります。

  1. 弾道モデルを表す微分方程式
  2. 微分方程式の数値解法(アルゴリズム)
  3. 弾道モデルの微分方程式の数値解を得るロジック
  4. 弾道計算のプログラム・コード

3番目の”ロジック”というのは、日本語で書いた擬似コードのようなものを想像していただければ。この例の微分方程式に対し、アルゴリズムを適用した結果です。

さて、顧客の仕事としては、どこまでの仕様を作れば良いでしょうかね。プログラマは、どのレベルの仕様があれば、そこからプログラム・コードまでの仕事をできるでしょうか。

SI現場の現実から考えますと、最低限、3番目まではやらないと、プログラマは仕事ができないでしょうね。それでもおそらくは不足でして、計算の具体例を何点かと、テスト・データも作成して渡してあげないと駄目でしょう。さもなくば、”わかりません”と言われておしまいです。

また、出来上がったプログラムは、顧客自身で、仕様どおりになっているか、チェックする必要があります。プログラマに渡した例を確認するのはもちろん、渡していない例も確認しないといけませんね。不具合が見つかった場合には、どのようなデータの場合に、どこがどのように間違っているのか、どうなるのが正しいのか、具体的に(”ロジック”のレベルまで落として)プログラマに教えなくてはなりません。さもなくば、”再現できません”と言われておしまいです。

どうすればいい?

結局、プログラマがもっと賢くなればよい、などという結論がでそうです。しかし、それは、人類全体の知的レベルをより引き上げるにはどうすればよいか、と問うようなものでしょうね。ある職業に従事するもの全員の知的レベルを引き上げる、というのは、そういうことかと思います。

できるとすれば、仕様を抽象的記述から具体的記述へと、機械によって変換することくらいでしょう。今のプログラミング言語よりも、より抽象的な言語は実現可能か、ということになりそうです。

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

2008年4月10日 (木)

インターフェイスとしてのリレーショナル・モデル

でも、経験的には、外部インターフェイスが同じであっても内部インターフェイスは、少なくともプログラムの場合は異なる。

データベース(端的にはテーブルのスキーマ)はどうだろうか? 同じだよなぁ。

結果は同じでも過程が異なる (L'eclat des jours)

まさにそのとおり、ですね。

リレーショナル・モデルの範囲内で考えると、"外部インターフェイス”として、唯一使えるのがビューになるわけですが。ビューは基本的に検索にしか使えないわけで、そうしますと:

  • テーブル: 挿入・削除・更新
  • ビュー: 検索

といった形にしかならないのですよね。

結合操作でできたビューが更新可能になる、というのは、現実の製品では聞かないですね。もし可能な製品があったとしても、導出元のテーブルを意識しないわけにはいかないでしょう。特に挿入と削除を行なう場合には。

・・・

テーブルが増えると、SQLクエリのJOIN句が複雑化してしまうという意見もあるが、羽生氏は「サブクエリやOUTER JOINがスラスラ書けない人は、DBの設計をすべきでない」と断言する。DBの設計は、プログラムの都合を一切忘れて行わねばならない、というのが氏の主張するところである。

DBは超グローバル変数、どう設計するか (マイコミジャーナル)

データベースをそうやって設計して、ユーザ/プログラマに「さあ、使ってください」という段階になって、”サブクエリやOUTER JOINがスラスラ書けない人”がユーザ/プログラマである場合は、どうしましょうか。

Who Needs Theory - Just Give Me The Data

Because most of what programmers do has no theoretical basis or system of proof, programmers back away from anything that looks like hard math. Failure to understand and appreciate relational theory has launched countless bad databases (and thousands of witless articles condemning SQL).

Why Programmers Don't Like Relational Databases (Typical Programmer)

アプリケーションで使う全てのクエリを、データベース設計者が書いて、プログラマに渡すとか。

内部設計の工程では,「詳細クラスモデル」 「SQLモデル」 「物理データモデル」を部分的に自動生成し,「共通詳細クラスモデル」を人手で作成する。

システム開発の業務プロセス自動化とは? (ITpro)

あるいは、O/Rマッパー(のようなもの)を使うとかですかね。それは、リレーショナル・モデルの”外”になりますけども。それこそ、オブジェクト指向のような、プログラミング・モデルで、リレーショナル・モデルを隠してしまう、という考えは、昔からありますね。3層C/Sモデルみたいな。

しかし、何か”屋上屋”な感じがして仕方がなかったりします。

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

2008年4月 4日 (金)

データベース正規化・非正規化

データ・モデリングの普及団体,DOA+コンソーシアムはこのほど,リレーショナル・データベース管理システム(RDBMS)の処理性能に関する実証試験を行い,調査結果を公開した。「データを正規化してデータベースに実装すると,処理性能が低下する」という"誤解"を正すため,実証実験を行ったという。

「DBを正規化すると遅くなる」は誤解,実証実験の結果が公開に (ITpro)

正規化(非正規化)すると早く(遅く)なる、という命題の立て方はどうかと思うのですけどね。

実証実験の結果,データベース上の単一テーブルを対象に検索した場合,いずれのパターンも2〜3ミリ秒で処理を終えた。一方,3つ程度のテーブルにわたりデータを検索した場合,正規化したパターンでは,5000万件のデータを90ミリ秒で検索できた。だが,非正規化したパターンでは,500万件のデータ検索に14秒かかった。

テーブルを非正規化したい理由としては、ユーザー/プログラマが結合操作を嫌う、というのは、よくあるんじゃないですかね。ですので、比較するなら、1テーブルに非正規化・集約したテーブルから検索する場合と、正規化した3テーブルを結合してから検索する場合とを比較するのが、妥当ではないかと思うのですが。この場合、得られるものが全く同じとすれば、非正規化の方が、おそらく処理速度は早くなるでしょうね。

非正規化というのは、正規化がまずあって、行なうものであるわけでして。非正規化によってメリットが得られないのであれば、それを非正規化というのは、どうなんでしょうね。単なる、”失敗作”であろうと思うのですが。

この手の話というのは、よくあるわけでして:

  • オブジェクト指向では、すべてをオブジェクトにするのが正しい。よって、使用する全ての項目について、クラス定義を行なう(しかも、それがリモート・オブジェクトだったり)。
  • 関数呼び出しをすると、呼び出しのコストの分、処理が遅くなる。よって、関数は使わずに、ひとつのルーチンにすべてを詰め込む。

設計というのは、相反する要求の間のトレードオフを考慮しつつ、最適な解を見つけ出そうとする活動なわけでして、一律にこうすべき、ああすべきなどとはいえないと思います。与えられた要件とその優先順位によって、解は異なるでしょう。

データベースの正規化というのは、データベースの拡張性・柔軟性を最大限に引き出すための、設計手法ですよね。それによって、失われるものというのは:

  • 検索の処理性能
  • 単純さ、あるいは、理解のしやすさ

といったものになると思います。

この二つは関係があって、デザインがプログラマにとって、複雑で理解しにくいものになっていたり、データの取得方法として、クエリを何通りにも書けたりすると、プログラマが性能の悪いクエリを書く可能性は、それだけ高まります。SQLクエリというのは、本番データ上で、実行してみなけりゃわからないところがあるのも現実です。コストペース・オプティマイザのように、データの統計情報によって、実行パスが変わるような場合は特に。

単純さ、理解のしやすさという点でも、テーブルの結合操作というのは、結構嫌われるのですよ。データベースの 正規化 vs 非正規化 というのは、オブジェクト指向でいう、小クラス主義 vs 大クラス主義 に通じるものがあるんじゃないですかね。

最後の手法が軽そうで良いなと思ってAPIリファレンスを眺める。

すると、javax.toolsがいかにも面倒そうなのでうんざりする。このうんざり感の原因には小クラス主義(1責務1インターフェイスあるいは、サブジェクト主義と名付けたくなる何か)にあるのだなということがわかる。

つまり、目的主義でAPIを眺めると、その目的にたどりつくまでのステップが多過ぎる。

その一方で、1責務1インターフェイスというのは、ケチのつけようがない考え方だと考えている自分にも気づく。

Javaのメタプログラミング (L'eclat des jours)

データベースにも、ファサドを作る方法というのはあって、ビューやストアド・プロシージャを使えば良いのですが。これはこれで、また新たな問題をもちこむことになるんですよね。

そんな単純な話じゃないよ、ということで。

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

2008年3月23日 (日)

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

@IT の記事です。

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

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

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

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

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

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

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

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

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

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

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

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

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

| | コメント (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月 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)

2007年12月 3日 (月)

Googleのソースコード管理システム

--- Googleは非常に合理的なエンジニアリングを行っているという印象が強いのですが・・・・・・ソースコードの管理については、PERFORCEというソースコード管理システムを用いて、全社で1つのリポジトリを共有しているんですよね。

鵜飼- そのとおりです。

『Special Interview Googleの開発現場』, システム開発 JOURNAL Vol.1, 毎日コミュニケーションズ, 2007/11/29, p.130

ということで、Googleが使っている、SCM(=VCS?)は以下の製品みたいです。

Perforce Software - The Fast Software Configuration Management System

Linus Torvalds が Subversion を滅茶苦茶にけなしているらしい、以下のエントリより。

大規模プロジェクトが多そうな、Google や MS はどういうVCSを使っているのかな?教えて中の人(もしくは知っている人)

Subversion - ひげぽん OSとか作っちゃうかMona-

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

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日 (土)

プログラマが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月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年9月20日 (木)

外部設計書記述ガイドライン

 NTTデータ、富士通などシステム開発会社九社は十八日、情報システム設計図の書式統一に向けたガイドラインを発表した。システム設計の初期段階で顧客が理解できるようにするため、わかりやすい設計図に統一するよう業界各社に促す。
 システム障害に迅速に対応したり、開発費が膨らむのを防いだりするには、顧客ニーズとシステム機能の食い違いを早期に発見・修正できる仕組みが不可欠と判断した。

「設計図統一へ指針 システム概要、顧客と共有」, 日本経済新聞, 2007年9月18日, 13面

「発注者ビューガイドライン(画面編)」は、Webシステム開発の画面部分に関する外部設計書について記述方法のガイドラインを定めたもの。東京証券取引所とAGSにヒアリングし、ガイドラインに反映した。SIベンダのSEと、発注者企業の情報システム部門・業務部門の担当者を利用者として想定している。

外部設計書の記述方法を標準化、NTTデータなど9社が提唱 - @IT

発注者ビューガイドラインは画面編、システム振舞い編(仮称)、データモデル編(仮称)の3編により構成されます。往々にして発注者と開発者との意識のズレや、発注者や開発者が互いの意図とは異なる理解をしたことに気づかないまま開発が進んでしまうことがあります。本ガイドラインは、このような状態を防止するために作成したものです。本ガイドラインでは設計書や関連する資料の表現や確認方法、レビューの方法を「コツ」として集約し、外部設計工程における生産物の単位に整理しています。

発注者ビューガイドライン(ダウンロード可能), 発注者ビュー検討会, NTTデータ 

実物にざっと目を通した感想です。

これは、汎用機時代以来の、伝統的な外部設計書の内容についてのガイドラインですね。Webシステム開発が題材(Java Pet Store)となっていますが、内容は、汎用機、C/S、Webと、昔から受け継がれてきたものだと思います。

「顧客ニーズとシステム機能の食い違いを早期に発見・修正できる仕組み」というのとは、少し違うような感じです。むしろ、伝統的なノウハウの継承のため、という印象です。これはこれで、大変意義深いものだと思います。ですが、近年のシステムの高機能化、複雑化、なにより社会基盤としての重要性が増していることを考えると、伝統的なアプローチだけでは力不足のように思います。

設計・検証・実装・テストを、より密に結びつけるような手法があると良いのですが。

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

2007年9月19日 (水)

郵政民営化・分社化に伴うシステム開発

日経コンピュータ 2007年9月17日号(日経BP社)の特集、「実録!郵政民営化」 より。

今回は、民営化の「暫定対応」とのこと。概略として、以下のような数字が出されています。

総開発規模 4万3000人月
総開発費用 1000億円
システムで利用するメインフレームの台数 130台以上
アプリケーションの総ステップ数 1億ステップ

郵便貯金のシステムというのは、社会保険庁の年金システムと並んで、データ量が日本トップクラスの規模である、という話が、以前、取り上げられていたように思います。奇しくも、両システムともに、「政治問題化」したわけですが。

内訳は以下のとおりで、やはり、貯金が一番大きく、次が簡保となっていますね。金融関係のシステム開発では、数千人月という開発規模は珍しくないようですが、それに比しても、やはり巨大な感じですね。

1) 日本郵政
 郵政総合情報通信ネットワーク PNET : 598億5000万円
 管理系システム(人事・財務など) : 5000人月
2) ゆうちょ銀行
 貯金システム : 2万3000人月
3) かんぽ生命
 保険システム : 1万2000人月
4) 日本郵便
 郵便システム : 2000人月
5) 郵便局
 局会社システム : 1000人月

貯金システムの開発スケジュールは、以下のとおりです。

2005年春 ~ 要件定義・設計
2006年1月~ 実装・単体テスト
2006年8月~ 総合テスト
2007年1月~ 全体テスト
2007年5月~ 本番稼動

2005年4月から開始したとしますと、設計・実装・テスト、それぞれの期間は、9ヶ月・7ヶ月・10ヶ月。割と普通な感じですね。

ちなみに、”bewaad institute” さんのブログでこのネタを思い出したのですが。

3年前、作業着手以前に立てた42,000人月との見通しからすれば、わずか1,000人月の超過(+2.4%)でやりとげたというのは、なかなか立派なプロジェクトマネジメントだったのではないでしょうか。

arnさんのいる場所は暗黒卿はすでに約3年前に通過しているッ! | bewaad institute@kasumigaseki

元記事の図(画像)をよくみると、4万3000人月のところに、注がついておりまして。

※1 PNETは除く。プロジェクト開始前の見積もり。実際はさらに増加している。

4万3000人月は実績ではないようです。1000人月分は、その後の検討で増えた予算でしょうか。

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

2007年9月12日 (水)

「システム障害と闘う」

本日の日経新聞に、「企業とIT システム障害と闘う 上」という記事が掲載されていました。

冒頭で、全日空のシステム障害が取り上げられています。

・・・
百三十便が欠航になり、七万人を足止めにした五月二十七日の大規模障害の”犯人”は通信機器に内蔵されたたった一個のメモリー部品の故障。ごく一部が狂うだけで全体に大きな影響が及ぶ「ガラス細工」のようなIT(情報技術)システムのもろさが露呈した。
・・・
実はメモリー部品の故障の予兆を担当者らは障害発生の前日につかんでいた。にもかかわらず対応を先送り。実際に障害が起きた時も別のシステムが原因と勘違いし四時間強を無駄にした。ガラス細工と隅々に目を凝らし、問題に適切に対処できる人材をどう育てるか。長期戦は必死だが「コストはかかってもやりぬく」(広報・総務担当の長瀬真専務)覚悟だ。
・・・

「企業とIT システム障害と闘う 上」, 日本経済新聞,2007年9月12日, 13面

ネットワークのスイッチ等の通信機器を原因とするシステム障害というのは、原因の特定が遅れて長時間に及び、大規模なものとなる傾向があるように思います。全日空のシステム障害の原因となったのは、シスコ製のスイッチだそうです。こうしたアプライアンス(ハード・ソフト一体で販売)型の機器は、”ハード”として扱われ、運用保守もメーカーにお任せになっていたりして、ユーザからは盲点になりがちなのかもしれません。

・・・
スイッチは米シスコ製でNECが納入、ICSは日本ユニシスが開発と機器納入、ATCPは東芝グループが開発と機器納入、をそれぞれ担当した。もっとも「トータルとしてANAサイドの判断が遅かった。どこのメーカーが悪いと言及もしていない」(同)と語り、ANA側に一定の責任があることを認めている。ネットワークの設計や構築はANAのグループ会社が行っている。
・・・

【会見詳報】ANA障害の原因判明、「世界4例のスイッチ故障がきっかけ、対応も遅れた」:ITpro

オープン系のシステムというのは、多くの異なるベンダーによって、機器が提供されるがゆえに、競争原理が働き、価格が安くなっているわけですが。反面、システムに関わるベンダーの数は、大規模なシステムでは、相当なものになります。システム障害の際には、ユーザは自身の手で障害の原因を突き止めなければ、担当のベンダーがどこなのかもわからない、ということになります。

・・・
システムが大規模化し複雑になるにつれ「落とし穴」の数も増えたが、それを管理する人の体制が追いつかない。NTT東西の五月二十三日の障害ではサーバーのハードディスク交換の際に大文字で書くべきコマンドを小文字で書くという人為ミスが原因になった。
・・・

「企業とIT システム障害と闘う 上」, 日本経済新聞,2007年9月12日, 13面

細かいところですが、ここは、「小文字とすべきを大文字」じゃないのかな。。。

・・・
間違えたのは、「コマンドの引数」(NTT-ME ネットワークビジネス事業本部ネットワークソリューション事業部IPソリューション部門担当部長の黒田敦氏)。本来、小文字とするところを大文字にしてしまったのである。そのシステムを提供するベンダーから「大文字を使うと重大な問題が発生する」という連絡は届いていたが、現場の担当者まで伝わっていなかった。
・・・

NTT東のフレッツ・トラブル,「ルート再計算により・・・」の真相:ITpro

*nix系OSの、ある種のコマンドでは、小文字・大文字の別で意味が逆になる、というルールが使われていたりしますが。それに倣ったものなのかもしれませんね。

・・・
連絡不徹底など反省すべきことであるが、大文字/小文字を間違えただけで大きな問題につながるとは、そのシステム自体も問題である。そのような“怖い”コマンドは入力できないようにするのがシステム側の役割であろう。
・・・

NTT東のフレッツ・トラブル,「ルート再計算により・・・」の真相:ITpro

ごもっとも。しかし、OSやファームウエアなどの”低レベル”なソフトウエアでは、「そのような“怖い”コマンド」が結構あるんですよね。サーバのファイルシステムを破壊してしまった人を見たことがあります(lnコマンドの引数を逆にしたのですが)。自分でも、コマンド操作は結構日常業務でやるんですが、深刻な”ミス”を自分でやったことは今のところないんですよね。我ながら不思議な感じがしています。

・・・
工場で働く一人一人に品質管理への強い意識を持たせることで世界最強の工場を育ててきた日本企業。ITを競争力の源泉に育てるには同様の知恵と努力が欠かせない。
・・・

「企業とIT システム障害と闘う 上」, 日本経済新聞,2007年9月12日, 13面

ややおざなりな感じのまとめ方ですけども。ユーザサイドとしては、運用体制の強化を考えるしかないのかもしれません。私は、”「ガラス細工」のようなITシステム”であることが真の問題であって、それを、運用側の努力でカバーするのも限界があるかな、と思います。

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

2007年6月26日 (火)

実際のディスク障害

大規模ITシステムの実運用から、ディスク障害の特性を調査した論文です。

Disk failures in the real world: What does an MTTF of 1,000,000 hours mean to you?

日経BP社ITProに、日本語の要約があります。

ハードディスク・ドライブの故障率に関する事実, ITpro 

論文の内容は、大きく分けて、前半でディスク障害に関する一般的内容を、後半でディスク障害が発生する時間的特性(故障間隔)を扱っています。

ここでは、前半部分からいくつか抜粋しておきたいと思います。

1) 平均故障時間 (MTTF)の定義について

Drive manufacturers specify the reliability of their products in terms of two related metrics: the annualized failure rate (AFR), which is the percentage of disk drives in a population that fail in a test scaled to a per year estimation; and the mean time to failure (MTTF).  ... The MTTF is estimated as the number of power on hours per year divided by the AFR. ... The MTTFs specified for today's highest quality disks range from 1,000,000 hours to 1,500,000 hours, corresponding to AFRs of 0.58% to 0.88%.

2.2 Specifying disk reliability and failure frequency

年間の時間数を、年間故障率(AFR)で割った値が、平均故障時間 (MTTF)になります。上の例にある、MTTF100万時間と150万時間についていいますと、以下のようになります。

  (24時間 * 365日) / 0.0088 ≒  100万時間

  (24時間 * 365日) / 0.0058 ≒  150万時間

MTTFは年間故障率の別の表現であって、語感から想像されるような、ハードウエアの寿命については何も語っていないということですね。

2) 年間交換率(ARR)

In contrast, in our data analysis we will report the annual replacement rate (ARR) to reflect the fact that, strictly speaking, disk replacements that are reported in the customer logs do not necessarily equal disk failures

2.2 Specifying disk reliability and failure frequency

この論文では、年間交換率(ARR)を、年間故障率(AFR)の代わりとしています。これは、実際に運用しているシステムからデータを得る関係上、このようにせざるを得なかったのでしょうね。

上記のとおり、ARRはAFRとは等しくなく、例えば、故障がなくても交換を行なうことがあります(予防的交換)。

Many sites follow a ``better safe than sorry'' mentality, and use even more rigorous testing. As a result, it cannot be ruled out that a customer may declare a disk faulty, while its manufacturer sees it as healthy. ... In fact, a disk vendor has reported that for 43% of all disks returned by customers they find no problem with the disk .

2.1 What is a disk failure?

ディスク・ベンダーが、顧客から戻ってきたディスクを調べると、43%は「問題なし」であった、という事実が指摘されていますね。

3) 調査結果

Observation 1: Variance between datasheet MTTF and disk replacement rates in the field was larger than we expected. The weighted average ARR was 3.4 times larger than 0.88%, corresponding to a datasheet MTTF of 1,000,000 hours.

4.1 Disk replacements and MTTF

本調査でのARR実測値は、ディスク・ベンダーのAFRカタログ値に対し、加重平均で3.4倍あった、とのこと。

一定の目安にはなるかもしれません。

Observation 2: For older systems (5-8 years of age), data sheet MTTFs underestimated replacement rates by as much as a factor of 30.

Observation 3: Even during the first few years of a system's lifetime (< 3 years), when wear-out is not expected to be a significant factor, the difference between datasheet MTTF and observed time to disk replacement was as large as a factor of 6.

この辺は、意味があるのかどうか...分からないですね。

Observation 4: In our data sets, the replacement rates of SATA disks are not worse than the replacement rates of SCSI or FC disks. This may indicate that disk-independent factors, such as operating conditions, usage and environmental factors, affect replacement rates more than component specific factors.  ...

SATAの交換率は、SCSI、FCよりも悪くはない。ディスク規格よりも、オペレーションや利用環境の方が故障に与える影響が大きいのではないか、とのこと。

ディスクそのものの品質とディスクの接続規格には、関連はないのかもしれませんね。

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

2007年5月27日 (日)

プロジェクト・マネジメントの極意

MOZANさんの記事より。「ベビーシッティング」という言葉があるんですね。「箸の上げ下げまで」という感じでしょうか。

サブコンは最低金額で仕事を落札してきたものだけが選ばれるが、もちろんコストを下げた最低金額にするために、サブコンはその仕事に出来る限りお金をかけないようにする。だから、仕事も手抜きになるし、マネジメントによる管理も弱くなる。すると、彼らに代わって元請けであるゼネコンが時間をかけてそのサブコンを管理しなくてはいけなくなる。業界では「ベビーシッティング」つまり、「赤ちゃんの面倒をみる」という言い方をする。

...

建設に限らず、全てのプロジェクトの大半の時間は「待ち」と「コーディネーション」に消えるという事実はここにある。工程計画表のほとんどが役に立たないのもコレが理由。コストとロスタイムは同等なので、工程表に従った厳しい管理は逆に「管理費」というコスト上のロスが生じる。 ...

MOZANBLOG: 安い施工会社は本当に安いのか, May 26, 2007

岸良 祐司 著「目標を突破する実践プロジェクトマネジメント」(2005, 中経出版)という本にも、これと似た話が出てきます。

...単価に注目したコストダウンには落とし穴があることも教えてもらった。工事原価を下げるために安い作業員を使うと、逆に管理や手直しに手間がかかることが多く、下手をすると納期が遅れてしまうことも多々あるという。

...

...もしも不幸にも2日の遅れが発生したとしよう。するとたった2日でトータルのコストは540万円に跳ね上がってしまう。これこそ、「安物買いの銭失い」だ。

p.128-129

ITシステム開発のプロジェクトも同様だと思います。個々のタスクを早く確実に完了させていくことが、プロジェクト成功の決め手なのでしょうね。

私が、オフショア開発と国内開発、どちらがコスト面で優位か、一概には言えないと思うのが、これがあるからです。オフショア開発は、単純に人件費の単価では、非常に有利ですが、管理コストとロスタイムは、結構大きなものがあると思います。国内開発の場合は、逆の構図になりますね。

結局、インド・中国の企業との競争も、マネジメント力と技術力の勝負ということになるのではないですかね。楽観はできませんけど、あまり悲観的になる必要もないと思っています。

---

CD‐ROM付 目標を突破する 実践プロジェクトマネジメント Book CD‐ROM付 目標を突破する 実践プロジェクトマネジメント

著者:岸良 裕司
販売元:中経出版
Amazon.co.jpで詳細を確認する

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

2007年5月 5日 (土)

ブロートウエアと民主政治

”bewaad institute@kasumigaseki”さんの以下の記事。面白いと思いました。

議会政治をMS Wordに擬えてみる

まあ、MS-Wordが売れている理由は、いわゆる”ネットワーク効果”の故であって、MS-Wordの機能によるものではないとは思います。商用ワープロソフトの機能はどの製品も大同小異だと思いますし。

「ネットワーク効果」は顧客が多ければ多いほど、より多くの顧客を得ることができる、という状況のことだ。

ストラテジーレターⅠ: ベン&ジェリー 対 アマゾン - Joel on Software

ブロートウエアの生まれる理由を考えれば、共通点は出てくるかな、と思います。つまり、商用ソフトウエアの機能は、なぜ肥大化するのか、ですね。

正確にはブロートウェアとは何だろうか?The Jargon Fileは悪意に満ちた定義をそれに与えている。「小さな機能に対し割の合わないほど多くのディスクスペースとメモリを要求するソフトウェアのこと。とくにアプリケーションやOSのアップグレードに対して使われる。この言葉とその現象は、Windows/NTの世界で非常に一般的である」


多くのソフトウェア開発者は昔ながらの「80/20」ルールに魅了されている。80%の人々は20%の機能しか使わない、というのは大いに意味があるように見える。それであなたは20%の機能だけ実装すればよく、それでも80%は売れると思い込む。

残念ながら、それは決して同じ20%ではないのだ。みんな異なる機能セットを使っている。過去10年間、互いに学ばないと心に決めた何ダースもの会社が、20%の機能だけ実装した「ライト版」ワードプロセッサをリリースしようとしたのを聞いてきた。これはPCの歴史と同じくらい古い。…


あなたが「ライト版」の製品のマーケティングを始めて、「どうです、軽いでしょう。たった1MBだ」と人々に言い、彼らはとても喜んで、それが彼らにとって必須の機能を持っているか聞くが、それがないと分かると彼らは買わない。

ストラテジーレターIV: ブロートウェアと80/20の神話 - Joel on Software

ソフトウエアの機能を決める際、ユーザ、マーケティング、記者などの意見を聞くと、間違いなく、ソフトウエアはブロートウエアとなります。意見を聞く人が増えれば増えるほど、ソフトウエアの機能は肥大化して、「重く」なるでしょう。

私は50人くらいの関係者の意見をとりまとめて、ソフトウエアの機能リストを作り、開発したことがあります。機能リストは恐ろしい量で、なかには、互いに矛盾するようなものも含まれていました。もちろん、出来上がったのは、とんでもなくブロートなソフトウエアでした。

ブロートウェアを嫌悪する人達に言わせると、優れたソフトウエアをデザインする唯一の方法は、ひとり(または少数)の優れたプログラマが誰の意見も聞かず、彼の独断のみによって、デザインすることだそうです。UnixやC言語は、そのようにデザインされた、というのが引き合いに出されます。

独裁者が統治する場合、「無駄」はなくなるでしょう。彼の人が「無駄」と考えることは行なわれなくなりますから。それを多くの人に納得させることができるかどうかが、彼の人の優秀さの証でしょうね。うまく行く場合は、ユーザの熱狂的な支持を得ることが多いと思います。

民主的に統治を行なう場合、つまり、多くの人の意見を聴き、それを反映させるならば、肥大化は避けられず、多くの人が「無駄」と思うものが含まれるようになるでしょう。「軽くしてくれ」という意見だけは、決して実現されることはないでしょうね。

「無駄な政策」が多いのは、民主主義がある程度は機能しているという証なのかもしれませんね。

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

2007年4月29日 (日)

プログラミング言語 Erlang

@ITの”NewsInsight”で取り上げられていますね。

twitterブームの陰で注目を集める“Erlang” - @IT

Erlangは、並列処理を得意とする、関数型の言語のようです。

Here's the good news for Erlang programmers:

    Your Erlang program should just run N times faster on an N core processor

Is this true?

What's all this fuss about Erlang? by Joe Armstrong

Nコアにすると、プログラムがN倍早くなる、という宣伝文句。まあ、これは、ちょっと言いすぎ(”we're optimistic”)のようですが。

Why do our programs just run faster?

It's all about mutable state and concurrency

関数型言語のコンセプトとして、「状態を持たない/副作用がない」というものがあったと思います。副作用がない言語を、”純粋”関数型言語とか呼んでいますね。これが並列処理と相性が良い、というのは、「副作用がない」ということの実用的かつわかりやすいメリットですね。この点、従来はやや衒学的な説明が多かったように思います。

PragDave: A First Erlang Program

”Pragmatic Programmer”な方々が注目しているようですし、これは普及するかもしれませんね。

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

2007年4月27日 (金)

Open Source Flex

アドビ・システムズのWebリッチクライアント開発ツール、Flexがオープンソース化するそうです。

Adobe is announcing plans to open source Flex under the Mozilla Public License (MPL). This includes not only the source to the ActionScript components from the Flex SDK, which have been available in source code form with the SDK since Flex 2 was released, but also includes the Java source code for the ActionScript and MXML compilers, the ActionScript debugger and the core ActionScript libraries from the SDK. The Flex SDK includes all of the components needed to create Flex applications that run in any browser - on Mac OS X, Windows, and Linux and on now on the desktop using “Apollo”.

Developers can use the Flex SDK to freely develop and deploy Flex applications using either Adobe Flex Builder or an IDE of their choice.

Flex:Open Source - Adobe Labs

Flex2で、SDKが無料提供されており、ActionScriptコンポーネントのソースコードが利用可能になっていますが、それに加え、ActionScript/MXMLコンパイラ、同デバッガ、ActionScriptコアコンポーネントのソースコードが利用可能になる予定とのことです。ライセンスは、Mozilla Public License(MPL)になるそうです。

最近は、リッチなWebアプリケーション構築案件の引き合いが増えてきています。Flex+サーバサイドJavaという組み合わせは、有力な選択肢になるかもしれませんね。オープンソース化のニュースは、Flex普及の後押しになりそうです。

この領域では、今は.Netが強いようですが、この選択肢が対抗馬になれば有難いですね。Windowsプラットフォームの縛りがないのが良いです。

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

2007年4月26日 (木)

最大最難の「メディアリスク」

日経BP社ITProに掲載されている記事です。

最大最難の「メディアリスク」(1)74年前に指摘された「三原山型観念的社会記事問題」

最大最難の「メディアリスク」(2)システム障害を巡る記事の書き方、教えます

最大最難の「メディアリスク」(3)マスコミが金融庁に与えた「権力」

最大最難の「メディアリスク」(4)マスコミを徹底して嫌ったIBM会長

”最大最難の「メディアリスク」(1)”で、以下のように問題提起されています。

メディアリスクという言葉を聞いたのは、ある勉強会の席上であった。情報システムに関連するあるトラブルを起こした企業の幹部が、トラブルの経緯を振り返りつつ、冒頭のように仰った。その方によれば、「顧客、警察、監督官庁、社内外関係者、すべてに応対しなければならなかったが、一番厄介なのがメディアだった」という。

 厄介だという理由をこの幹部はこう説明された。「会見や個別取材で、どれだけ時間をかけて説明しても、まったくこちらの主張を分かってくれない。というより、そもそも理解しようという姿勢にない。記者のほうが結論を用意していて、それに合うコメントだけを取って帰ろうとする」。

マスメディアが、あらかじめ立てた「筋書き」にそって、取材をおこない記事にする、という話は昔から指摘されているところです。昔と異なるのは、その報道の影響の大きさでしょうか。

最近ですと、不二家を巡る一連の報道が「メディアリスク」現実化の一例かもしれませんね。

TBSの捏造報道として問題になっている「賞味期限切れのチョコレート再利用」の件だけでなく、他局の報道に出てきた以下の問題は事実無根である。

    * 3秒ルール
    * カビの生えたケーキや床に落ちたケーキを販売
    * 虫混入とか金属片混入とか

アンカテ(Uncategorizable Blog) - 不二家捏造報道問題: バッシングでつぶしてしまえばテレビ局の勝ち?

確かに不二家自身の最終報告書を読みますと、メディアの報道とは大分ニュアンスが異なるようです。

不二家からの大切なお知らせ:第2回「信頼回復対策会議最終報告」記者会見

まあ、こうして当事者のコメントを直接知ることができるのも、昔とは異なるところではありますね。

昔なら、マスコミにコメントを求められるというのは恐怖感を覚えるほど覚悟のいることだった。何を書かれるかわかったもんじゃないという不信感がある。だが、今はまあどうでもいい。日記に本意を書いておけばいいのだから。

高木浩光@自宅の日記 - 新聞の意味不明な識者コメントはデスクの解釈で捏造される

”最大最難の「メディアリスク」(2)”は、メディアの仕事のパターンをマニュアル風に書いたもので、なかなか皮肉が利いています。

本来は、システム障害の原因をきちんと取材すべきだが、それについては深追いする必要はない。障害直後は原因を特定できていないことが多く、きちんとした説明がされない(できない)からである。そもそも記者の多くは情報システムの仕組みを理解していないので、説明があったとしてもよく分からない。

 むしろ、当事者ではなく、システムに詳しい識者に電話し、「今回のシステム障害をどう思われますか」と聞く方が効率的である。コメントを集め、「『内部管理の抜本見直しは避けられない』との声も上がっている」「基本的な手順をおろそかにしていたと批判されても仕方ない」と書く。記者の主張ではなく、「識者がそう言っている」と取られるように書くことが大切である。

 いきなり電話を受けた識者の中には、「原因が特定できない以上、今は論評できない」「大騒ぎをすればするほど、システム開発を担当する技術者たちが萎縮してしまい、かえって危険」といった、“使えない”コメントをする人がいる。こうした人は、識者リストから外しておく。

”最大最難の「メディアリスク」(3)”は、かの有名な某銀行システム障害のときの話。ITサービス業の人間であれば、このときの記事を読んだ人は多いと思います。

1985年にバンク・オブ・ニューヨークが情報システム障害で倒産寸前に追い込まれたとき、議会で証言したニューヨーク連銀のジェラルド・コリガン総裁は、「関係職員の疲労」に言及したという。

 今回のトラブルについては、議会証言もあった。テレビや新聞において、猫も杓子も発言した。だが、コリガン総裁のように、現場の担当者の疲労について言及した人はどれだけいたのであろうか。

この一件に限らず、現場で不眠不休で必死に働いた方々への配慮というのは、あまり見受けられないように思いますね。

柳澤伯夫金融担当相(筆者注、当時の肩書である)は4月24日、「某銀行から(情報システム統合の進捗について)虚偽の報告を受けた」とまで発言した。ほとんど犯罪者扱いである。

(・・・)

メディアの「中の人」である方が、こうした問題意識をお持ちであるというのは、心強いことだと思います。

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

2007年4月11日 (水)

Assembler as a Service

ツボでした。ありがとうございます。

これで、出先のネットカフェで突然x86のハンドアセンブルが必要になっても安心だ。

秋元@サイボウズラボ・プログラマー・ブログ: x86アセンブラ on ブラウザ

Intel社と共同で世界発のマイクロ・プロセッサを開発した、嶋 正利氏が日経BP社ITProで、当時の回顧録を掲載されていますね。「4004 Dr.嶋ブログ」の内容をこちらに移したのですかね。

【当時の勉強ノートを公開】世界初のCPU「4004」開発回顧録(1)それは電卓の価格競争から始まった:ITpro

世界初のCPU「4004」開発回顧録(2):ITpro

同サイトより、嶋 正利氏のプロフィールです。

ビジコン在籍中に米Intelと共同で世界初のマイクロプロセッサ4004を開発したほか,Intelで世界初のパソコンを生んだマイクロプロセッサ8080を,ZiLOGでZ80,Z8000などを開発。

このあたりの話は、「インサイド・インテル」という本に出ていましたね。


古典電脳物語―8085,Z80,CP/M,タイニーBASIC… Book 古典電脳物語―8085,Z80,CP/M,タイニーBASIC…

著者:鈴木 哲哉
販売元:ラトルズ
Amazon.co.jpで詳細を確認する

こちらは、往年のマイコンを自作したという人のお話です。マイコン時代の歴史についても簡単に触れられています。

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

2007年4月 9日 (月)

オンラインストレージ“Dropbox”

Subversionリポジトリの、オンライン・ストレージ・サービスがあると便利なのに、と考えたことがありましたが。それに近いサービスみたいです。

OSのファイルシステムに統合され、Windows上からは通常のフォルダとして扱えるオンラインストレージサービス「Dropbox」の詳細が明らかになった。Dropboxは、複数のPCから同一フォルダが扱えるだけでなく、バックアップや変更履歴管理、ローカルファイルシステムと完全な透過性を備えた高機能なオンラインストレージサービスだ。

HDD以上に便利なオンラインストレージ“Dropbox” - @IT

ローカルファイルシステムとネットワーク上のストレージが、自動で同期するというのは、便利でしょうけど、危険でもありそうですね。

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

2007年4月 7日 (土)

モデルと現実と

「レジデント初期研修用資料: 現場の狂気と教科書の正気」 より。いつもお世話になっています。

正しい教科書は正しいやりかたを教えてくれない

医療ならどの分野でもそうだろうけれど、現場でやってることは、教科書にはほとんど書いていない。

日経コンピュータだったか、オブジェクト指向ソフトウエア開発が「先進的事例」として紹介されていた記事で、以下のような発言がありました。

「(オブジェクト指向の)理論どおりなのにうまくいかなかった」

リモート・オブジェクトを使用した開発で、それが、EJBだったかCORBAだったかRMIだったかは忘れてしまいましたけど。なんでも、「ひとつの項目をひとつのオブジェクトとする」のが「理論どおり」だとかいう記事でしたね。

まあ、「すべてをオブジェクト」にするのは、オブジェクト指向のひとつの考え方としてあるわけですが、「すべてをリモート・オブジェクト」にするのは、問題ありすぎるのは、少なくとも今では常識でしょう。その記事が掲載された当時でも、現場感覚からすると、ありえない感じではありましたけど。

Session Facadeパターンは、EJBコンポーネントの利用に際して、最も広く定着しているベストプラクティスの1つである。実のところ、このパターンは、 CORBAやEJB、DCOMなどのあらゆる分散テクノロジー分野で用いられている普遍的なルールを表したものだ。つまり、アプリケーションにおける「ネットワークの横断」をなるべく減らすという原則である。これにより、細かなデータがネットワーク上を何度も行き交うことによるオーバーヘッドの発生を防止できる。

@IT:J2EEのベストプラクティス・トップ10(後編)

もうひとつ。ソフトウエア開発プロセスに関するウォーターフォール・モデル。これは、現場の開発者には評判の悪いモデルです。

一般に理解されるウォーターフォール・モデルは手戻りを許さない逐次開発型であるため、工程間のフィードバックが必然的に発生する実際のソフトウェア開発という作業の実情にそぐわないとの批判も多い。また、ウォーターフォールはプロジェクト管理に膨大な手間がかかること、システム開発の短納期化へのニーズが強いことなどから、反復型開発手法などと折衷したモデルなども提唱されている。

ウォーターフォール・モデル - @IT情報マネジメント用語事典

私個人としては、ウォーターフォール・モデルは、ソフトウエア開発プロセスの「静的な構造」を明確にしたと言う点で、高く評価しています。ひとつのモデルとして。

現実を無理矢理にこのモデルに合わせようとする人達が出てきてしまったのが、このモデルの評判を落としてしまいましたね。それだけこのモデルが、(素人にも)わかりやすいものであったわけで、現実をうまく抽象化したという点で、モデルの評価を高めるものだとは思います。

理論と現実というのは異なるもので、現実は理論どおりではないというのは、当たり前のことだとは思います。技術者は、理論と現実のギャップを埋めるのが、その役割であると思うのですけどね。技術者が理論を言い訳にするのは、本末転倒のような気がします。

しかし、技術者にも説明責任が求められる昨今ですから、理論と現実のギャップをどう説明するのか、悩みどころです。現実を無理矢理にでも理論に合わせれば、説明が楽になるのは確かなのですけど。

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

2007年4月 4日 (水)

RAIDの基本(2)

前回、1988年RAID黎明の時のリサーチを取り上げました。基本的な特性は変わらないとは思いますが、なにしろ20年近く前の話ですので、比較的最近のものを探してみました。

日本HP HP ProLiant Benchmark 付録B: Exchange Server 2003テスト(2005年)

Hewlett-Packard社製品のベンチマーク結果です。

これは、Microsoft社のメールサーバ製品である、Exchange Serverをシミュレートした負荷テストの結果です。RAIDレベル0、1+0、5、6の4つのRAIDレベルをテストしています。この中から、RAID1+0とRAID5を比較してみたいと思います。

テストはいくつかの構成・パターンで行なわれていますが、ここでは、以下の構成・パターンで比較してみます。

  • 15krpm、36 GB、U320 SCSIドライブ10台を搭載したMSA30エンクロージャを、Smartアレイ6402コントローラに接続
  • 14のJetstressスレッド

テスト結果は以下のとおりとなっています。

[RAID 1+0]
転送速度: 1409 Transfers/秒
読み取りレイテンシ: 0.015秒
書き込みレイテンシ: 0.0019秒

[RAID 5]
転送速度: 1127 Transfers/秒
読み取りレイテンシ: 0.01869秒
書き込みレイテンシ: 0.00373秒

RAID5の性能はRAID1+0の8割程度となっています。

IOについては、おおよそ、「65:35の読み取り/書き込み比率の作業負荷」となっているそうです。読み取りに関しては、両RAIDレベル間で、ほぼ差はないと考えると、RAID1+0からRAID5への、書き込み性能低下は4割程度あるかもしれません。

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

2007年4月 3日 (火)

RAIDの基本

Wikipedia(en)より。

In computing, the acronym RAID (originally redundant array of inexpensive drives (or disks), also known as redundant array of independent drives (or disks)) refers to a data storage scheme using multiple hard drives to share or replicate data among the drives. Depending on the configuration of the RAID (typically referred to as the RAID level), the benefit of RAID is to increase data integrity, fault-tolerance, throughput and/or capacity, compared with single drives.

コンピュータ分野で、RAID-元はredundant array of inexpensive drives (or disks)の略であり、redundant array of independent drives (or disks)の略でもある-は、複数のハード・ディスク・ドライブを使用した、データ・ストレージの仕組みであり、複数ドライブで同一データを共有します。RAIDの構成方法-通常、RAIDレベルと呼ばれる-によりますが、単一のドライブに比し、信頼性、耐障害性、応答速度、収納効率で優れています。

RAID. (2007, April 1). In Wikipedia, The Free Encyclopedia. Retrieved 11:19, April 3, 2007

同記事で、RAIDという言葉を最初に使用したのは、"David A. Patterson, Garth A. Gibson and Randy Katz”であるとされています。

The term RAID was first defined by David A. Patterson, Garth A. Gibson and Randy Katz at the University of California, Berkeley in 1987. They studied the possibility of using two or more drives to appear as a single device to the host system and published a paper: "A Case for Redundant Arrays of Inexpensive drives (RAID)" in June 1988 at the SIGMOD conference.

ここで紹介されている、"A Case for Redundant Arrays of Inexpensive drives (RAID)"という1988年の論文は、ネット上で入手できるようです。

"A Case for Redundant Arrays of Inexpensive drives (RAID)"(PDF)

RAID1~RAID5まで挙げられていますが、現在使用されているのは、RAID1(ミラーリング)と、RAID5(パリティ分散)だけですので、この2つについて、リサーチの内容を見てみたいと思います。

まずはRAID1の特性から。

MTTF: 4,500,000 hrs or >500 years
Total Number of Disks: 2D
Overhead Cost: 100%
Useable Storage Capacity: 50%

I/Os/Sec vs. Single Disk          Full RAID   Per Disk
 Large (or Grouped) Reads/sec     2D/S        1.00/S
 Large (or Grouped) Writes/sec    D/S          .50/S
 Large (or Grouped) R-M-W/sec     2D/3S        .33/S
 Small (or Individual) Reads/sec  2D          1.00
 Small (or Individual) Writes/sec D            .50
 Small (or Individual) R-M-W/sec  2D/3         .33
 
Characteristics of Level1 RAID, p.10

これは単純な二重化ですので、ディスクがシングルの倍必要になります。

読み取りはシングルの2倍早くなっているのは、二重化したディスクからパラレルに読み出すからだそうです。書き込みは、シングルと同じになっています。これは、ディスク1台に書き込んだら、制御を戻し、ミラーの完了は待たずに処理を完了させるからだそうです。

次はRAID5の特性。ディスク11台(データ10台、チェック1台)の場合です。

MTTF: 820,000 hrs or >90 years
Total Number of Disks: 1.10D
Overhead Cost: 10%
Useable Storage Capacity: 91%

I/Os/Sec vs. Single Disk          Full RAID   Per Disk
 Large (or Grouped) Reads/sec     D/S         .91/S
 Large (or Grouped) Writes/sec    D/S         .91/S
 Large (or Grouped) R-M-W/sec     D/2S        .45/S
 Small (or Individual) Reads/sec  (1+rC)D     1.00
 Small (or Individual) Writes/sec (1+rC)D/4   .25
 Small (or Individual) R-M-W/sec  (1+rC)D/4   .25

Characteristics of Level5 RAID, p.18

RAID5の場合、パリティを格納するため、常に1台余分のディスク容量が必要になります。データがディスク10台なら11台で、1.1倍ですね。

MTTFはRAID1の2割ぐらいに落ちています。RAID1は、最大半分のディスクが壊れても大丈夫ですが、RAID5は2台壊れたらそこまでですので、こんなものでしょうね。なお、ディスク26台(データ25台、チェック1台)の場合も載っていて、"MTTF 346,000 hrs or 40 years"となっています。ディスクを倍にすると、MTTFは半分という感じですね。

さらに、"Large (or Grouped) R-M-W/sec"(読み取り-変更-書き込み)が、シングルの約半分の速度、"Small (or Individual) Writes/sec"、"Small (or Individual) R-M-W/sec"が約四分の一の速度となっています。

サーバ機のストレージは、大抵RAIDを使用していると思います。このRAIDのレベルですが、サーバ機の初期設定ではRAID5となっていることが多いようです。ハードメーカーとしては、低コストで冗長化できることをアピールしたいのだろうと思います。

しかし、RAID5は、基本的には、「安かろう悪かろう」であることを忘れてはいけないと思います。特に少量の書き込みが大量に発生し、かつ高い信頼性が求められる、データベース・サーバには、全く向きませんね。

RAID5は、結構、適応が難しいのではないでしょうか。

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

2007年3月31日 (土)

情報処理技術者が不足?

2007年3月27日付けの日経新聞朝刊の記事です。

厚生労働省によると、情報処理技術者の一月の有効求人倍率(パートを含む常用雇用ベース)は、3.68倍。全職種平均の1.09倍を大きく上回っており、同分野の技術者不足が鮮明になっている。

「転職サイト各社 『情報処理技術者』に重点」, 日本経済新聞, 2007年3月27日朝刊15面

2月の値で見ると、情報処理技術者の有効求人倍率は3.71倍、全職種では1.09倍となっていますね。

厚生労働省:一般職業紹介状況(平成19年2月分)について:職業別一般職業紹介状況[実数](常用(含パート))

他の職種の値も併せてみますと、上から6番目に位置しています。

建設体工事の職業 6.25

医師、歯科医師、獣医師、薬剤師 6.11

機械・電気技術者 4.74

保安の職業 4.67

接客・給仕の職業 3.84

情報処理技術者 3.71

長期時系列表からグラフを作ってみました。

Graph20070331_1

 








2年ほど前に3倍を超えたみたいですね。

現場でも不足感は相当あります。中国系・インド系の技術者の方も良く見かけるようになりましたね。今後、国内だけで技術者が充足することはないように思います。

今後を見据えれば、オフショア開発も必要なのは確かでしょうね。オフショア開発は、良く見受けられるような、安く買い叩くような発想ではなく、かの地の技術者の方々と、長期に渡るパートナーシップを築く考えで進めるべきと考えます。

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

2007年3月29日 (木)

自動車制御OS

今朝の日経新聞一面で取り上げられていました。

 トヨタ自動車はパソコンの基本ソフト(OS)に相当する自動車搭載用の標準ソフトウエアを独自開発する。自動車はIT(情報技術)化が急速に進展。ソフト開発に必要な人員やコストが膨らんでいる。トヨタは世界の自動車大手に先駆けて標準ソフトを導入して開発を大幅に効率化、安全など今後の技術高度化に道を開く狙い。

「自動車制御 トヨタが標準ソフト」, 日本経済新聞, 2007年3月29日朝刊一面

以前、レクサスの制御を行なうソフトウエアが1,000万ステップを超えるとかで、話題になっていましたが。自動車の世界でも、ソフトウエア開発の量は急速に膨張しているようですね。携帯端末などの組み込み系ソフトウエアでは、OSはもちろん、データベースなどのミドルウエアも既に使用されているようですから、驚くような話ではないのかもしれません。

 標準ソフトは電子制御の基本機能を担い、車に搭載する数十の超小型コンピュータ(マイコン)に共通して使える。これにエンジン、ブレーキ制御など個別機能に対応する応用ソフトを組み合わせる。

このあたりが、自動車独特の感じがしますね。汎用コンピュータや、同じ組み込み系でも、家電製品の場合は、電子制御が主、メカは従となってシステム全体を制御するのでしょうが。自動車の場合は、メカが主で電子制御は従という位置付けなのでしょう。パソコン・家電製品などのエレクトロニクス分野でのOSのイメージとは、幾分異なるように思います。

 現在一台の車には平均四十個程度のマイコンが搭載されている。トヨタの最高級車「レクサスLS460」は衝突防止のためにレーダーやセンサーを駆使。搭載マイコンは約百個に上っており、今後も自動車のコンピュータ化は急ピッチで進むとみられている。
 それに伴いソフトの開発量も急増。車種によってはソフト技術者を五百人動員しても開発に二年以上かかるという。プログラムの欠陥が原因となる不具合も増え、品質検査の作業も大きな負担になっている。

500人×2年=12,000人月ですか。凄まじいですね。現代が「ソフトウエアの時代」であることを実感する記事でした。

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

オフショア開発の誤謬

日経BP社ITproに対照的な記事が掲載されていました。

「オフシェア並みの料金でお願いしたい」。最近、こんなシステム商談が増えていることにITサービス会社の経営者らは危機感を募らせている。…

ところがユーザーから「30万円」と言われれば、極端に言えば新人の給与も支払えない事態になる。「30万円は無理です」となれば、ユーザーはオフシェアへとなる。…

TISの岡本社長の心配事:ITpro Watcher,  2007年03月28日


あるオフショアのケースでは,当初,日本国内委託に比べて40%のコスト削減になる計画だったものが,オフショア開発の失敗により反対に60%もコストが増え,納期も半年遅れ,日本側リソースがフォローに当たったために別のプロジェクトチャンスも失った例があります。

海外アウトソーシングでパフォーマンスは本当に上がるのか:ITpro Watcher, 2007年03月27日

「ソフトウエア開発を、中国・インドなどの人件費の安い国に委託することで、開発費が半額以下になる。」

などというのは、あまり現実的な考えではないでしょうね。どうも値下げ要求の理由付けに、こうした誤謬が良く使われるようですけど。

案件を海外に出す場合、国内よりも高度なマネジメントが必要になるでしょう。また、翻訳・貿易関係の手続きなど、国内で開発する場合には必要のない作業も色々と増えるようです。結局、15%程度コストが削減できれば成功、というのが現実的みたいですね。


コミュニケーションや見えない管理作業などのオーバーヘッドを考慮すると、国内開発と比べてオフショア開発の作業効率はかなり悪くなります。米調査会社META Groupは、「オフショア開発におけるコスト削減率は15%程度」とレポートしていますが、この数値は私の経験とも一致しています。

@IT情報マネジメント:なぜ、中国オフショア開発の見積もりは高いのか?, 2004/11/12

単純に技術者の人件費単価だけで比較すれば、国内開発はオフショアに太刀打ちできませんが、工期・管理コストという点では、国内の方が有利でしょう。建設業の世界では、コスト削減に最も有効なのは、人件費の単価を減らすことではなく、工期の短縮であるとされているそうです。

人件費の単価だけを取り上げるところに、オフショア開発の誤謬があるように思います。

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

2007年3月16日 (金)

社会人基礎力-職種別分析【IT系】より

経済産業省が、”企業の「求める人材像」調査2007~社会人基礎力との関係”というアンケート調査を結果を公表したそうです。

経済産業省調査結果、IT系は「情況把握力」、「ストレスコントロール力」が不足 - ナレッジ!?情報共有・・・永遠の課題への挑戦 [ITmedia オルタナティブ・ブログ]

ソースは以下で、私も目を通してみました。

企業の「求める人材像」調査の結果について~社会人基礎力との関係~ 報道発表(METI/経済産業省)

IT系職種について、以下のようにまとめられていますね。

職種別分析【IT系】

○求める社会人基礎力は、「考え抜く力」が最も高く、唯一全職種平均を上回っている。また、不足が見られる社会人基礎力については、「前に踏み出す力」の不足が最も目立っており、「チームで働く力」とともに、不足の度合が全職種平均を上回っている。

○要素別では、「課題発見力」、「情況把握力」、「創造力」などが、全職種平均に比較して高く求められている。そのうち、「情況把握力」、「ストレスコントロール力」の不足が、全職種平均に比較して目立っており、ニーズが高い能力といえる。

確かに、「情況把握力」、「ストレスコントロール力」の不足が指摘され、ニーズが高い能力とされていますね。

情況把握力
自分と周囲の人々や物事との関係性を理解する力
例)チームで仕事をするとき、自分がどのような役割を果たすべきかを理解する。

ストレスコントロール力
ストレスの発生源に対応する力
例)ストレスを感じることがあっても、成長の機会だとポジティブに捉えて肩の力を抜いて対応する。

素朴な疑問ですが、ストレスってコントロールできるものなのでしょうかね。私の印象だと、もっぱら本人の性格によるという気がしますが。ストレスに強い人というのは、周囲の人間のことを、あまり気にしない人だと思います。良くいえばマイペースな人。IT業界には、そういうタイプが多いような気がします。

そうすると、「情況把握力」なるものとは衝突しそうですね。周りを気にするタイプの人は、プレッシャーからくるストレスに負けてしまうことが多いような...

しかし、暗に高ストレスにさらされる職種であることを示しているような調査結果ですね。まあ、実態は出来るだけ知ってもらった方が良いと思いますけど。

その一方で、「感情的コミュニケーション」は、若いうち (例えば 30歳前半まで) は手を出さないようにして欲しいコミュニケーション能力である。特に研究者や技術者を目指そうとする若い人たちには、周りの人がどう思うかなんかは気にせず、 (「空気嫁!」などの罵倒は無視して) 我が道を進んで欲しい。

仙石浩明の日記: 「人を動かす」感情的コミュニケーション能力と 「モノを動かす」論理的コミュニケーション能力

論理的コミュニケーション能力と感情的コミュニケーション能力、という分け方に感心してしまいました。

私も若いエンジニアの方々には、論理的コミュニケーション能力の方を、まず優先して、鍛えていただくのが、良いと思います。これから技術を学んでいく上で基礎となる部分ですからね。勉強の仕方を勉強するようなものだと思います。

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

2007年3月14日 (水)

日本のソフトウエア産業の衰退

「衰退」というのが前提になっているようですが。

日本のソフトウエア産業、衰退の真因:ITpro

「衰退」が何を意味するのか良く分からない、という感想が語られています。

日本のソフトウェアは世界一だ! - 日本のITは世界を制す!? [ITmedia オルタナティブ・ブログ]

確かに、論点がいまひとつ定まらず、散漫な印象の記事ですね。

ちなみに、経済産業省の「特定サービス産業動態統計調査」の「情報サービス業」を見ると、産業が衰退している、というのは当てはまらないかな、と思います。売上高で見る限りですが。

経済産業省 特定サービス産業動態統計

数値ですと分かりにくいので、グラフにしてみました。

Graph20070314_3








以下の記述からすると、ソフトウエアの品質について「衰退した」ということだろうとは思います。

ヨードンが前掲書に、またクスマノが『日本のソフトウエア戦略』に書いたように、メインフレーム全盛時代の日本のソフトウエア開発力は、かなり高い水準にあると評価された。当時の調査の実態を知る筆者から見ると、これらは選別されたデータに基づく、やや過大な評価であった。それでも、富士通、日立製作所などコンピューターメーカー各社が、製造業の伝統を継承し、それぞれが「プロダクト指向の品質ドリブンモデル」とでも言うべきソフトウエア開発モデルに沿って、かなり高い水準の品質と生産性を達成していたことは事実である。当時の日本企業はソフトウエア開発環境への投資にも熱心であった。

 ところがその後、米国やインドとは逆に、日本のソフトウエア開発の国際競争力を憂慮せねばならない状態に陥った。開発プロジェクトの混乱、製品出荷後の不具合、システム稼働後のトラブルをしばしば耳にするようになり、国内の開発者だけではソフトウエア開発への要求を満たせなくなった。

受託ソフトウエア開発に関しては、ハードメーカーのクローズドなシステムから、オープンなシステムへと移り変わったことが、業界全般としての、納入物件の品質低下をもたらす一つのきっかけとなったのは確かでしょうね。

耐震偽装事件のとき、規制緩和で技術のない会社でもマンションの企画・販売ができるようになったことを、事件の背景に挙げていらした方がいましたが、情報システムのオープン化は、ハードメーカーからの、「規制緩和」として機能したように思います。

汎用機とPCでは、値段の桁が2つ3つ異なるわけでして。なぜかこの値段の法則は、ハードだけではなく、ソフトにも適用されてしまうようですね。

ただ、汎用機全盛の頃と今とでは、技術・社会環境・業界構造など、何もかもが違ってしまっていると思いますので、比較することに意味があるかどうかは疑問です。

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

2007年3月 4日 (日)

医療危機とソフトウエア危機

「新小児科医のつぶやき」 のコメント欄に以下の意見が出されていました。元は週間新潮の連載記事だそうです。

医者が減った、絶対数が少ないからと報道していたが、どう考えても納得いかない。今は27万人以上で、1970年ごろは11万人だったが小児科・産婦人科が不足している話など無かった。

これに対する医師サイドの意見は、30年前と比較して、医師の仕事量は格段に増加していて、現在の人員ではとても足りない、というものです。

以下から私の考察です。

医師の仕事量が増えたのはなぜか?

根本的な原因を考えると、やはり医療技術の進歩があるように思います。検査の数・量が増え、発見される疾病が増える、また、治療可能な疾病が増え、治療の数も増える、という構図ですね。

さらに、インフォームド・コンセントなど、治療以外の仕事の増加もあるでしょうが、これは、社会が変化したことの反映であり、社会の変化をもたらしているのは技術の進歩であるように思います。この場合は、医療技術に限らず、科学技術全般の進歩が、ユーザの期待を増大させている面があるかもしれません。

では、現在どの程度の人員が必要なのか?

専門家ではありませんので、わかりません。この場合は、医療政策の専門家が見積もる話になるのでしょうか。医療技術がどの程度の速度で進歩し、必要人員がどの程度の速度で増加するのか、定量的に見積もる必要があると思います。

我がIT業界で有名な法則として、ムーアの法則というものがあります。

ムーアの法則とは、最小部品コストに関連する集積回路におけるトランジスタの集積密度は、18~24ヶ月ごとに倍になる、という経験則である。

"ムーアの法則." Wikipedia, . 25 2月 2007, 15:09 UTC. 4 3月 2007, 00:29

ものすごく単純化して、コンピュータ・ハードウエアの価格性能比は、1年半で倍になる、としてしまっても、ユーザの感覚としてはおかしくないと思います。実際には、ハードの性能が向上すると、ユーザの期待はそれをはるかに上回って増大する、というのが、業界の人間の感覚ですね。

ハードの性能が凄まじいスピードで向上し続けた結果、ソフトウエア開発がこれに追いつかなくなる、という問題が表れました。これがソフトウエア危機です。1960年代の終わり頃から言われ始めた言葉のようです。

The software crisis was a term used in the early days of software engineering, before it was a well-established subject. The term was used to describe the impact of rapid increases in computer power and the complexity of the problems which could be tackled. In essence, it refers to the difficulty of writing correct, understandable and verifiable computer programs. The roots of the software crisis are complexity, expectations, and change.

ソフトウエア危機は、ソフトウエア工学が生まれた初期に使われた言葉。コンピュータの計算能力の劇的な向上の結果、コンピュータが扱える問題が複雑化した状況を指す。より直接には、正しく、理解が容易で、検証可能なコンピュータ・プログラムを書くことの難しさを言う。ソフトウエア危機が起きた要因として、問題の複雑化、ユーザの期待の増大、時代の変化がある。

"Software crisis." Wikipedia, The Free Encyclopedia. 27 Feb 2007, 01:19 UTC. Wikimedia Foundation, Inc. 4 Mar 2007

今でもソフトウエア開発というのは、大部分、プログラマの手作業によって行なわれており、ソフトウエア危機の状況は、継続中であるといって良いと思います。最近では、携帯電話などの組み込みソフトウエアで、ソフトウエア危機が言われていますね。

こうした事態は、表面的には、人手不足の問題として表れます。実際、SE不足、プログラマ不足はかって深刻な問題として言われていましたし、今でも言われています。

しかし、技術が進歩を続ける限り、そして技術の進歩を止めることはできないわけですから、人員は永久に不足を続けます。人が足りないから人を増やせばよい、という単純な問題ではないのは明らかだと思います。

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

2007年2月22日 (木)

業務プロセスの重量化

2008年度から適用が始まる、内部統制法(日本版SOX法)への対応が本格化しているようです。今号の日経コンピュータでも特集されてましたね。

日本版SOX法対策のためERPをフルカスタマイズする不条理

ISO9000、ISO14000、個人情報保護法、内部統制法と業務プロセスに係わる書類仕事は増加の一途を辿ってるように思います。業務プロセスを変更すれば、こうしたプロセスに係る書類仕事、さらに書類仕事をサポートするITシステムも見直すことになりますので、業務プロセスに相当の重荷を載せている感がありますね。

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

APジェネレータ

業務で使用する、画面・帳票の内容から、業務アプリケーションを自動生成する、というアイデアは以前から存在したと思います。

APジェネレータが導くシステム開発の新パラダイム - @IT情報マネジメント

最近、この分野が再び注目を集めるようになってきているみたいですね。

実際のところ、業務アプリケーションというのは、画面・帳票・DB・オブジェクト間のマッピングが大部分を占めますし、ロジックも定型といえるものが多いですから、自動生成という考えは当然出てくるものと考えます。私も常々、業務アプリケーション開発のコーディング作業のうち、8割くらいは自動化可能ではないか、と思っていました。

業務アプリケーションの自動化技術を現実に使用する場合、以下の点が気になるところです。

1. 自動化ソフトウエアのライセンス料が高額でないか

2. 自動生成されたコードのパフォーマンスは実用に耐えるか

3. 手で書いたコードと自動生成コードがリンク可能か

4. 検証・テストが容易に行なえるか

5. 既存システムのプラットホーム(特にRDBMS)と統合可能か

こうした点をうまくクリアできるのであれば、普及しそうな気がします。今のところ、この手の製品の最大のネックは、ライセンス料ですかね。大抵は恐ろしく高額ですから。

この分野の製品がいくつか販売されるようになり、ユーザーベースが拡大していけば、解決されていきそうですけどね。鶏と卵の関係ですが。

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

2007年2月21日 (水)

コミック・ベースド・ストーリーボード

漫画を使ってシステム利用のシナリオを説明しよう、という話です。

最近知ったのだけど, sun.com のデザイン・チームは検討過程におけるコミュニケーション手法のひとつとして 「コミック・ベースド・ストーリーボード」 というのを使ってるんだそうだ. サービス利用の一連の流れをマンガっぽくみせることで, デザインの専門家ではない実際の利用者からの意見を得やすくするらしい.
sun.com 謹製コミック・テンプレート - tkudo's weblog about identity management,Feb 14, 2007

StarOfficeまたはOpenOffice用のテンプレートがあるみたいですね。

 Design Comics: An 0.9 Version You Can Use

バレエの「くるみ割り人形」のチケットを、オンラインで買おうとして...という例が載っていますね。

もっと長いもので、”customer ratings system”の例が以下にあります。

Examples of Comics in Designing Customer Experiences

面白いですけど、職場によっては、ここまでくだけると怒られるかもしれませんね。

「これはポンチ絵(漫画絵)なのですけど...」
「マンガとは何だ!!」

どこかでこういう話があったような気がします。

まあ、大抵の人は喜んでくれると思いますけどね^^)

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

2007年2月19日 (月)

体系化された知識 vs 断片的知識

以下のブログ記事を読んでの感想です。

仙石浩明の日記: 組織を強くする技術の伝え方
仙石浩明の日記: プログラマを目指すのに適した時代、適していない時代 

応用の利く体系化された、つまり理論的な知識と、断片的な、いわゆるHow-Toな知識、どちらがより有用か、という話があるようで、まあそれは記事の本旨ではないようですけど、後者の方が有用だとする人がいることに、少々驚きました。考えるまでもなく、前者のように思っていましたが。

様々な「データベース連動Webサイト」コンサルティング会社が過去2年間に急成長し、データベース連動Webサイトを作るための14ステップをアマチュアたちに教えて彼らの同類を増やした(ここにselect文があるね、さあ、Webサイトを作って)。しかし今やドットコムは崩壊し、突然ハイエンドGUIプログラミングとC++のスキルと真のコンピュータサイエンスが要求されるようになり、武器庫にselect文しかないちびっ子は、急すぎるラーニング・カーブに直面して、キャッチアップすることができない。
「ビッグマック 対 裸のシェフ」, Joel Spolsky / 青木靖 訳,2001/1/18

...Javaは大体において優れたプログラマと凡庸なプログラマを見分けるのに使えるほど難しい言語ではないということだ。Javaは仕事で使うのには良い言語かもしれないが、それは今日の話題ではない。Javaが十分に難しくないというのはバグではなく、機能であるわけだが、それには1つ問題がある。

私のささやかな経験から言わせてもらうと、伝統的に大学のコンピュータサイエンスのカリキュラムで教えられているもので、多くの人がうまく理解できないものが2つあった: ポインタと再帰だ。
...
...コンピュータサイエンス学科のドロップアウト率の数字をいろいろ見たが、それは通常40%から70%の間だ。大学はこれを損失だと考えているようだが、私はこのふるい分けを不可欠なものだと思っている。彼らがプログラミングのキャリアで成功したり幸福になることはないだろうからだ。
「Javaスクールの危険」,Joel Spolsky / 青木靖 訳,2005/12/29

How-Toな知識というのは、誰かがお膳立てをしてくれて、敷かれたレールの上で仕事をする分には、それで十分なのですけどね。道なき道、障害物だらけの道で仕事をする場合には、全く不十分だと思います。いずれは壁に突き当たることになるでしょう。それは、自分がお膳立てをする側に回るときですかね。まあ、私もあまり他人のことを言えるような立場ではありませんが。

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

2007年2月10日 (土)

不二家の不祥事は受発注システムの不備が一因?

詳細が不明なので、内容についてはコメントしようがないです。

不二家の受発注システムには、受発注の最新状況や原料の消費期限などを厳重に管理していなかった可能性があるという。改革委員会は、原料の使用状況を厳重に管理・チェックするシステムを整備すべきと不二家に伝えたもよう。

不二家の不祥事は受発注システムの不備が一因か、改革委員会が指摘,ITpro,日経BP社,2007/02/08

企業がITシステムに業務を依存するようになって久しいですから、ITシステムが不祥事の一因となることもあり得るでしょうね。ITシステムの導入は経営戦略の一環であり、経営者のコミットが必要、ということが実感される一事です。

ベンダーはユーザーに対して,IT導入は経営そのものの問題であることをトコトン主張すべきだ。併せて,必要な業務改革を断行すること,IT導入成功のためには常にユーザー主導でいくこと,初期段階でユーザーとベンダーの役割を明確にすることなども主張し,啓蒙する。そして,ユーザーの意識を変えなければならない。

ダメシステムとその甦生に関わる人々(11)ベンダーはシステム丸投げを受け入れるな,ITpro,日経BP社,2007/02/09

私達業者サイドも場合によっては責任を問われかねない、ということを自覚する必要がありますね。

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

2007年2月 2日 (金)

順を追って整理しましょう

システム開発では、現状分析のフェーズは疎かになりがちです。顧客も業者も頭の中が「次のシステム」で占められてしまい、「今どうなっているのか」という点が見過ごされてしまうのですよね。また、顧客にとっては、要望を言う方が現状を説明するより楽しく、業者側も現状を調査するより新しいシステムを検討する方が楽しい、というのがありそうです。

 今、小生のビジネスで、新しいPJが複数立ち上がろうとしている。多くの場合、PJの最初に現状調査・現状分析を行うことが多い。これは、これからコンサルティングやサポートを行っていく中で、クライアントの内外の状況をきちんと理解し、共有していくことが非常重要だからだ。

 特に、中堅企業以下、もしくは、ベンチャー企業では、現状を文書にしている場合は少ない。成長が激しかったり、そもそも業者任せだったりすると情報が古かったり、存在していないことがほとんだ。これでは、外部のメンバーだけではなくクライアント様メンバーでさえも正しい決断ができないのだ。

 だからこそ、時間と費用はかかるかもしれないが、現状調査・分析フェーズが必要で、重要なフェーズになってくる。

「現状調査・分析フェーズとは - ITコンシェルジュの Try ! & Error ?」,ITmedia オルタナティブ・ブログ,川上 暁生,2007年02月02日

現状分析を疎かにしますと、後の設計・開発・テストのフェーズで、仕様の漏れが見つかったりして、手戻りが多発することになりますね。結果、プロジェクトが危機に陥ります。

システム分析のフェーズとして、以下のフェーズ分けが原則としてあると思います。

現物理モデル->現論理モデル->新論理モデル->新物理モデル

この話をすると、大抵は「なんでこんな面倒なことを」という反応ですね。顧客も業者も。しかし、フェーズ分けで検討内容に縛りをかけることは、おおいに意味がありまして、それは冒頭に挙げたものです。つまり、縛りがないと、システムの現状に関する内容がなかなか出てこなくなってしまう訳です。

順を追って構築するべきシステムの姿を整理していくことは大事です。必要な仕様を漏れなく拾うため、当然のことと考えないといけないですね。

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

2007年1月30日 (火)

ソフトウエアのミッシングリンク

データが重要

...ユーザーにとっては、ソフトウェアのコードが自分のものでなくてもいい。しかし、自分が作成して編集し、蓄積したデータは自分のものだ。

文:John Milan,翻訳校正:吉井美有,「ソフトウェアの突然変異:ミッシングリンクを予見する」,CNET Japan,2007/01/30 08:00

コンピュータを利用する上で、データが最も重要ということは、ITシステムの開発を行なう人間であれば、身にしみていることだと思います。

ITシステムを構成するものの寿命は、データ>ソフトウエア>ハードウエアの順で、業種にもよりますが、データの寿命は半永久と考えて良いと思います。2000年問題の例で分かるように、ソフトウエアの寿命も予想以上に長いですけどね。30年くらいはいきますかね。

企業のITシステムでは、長年にわたって、システムが使われ続けていますので、データが最重要であることはほとんど常識なのですが、コンシューマ向けの領域においても、このことがより重要なポイントと認識されつつあるのかもしれませんね。今さらなのかもしれませんけど。

企業のシステムにおいては、それこそ私達のような業者が、各アプリケーションのデータ交換を行なう部分を作り込むわけですけども、コンシューマ相手の場合はそうはいかないですね。データ・フォーマットの標準化が強く求められる所以でしょう。

しかし、例えば、OpenDocument Format  のような試みは既に行なわれているわけですが、データ・フォーマットを標準化するだけではうまくいかないのですよね。結局、各アプリケーションでデータのセマンティクスを完全に統一することができないからでして。

引用先は、同じ種類のアプリケーションでのデータ交換ではなく、異なる種類のアプリケーションでのデータ交換についてですので、話は違うのですけどね。しかし、異なるアプリケーションでもセマンティクスの問題は起きるでしょうね。

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

2007年1月28日 (日)

ITシステム開発における「オーナーの弱さ」

ITpro「記者の眼」で、プラント建設などのエンジニアリング業界と、ITシステム業界とを比較した話が出ていました。

ただ,いまのままではどうにもならない問題がある。それは「オーナーの弱さ」だ。先述したように,エンジニアリング業界では,標準的な処理フローや配置図を基に詳細なRFPをオーナー側が作成。それを基に厳密な仕様変更管理が可能となっている。詳細なコーディネーション・プロシジャにより,作業手順もオーナー側がコントロールする。

 要するに,エンジニアリング業界では「オーナーが強い」のである。実際,エンジニアリング会社の元PMは,「オーナーであるエクソンやモービルなどの石油メジャーに教えられたことは多い」と語る。エクソンやモービルなどの強力なオーナーを相手に商売をしているうちに,エンジニアリング会社のプロジェクトマネジメントも洗練されていった,という構図だ。

 エンジニアリング業界における処理フローや配置図は,システム開発では「業務プロセス」に当たる。そして,これを作成できるのはオーナーしかいない。詳細なRFPの作成も,作業手順書も本来はオーナー(ユーザー企業)が作成すべきだろう。システムはオーナーのものなのだから。

平田 昌信, 求められる「オーナー支援コンサルタント」,ITpro「記者の眼」,日経BP社,2007/01/24

ITシステム開発でのオーナーも、今までのように、業者に丸投げではなく、自ら積極的にプロジェクトに係わろうとするようになってきているように思います。

以下の記事は象徴的ですね。

東証システム、全面刷新の真相【真相6】東証システムの開発体制 丸投げ体質からの脱却を目指す, ITpro, 日経コンピュータ 大和田 尚孝, 2007/01/22

過去の「丸投げ体質」を反省するとして、以下のようにあります。

2005年までの東証のシステム部門では、ITベンダーにシステム開発を依頼する際、RFP(提案依頼書)を書かずにITベンダーに口頭あるいは書面で大まかな要件を伝え、見積りを出してもらうケースが少なくなかった。要件定義の中身は、「現行業務を忠実にシステム化してもらいたい」、あるいは「現在のシステムを参考にしてもらいたい」といったレベル。実質的にはベンダーに要件定義書を作らせていた。

まあ、別に驚きませんけど、「全てお任せコース」ですね。それで、今回の全面刷新に当たって、以下の作業を東証が受け持つそうです。

  • 要件定義と検収
  • 進捗チェック

当たり前すぎてズッコケそうになってしまいますが。現実はこんなものですかね。

残る問題は、業者側の経営者でしょうか。どうも、オーナーの提灯持ちに成り下がってしまっている感じがします。当のオーナーが冷たい目で見ていることに気づきましょうよ。

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

2007年1月26日 (金)

ゆとりの法則

ゆとりを排除し、企業を効率化する任務を負った人は、自分の仕事を正当化するために、財務上の利益をもちだす。1円を節約すれば、1円の利益になるというのだ。これが真実だと信じているのは、何度もそう聞かされてきたからである。おそれながら、この古人の知恵に真っ向から異を唱えてみたい。

「1円を節約しても、1円の利益にならない」

トム・デマルコ 著, 伊豆原 弓 訳, 「ゆとりの法則 誰も書かなかったプロジェクト管理の誤解」, 日経BP社, 2001年, p.50

電車の吊広告に求人情報誌の広告が色々あり、見るともなしに眺めていると、「残業なしの仕事」とか「休日が必ずとれる仕事」といった特集記事の見出しが出ていました。日本も、Work life balanceが重視される世の中になってきているのだ、という感想を何ともなく抱きました。

我がITシステム開発業界でも、ほんの5年くらい前ですと、月300~400時間労働が当たり前の感覚で行なわれていました。おかげさまで、「きつい」「厳しい」「帰れない」の新3K職場との称号もいただき、若者から敬遠される職場の代表格となってしまったみたいです。「花形」と呼ばれたことがあったなどと信じられませんね。

@ITに以下のような記事が出てました。

働き盛り年代減少で危機を迎える情報サービス産業 - @IT情報マネジメント(井上 実, 2006/12/21)

まず、「年齢構成のゆがみ」ということで、以下の指摘があります。

情報サービス産業において、最も働き盛り年代である30代半ばの人口が少ないというゆがんだ年齢構成は、情報サービス産業の業績を左右するくらい重要な問題である。なぜ、このような事態を招いてしまったのだろうか。その原因を探ってみる。

私の印象ですと、30代半ばというより、20代~30代後半までが、40代以上(バブル期入社にあたりますね)より極端に少ない、という感じです。客観的に見ると、上のようなことになるのですかねえ。

それで、「ゆがんだ年齢構成を乗り越えるための3つの方策」として提案がされています。

1. 若年層の早期育成
2. スペシャリスト育成と複線型人事制度
3. グローバル・アウトソーシング

今までに散々言われ、また行なわれてきたことですね。おそらく効果は期待できないでしょうし、次世代の若者のことを考えれば、事態を悪化させるだけでしょうね。

最後の「根本的な解消を図るには、情報サービス産業がほかの産業と比較して魅力のある産業になる必要がある」は、まさしく正論なのですけど、そのためには、先のような場当たり的な「対策」をやめ、このビジネスの本来の姿を取り戻す必要があると思います。

---

ゆとりの法則 − 誰も書かなかったプロジェクト管理の誤解 Book ゆとりの法則 − 誰も書かなかったプロジェクト管理の誤解

著者:トム・デマルコ
販売元:日経BP社
Amazon.co.jpで詳細を確認する

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

2007年1月14日 (日)

「スーパーカミオカンデ」データ解析システム

同日付の日経新聞朝刊にも出ていたニュースです。

富士通は1月12日,観測装置「スーパーカミオカンデ」のデータを解析するシステムを東京大学宇宙線研究所附属神岡宇宙素粒子研究施設から受注したことを明らかにした。Linuxを搭載した270台のブレードサーバー(540プロセッサ,1080コア)によるクラスタ,大容量ファイル・サーバーなどで構成され,2007年3月から稼動する。従来システムの約35倍の演算性能となる。

スーパーカミオカンデがLinux270台,1080コアのPCクラスタによる解析システム構築へ(2007/01/12, ITpro, 日経BP社)

1月12日に受注して3月から稼動ということは、構築期間が約2ヶ月ですか。とすると、何らかのパッケージを使った、汎用的なPCクラスタシステムなのですかね。独自システムを開発するのであれば期間がなさすぎますし。「受注額は約八億」(日本経済新聞, 2007/1/12, 朝刊13面)とのことですから、1台あたり約300万円。ハードウエア・OS・ミドルウエアだけの値段という気がします。

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

2007年1月12日 (金)

東証システム全面刷新

日経コンピュータの特集記事が、一部ネットでも見れるようになっていますね。

東京証券取引所は、2009年後半の稼働を目指す次世代売買システムの開発ベンダーを富士通に決めた。証券取引所の中核をなす売買システムを巡って、 2005年11月以来3度の大きなシステム・トラブルを経験した東証は、初の国際入札を実施した。18グループに及ぶ世界の有力ベンダーの提案をどのように審査したのか。富士通の提案の何が決め手になったのか。東証が再生を賭けるプロジェクトにおけるベンダー選定の真相を詳報する。

東証システム、全面刷新の真相 【真相1】東証システムのベンダー選定18グループから勝ち残った富士通(ITpro 日経BP社)

日経コンピュータの記事は一応目を通したのですが、Linuxベースのシステムで、ミドルから独自開発、インメモリで全トランザクションを処理する、というような、かなり野心的なシステムのようです。これだけの規模・内容のシステムを開発するのは滅多にないことだと思います。注目したいと思います。

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

2006年11月 8日 (水)

「XMLって最低でしょう?」

という記事です。

XML does suck technologically, but:

  • The technological problems can be managed
  • The political and commercial advantages of working with the same open standard as everyone else are enormous

XML is here to stay
Does XML Suck?

XMLは技術的には最低な選択肢だが、既に広く使われて、「標準」になってしまっている。
だから、これからも使われ続けるだろうね、とのこと。

xmlsucks.org とか、 xmlsucks.com とか、このトピックだけでWebサイトを作ってしまうとは...

| | コメント (0)

2006年11月 3日 (金)

Googleと蜜柑

Googleの商売について思うこと。

Google アプリ独自ドメイン向けは、企業や団体にコミュニケーションとコラボレーションのためのツールを提供します。独自のブランド設定、テーマカラーやコンテンツのカスタマイズなどは管理コントロール パネルから操作でき、別途ハードウェアやソフトウェアをインストールしたり管理していただく必要はありません。
Google アプリ 独自ドメイン向け

最近読んだ本の、以下の一節にある、果物屋さんの話から、Googleのことを思い浮かべました。

「なぜ、こんなに勢いよく蜜柑が売れるのですか」
「決まってるやないか、安いからや」
<略>
「...今ここで売っている蜜柑は今朝、自分の腹巻に巻いた現金で払うからと言って、卸売り市場から安く仕入れてきたものや。それを、そのままで出している。」
SEのためのシステムコンサルティング入門―システムコンサルタントになるための実践ガイド
p.16

この果物屋さんは、蜜柑を仕入れ値で売って、儲けているそうです。

Googleの商売というのは、ソフトウエアを無料で提供し、膨大なユーザベースを獲得した上で、ソフトウエアの販売によらず収益を上げるやり方ですよね。このあたり、上の蜜柑の話に通じるものがあると思います。

ソフトウエアの作り手としては、自らの汗と涙の結晶であるものを、無料、あるいはただ同然で大盤振る舞い、という商売のやり方には、忸怩たるものがなくもないかと思いますが。

ユーザから見た場合、ソフトウエアを購入する、というのはリスクの高い行動であるとも思います。と、申しますのは、ソフトウエアというものは、ある程度使いこんでみないことには、その価値を知ることができないからでして。安からぬお金を払い、そして少なからぬ時間と労力を注いで、そのソフトウエアが使い物にならないことが分かったとなると、大きな損失となります。

ソフトウエアを無料で、なおかつ、SaaSで提供することにより、ユーザの初期リスク(お金と導入の時間・労力)を最小限にする。ユーザを獲得する方法としては、究極に近いですね。獲得した後は、まさに、そのソフトウエアの優劣で、ユーザベースを維持できるかが決まってくるわけです。

これからのソフトウエア商売は、無料サービス、有料サービス、そして構築・導入サービスなどを、組み合わせて、ユーザの導入リスクを最小限にした上、ソフトウエアの優劣を競うようになるのかもしれませんね。

| | コメント (0)

2006年11月 1日 (水)

XML再考

最近(でもないですが)出てきている、XMLに関する「素朴な疑問」について。
すっかり忘れていましたが、以下の記事をみて思い出しました。

今更聞けないXML? - Microsoft Regional Director のブログ [ITmedia オルタナティブ・ブログ]

XMLも一時のブームが去り、この技術の利点・欠点について、冷静に考えてみようという動きがありますね。

まずは、かのPragmatic Programmer達の以下のインタビューより。

Dave Thomas: XML sucks.

Bill Venners: Why?

Dave Thomas: XML sucks because it's being used wrongly. It is being used by people who view it as being an encapsulation of semantics and data, and it's not. XML is purely a way of structuring files, and as such, really doesn't add much to the overall picture. XML came from a document preparation tradition. First there was GML, a document preparation system, then SGML, a document preparation system, then HTML, a document preparation system, and now XML. All were designed as ways humans could structure documents. Now we've gotten to the point where XML has become so obscure and so complex to write, that it can no longer be written by people. If you talk to people in Sun about their libraries that generate XML, they say humans cannot read this. It's not designed for human consumption. Yet we're carrying around all the baggage that's in there, because it's designed for humans to read. So XML is a remarkably inefficient encoding system. It's a remarkably difficult to use encoding system, considering what it does. And yet it's become the lingua franca for talking between applications, and that strikes me as crazy.

Misuses of XML

「XMLは、もともと構造化文書のための規格であって、(アプリケーションの)データファイルとして使用するのは適切ではない」というご意見です。Javaの世界で、「設定ファイル地獄」と言えば、まさにXMLで記述された大量の(複雑で読解困難な)設定ファイルのこと。このことは、以前から、指摘のあるところです。

私もこの指摘は的を得ていると思います。XMLの空白・改行の(不可解な)扱い、そしてCDATAの存在は、これを文書フォーマットとして考えて、初めて納得のいくところでしょう。つまり、「空白での字下げ」だとか、「改行でパラグラフを区切る」のような、「書式」に属するようなものは、スタイルシートで別途定義するので、XML内には含めるな、という趣旨ですよね。

XMLそのものは、構造化データを格納するのには、あまり適してないと言ってよいと思います。ただし、この「誤用」が広く行なわれた結果、これがデファクトとなってしまった面があり、数多くのツールやフレームワークが「XMLデータファイル」に対応していますので、今ではこの使い方をすることにも、メリットはあるのかな、と思います。既成事実は強し、ですね。

構造化データを、より簡便な形でテキストファイル化する、というアイデアもありまして。

XMLの論考: YAMLはXMLに改良を加える

まあ、悩ましいところですが、私の考えとしては、「それで十分ならそれを使う」ですかね。

フラットなデータなら、CSVで十分でしょうし、構造化されたデータであれば、YAML(あるいはJSON)でまずは十分かと。XMLを使うのは、主にはHTTPなどでインターネットでデータをやり取りするような場合ですかね。

構造化データを、人間が読むことはなく、プログラムからしか読まないことがわかっているのであれば、オブジェクトをバイナリでシリアライズしたものでも、当然良しだと思います。

| | コメント (0)

2006年10月22日 (日)

技術力とは何か

ソフトウエア・エンジニアの技術力とは何でしょうか。

どうも、この業界では、プログラミング言語の使用経験で、エンジニアの技術力を考えようとしますね。Javaでプログラミング経験が何年、など。つまり、特定の言語が使えるかどうかで判断することが多いと思います。

私は、特定のプログラミング言語で、プログラムが書けることは、「技術力」だとは思っていません。「技能」ではあると思いますけど。これは、例えば建築家で言えば、図面が引けるかどうかのレベルの話だと思います。でも、建築家の技術力は、単に図面が引けるという話ではないですよね。優れた建築物の設計ができるかどうかだと思います。

この業界に関わる人達も、プログラミングができるということと、優れたアプリケーションを開発できるということは、イコールでない、ということには、とうに気づいているのでしょう。そこで、言われ始めたのが、コミュニケーション能力なるもののような気がします。しかしまあ、コミュニケーション能力があれば、優れたアプリケーションが開発できるかというと、これも違うと思いますね。

結局、優れたエンジニアであるかどうかは、その人の作った「作品」を見ないことには、評価できないと思います。優れたものを作る人が優れたエンジニアである、ということにしかならないのではないでしょうか。

この世界では、「図面」の書き方が多種多様で定まった方法がなく、しかも、未だに新しい方法が生まれ続けているような状況ですので、「作品」を持ってこられても、評価できる人があまりいない、というのが問題なのでしょうね。

| | コメント (0)

2006年10月 5日 (木)

ソースとターゲット

通常、コンパイル言語の場合、ソースファイル上でプログラミングを行い、ビルドを行なうことで「ターゲット」となる、実行可能ファイルを作ります。スクリプト言語など、インタプリタ言語では、ソースファイルがそのまま実行できますので、基本的にはソースとターゲットは同じファイルとなります。

ところが、このソースとターゲットを分けるかどうか、はっきりしないものがあります。

Oracleデータベース上で、PL/SQLを使用して開発を行なっていた際、これが問題となりました。

私はテキストファイルの「ソース」上でプログラミングを行い、そのソースを「ターゲット」となる、開発用のデータベース上で、コンパイルする、という方法を考えていました。というか、これが当然と思い、他のやり方があると考えていなかったのですが。

ある人は、Oracleデータベース上で、データベースのディクショナリに格納されている、「ソース」を、直接編集していたのです。ある種のGUIツールを使えば、これが可能なんですよね(親切なことに、このGUIツールには、「デバッガ」までついてました)。そして、その人は、それが「当然」だと思っていたわけです。

で、ここで「どちらの方法が良いか」議論となったわけですが。

私は、以下の点を主張して、説得しました。
--
1)
ソースは別にしないと、ソース管理システムに入れられない。

2)
「ソース」が、おざなりに管理されている、開発用データベースに置かれているのはまずい。開発用データベースは、誰かが「無茶をして」クラッシュさせても良いものだから。

3)
「共有の」開発用データベース上で、複数の人間が「ソース」を編集し始めると、互いの変更が影響しあって、訳がわからなくなる