orangeitems’s diary

40代ITエンジニアが毎日何か書くブログ

仕様通りに作ってバグもないのに大問題になるケースをどう防ぐか

f:id:orangeitems:20200910090346j:plain

 

ドコモ口座問題、大変なことになっていますね。

 

www.itmedia.co.jp

NTTドコモが提供する電子決済サービス「ドコモ口座」を利用して、銀行から不正に現金を引き出す被害が相次いでいる。七十七銀行(宮城県仙台市)は9月7日、同行の顧客に被害があったとしてドコモ口座への新規登録を当面停止すると発表。中国銀行(岡山県岡山市)、大垣共立銀行(岐阜県大垣市)、東邦銀行(福島県福島市)も8日、同様の理由で新規登録の停止を発表した。

 

原因については今後の情報を待ちますが、考えさせられる問題です。

ドコモ口座をどこぞのSIerが受注し、構築したかはわかりませんが、彼らとしては要件通り作ったに違いありません。

その要件については、顧客であるNTTドコモ社に承認を得ているはずです。

そこからはもう、その通り作るだけの話で、それらの仕様を一連のテストで完全に確認したはずです。そして顧客と共同で行う運用テストでNTTドコモ社も「うん、これでいいよ」とSIerに回答しているはずです。

このとき、責任、と言う意味では発注元であるNTTドコモ社ですし、SIerには責任はないように見受けられます。むしろ、仕様修正のオーダーが来ることが予見されます。仕様通り動かない、という問題ではないので、アプリケーション保守の範囲から完全に逸脱します。

このように、SIer側としては契約等々でディフェンスをしながら、ユーザー企業とお付き合いしていて責任が及ばないようにしているのが普通です。

 

ただ、最近思うのが、SIer側にいた場合に作る人が「あれ?これおかしいんじゃないの?」と気づいたとしても誰も止められないということです。

SIer側が全て内製で作り込めるケースは少なく、たいていパートナー会社にSESなどでアウトソーシングして実装します。この段階で「仕様」「要件」については神格化されることも多く、実装者が「なんだこのおかしい仕様は・・」と思っても、淡々と実装するしかないということは起こりえます。パートナー会社からすれば、お客様は元請のSIerで、ユーザー企業ではありません。志のある人が元請のSIer、例えばPMに仕様の話をしにいくのはある意味越権行為と取られる場合もあります。下請らしく、言われた通り作ればいいんだよ、と。

ユーザー企業は、SIerはITの専門家なので、専門範囲ならば指摘が欲しいと思っているふうですが、今回のような金融仕様の話だと、口をはさみにくいというのもあります。会議の中で、ドキュメントで触れない範囲で、善意を持ってこの仕様ではまずくないですか?と言う話をすることはあるかもしれませんが、そこまで行くとプロジェクトの方向性まで踏み込むことになりSIerもリスクがあります。あのときあんなことを言わなければ・・・という副作用。要件が変われば費用も変わりますから、軽々とは仕様変更の話をSIerからするわけにもいかないのです。

 

今年の7月ごろに、マイナポイント申請のWebページがInternet Explorerのみの受付、という件がニュースとなりました。今はChromeやEdgeも対応したようですが、これも、実装した人は「なんでIEなの???」とクエスチョンマークを100個飛ばしながら、感情を押し殺して実装したはずです。

このように、SIerとユーザー企業の関係は伝統的に短所を抱えていて、仕様通りに作った。バグもない。でもリリース後大問題。そんなことが起こりがちです。

ですから、最近はDXコンサルのような、仕様策定の部分から責任を持ちますよ、というビジネスモデルが流行し始めています。ここで問題になるのは、ユーザーとコンサルが一緒に考えたその仕様、誰が最終責任を負うんですか?と言う問題。多分コンサルは責任を負いたくはないでしょう。ですからSES契約を駆使して、成果物責任を負わないような受注形態を取っているのでしょう。

問題全体を俯瞰すると、やっぱりどこかで、実装している人が声を挙げられるような仕組みが必要になるんじゃないかな、と予想しています。今はそれができていない。本当は実装者の気づきって、宝の山なんですけどね。