修正の影響範囲が分からない？ そんなの徹夜でおやりなさい：美人弁護士 有栖川塔子のIT事件簿（8）（2/2 ページ）

[東京高等裁判所 IT専門委員 細川義洋，＠IT]

何よ、怖い顔をして。仕方がないわね、教えてあげる。そんなにあちこちに影響が出ちゃうシステムの作り自体問題アリだけれど、要は追跡可能性の問題よ。

追跡可能性？

あるプログラムの持ってる機能が、どの設計を基にしたもので、その設計はどういった要件から作られているのかを追跡できること。この管理はなかなかの難題よ。

そうなんですー。その辺り、実は誰も把握していなかったんです。

実際、大変なのよ。要件と設計、設計とプログラムは1対1でシンプルにつながっているわけじゃないでしょ？

複数の要件から複数の設計、その先のプログラムも複数に分かれたり共通化されていたりで、N対Nのメッシュ構造になっちゃうんですよねー。

だから、ちゃんとしたプロジェクトでは『トレーサビリティマトリクス』というのを作って管理するのよ。

トレーサビリティマトリクス？

要件項目、設計項目、プログラム、テストケースに一つ一つIDを振って、ID同士の関連を1枚の表にまとめるのよ。

関連する他のID？

例えば「出品者管理のデータベースが必要で、こんな項目を書き込むべき」って、決める要因になった要件があるはずよね？

もしかして、あれですか？ 「オークションの一覧を、出品者の名前で検索し、画面に表示する」とか、「出品者は、自身でログイン名以外の情報を修正できる」とか。

そうそう、それよ。そういう要件項目一つ一つに振られているIDと出品者管理データベース設計書のIDが関連していることが分かるような表を作るのよ。そして、同じように設計書のIDと、それを基に作ったプログラムのID、さらにテストケースのIDも結び付きが見えるように管理する。

その表をたどると、変更の影響範囲を把握できるわけですね。

今は単純に要件と設計がつながる例で説明したけれど、実際には、要件から別の要件が導き出されたり、設計同士で双方に関連が出てきたりするから、相当複雑よ。

大きくなると、ちょっと人間技じゃないですね。

そうね。ある程度の規模になったら、専用ソフトじゃないと無理ね。

トレーサビリティマトリクス用のソフトですか。ソフトのお金と管理の手間が掛かっちゃいますね。

本来はこういう費用もプロジェクト管理費用の一部として、見積もりに入れておくべきなのよ。「ウチのプロジェクト管理費用は高いけれど、それだけのことをやる」って、ベンダーの付加価値をしっかり理解してもらうべきね。

なかなか言えないんですよねー、競合してると。

「安いが1番ってユーザーとは、付き合いを考えた方が良い」って前も言ったわよね？ ビルを建てる施主は、作業員の安全のために貼る防護ネットの費用をケチらないし、船で物の輸送を頼む人は、船舶保険代をケチらないわ。具体的な成果物が見えなくても、必要なものは必要なのよ。

でも困ったなあ。もうトレーサビリティマトリクスなんて段階じゃないんです。一部プログラミングまで始めてるので。

だったら最低限、要件として定義した項目とシステムテスト・ユーザー受け入れテスト項目※1の間だけもIDで結ぶことね。最悪、稼働後の機能モレや不整合を防止できるでしょ。それもダメなら、オペレーターが通常使う機能の要件と受け入れテストケースのIDを結ぶだけでも、やらないよりはマシよ。裁判でも、普段使う部分が動いていれば、システムの完成を認めてくれることが多いし…… てか、なあんか納得してないような顔ね。

いえ、納得はしてます。正しいとは思いますよ。ただ…… 今のプロジェクトで現実にできるのかなって。

正しいと思うのなら、とにかくやってみなさいよ。たとえ失敗しても経験値が上がる分だけ、何かしらマシになるはず。

失敗は成功の元？

自分が正しいと思ったことは、しがらみを破って突き進める。これは女のスペックよ。頑張ってみなさい。

そっかー。先輩が色んな男の人と、付き合っちゃ玉砕してるのも、そういう…… あ、何ですか。スマホなんか握っちゃって。それで私を殴るんですか？

ねえ彩音ちゃん。私ね、とっても素敵な動画を持っているのよ。

えっ？

以前一緒に旅行に行ったでしょ。あの時の彩音ちゃんのパジャマ姿、20歳過ぎてもプーさんの腹巻きがないと寝られないっていうアレ。

ゲゲゲ！

あんまり可愛いからネットにでもアップしようかと……

ぎゃあ！ ヤメヤメ、ヤメてえ！

今回のPOINT

• 要件・設計・プログラム・テストケースは、トレーサビリティマトリクスで双方向の追跡可能性を確保し管理するべき
  
  
• 追跡可能性管理に必要な工数をユーザーにも理解してもらうべき

　次回は3月7日掲載、塔子の愛読書が明らかに！

※1　システムテストやユーザー受け入れテストの項目は、本来要件に対応して作成すべきものなので、その対応関係をIDの結び付けで表現することは、比較的容易にできます。

書籍紹介

なぜ、システム開発は必ずモメるのか？

細川義洋著
日本実業出版社　2100円（税込み）

約7割が失敗すると言われるコンピューターシステムの開発プロジェクト。その最悪の結末であるIT訴訟の事例を参考に、ベンダーvsユーザーのトラブル解決策を、IT案件専門の美人弁護士「塔子」が伝授する。

細川義洋

東京地方裁判所 民事調停委員（IT事件担当） 兼 IT専門委員　東京高等裁判所 IT専門委員

NECソフトにて金融業向け情報システム及びネットワークシステムの開発・運用に従事した後、日本アイ・ビー・エムにてシステム開発・運用の品質向上を中心に、多くのITベンダー及びITユーザー企業に対するプロセス改善コンサルティング業務を行う。

2007年、世界的にも稀有な存在であり、日本国内にも数十名しかいない、IT事件担当の民事調停委員に推薦され着任。現在に至るまで数多くのIT紛争事件の解決に寄与する。

ITmedia オルタナティブブログ「IT紛争のあれこれ」

「美人弁護士 有栖川塔子のIT事件簿」バックナンバー

• 要件やシステム化の範囲はどうやって決めるのか？
• 業務要件のモレを無くすためにマークすべき人とは？
• もしも要件定義の無いシステム開発の担当になったら
• もし要件定義担当者とベンダーが「グル」だったら？
• 修正の影響範囲が分からない？ そんなの徹夜でおやりなさい
• その性能要件は消滅しました（えっ！？）
• 要件が決まるまで、テコでも動きません！
• パッケージソフト導入の「お・と・し・あ・な」
• 排他制御でアイタタタ！―― パッケージソフトの落とし穴
• 要件定義を決めるのはベンダーの仕事でしょ？
• そもそも要件定義って何なのよ
• IT訴訟弁護士「塔子」参上！
• 登場人物紹介　有賀一郎
• 登場人物紹介　西園寺彩音
• 登場人物紹介　成兼章介
• 登場人物紹介　有栖川塔子
• 登場人物紹介　全員