日経コンピュータ2017/8/3号特集「変わるITトラブル」を読んだ

趣味のITトラブルウォッチャー活動として、日経コンピュータ2017/8/3号の特集「変わるITトラブル　実例1096件分析、新事実が明らかに」を読んだ感想。日経コンピュータ創刊の1981年から現在まで「動かないコンピュータ」コーナーなどに掲載された事例を分析したというもの。なお記事には残念ながらデータは掲載されておらず。

突然のシステムダウン、システム刷新プロジェクトの失敗----。
1981年の本誌創刊号から2017年までにわたって「動かないコンピュータ」などに載せたトラブル事例は実に1098件。これらを分析して、トラブル防止につながる知見を得られないか、こう考え、セキュリティ関連、システムダウン、開発失敗というITトラブルの3大リスクを対象に様々な角度から調べてみた。すると、知られざる傾向と対策が見えてきた。

• 日経コンピュータ2017/8/3号 特集「動かないコンピュータ 変わるITトラブル　実例1096件分析、新事実が明らかに」

なお記事の詳細は同誌を確認いただきたい。

• 雑誌：日経コンピュータDigital
• 日経BP書店｜商品詳細 - 日経コンピュ−タ

三大リスクは本当に「三大リスクなのか？」

最初に気になったのは、この特集で取り上げられた三大リスク（セキュリティ、システムダウン、開発失敗）が本当に重要なものなのかがよく分からなかったというもの。概要でもいいのでデータ全体に触れられていれば良かった。もちろん掲載されているリスクはそれぞれ重要なものではあるが。

三大リスク①セキュリティ編

不具合やハードの故障以外の要因として、サイバー攻撃や脆弱性関係のトラブルが大きなリスクとなりつつあるという分析。記事の中では以下のような分析があって興味深い。

• システムダウンの原因別割合(年代別) 日経コンピュータ調べ
  • 2010年代から急増
• セキュリティに関連したトラブルの原因別割合(2010年代) 日経コンピュータ調べ
  • サイバー攻撃・脆弱性関係が8割以上を占めている
• クレジットカード不正使用被害の発生状況(2014年-2016年) 日本クレジット協会調べ
  • 2015年以降急速に増加

嫌な世の中になったものだ、といっても仕方が無いのだけれども、ユーザの要求に従ってシステムを構築しただけではNGな時代に突入したということだと理解している。また、セキュリティのリスクは常に(攻撃手法等や発見される脆弱性が)変化するので、システム開発時だけではなく運用でもどう刈り取っていくのかよく考えなくてはならない点だ。個別エンジニアのスキルで討ち取るのは困難なので、支援体制がちゃんと整っているかどうかがポイントだと思っている。

しかし、この傾向は別に日本に限った話でもないわけで、そういう意味ではグローバルのトレンドも気になるところだけれども、どこかに整理されているものはないか、別の機会に調べてみようと思っている。

三大リスク②システムダウン編

システムダウンのうち「全面ダウン」の比率が10年代に比率として増加しているという話と、いくつかの最近増加しているトレンドについて整理されている。こちらの章で紹介されている分析は以下の通り

• システムダウン全体に占める全面ダウンと一部ダウンの割合(年代別) 日経コンピュータ調べ
  • 2000年代で若干全面ダウン比率下がるも、2010年代でまた上がる
• 全面システムダウンの原因別割合(年代別) 日経コンピュータ調べ
  • ハード起因の比率が微増
• ハードウェア故障の原因別割合(年代別) 日経コンピュータ調べ
  • サーバーに起因するトラブルが増加
• 平均ダウン時間の変化(年代別) 日経コンピュータ調べ
  • ダウン時間は増加トレンド

記事を注意して読まないといけないのは、システムダウン自体が増加しているわけではなくて、システムダウンのうち「全面ダウンの比率」が増えているという件。件数自体は2000年代から2010年代は減っている。もちろん、件数としてカウントされているのは日経コンピュータの取材、情報収集の範囲に限定されるので実際にシステムダウンが増えているのか、減っているのかというのはなんとも言えないように思える。

ただ、平均的なシステムの複雑度は以前より上がったのは事実だと思っている。

• そもそものシステムに対する要求がゼロ年代から難易度アップ
• システム間の連携も複雑化（というか世の中のシステムが増えた）
• ゼロ年代に構築されたシステムが再構築を経て魔窟化、もしくは延命されて妖怪化
• 採用テクノロジーが複雑化、組み合わせが多様化

で、複雑度が上がれば予期せぬ全面ダウンのリスクも増えるわけで、アンチフラジャイルとかレジリエンスなどは今後重要なテーマになっていくような気がしている。

• ソフトウェアにおけるアンチフラジャイルとレジリエンス - 勘と経験と読経

反脆弱性[上]――不確実な世界を生き延びる唯一の考え方

反脆弱性[下]――不確実な世界を生き延びる唯一の考え方

三大リスク③開発失敗編

システム開発失敗の主因は要件定義にあるというストーリー。ただ、ここでも注意が必要で、システム開発失敗の件数そのものは減少傾向である。失敗はしにくくなったが、失敗するときには要件定義工程で大コケする、という話と考えたほうがいいと思っている。本章で提示されている分析は以下の通り。

• 開発失敗の4大要因とその割合(年代別) 日経コンピュータ調べ
  • 2000年代から2010年代について、トップ要因は「ユーザ企業が要件をまとめられず」であるが、2位の「ベンダーが要件を理解できず」が2000年代再開から急浮上している
• 工期遅延理由の分類 JUAS「ユーザ企業ソフトウェアメトリックス調査2016」より
  • 遅延理由の4割が要件定義関連
• 開発失敗の事例におけるソフトウェア開発形態別の割合(年代別) 日経コンピュータ調べ
  • パッケージ導入タイプの失敗が大幅に増加
• 開発失敗により稼動延期期間の割合(年代別)
  • 稼動延期期間は短縮傾向、超リスケは減っている

システム構築の受注者側であるSIベンダ等の開発能力や管理能力の向上の結果、適切な要求オーダーがあればシステムを完成させる能力は向上していると思っている（もちろん色々な課題はある）。ボトルネックが要件定義などのいわゆる上流工程に移っているという理解。発注者・受注者の共同作業である要件定義で、どちらかの能力不足によって「ユーザ企業が要件をまとめられず」または「ベンダーが要求を理解できず」で失敗するというのは当然だろう。

あと記事では言及されていないけれど個人的に気になるのは、システム再構築プロジェクトの増加だと思っている。記事の中では「再構築プロジェクトは大規模・ビックバンになってしまい開発規模の大きさからトラブルになりやすい」といったニュアンスの言及はあるけれども、再構築プロジェクトそのものの難しさ、要求／仕様抽出の困難性や人的要因（「わかる人がもういない」）は失敗トレンドの変化に越境を強く与えているのではないか。まぁ、あくまで感覚論なのだが。

なぜ、システム開発は必ずモメるのか？