旭川医大とNTT東の騒動から「セキュリティバイデザイン」を考える

先月末、ITProに掲載された記事が話題を呼びました。

システム開発の失敗がどこにあるか争われた裁判。一審ではベンダー側に8割の非があるとされたのですが、二審では全面的にユーザー側の責任とされました。この判決、サイバーセキュリティにも影響を与えそうな内容ですので、少々追って行きたいと思います。

この記事の目次

1 騒動の大まかな経緯
2 他の現場でも起こり得るのか
3 セキュリティの確保が困難となる？
4 システム開発のあり方が変わる一石になれば

騒動の大まかな経緯

元々は、ユーザー(旭川医大)からの仕様書の入札に対してベンダー(NTT東)が落札し、開発を請け負いました。ごく普通の流れです。ところが、契約後ユーザー側より、現場の意見が出たとして、625件もの追加要件が加わります。ベンダーはこれを納入期限延長とこれ以上追加要件を出さないことを条件に受け入れます。

しかし、その後もユーザー側から次々と171件の追加要件の要求が出ます。さらにユーザーは「追加要件を受け入れてくれないと、受領できない」と主張します。

ベンダーはこのうち136件を受け入れましたが、結局納期に間に合わせることはできませんでした。ここに至り、ユーザーは契約を解除。ベンダーは不当な受領拒否を受けたとして損害賠償を要求。ユーザー側も導入失敗の逸失利益の賠償を要求することとなりました。

この訴訟に対し一審では、「追加要件を毅然と拒絶していなかったこと」からベンダーに8割の責任があるとしました。一方、二審では、弱い立場のベンダーが「毅然と拒否」するのは困難としてユーザー側の全面的な責任としました。

他の現場でも起こり得るのか

おかしな話かも知れませんが、このような事例はシステム開発の現場ではよくあります。だからこそ、話題にもなったのでしょう。でも、他の仕事でこのような事例は起こるのでしょうか？一つ、例を挙げて考えてみましょう。

あなたはタクシードライバーです。朝の9:30に客がやってきました。
「いやあ、仕事のミスで〇〇商事にお詫びに行くんだけど、10:00までに到着できる？」
あなたは、その会社までの道順を知っていました。多少道が混んでいたとしても20分あれば着きます。そこで「大丈夫だ」と言って客を乗せました。

しばらく行くと、客がこう言い出しました。
「あー、手土産持って行かないとまずいよな。和菓子で有名な○○屋に寄ってくれる？」

あなたは残り時間を判断して客に告げます。
「わかりました。でも、５分しか時間は取れませんよ」
それで良いというので、あなたは和菓子屋に寄りました。

客は、結局買い物に10分かかって戻ってきました。でも、まだギリギリなんとかなりそうな時間です。ところが、戻ってきた客はこう言います。
「いやあ、良かった、買えた。あ、でも剥き出しで渡すのは良くないな。あそこの雑貨屋にも寄ってくんない？」

あなたは流石に”これはマズい”と思いました。
「お客様、もう一軒寄るとなると10:00までに到着できないかも知れませんよ。」

客は主張します。
「そこはプロなんだから何とかしてよ。とにかく、謝罪に行くんだから剥き出しはまずいんだってば！」

客の主張にあなたは折れ、雑貨屋に寄りました。今度は客も数分で戻ってきました。あなたは、何とか時間に間に合わせようと猛スピードで車を走らせます。
「おいおい。スピード出し過ぎで捕まっちゃうよ。安全運転で頼むよ。」
確かにそれも一理あります。あなたは、通常運転で○○商事に向かいました。 …が、到着は10:00を過ぎてしまいました。

到着すると客は豹変しました。
「どういうことだよ！時間までに着かなかったじゃないか！謝罪が上手く行かなかったらお前のせいだ！運賃は払わんし、賠償も要求するからな！」

ドライバーと客のどっちが悪いんでしょう？「間に合わないから買いに行くんじゃない」と強く拒否しなかったドライバーですか？

これはシステム開発の現場でも”よくある”ケース

どんどん追加要件を要求するユーザー。しかも納期は変えようとしない。「何とかしてくれないと困る」の一点張り。なのに納期に間に合わないと賠償を要求してくる…笑いごとで無いのは、システム開発の現場では、このような事例を”良く見かける”ことです。

セキュリティの確保が困難となる？

今、国は「セキュリティバイデザイン(企画・設計段階からセキュリティを確保するよう考えること)」の取り組みを強く推奨しています。開発の初期段階からリスクを減らす設計をしておけば、必要な対策も減らせます。サイバーセキュリティ対策には非常に有効です。とても良い取り組みだと思います。

ですが、開発現場で次々と追加要件が出てきたら、セキュリティバイデザインもへったくれも無いですよね。前提条件がどんどん変わってしまうのですから。追加要件が数多く出てくるということは、それだけセキュリティリスクも増しているということなのです。サイバーセキュリティ観点から見ても、追加要件を多く出すシステム開発は高いリスクを内包していると考えざるを得ません。