多様性を選ぶのか、それとも安定性を選ぶのか

島田　エンドユーザーとベンダーが組んで作ると、稼動後のリスク認識の甘さからか、運用面やセキュリティ面で脆弱なシステムになりやすい感じがします。多くの場合、開発したベンダーが運用も面倒見てくれるケースが多いようでしたが、それでも私たちから見るとリスク認識が十分でなく、脆弱性を抱えているシステムがずいぶん見受けられ、稼動後しばらくしていろいろなリスクが顕在化することがありました。

　システム構築は、よく建設に例えられることがあります。お客様と設計士との間でどういう家を建てるか明らかにしていって（要件の明確化）、その後、設計図の完成（要件定義書）、それに従った建設作業（プログラミング、テスト）、引渡し（納入）という感じだと思います。しかしながら、システムには建築基準法がないんです。だから先ほどの話にあったように、見かけはいいけれど、耐震性や耐久性などの確認や保障がなされていることはほとんどない。

http://ascii.jp/elem/000/000/425/425923/index-4.html

メインフレームに携わったことがないので、オープン系の経験をベースにしていろいろ書くけど、オープン系だとメインフレームではすでに用意されている機能を実現するために、いろいろとしなければならない事が多いけども、そのための選択肢がたくさんあって、それで必要十分のものが選べるから安くなっているんだと思ってる。

結局のところ、「自分たちで選択できるようにしたから、それに関するリスクも自分たちで取れよ」っていうルールを理解しないで、全部ベンダーにおんぶにだっこしてきたツケがリスクとして顕在化してるだけじゃないのかな？（メインフレームだとそうせざるを得なかったけど。）

少なくとも私が保守や追加開発で見てきたシステム（1998年頃から2002年頃）では、どういう運用にするのかとか、復旧するときにはどうするのかとか、そういった部分に注意しているものはほとんど無かった。

昔のシステムの文書を見ても、非機能要件に関する記述はとても少なく、せいぜい性能についての記述があればよい方で、システムがぶっ壊れた場合にどの程度の期間で復旧させなければならないかとか、テストやデータの移行を容易にするためにどういった方針にするとかいう記述はまず無かった。全部ベンダーというか現場の担当者任せだった。

ある機能をどのように実装するのかということに手一杯で、非機能要件はあまり考えていなかった事が伺える。
(機能要件をちゃんと整理していたかというと、疑問がのこるけど。)

――システムにもそういう基準法が必要だと言っている人もいますよね。

島田　私もそう思いますよ。私どもの会社では、セキュリティ要件や性能要件などの非機能要件についての基準を“システム強度”としてある程度明らかにし、その基準を満たさないシステムについては稼動させないようなルールにしています。この“システム強度”が建築基準法のように一般化され、いろいろなシステムの客観的な評価基準に使えるといいと思うんですけどね。

この部分にはだいたい同意する。

近年になって発足したNTTデータ公式サイトが
非機能要求に関する共通の基準を作った事は大きな進歩だと思う。