ユーザーの厳しい要求がベンダーの質や力を向上させ，システムを成功させると言われる。しかし，その一方でユーザーの厳しい要求，頻繁な要求変更に対応しているうちに，システムが複雑に錯綜して，硬直化してしまうという例が少なくない。どちらも両極端な見方だが，いずれにしろユーザー要求は，あるところで切り捨てられなければならない。
これからシステム構築に取り掛かる場合は，オーソドックスにユーザーの要求を反映するように努力すべきだ。だが，この連載で取り上げてきた「いったん稼働したがレイムダック化（弱体化）したシステム」を甦生させるには，ユーザー要求を「力ずく」で切り捨てることも，無視できない有効な手法である。
不十分な要件定義がシステムのレイムダック化を招く
まず，「ユーザー要求を軽視している」という誤解を解くために，システム構築時のユーザー要求がいかに重要かということに若干触れておくことにする。
IT導入の目的が業務効率化などの単純なものであればともかく，最近のように資産価値の最大化・顧客満足度の向上などの戦略的なものになると，ユーザーの要求を明確にしておかなければシステムは誤った方向へ進みかねない。そのためにはユーザーの要求をまとめた「要件定義」をドキュメント化することが必要となる。
「要件定義」をまとめるにあたっては，システム構築側とユーザーとの緊密なコミュニケーションが欠かせない。ユーザーはリーダーシップを取るくらいの考えで要件定義の作成に臨まなければならない。一方，システム構築側は完成した「要件定義」の行間を読み取らなければならない。さらに，要件定義書はソフトウエア開発中はもちろん，開発後にも保守ドキュメントとして活用することになる。このため，そうした活用に対して要件定義書が機能・拡張性・信頼性・期限などの点で耐え得るかどうかを評価する手法も心得ておいて，忘れずに実施しなければならない。
しかし，私の経験から言って，要求仕様のドキュメント化を省略するか，ドキュメント化しても形だけで終わらせてしまうケースが数多く見られる。
ドキュメント化を軽視する主な理由は，いちいち整理してドキュメント化する時間もないし，しなくても分かっているというものだ。そこには，「要求仕様にはドキュメント化の必要が無い」という信念さえうかがえるような当事者，あるいは当該グループの体質の問題がある。何度注意してもドキュメント化しようという姿勢が見られず，スケジュール通りにシステムを完成させればいいのだろうという開き直りさえ感じられる。
「要件定義」が不十分だと，ユーザーの要求に対する解釈が，本来の当事者ではない後工程の設計者やプログラマにまかせられることになる。不十分な「要件定義」をもとに設計やプログラムの工程に入れば，どんなシステムが出来上がるか，想像に難くない。
それでなくても，ユーザーの要求は変わりやすい。十分に打ち合わせしたつもりでも，いざシステムが稼働を始めるとユーザーからは「意見が反映されていない」，あるいは「誤解されている」という，対応が難しい変更要求が頻繁に寄せられる。
それに対応しない，あるいはできないために，システムはユーザーから敬遠され，やがてレイムダック化する。
ユーザー要求の切り捨てには根拠がある
さて，レイムダック化したシステムの甦生を，どう図ったらよいのか。残念ながら，奇策はない。トップ主導の相当思い切った対応が必要だ。
私の経験から対応策は3つある。1つはレイムダック化したシステムの心臓にショックを与え，強制的に甦生させる方法だ。具体的には，ユーザーの不満をいっさい無視して，強制的にシステムを利用させる。例えば，エンドユーザー部門から「経理部門の仕事を楽にするために，どうして我々がデータ入力しなければならないのか」とか，「フォーマットを変えなければ使えない」という不満が噴出しても，最終的にトップの号令で押さえ込み，罰則を課してでも強制的にシステムを使わせる。
2つ目は，ひとまず対症療法的な小手術を施した上で，ユーザー要求や業務改善などを視野に入れた大手術へ進む方法である。そして3つ目はレイムダック化したシステムをプロトタイプと割り切っていったんスクラップして，要件定義からシステムの構築をやり直す方法である。
この3つの方法からどれを選ぶかは，予算，期限，そして人材など企業の体力によって判断されるべきである。
それぞれの方法にはメリット・デメリットがある。ただし，いずれにも共通して言えることは，ユーザーはどこまでいっても，必ず不満を並べるもの，変更要求を出してくるものと考えることである。システム構築側は際限無くユーザーにお付き合いすることは避けて，あるところでユーザーからの要求を冷たく切り捨てる必要がある。また，ユーザー側も，適当に譲歩すべきである。
ここでシステム構築側が，ユーザーに不必要な負い目を感じることはない。ユーザー側も不必要に過大な不満を感じるべきではない。なぜなら，ユーザー要求を適当なところで切り捨てることには，いくつかの根拠があるからである。以下，主な根拠を列記する。
1．ユーザーはとかく自部門だけを念頭に置きがちだが，システムは全体最適を考えなければならない
2．ユーザーは自己中心になりがちであり，レアケースを一般論化して主張する場合がある。システム化せずに，手作業で対応する選択が正しい場合もある
3．ユーザーの意見を聞き過ぎることで，システムが複雑怪奇になり硬直化するおそれがある
4．ユーザーがシステムを使わない言い訳として，「要求を聞いてもらえなかったから」と主張する場合がある
5．費用との関係から，要求を無制限に聞いてはいられない
こうして考えてくると，「適当なところでのユーザー要求の切り捨て」はシステム稼動後の甦生だけの話ではない。システム導入時にも，同じように「適当なところでのユーザー要求の切り捨て」が必要になるはずだ。
|
→増岡 直二郎バックナンバー一覧へ |
■増岡 直二郎 (ますおか なおじろう)【略歴】 小樽商科大学卒業後，日立製作所・八木アンテナなどの幹部を歴任。事業企画から製造，情報システム，営業など幅広く経験。現在は，nao IT研究所代表として経営指導・執筆・大学非常勤講師・講演などで活躍中。 【主な著書】 『IT導入は企業を危うくする』，『迫りくる受難時代を勝ち抜くSEの条件』（いずれも洋泉社） 【連絡先】 nao-it@keh.biglobe.ne.jp |
