システム開発会社をパートナーとみなさない発注者には気をつけよう

以前から、こうした事件は起こっているわけだが、野村證券とIBMの訴訟合戦は最高裁まで行くことになったらしい。

よくある現状踏襲

日経コンピュータの「フォーカス」というコーナーで読んだ、野村證券とIBMの訴訟合戦。
記事を拝見する限り、いわゆる「現状踏襲」に固執するあまり、要求追加と仕様変更が多発して制御不能になるパターン。
システム導入の際、現状踏襲するべき部分というのは確かにゼロではない。
ただ、それに固執するあまり、システム導入による業務改善がなされないというのは良くある話である。

そもそもは「お客様は神様」思考

こうしたシステム開発の失敗で根底にあるのは、「お客様は神様」思考である。
「請負契約を結んだのだから、完成責任はシステム開発会社側だけにある」
という間違った思い込みが失敗を招く。

システム導入が成功すれば、発注者は大きな恩恵を受ける。
つまり、システム開発を邪魔するようなことは、自分の首を絞めることになる。
その意味では、発注者もシステム開発会社も同じベクトルで動かなければならない。

だが、失敗したシステム開発の現場では違うことが起こっている。
発注者が神で、システム開発会社は人間ではないのである。

仕様変更が悪なのではない

こういう話をすると「お金を払っているのに、思い通りの仕組みが作れないのでは意味がない」という反論が来る。
全くその通りである。

つまり、仕様変更自体が悪だと私は言っているのではない。
それを出すタイミングが間違っていると言っている。

今どきではないと言われながらも大きなシステムではいまだにウォーターフォール型の開発が行われている。
ウォーターフォールが悪いとも言っていないので、注意して欲しい。
ただ、ウォーターフォールの弱点である「仕様変更に弱い」という点を意識せずに進められていることが問題である。

要求定義段階ですべてを網羅できないことは人間がやることだから避けられない。
しかし、要求変更を出しても、納期は変えない、開発範囲はそのまま、支払金額も増やさないでは、とん挫するのは当然である。

発注者も開発に協力する

成功しているシステム開発は、たいていの場合、発注者が開発に協力的である。
発注者が神になっているときは、概ね、失敗している。
リリースが無駄に伸びたり、システム開発会社が逃げたり、訴訟に発展したり、開発中止になったりである。

発注者はシステム開発会社を「システム開発を成功に導くパートナー」とみなしたほうがいい。
もし、そうみなせば、相手を思いやる気持ちも出てくる。
無理な仕様変更も言いにくくなる。

仮に言ったとしても、納期や開発範囲、支払額などを変更するだろう。

結果として、開発会社側もそれを意気に感じて、譲歩してくる部分も出てこよう。
保守も含めて、長く付き合う可能性がある関係性を保てる方が、お互いのためである。

ただし、ひとつ気を付けることがある。

システム開発会社側も倫理的行動をとる必要があるのである。