本ブログの記事に対して多くの皆さんからいただいた意見を総合すると、技術力のあるトッププログラマーにとって現状の日本のSI業界での仕事というのは、働き甲斐のない、魅力の少ない仕事として認識されているという残念な事実を思い知らされます。 オブジェクト指向の基本すらいまだにきちんと使いこなせない開発の現場 技術について勉強した知識をほとんど活用できないし評価もされない 無駄なドキュメント作成などに対する膨大な単純作業を強いられる いわゆる3K職場と言われるような過酷な労働と低い賃金 20年以上も前の仕事の進め方からあまり進歩が見られない 多重下請け構造によりユーザーに直接価値を提案するような仕事が難しい 多くの業務アプリケーション開発現場における体験を通して、以上のようなことが語られているということを考えれば、「業務アプリケーションのプログラマーは負け組だ」という意見が出てくることも当然のことか

第３０回記念のソフトウェアシンポジウムで、「ソフトウェア工学の分岐点における、アジャイルの役割」 と題した発表をしました。 ソフトウェア工学、は衰退したのか、滅びるのか？あるいは、これからなのか？ 1968年にNATO会議で初めて使われたSoftoware Engineeringという言葉。この言葉は、2010年の現在、どう響くのか、という点を、エド・ヨードン、トム・デマルコ、トム・ギルブ、アリスタ・コバーン、メアリ・ポペンディック、ら過去のソフトウェア工学のジャイアンツの最近の発言と、その中でのアジャイルの台頭という観点で、書いてみました。

プロセス統合を支えるデータベースとデータ統合を支えるデータウェアハウス DBMSとDWHの違い：統合CRMを支える情報基盤（2） 「顧客起点経営」を実現するためには、基幹系システムのプロセス統合のみならず情報系システムとして全社的なデータ統合も忘れてはならない。これをできるだけシンプルな例で説明してみよう。そしてプロセス統合を支えるデータベースとデータ統合を支えるデータウェアハウスのアーキテクチャと役割の違いに言及したい

ソフトウェア工学の祖の一人である、トム・デマルコが、最近IEEE Software 誌に、過去のソフトウェア・メトリクス賛美を悔い改める記事を書いている。 「ソフトウェア工学」というコンセプト－その時が来た、そして、その時は去った。http://www2.computer.org/portal/web/computingnow/0709/whatsnew/software-r 1982年に、デマルコは有名な「計測できないものは制御できない」という一文から始まる、『品質と生産性を重視したソフトウェア開発プロジェクト技法』という名著を書いている。このドグマは、ソフトウェア工学の考え方に強く根ざしている。むしろ、すべての「工学」という活動は、科学や経験から得た知見を使って自然現象をコントロールし、人間の役に立てることをその定義としており、そこでは測定を元にしたコントロールという概念はその中核にあ

Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

ガートナー データ＆アナリティクス サミット 2024年5月21日（火）- 23日（木） | Tokyo, Japan

「COBOLは現役バリバリだ。“COBOLは化石”などと口にするのはITとエンタープライズシステムが何たるかをわかっていない証拠」。東京海上日動システムズの稲葉茂 取締役 抜本改革推進第1本部長（写真）は“不当な”評価にさらされるCOBOLの評価をこう正した。稲葉取締役は2008年9月4，5日に開催した開発者向けセミナー「XDev2008」で「基幹系インフラを支え続けるCOBOL ～東京海上日動の抜本改革～」と題して講演した。 稲葉取締役がこうした熱いエールを送るのには理由がある。東京海上日動火災が25年ぶりに取り組むシステム全面再構築である「抜本改革」プロジェクトでは，開発言語を多面的に評価した結果，新システムでもCOBOLをビジネスロジックの開発言語として再び採用したためだ。2008年5月に，3年7カ月前に着手した第1次フェーズが終了し，自動車保険システムが新たに生まれ変わった。300

ソフトウエアは硬い。ハードウエアよりも硬い。ある程度の規模のソフトウエア資産を抱え，それを日々動かしている担当者の方であれば，ソフトウエアの硬さ，すなわち柔軟性の無さを痛感しておられると思う。 ソフトウエアが硬くなっている，という印象的な表現は，2004年1月に出版された『ソフトウェア入門』（黒川利明著，岩波新書）に出てくる（日経エレクトロニクスも2005年12月19日号で「ソフトウエアは硬い」という特集を組んでいた）。本来，ソフトウエアは開発した後であっても，使い方や環境の変化に応じ，柔軟に変更できることが特徴だった。ところが同書によれば，「コンピュータシステムにおいては，ハードウェアを変更するか，ソフトウェアを変更するかという判断を迫られたとき，今日ではユーザは一般的にハードウェアの変更を選び，ソフトウェアの変更は後回しにする」ようになってしまった。 例えば，あるシステムの応答速度が遅

わたしたちCIOは、ERPプロジェクトについて多くを学んできた。そうした教訓の多くは困難な道のりの末に得たものだ。会社挙げてのプロジェクトに多大な時間を費やした後、CIOはその代償に見合うだけのメリットを見つけ出そうと躍起になる。ほぼどのようなERP（またはCRM、SFA、BPMなど）についても、後になってプロジェクト管理者に、もし違ったやり方でやるとしたらどうしていたかと尋ねた場合、答えは大抵同じだ。 「ソフトウェアをカスタマイズしない！」 この結論にもかかわらず、組織がERP（またはCRM、SFA、BPMなど）選定と導入のプロジェクトに着手するたびに、ERPソフトウェアで自社の事業特有の局面を処理できなければならないという前提が浮上する。 大規模なシステム導入を幾つか手掛け（そして膨大な数のプロジェクトのコンサルティングを担当し）た経験を基に、わたしはビジネス／ITプロジェクト簡素化の

SOAの世界を5秒で巡ってみよう。調査会社Hurwitz ＆ AssociatesのアナリストRobin Bloorは、先頃のIBMによるSOAに関した発表を受け、業界の大手ベンダーがSOAに対して現在どのような立場を取っているのかについての考えを、次のように述べた。 IBM「SOAの本質がどこにあるのか明確に把握しており、真剣に取り組んでいる」 HP「今後進歩する可能性がある」 SAP「相応の取り組みを進めている」 Sun Microsystems「SeeBeyondの買収をきっかけにSOA市場に本格参入し、現在も力を入れている」 JBOSSおよびBEA「骨身を惜しまず努力している」 CA「後発組ながらも、やはり大きな力を傾けている」 OracleおよびMicrosoft「取り組みは遅々として進んでいない」 さらにBloorは、SOAは「狙いを定めにくい標的」だったが、2006年には主流

Enterprise buyer's guide: Remote IT support software Buying for the first time? Know what your options are. Considering replacing what you have? You might just save 25% or more on licensing costs. Here's what to look for and 12 leading remote support tools to consider.

まず、図1をご覧いただきたい。これは情報システムの開発プロジェクトがどれくらい予算オーバーするかを、統計的に分析したものである。黒丸で示してあるのが一つひとつの情報システム開発プロジェクトである。お気づきのように、プロジェクト規模が大きくなればなるほど、当初予算に対する超過割合も高くなる傾向が見られる。 同じ図の上で、道路、鉄道、橋やトンネルなどの建設系開発プロジェクトもプロットしてある。こちらも予算オーバーのケースがあるが、明らかに情報システムほどのコストオーバーは起きていない。また、プロジェクト規模が大きくなったとしてもコストオーバーのレベルがそれに応じて高くなるということもない。 非常に深い意味合いを感じさせる分析ではないだろうか。同じように大規模なエンジニアリング開発プロジェクトであるにもかかわらず、情報システムのみがコスト管理ができない、という事実が突きつけられている。この差はな

「SOAのプログラミング・モデルはSCA」──新標準SCA（Service Component Architecture）のVersion 1.0が2007年3月21日に発表されました。 発表したのは，OSOA（Open Service Oriented Architecture）です。OSOAは，標準化団体ではなく，複数のソフトウエア・ベンダーによるコラボレーション・チームです。 このSCAは，どのような標準で，どのような変化をもたらすのか。本連載で，SCAの全体像を解説していきます。 ・第1回　大事なことが決まっていなかった ・第2回　SCAは何も変えない？ ・第3回　SCAのプログラミング・モデルとは（前編） ・第4回　SCAのプログラミング・モデルとは（中編） ・第5回　SCAのプログラミング・モデルとは（後編） ・第6回　SCAを体験する ・第7回　SCAのある世界

面白いPOSTがあったのでご紹介。BPELとXPDLってどう違うんですか？という問いに答えるものです。これが一番わかりやすい説明だと思います。 XPDL and BPEL BPELの性質 BPEL is an "execution language" designed to provide a definition of web services orchestration, specifically the underlying sequence of interactions, the flow of data from pointtopoint. For this reason, it is best suited for straightthrough processing or dataflows visavis application integration. BPELという言

「自動車のような産業構造に再編すべきだ」。NTTデータの山下徹社長はインドや中国など海外ソフト会社が日本市場に本格進出してくる前に、ソフト産業の構造改革を実行する必要性を説く。日本のソフト産業が崩壊の危機にあるからだ。 パッケージベンダが自動車産業を参考にするのは、100歩譲るとありかもしれない。消費者に受け入れられるだろうという予想にもとづきプロダクトを開発していくモデルだから。 でも、やっぱないな。車は、多少の違いがあっても、どれも基本的な構造は同じ。パッケージは、いろんなものがあるからね。 それに対して、SIは一品ものだもの。規格(パッケージ)通りじゃないものを作るのがSIです。 マフラーだけを作るソフト部品会社、タイヤだけを作るソフト部品会社と、システムインテグレータと呼ぶシステム組み立て会社に分業化することで、インテグレータはソフト部品会社から調達した部品を組み合わせてシステムを

企業のIT部門の間でサービス指向アーキテクチャ（SOA）に関する技術的ノウハウの蓄積が進む中、ベンダーは、ビジネスインテリジェンス（BI）のような付加価値機能をSOAに統合するというビジョンを盛んにアピールしている。 結局のところ、Webサービスの技術的パフォーマンスを監視することと、Webサービスがもたらす財務的パフォーマンスやビジネスチャンスを把握することは、まったくの別問題だ。そこにBIの出番がある。ベンダーはBIを、基本的に、SOAを効果的にビジネスに活用するためのツールと位置づけている。 「従来、BIは、人間の要求に応じて、重要な可能性がある情報を提供することが主眼だった」とIBMのDB2およびBI製品開発担当ディレクター、ダン・スターマン氏は語る。「サービス指向アーキテクチャは、BIに次の大きな飛躍の契機をもたらす。今後はさまざまなサービスが情報を必要とするようになり、人間だけ

Elon Musk’s suit against OpenAI — right idea, wrong messenger