こんにちは、Hです。
つい先日ですが、他ベンダーが開発しているシステムで障害が発生していました。
業務に対する影響度も高かったためか、週内でリリースを完了させていました。
後で内容を聞いたところ、分析作業でのミスが発端でそのまま誰も気づかずにリリースまで行ってしまったとのことでした。
たしかに機能数は300を超えて、また関連するサブシステムも多数、一方で性能・セキュリティ等々
考慮すべき事柄がたくさんあるため、分析が漏れてしまうのは無理ないかもしれません。
しかしながらそれを無理と言っていては障害は防げません。
良い機会だったので私たちのチームだったらどうできたかなと考えてみました。
私たちのチームでは分析時には「分析観点」と呼ばれるものを用意して、分析作業を実施しています。
■分析観点
- 機能・画面影響調査
- DB影響調査
- サブシステム影響調査
- 外部IF影響調査
- 移行調査
- 競合調査
- 過去改修調査
- 仕様調査
- 方式検討
上記の観点別にするべき作業を一覧化して、各担当に割り振って実施してもらっています。
この観点のいいところは「どんな分析をすべきか？」というところをあらかじめ定義してあるので
時期やプロジェクトによってぶれることがないことです。
また観点を提示していることで要件定義の段階でも、そのような視点を持って
要件資料を確認することができるというメリットがあります。
作業を一覧化して分担をするのですが、調査対象が被ることがあります。よほど大きなダブりでない限り、それを許容するようにしています。なぜかというと分析結果の正確性が上がるからです。一人の人が分析してそれをレビューするというのもいいのですが、その作業者がちょっとしたミスをしていたら、なかなか気づきにくい場合もあります。そのため複数の人が同じ対象を分析することでお互いの結果を比較することができたりします。それによって精度があがるというわけです。
本題の障害については上記観点の「画面・機能影響調査」で見つけられそうです。
そして見つけた内容がどのようにして正しく設計書に反映されていくか、これは別の機会にお話ししたいと思います。
