最近、7月の大雨でダムの決壊を防ぐために放流したことで多くの人命が失われるという事件があった。下流域の住民を含めてシステムを捉えることで、システムリスクへの対処内容が変わった可能性がある。放流したことは止むを得ないにしても、下流域への被害を最小化するために十分な活動が実施されていたかが問われるのではないか? ダムの決壊を防ぐことが、ダムを含む地域全体の安全と必ずしも一致していなかったのではないかと思われる。

システムの安全性をどのように捉えるかという点では、ビジネスでも同じような状況が考えられる。現行システムを守ることが、システムによって運営されるビジネスを危機的な状況に追い込むことになる可能性がある。ビジネス機会が消失したのでは、現行システムを守ることに価値があるとは思えない。したがって、システムとシステムがおかれるビジネス環境との関係を把握する必要がある。システムが安全であるためには、安全性に対するリスクが解消されていることが必要である。

ビジネスにおけるシステムリスクとは、システム障害によるビジネスの停止だけでなく、システム構築が迅速性を欠くことに起因するビジネスの遅滞、システムの仕組みが旧式で最新の技術革新による性能を享受できないことなどがある。

システム障害によるビジネス継続性リスク

最近の例では、みずほ証券のインターネット取引サービスが2日間停止した事例があった。このシステム障害の原因は運用トラブルであった。このようなトラブルを抑止するためには、運用プロセスを自動化する必要がある。しかし、そのためには、運用手順が標準化されている必要がある。筆者らの経験では、運用プロセスをITIL準拠としている組織は多いが、実際はITIL資格取得者が参画してはいるものの、運用手順そのものを明確に規則化している組織は多くない。もし、適切に障害発生時の運用手順が確立できていれば、運用インシデントが発生した際に、原因究明と障害による2 次的影響範囲の限定が即時対応できているはずである。障害復旧後に菓子折りを持って顧客に謝罪することが運用リスク対応ではない。運用手順が明確になっていなければ、運用リスクを識別することはできない。運用手順の成熟度を直ちに確認し、運用リスクを識別するとともに対応すべきだ。

システム開発の迅速性の欠如によるビジネス即応性リスク

グローバル企業では、大規模システムのアジャイル開発が浸透している。アジャイル開発するためには開発対象を小規模化する必要がある。また、小規模な開発要素によって大規模システムを構築するためには、多数の開発要素を適切に連携するためのアーキテクチャが必要である。シェル石油では、エンタープライズアーキテクチャによってアジャイル開発を取り込む仕組みをIT4IT[1] として標準化している。現代のエンタープライズアーキテクチャ(EA) の目的は、ビジネス即応性の実現である[2]。ビジネス即応性の点で、アジャイル開発とEA は共通のゴールを持つのである。例えば、グローバル企業である武田薬品では、日本を除くグローバルなすべての開発案件がクラウドを前提とするアジャイル開発になっており、デジタル変革を推進している。アジャイル開発案件が個別に乱立してしまうと、収拾がつかない。アジャイル開発案件のガバナンスが必要である。このような迅速な開発を実現するために、同社では経営幹部も参画するEA委員会で、開発案件のリスクを制御している[3]

同社では、日本だけがオンプレミスのレガシーシステムの維持を主張するとのことで、日本の特殊性が際立っているようである。いずれにしろ、現代EA の目的は社内システムの最適化ではなく、ビジネス即応性の実現であることが、グローバル企業では広く認識されている。また、アジャイル開発のためにも、EAが必要であることは明らかだ。

システム基盤老朽化に伴う性能低下によるビジネス競争力の低下

現行システムのモダナイゼーションでは、顧客企業から「現行踏襲で進めたい」という案件が多いようである。現行踏襲になる理由の1 つは、現行システムが大規模化・複雑化・ブラックボックス化しており、現行システムの内容が見えないことがある。上述したように、本来であれば、「このようなビジネス変革を実現したから、現行システムの必要な部分を再利用して、新たな機能と性能を早期に実現するとともに、不要な部分を廃棄することで運用経費を削減したい」というべきところだ。現行システムの仕組みが不明確であると、不要な部分を識別できないため、丸ごと移行することになる。この場合、従来のシステム基盤では、ハードの制約から性能を実現するために必要となった仕組みも、最新のハードでは不要になることが多い。したがって、現行の情報システムがこのような従来のシステム基盤と密結合していると、最新のハードを活かしたシステム基盤の上に旧式のシステム基盤が重畳されることになり、期待する性能を実現できないことになる。最新のシステム基盤の上に実現された競合企業のシステムと、このような現行踏襲型のシステムでは、性能面で2桁以上の差が出てもおかしくはない。現行踏襲の採用による狭量なシステム開発リスクの低減が、ビジネス競争力の低下をもたらすことになる。ビジネス即応性を考慮したシステム基盤と情報システムのデジタル変革が必要である。

また、現行システムの複雑性を解消し、単純化するために海外では、現行システムのマイクロサービス化が進んでいる。ある会合で、基幹系システムのマイクロサービス化に取り組むべきだと発言したら、ブラックボックス化した現行システムをマイクロサービス化するのはリスクが大きすぎるという意見が多かった。しかし、現行システムをそのまま移行したのでは、ビジネスの変化速度に追従できない。システム開発リスクではなく、ビジネス変革即応性に焦点を合わせるグローバル企業に勝てるはずがない。

これらのシステムリスクへの対策として、経営面から見たシステムに対するガバナンスの強化が必要である。特に、AI、ビッグデータ、クラウドサービス、IoT、ロボティクス、モバイル、マイクロサービス、RPAど、最近のデジタル技術の発展は目を見張るものがある。これらの技術を活用したソリューションが個別、還元主義的に開発されていくと、企業全体では新たな混乱が発生することになる。

このような混乱を防ぐためには、ビジネス全体の中でシステムを捉えることにより、前述したEAによるガバナンスの仕組みを確立する必要がある。例えば、グローバルに普及しているEAであるTOGAFはビジネスアーキテクチャ、情報システムアーキテクチャ、テクノロジーアーキテクチャ、物理アーキテクチャによって階層化している。デジタル技術をこのEA階層に対応付けた、次のような取り組みが必要になる。
・ビジネスアーキテクチャ:RPAによる業務の自動化、IT運用の自動化
・情報システムアーキテクチャ: マイクロサービス、モバイルサービス
・テクノロジーアーキテクチャ:ビッグデータ、クラウドサービス
・物理アーキテクチャ:IoT、ロボティクス、モバイルデバイス

まとめると、次の2 点になる。

①システムの安全性はシステムリスク
を個別に解消することではない。

②経営面から全体的に統制していく試みがグローバルなビジネス競争では必要になる。

[1] 山本修一郎、 IT サービス・マネジメントの技法、出版社: デザインエッグ社; (2017/11/20)、 ISBN-10: 4815002533
[2] 山本修一郎、現代エンタープライズ・アーキテクチャ概論 – ArchiMate 入門、出版社: デザインエッグ社; 2016/7/20) ISBN-10: 4865436804
[3]  Yoshimasa Masuda, Seiko Shirasaka, Shuichiro Yamamoto, Thomas Hardjono, R i s k M a n a g e m e n t f o r D i g i t a l T r a n s f o r m a t i o n a n d B i g D a t a i n Architecture Board: A Case Study on G l o b a l E n t e r p r i s e , I n f o r m a t i o n E n g i n e e r i n g E x p r e s s , v o l . 4 , No.1,pp.33-51, 2017

<システム安全性のことなら下記へ>

yamamotosui@icts.nagoya-u.ac.jp