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

プロジェクト管理面での責任

　そしてこうした開発を行う場合、プロジェクトの管理、特にリスク管理、スケジュール管理、メンバーのスキル管理といったものが、ベンダー主導でないと行えないと考えられます。

　パッケージを利用する場合「どうしてもFitできない部分があった場合どうするのか」という問題があります。これは「そういう部分があると分かったわけではないが、もしあったらプロジェクトの進行に重大な影響を与える」という「リスク」として定義できます(ちなみにそういう部分があると分かった場合には、この「リスク」は「課題」になります)。

　通常の開発であれば、何か実現が困難な要件が検出された時点で、これを「リスク」あるいは「課題」として定義しますが、パッケージの場合は、その採用が決まった時点で、この「どうしてもFitできない部分があった場合どうするのか」をリスクとして定義すべきと私は、考えています。

　その際にやるべきことは、ケースバイケースですが、

1. パッケージソフトのプログラムやデータベースを開発元にやってもらう
2. 同じ機能の代替プログラムを、別途ベンダーが作成する
3. パッケージソフトの上に別のプログラムを被せて、都合の良い入出力に変える
4. ユーザーの業務自体をパッケージに合わせて変更する
5. 採用するパッケージを変える、あるいは、スクラッチ開発に変更する

　などがあります。

　パッケージを使う際には、こうしたことを常に頭に置いてプロジェクトを進める必要があります。そしてこれらのうち、多くはベンダーが主導しなければならない部分です。4や5にはユーザー側の責任も入るかもしれませんが、ベンダーが言い出さなければ、事は進まないでしょう。

　ベンダーにはこうした事に対する備えを行っておく責任があります。つまり、

A　パッケージの中身を熟知して、正確なFit＆Gapを行い、妥当な解決策を提案できるメンバーを十分に関与させる体制を構築する

B　パッケージソフトの開発元にパッケージソフトやデータベースの変更が可能か確認し、必要時にはその作業を依頼できるように確約をとっておく

C　代替プログラムなどの開発要員を必要時にアサインできる準備をしておく

D　必要時にユーザー業務変更の依頼やパッケージ変更の申し出をタイムリーに行える場をあらかじめ設定しておく

　などがあるでしょう。

　今回の場合、これらのこと、特にAやDが適切に行われなかったのでは、と考えています。プロジェクトの体制構築とメンバーのスキル管理、およびユーザーとのコミュニケーション管理がうまくいかず、それ以前にこれらを「リスク」や「課題」として捉えて、あらかじめ定めた対応策とその発動基準を基に監視する「リスク管理」、「課題管理」がうまくいかなかった。

　契約解除の直前になって、IBMがパッケージソフトの変更を申し出ていますが、この時期の遅さはこうしたことを表していると思います。裁判所は、これらを総じて「プロジェクト管理責任」と捉えたのではないでしょうか。今回の判決について、各方面から驚きの声も聞かれますが、開発の現場を知る私としては、それほど意外なものではありませんでした。

ユーザーにもやれるべきことはあった

　今回の裁判は、プロジェクト開始後のことを範囲としていますので、上述のようなベンダーの責任を重く考える結論に達したのかもしれませんが、ユーザーの立場からは、何もできなかったのでしょうか。

　請負契約の責任論はともかく、プロジェクトの成功のためという観点で言えば、ベンダー選定やプロジェクト計画立案の段階で、上述のようなことをチェックし、不足分についての対応を初期段階でベンダーに求めることができたのではないでしょうか。

　「ちゃんと分かってる人が参加してくれるの？」、「万一に備えて、どこまでパッケージを直せるの？」、「追加開発が発生したらどんなスキルの人がやってくれるの？　影響調査はできるの？」、「会議には、どんな人を参加させたら良いの？」などなどの質問をベンダー選定時にぶつけて、その回答を選定の判断基準にする。

　プロジェクト計画時や実施中も、それらが担保されていることを管理する。リスクや課題の管理をベンダー任せにしない。専門家の責任範囲やあるべき論はともかく、これらのことを行うことは、ユーザー自身に取って非常に有意義なことです。ぜひ、こうした評価軸をユーザー自身が持って、できれば社内で標準化して欲しいものです。

おわりに

　スルガ銀行とIBMの紛争について思うところを書いてみました。「後になってからならなんとでも言える」とのご意見もあるでしょう。しかし、まだまだ未成熟なこの業界においては、今までも、これからも、数多くの失敗からさまざまなことを学び、ユーザーもベンダーも成長していくことが必要です。「後になってからの学び」こそ、IT業界発展のための宝です。両社がユーザーとして、ベンダーとして、今回からの教訓を糧にさらに成熟していくことを強く望みます。