PR

 あるメガバンクのシステム部門に所属している友人から聞いた話である。

 この友人は大学卒業後,このメガバンクの前身である大手都銀に入行。約2年の営業担当を経てシステム部門に配属され,SEとして様々なシステム案件を手がけてきた。

 筆者は以前,この友人と会うたびに,彼が所属するシステム部門の保守的な文化や,部下の提案に聞く耳を持たない上司の愚痴などをよく聞かされていたのだが,その友人がある時,「もう我慢できない」と漏らしたことがあった。それは今から数年前,彼が勤務する大手都銀が別の大手都銀と経営統合することになり,両行のシステム部門がそれぞれシステム統合に向けた準備に着手した頃だった。

 ご存知の読者も多いと思うが,企業間の合併・買収などに伴うシステム統合では,それぞれの企業が保有している既存システムを,業務(あるいは機能)単位で比較検討し,一方のシステムを存続させて他方のシステムを統合するか,それとも全く新しいシステムを一から再構築するか,といったことを決定する。銀行であれば,勘定系,情報系,店舗系,対外接続系といったシステム同士を比較することになる。

 システムの統合方法を決定する際には,それぞれの性能や拡張性,経営統合後のビジネス展開への適性など,さまざまな観点から判断を行うわけだが,これ以外に企業間の“バランス(平等性)”といった,現場のSEには理解しがたい要素が絡んでくることがある。筆者の友人が「我慢できない」と漏らした理由は,こうした企業間のバランスよりもさらにタチの悪い,企業間の“エゴ”のぶつかり合いと言っていいようなものだった。

 友人の説明はこうだ。

 彼が所属するA行のシステムと,統合相手であるB行のシステムを個別に比較し始める前に,ある業務のシステムについては,A行がまだ開発途中だったのに対し,B行は既に開発済みであることが判明した。そこで,友人をはじめA行のスタッフは,当然,B行が開発済みのシステムをベースにシステムを拡張していくことになると考えた。

 ところが驚いたことに,A行のスタッフには,B行のシステムと比較できるようにすることだけを目的に,開発途中のシステムを突貫工事で完成させるという指示が出されたのだという。

 当然,スケジュールが最優先であり,品質は二の次である。こうして,いわば形だけ完成させたA行のシステムとB行のシステムを比較した結果,案の定,B行のシステムが採用されたという。

 システム部門の現場では,この案件がトップからの理不尽極まりない開発命令だと受け止められた。当然だが,友人をはじめ,この開発に携わったスタッフのモチベーションは下がる一方だった。何人かは本気で「この銀行をいつ辞めるか」ということまで話し始めたという。

 以上の経緯は,あくまで友人の発言に基づいたものであり,突貫工事を行うことになった理由について,実は本人の知らない事情や背景があったのかもしれない。また,不満や怒りの感情から,友人が話を少し膨らませて筆者に話した可能性もあるだろう。しかし,古くからこの友人を知る筆者は,A行ではおそらくこの話に近い事実が存在していたのだと確信している。

軌道修正できるだけの知識と心構えを

 このケースは少し極端かもしれないが,読者の皆さんも,システム開発の現場で,理不尽としか思えない開発案件に遭遇したことがあるのではないだろうか。

 理不尽と感じる原因はさまざまだろうが,とりわけシステム化の目的が十分に議論されないまま(あるいは考慮された気配が全く感じられないまま),トップダウンで決まったシステム案件では,現場に大きな不満が蓄積しやすい。経営トップの“政治的決断”やコスト効果に関する誤解などによって始まったERPパッケージ導入プロジェクトなどは,その最たるものだろう(ERP導入に関しては以前から様々な議論が尽くされているので,ここではこれ以上触れない)。

 特に誤解に基づく開発案件では,現場はひたすら疲弊し,その一方でトップ自身も期待した効果が得られないので不満を抱く,という具合に,会社全体に痛みしか残らない可能性が高い。企業の経営トップだけでなく,CIO(最高情報責任者)やシステム部門のマネージャが誤解に基づく意思決定を行った場合にも,同じことが言えるだろう。

 しかし,誤解であれば,軌道修正できる可能性もあるはずだ。その点,冒頭で紹介した友人のケースのように度を越した理不尽や,現場が手も足も出せないような政治的決定とは違う。だとすれば,システム部門内での立場はさておき,誰かがその誤解を解かねばなるまい。

 とりわけ今後1~2年にわたって,こうした誤解に基づく理不尽なプロジェクトが増えなければいいが,と心配させられるのが,内部統制に関する開発案件である(参考記事「危機管理のキモは“事件”の前?後?」)。

 今年5月には会社法が施行され,6月には金融商品取引法(いわゆる日本版SOX)が国会で成立。金融商品取引法は,2008年4月以降に開始する事業年度(2009年3月期)から適用されることが正式に決まった。一方で,ITベンダーやコンサルティング会社などは,内部統制に関連するソフトウエア製品や支援サービスを相次いで投入しており,その数は急増している。

 そうした状況のなかで,企業経営者が内部統制の本来の目的から離れ,新法適用の期限が迫る焦りも手伝って,不要な(あるいは優先度の低い)案件を含む膨大な作業をシステム部門に押し付けてしまうことはないだろうか。筆者はその可能性は十分にあると考える。実際,そうした危機感を抱いているシステム部門も多い。

 例えば,金融商品取引法が規定する内部統制の目的は,あくまでも「財務報告の不正を防止すること」にある。もちろん,財務報告の不正防止にかかわる取り組みには,コーポレートガバナンス(企業統治)やセキュリティ対策など様々なものがあるが,ガバナンスやセキュリティ対策そのものは目的ではない。

 そこを誤解すると,実は財務報告の不正防止には直接関係のないセキュリティ対策に時間やコストをかけ過ぎてしまったり,逆に,財務報告の不正に密接に関係する重要なリスクを見落としてしまう,ということになりかねない。

 内部統制関連の総合情報サイト「内部統制.jp」で,日本版SOX法対応に関する解説(「日本版SOX法対応は恐くない-IT部門の必須知識と心構え」)を連載中の公認会計士・岩谷誠治氏は,次のように指摘する。「不正を100%根絶しようとすれば,システム部門は間違いなくパンクしてしまう。肝心なのは財務報告に直結する業務プロセスの範囲を正確に見極めることであり,そこに取り組みの重点を置くべきだ。さもないと,スタッフが疲弊するだけでなく,システム部門として手がけるべき別の重要案件が後回しになるなど,会社にとっての損失も大きい」。

 システム開発の最前線で活躍するITエンジニアやマネージャがそうした事態を回避するためには,システム開発案件の本来の目的を正確に把握し,場合によっては,経営トップの誤解を解いたり説得したりできるだけの知識やスキルを身につけることが必要だろう。内部統制を例にとれば,金融商品取引法や会社法(内部統制.jpの参考記事「押さえておきたい「会社法」の基本」)が企業に求めていることの本質を正確に理解することが,システム部門に必要な取り組みの第一歩と言えるのではないか。

 システム開発の目的やその根拠を,会社全体の戦略や利害と関連付けて的確に説明できるITエンジニアは,システム部門の上司はもちろん,経営トップからも一目置かれる存在となるはずだ。そのような人材は,理不尽なプロジェクトを減らす大きな原動力にもなるに違いない。