忍者ブログ
プロフィール
メニュー
最新コメント
最新トラックバック
1  2  3 
 以下は、ある著作からの引用です。「できるかぎり立派に○○を確立することがわれわれの目的であるからこそ、われわれはその○○をできるかぎり厳格にテストしなければならないのであり、コトバを換えていえば、その○○の欠点を見出そうとし、それを反証しようと務めねばならない」、「われわれの最善の努力にもかかわらずそれを反証できないという場合にのみ、○○は厳格なテストに耐えたということができる」、「ある○○を裏づける諸事例を見出したということは、もしわれわれがその反証を見出そうと努めて失敗しているのでなければ、それが意味するものはきわめて少ない」...

 ここで「○○」には何が入るかと問われれば、IT関係者なら、「システム」などと答えたくなるところです(耳が痛いので、答えたくないかも知れませんが)。しかし、「反証」という言葉が少々余計なヒントになっているとおりで、正解は(科学上の)「理論」です。原文は、K.ポパーの「歴史主義の貧困」(久野・市井訳)からのもので、著者のいわゆる「科学的発見」論を敷衍した部分です(著作全体の論旨からは、やや傍論ですが)。
 ITの世界にも、テストはバグの無いことを示すためにあるのではなく、バグを抉り出すためにある、という趣旨の格言がありますが、それにしてもピッタリきます。都合の良いデータで、都合の良いオペレーションをすれば、見掛け上はうまく動く。しかし、厳しいテストに耐えていないから、それより遥かに厳しい実際の運用にはとても耐えられないシステム。趣味のプログラミングならともかく、プロ(似非でしょうが)の仕事でも、このようなものが少なからずあるのが現実です。
 これに対して額面どおりのプロであれば、バグを抉り出すために、計画的・段階的なテスト、テスト密度や障害密度といったメトリクス、開発者と検証者の分離など、それなりの担保を用意します。しかし、いくらこうした担保があっても、システムを徹底的に「反証」しようとする「最善の努力」がなければ、それも空念仏に終わってしまうでしょう。ポパーは、科学上の理論を「反証」する「最善の努力」の担保として、どのようなものを心に置いていたのでしょうか。

拍手[0回]

PR
author : ITS 
 情報システムのビジネス・ロジックをどのように定義するのかは、システム開発の肝の一つです。紛争に至った場合、それがどこにどのような形で定義されているのかは、一つの重要な争点となります。原則論を言えば、要件定義や外部設計の中で、設計書や仕様書の形で定義しておくべきですが、現実には、しばしば不十分なままに終わります。しかし、不十分であれば、散逸しかけた設計メモや担当者の頭の中や、果ては対象業務それ自体から再構成する他なく、代償も大きくなります。

 ビジネス・ロジックの最も驚くべき定義場所は、システムのコードそれ自体というものです。もちろん、これではシステムの出した答は常に正しいということになってしまって、検証のしようもありませんから、新規開発の場合にはあり得ません。あり得るのは、開発後10年、20年と、文字どおり世代を超えて運用され続けてきたシステムです。
 ある物販のシステムでは、リベート(もちろん、違法なものではありません)計算のロジックが長年、極めて複雑に調整されてきた結果、担当者ですらシステム無しには計算することができない状況となっていました。(少なくともアップデートされた)規則集や設計書類は存在せず、担当者も交代前の状況は分かりません。当然、利害関係者である取引先はあるわけですが、その取引先には何とシステムの計算モジュールそのものが提供されており、取引先はそのモジュールを使ってリベート額を「検証」していたのです。まさに、「システム・イコール・規則」という状況です。誰も本当の(合意された)リベート額が幾らであるのか、分からないわけです。
 これで滞りなく運用されているなら、それはそれで良いとする見方もあるかも知れません。しかし、このシステムをリプレースする時には、どうするのでしょうか。途方もない労力をかけてリバース・エンジニアリングでもやる他ありません。この事例ほどではないですが、リプレース時には、これと似た話は良く聞くところです。「仕様は、現行システムに聞いてくれ」と。当然、開発のトラブルにつながるわけですが。

拍手[0回]

author : ITS 
 ITの分野は、恐らく他のどのような分野にも増して、進歩の速い世界でしょう。犬の1年が人間の7年に相当することになぞらえたドッグ・イヤーは、技術革新一般についての言葉ですが、その筆頭は何と言ってもITです。ムーアの法則によれば、「半導体の集積密度は18から24か月で倍増する」のだそうで、早晩、集積が原子レベルにまで達して頭打ちになるだろうと言われるほどです。実際、今のパソコンは、かつてのメインフレームを単純性能ではるかに凌駕します。

 こうした進歩は、物理的な性能が前面に出る場合には、それに比例するとまでは言えないまでも、十分に実感することができます。企業内のオンライン処理で「ただいま処理中です」などとオペレータを待たせるだけの画面は、まず見られなくなりました。初期には1分近くも待たされていた銀行のATMも、いまではほぼ瞬時と言って良いでしょう。
 ところが、オフィス系ソフトの体感スピードになると雲行きが怪しくなってきます。この種のソフトが企業で一般に使われるようになってから20年以上が経ちますが、体感スピーとは測ったように変わりません。いや、「測ったように」というのは、正しくありません。むしろ、技術進歩の恩恵は、殆ど使われることのない無駄な高機能化や、開発効率化のための技術によるオーバーヘッドが、精確に「測って」食い潰してきたのでしょうから。
 さらに言えば、システム開発のマネジメントは、まったく進歩がないように見えます。システムの仕事に初めて就いたとき、関連会社のベテラン技術者が「自分が仕事を始めた20年前と比べて何も変わっていない」と嘆いていたのを思い出します。それから早25年、トータル45年、やはり何も変わっていません。この間、様々な開発方法論やマネジメント手法が出ては消えましたが、少なくとも開発プロジェクトの成功率を顕著に押し上げるような変化は、絶えてなかったと言うほかありません。開発生産性に至っては、オープン化以降、はっきりと低下したように思われます。
 このような問題を抱えているのは、ITが産業として若いからだと言いたくなりますが、それでも既に半世紀の歴史はあります。むしろ、若いほど伸びしろは大きい理屈ですから、停滞の口実にすることはできません。あえて言うなら、技術そのものや、社会経済からの要求や、需要の絶対量など、IT産業をとりまく環境の凄まじい変化が、産業としての「健全な蓄積」を許さなかったということが、最も大きいものと思われます。人間は犬のスピードで生きることはできない、と言ってしまうと身も蓋もありませんが。

拍手[0回]

author : ITS 
 情報システムは、その企業固有のカスタムメイドのものですから、開発をベンダに委託したとしても、ユーザは必要な情報提供などの協力義務を負います。のみならず、ユーザは、当該システム(あるいは開発プロジェクト)のオーナーとして、ベンダの業務について、厳しく目を光らせる必要があります。

 確かに、ベンダはシステムを完成させるための専門家責任であるプロジェクトマネジメント義務を負います。これは、開発経験のないユーザが協力義務を怠っているような場合に、適宜これを指導してシステム完成への障害を取り除くことまで含む、重い義務です。したがって、少なくとも法的には、ベンダがまずいプロジェクト遂行をしている場合に、ユーザにはこれを是正する義務はありません。
 しかし、これは、実際にプロジェクトが失敗してしまった場合の事後的な責任配分の問題だと認識すべきです。プロジェクト遂行中に、ユーザが主体的な立場を失うと、開発に失敗した後で「損害賠償」は取れるかもしれませんが、開発に成功して「望むシステム」を手に入れることはできません。裁判で取れる損害賠償と、望むシステムを運用して得られる利益は、下手をすれば一桁違います。損害が莫大であるばかりでなく、事後処理を含めて数年から十年近くが費やされ、事業展開自体に深刻な影響が及んだ事例も稀ではありません。
 ひとたびシステム開発を決断したなら、相当の経営資源を投入する覚悟がなければならないはずであるのに、安易に考えている例があまりにも多いことに、驚かされます。

拍手[0回]

author : ITS 

 一時期、情報システムのTCO(Total Cost of Ownership)ということが喧伝されました。新規システムの導入時に、導入コストだけでなくその後のランニングコスト(運用・保守コスト)を考慮して初めて、正確な費用対効果が出せる、というものです。恐らく、このTCOの考え方は、改めて「TCO」などと言うまでもなく実践されるほどに、実務に浸透したものと思われます。しかし、一点だけ、平時のランニングコストのさらに先にあるもの、すなわち情報システムないし情報技術の継続性という観点だけは、どうも抜け落ちがちのようです。

 この点は、2〜3年毎にリプレースを繰り返さなければならない、ウェブ・サービスやECサイトの方が、はるかに意識が進んでいます。というより、初めから短期間でのリプレース・サイクルが、中長期計画のなかに組み入れられた形で投資判断がなされているからです。ある求人サイトでは、次期システムの企画段階で、既に次々期のシステムの青写真が出来ていると言います(もちろん、別の部署が取り組むとのことです。)。
 これに対して、数年から十年のサイクルが通常である基幹系システムでは、構築段階で次を見通すなど、現実的ではありません。それだけならまだ良いのですが、旧プラットフォームであるホスト機のメーカー保守が終わりに近づいて始めて、大慌てで対応をとる、などといった事例も稀ではありません。いまさらホスト機ではないし、オープン系にストレート・コンバージョンするにも新規開発に匹敵する期間とコストがかかる、これを機に新規開発に取り組もうとしても、明らかに時間不足...継続性リスクが適切に対応されていなかったわけです。
 ウェブのような新しい技術を用いていても、更新サイクルが比較的長い場合には、同様のことが起こります。技術が新しければ反って技術サイドのサイクルが早いため、旧バージョンのミドルウェアのセキュリティ保守が終了したり、互換性のない新バージョンに移行したり、また、利用していたデータ・センターが突然に休止するといった事態もあるでしょう。こうした場合の対応は、システム全体の改修(場合によっては再構築)に及び、制度変更などによる部分的改修とは比べものにならないコストを発生させます。定期的に継続性情報をウオッチし、早めの対応ができるよう体制を整えておくことが不可欠です。

拍手[0回]

author : ITS 
忍者ブログ | [PR]
 | PAGE TOP
write | reply | admin