最近、金融機関の勘定系システムなどの保守運用業務が、技術者にとってどんどんやばくなっているそうだ。そもそも金融機関のシステムの現場といえば、従来は「超」が付くほどの長時間労働の温床。ITベンダーの技術者が常駐すると、プライベートは完全に犠牲になり、下手をすると体を壊すような職場だった。 例えばかつて大手銀行に常駐していた技術者に「銀行の仕事は長時間労働がすさまじいと聞くけど、実際にはどうなの」と尋ねたら、「その通りですよ。私が常駐していた当時はいつも終電で帰っていました」と返ってきた。「何で」と重ねて聞くと、「だって客からの指示が来るのがいつも午後11時でしたから」と。 まあ、銀行など金融機関はシステムトラブルやセキュリティーリスクをどんなことがあっても避けなければならないし、金融庁のお達しにも即座に対応しなければならない。だから金融機関のIT部門にも言い分はあるだろうが、ITベンダーの技

最後に，複数のクラスの実装を継承できない問題を取り上げる。この問題の原因は，Javaが多重継承を許していないことにある。 Javaでは多重継承ができない。これは，デメリットと言うよりもメリットとして語られることが多い。C++は多重継承を許しているが，その結果プログラムが複雑になり難解なバグを生んだ。 多重継承は実装を引き継げるが複雑 多重継承は，次のような点で混乱を招く。一つが名前の衝突である。同じ名前のメソッドを持つ別のクラスを継承した場合，どちらのメソッドが呼び出されるかわからない（図5[拡大表示]）。これは，一つのクラスを継承した二つのクラスを，さらに一つのクラスが継承するときによく起こる。これをダイヤモンド継承という（図6[拡大表示]）。一番上位のクラスのメソッドを別々にオーバライドしていて，それを最下層のクラスが呼び出すと問題が起こる。 図5●同じ名前のメソッド名を持つ二つのスー

「メンバーに指示したのに思った成果が得られない」「決定事項をユーザーにひっくり返される」。メンバーやユーザー側の担当者の思わぬ動きに翻弄されて起こるのが「手戻り」だ。残業の多いITエンジニア共通の悩みである手戻りをなくすノウハウを紹介する。 本記事は日経SYSTEMSの特集をほぼそのまま再掲したものです。初出から数年が経過しており現在とは状況が異なる部分もありますが，この記事で焦点を当てた開発・運用現場の本質は今でも変わりません。 ITの現場における残業の原因として真っ先に思い付くのは作業の「手戻り」ではないだろうか。プロジェクトで起こる手戻りのうち，ITエンジニアが最もこたえるのは，せっかくまとめた要件や仕様の内容がひっくり返されることだろう。 製造業コンサルティング会社，ネクステックでプロジェクト・マネージャを務める，北山一真氏（マネジャー）も苦い経験を持つ。ユーザー側のマネージャと要

「従来のEJBは存在自体が間違いだった」，軽量コンテナ「Spring Framework」開発者のRod Johnson氏吠える 「エンティティBean（EJB：Enterprise JavaBeansに含まれるデータベース・アクセスのカプセル化機能）なんてないほうがよかった。エンティティBeanのせいで2～3年が無駄に失われてしまった」。現在，最も影響力のあるJava関連技術者の1人であるRod Johnson氏は，2005年6月21日に東京で開催された「JavaWorld DAY 2005」で，従来のJ2EE/EJBがいかに間違った存在だったかをとうとうと語った。「米国や英国で，新規のプロジェクトがエンティティBeanを採用したという話は，もはや1件も聞かない」。 Johnson氏は，広く使われている軽量コンテナ「Spring Framework」の開発者。J2EE開発者に大きな影響を

「DIする」，「インジェクション（注入）する」──新しい技術に敏感なソフトウエア開発者たちの間で使われている言葉である。DIとは，「軽量コンテナ」を実現する新しい設計思想Dependency Injection（依存性注入）の略称である。同じ概念をIoC（Inversion of Control，制御の反転）と呼ぶ場合もある（詳細は後述）。「DIする」と言えば開発者の間では通用するぐらいに，この設計思想は注目されているのだ。 DIが注目される理由は簡単だ。ソフトウエア開発者の開発サイクルを大幅に改善するからだ。筆者が司会を担当した「軽量コンテナ」に関するパネル・ディスカッション（注1）では，DIを適用した軽量コンテナ「Spring Framework」のおかげで「睡眠時間が確保できるようになりました」と複数のパネリストが真顔でコメントしたほどである。DIは，それだけ有効な技術なのだ。 注1