システムにどのような機能や性能を持たせるかを決める要件定義には、ベンダーによるガイドと、ユーザーとベンダーの役割を超えた率直な議論が必要です。
※この連載は「なぜ、システム開発は必ずモメるのか?」(細川義洋著)のCHAPTER1を、著者と出版社の許可の下、一部修正して転載するものです。
これまでの泥沼プロジェクトから担当が変わった彩音。今度のプロジェクトは、ユーザーがシステムの要件定義を任せてくれるため、開発がスムーズに進むと上機嫌です。そんな彩音に塔子は、以前担当した紛争のユーザーと似ていると忠告します。
塔子先輩、聞いてくださいよ。今度のお客さんは、「とにかく動くものを作ってくれればOK」って一切お任せで、こっちの思い通りにさせてくれるから本当に楽チンなんです。だから時間ができたので、今日は久々に合コンに行こうかと思って。先輩もどうですか? どうせ夜は暇でしょ。
彩音のその舌、いつかひっこ抜いてやるわ。世界人類のために。
せ、世界人類って。
でも、危ないわ。「私達は素人で、ベンダーにお任せしていました」ってのは、裁判所でよく聞く決まり文句よ。
でも、質問にはちゃんと答えてくれるし、決めた要件にもすぐ納得してくれるようなお客さんですよ?
任せてくれるのが“いいお客”だなんて、アンタが「アタシかわいい!」ってほざくのと同じくらいの大間違いよ。
何でアタシが出てくるんですか!
ったく、幼児並みの脳みそのくせに一人前に色気づいて、ミニスカートにカラコンぎらぎらの目で迫れば男が落ちるとか、安っぽい計算がミエミエ。そんな女に鼻の下伸ばす男がいるもんだから、あー腹立つ。
先ぱぁい。もしかして欲求不満ですかあ?
……どっかに“くぎ抜き”ないかしら。
や、やめてくださいよぉ。でも本当にどこが悪いんですか?
アタシが担当した事件にも、そういうのがあったのよ。借り手の融資履歴を外部の情報ベンダーからもらって、貸出枠を判定する金融機関のシステム※1だったんだけどね。ベンダーには実績があったので、ユーザーもすっかり安心して任せきりだったの。
ベンダーの実績は、ユーザーが1番安心しますもんね。
だけどフタを開けてみたら、情報ベンダーがくれる融資履歴のデータ形式が想定と違って、新システムに取り込めないことが分かった。データの区切りとか文字コードが全然違って、そのままだと訳の分からない文字の羅列になったり、桁ズレしたりしちゃう。
あらら。
まずかったのは、それに気付いたのが設計工程も終わろうってころだったこと。データ変換の方法を新たに検討しなきゃいけなくなって計画が狂った。
要件定義も設計もテスト計画も全てやり直しで、スケジュールは大幅遅延。何とか間に合わせようと慌てたから、テストやレビューも足りなくて、出来上がったシステムはボロボロ。文字化け、桁ズレ、処理中断の山でね。このときになってユーザーが怒り出したって始末よ。
あちゃー。
ベンダーは「データが特殊過ぎる」って言うし、ユーザーは「素人の自分たちが知るわけない。そもそも変換プログラムなんて要件定義書にないものを勝手に作って、こんなひどいものができたんだから、ベンダーが悪い」って。
確かに、ユーザーは被害者ですよね。
そう思うのは素人よ。この紛争は、ユーザーの「お任せします」とベンダーの「承りました」の併せ技で「一本!」
併せ技?
※1 いわゆる「信用情報管理システム」。外部の信用情報ベンダーから借入希望者の取引履歴や自己情報を入手し、収入や担保の有無、種類、保証人情報などと併せて、貸し出しできる金額(信用枠)を算出する。
Copyright © ITmedia, Inc. All Rights Reserved.