システム開発では、ローンチまでの間に小さなタスクの『成功』と『失敗』を繰り返しながら挑戦に満ちた過程を進捗していきます。
小さなタスクの『失敗』を他のタスクでカバーしながら進捗して、最終的に『成功』に繋げられれば良いのですが、残念ながら『失敗』のまま終わることもあります。
これらの『失敗』は貴重な教訓をもたらし、次のプロジェクトを成功に導くための重要な指針となります。
今回は、過去に発生した世界におけるシステム開発の失敗例について、背景と原因とともに紹介し、そこから学べる教訓について考えてみたいと思います。
失敗例 1 : Healthcare.gov のローンチ失敗
背景 :
2013年、アメリカ政府は Affordable Care Act (オバマケア)の一環として、国民がオンラインで医療保険にアクセスできるマーケットプレイスである Healthcare.gov を開設しましたが、Web サイトのローンチ直後から技術的問題やパフォーマンスの問題が発生し、数百万の利用者がアクセスできないという状態が続きました。
原因 :
●スケジュールの圧力
政治的な理由からリリース日が厳格に決められており、十分なテスト期間を設けられなかったことや不具合に対する修正を行う余裕がありませんでした。
●複雑な要件
医療保険システムは仕様が非常に複雑で、多くの異なるステークホルダーの要件(要求含む)を満たす必要がありました。
●不十分なテスト
パフォーマンステストやストレステストが不十分で、多数のユーザーがアクセスした際にシステムが負荷に耐えられませんでした。
教訓 :
プロジェクトを進めるにあたって『トラブルはつきもの』です。
複雑なシステムでは、それが顕著に現れるものですので要件を明確にして関係者全員が共通した認識を持つことが必要です。
また、想定していなかったリスクが顕現したとしても、リカバリーができるようにプロジェクト全体のスケジュールには余裕を持ち、十分なテスト期間を確保してシステムの品質を担保することは必須です。
スケジュールが厳しい場合でも、テストを軽視することは避けるべきであり、品質を犠牲にした場合の末路は、最終的により大きな代償(コスト)を支払うことになるでしょう。
失敗例 2 : ナイトキャピタルの新アルゴリズムによるトレード失敗
背景 :
2012年にナイトキャピタル・グループ(アメリカ)は、新しいアルゴリズムの取引ソフトウェアを導入しましたが、導入直後にシステムが誤作動を起こし、1分あたり100万ドル、これが45分間続き、約4億4,000万ドルの損失を出しました。
原因 :
●人為的ミス
手動でシステムの切り替え(デプロイ)が行われ、その際に 1 台だけ切り替えを忘れるというミスが発生しました。
●部分的な切り替え(デプロイ)
新しいソフトウェアと古いソフトウェアが同時に稼働したことにより、本来は稼働することがないはずの試験的な機能のデッドコード(未使用プログラムコード)が動作してしまい、誤作動を引き起こしました。
●不十分なテスト
実際の取引環境での十分なテストが行われていませんでした。
教訓 :
ソフトウェアのデプロイメントは慎重に行い、可能であれば手動ではなく、CI/CD ツールなどを利用した自動化を行い、全体の整合性を担保することが重要です。
また、商用環境など、実際と同等の環境で十分なテストを行うことや、人為的ミスを最小限に抑えるためにプロセスや手順などを整備することが必要です。
失敗例 3 : オーストラリア国税庁(ATO)のシステム障害
背景 :
2016年、オーストラリア国税庁(ATO)のシステムがダウンして、オンラインサービスが数週間にわたって利用できない状態となり、多くの納税者や企業に大きな影響を与えました。
原因 :
●ストレージ障害
主要なストレージシステムに障害が発生し、データへのアクセスができなくなりました。
●バックアップ計画の不備
バックアップとリカバリーの計画が不十分で、復旧に時間を要しました。
●複雑なシステム構成
システムが複雑に構成されており、根本原因となる問題の特定とその修正が難航しました。
教訓 :
システムのバックアップ計画は、障害時に迅速に復旧できるようにすることが目的ですので、復旧リハーサルなどを通じて事前に手順などを整理しておくことが重要です。
また、システム構成はリカバリー計画を踏まえて検討するべきで、複雑な構成を避けることで、問題発生時の迅速な対応を可能にすることができます。
失敗例 4 : ロイヤルバンク・オブ・スコットランド(RBS)のシステム障害
背景 :
2012年、ロイヤルバンク・オブ・スコットランド(RBS)はシステムのメンテナンス中にエラーが発生し、数百万の顧客が数日間にわたってオンラインバンキングサービスが利用できないという状態になりました。
原因 :
●ソフトウェアアップデートの失敗
バッチ処理システムのアップデートが失敗し、トランザクションが処理されませんでした。
●古いシステムの維持
老朽化したシステムが使用されており、知見のある技術者もおらず、トラブルシューティングが非常に困難な状況となりました。
●不適切な緊急対応
エラーが発生した初期の対応が遅れてしまい、問題の拡大を防ぐことができませんでした。
教訓 :
システムに関わるソフトウェアのメンテナンスやアップデートは事前に内容を精査して、影響度などを考慮して慎重に行うべきであり、発生しうるリスクを事前に検討しておき、影響を最小限に抑えるための対策を講じておくことも重要です。
また、老朽化したシステムやソフトウェアのバージョンアップ、障害発生時の緊急対応における体制やプロセスを平時に整備しておくことが大切です。
まとめ
ここまで一例ではありますが、過去に発生した世界におけるシステム開発の失敗例を見てきましたが、いかがでしょうか。
結果だけを見ると、システム開発に携わるものとしてはゾッとする規模の影響が発生していますが、どの事例でも要件が不明確であったり、タイトなスケジュールを強行したことやコミュニケーション不足、テストが満足に行えていない、緊急時の方針や手順が整備できていないことなどが原因となっています。
これらの原因について、聞いたことがないというシステム開発者はいないと思います。
つまり、システム規模の大小を問わず、プロジェクトを『失敗』へと誘う原因は常に身近に存在すると言っても良いと思います。
このことをしっかりと認識して、過去に発生した『失敗』から学び、次に活かすことでプロジェクトの成功率を高めることができると思います。
明確な要件定義、十分なテスト、綿密なコミュニケーション、適切な技術選択といった基本を守ることで、『失敗』のリスクを大幅に減らすことができるでしょう。
積極的に学び続ける姿勢こそが、優れたシステムを生み出す原動力となるのではないかと思っています。
SmartBee
作業項目や現場情報の一括管理を可能にするクラウドサービスです。
SmartBeeを導入すれば、管理業務の負担が減るばかりでなく、点検現場の状況をリアルタイムで把握でき、ミスやコスト削減につながります。
