金融機関での大規模なシステムトラブルが後を絶たない。 昨年のUFJ銀行やみずほ銀行のシステム統合に伴うトラブル、 今年に入ってからも、 3月のりそな銀行、ゴールデンウィーク前後のジャパンネット銀行のほか、 細かな ATM のトラブルなどを挙げればキリがない。 信頼性や安定性が最も求められる公共性の高い大規模システムにおいてトラブルが頻発している。 企業の再編、合併が今後も相次ぐと予想される状況においては、 こうしたトラブルが今後増えていくことも 懸念されている。

避けられないシステムトラブル

大規模なソフトウェアが何らかの不具合を含むことは不可避である。 問題は、テストにより、その不具合をどの程度まで消すことができるかだが、 一般にテストは莫大な時間と工数を要するので、 そこはリスクとのトレードオフになる。 もし仮に万全と思われるテストを施していたとしても、 マクロ的に見れば、不具合が出るかでないかは単なる確率事象だから、 不具合が発生したときに「テストを万全に行えばあらゆる不具合は防げたはずだ」 と批判することは必ずしも的を得ていない(※)。 特に、システムトラブルが発生した際に、 現場で連日徹夜で対応にあたる技術者のことを思えば、 「たるんでいる」という批判だけで済まされるような問題ではない。

※ もちろん、 テストをいかに効果的に行なうかということは不具合の数を減らす上で極めて重要である。 たとえば、最近の社会基盤ソフトウェアのトラブルに鑑み、 信頼性を向上させるためのテスト手法に関する情報交流として、 JaSST (Japan Symposium on Software Testing) が本年3月に開催されている。

割にあわない地味な仕事 ?

一般に、大規模なシステム統合や業務系システムの構築というのは、 どうしても地味な仕事という印象がある。 うまくいって当たり前、失敗すれば何をしているのか、と叱責されてしまう。 組織のしがらみや硬直化、連日の徹夜、 悲惨な作業環境というイメージを植え付けるかのような報道も多い。 経営戦略の重要な一翼を担うはずの情報システムの構築は、 いうまでもなく非常に重要な仕事であるにも関わらず、 どうしても裏方のイメージ、換言すれば「割に合わない」 というイメージがつきまとっている。

一方でこうした分野では優秀な人材が必要なことはいうまでもない。 もし、「地味で不条理な仕事」といったようなイメージが定着してしまうと、 こうした現場は次第に敬遠されるようになってくるだろう。 経営戦略における情報システムの重要性が高まる一方で、 優秀な技術者から敬遠される状況になっているとすれば極めて危惧される状況ではないだろうか。

柔軟な創造力が発揮できる局面

システム統合や、大規模業務システム構築のような、 できることが大前提となっているようなシステム開発に対しても、 高い付加価値を求め、かつそれを健全に評価する仕組みが必要である。 創造性よりも従順性、俊敏性よりも確実性が重視されると思われがちな システム開発において、どのような付加価値が考えられるのだろうか ? 以下、考えられるところを列挙してみよう。

• 開発工数をいかに工夫して短縮できるか ?
  開発方法論を工夫する、新しい技術を取り込むなどにより、 開発工数の削減を行う。 ただし、通常、システム開発費用は、工数の積み上げで見積もられるので、 工数を削減するとかえって仕事を増やしてしまうといったような意識もあり、 インセンティブは働きにくい。 開発工数削減に対する成功報酬など、契約形態の再考も必要だろう。
  
  
• 付加的なパフォーマンス向上が達成できるか ?
  最初に決められた最低必要条件のみをクリアできれば、 あとはどうでもいいのではない。 良いパフォーマンスがシステムの価値を決めるくらいの意識を持つ必要がある。
  
  
• いかに柔軟な対応力が発揮できるか ?
  仕様や条件は必ず途中で変わる。 それはできません、というのは簡単だし、相手も納得してもしまうのだが、 これができるかどうかが付加価値の分かれ目になる。
  
  
• 技術者の満足度向上
  開発の進め方を全員で共有し、自由に意見をいいあえる環境を作ることで、 参加する技術者の満足度を向上させる。また、 後々参照できるようにうまくドキュメント化しておき、 成功事例として積極的に内外にアピールすることが重要である。

創造性の働かない硬直化したプロジェクトでは、開発者のモチベーションは低下し、 良い人材も集まらない。 これからは、「うまくできることが当たり前」ではなく、 「いかにうまくできたか」が問われ、評価されなければならないのである。 もちろん、これは、開発者側だけの問題だけでなく、 その成果を正当に評価する顧客や社会の理解も必要だ。