最低10年使える業務アプリケーション（後編）
前回「最低10年使える業務アプリケーション（前編）」は数年間アプリケーションを保持し運用し続けるためには多くの問題がある点を見てきた。今回は後編として、それらの原因と解決の方策を探り、現代のアプリケーションは長期運用に耐えるのかを考えたい。 動かなくなるカラクリ 前回「最低10年使える業務アプリケーション（前編）」、数年前に構築されたJ2EEアプリケーションが新しい環境で動作せず、企業担当者が怒りと悩みで苦しんでいる例をご紹介した。筆者はそこで、意外にも多くのアプリケーションで共通に持つ悩みを垣間見ることができた。 どういうことかというと、筆者が先の顧客に対し現象を調査したところ、当然ながら古いJDKのAPIとその挙動に依存して動作している個所、および古いJDKでしか動作しないライブラリやオープンソースが非常に多く見られ、さらに一部ではJ2EEの規約に違反していたため、新しいJDKやアプリ
口に出す前に考える、「システムって何？」
われわれは日常的にたやすくシステムという言葉を使ってしまうけれど、システムって何だ？ システムズ・エンジニアって誰だ？ 「最近システムがよく落ちるんで困るっすよ」ってどーゆーことだ？。 システムとは相互作用する複数の要素の集合。だから太陽系もシステムだし、会社もシステムだし、計算機もシステムだ。仏教的にはあらゆるモノはほかのモノとの相互作用においてのみ存在するわけだから、（仏教的世界においては）あらゆるモノはシステムということになる。とはいっても、例えば地球、月、太陽というたった3つのモノの（古典）力学的相互作用にさえ、厳密な一般解はないといわれているくらいで、カンタンではないのもシステムとゆーやつの特徴だ。 この複雑で厄介なシステムを「エンジニアリング」的に相手にして、飯を食っているのがわれわれシステムズ・エンジニアである。じゃあ、こんなものをどうやって相手にすればよいか。大きく分けて2
＠IT：ソフトウェア開発をちゃんと考える（2） 開発者の集合はどのように形作られているか
ソフトウェア開発の効率性を考えていると、いつかは必ず人の問題に突き当たる。プロジェクトチームという開発者の集合はどのように形作られ、どのように動いていくものなのだろうか。そこには必ず何らかの機構（メカニズム）があるはずだ。（＠IT編集部） アーキテクチャといえば、普通はプロダクトの、あるいはソフトウェアのアーキテクチャを思い浮かべるわけだけれど、システムやソフトウェアを作っていく過程ではプロジェクトのアーキテクチャ、つまり開発に主体的にかかわっている人たちの集合がどのように形作られるかも、とても重要な要素になる。 なんでこんなことをいい始めたかというと、たまたま「フューチャー・オブ・ワーク」を読んだからなのだ。なんで、こんな本を読んだかというと、 著者のマローンは米マサチューセッツ工科大学で「The MIT Process Handbook Project」［注］というプロジェクトをやって
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
