第2回：一行減らせて嬉しかったのに… (3/3)

設計変更によってすべてが水の泡に…

システム開発を行う上で、その設計は非常に重要である。しかし当初の予定から変更が加えられるケースも、この業界ではよくある話だろう。

20代のプログラマであるG氏は、参画していたプロジェクトにおいて、設計にまつわる非常に怖い体験をしたと語ってくれた。それはある意味で、先を見越したプログラムを行っていたからこそ、起こった悲劇といえるかもしれない。

「私の担当していたプロジェクトの中で、大量のデータをあつかうプログラムを作成する、という箇所がありました。若干非力なシステム上でデータをあつかわなくてはいけない関係上、インデックスを指定してテーブルからデータを取得する、という形で進めることになりました。

取得したデータは10種類程度のモジュールで、それぞれ画面上に展開されることになっており、前述の設計ポリシーによって、満足できる実行速度を実現できるようになりました。

順調に開発は進んでいるかのようにそのときは考えていたのですが、スケジュールが終盤にさしかかったとき、上司から伝えられたのは『テーブル列の順番を変更する』というものでした。目の前が暗くなりました。

インデックスを指定してテーブルからデータを取得するというロジックを組んでいたため、テーブル列の順番変更はすなわちインデックスが役にたたなくなるということです。案の定、というか悪い夢をみているかのように、開発中のシステムでは動作しなくなる画面が多発しています」

「すでにインデックスを使用した形でシステムは構築されつつあります。すべてを1からやり直すことはできません。しかし納期は迫ります。結果的に人海戦術でインデックスの書き換えを行うしかありませんでした。

なんとか納期に間に合わせた後、そのプロジェクトに参画したメンバー一同、『インデックスでデータ取得するのは後工程を考えてから』が合言葉になりました。もちろん設計問題や設計ポリシーと絡む問題なのですが…」

「良し」と思った設計が後々に引き返せない状況を作ってしまう。それまで万全で進んでいたプロジェクトだけにショックや恐怖の大きさは計り知れない。

最後に30代のシステムエンジニア、H氏の恐怖体験を紹介しよう。

「バッチ処理の異常処理をミスして、企業の受注残データをすべて消去してしまいました。…バックアップから復旧できたので、一安心。平謝りでした」

シンプルだが、非常に怖い話だ。

次回は、それで発生した追加コストはどうなったの？　と思わず心配したくなる恐怖の事例をお届けする。公開は12月21日だ。 タイトルへ戻る