要件が決まるまで、テコでも動きません！：美人弁護士 有栖川塔子のIT事件簿（6）（1/2 ページ）
システム開発では、要件の全てが要件定義工程の完了時点までに決まることはまれです。決まらない要件は未決事項とし、解決担当者や期限などを定めて継続的に管理することが大切です。
※この連載は「なぜ、システム開発は必ずモメるのか？」（細川義洋著）のCHAPTER1を、著者と出版社の許可の下、一部修正して転載するものです。
スーパー越後屋 御曹司の成兼章介は、オンラインショップシステムの開発を任されたのですが、社内からのさまざまな要望を要件としてまとめられません。「これ以上は待てない」とベンダーに迫られて、助けを求めに顧問弁護士 塔子のオフィスにやってきました。「と、塔子ぉぉぉぉぉ」
どうしたの？
オンラインショップの開発がうまくいかなくて大変なんだ。要件定義の期限を3カ月以上過ぎてるのに、ウチが要件を固めないもんだから、ベンダーが怒っちゃって。
どういうこと？ ちゃんと話してみなさいよ。
みんなが勝手なこと言ってまとまらないんだよ。販促部長は「ショップの買い物にポイントを付けたい」って言うし、システム管理部長は「クレジットカードのセキュリティをもっと強化したい」って。そうしたら営業本部長が「販売実績の分析機能が欲しい」とか言い出すし……。
想定外の要望が溢れて、取捨選択もできないのね？
その上、売り場のオバちゃんたちに画面を見せたら、「文字入力が多過ぎる」とか「画面が分かりにくい」とか「字が小さい」とか、もうぐちゃぐちゃ。最後はみんな、僕に何とかしろって……。
板挟みになってボコボコにされるのも、いい経験じゃない。
そんなこと言わないで助けてよ！ 僕、どうしたらいいんだよう。
そうね。一つ一つの要望の、効果と実現性とデメリットを検討して優先順位を付けたり、似たような機能をまとめたり……。
そんな時間ないんだよ。「もう設計に入らないと、絶対に本番オープンが間に合わない」ってベンダーの人が言うんだ。
全然、設計に入ってないの？
だってシステム開発では、要件をキチッと固めて、もうこれ以上変わらないって段階にならないと、次へ進めないんだろう？ ウォーターフォール方式※1だっけ？
そんなやり方してたら、ショップのオープンはサグラダ・ファミリアの完成より遅れるわ。全ての要件が事前に固まり切るなんて、事実上無理よ。
でも要件なんだから、先送りはまずいんじゃない？
まずいところと、そうじゃないところがあるのよ。今の話なら、「ポイント」はモノを買う部分に関する機能で、他への影響も大きいから、最初に決めておかないと先へ進まない。けれど、オバちゃんたちの話は、画面設計の時までに決めればいいのよ。
クレジットカードのセキュリティや分析機能は？
セキュリティは大切だけど、他の機能に影響せず後から付け加えられる。分析は、それがないと他の機能が動かないものじゃないから、次フェーズでもいい。こういうふうに、本当に今やらなきゃいけないこととそうでないことをしっかり分けて※2、前者だけを決めれば、要件定義工程は完了。他は未決事項にして、後でやる。
まあ、現実的っちゃあ、現実的かなあ。
問題は未決事項の管理ね。未決事項は単なる先送りじゃないから、きちんと管理する必要があるわ。
どうやって？
未決事項一つ一つについて、「誰が」「いつまでに」「どんな方針で」決定するかを決めて、その進捗管理の方法も決める。そして、未決事項を期限内に解決できないと分かったときはどうするのか、その代替策もあらかじめ決めておく。取りあえずその機能はリリースしない、とユーザーの責任者判断で決めてもらうとかね。
何でも、最初に決めておくんだね。
大事なのは、未決事項を決める人にそれなりの権限を与えておくこと。役職クラスがいろいろ自分勝手なことを言っても、最後には自分の言うことを聞けーって言える権限が必要だわ。
じゃあ、未決事項の担当者には、エラい人を充てるってこと？
※1 システム開発を「要件定義」→「設計」→「実装」→「テスト」と、明確な工程に区切って進める方法。いったん設計工程に入ったら要件定義には戻らない「滝」のような方式であることからこの名前が付いているが、実際には、前工程に戻らざるを得ないことが少なくない。
※2 一つ一つの要件を「Must（必須）」「Should（できればやる）」「Could（あれば、なお良い）」「Want（将来的にはやりたい）」に分類するMSCoW分析が有名。
Copyright © ITmedia, Inc. All Rights Reserved.
ITmediaはアイティメディア株式会社の登録商標です。