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

» 2014年02月21日 18時00分 公開
[東京高等裁判所 IT専門委員 細川義洋,@IT]
前のページへ 1|2       
TOKO

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


AYANE

追跡可能性?


TOKO

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


AYANE

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


TOKO

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


AYANE

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


TOKO

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


AYANE

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


TOKO

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


AYANE

関連する他のID?


TOKO

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


AYANE

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


TOKO

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


AYANE

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


TOKO

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


AYANE

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


TOKO

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


AYANE

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


TOKO

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


AYANE

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


TOKO

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


AYANE

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


TOKO

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


AYANE

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


TOKO

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


AYANE

失敗は成功の元?


TOKO

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


AYANE

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


TOKO

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


AYANE

えっ?


TOKO

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


AYANE

ゲゲゲ!


TOKO

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


AYANE

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


今回のPOINT

  • 要件・設計・プログラム・テストケースは、トレーサビリティマトリクスで双方向の追跡可能性を確保し管理するべき

  • 追跡可能性管理に必要な工数をユーザーにも理解してもらうべき

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

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

書籍紹介

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

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

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

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


細川義洋

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

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

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

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



前のページへ 1|2       

Copyright © ITmedia, Inc. All Rights Reserved.

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。