注目の書籍好評発売中！
必聴講座ご紹介 Cloud Days Tokyo 2012 エムオーテックス Cloud Days Tokyo 2012 ヴイエムウェア Cloud Days Osaka 2012 アマゾン データ サービス ジャパン |
記者の眼
「危険」という視点からのチェックが動かないコンピュータを減らす動かないコンピュータ・フォーラム（13）前回の「危険になる動かないコンピュータと安全の関係」というテーマにも70人を超える方からご意見をいただきました。今回も非常に参考になる意見ばかりでした。ありがとうございます。 今回は，これらのご意見を中心にして，動かないコンピュータの撲滅に「安全（Safety）」という考え方が有効なのかどうかについて，考えていきたいと思います。 東京では7月23日土曜に最大震度5強を記録する地震が起きました。この時，震度データを政府に伝達する東京都のシステムの処理能力が不足していたため，正確なデータの配信に時間がかかり，政府の危機管理のスタートまでに30分が経過してしまいました（関連記事）。システムが原因で，初動対策が遅れたわけです。今回の初動の遅れは，大きな問題を招いたわけではありませんが，改めてシステムというか情報の影響力の大きさを感じました。 少しだけお知らせがあります。前回のフォーラムでもお伝えしましたが，6月に日経コンピュータが誌面刷新を実施しました。このフォーラムと連動する連載「動かないコンピュータ」はページ数を3ページに拡大して継続中です。8月8日号では，東京都の震度データについてもレポート記事を掲載しました。日経コンピュータは，こちらのページからお求めいただけます。 システムが人の命にかかわる時代に 東京都の震度データ伝達システムのケースに限らず，「動かないコンピュータ」が，さまざまな危険を呼ぶことが増えていると，読者のみなさんもお考えのようです。システムがもたらす危険は以下のご意見のようなものが代表的といえるでしょう。
大規模な損害額システム停止・誤動作により社会的信用への打撃 （ユーザー）
ありとあらゆるリスクに関係する。日常生活から企業のリスク管理そのものにまで影響してくる。なぜならばすべてシステム頼みだからである。 （ユーザー） シンプルですが，以下のようなコメントもいただいています。
人命を危険にさらすケースもあると思います。 （ユーザー） こういった危険の潜む動かないコンピュータを減らすために，「安全（Safety）」という考え方が有効かどうかという問いに対しては，約7割の方が「そう思う」と回答されました。「そう思わない」と回答された方は全体の約1割でした。 ただ残る2割のみなさんは「分からない」という回答でした。提起編の記者の文章が分かりにくかったせいかもしれません。読者の方からも，以下のようなご意見をいただきました。
病院の停電，信号機の停止，航空管制装置の故障など，すでに我々はシステムによる危険に曝されている。わたしが認識している『動かないコンピュータ』のタイトルの意味は，実稼働に至らなかった開発プロジェクトやシステムのことであり，安全性という考え方とはなじまない。むしろ焦点外の問題であると思っている。 （ベンダー） 少し補足説明したいと思います。記者は，「動かないコンピュータ」というものについて，もう少し幅広い視点で捉えています。実稼働に至らないシステムやプロジェクトも問題ですが，大きな問題を抱えているにもかかわらず本番稼働しているシステムにも，同じような問題があると考えるからです。 実際に日経コンピュータの連載で取り上げた「動かないコンピュータ」の中にも，こうした例はいくつも存在しています。前回の記事でもこういった部分については十分に説明できていなかったかもしれません。「安全」という視点が有効ではないかと考えたわけです。 あるベンダーの方からは，システムだけではなく経営の視点を加えて考えると，「安全」という考えが生きてくるのではないか，というご意見をいただきました。
もし空気がなかったら，水が一滴もなかったら，などとはなかなか考えないもの。品質がこれまで追求されているほど，異常事態は想像できない。システム単体は品質，経営システムとして大きく見るときに安全という概念が現実的に見えるのではないか。 （ベンダー） 最近，システム運用に関連した形でITIL（関連記事）というキーワードがよく使われます。最近，ITILを策定したオリジナル・メンバーの一人とお話する機会があったのですが，ITILはもともとシステム運用に関するものではなく，ビジネスと不可分なITを使ったサービスの改善や継続を目的とするものだといいます。ビジネスや経営とITが不可分になっている時代だからこそ，システムに「安全」という要素が求められるのではないでしょうか。 システムが危険なトラブルを招く理由に関するご意見もいただきました。いずれもベンダーの方からのものですが，単純なユーザー批判とは言い切れない気がします。
システムがもたらす重大性も，様々な危険と直接にしかも日常的に触れているシステム関連職種の人間がQCDSEのうち，守りやすい部分を優先するようインセンティブを持ってしまうこと。これが，一番の「危険」なのだと思います。システム開発で「危うそうなら近寄らない君子気取りの小人」ばかりになると，Dが遅れCがかさみQが保証されるのを待つ間に無価値なシステムになってしまうのでしょう。これでは，SもEも「うるさい職場ルールが増えたな。面倒くさい。目をつけられない程度の適当な対応でいいだろう・・・」といった感覚でしか取り組めないのでしょう。 （ベンダー） ご意見にある「QCDSE」とは，QはQuality（品質），CはCost（価格），DはDelivery（納期）を意味するQCDに，Safety（安全）のSとEnvironment（環境）のEを加えたもののことで，建設業界ではすでに一般的な言葉だといいます。前回のフォーラムで記者も使いました。 もう一つのご意見は以下のようなものです。
最近のシステム開発では難しいが，「時間」が必要。納期を維持するためにリリース前のテストや運用設計に費やす時間がほとんど無い。システム構築プロセスの中に「安全設計」という考え方を持たせることが必要だが，結局は工数が増えコスト高になるため，ユーザには受け入れられないかもしれない。 （ベンダー） 最初のご意見は動かないコンピュータを巡る人の問題，二つ目のご意見はカネの問題と言い換えることができるのかもしれませんが，「安全」という視点でシステムに投資する人やコストの適正量を再検討することも有効かもしれません。 |
