連載
» 2014年01月24日 00時00分 UPDATE

美人弁護士 有栖川塔子のIT事件簿(6):要件が決まるまで、テコでも動きません! (1/2)

システム開発では、要件の全てが要件定義工程の完了時点までに決まることはまれです。決まらない要件は未決事項とし、解決担当者や期限などを定めて継続的に管理することが大切です。

[東京高等裁判所 IT専門委員 細川義洋,@IT]
title_jikenbo_a.gif

※この連載は「なぜ、システム開発は必ずモメるのか?」(細川義洋著)のCHAPTER1を、著者と出版社の許可の下、一部修正して転載するものです。

 スーパー越後屋 御曹司の成兼章介は、オンラインショップシステムの開発を任されたのですが、社内からのさまざまな要望を要件としてまとめられません。「これ以上は待てない」とベンダーに迫られて、助けを求めに顧問弁護士 塔子のオフィスにやってきました。「と、塔子ぉぉぉぉぉ」

登場人物紹介

前回のお話

TOKO

どうしたの?


SHOSUKE

オンラインショップの開発がうまくいかなくて大変なんだ。要件定義の期限を3カ月以上過ぎてるのに、ウチが要件を固めないもんだから、ベンダーが怒っちゃって。


TOKO

どういうこと? ちゃんと話してみなさいよ。


SHOSUKE

みんなが勝手なこと言ってまとまらないんだよ。販促部長は「ショップの買い物にポイントを付けたい」って言うし、システム管理部長は「クレジットカードのセキュリティをもっと強化したい」って。そうしたら営業本部長が「販売実績の分析機能が欲しい」とか言い出すし……。


TOKO

想定外の要望が溢れて、取捨選択もできないのね?


SHOSUKE

その上、売り場のオバちゃんたちに画面を見せたら、「文字入力が多過ぎる」とか「画面が分かりにくい」とか「字が小さい」とか、もうぐちゃぐちゃ。最後はみんな、僕に何とかしろって……。


TOKO

板挟みになってボコボコにされるのも、いい経験じゃない。


SHOSUKE

そんなこと言わないで助けてよ! 僕、どうしたらいいんだよう。


TOKO

そうね。一つ一つの要望の、効果と実現性とデメリットを検討して優先順位を付けたり、似たような機能をまとめたり……。


SHOSUKE

そんな時間ないんだよ。「もう設計に入らないと、絶対に本番オープンが間に合わない」ってベンダーの人が言うんだ。


TOKO

全然、設計に入ってないの?


SHOSUKE

だってシステム開発では、要件をキチッと固めて、もうこれ以上変わらないって段階にならないと、次へ進めないんだろう? ウォーターフォール方式※1だっけ?


TOKO

そんなやり方してたら、ショップのオープンはサグラダ・ファミリアの完成より遅れるわ。全ての要件が事前に固まり切るなんて、事実上無理よ。


SHOSUKE

でも要件なんだから、先送りはまずいんじゃない?


TOKO

まずいところと、そうじゃないところがあるのよ。今の話なら、「ポイント」はモノを買う部分に関する機能で、他への影響も大きいから、最初に決めておかないと先へ進まない。けれど、オバちゃんたちの話は、画面設計の時までに決めればいいのよ。


SHOSUKE

クレジットカードのセキュリティや分析機能は?


TOKO

セキュリティは大切だけど、他の機能に影響せず後から付け加えられる。分析は、それがないと他の機能が動かないものじゃないから、次フェーズでもいい。こういうふうに、本当に今やらなきゃいけないこととそうでないことをしっかり分けて※2、前者だけを決めれば、要件定義工程は完了。他は未決事項にして、後でやる。


SHOSUKE

まあ、現実的っちゃあ、現実的かなあ。


TOKO

問題は未決事項の管理ね。未決事項は単なる先送りじゃないから、きちんと管理する必要があるわ。


SHOSUKE

どうやって?


TOKO

未決事項一つ一つについて、「誰が」「いつまでに」「どんな方針で」決定するかを決めて、その進捗管理の方法も決める。そして、未決事項を期限内に解決できないと分かったときはどうするのか、その代替策もあらかじめ決めておく。取りあえずその機能はリリースしない、とユーザーの責任者判断で決めてもらうとかね。


SHOSUKE

何でも、最初に決めておくんだね。


TOKO

大事なのは、未決事項を決める人にそれなりの権限を与えておくこと。役職クラスがいろいろ自分勝手なことを言っても、最後には自分の言うことを聞けーって言える権限が必要だわ。


SHOSUKE

じゃあ、未決事項の担当者には、エラい人を充てるってこと?


※1 システム開発を「要件定義」→「設計」→「実装」→「テスト」と、明確な工程に区切って進める方法。いったん設計工程に入ったら要件定義には戻らない「滝」のような方式であることからこの名前が付いているが、実際には、前工程に戻らざるを得ないことが少なくない。

※2 一つ一つの要件を「Must(必須)」「Should(できればやる)」「Could(あれば、なお良い)」「Want(将来的にはやりたい)」に分類するMSCoW分析が有名。

       1|2 次のページへ

Copyright© 2017 ITmedia, Inc. All Rights Reserved.

TechTargetジャパン

この記事に関連するホワイトペーパー

RSSについて

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

メールマガジン登録

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