定まらない要件、ユーザーからのむちゃな要求：システム開発プロジェクトの現場から（4）（2/2 ページ）

タフなユーザーのタフな要求

　やっとの思いで契約にこぎつけ、ほっとしたのもつかの間、今度は発注部門の担当者からの厳しい要求が待っていました。

　この方は以前から、ITサイドにとって手ごわい存在として有名でした。予算が決まった後からできるだけ多くの要求を出し、少しでも多くの機能を実装させようというポリシーの持ち主だったのです。「これも当然やってくれるんですよね？」というひと言に、これまでも多くのメンバーが泣かされていました。

　このときもそのようなノリで、要求を提示されたのです。

　物流の現場では、倉庫から製品を出荷するとき、先入れ先出し法（先に入庫された製品から順に出庫する方法）で行うルールとなっています。

　担当者からの要求は次のようなものでした。倉庫からの出荷データにロットナンバーがなくても、出荷が先入れ先出しで行われたと見なせば、入庫時の情報を頼りにロットナンバーは類推できるはず。だからロットナンバーが記録されていない在庫移動については、システムが仮想的に計算してロットナンバーを割り出す仕組みにするべきだと。

　確かに趣旨は理解できます。しかしこのような要求をそのままシステムに取り入れたら、現場で行われている物流パターンをシステム上にくまなく再現し、断片的な情報からその流れを類推するという、シミュレーションシステムのようなものになってしまいます。いきおい、機能や仕組みは複雑なものとなり、システムの規模は一気に40〜60％も大きくなってしまいます。

　予算はすでに確定してしまっていますから増額は望めませんし、食品の安全性にかかわるシステムですから、バグを頻発させて間違った結果を出したり、パフォーマンスを犠牲にしたりすることは許されません。

　この要求を聞いたときは、一瞬、目の前が暗くなりました。……こんなとき、皆さんならどうしますか？

本当に妥当な要求なのか？

　この要求に対してどう反応すべきか考えていたとき、以前上司のSEから聞いた言葉を思い出しました。

　「要件定義は、客から拾い集めた要望を取りまとめる作業ではない。客から集めた情報を基に、システムのあるべき姿をSEが責任を持って考え出す作業だ」。要件定義においては業務の特性やIT的な制約から、システムの「あるべき姿」を描き出すべきであり、それができる立場にいるのはSEしかいない、という意味の言葉です。

　私はこの言葉に立ち返り、あらためてこの要求について考えてみることにしました。

　仮に、要求どおりシミュレーションを行ったとしたら、その結果は「きっとここにあるだろう」というものになり、100％確実なものではなくなってしまいます。品質に問題がある製品の所在を突き止め、確保しようというとき、このような不確実な要素をはらんだ情報を当てにするでしょうか？

　また、そのようなロジックを実装するためには、大量で複雑なソースコードを生み出すことになります。今回の導入時に予算を抑えられたとしても、長期的には仕様変更への許容性や改修にかかるコストなど、ユーザーにとってもやはりデメリットはあるのです。

　今回のシステムの目的を考えれば、ロットナンバーが存在する履歴は事実としてそれを提示し、ロットナンバーが存在しない履歴は、参考情報を提示するというポリシーを採るべきであり、それらの情報をユーザーが把握しやすいように一元的に提供することが主眼であると考えました。システムができるのはそこまでであり、不足する部分は人間系による判断、つまりユーザーが情報を集めて行う判断に委ねるべきなのです。

　実務上の物流の全体像を念頭に資料を準備し、担当者にこのようなポイントを説明しました。何回か打ち合わせを重ねてようやく納得してもらうことができ、無事に要求は取り下げられました。

要件定義のあるべき姿

　上流工程で時間を消費してしまったため、後続の工程は日程的に苦しくなってしまいました。

　しかし、これは緊急時に使われるシステムです。瞬時に結果が返ってくるパフォーマンスと、必要な情報を端的に検索・照会できるユーザーインターフェイスにすることに手を抜かず、設計、実装を行いました。結果として、要件どおりのシステムを完成させることができました。

　今回のプロジェクトでは、なかなか定まらない要件、発注部門の担当者からの過度な欲求などに悩まされました。しかし「要件定義とは、システムのあるべき姿を責任を持って考え出す作業だ」という上司の教えを思い出し、あらためて実践することができました。厳しいスケジュールの中でも自分でスコープをコントロールし、かつ要件にマッチした機能を実装できたという手応えを感じたプロジェクトであり、多くのことを学べたと思います。

　幸か不幸か、私が契約満了でそのクライアントの元を離れるまで大きな製品不良は発生せず、このシステムが実務で使われることはありませんでした。

　使われないのが幸せな仕組みというものもあるんですね。