オルタナティブ・ブロガーの視点：スルガ銀行とIBMの紛争について (2/3)

ベンダー側にこそ厳しさが必要

　この判決はパッケージソフトウェアのカスタマイズについてではありませんが、少なくともシステム作りの、特に要件定義においてユーザーにも一定の責任があることが述べられています。裏を返せば、システムの機能を明らかにするのにベンダー任せではできないということになります。そしてパッケージソフトウェアのカスタマイズにおいては、特にシステムの中身がユーザーから見えにくいことから、逆に、より厳しい目でパッケージソフトウェアの内容やベンダーの作業を見る必要があると考えられます。

　パッケージソフトウェアを導入する場合、構築したいシステムの機能や性能、データの持ち方などとパッケージソフトがもともと持っているそれらを比較して乖離を明確にする、いわゆるFit＆Gapと言われる作業をベンダーが中心となって行いますが、ユーザーには、その結果を責任を持って評価する目が必要です。

　そしてもし両者の乖離が大きい場合には、パッケージソフトウェアをどこまで大胆に修正してくれるかを確認し、その改修で本当に自分たちの望むものになるかを評価する目も必要です。ベンダー側の技術者が、そうしたことに対応するスキルを持ち合わせているかを評価する目も併せて必要になりますし、それ以外にも、パッケージソフトウェアを使用するリスクを洗い出し監視する目や、パッケージソフトウェアが使えないとなったときに損切り覚悟でやり直しをいち早く判断できる仕組みも必要でしょう。

　パッケージ開発には、ある意味スクラッチ開発よりも難しい作業がユーザー側の責任で行われる必要があるのです。

ベンダーの責任は有限

　このような専門的なことを評価したり判断したりするのは、素人であるユーザーには酷だ、との意見もあるでしょう。しかし、システムを使用して大きなメリットを享受するのも、会社の経営に重大な陰を落とすほどの失敗を受け入れざるを得ないのも、結局ユーザーであり、ベンダーの責任はあくまで有限です。

　上述のような評価をベンダーにさせて結果を納得できるまで何度もヒアリングしても良いですし、第三者的立場の技術者に見てもらっても良いと思います。自社の要員を教育してこうしたことができるようになれば、それに越したことはありません。

　パッケージソフトウェアを活用した開発は、ある程度の機能を具備しているものをカスタマイズすることから、導入は容易で手間のかからないものに思えるかもしれません。確かに導入期間は、短縮できることが期待できますし、結果としてコストも抑えられるケースがあります。しかし、ユーザーに求められるスキルについて言えば、むしろ、スクラッチ開発より高いものが、要求されると私は考えています。

問題は要件定義

　判決については明らかにされていない部分も多く、詳細な説明は私もできないのですが、費やした開発費のほぼ全額を変換するように命じられたIBMの問題点は、「プロジェクト管理の義務を果たさなかったこと」が大きかったようです。

　種々の状況から察するに「IBMがパッケージソフトを用いた開発に係るリスクを管理しなかったため、要件定義を3回繰り返しても要件が固まらず、結果としてプロジェクトが頓挫してしまった」といったところでしょう。これは、どういうことでしょうか？

　私なりの理解を述べます。要件というのは、情報システムに持たせたい機能や性能のことです。銀行のATMで預金を引き出す部分であれば、「顧客が、画面から暗証番号を入力できるようにする」、「入力された暗証番号が正しい事をチェックする」、「顧客が、画面から引き出したい金額を入力する」、「入力された金額が、口座の残高より少ないことをチェックする」、「ATMに引き出しの指示を出す」、「引き出された金額と手数料分を口座の残高から差し引く」、「取引後の残高を画面に表示する」と言ったシステムにやらせたい機能が並びます。

　性能の方は、「ユーザーが画面から入力した後、次画面を表示するまでの時間は、0.5秒以内とする」といった処理速度などが定義されます（勿論、開発において定義する要件は、これらをもっと細分化して定義するのですが、今回は要件定義について詳細に説明する場ではないので、最上位のごく大ざっぱな部分だけ書きます)。

　今回の紛争では、こうした要件の定義を3回やってもまとまらなかったとのことです。「暗証番号のチェックだけでは足りない。カードそのものが偽物でないこともチェックしてほしい」、「うちは1つのカードで預金と貸し付けの2つの出金ができる。この要件では対応できない」、「応答時間が0.5秒では遅過ぎる」というように、ユーザーが自身の業務からみて修正を加えるべき点についてさまざまな注文を出し、これに応えるとまた別の注文が出て、といったたぐいのことが延々と繰り返されたことでしょう（説明の為の例示です。スルガ銀行やIBMがここまで稚拙な要件定義を行うことは、なかったでしょう）。

パッケージ利用の要件定義はベンダー主導

　ここで1つ疑問が湧きます。要件定義がまとまらなかった責任を本当にベンダーだけが負うべきものなのか？　ということです。

　システム開発の要件は、ユーザーとベンダーのキャッチボールで定義されていくものであり、まとまらない責任は双方にあると考えるのが自然です。ユーザー側が出した要望を、ベンダーがその実現手段を検討しながら後続の設計工程の入力となり得る要件に落とし込み、ユーザー側がこれを承認するのが一般的なやり方です。要件定義がうまくいかないことの原因は、双方に求められる筈です。

　では、何故今回は、専らベンダーにその責任を求める判決が出たのでしょうか。私が考えるに、今回の開発がパッケージソフトをカスタマイズしてシステムを構築するタイプであったことに原因があります。

　パッケージソフトを利用する場合には、前述のFit＆Gapという作業が行われます。この作業には、パッケージソフトに対しての深い理解とこうした開発ならではのプロジェクト管理能力が必要であり、普通は専門家であるベンダー側でなければできない部分が非常に大きいものです。

　ユーザー「このソフトには、われわれに必要な○○機能がないけど、どうするの？」　ベンダー「新しく作り込みましょう、元の部分とのつなぎには、こんな関数を作れば、うまく行きます。機能要件として定義しましょう」

　ユーザー「このデータ項目は、うちでも必要だけど、桁数が違うね」　ベンダー「桁数の変更は可能です。変更すべき箇所は、こことここです。データのカスタマイズ要件ですね」

　といったように、要件定義がベンダー主導で行われます。ユーザーが必要とする機能を、ベンダーが技術的な実現可能性を確認しつつも、基本的には「承る」だけのいわゆるスクラッチ開発とは、ベンダーの責任が随分と違ってきます。