1|2何よ、怖い顔をして。仕方がないわね、教えてあげる。そんなにあちこちに影響が出ちゃうシステムの作り自体問題アリだけれど、要は追跡可能性の問題よ。追跡可能性?あるプログラムの持ってる機能が、どの設計を基にしたもので、その設計はどういった要件から作られているのかを追跡できること。この管理はなかなかの難題よ。その辺り、実は誰も把握していなかったんです。要件と設計、設計とプログラムは1対1でシンプルにつながっているわけじゃないでしょ?複数の要件から複数の設計、その先のプログラムも複数に分かれたり共通化されていたりで、N対Nのメッシュ構造になっちゃうんですよねー。したプロジェクトでは『トレーサビリティマトリクス』というのを作って管理するのよ。プログラム、テストケースに一つ一つIDを振って、ID同士の関連を1枚の表にまとめるのよ。「オークションの一覧を、出品者の名前で検索し、画面に表示する」とか、「出品者は、自身でログイン名以外の情報を修正できる」とか。いう要件項目一つ一つに振られているIDと出品者管理データベース設計書のIDが関連していることが分かるような表を作るのよ。同じように設計書のIDと、それを基に作ったプログラムのID、さらにテストケースのIDも結び付きが見えるように管理する。その表をたどると、変更の影響範囲を把握できるわけですね。今は単純に要件と設計がつながる例で説明したけれど、実際には、要件から別の要件が導き出されたり、設計同士で双方に関連が出てきたりするから、相当複雑よ。大きくなると、ちょっと人間技じゃないですね。ある程度の規模になったら、専用ソフトじゃないと無理ね。トレーサビリティマトリクス用のソフトですか。ソフトのお金と管理の手間が掛かっちゃいますね。本来はこういう費用もプロジェクト管理費用の一部として、見積もりに入れておくべきなのよ。「ウチのプロジェクト管理費用は高いけれど、それだけのことをやる」って、ベンダーの付加価値をしっかり理解してもらうべきね。言えないんですよねー、競合してると。ビルを建てる施主は、作業員の安全のために貼る防護ネットの費用をケチらないし、船で物の輸送を頼む人は、船舶保険代をケチらないわ。具体的な成果物が見えなくても、必要なものは必要なのよ。トレーサビリティマトリクスなんて段階じゃないんです。一部プログラミングまで始めてるので。最低限、要件として定義した項目とシステムテスト・ユーザー受け入れテスト項目※1の間だけもIDで結ぶことね。最悪、稼働後の機能モレや不整合を防止できるでしょ。それもダメなら、オペレーターが通常使う機能の要件と受け入れテストケースのIDを結ぶだけでも、やらないよりはマシよ。なあんか納得してないような顔ね。いえ、納得はしてます。正しいとは思いますよ。今のプロジェクトで現実にできるのかなって。正しいと思うのなら、とにかくやってみなさいよ。失敗しても経験値が上がる分だけ、何かしらマシになるはず。失敗は成功の元?自分が正しいと思ったことは、しがらみを破って突き進める。これは女のスペックよ。