稼働中のシステムのハードウェアやソフトウェアを刷新する場合、バグの兆候として下記のものがあります。
表示している内容が違う場合は、ロジックではなく、データに間違いがある可能性があります。よく見直しましょう。
新旧で同等の部分がある場合は、新旧で同等の結果となるか確認しましょう。「表示内容に違いがある」「計算処理が間違っている」などの食い違いがある場合は、新システムのバグの可能性大です。
レガシーシステムの呪縛から逃れるには、顧客の協力も欠かせません。開発側に丸投げする担当者の場合、仕様抜けなどが多分に発生する可能性があります。注意してください。
ここからはシステム刷新でバグが起こらないようにするための対策を紹介します。
データに関連するバグは、手作業で行うのは危険です。整形ツールや自動スクリプトを作成し、再現可能な仕組みを作成しましょう。また、顧客によく確認してもらうとより問題が整理できます。
顧客側での受け入れテストは確実に実施しましょう。作り手と使い手のマインドは異なります。ここで、機能漏れが見つかることは非常によいことだと考え、確実に実行しましょう。
筆者の失敗にもある通り、最大構成でテストしないと、リリース後に思わぬバグに悩むことになります。最大構成を構築することは簡単ではありませんが、確実にやっておきましょう。
21世紀以降のソフトウェア開発の課題が、レガシーシステムとの戦いでしょう。その中でも、今回、非常に小規模ではありますが、ECサイトのシステム刷新時のバグを紹介しました。非常に小規模ですが、数ある案件のケーススタディーとして考えていただければと思います。
[1]みずほ銀行システム統合、苦闘の19年史 史上最大のITプロジェクト「3度目の正直」(山端宏実、岡部一詩ほか、2020年、日経コンピュータ)
本シリーズ「ソフトウェア技術者のためのバグ百科事典」を大幅に加筆、修正した山浦恒央先生の新刊「ソフトウェア技術者のためのバグ検出テキスト」が日科技連出版から発売されました。連載でも取り上げた、「要求仕様書のバグ」「実装抜けのバグ」「テスト業務のバグ」など、バグを36種類に分類して解説しました。囲碁や将棋であれば、「相掛かり」「矢倉」「四間飛車」「藤井システム」のような戦法を網羅した内容になっています。
前著「ソフトウェア技術者のためのバグ検出ドリル」(2019年11月刊行)も好評発売中です。実際にバグを含む要求仕様書、設計書、コーディング、デバッグ、保守を具体的に取り上げ、練習問題として31問を出題しました。同書は、囲碁や将棋における「次の一手」的な問題であり、ピンポイントの場面を取り上げ、実践力を鍛えることを目的としています。
両書とも興味のある方は、Amazon.comや書店でチェックしてください!
東海大学 大学院 組込み技術研究科 非常勤講師(工学博士)
Copyright © ITmedia, Inc. All Rights Reserved.